Iobroker quest for quests in reality games

Hello everyone, there are already several articles on Habré about automation of games like "quests in reality" ( one , two , three , four , five ...), I would also like to share my experience of participating in such a project. Back in 2015, my friends decided to organize an escape-room quest “Bank Robbery” in our city. They knew that I had been fond of various automation for a long time, including systems such as "smart home" based on open source solutions, so they asked for help in organizing the game. This idea seemed interesting to me and I agreed - I wanted to apply my experience and solutions for something more interesting than blinking a light bulb in my apartment.

I tried to take part in the full cycle of the project - from making changes to the script to the next run-in tasks, identifying and fixing bugs, subsequent improvements. I visited several games in our city (in 2015 they could be counted on the fingers of one hand), not for the fan, but rather for gaining experience and reverse-engineering solutions, and this was clearly visible by the reaction of the organizers. But after participating in the game in Moscow, I understood the real scale of the “disaster” and I really wanted to do my job no worse than the technical side. So, the quest “Rob the Bank” in Tver, for details of how it was created and developed over the course of several years, I ask for cat.

Description of technical solutions

After my colleagues explained to me on the fingers what they want from me and how everything should work, in my head literally in a couple of minutes an architecture took shape: a central server with ioBroker platform , local controllers based on Arduino boards and modules, data exchange with server and between controllers using the MQTT protocol. As a result, the architecture turned out to be approximately as follows:


In addition to the interaction of the task controller with the central server, it was necessary to establish interaction between the controllers of different quest tasks. For this, in my opinion, the MQTT protocol with a broker on a central server was ideally suited. Clients - controllers publish their states to the server, subscribe to commands from the server and the states of other controllers. To implement this solution, the MQTT adapter was used - it was also an MQTT broker and allowed you to create a hierarchy of topics in the ioBroker object tree to use the data for visualization and management (a screenshot below the old version of the “admin panel”).


Subsequently, I did not regret that I chose just such a solution:

1. MQTT is a lightweight protocol, the library took up little space and was more than enough even for the Arduino UNO with the ATmega328 chip
2. When rebooting or turning on the controllers for the first time, they received the initial conditions for starting work using MQTT - it’s very convenient
3. This solution turned out to be the most reliable of those tested and quite simple for a beginner to implement and study

Only a few options are obtained by data streams, the simplest of them - an event occurs in task controller No. 1 (a button is pressed), it publishes the button state in a certain topic and its status is displayed by changing the color of a graphic element on the operator’s visual form.


An equally simple and opposite option is that you need to manually turn on the relay through task controller No. 1, a control event is supplied through the VIS adapter, which changes the state of the topic of this controller, and with ask = false. The MQTT adapter receives a topic change with ask = false, so this topic did not arrive from the controller, respectively, the change is published to the controller, which in turn publishes a confirmation with ask = true in response.


Intercontroller exchange occurs on an event on one of the controllers. For example, the first controller has fulfilled its task and must turn on the relay on the second controller - it publishes its status in the general topic, the broker displays it in the tree and on the visualization page, since the second controller is subscribed to this topic, the broker publishes it to the second controller and the latter in turn publishes a confirmation response.


The project still had to add the task of interacting with a computer. The interface was written in php, the page was spinning on a WEB server with autorun in full-screen browser mode. Integration with the main system was carried out using the simple-api driver - certain php requests to ioBroker simply twitched through php. The system unit itself was hidden in the bowels of the office desk, the interface was controlled with the mouse, and the quest dispatcher had a wireless keyboard.

Visualization for the operator was developed in the VIS driverfor one resolution - the operator’s monitor, but subsequently the quest staff were able to use mobile tablets with the same interface, it turned out to be convenient for resetting in preparation for a new game and for diagnosing the system. The interface turned out to be Spartan, without fashionable dashboards and ryushek-switches, but understandable, simple and fast. There was no need for special logic, layers, graphs, or anything else in the interface, only icons for displaying equipment status, buttons for control, and several text fields for displaying the operation mode of controllers and the system operation log.


At the time of the development of the project, there were no other options for visualization design. Later, visualization adapters appeared both for mobile devices (I use material ) and for stationary tablets / computers: habpanel , lovelace , tileboard and others.
The main logic was laid down in the code of the controllers, but the general interaction, initialization of parameters for starting, service functions, etc., was implemented on the main server using the javascript adapter . The code was written in JS using the built-in ioBroker functions , followed by a "move" to blockly (this functionality appeared later than the start of work on the project).


In total, several scripts were involved:

1. script for initial system initialization (first inclusion)
2. script to reset all controllers before the next game
3. one of the controllers did not immediately "move" to MQTT, so for some time a script was used to exchange with the controller via HTTP - GET requests
4. script for maintaining a separate log of the gameplay

