Dev system, testing and backup

Hi guys,

I’m finally getting to a stage with my OH setup where the basics are running ok and I’ve realised that just trying new stuff on my one and only live system isn’t the best way to go most of the time so I’m done ‘playing’ with OH and want the get organised.

So, how do you all deal with testing new stuff. Do you have a second pi / OS for testing and one for live, how do you transfer testing across to live, how / what do you backup?

I’ve currently got a pi with openhabian 2.4 on, I’m waiting for the milestone 2.5 to come out before upgrading on the live system but would also like to have a test system that I can upgrade to the snapshots to test and help the community etc.

I’m seriously looking into putting OH on a docker on my synology to give me this flexibility but still in two minds the best way to do it.

Any thoughts)?

My primary system is now on a Hyper-V VM so I can use my Pi as a Testing system.
I usually test rules, etc. with no Item binding but I am fortunate enough to have an extra Z-Wave stick if I need to use that.

My productive system is running on an Intel NUC, whereas my development and test environments are all ESXi VM’s. Only thing I cannot test is my Zwave network.

1 Like

I assume because you only have one Z-Wave controller? I was fortunate enough to get a free sample to test with OH. I was then told I could keep it.

Indeed, that’s the reason, but never was in need to do tests on my Zwave network. It is just for my smoke detectors which are up and running without any issues.

1 Like

I too have a VMWare ESXI Server with an productive instance and a test instance.
And I have 2 Z-Wave sticks, one for productive use and a backup in case it burns down… I use that backup for testing new stuff (I recommend that highly as Z-Wave Network can get clunky if you have items in your network that are not configured proberly).

Oh, and I have maintenance day (wednesday), in cooperation with my wife :slight_smile: I don’t touch the productive systems besides those days. I play around in the test system only, and then document… and then use documentation on Wednesdays to install on P.

1 Like

As a bachelor I can do testing with my live system. :laughing:

But beside what everybody else is mentioning (VM, Docker, etc.) I would encourage you to use the text files for configuration and use git to document and organize your changes.
This would also allow you to simply transfer your tested configuration to your production system.

But one issue with a separate openhab testing system is that some binding establish a connection to a devioce/hub that cannot be connected by a second system (like our openhab-test-system).
So it might not be possible to have two separate openhab systems where everything is working simultaneously.

2 Likes

Honestly, I’m lazy. I just have the one system (VM running on ESXi with OH running in Docker). I just make sure to create a backup before making any significant changes. But I can get away with this because my home automation is more “ambient”. When OH goes offline, you wouldn’t necessarily notice unless you were to try to do something through OH or something that usually happens automatically like the lights fail to go on. I go for automation more than control and there is always a manual way to do anything so if something goes wrong, it’s not a big deal and I’m not under the gun to fix it.

One of the challenges of running multiple instances is you can’t share the hardware (e.g. zwave controller) so the amount of and thoroughness of the testing that can be performed is a little limited.

I do run in Docker and there have been occasions where I’ve upgraded to a snapshot that breaks things. So then I just roll back. And if there is ever as significant a change as there was between OH 1 and OH 2, I’ll probably run two containers on the same machine but only one at a time. I’ll shut down the OH 2 instance, start up the OH 3 instance, do my work, then close down and start the old one.

But, like I said, I can get away with this because I push as much of the “smarts” to the end devices, in the failure case I still retain a way to control everything manually, and I don’t really use OH UIs directly to control the automation, it just does it. YMMV.

I’ll second the use of git, but you can use git with the JSONDB too so you are not strictly limited to the text config files. All of my Things are automatically discovered or created through the REST API and I have a fairly usable history of all the changes to my Things in git. It’s not perfect as sometimes they get saved out of order but in my experience that happens pretty rarely and my history is pretty clean.

I have a couple of motion sensor / light combinations with timers. Not sure how to make them less OH dependent. Z-Wave Association Groups could work except for keeping the light on for a time of inactivity.

My Home fully depends on OH, I don’t even have a way to turn of certain things without openhab. But I had several issues so far, all of them were resolved quickly thanks to VM’s that I backup every night to my NAS.