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

Setup, Configuration and Use Beginners
61

So this means they are using OH only for hobby-like functions. My approach allows putting on OH something more serious, expanding it’s use nische.

This is again a conflict, which I asked @rlkoshak to resolve. What if you don’t want actuator to accept sensor input directly if OH is running and controlling your installation? Example as above - motion sensor and a light relay(actuator). You can configure motion sensor to send command directly to relay and activate the light wherever movement is detected - yes, Z-wave mesh feature allows this easily, as well as in KNX, and this will work without any central controller. But when you have a controller you might want to change this algorithm, make it more user friendly. You might want to block the light activation sometimes, when you are watching a movie or activate movement detection only at certain time when it’s dark, or reduce the light brightness after 21:00. So you will need to modify the command in controller before it reaches in the actuator. But all this will not work, if you have a direct sensor-actuator link. Therefore I say - Mesh is useless. Or you explain me how can you keep it working like this.

62

That sort of provocative wording is yours (only). That’s what I’m tired of.

It depends on the actuator’s capabilities if that would work.
But you’re missing the point. This is a design decision you have to take in one way or another.
You would only do that on lights that you believe need to even work in degraded mode and that don’t have a wired switch. Given we have optimized MTTR that’s just a couple of minutes you will run in this degraded mode.
You could even add emergency-only switches. I for instance have a ZWave remote to cover that case.
Placed right next to my bulb light that I might need in case of power outages.
Hardly ever used it although my controller is relatively often down as I use my home as a test bed.
To sum up, if you properly designed your home that scenario won’t exist.
So it’s a purely hypothetical question hence irrelevant to the architecture discussion.

63

I can’t say but I don’t see why not. I’m in the US so those are not that common. I have mine set up with a decora rocker switch set up where flipping it either direction toggles the light on or off. My Zwave switch looks like a decora switch but it’s just a push button in practice.

Who cares? Based on past experience OH is down for about 2 hours over the course of a year. And that’s for upgrades and power outages. In five years I’ve experienced exactly one case where I was away, came home, and I couldn’t open the Garage Door because something went down. But I had the remote that came with the garage handy and was able to get into the garage just fine. It was just a little less convenient.

That’s why I keep asking, is adding all this redundancy and fail over and such worth it?

But, if you are using Zigbee or Zwave that scenario is possible. You can configure the devices so that the motion sensor controls the light or the switch directly without going through openHAB.

Of course. That’s all part of the failing gracefully. When OH is down, the device need to perform at least at a basic level independently. When OH is down, you can control the lights with the wall switches. When OH is down, you can control the HVAC with the thermostat on the wall. That’s what failing gracefully means. When OH goes down, your stuff behaves more like an escalator than an elevator. It may not be as convenient when OH is down, but it’s not completely unusable.

You have to choose. Is it more important to you that your home automation perform 100% of all automation functions at all times regardless of failure, or do you allow some of the automation functions not work during those brief periods of down time. If you want the former, you probably don’t want to use openHAB anyway as a central controller and instead push all the behaviors and interactions out to the end devices, letting them talk to each other without central control. If the former, modern hardware is reliable enough when only minor precautions are taken.

Do you have to be able to control those roller shutters during those brief periods when openHAB or your network is down? I think the crux of the problem is your home automation does not have to be fully functional at all times and in all ways. Stuff goes wrong. When stuff goes wrong, you need some sort of backup for the important stuff. Stuff like lighting, door entry, HVAC. you know, health and safety issues. Does it really matter if you can’t open or close the blinds for an hour because openHAB crashed for some reason?

Honestly, there are aspects of the openHAB architecture and overall approach that makes it unsuitable for almost all of those more serious applications. There is no real-time processing, no transactions, a lot of times there isn’t even confirmations and acks. There is no determinism. You can’t even guarantee the order of processing for events that occur too close together.

If you need the kind of reliability and deterministic behavior, you need to go with a system designed from the ground up to do it. openHAB is not it.

64

Yes it’s all about failing gracefully, going to degraded modes, installing backup switches, MTTRs, selecting right actuators or invest couple of hours and two hundred bucks into redundant central controller with automatic changeover and forget about all this.

I selected second approach and recommend it to others. Others can check arguments for both aproaches above, discussion can be closed.

65

Don’t I know that one :stuck_out_tongue_closed_eyes: but my house still functions as it did before I found openhab so the wifey is happy :muscle:

66

My TV is located behind an OH-operated shutter door so you can’t watch when it’s down.
Forget about lighting and HVAC - THAT is when you really really need a fallback (I have kids).
Actually about the only occasion I ever used this for.

67

@Artyom_Syomushkin and @rlkoshak/@mstormi are two interesting way to have e reliable and available smart house.

How I understand things :
The Artyom’s one is focusing on having all the features up on a maximum of time. Behaviors are mainly coded in devices and less in OH. But at a price of convenience in setting things : set up rules and behaviors seems to me to be less easy in this way. And could be limited compared to OH ones.

The Rich/Markus’ one is focusing on convenience to set up and modify rules and behavior. Behaviors are mainly coded in OH. Degraded operation is coded on devices. It is simpler to set up and behavior could be more powerful via OH. But when OH is down, the operations are in degraded mode. It seems less complex to set up in hardware aspect too.

For me, and it is my personal point of view, the second way seems to be more convenient. The Rich’s last post sums it up very well.

That’s exactly how I see home automation. But as I have already said, it is a personal point of view :wink:

In any case, thank you for these instructive interventions.

68

No, all my behaviours and rules are coded on and only on main controller, even the simplest ones. My devices are really dumb I/Os.
And instead thinking about graceful failure modes by wiring wall switches for local light control or adding mesh relationships between devices I just eliminate single point of failure and make sure that my controller is available 99.99% of time and it’s availability is guaranteed. As the result my rules are as simple as they can be and the system architecture as well, but whole system is a lot more reliable.

And now I can treat my home control system like it is just a solid device without degraded behavioural modes - it either works and executes 100% of functions or doesn’t work at all e.g. fails - this is how it is done in industrial world. Only I/Os can degrade - e.g. if some relay fails, connected lamp will not work. But the rest of the system will continue working as usual. This makes life and understanding a lot easier.

69

Maybe I miss something, but if all your devices are dumb I/Os and all your installation is controlled by a central controller, there still are a single point of failure : the central controller. It can be as reliable as possible, it is always a single point of failure.
Even if you have automatic switch with second controller. For example, a corruption synchronized by error on the second controller could happen. Yes, risk is very weak, but it still exists.

Why do not add meshed communication between devices on top of your setup ?
It is not incompatible it seems to me.

To be clear, I am not criticizing any point of view. I’m trying to very well understand the reasons everyone use this or that strategy.

70

Single point of failure means that if this equipment fails the whole system will fail. If I would have just single central controller - yes, it is a single point of failure, as my whole Home Automation will stop as a result of it’s failure.

But redundancy is one of the ways of eliminating single points of failure, so I use it in my system. And as we have clearly identified SPOF component - central controller, it becomes obvious where we need redundancy in my case - just for central controller.

The way I implement redundancy is one of multiple possible ways - you can have hot backup, e.g. when your standby controller is also running - this is critical for a systems where process should not be stopped during changeover. Or you can have a cold backup - where you have spare parts on site to replace broken controller. Or you can have warm backup - e.g. when backup controller is not powered when main controller is active, but will be powered on it’s failure. While having minor impact on total availability percentage these approaches have significant difference in changeover time - from few milliseconds to hours. That’s why in aircraft they usually have a hot backup. And I use warm backup - as it is a good trade-off between implementation effort and changeover time.

I’m not using any type of automatic syncing between controllers. Secondary controller is not powered when it is not active, so also HW issues - like broken SD card or power supply are not relevant for it.

Go ahead and do it. You can relatively easily add backup switches for light controls as suggested above, especially in existing installation. In my case it was a new installation, so I decided to have a completely switch-less setup with tablets instead of switches. I saved a lot of money BTW, because for each switch my electrician wanted about 50 euros.

But everything more complex than that will require more clever I/O devices or a lot of thinking, so I avoided that.

71

So you don’t notice if it’s broken until you need it.
That’s actually a well known issue to in fact happen quite often with this type of setup in both, data centers and homes and one major reason why I’d avoid this.
And you need to sync data when you power up your backup.
But at this stage, your primary to sync from is broken. So how do you access the data ?
It might be simple (move an SD or USB device) but what if that is the broken component ?
It can also get ugly quickly if you need stuff like e.g. the latest configuration of your zwave network (which is stored inside your controller and nowhere on disk).

