FAQ & Knowledge Base

No. Our unit (PVEZBRIDGESLAVEv3) runs slave-only firmware. The MASTER connector is physically present but electrically inert on this build, there is no runtime mode switch, and the serial protocol exposes no firmware-update command (FIRMWARE?/MODE?/BOOTLOADER? all return UNKNCMD).

If you need a VMC/master you need the separate GalaxyVend MDB MASTER board (a different SKU — its manual is in Supported Controllers), or ask the vendor about a reflash.

It has no USB power-in — USB-B is data only. Installed in a machine it draws power from the MDB bus via the SLAVE connector.

For bench use, the J8 POWER 2-pin accepts 9–32 VDC (polarity-insensitive) or 7–24 VAC per the GalaxyVend MDB SLAVE v1 manual. A 24 V DC supply works (a 24 V VoIP-phone PSU is fine). The Pi still needs its own PSU — the Picovend does not power it.

The Picovend/GalaxyVend slave firmware (v5.13) takes every numeric config argument as DECIMAL. A "0x.." prefix parses to 0.

So CSLSOPTIONS(0x0A) stores 0, CSLSEXPBITS(0x20) stores 0. Use decimals: CSLSOPTIONS(10) (b1 multivend + b3 cash-sale), CSLSEXPBITS(32) (always-idle on). EUR is CSLSCOUNTRY(2424) — the board then echoes it back as hex "978". Our agent (1.54.5+) does this correctly; older builds had the hex bug.

The device auto-denies a VNDREQ if it doesn't get a VNDAPP/VNDDEN before its approval timeout — or if there's no open session and no fake-credit approval path.

Fixes: send VNDAPP(amount, timeout) within ~1 second of VNDREQ; or run the device in always-idle mode (CSLSEXPBITS(32)) with CSLSFAKECREDIT(65535) so it approves against fake credit automatically. On a real Level-1 machine (e.g. Palma H) you must BEGIN a session before selection.

Yes. A Pi can host multiple controllers (qibixx on /dev/ttyAMA0, Picovend on /dev/ttyUSB0). The agent reports each one it finds on its heartbeat and the cloud auto-registers one Controller per (Pi, serial port) — the Picovend appears on the Controllers page by itself, same as the qibixx.

A controller attaches to a vending machine (not to the Pi) — the Pi is just compute, reached through the controller.

On the PCB002Q v1.2 the two white MDB connectors are bridged by the factory X2 / C_S jumpers, so electrically it doesn't matter which one you plug into. Leave those jumpers as shipped.

Master vs. slave is software (C,* commands = slave, D,* = master), not the connector. In normal operation the qibixx is a cashless slave and the machine is the VMC.

Capability tiers negotiated between the machine (VMC) and the cashless device during SETUP:

Level 1 — basic cashless. The VMC sends VEND REQUEST directly; no session, no display. The Azkoyen Palma H is Level 1. Level 2 — adds display messages and cash-sale reporting. Level 3 — adds Always-Idle (product selection first, no button press), revalue, and expansion identification.

There is no "Level 4/5" for cashless — higher numbers refer to coin/bill peripheral features.

Level 3 + Always-Idle: the customer selects a product first; the cashless device approves against credit. No BEGIN needed.

Level 2, or Level 3 without Always-Idle: a session must be opened (BEGIN, or the physical START button) before the customer can select. The Palma H (Level 1) behaves like the session-first case — the VMC opens it.

MDB is a ~34 V DC bus (spec range roughly 18–42 V), sourced by the VMC (the vending machine). Peripherals draw tens of mA each; the whole peripheral side is spec'd to ~1.5 A. You never inject bus power when a real machine is the VMC — it supplies it.

Yes — add a Virtual Machine from the Vending Machines page. It creates a full simulated Pi → Controller → Machine chain; the cloud stands in for the agent (heartbeats, command results, a simulated vend flow that writes real transactions and decrements stock). Good for previewing the dashboard and operator flow.

Yes, if you have a qibixx hat and a cashless slave (e.g. a Picovend). Wire the qibixx MDB connector to the slave, power the slave, and use the VMC Simulator on the Controller → Diagnostics tab. It drives the qibixx as a VMC at MDB Level 1/2/3, fires a simulated customer vend, and reports the transcript.

