Issue of the topic: rule “when item changed” is triggered when system restarts
I’m working with a SmartThings presence sensor Item using the SmartThings binding. The item.state changes from NULL to “not present” or “present” when the OpenHAB service starts. Which triggers the rule condition.
I tried using the syntax
when item.state changed from "this" to "that"
but it didn’t work.
Is there a way to detect when a restart has occurred? I saw some info about
when System started
which could be used to set a variable that all of the other rules could check if there had been a restart, but that feels like the path to spaghetti code.
How can I tell if Items are changing from Null to another value because of a restart?
Please post configurations (if applicable):
Items configuration related to the issue
Sitemap configuration related to the issue n/a
Rules code related to the issue
rule "Housemate01 Presence changed"
when
Item Housemate01_Presence changed
then
logInfo("SmartThings", "Housemate01_Presence : " + Housemate01_Presence.state)
if(Housemate01_Presence.state =="not present")
{
OfficeBot_Speak.sendCommand("Hello, I just noticed that Mariam has left the house.")
}
rule "Housemate01 Presence changed does not work"
when
// Item Housemate01_Presence changed
Item Housemate01_Presence.state changed from "present" to "not present"
then
logInfo("SmartThings", "Housemate01_Presence : " + Housemate01_Presence.state)
if(Housemate01_Presence.state =="not present")
{
OfficeBot_Speak.sendCommand("Hello, I just noticed that Mariam has left the house.")
}
Services configuration related to the issue
SmartThings Binding
If logs where generated please post these here using code fences:
of course you can filter for a NULL state with an if statement and changed instead of changed from yada to yada is good because it will always run even if, say there was a restart or whatever. I’m sure you’ve also heard of persistence to restore states after a restart but yes
when system started
can be a great opportunity to set items to a state that will be better then a NULL. If you think about how your rule works, a lot of times you can figure out a good starting point for an item’s value. Understand that at start up, a lot of stuff is happening all at once. Try to assign a value which is a common state for the item such as ON or OFF for a switch or 0 for a number. Don’t try to do any calculations or try to fetch another item’s state, jusy set it to a ‘native’ state.
don’t bother, just set things to a usable state or restore from persistence. You will learn to write rules which catch theses ‘edge’ cases
If you use restore-on-startup with persistence, this ought to complete before rules run - but it doesn’t always in some versions/configurations.
If you edit Items during running, they may get reset to NULL again.
That last factor means it is worth writing rules to deal with the NULL case during system development at least, saves frustration.
Then you did something wrong; it works in principle. You do have to get the correct syntax though, no guessing! no mention of .state in triggers.
when
Item Housemate01_Presence changed from "present" to "not present"
then
In the more general case, you may not know all the strings or numbers some Item may get changed to, so you cannot pre-complete all the from-to combinations.
You can have from without to, doesn’t help much here.
There isn’t a way to say “changed from not-NULL” either.
In the case of a changed rule trigger however, openHAB provides a useful implicit variable called previousState
In the body of the rule you can examine that to see if it is (was) NULL
when
Item Housemate01_Presence changed
then
if (previousState == NULL) {
logInfo( "test", "No idea if was home or not before")
} else {
...
