Releases: Liongrass/bepsi
v4.1
v4.0
This is expected to be the final major release of this code base.
In this version, the code is further split out, with all of the button logic now sitting in a separate buttonL.js file. This hopefully makes the code more readable and accessible for anyone looking to work on top of it.
The "Available Trays" logic introduced in the previous version proved to be insufficient in getting an accurate reading of the button presses. As a consequence the function is only called on startup, and the logic that makes the machine cold no longer depends on it. As a precaution, the machine is made cold whenever a button press is detected, regardless of what the state of the machine is.
The machine now allows the ping interval to be configurable. Whether the mechanism is sufficient at preventing a stale websockets connection remains uncertain.
Finally, the machine now contains a simple configuration mechanism that lets the user switch between "production" and "testing" stage, the difference being solely the inverted pins.
Going forward, we are moving to a python code base hosted in the 21UP repository. This allows us to work with e-ink displays, which seem most suitable for a vending machine. Displays also allow us to move to bolt11 invoices over LNURLs, which maximizes interoperability among Lightning wallets, and minimizes the risk of issues with the websockets.
v3.0
While this release introduces a lot of code changes, the machine functions exactly as it was before.
Following the separation of the button logic from the websockets logic, this releases introduces the concept of "available trays". The issue we ran into with v2.0 was that when a single button was pressed, multiple button presses were detected, and often in the wrong order. Now, upon startup, the machine checks which trays are available and which are not. Whenever the machine becomes hot and a button press is detected, the machine checks whether it should ignore the button press or not. This does not always work, still.
The machine now also regularly pings the websockets peer, to make sure the connection is live. We hope the machine now no longer loses its connection with the websockets, avoiding frustration and necessary restarts.
v2.0
In this release, the button logic is made independent of the websockets logic, which solves the problem of the button logic being replicated in the background whenever a new payment is coming in.
This will simplify further development that depends on the buttons, as well as make the logs more readable. This also moves the logic of what pin is triggered by a payment from the LNbits server to the machine, although it will still also have to be specified on the server.
Furthermore, the logic that makes the machine "hot" or "cold" is separated out into separate functions.
To the user, the machine functions as it was in version 1.0, although hopefully more reliably.
v1.0
This is the first major release of the 21UP. The 21UP now acts as a full-functioning vending machine. You pay once and can expect exactly one pop. There no longer is a time limit to how quickly you have to press a button, meaning it's now also possible to "pay it forward," although the machine still lacks a mechanism to indicate whether it is currently "hot" or "not."
There is an LNURL-pay QR code displayed on the front of the machine. The raspberry pi listens to the LNbits websockets for incoming payments.
As a user scans and pays the QR code, the machine becomes "hot," meaning it is ready to dispense pops. The machine will then listen on six separate pins, one for each button. The buttons are wired into an Optocoupler, which does not interrupt the flow of electricity to the motors, but feeds off them to give a 3.3V signal to the Raspberry Pi.
This allows the Raspberry Pi to detect when a button is pressed. The machine dispenses the pop, and the relay is closed to prevent further button presses. The machine logs which button was pressed and what item the tray belongs to.
Each tray contains a sensor that is triggered when the machine is running low on pop. The machine can show this information by turning on a little red light behind the pop labels on the front of the machine. When the light is on the machine also refuses to release the pop. In this iteration, this sensor is wired to also trigger the Pi at the same pin as the button, which prevents the Pi from picking up a pressed button when the tray is running low.
In effect, when a tray is running low, a button press no longer triggers the release of a pop, and also no longer closes the relay. Instead, the user can make a second choice.
Regardless of whether the tray is low or not, the red light will also flash when the user presses a button after a payment was made.
The entire logic lies in three different parts of the machine:
- The Machine itself carries the logic for how to dispense a pop, and which tray to dispense.
- The Raspberry Pi carries the bulk of the logic, mainly detecting incoming payments and which button is pressed. It uses that information to "open" and "close" the relay, which allows the buttons to be pressed. It currently uses a fork of the DCTRL Bepsi code, written in NodeJS.
- The LNbits backend (v1.2.1) is used to generate the LNURLp code printed on the front of the machine. Using the bitcoinswitch extension (v1.0.1), we define the price and the outgoing pin that is triggered when a payment comes in.
In future iterations, we expect more logic to move to the Raspberry Pi, such as which tray to dispense or which price to set.
Current issues and limitations:
- The code needs improvements around the button listener logic.
- The machine only allows for uniform pricing, as it would have when it was running fifty years ago.
- There is no indication that an invoice was paid and that the machine is ready to dispense
0.1
This release was deployed at the 21UP on August 11.
There is a static QR code displayed at the machine, all drinks have the same price.
The user can pay the QR code and then has ten seconds to press any of the six buttons on the 21UP.
A drink will be dispensed.