The bench harness (tools/mdb_bench/ in the repo) is reusable and works in either rig orientation.

Raspberry Pis → Onboard Pi generates a one-time provision token and an install one-liner. SSH into the Pi and run it — the script sets up the UART, installs the agent, registers the Pi to your account, and enables the systemd service. The Pi appears on the Raspberry Pis page once it heartbeats.

The agent checks its version on each heartbeat. If the cloud reports a newer one and OTA is enabled (OTA_ENABLED=1 in the Pi's env), it downloads the new agent.py and restarts itself. The target version is pinned by the platform.

Each machine has a Payment scenario (set on the Add-machine form and on the machine's Payments tab):

• Card only — our controller is the payment device on the bus. Every selection is a card charge through the configured provider, then we approve the vend. • Coin only — a coin mechanism on the machine handles the money. Our controller listens on the bus and records each cash sale. Set the controller's mode to Sniffer on the Controller screen. • Coin + card — both. Card selections charge our provider; coin selections are handled by the coin mech and recorded from the bus. Keep the controller as cashless slave/master. • No payments — vend requests are cancelled (display-only / free machine).

Yes, if you turn it on. On the printer's row in // printers there are two toggles: "auto-print card sales" and "auto-print coin sales". A coin sale writes a Transaction and runs the same invoicing + receipt pipeline as a card sale — the toggles only control whether paper comes out. The receipt line shows ΤΡΟΠΟΣ ΠΛΗΡΩΜΗΣ: ΜΕΤΡΗΤΑ for cash.

It is provider-agnostic. When the machine requests a cashless payment for a selection (e.g. the customer presses AB), the Pi takes the price for that slot and starts a sale on the machine's configured payment provider's terminal. The customer completes the transaction on the terminal; on approval the Pi approves the vend and the product dispenses.

Pick the provider per machine on its Payments tab. Provider API keys are entered once, org-wide, in Settings → Payment provider credentials.

Supported today: None, Mock (auto-approve, for testing), and SumUp (Solo / card terminal). Planned (listed in the UI but not yet selectable): Viva.com Cloud Terminal, Nayax.

Yes. Set an invoicing provider in Settings → Invoicing. Supported today:

• accgr.com (Greek myDATA) — issues a retail receipt for goods (απόδειξη λιανικής, inv_type 11.x) after every vend and returns the MARK plus an AADE QR verification URL. Runs in the cloud, so the API key never touches the Pi. • Mock (no provider) — builds a receipt from just the item name and amount, no external service and no account. The printout is stamped "ΔΕΝ ΕΙΝΑΙ ΝΟΜΙΜΗ ΑΠΟΔΕΙΞΗ". Use it to test the print path and preview the layout.

Issued receipts show on each machine's Receipts tab with their MARK / reference and QR link.

Manage receipt printers on the // printers tab. Add a printer, pick its type, and assign it to one machine (one printer per machine). Supported types: ESC/POS thermal over USB, ESC/POS thermal over network (raw TCP 9100), and Star CloudPRNT.

The network option works with any Ethernet ESC/POS receipt printer — Neural Gear NG 2201 / 2202, Epson TM-T, most generic 80 mm printers. Just enter the printer's IP; port defaults to 9100. The Pi opens a socket and sends raw ESC/POS.

Star CloudPRNT is pull-based: the printer polls a cloud URL shown on the printer's row, so it works from behind NAT with no port-forwarding and no agent involvement.

Each printer has "auto-print card sales" / "auto-print coin sales" toggles and a TEST PRINT button (works before it's assigned to a machine — pick which Pi sends it). The machine's Payments tab shows the assigned printer read-only.

Yes. Default character set is CP737 (Greek) — bench-verified on the Neural Gear NG 2202, which prints Ελληνικά natively (ΣΥΝΟΛΟ, ΑΠΟΔΕΙΞΗ, Ευχαριστούμε) and renders a real scannable QR code from the myDATA verification URL via ESC/POS GS ( k.

If you pick the model from the dropdown (NG 2201 / 2202 / 2200 / 80 / 58, or Epson TM-T88), the character set, paper width and QR are pre-filled. For an unknown printer that garbles Greek, options in order: PC928, Windows CP1253, or Greeklish (transliterates Greek → Latin, works on literally any ESC/POS printer). Turn the QR off to print the verification URL as plain text instead.