That would have been worth to mention earlier … when you don’t have the hardware capabilities to fail gracefully (e.g. switches) you have no chance to increase reliability other than going for controller redundancy. But that does not apply for the vast majority of users.
Yes you can save some money here. But I think the old saying “you get what you pay for” applies literally in this case.
You can do this on non critical infrastructure. For example I, too, omitted switches on roller shutters when I motorized them (there was no switches before so I saved paying for them as well) because it isn’t critical if you cannot raise them in degraded mode so that was a clever move.
Omitting all switches including all lighting on the other hand means to save on the wrong end (Rich is there a better English saying ?). Again, you get what you pay for. And there’s existing switches in practically every home, even new ones. Most actuators allow to attach existing switches so as a net balance they are there “for free” and this is what will allow you to degrade gracefully.

72

…and there are many ways to solve this.
First the secondary controller in not powered when in standby. This means it has no wear and it even can survive a lightning surge in the house, while other equipment will burn. So it’s reliability much higher, than of primary controller.
Second I usually run a simple test every now and then, where I shutdown the primary controller and check that secondary successfully takes over.

Well, nobody cancels usual backups here. And basically how you clone the controller? You take a backup of your SD card and Z-wave stick and then clone them to another SD card and stick. I also store a copy on my NAS, synchronized to google drive. So you will have three backup images to choose from.

While I agree, I did a new installation and have some specifics with wall switches, I can’t agree completely with you statement about “existing switches in practically every home”. In many cases they are close to be … impractical.
And you know why - absence of the N wire at wall switch - in standard electrical installations at least here in Europe they don’t route N wire via wall switch box, and instead it goes straight to the load. And switch just commutates the phase. So if you want to install actuator in wall switch box - you have a problem - no N wire, no power. Some dimmers can work without neutral, but relays not.
And if you put actuator close to the load, then you need constant L. If you route it via switch, then yes, you will have a kind of degraded mode, but when you turn off the switch, your actuator becomes unpowered and will not react on controller commands. That’s a bit weird for Smart Home.

73

Definitely, I find this really to be an interesting discussion :+1: :ok_hand:

Artyom’s choices seems to be very relevant in his installation without switches. And even in more standard installation with wall switches, some parts could be interesting and relevant.

Regarding the central controller, a hot backup seems to be unnecessarily complex. A cold backup seems to be the simpler way. With a very little more complexity, a warm backup as said Artyom seems to be a good compromise regarding the convenience gain.
I agree with Markus that is maybe too much for some beginners or simple installation. But just one more PI with two relays doesn’t add as much cost. So for some zealous makers or for some cheap luxury, it could be interesting to add it.

I do not remember if it is possible to store just the configuration files without the whole OH installation. But in case it is possible, why not to store the backup archive on a git system like GitLab or GitHub too ? In addition to a cold backup on the shelf.
Version control could have some interest in this use case.

Regarding a standard installation with existing wall switches, the possibility to fail gracefully still seems to worth the added costs.
It could be interesting for beginners and more to list ways to achieve it. Maybe this list already exist ?

Regarding me, as I want to learn ZigBee and design and add customized battery powered sensors indoor and outdoor, I still keep my idea of using a meshed network in parallel of a warm backup. It adds a little complexity, but to me, it seems to worth the time and money cost (ultra low power wireless devices enthusiasm me a lot).

One other thing, just to think about i t:
In case of a more complex element like a lighting with CCT dimming (or led lighting where the dimming function can not be achieved by modifying the main AC line signal), how would you handle it ? With a wireless CCT dimmer located on lighting, and a brightness/color value set by default directly on this controller (to fail gracefully) ?

74

You also don’t have backups if you have never tested them. Some of our systems have single point of failure however most of them are mechanical. We use all forms of backup warm, cold, hot and human hotline.

We had a configuration SD card die in our main controller. It was not during operations and less than 5 min for me to fix. About a year later boss tells me they had this issue on different site and it was not running for 18 hrs. I told him we mitigated that issue and to not worry about it. work

It all depends on the level of skill you have for people to fix an issue. At work because our local team is has some highly technical people we don’t log an issue on hotline as we normally have fixed the issue before they ring.

We have cold backups on a changeover switch system that failed spectacularly with sparks and smoke. So the backup system failed and wouldn’t supply power to the system on one side of the system. After a flick of the switch we could get it running in the time it takes to boot the pc’s. All the data was erased on that system and everything had to be regenerated which took a little longer.

