What's your HA reliable architecture ? Mesh + central controller?

Setup, Configuration and Use Beginners
1

Hello there,

I would like to know what are your Home Automation architecture and strategy. More precisely, how do you achieve a reliable and safe HA?

I have already OH installed with few devices and sensors. All is working fine, but I would like to go next level and automate my lights reliably.

I have thought to use a mesh network for sensors and actuators, along with a central OH controller, and try to avoid singles points of failures in the same time. It may be asking a bit much…
With actuators and sensors communicating on a mesh network like Zigbee or Thread, events and data can be reliably diffused.
A central controller can add intelligence and scenarios on top of that mesh network. And be easy to set.
But a central controller is a single point of failure, and if it fails, all the home automation fail.
I would like to make coexisting both. Mesh network with central controller. This way, if OH server fail, devices can still work.

What’s your opinions / Strategy about this subject ?
Thanks to share those :wink:

1 Like
2

I have a VM running Debian & OH on a UPS powered server. The UPS alerts the server if runtime gets low so the server can cleanly shut down.

My devices are Z-Wave mesh network devices. If I wanted further redundancy I could associate devices using their groups so they could operate independent of OH.

3

Runnin OH under Armbian on UPSed & eMMCed passive cooled Nanopi K1 plus -> Z-Wave network + 1W gpio attached sensors to measure temp in the rack. No issues for about two years now. Already a bit overkill for the job.

4

I am also running OH on a UPS. But it is not really the subject because if the main AC line fail, all actuators fails. It just permits to not suffer an OH server reboot due to short time main AC line fail.

I have though about some parts of a global reliability strategy :
• Mesh networks permit to have a reliable communication between actuators and sensors.
• OH automatic backup and hardware spare permit fasting reinstall OH in case of hardware or software failure of central controller.

It still misses parts between those.
Take the following example on lighting scenario :
I have a mesh network, assuming Zigbee, on lighting. A Zigbee compatible light, wall switch and presence detector. I can set those to work without OH. The Wall switch can actuate light without OH. It is the simplest and reliable solution (after not to create HA in fact).
On top of this I can add some intelligence by connecting a central controller with OH and a Zigbee gateway. This permit to, for example, switch on the light when presence detector trigger. And if the central controller fail, I still can use my lights, without the smart and autonomous part.

Taking the same example but with the central controller, but without link between the wall switch and the light. The central controller tell the light to switch ON or OFF when the wall switch is trigger. But if this central controller fail, all the lights fail.

It’s about this sort of scenario and strategy I would like to discuss with you :wink:
What are yours ?

5

In my somewhat controversial opinion, focusing on this sort of reliability is:

  • super complex and difficult to achieve; well beyond what even most technically savvy home automation deployers

  • The complexity added rarely “costs” less than the problem being mitigated

  • the redundancy and fail safe technology often becomes a source of failure itself.

It’s a fun exercise and challenge. If you want to do it as a personal challenge and learning exercise go for it. But if you ae serious about the reliability of your home automation:

  • Design escalators, not elevators. Even when the power is off, you can use an escalator like stairs. It may not be as convenient and you won’t have full capability, but you can get by without the automation for a short but of time.
    example, don’t eliminate those wall switches.

  • Have a well established and tested backup and restore approach.

  • Use UPS where necessary to protect devices (e.g. computers running off of flash memory)

  • Keep it simple.

Reliability engineering is as hard if not harder than home automation itself. And it’s not needed in a home automation context. You can achieve at least three or four nines of reliability (i.e 99.9 to 99.99%) almost out of the box. How much time and effort is it worth to spend to save < 88 hours down time over the course of a year?

But you have to make technology choices and architectural choices to achieve the above. In your scenario you have a light switch not physically controlling the light. The solution is don’t do that. It have done Uther way to control the light when stuff goes wrong.

2 Likes
6

Like @rlkoshak already pointed out - tl/dr keep it simple and have a backup :slight_smile:

Autonomous system that works without any extra brain in basic mode so that your wife doesn’t get upset during maintenance sessions + fancy stuff driven with HA.

