Do it the right way - Rules, Persitence and Items

[Dibbler42 (Thomas Bail)]

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

[sihui]

For 1) see

System started trigger

I’ve changed to db4o. Persistence refresh order I have as follows: items, sitemap, persist, rules - I think it is default. Still I got same problem, it looks like it works when I just refresh some file, but it doesn’t when I ctrl+c script start script under Win or “service openhab restart” under Linux. As I understand data should be also recover after service restart, otherwise it makes no sense.

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

Force one rule to load first

Set up the mapdb persistence file per the Persistence wiki page and everything is done for you. Just be sure to use “restoreOnStartup” and “everyChange” strategy and only list your startup switch in the mapdb.persist file. In your rule all you need to do is startingSwitch.sendCommand(OFF) where startingSwitch is the one that the other rules check to determine whether they are allowed to run. Also, if the rules you are having problems with are not associated with your GPIO problems, you can add…

to setup persistence (mapdb is a good choice)

[rlkoshak (Rich Koshak)]

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.