How to set up a stable smart home system

Tutorials & Examples
1

To setup a stable smart home system that will run without maintenance for year after year might be tricky, but here are few points that I found useful. I am renting out my flat part time of the year so it needs to be stable! Also by law in Norway you need to have a system that can run 5 years after you sell the flat or you might be obliged to come and fix it…

Moving to my.openhab.org and required java updates made me for a while consider other systems, but I believe the core of OH now should be stable and that new features will not influence old features.

My router crashed the other day, so here is what I have learned by it.(Or what I am glad I already had set up)

  1. Heating and lights should be connected to RPI directly! You dont want your mum to freeze and sit in the dark because something fails and you are not available.

  2. The RPI can crash, so make sure you have pushbutton to reset it, either power your RPI through the GPIO or somehow solder the switch on to the usb cable(In theory you could unplug either the usb from RPI or from the outlet, but my mum finds it easier to just press a button instead of opening the fusebox and the locate the RPI)

  3. Always have a spare RPI with a clone of the system so that it easily can be changed if it breaks(like lighting, sd card malfunction etc can happen), this way with proper instruction some can get the system up running again. Maybe there is some possibility to run two systems in parallel?

  4. For heating connect them NC on the relay, because if all above fails the heating will be constantly on instead of off
    For lights the NC could also be used, but I have not done this so far. My RGB lights are running on a USB dongle instead of ethernet(HUE bridge might crash so consider wiring this togeheter with the rpi power supply). In addition I keep an extra lamp around as well as candle lights:)

  5. I only have a few switches and these are hardwired to the RPI, this means if the router, tablet,alexa, phone crashes I can not set fancy scenes, but I have lights and heating!

  6. Keep a list of separate apps that can control devices in case all above fails…

  7. Make sure no automatic updates happens! We dont want our system to crash because of software changes.

I also have physically pushbutton to reset services such as olad, python and so on, to avoid needing to reset the whole rpi when a service go down.

For automatic hvac control, roller curtain, door opening etc MQTT or http is just fine, because these are just nice to have features:)

Maybe @Kai or @ThomDietrich can collaborate on this, but it is very important to communicate out to the users what can happen in a smart home if somethings go wrong, and how we can make it fail-safe… Being able to run two RPI in parallel with some mux in between the ribbon Cables(or USB) might be worth considering)

In my case my RPI got new IP(in my router i can not set static IP, combined router/TV from our cable provider… ) and I needed to change this on all tablets and change the hue emulator IP.

1 Like
2

How do you plan to handle the dynamic IP address assignment? Isn’t it possible that will change on every RPi reboot? If I were forced to use a limited service provider router like yours (and I assume it’s a router/switch/WAP), I buy my own and network it to the provider’s router. I’d turn off the wireless access point (WAP) on the provider’s router (or just not use it) and use the WAP on my own router. From the provider’s router perspective, my personal router would be the only device.

As for running the RPi’s in parallel, do you mean in a fully redundant mode or do you mean master/slave with different functions? The latter can be done with the MQTT event bus binding. The challenge with the former is that you may need redundant hardware (for example, ZWave dongles, etc.) on each RPi.

3

Seems to be static, only changed when I got a new router(same device, but IP changed from 48 to 18)… I have installed a custom switch, however I need to move my PI around to be able to get Ethernet cables physically in it. No matter a switch might also break, hence in my opinion keep it running with minimum components needed for basic functions.

4

My idea was to use a mux so that the ribbon cable routed to one or the other RPI, dependenet on a postion of a mechanical switch. I will make a sketch later of ideal setup later.

5

It’s true that hardware devices can malfunction, but assuming that DHCP will provide the same IPs for a device without an address reservation is very questionable (at best) from a system design or reliability perspective.

When you say mux and ribbon cable are you assuming the device control is through GPIO versus other wired and wireless protocols that may need protocol-specific hardware?

6

Yes, All my main features are hardwired to RPI GPIO, so no matter if localhost or internet/router goes down/dies my basic functions still works, only problem is if my RPI dies… hence I would like a second one in backup eventually, which gives me time to fix one broken one while the other one is running OH.

If you can not do wired setup(like refurbushing an old flat, new built should always do wired in my opinion) then use RF instead of WIFI because this is more likely to stable(no need to reconfigure username etc, less power consumption)

