Rule Example Wasp in Box

Tutorials & Examples Solutions
4

I’ve altered this rule on my system because I’ve learned a few things and I am going to update the first post to reflect the changes but use this post to discuss the changes so as to not clutter the example.

First change is to the system start up rule. Here is a thread I’ve started to discuss this issue. What I am beginning to realize is that the practice of using what I am now calling ‘unbound’ items, in other words, an item which is not linked to a binding and used instead to hold a value requires these values to be set at system start or bad things can happen.

I have used unbound items since before I even attempted writing rules but I recently questioned the practice until I stumbled across this design pattern by Rich promoting the technique. Since eventually a cron rule or some other process was setting these items to a value, I hadn’t noticed this problem sooner. (beginner’s luck)

So on to the first fix. The original system start up rule was almost an after thought in this example. What I originally did was simply make a guess using the time of day and day of week. Not only did this not work very well because of how things work during start up, I now believe this went against the whole principle of how the algorithm is supposed to work. Here is the original system start up rule

rule "initializeSys"
when
    System started
then
	// initialize wasp in box value from null
	// if M-F 9-5 off & otherwise on
	var dayofweeknum = DayOfWeek.state as Number
	if(dayofweeknum < 6 && now.getHourOfDay() >= 09 && now.getHourOfDay() < 17){
		WaspInBox.postUpdate(OFF)
	} else { WaspInBox.postUpdate(ON) }
	// post update only so wasp in box is not null 
end

The first step is to understand that at system start up, rules files are loading and the persistence system is restoring values that are set to restoreOnStartup at the same time. At this time the system is very busy and operating under heavy load. There are no guarantees of the rules files loading or item values being restored in any particular order. This is how OpenHAB works and may change in some future version but for now it is best to work with how the system works.
Rich suggests using MapDB for restoring item state using restoreOnStartup because MapDB is an embedded database running within OpenHAB. This means is should run a little quicker and encounter less problems

The second problem I had with this rule is that if the system restarts, we really don’t know the status of the wasp, the box is effectively open. Rather then guess, I decided to set the wasp as gone. I looked at the rest of the rules and made further changes to ensure the rule would ‘self correct’. In other words, if the system restarts, and the Wasp is mark as ‘out’ but then motion is detected, the rules will automatically switch the wasp to ‘in the box’.

So in the end, the strategy I choose for the system started rule is to simply set the unbound items to values which indicate that the box has opened and wasp presence is unknown.

rule "initializeSys"
when
    System started
then
	// initialize wasp in box unbouund item values from null
	WaspInBox.postUpdate(OFF)
	WaspConf.postUpdate(0)
	boxTimer.postUpdate(OFF)
	lastBoxBuzz.sendCommand(new DateTimeType(now.toString))
	lastBoxOpen.sendCommand(new DateTimeType(now.toString))
end

I’ve chosen to use postUpdate so this rule merely sets the values so they are not NULL. It causes no other effect. I also choose to use ways of setting the values with out requiring items to be initialized. The two switches are set to OFF and the number item set to zero. The two DateTime items I use the now command, setting the lastBoxBuzz first so it will be older (indicating non-presence )