I thought it was the sonoff doing this, but when OH2 restarts and comes up, its triggering sonoff relay via MQTT and opening my garage door!
Why I dont know but this is really really stressing me out as Ive dogs that have just got out. Luckily I have a tradesman at home who locked them inside.
My relays have poweronstate 0, and with the wifi, if it looses that it doesnt trigger the relay either so this is definitely related to OH2 as it only does it when the server is reset.
How can I absolutely ensure that OH2 does NOT trigger my sonoff relays.
You should probably tell us how openHAB normally operates the relays. I guess you have Item(s) linked to Sonoff in some way, switches perhaps?
What do you see in events log for these Items? Maybe the rules that control them are triggered by other Items establishing themselves. Which ones are subject to restore on startup, which ones read or calculate new values after system boot?
there are no rules involved but here is the log at startup
2019-03-12 12:01:38.677 [vent.ItemStateChangedEvent] - Gate_full changed from NULL to OFF
2019-03-12 12:01:44.136 [ome.event.ItemCommandEvent] - Item 'Gate_full' received command ON
2019-03-12 12:01:44.256 [vent.ItemStateChangedEvent] - Gate_full changed from OFF to ON
2019-03-12 12:01:45.167 [vent.ItemStateChangedEvent] - Gate_full changed from ON to OFF
That didnāt come from nowhere. Itās a full six seconds after a presumed status from the real device. It comes from a rule, or a UI, or a linkage to some binding, or possibly something external sending REST
Iāve not heard of any of the UIs spontaneously generating commands, say in response to a flood of start-up changes.
Itās worth using REST API to search your things for mention of Item name - few bindings will generate commands, but some do.
IMHO this rule is run on every startup since the item LivingRoom_Zrc_Remote will get an update on systemstart.
I guess you have all Items with the strategy ārestoreonstartupā, that way the LivingRoom_Zrc_Remote will be reset to the last value before shot down. In your case the last state was probably 8!
Add a change to a state that has no effect ( 0 ?) at the end of the rule, that way the rule will do no harm after a restart.
Yes, that is correct.
If you want to be sure that such was the case and the issue is solved by the line in the code you could add at least one logInfo line in the rule in order to know if the rule is run.
Something like this after the 2var int sceneNumberā¦" - line.
logInfo ("Remotec ZRC-90 - Fridge", "Started!")
In the log you will have a line each time the rule is run.
Having exorcised your ghost, it is perhaps worth now spending a little time considering why you would want to persist and restore absolutely everything.
Especially for Pi/SSD users, it generates unwanted overheads.
Restoring some sensor states is counterproductive. No good being reassured by openHAB that all doors are closed when in fact it has no idea yet.
Persisting a remote button press is a different case - but do you care what the button last pressed before reboot was?
Itās sometimes implemented as a lazy way to avoid Items being NULL or UNDEF in rules. It all depends, but rules can be rewritten to deal sensibly with āmissingā values and that may be more desirable than using old stale values.
Quite often thereās a bonus effect from that effort that will bring graceful responses to in-flight failures.
Thatās a decision best made early in rules development. Iāve very few persisted/restored Items, and am fed up with typing if (myItem.state != NULL && myItem.state !=UNDEF)
but I bet I get less surprises
Changes can be quite subtle sometimes, !=ON is not the same as ==OFF for example.
Just food for thought.
Thatās probably a good idea - once the button event is dealt with, clear it away.
switch-case also has a default: option, by the by,
This is a familiar prob for me to. I solved it by changing the relays to be high not low active. I donāt use sonoff for them, but do use mqtt.
If your mqtt server is on the same unit as OH try using mqtt persitance when publishing. I canāt remember how of the top of my head.
The most important part of my garage setup is the open close switches, which tells OH the state of the door, and a rule to indicate an open door.
It is usually not necessary to restore all Items since there is a good chance that they are no longer accurate (switches may have been toggled, sensor values are likely to have changed), and the restoration may result in unwanted rule actions. Rules can be coded to detect UNDEF or NULL and behave appropriately. The * can be used for all Items if desired.
ā¦
I will propose this change if you think it is good.
Can probably simplify a bit. The doc describes * earlier on, so we neednāt do it again. And rule tweaking is out of scope - we could just say
It is usually not necessary to restore all Items since there is a good chance that they are no longer accurate (switches may have been toggled, sensor values are likely to have changed), and the restoration may result in unwanted rule actions.
There is actually an earlier line to fix up for OH2 as well
When restarting your openHAB installation you may find there are times when your logs indicate some Items have the state, UNDEF
should now be
When restarting your openHAB installation you may find there are times when your logs indicate some Items have the state, NULL