All controllers based on Arduino UNO boards (later several controllers had to be converted to Arduino MEGA boards - there was not enough memory) were equipped with an Ethernet expansion card based on the W5100 chip. Data exchange between controllers and the server (as written above) using the MQTT protocol. The development of algorithms in the Arduino IDE was carried out using standard libraries. On the iron side, there is nothing supernatural - the maximum use of ready-made modules and expansion cards with a minimum of soldering and without the manufacture of custom boards - all on breadboard boards. Load management through modules with conventional and solid state relays, transistor switches for LED indicators and low-power loads. On the mechanical part, I tried to use movable elements as little as possible: microswitches, pushers, E / M locks and more use ready-made LED-photodiode modules (open optocouplers), solid state relays, conventional magnetic locks, proximity card readers and reed switches. A few photos below:





On-site controllers were powered through home-made POE adapters - twisted-pair cables used idle cores to broadcast 12V DC. Conversion on controller boards through ready-made DC-DC boards up to 5V - from which Arduino + Ethernet boards themselves and low-power load with 5V logic were fed: low-current LEDs, relays, etc. More powerful 12V load: magnetic locks, powerful relays or contactors, various lighting equipment - Separate cable lines were used with a ball screw or PVA wire. Two 220V AC inputs were brought into the main automation cabinet and a UPS was connected via contactors on the contactors, which in turn was connected via bypass, for ease of maintenance. To power all automation and low-voltage, powerful 2-volt power supplies were installed in the cabinet, 2 by 12V and one by 5V.



The remaining solutions are pretty standard for such projects. Video surveillance system on wired IP cameras, always with IR illumination and built-in microphones. The video stream is used in one of the quest tasks and is additionally processed on the quest manager’s PC; open source software (ZoneMinder) is used. The local network of Arduino controllers was separated from the rest of the networks so that the stream from the cameras would not load the already weak W5100 chips of ethernet-boards.

Handsfree with participants in the game using a conventional Soviet amplifier and built-in ceiling speakers.

In the end I wanted to describe a little central server. The ioBroker platform is deployed on the BananaPi ARM single-board, the power of which turned out to be enough for all tasks. The environment is the Armbian operating system, a couple of bash scripts for working with GPIO and for creating backups to the cloud on Yandex.Disk. Several GPIOs are used to indicate the operating status of individual modules and adapters (LEDs) and a button to turn off the system correctly. In the photo of the 19 ”cabinet above it can be seen that the board is in a standard cheap plexiglass case; later it was installed in a 1U case with a normal power supply and other peripherals.

Bugs, pitfalls, difficulties

My colleagues and I thought out the basic architecture quite well in advance (I did the project) and many nodes were assembled and tested “on the table”, so there were no fundamental changes. Minor “roughnesses” were fixed on the spot. The main problems, the solution of which took quite a lot of time:

1. Lack of Arduino memory on 328 chip, moving to Arduino MEGA board. Predictably rested on some controllers in the chip memory. Most of the time was spent on reworking the expansion cards.
2. Glitches in working with the MQTT driver were rather quickly solved by the author of the ioBroker project.
3. The long and difficult process of selecting a browser for the normal visualization in the VIS driver. It turned out to be difficult to work with this adapter. As a result, editing was carried out in the Chrome browser, and the runtime operator launched a specific version through the Dragon browser. As the bugs were fixed, they completely moved to the latest Chrome browser.
4. Gradual creation of anti-vandal solutions - abandoned microswitches, mechanical buttons and pushers, film keyboards, etc.
5. The Sheriff electromechanical locks turned out to be of very low quality; they had to be replaced locally with ordinary electromagnetic locks.
6. The unstable operation of Arduino controllers when working with IP cameras, as a result, the networks were divided and everything worked as it should.

Conclusion

The entire project, from studying and agreeing on the scenario to launching the first test groups, took about six months - a lot, but it was the first experience and, moreover, I almost kept up with the main work on building / repairing the premises. Plus, there was a lot of work "on the table" - mainly when using separate Arduino modules, because they did not work exactly as I expected. When implementing the project, we tried as much as possible to adhere to the following principles:

1. The project involved maintenance and minor repairs by any engineer who at least once held a soldering iron in his hands, knew what the Arduino was, and would be able to “blink” the LED soldered on the board.
2. Development in Arduino IDE using standard libraries for maximum simplicity.
3. Maximize the use of off-the-shelf, common modules in a project for ease of maintenance and replacement
4. Use standard protocols and data networks
5. Minimize the number of mechanical parts for durability and anti-vandalism.

As a result, in the first couple of weeks it turned out to get rid of all the minor flaws and now the system has been working for almost 4 years now in almost the initial environment.