1 Like
7

Maybe I misspoke and make myself misunderstood.
I don’t want to build a complex system. I would like to keep it as simple as possible, and only would like to build escalators and not elevators as @rlkoshak said.

Ideally I would like to keep all the current installation and keep all the current wall switchs. And just add some intelligence on top of it with OH. But I haven’t seen how to achieve it with simple things, and I went to found mesh network + central controller idea…

To continue with the lighting example :
Assuming keep all the current wall switchs. To add some intelligence on top of light system and stay simple, the only way I could see is to replace wall switchs with smart wall switchs, that have a physical button and a wireless communication to be able to be operated by OH. Am I right ?

What is your strategy for this example ?

Thanks :wink:

8

This is exactly what I did and probably many others. You need to add ground wire to all switches since you need to power them.

9

Looking at what Z-Wave offers it varies depending on world region. Here in North America the wall switches can be replaced with Z-Wave ones and they still keep their local control. Other regions require some relay devices. etc.

10

Depending on your region this may be the neutral wire. Certainly here in the UK it’s the neutral that is (often) missing from the back boxes.

2 Likes
11

You don’t want to have any physical switches in your system at all. If someone leaves a switch off you cant use it.

I have ceiling fans with lights controlled and have installed IFAN03 I put blank wall plates on to replace old light switches and used double sided tape for to stick the remotes to them.

I flashed them with TASMOTA for better control. I can control the fan and light in multiple ways.

  • MQTT
  • Navigate to webpage
  • Remote taped to wall (it looks better than it sounds)
  • openHAB - Google Assistant - Sitemap - Rules
12

Powering the wall smart switch is not a problem. At the beginning of my HA experiments, I have added some Shelly and Sonoff modules back of a few switches, but gave this way up thinking it was not the more reliable way.

Ok, so if I understand :
• the physical button of the wall switch become an external “toggle button” of the module, that invert the current light state. Those could even be replaced by touch switchs like @denominator said
• the module could be actuated by this physical button, or wirelessly by OH. By rules with presence detector for example.
This way, it can work without OH in case of fail, or with OH.

I need also to determinate the wireless protocol. I am still hesitate between Zigbee/BLE and Wifi
• Wifi is the easier way (ESPs are Arduino compatible). Modules already exist like Sonoff or Shelly, with open firmware like Tasmotta, or better with custom own firmware. But I find that they consume a little too much current unnecessarily. It could also congest my Wifi network in the long term.
• BLE and Zigbee could be a more efficient way, but these are a bit more difficult to use. Especially Zigbee. BLE could be a good compromise if I want to reduce idle consumption and stay easy to implement.
But this is another subject…

If we continue on the lighting example, and try to add a some features like dimming or schedules, what would be your more reliable and simple way to implement it ? Locally on smart wall switch or by OH ?

13

I mean neutral, yes. Sorry for adding confusion.

14

My physical Z-Wave switches do not work like that,

https://www.getzooz.com/zooz-zen23-24-toggle-switch.html

1 Like
15

Some thoughts about dimming feature :

Dimming can be done multiple way :
• On the wall switch part, by directly act on the AC signal. As this way can not be use with led lighting, I gave it up.
• On the light part, by PWM dimming or current dimming. As the leds should dominate lighting market, I assume that this should be the way to go.

If the dimming is done on the light part, to keep things simple and reliable, the dimming value should be able to be set on a wall dimmer (in case of OH fail) or by OH. So the value must be communicated to the light part, at least by the wall dimmer.
I can install a new couple of wires between the wall dimmer and the light part to communicate the dimming value. But it is not feasible in the most case. So it must be done wirelessly. And there, maybe you see where I’m going with this…
This requires to implement a direct wireless link between the wall dimmer and the light part (for the direct set of dimming value by the wall dimmer) and a wireless link between OH and the light part (for OH rules).
The simple way could be to use MQTT. All parts talk with each other by MQTT, the wall dimmer, the light and OH. But if we have several switchs and several lights in the house, the MQTT broker become a dangerous single point of failure.
So I come back to my original subject and solution : mesh network + central controller…

