Difference between revisions of "Vending Machine/Cashless Device Implementation"
m (Danspencer101 moved page Vending Machine/Cashless Device Implementation to Project:Vending Machine/Cashless Device Implementation)
|(One intermediate revision by one other user not shown)|
|Line 90:||Line 90:|
Latest revision as of 16:20, 24 February 2019
We now have two versions of the custom cashless device:
- v1 - created for the Westomatic vending machine, and uses a nanode and RDM880 based RFID module, and is build mostly on perf board.
- v2 - created for the BevMax45 vending machine, and is heavily based on v1, but now uses a custom PCB with a SAM D21 MCU (same as the Arduino Zero), a WizNet Ethernet shield and a MFRC522 RFID reader. There is an aim to update the first vending machine to use a v2 cashless device, but as of Dec 2018, this hasn't been done yet.
There is a board between the Nanode (see Media:VMC-Nanode Schematic.png) and the vending machine which both powers the nanode from the ~34vdc supply, and allows serial communication with the VMC.
The nanode is connected (using software serial) to an RFID reader mounted under the 'H' logo on the outside of the Vending machine. There is also a micro-switch attached to the coin-reject mechanism (to allow any RFID card read to be cleared from memory), and a blue LED above the reader to indicate when a card has been read & recognised. An LCD to show your username & current balance was added in July 2013.
Firmware for this device is in GitHub.
The second cashless device uses a cutom PCB using the SAM D21 MCU (as used in the Arduino Zero), and has numerous changes, including:
- A MFRC522 RFID module, which is the same as the NoteAcceptor, tools boards, etc., instead of a RDM880 based module
- Uses TCP/IP to connect to a Mosquitto MQTT broker on holly instead of UDP/IP. The messages sent remain the same.
- A serial based setup menu, to allow for entry of device name, IP, etc. This should allow the same firmware to be used unmodified in both machines.
Firmware for this version is also in GitHub.
To keep things simple, the interface to holly is text based; the sequence of messages is shown in the flowchart below:
For v1, these messages are sent using UDP/IP, for v2 they use MQTT, transmitting on the
nh/<device_id>/tx topic and receiving on the
nh/<device_id>/rx topic. Not an ideal implementation for MQTT by a long way, but reuses a message flow that's been working well for some years.
Sent when RFID card first read
Sent in response to AUTH if the card is known & marked as active in the database.
Sent in reply to AUTH if the card is either not know, or marked as expired/canceled.
Sent when a selection is keyed in. <amount> is in pence.
Sent in response to VREQ if the purchase is permitted (e.g. credit limit won't be exceeded).
Sent in response to VREQ is the vend should be denied for any reason.
Sent after the VMC reports to the nanode that the product has been successfully vended.
Sent if the VMC reports that the vend failed. ***UNTESTED*** for the Westomatic machine, as we don't beleive the machine can/would ever report a failed vend. The BevMax45 can report failed vends (if enabled on the machine), but due to a fault with the drop sensors, it was reporting every vend as failed, so this has been switched off.
Sent if the coin reject button is pressed. Will record a cancelled vend if an AUTH has been sent, but no VREQ yet received - otherwise it has no effect.
Information message that can be sent at any stage - has no effect other than being written to a log on holly.
|<RFID serial>||RFID serial number - expected to be 9 digits long|
|<transaction number>||Unique number assigned to the vending machine transaction when an |
|<position>||Position in the vending machine as reported by the VMC. Note that this location is mapped to the locations codes displayed in the vending by holly (e.g. 41-31 reported here corresponds to location A1).|
The code of the server side component is on Github (the relevant part is nh-vend.cpp). This code is common to both v1 & v2 of the cashless device, and also handles payments received via the NoteAcceptor & CoinAcceptor.