Do it the right way - Rules, Persitence and Items

Hi there,

my system evolved over the last one and a half years with openHAB. I changed things read about design patterns, learned about groups and what i really nedd in homeautomation and it goes on and on and on. Getting more into the things i am looking for some design rules.

1.) How to design the system start. Persistence, rule etc are startet in no predictable order. How should it be handled that items are inialised before using them, giving them a default value etc.

2.) What should be tried and catched are there any standard things?

Thanks
Thomas

For 1) see


to control the sequence of loading the different files.

Or you may use System started triggers, there are many examples here in the forum.

For 2) see


to setup persistence (mapdb is a good choice)

To answer from a philosophical perspective:

  1. Design it to be flexible. By this I mean make it so as little as possible cares at all about the order things start up in. I achieve this by using MapDB with restoreOnStartup on EVERYTHING (see the Design Pattern’s thread for my persistence setup) and setting the polling periods for the various file types so the rules files do not get loaded until after my items and persist files. In OH 1 there are some options that start with “file” which let you set the polling period near the top of openhab.cfg. Just set the polling period for rules to a value larger than items and persist (the number is in seconds). With these two things I guarantee all my Items have a value on startup and no rule executes before Items can be initialized.

  2. There are two approaches you can take. When you encounter an exception in the logs caused by one of your rules, add a try/catch to that rule. The other is to add a try and catch(Throwable t) in every rule. This will cause you to catch everything and potentially deal with it (e.g. log out a more useful error message). No exception will get ignored this way, but frankly it is likely overkill in most cases.

I use a combo of the two. Mainly I’ll add a try/catch where I have to (see below) and I’ll add more when I’m debugging a rule and once the rule works I’ll usually leave the try/catch in there until I get around to refactoring.

You will be forced to catch InterruptedException when using Thread::sleep in certain contexts (e.g. lambdas). It is always a good idea to try/catch/finally when using reentrantLocks with the unlock taking place in the finally block so no matter what happens the lock is released.