Throughout my automation journey there is one thing I always strive for, that is full duplex communication. The ability to send a message, but also receive a message from a device. This need, often in many cases influences technology choices. Which TV will I buy? Why will I build an irrigation controller over buy?
Automation is closely related to many software engineering concepts.
The ability to read state, can be achieved in both the physical and logical world using sensors (analogue and digital) and protocols from MQTT, HTTP through to Serial and beyond.
You do this because, just because you tell a device to turn off, or on, are you really sure you it did what you told it do?
You want feedback loops
Could you afford to have your door left open to your house or garage not closed (I know I can’t!) or if I turn the volume up on my NAD pre-amp for a zone manually, will my upstream systems (Home Assistant / PLC) know about it, what a horrible user experience?
But what do you do when you can’t read back the state? So, in this post I will illustrate what are your options for maintaining state when you can’t read it. Like any good opinionated architect here are my opinions on options. What are yours? Let me stress none of these are ideal but with these approaches you can build systems that are reliable and the engineering effort often comes back to business impact vs likelihood of getting it wrong.
Option 1: Limit the control plane
It may sound obvious here but when you can’t read the state of an object, the first thing I look to do, is to limit the control-plane. So, whilst you cannot maintain state easily, could you limit the control surfaces for this product?
This is a viable approach and works when the mechanism to control the device is reliable.
Examples here in my house
- X10 appliance modules (yes X10 can be reliable with the use of devices such as XTB-IIR) which I did use heavily at one stage for switching of GPO (General Purpose Outlet)’s. I still have a few scattered around. Whilst they are technology of yesteryear, being that they are nestled in the wall behind the GPO means there is one way to control them, and that is by device running the X10 network (my PLC in this case, but it could by a MCU / Raspberry PI / Computer or anything with a serial UART).
- Roller Shutters. I run electric 240v AC powered roller shutters which I drive solely via MQTT topics. You can read more about my journey here. There are no wall switches in my house. By using MQTT topics with multiple subscribers I have one entry point to the control plane (the sole MQTT Topic). The multiple subscribers I have thus far are a PLC, Arduino, Home Assistant and by virtue of integration in to Home Assistant, Amazon Alexa.
By removing, or never installing wall switches it is just MQTT as the sole mechanism that can change state.
Option 2: Eventually consistent
This sounds like Azure Storage / Amazon S3 here which in various modes are eventually consistent.
I use this as an option as what if you have a need for multiple control planes. It could be for example it could be when you need to have both physical and virtual control planes.
If there is no way to communicate that a switch was toggled to the other control plane, what can you do to maintain state?
Well, it’s not perfect but you can augment sensor data to give you a higher level of confidence that a device is in a specific state. Add richness via correlation?
An example in my house is
- X10 yet again, but this time what if I use an X10 appliance module for a light switch. Given the module is not able to send a message back updating state, how can I deem if someone manually toggled a switch. The truth is I can’t, but I can augment. I have PIR sensors in every room for my alarm system and I can track state.
The rules in my house state to turn lights off when there is no presence in rooms. What this means is when I logically turn lights off, I have then synchronised both the physical and logical world. The lag time, or feedback loop will vary depending on my logic, but it means I can deem state to a degree.
Option 3: Sensor augmentation
Similar to eventually consistent but could you detect if a device is on or off by using another sensor. This doesn’t limit the control plane but allows you to deem if a device is on or off, up or down based on other sensors.
Ideally you want to strive for this option as it provides full duplex control.
Examples in my house are
- Garage and Roller Panel Doors. I have in total of 4 roller / panel doors in my house with electric motors. Changing state is in all cases a dry contact in which is PLC / Microcontroller controlled in all cases. But what I can’t tell is the state of the door, is it up or is it down. What I can do is use a magnetic proximity sensor which will act as a digital input and be high or low depending on state.
Not used in my house but possible would be
- Current detection. Various appliances modules (Sonoff Dual R3 / Shelly 1 / Sonoff Pow) will be able to detect current draw. As you can then transmit via HTTP or MQTT you can then deem state and apply logic as provided
Conclusion
Whilst not ideal having devices to which you can’t track state, I hope these 3 approaches will arm you with mechanisms to mitigate the impact of not being able to read state. Automation is a journey and there are approaches you can take in both automation and software design. What is the likelihood of a false positive, what is the impact of getting it wrong? These are all decisions we need to make as builders and architects. Automation and software architecture is a journey, which path will you take?
Think big and happy building
Shane