HSBNE's Drinks Machines and Spacebucks

By now, some of you might’ve noticed that our drinks machines are sporting an RFID plate and screen much like this:

This is a culmination of a bunch of effort by various people including myself, @Thermoelectric @buzz and a few others and this system is now live and you can add credit to it at http://porthack.hsbne.org/members/addbucks for either yourself or another member.

Buut how did we get where we are now with this? This post will hopefully serve as a bit of history on it.

The beginning
One night over dinner, shortly before we moved to the Port Hack campus we had one of those ‘what if’ sessions and one of the ideas that came up was a credit system on member’s cards that could be used for vending machines and consumables.

I took it on board and with the help of @Thermoelectric we figured out that the vending machines were very simple, with the coin mechanism latching a relay that enable the dispensing circuit.

Eventually the Digistump Oak boards came out and I got one working with an i2C LCD Screen.

Emboldened by this, I popped out a panel on the drinks machine and made up a replacement on the laser cutter to hold the screen, like so.

The project stalled for a few months while I had issues with Particle’s download OTA setup, so I designed PCBs with the hopes of getting the software working after hardware.

This was the first version, using EasyEda to design it and then Digispark’s pcbs.io service to produce them.

It was really cool, but it had one fatal flaw… there was a connection where there shouldn’t been and this caused a ground loop.

So I redesigned it and came back to it once the boards arrived…


One thing I notice, some members are doubled up…

@sjpiper145 is a nice person and all… but if we wanted to buy her a drink which one do we use?

That’d be because some helpful person has added duplicate card entries. I’ll figure out which is correct on the backend.

Heh, someone forgot ALTER TABLE members ADD CONSTRAINT c_unique_name UNIQUE (name); in their database schema. (That’s PostgreSQL/MySQL syntax, not sure what database is in use.)

No worries. There’s a couple in there… might want to hide others like Sec and the Men’s Shed. Unless there’s some sort of email triggered for when someone tops up a card, they would possibly never know.

That said, the fact that someone can top up another member’s card is good, as it means you’ve got a way of returning a gesture for a favour done.

1 Like

This is all fixed now. I’ll be doing a post detailing the rest of the hardware and software development soon.


Quick update: Last night we had someone with a balance on their RFID tag who could ‘swipe’ on the drinks machine, but was unable to complete a purchase. The backend database that manages this system does a few checks prior to allowing a sale of a drink, and this particular person had let their membership expire, so their RFID tag balance didn’t let them ‘spend’. We also have checks to make sure your profile has an email address properly attached to it ( or the backend wouldn’t know where to send hte email to), and other less important measures. Anyway I’m not sure if we want this must-be-current-member limit in the system long-term ( as I can see drinks as a perfectly good thing to ‘spend’ on, even if you are overdue ), but it’s there right now, so if you have any issues when you first use the system, please do let Nog and/or I know, as one of us can certainly fix your problem easily. :slight_smile:

1 Like