The issue that caused us the most about of total downtime to date was a full HDD.

Marry Christmas Everybody.

75

For me running my openhab on a qnap NAS with hot swap raid drives works fine.
Backups are taken nightly over two site to site vpns to 2 x other NAS drives.
My smart home environment also operates over the vpn with smart devices at all locations.
The vpns are Ethernet level and both other NAS units have multiple interfaces configured for my local subnet.
If my NAS fails for any reason one of the other NAS’s will start openhab with the latest backup.

To date I haven’t had my NAS fail, or a hdd, and I’ve had it running continuously for 7 years now - although I probably should give it a clean.

Oh and all sites have ups and sim 4g backup

76

Interesting solution. I did not think about it. It is still more complex, and needs a second NAS. But it works.

What about CCT or color dimming ? How would you handle this case ?

77

In what sense? Control? System Failure?

For control - I have Fibaro dimmers at every ‘main’ light fitting (where the switched live is). My switches are retractive and use click/double click/hold for on-off/full power/dimming. Where I have colour bulbs I just have a hue dimmer next to the switch which is set up for scenes. Ideally I would want to have wall mounted Zwave colour controllers which can also do scenes, but, I like to have the physically wired, mechanical switch there if there are any issues (wife friendly). These were my preference and will probably get at some point, then will add association as the fibaro for controller failure, and let openhab manage scenes for colour (hue bulbs), (but you could use Zwave bulbs and eliminate the dimmer unit)

And where I have rewired rooms due to a complete gut, I have run additional cables so I use centre off retractives so I can use the switch for scenes aswell.

78

@pit34 let me point out the fundamental difference of @Artyom_Syomushkin’s solution and ours:

Sure first thing is the different methods to increase reliability. Note however that you MUST go for controller redundancy when you don’t have hardware that allows to fail gracefully.
Then again if you do, you CAN use both methods. At the same time. I wouldn’t recommend for redundant controllers (reasoning yadda yadda see above) but you COULD while for a controller-only setup there is no way to set that up to fail gracefully.

@Artyom_Syomushkin said he didn’t implement it because it’s complicated.
Well, yes it takes quite some work and time to get it right, but it isn’t too complicated otherwise there would not be that many working installations.
And it provides functionality superior to the controller-only setup.

But what’s IMHO most important is this:
Traditional operability via switches is what most people expect and demand, and noone (but except the most convinced like Artyom) wants to change his habitude of ‘traditionally’ operating their home using switches. Most are fine with additional functionality such as voice control or light to turn on automatically thanks to presence detection … but NEVER at the expense of giving up control via switches.
That means you have to solve this challenge anyway - one way or another.
And note the above applies to individuals but it applies likewise and even more so when you have partners and family to live in the same home, guests and other people to expect your home to work in a specific fashion (think craftsmen) let alone in case of emergencies (think firemen, medics).

79

I totally agree with what you said.

It is why I want to keep my existing wall switches and just add smart modules on thems to have gracefull failure.
It will be my main reliability feature. In second time I will maybe add a redondant controller like @Artyom_Syomushkin has done.

For color dimming, it seem for me that @delid4ve’s setup is a good way to achieve it.
Thanks

80

That reminds me of another major reason to go for local control (switches) although as Dave said it’s very difficult to get hold of them in this case.
I had a couple of issues with the software to run (i.e. openHAB).
Note not to mix/confuse that with hardware issues and measures to mitigate we discussed in this thread. Also note this is a much more frequently met problem than hardware failures are.
It can happen on dual controllers with a perfectly working redundancy mechanism as well.

The issue I ran into is this: I had a lighting scene active including a bright RGBW color lamp (actually a large strip to do indirect lighting) that has no local switch because of (un)availability of “color” switches.
Then there was a problem with openHAB. It crashed and refused to restart.
Note I hadn’t changed anything - that implies that if I had switched to a secondary controller with the same software setup (if I had had one …), I would likely still have been having the same issue with openHAB still being unable to switch (off) the color light.
I was tired and annoyed because I couldn’t pinpoint the openHAB problem and could not get it back to start so I decided I needed a break.

But it was 2 a.m., and my bedroom was brightly lit.

By a lamp with no switch. Not even powercycling the breakers helped because the actuator was configured to restore settings on outages. All I could do was to power down the house for the night :frowning:.
Duh. That’s those occasions where you wish you would have spent even more work on your architecture (and a consequent implementation).