rossko57
(Rossko57)
March 31, 2019, 11:58am
6
That is correct. An Item is something in openHAB, It may or may not represent some device, or part of a device, or situation in the real world.
restore-on-startup is only intended to restore the state of the Item.
If you want to to take some action on a real world device, it’s up to you to do that.
Example rule
@rlkoshak
Okay… I just started with GPIO because for me that was the first “small step” that I could do without bringing too much complexity into learning OpenHAB. I thought: Do one small step, understand it, do next step.
Here some results of further testing:
I used this rule:
rule "Restore GPIO states"
when
System started
then
logInfo("startup.rules", "Executing »Restore GPIO states« rules")
Thread::sleep(1000)
DesktopLight_Switch.sendCommand(DesktopLight_Switch.previousSta…
Edit - this discussion is useful too
Continuing the discussion from Problem with previousState :
Hi,
I’m facing another situation with ‘.previousState()’.
The issue is with the TRADFRI lights, since they are initialized after persistence kicks in on system reboot.
I’m able to get this value from influxdb, but as @rlkoshak mentioned it is the same state as current once reload is finished. This is, of course, due to fact that state is changed from UNDF to “Current state” which triggers new persistence record to be added to DB.
It…