Hello,
I would like to share a project I’m starting to work on, which I think can be a good “case study” for the new mesh devices, and ask your opinion and suggestions on a few “open points”.
The idea is to create a HW and SW platform to control Escape Rooms.
Escape Rooms are composed of “puzzles”. Each puzzle is controlled by a mesh device, what I call a “Control Brick”. The platform consists of:
- One or more Control Bricks, one for each puzzle in the game.
- (optionally) One or more Control Bricks to control lights and appliances in the game which are not part of any puzzles.
- One web application to configure the Control Bricks (device manager).
- (optionally) One tablet application, used in the field to communicate with the Control Bricks, monitor their states and send commands.
All Control Bricks communicate between them using the thread mesh network. At least one Control Brick acts as a gateway to the internet, in order for the device manager web application to work. Once configured, the Control Bricks does not need internet connection to operate.
The logic of the puzzles is saved inside each Control Brick. So, each puzzle is autonomous in its operations, but can optionally communicate with other puzzles and with other lights and appliances.
Control bricks can sometimes be used alone to control lights, appliance or other actuators. We can call them “actuator bricks”. They are not “puzzle”, they just receive commands and execute them. This way a puzzle can send events to lights or appliances.
At least one control brick is connected by wifi to the Particle Cloud. Particle Cloud is used to monitor the devices, update firmware, and configure the logic of the puzzles.
The logic of each puzzle is configured inside each control brick, which can run autonomously.
Actuators bricks have no logic, they just receive command and control their outputs.
The platform lets Escape Room Owners to configure the logic of the puzzle without programming. We make use of Finite State Machines (FSM) to define the logic of the puzzles. I thing that this is (together with the mesh network) the most innovative aspect of the project.
Generally speaking, each puzzle is an event-driven machine which:
- Receives triggers (“events”).
- Run a “logic” in response to the events, to determine when the puzzle is “solved”.
- Activates an output (generally a relay) when the puzzle is solved, to open a lock, a door, or activate an appliance.
Events can come from: - Input sensors (for simplicity digital ones).
- Virtual inputs (see below).
- Time events.
- Events received from other puzzles.
Often the solution to the puzzle requires several “steps” (ex: recognizing a sequence of inputs in the correct order). The puzzle in that cases changes its state in response to events and eventually reaches the final state associated to the soluzion.
According to the above, we can configure the logic of the puzzle using a finite state machine (FSM), with states, events and transitions between states.
Some puzzles may be complicated, and their logic may be not easily described by one single FSM. In these cases:
- The puzzle can be split in subpuzzles, where each subpuzzle can be described by a FSM and each subpuzzle may receive inputs and send events to other subpuzzles.
- One subpuzzle (one FSM) creates a “virtual output”, which is received as a “virtual input” from on other subpuzzle (another FSM).
The firmware of the Control Bricks is a “runtime” environment which:
- Loads the “configuration” of the logic it must execute at startup time (JSON file)
- Waits for events to happen (inputs to the Control Bricks, time events, command received by other Control Bricks)
- Acts as specified in the configuration (sets its output, sends commands to other Control Bricks)
The firmware exposes a function to Particle Cloud (setLogic), which can be called to change the logic of the Control Brick (JSON file passed as parameter). When a new logic is received, the Control Brick checks the configuration for syntax errors, saves the configuration in flash memory and restarts.
The firmare also exposes a string variable (currentLogic) to Particle Cloud containing its actual configuration, so that it can be checked from Particle Cloud and from the device manager web application.
The FSM is configured using a JSON string.
The JSON describes:
- The name of the FSM.
- Which are the inputs to the FSM. Eventually not all the 12 inputs are inputs to the FSM. This will be usefull when the logic of the puzzle may need to be espressed by more than one FSM.
- Which are the outputs from the FSM. It generally is the digital output of the control brick, but defining a “virtual” output may be usefull when the logic of the puzzle needs more than one FSM and the output from one FSM can be the input to another FSM.
- Which are the events which triggers the change of the state.
- Which are the states and which is the initial state.
- Which are the transitions between states, with the event that causes the transition and the output that must be set entering the new state (melay FSM).
{
game: “name of the escape room”,
FSM: [{
name: “name of FSM”,
inputs: [{name: “input1”, connection:”IN1”}, {name: “input2”, connection:”VIRTUAL”}],
output: [{name: “output1”, connection:”OUT”},
{name: “output2”, connection:”VIRTUAL”}],
events: [{name:”input1on”, input:”input1”, oldValue:”0”, newValue:”1”}],
states: [ {name: “state 1”}, {name: “state 2”} ],
start: “state1”,
transitions: [{ name: “transitions2”, event: “input1on”,
from: “state1”, to:”state2”, output:”0”} ]
}]
}
Woo … sorry if this was soooo long.
I really would be pleased to receive your feedbacks.
@gusgonnet is helping me with the firmware and we’re actually discussing weather a JSON file is the best way to describe the FSMs or not.
What do you thing ? Have you got any alternative ideas ?
Thanks in advance for any inputs. If interested I can followup the progress of the project.