7

Hello guys

This is a very funny article :slight_smile:
Let me share some experience from nearly 20 years providing high availability data center services :

  • use reliable hardware
    RPIs don’t meet this requirement. You can use it for your own, small installation.

  • place switches to all strategic places.

  • if possible, use wired, standard installation (Bus!)

  • have fallback scenarios

  • BACKUP REGULARY

  • Updates are necessary, but plan it.

  • Make a good good documentation and keep it a jour

  • actors and sensors should be quickly accessible for maintaining

  • use logging and monitoring

But of course each installation is different, and so feel free to pick out of what fits you or add points, which I may forget…

Greets, and Michael

4 Likes
8

Well, not wanting to pick on you… data-centres have come a long way; e.g. virtual networks, virtual servers, virtual services; IaaS, Silverblade, etc. which I find highly reliable and available, but an overkill for a domestic HA system.
Though, I agree, that an appropriate back-up strategy, fully tested and repeatable, is good advice.
There are a few good threads i this forum about this…

In general, I have thought long and hard about this topic; as I have chosen to not only augment traditional functionality, but replace it with OH altogether. E.g. no light switches → all controlled by OH.

Also, why would a rPi not meet the reliability criterion?
Burn in the hardware (backing oven) to MIL STD, and you’re good to go.

I agree with your point of documentation: I have comprehensive documentation on how to maintain, repair the system, with every component as spares on a shelf and catalogued. All devices which may need attention have a QR code, which points directly to a page in DokuWiki, which usually has a general description, specific description, linkages to other components of a system, tech specs, trouble shooting, and resource sections. – Not even half way through and have 85 pages :slight_smile:

There is even a spare computer with all the software to maintain the sytems, IDEs for loading code to the Arduinos, rPis, etc. incl documentation.

My wife is the tester :slight_smile: is she can’t fix it, my docu is not right. If she can, any professional in the respective field should be able to fix it.

Yes, quite a lot goes into making a reliable and more so highly available system.

I will eventually look at building a cluster with auto failover and redundant shared storage.

1 Like
9

I understand the pain of something not working when you (or the wife) needs it to.

I have gone to great lengths to try to make as much of my network fault tolerant as possible for HA stuff.

and part 2

I have a mysensors RF network setup and I am currently in the process of testing HA with that as well.

10

@Max_G

Don’t panic :slight_smile:

You are completly right. But the historie of datacenters show us the very basics.

With the focus set to a stable smart home system (Topic name) having
Spare devices, hardwireing to RPI you don’t achive this target. It’s a failback szenario
This is why I mentioned its not every time the right device.

I used an RPI in my old flat, which works fine. But many people are focused to this device because of its price.
If you try to build a system for non geeks like us (e.g. our parents) it’s may better to choose another device.

There are many more powerfull, reliable devices available (of corse with higher costs).

As next I tried to bring the focus on reliable standards:
Everything which is selfmade works for you, but for every other its getting harder and harder to take a look behind.
Calling a electrican in the middle of the night is expensive. And the price rises if he needs to read a documentation first…
Do you know, what I mean?

Greetings to your wife and my honest respect. My wife is an angel, when everythings works fine and takes me to hell if something don’t work as expected. This is why I recommend to place switches on strategic places for basic functions.

I thought long about this. And decided to start with a single installation on an industrial hardware, which is designed for 24/7 uptime.
If you going to built a cluster… you bring much more complexity and can’t eleminate all single point of failures. And you have your downtime for updates anyway :wink:

Greetings
Michael

11

A hardware question to you guys, can a gpio defined as output on RPI handle to get voltage in? See my simple sketch.

Screenshot_3.png918×547 127 KB

12

Good thinking.
All but a few of my lamps in my system are controlled by Rf433. If the network/RPi fails, there is the remote transmitter.
If that fails… there is a button on most of the remote switches.
My heating has an override button
I think I will be fine :slight_smile:

13

To be honest, I can’t really follow yr sketch, but generally it is not a good idea to put a voltage on a pin that is an output.
Suppose that voltage is 3.3V and your ‘Output’ goes LOW. that is basically shorting the voltage source and that voltage then needs to go somewhere.
Goes without saying that any voltage over 3.3V is lethal, no matter if output or input