And you, how would you do reliably the gradation?

16

You know what I mean they are toggle switches and can be toggled remotely. :man_facepalming:

I was more talking about a switch the ones that cut the power when turned off.

17

Most of the existing physical switch I added a Zwave dimmer/switch supports allows local control without any central ‘brain’. ZWave Mesh is nice, but also has single point of failure (the Zwave controller), based on personal experience failing or missing nodes can make a ZWave network very unresponsive as well.

For that reason I am using now a combination of MQTT(Tasmota) and Zwave. So not relying on a single system to have some kind of redundancy.
So far I consider the WIFI infrastructure more reliable and easier to maintain and setup.

18

It is worth noting that this is probably the wrong approach. You will get better redundancy, or robustness, by using a single system - yes, that does open you up to a systematic failure (eg if ZWave had a major problem then your system would go down) but if you use technology like ZWave or ZigBee that have been around for many years, such a systematic failure is unlikely.

Also, I guess redundancy isn’t really what you have, as you probably don’t have every light using both ZWave and WiFi such that if one system failed, you can still switch a light with the other?

The point though is that if you use more devices in a mesh network, you will have a more reliable system - the mesh will be better, the controller will have more options for routing, and overall reliability will be better. By using multiple systems, you potentially significantly reduce the robustness of your system.

WiFi has many issues in this space…

Currently, most WiFi systems are not mesh networks but are point to point connections.

You must ensure that you have a system that can handle enough devices. Most low cost WiFi systems that most people have at home do not support the number of connections required for a “full house” home automation system where every device is on the network.

WiFi will typically not work well for battery devices - ZigBee/ZWave mesh systems are designed with super low power mesh networking in mind.

Also note that there are currently limited application standards over WiFi, so devices can’t talk to each other (unless they are the same manufacturer, but then you’re back to the systematic failure issue).

ZigBee/ZWave all have well defined application layer interfaces to allow devices to communicate and interoperate. You know that if you buy a certified device in one of these systems, it will talk to other devices - even from different manufacturers (in at least 99% of cases anyway :slight_smile: ). WiFi is just a transport layer, so you need something on top of this to provide the application - possibly MQTT is becoming more common that it might one day meet this need - who knows.

19

I mostly agree with that @chris said. Mesh seem to me the best way, to an efficiency and low power point of view, and reliability point of view. For a simple smart house, Wifi could be a simpler solution, but if you want to add door sensors, light sensors, temp sensors and so many things, you will reach limits pretty fast.
It is not my case right now, but I love to create DIY things like sensors, and I don’t want to restrain my possibilities at start.
I should add a mesh communication protocol along my central controller.

To do that, the difficulty is that Zigbee and Zwave are not DIY-friendly. Creating a custom module and firmware to design my own sensors and nodes are not really easy, and not well documented.
I am currently searching in BLE mesh (HM-10 BLE + Arduino) or RF mesh (nrf24L01 + Arduino) that seems to be more documented.

If anyone has another advices on those subjects, you are welcome :wink:

20

ZigBee is very well documented, and there are many suppliers of hardware who have their own documentation for their frameworks, so it’s not so hard (although it’s also quite a complicated protocol in some ways).

ZWave is also well documented, but there is of course only a single supplier of devices, and IMHO the Silabs documentation here (which to be fair they inherited recently from Sigma!) is not good, so it’s definitely much harder to play in this space.

IIRC, BLE-Mesh is not a real mesh, but uses broadcasting rather than routing. This will have some limitations.

From my experience, BLE and ZigBee probably have similar “DIY learning curves” - it depends on the devkits and tools etc that the chip manufacturer supplies. My recommendation would be to go for ZigBee - the other problem you will have with BLE is you will need to be responsible for both ends - ie the device, and the binding since there are limited application layers available for BLE (AFAIK anyway). If you implement to the ZCL, then you have compatibility with the ZigBee binding, or the zigbee2mqtt etc binding.

2 Likes