Mate Dealer 3.0

by Bouni - 2019-10-24

The background

It all started with MateDealer 1.0 with all its original electronics extended by an MDB implementation. The controller died for some unknown reason and the MateDealer sat there in an pitiful state for a quite long time.

Then we decided to build our own new controller board based on an Arduino Mega2560 and an Alix 3d3. MateDealer 2.0 was born. This itteration never took of as we had problems getting the communication between the Arduino and the PC working flawlessly.

Again the MateDealer was out of order for a couple of years, until we decided to take a third attempt to get it up and running. Here’s what we came up with!

MateDealer 3.0

Features

• Based on a RaspberryPi 3B+
• Custom Hat designed to fit our machine (might work for yours as well)
• 24VAC powered
• Bridge rectifier for ~22VDC
• DC-DC StepDown converter for 5VDC
• NFC Reader for authentication
• Control for 5 slot motors via relays
• TR5 fuses to protect the moters in case of a jam
• Control for the cooler via another relay
• 5 inputs for motor home position switches
• 5 inputs for slot empty switches
• 5 inputs for product selection buttons
• LED’s for every output and input
• 1-Wire port for temperature measurement
• I2C port for later addons

Pictures

The HAT in all its beauty

The HAT stacked on top of the RaspberryPi and mounted to the inside of the machine using M2.5x12mm distance bolts

The wiring of the product selection buttons

The wiring of the motors, the home postion switches and the slot empty switches

A close up of the motor wiring

The 1-wire temperature sensor

The external relay that switches the cooler

The procedure of getting a cool drink

1. The person approaches the machine and swipes a NFC Tag
2. The reader beeps, signaling the person that its ready
3. The person selects a drink via one of the 5 buttons at the front
4. The machine dispenses the selected bottle from the slot
5. The machine writes user_id, timestamp and product_id to a influx db that runs on actse¹
6. Happy person consumes the drink

The payment

Once every month a script runs on actse calculating the amount a person has to pay depending on the number of consumed drinks an the costs. That makes it easy for us to get the money and does not need to handle payments on every vend.

What works so far

We are in a beta phase at the moment.

NFC authentication

We finally managed to integrate a ACR-122U USB NFC Reader with the MateDealer that allows us to authenticate a user. We know for sure that using the UID of a NFC badge isn’t very secure but thats not the point for us.

Cooler

The cooler is controlled depending on the temperature inside of the machine with a hysteresis that is configurable. That allows us to only coll down when its neccessary. The cooler is blocked when nobody is in the hackerspace to save energy or it is not Tuesday between 18:00 and 23:00 which is our main opening hours.

Display

We ordered a 8" HDMI display on AliExpress that will replace the product lables next to the selection buttons. That way we can shwo dynamic product labels an when a vend is ongoing or another information needs to be shown to the users it can be done that way.

Accounting

We decided to send a measurement to a InfluxDB on every vend that includes username, product, price and a timestamp. At the end of the month, we can simply run a (yet to be written) script that fetchs all vend of the past month and sums up the consumption per user. Our treasurer then can request the amount from the user. We plan to have users to top up a virtual account and the the treasurer wil subtract the amount from the available funds. That way he does not have to run after people an make them pay afterwards. We will see how that works out.

Logging

We send several values to the InfluxDB to have a log of what is going on, at the moment these are:

• Inside temperature
• Cooler state (on/off)
• Slot states (ok/empty)

Integration

Our pwrCMDer runs Home-Assistant, from there we’ve integrated several InfluxDB values as sensors. That allows us to let the pwrCMDer react to state changes. We plan to let it send a information message when a slot runs empty for example (yet to be done) or having the states in our SpaceAPI (already done)

Fails

• I didn’t know how much current the motors draw, so I guessed 1A and ordered TR5 fuses with 1A. Turns out the are labled with 5.2A and actually draw 4.9A which on the first try blew all 5 fuses imedialtely.
• I used relays that are rated for 3A because I guessed the actual motor current (and I had dozens of them laying around). I decided to use them directly until they start to fail. If that happens I replace them and use additional relays that are controlled by the small ones.
• I accidentally placed a via that stitches 24VAC to GND which results in a short circuit when one of the relays is switched on. This issue could be easily fixed with a sharp cutter knife.