In many open spaces or coworking spaces we see phone booth emerging. They are quite nice as they provide an ideal space to think and have a chat with someone. In my company, we use phone booth for interviews, to have a quick visio chat with a remote employee, or often to avoid the ambient noise.
Sadly, the number of phone booths is quite limited and we often struggle to find some when needed. As most of the office management software don't support those little space, we cannot book them either.
The Use casesI'd like to build a device that allow employees to book phone booth and to avoid overbooking, I would like to provide employees with limited credits every week they will use to book the phone booths.
Another interesting use case is for coworking space to provide phone booths as a service.
ArchitectureThe system is composed of three components:
- the Tangle network where transactions lives
- a broker between the Tangle network and the device
- the device located on the phone booth itself that allow user to see if a phone booth is book and when it will be free
PrototypeThe Device
The device will display some informations on a display:
- the address where to send tokens as a QR code
- the occupancy status and the next time the phone booth will be free
- the name of the phone booth
All of those informations will be provided by a MQTT broker. This will again simplify the setup and the maintenance.
I chose an e-ink display because I ultimately plan to power the device using batteries to simplify the setup.
Ideally, the device should be fixed to the phone booth door. Lacking time to build a nicer version of the prototype, it will simply rest on the workbench for now.
The user will scan the QR code and decide how much he wants to pay to book the phone booth.
The Broker
The broker will frequently fetch new transactions from the Tangle, send updates via MQTT to the device, and update the booth calendar according to the transactions. The transaction message will serve as the public meeting name. We can imagine having a more complex message but it would require a dedicated application to send transactions and using Trinity to send tokens is simpler for now.
Right now, the broker is the combination of a MQTT queue and a Go server. I didn't embed the broker code inside the device to ease maintenance when we will want to support many devices. Having somewhat dumb devices allow easier updates to the system.
What's next?With this prototype I learned how to create an IOTA-enabled device and how to build complex workflow with this interesting technology.
Here are some actions I have in mind for the next prototype:
- Insert a proximity sensor and create an interactive map of the phone booth on a building. It could support a find a free phone booth near me kind of scenario. I would use the messaging support of Tangle to support this feature.
- Cleanup the code and create a proper broker that manages a fleet of phone booths.
- I need to think about refunds and cancellation. What do I do when an user send more than what's required? I would probably need my own application to send tokens.
- We need to be in a front of a phone booth to book it. We could do this online using the interactive map mentioned earlier.
- The planning algorithm should be enhanced with valid periods and time slot constraints.
- Build a case and fix the prototype to a phone booth and have users test the prototype.
In the future, we can imagine integrating the device in a more complex workflow where it could pay for the location to the building, and the electricity and Internet to the corresponding providers.
Comments