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
In your MQTT configuration, do you have retain=true set?
I had the same problem with my MySensors devices all toggling when the server reset, and it turned out to be all the retained messages on the MQTT broker being sent to OpenHab when it connected, causing all kind of weird behaviour (A/C turned on, false motion triggers, etc.)
I solved it by setting retain=false in the config file, and then I had to delete Mosquitto’s retained state database as described here: Clearing MQTT retained messages