Machine care: service access, updates, remote support and recovery
Use this manual after a cabinet has been identified, provisioned and accepted. Check the physical cabinet, installed application and software machine number against the assigned Operator account before servicing. A hardware badge in the app is a useful clue; it does not establish the installed controller or Android firmware.
The downloads page records the current verified APKs and their package, version and integrity evidence. A published APK or rollout offer does not prove that a cabinet installed it or passed physical acceptance. The photographed VC EL cabinet remains unidentified and awaits access for flicker diagnosis.
Daily checks and service windows
At opening, check fresh connectivity, faults, available stock, product prices/currency and unresolved orders for the correct cabinet. Confirm important configuration changes on the shopper screen. A cloud save alone does not establish that an offline machine received it.
Before maintenance, finish any active purchase and use the cabinet's documented service procedure to suspend new sales. Preserve unresolved payment, dispense and offline-report references. Do not reboot, update or start another vend while the original outcome is uncertain. After servicing, verify the normal kiosk returns, connectivity and controller readiness recover, and pending transactions are reconciled before reopening.
Service access and credentials
Obtain the assigned cabinet service credential from the fleet owner through the approved credential vault. Do not use public/default PINs or copy passwords into support chat, screenshots or reports. Operator login, the cabinet service PIN, its cloud device credential and a remote-support password serve different purposes.
| Cabinet | Authorized service entry | What to verify afterward |
|---|---|---|
ZHZN KioskX, ai.intelliverse.zhzn.kioskx |
Tap the top-left corner seven times within five seconds, then enter the assigned service PIN | Follow the service menu's supported Android/settings action; return to the kiosk and confirm its locking/launch policy |
Reyeah JD, com.ruiye.jd |
Long-press the invisible top-right service hotspot, then enter the assigned cabinet credential | Use the native service menu; confirm the vendor storefront and controller connection return |
| VC EL / another vendor installation | Use the manufacturer's existing service procedure | Record app/package/OS/controller identity before selecting software or changing settings |
Have the credential owner rotate access through the supported provisioning process. Confirm the new credential on the actual cabinet and revoke superseded access. Offline machines, missing device credentials or OEM restrictions can prevent remote changes; rotation is not guaranteed to take effect without a visit. Repeated incorrect PIN attempts do not repair an enrollment or connectivity fault.
Detailed procedures: ZHZN Android operation, ZHZN device identity, Reyeah operation.
Update the correct software layer
| Layer | Correct release/recovery procedure |
|---|---|
| Android vending APK | Select the matching cabinet package from downloads; verify signer, hash, Android/ABI and advancing versionCode; follow the family's Android installation guide |
| Operator phone/tablet app | Use the Operator platform guide; a phone update does not replace cabinet software |
| Vending-controller board firmware | Use the exact controller manufacturer's approved firmware, tool and recovery procedure; an Android APK rollout does not flash the VMC |
| Separately installed Linux/Python ZHZN agent | Use Linux agent upgrades and boot-guard recovery only when that agent and recovery arrangement are actually provisioned; its signed archive/install-root rollback is not Android APK rollback |
For an Android update:
- Record the current package/version/signer, cabinet/controller/ROM, machine identity and unresolved transactions. Have the approved recovery material and an onsite escalation contact available.
- Select the immutable verified file for that package from downloads. Match its digest and signing identity, Android/ABI requirements and versionCode to the installed device. Manufacturer branding alone does not establish compatibility.
- Follow ZHZN Android installation or Reyeah installation and migration. Use a named supervised canary before an authorized wider rollout. Silent installation requires the relevant provisioning and privileges; an ordinary sideload may need local Android approval.
- Track offered, downloaded, installed and returned-online states separately. Read the installed version back from the cabinet, then verify kiosk startup, controller readiness, catalog, device identity and transaction/report recovery.
- Stop an expansion when a new fault appears. Prefer an approved correction with a higher versionCode. Android may reject a downgrade or different signing certificate; pointing a rollout at an older APK does not establish rollback.
Do not routinely uninstall, clear storage or factory-reset to resolve an update error. These actions can remove device credentials, local configuration and pending transaction evidence. A signature migration or exceptional reinstall needs a machine-specific recovery plan from the release owner. Device-owner enrollment also has prerequisites; it is not a generic repair command for an already provisioned cabinet.
See APK rollout procedures for the release operator and ZHZN fleet recovery and acceptance for staged validation.
Screenshots and remote support
Open the supported Remote screen workflow for the assigned machine in Operator or the web console. Verify capture time, current readiness and the scope of the image before interacting. Historical images are evidence of an earlier state, not safe targets for new taps. Control availability depends on the installed phone, backend, cabinet agent and permissions.
| Cabinet | What remote access can establish | Remaining requirement |
|---|---|---|
| ZHZN KioskX | Native capture/control concerns its own application window | It does not provide general Android Settings/other-app access. Verify the remote-screen feature, fresh capture, input result and installed release; older capture paths may omit video surfaces |
| Reyeah JD | The stock vending app has no bundled gotoagent support; an optional separate screen companion can provide a support surface |
Before first launch, provision the exact companion role, matching companionMachineNo, validated privileged/root firmware and the approved credential mode. Prefer machine-scoped credentials. Leave dispensing with the Reyeah app |
| VC EL / unidentified installation | An existing authorized vendor connection or attended AnyDesk session may provide diagnostics | Confirm the installed app and actual control scope first. Preserve the vending APK; full Android control and unattended recovery are unverified |
Reyeah companion credential provisioning is a release prerequisite. The prepared new client reads a private companion-credentials.json file with a machine-scoped deviceKey, optional initial witness, or an explicitly authorized compatibility reyeahSecret. It has no automatic ZHZN fleet-secret fallback; without credentials it makes no HTTP request. Compatibility mode is not machine-scoped identity. A returned x-device-witness is retained in checked private storage for subsequent calls with the same device key; replacing the key ignores the old saved witness. This witness maintenance does not enroll or rotate the device key. Follow the provisioning/readiness contract for the matching approved releases. Do not assume an older companion authenticates or that a serial is a credential. Rooting a cabinet is not routine maintenance.
For native controls, require fresh readiness and a current image. The new companion reports device scope only with a valid root capture from the preceding 30 seconds; native ZHZN reports app scope. New inputs have a 15-second execution deadline and duplicate suppression. Stale, expired or unready input must be refused. A queued request or submitted input is not proof of a completed business action.
After each input, further control stays blocked until its matching successful acknowledgement and the exact fresh, decoded follow-up screenshot named by lastResult.captureId arrive. An unrelated live image is insufficient. A failed result stops Control even when a diagnostic frame arrives. An uncertain result needs explicit inspection and reconciliation before resuming; do not repeat the tap merely because a request timed out. Follow the after-input inspection procedure. Verify these safeguards on the installed release combination before accepting remote control.
For Android-wide help, use the Android cabinet remote-access and handoff guide. It covers AnyDesk/control plugins, TeamViewer/OEM alternatives, company access restrictions, two-factor authentication and unique credentials in the approved vault. Initial permission approval and new screen-capture sessions can require a person onsite. Qualify reconnect and reboot on the exact cabinet before marking it unattended.
Recover from a fault without losing evidence
| Symptom | Next action |
|---|---|
| Offline or old health timestamp | Check the actual network, captive portal, clock and agent status; retain local configuration and queued reports |
| Enrollment denied, unprovisioned or credential rejected | Record the exact identity state, installed package/version and machine number; follow the current enrollment/recovery procedure with the credential owner. Do not reuse a historical shared-secret fix |
| APK signature/ABI/version error | Record the Android error and installed identity; obtain the compatible approved artifact or a planned migration |
| Screenshot unavailable, old or view-only | Check current agent readiness, feature setting, permissions and capture scope; use attended support if needed. Do not infer that a missing image means the vending app must be replaced |
| Tap failed or timed out | Stop Control. Inspect the matching result and follow-up frame; if the result is uncertain, inspect fresh state and reconcile the original action before explicitly resuming. Do not automatically retry or treat transport acceptance as completed input |
| Paid order with uncertain delivery | Retain the original order/payment references, check the physical pickup area and reconcile with the provider. Do not repeat the vend or claim a queued refund has settled |
| Flicker, repeated app restart or full reboot | Record when it happens, observe the physical panel and compare a contemporaneous remote image where available; follow VC EL diagnosis or the identified manufacturer's procedure |
Use ZHZN installation/enrollment recovery, ZHZN failure and recovery acceptance, Reyeah fault/payment recovery and Nayax reconciliation for the matching case. Linux boot-guard recovery applies only to the separately provisioned Linux agent.
Handover and return to service
Record the cabinet serial, software machine number, controller/ROM, installed APK and Operator releases, support service/ID, vault record reference, symptoms, changes and outcomes. Include the onsite contact and any unresolved item with its owner. Keep credential values out of the record.
Mark screen/touch, kiosk startup, cloud identity, stock/prices, controller readiness, remote reconnect/reboot and any required supervised sale/refund checks pass / fail / not tested. Remote visibility does not certify physical delivery, settlement or repaired hardware. Do not mark an untested cabinet fully operational.