Silkron / Vendron operation and integration prerequisites
Status: integration not implemented or hardware-certified in this work. The photographed VC EL cabinet is not yet confirmed to run Vendron. Start with cabinet identification and flicker diagnosis.
Confirm the installation
Record cabinet manufacturer/model separately from Vendron version/edition, host OS, device/controller type and API activation. Obtain a supported vendor inventory/export or About/license view. A generic Android box, reseller label or touchscreen layout cannot confirm Vendron.
Silkron's public documentation describes Socket API for local Windows plugins and Cloud API for REST/mobile access. The editions page marks activation/subscription conditions. Obtain the actual licensed contract; these pages are not SDK specifications. API overview, editions.
What the final Operator workflow must provide
- An administrator links the vendor account to the correct Kiosk-X tenant using server-managed credentials.
- The operator selects an imported, positively identified machine and confirms its native machine ID and location. Do not register it under
reyeahmerely to make it appear online. - The adapter imports supported products, lane mappings, current prices, inventory, machine status and fault states, with timestamps indicating freshness.
- Operator edits supported properties; the integration shows whether the machine applied them, is awaiting delivery, or refused the change. Unsupported features are unavailable rather than simulated.
- Supervised service/purchase workflows persist correlation before dispatch and reconcile physical delivery, stock and payment state. An API acceptance is not a completed sale.
- Alerts, service records, reports and recovery remain scoped to the owning account. Operators follow the actual failure state rather than retrying an ambiguous physical command.
These are acceptance requirements, not available Silkron screens or endpoints in the current Operator app.
Engineering inputs required
Obtain versioned request/event schemas, authentication and credential rotation, machine/product/lane mapping rules, supported cloud writes, callback verification, order lookup and delivery evidence, retry/deduplication guarantees, timeouts and terminal states, refund/payment responsibility, rate limits, licensing and a test machine. For Socket API also obtain Windows runtime/transport requirements and plugin lifecycle documentation.
A Windows companion would translate the documented local API to Kiosk-X. A Cloud API adapter would run on the backend. Keep vendor credentials off the operator phone. Do not invent ports, opcodes, payloads or successful results before the SDK exists.
Commission and operate
Until that adapter passes tests, maintain the native Vendron installation and use the vendor's existing supported operation tools. Preserve its license/configuration and rollback package before any migration. Do not overwrite it with the Reyeah/ZHZN cabinet app.
For each supported configuration, complete the common hardware signoff, including inventory readback, payment approval, actual delivery, failure/refund, duplicate/late callback handling, disconnect and restart. Test partial carts separately where supported. Record the exact vendor firmware, backend revision and operator APK digest.
Silkron's retrofit page is a solution description; it does not certify every make/model. Its Cube solution involves physical interface hardware. The installed board, wiring and mechanisms must be identified and accepted for every retrofit profile. Retrofit, Cube.
Requested feature coverage
The table separates related Kiosk-X functionality from demonstrated equivalence. It covers the feature families requested using Silkron's edition comparison; it does not assign a Silkron edition entitlement or certify interoperability. Related source code is not evidence of a working vendor integration.
| Requested capability | Kiosk-X status and remaining check |
|---|---|
| Support, diagnostics and maintenance | Operator has machine health, faults and support workflows. Screenshot, logs and remote access depend on agent/version permissions; validate on the actual cabinet. |
| Products, planograms, kitting, routes and warehouse | Relevant management workflows exist. Verify stock conservation, price/currency readback, route allocation and physical refill. Consult the current phone feature matrix for screens absent from a signed release. |
| Alerts and sales reports | Relevant screens and APIs exist. Verify event freshness, refund treatment, tenant scope and reconciliation to actual payments. |
| Storefront, images, carts and mobile purchase | Cabinet and web shopper flows exist. Verify selection, multiple-item/partial delivery and totals on each controller. |
| Cash/cashless peripherals | Controller/reader-specific implementation. MDB support alone does not qualify every coin unit, recycler, dispenser or cashless reader. |
| Signage and scheduling | Advertising and media controls exist. Offline playback, scheduling, proof of play and content recovery need cabinet acceptance. |
| Multi-controller topology, I/O and access control | Individual telemetry/configuration fields exist; general master/slave and all sensor/door workflows are not established. |
| Product properties, expiry, bundles and timed prices | Related inventory/pricing code exists; each requested behavior needs its own acceptance test. |
| Layout plugins, languages, help and browsing | Existing storefront/localization/support code does not establish a Vendron-compatible plugin or browser environment. |
| Receipts, tax, promotions, membership and controlled dispensing | Some related payment, order and redemption workflows exist. Verify printer hardware, identity entitlements, tax calculations and one-time redemption separately. |
| Newsletter and proximity sensing | No equivalent end-to-end implementation was established. |
| Surveillance and live assistance | Camera/support code exists, but recording, retention and live-support parity were not established. |
| Recommendations and demographic/audience analysis | No equivalent camera-based analytics pipeline was established. |
| Surveys, games and photo sharing | Related experiences exist; verify shopper access and physical cabinet behavior separately. An operator tray survey is not a shopper questionnaire. |
| Socket and cloud integration | Blocked on the real vendor contract, licensing, implementation and test access. Do not expose a simulated adapter as operational. |
For every accepted feature, retain the test case, expected and observed result, timestamp, device/profile identifier and software revision. Features awaiting implementation or hardware evidence must remain visibly unavailable or unverified in the support record.