iam trying to get the persistence working on my OH 4 installation.
My aim is, that every item is restored to its last state, either caused by the raspberry to be restarted or for example if the power control plug is in state ON and is then plugged out of the socket, then after inserting the plug again in the socket i want the item to get the last state it had. The same for lightbulbs and so on. So in short: If a item state changes from offline to online i want to get it its last value by using the persistance service.
Currently i have installed the mapdb binding and created a mapdb.persist file under: /etc/openhab/persistence/ where i entered as sudo user the following code:
In the openhab configuration i set the mapdb binding to be used as the default persistence binding and uninstalled the rrd4j binding since for me only the last value is required and no overhead due to dbs like influx or else is required.
If i plug a lightbulb that is in state ON out of its bulb socket, wait a minute and then reinstall it in the socket, its state is OFF and therefore the persistance procedure is not working. I have no idea what to do further, can someone please help me?
Without knowing your bulb type and binding you use, it seem that after reinserting it, openHAB queries the state from the bulb and therefore the item shows OFF.
Your persistence settings are defined to store the state on every update, but restore state from persistence is only done when openHAB is started. It does not mean to restore when a device is readded/reinserted.
This smells like an XY Problem and indicates some confusion about how OH works.
Item’s don’t have an ONLINE/OFFLINE state, Things do. Persistence works on Items so there will never be a case where an Item changes it’s state to OFFLINE or ONLINE and therefore nothing for Persistence to trigger on to restore the state.
What a Thing does to the Item’s state when the Thing goes OFFLINE likely depends on the binding. Some will possibly update the Item to UNDEF or NULL while others will simply leave the Item’s state alone. As far as I’m aware, all of the bindings I use follow the latter behavior and leave the Item’s state as is.
In the latter case, the Item won’t change state unless you update or try to command it from OH in the first place. And if you command it, the Item will only change state if you have Autoupdate enabled, which is the default.
But what’s the actual state of the device? Is the bulb in fact OFF? Shouldn’t OH reflect the actual state of the device instead of overriding it from persistence and ending up with the state in OH not matching the actual state of the device?
I wonder if there is confusion between commands and states. Changing the state of an Item is internal to OH. Updating the state of an Item from OFF to ON does not turn on the lightbulb.
With restoreOnStartup, the Item states are updated.
The only way to actually turn on the light bulb from OH is to send a command to the Item. A command doesn’t change the state of the Item on it’s own. Either autoupdate changes the state or, in the ideal case, the binding waits for the device to actually change to ON and then updates the Item’s state.
Are you really trying to turn the lightbulb back on when it comes back ONLINE? If so, you’ll need a rule that triggers on the Thing’s state changes and in the rule sendCommand to the Light with the last saved state. Persistence isn’t going to do this for you on it’s own.
The bulb type is this Ikea Tradfri. A ok i did not know that there are specific events for readded or reinserted and to be honest i do not find infos in the docu, can you please let me know the strategy string that i have to insert to let the item states be updated on readded/reinserted (which physically means openhab thing state changes from offline to online or?).
The problem is, that the bulbs states if one inserts them is always on. This is not good.
ah okay thanks for the explanation. With your explanation in mind i would now redefine what i want to realize. My physical lightbulb (i use this on here ) that is connected via zigbee2mqtt using the binding is “connected” to OH as a generic mqtt thing. The problem i have is, if the lighbulbs physical state is off and i plug it out of the socket and reinstall it, the lamp always gets on. This is a problem for me.
Me thinking now is, if i plug out the physical bulb i would expect that the corresponding OH thing changes its state to something like offline or? I then would like OH to recognize if the things state changes from offline to online back which should trigger sending a “OFF” command to the corresponding items that control the state of the bulp so that i can be shure that the bulps physical state will be set to OFF if there were e.g. a person who turned off the phyiscal wall switch instead of using my smart home switches.
How can i realize this? Creating a rule for every thing to be triggered of the state changes? Seems to be a lot of rules.
This is even trickier. Does zigbee2mqtt actually send a message when the bulb is unplugged? Is the MQTT Generic Thing configured to go OFFLINE when that message is sent? If not, how is OH supposed to even know if the lightbulb was unplugged in the first place?
Since it’s a Generic MQTT Thing you don’t get this for free. It will only go OFFLINE if you set the Thing up to do so. Otherwise, so long as the Bridge Thing is ONLINE all it’s Things will remain ONLINE.
Assuming you can get the Thing to go OFFLINE/ONLINE in the first place create a Rule that triggers on the Thing’s status changes and when it changes to ONLINE and command the Item.
Most of us have long since determined that messing with smart bulbs is nothing but pain. They all behave differently when power is restored. You’ve made things even more challenging in that you are one step removed from the bulb and have to rely on zigbee2mqtt to tell you if the lightbulb went offline (assuming it can do so). But even if you used the Zigbee or Hue binding, it often takes quite some time before the binding will mark a Thing as OFFLINE.
But all is not lost. If you can get the Things to change ONLINE/OFFLINE, you could use Thing Status Reporting [3.2.0;3.4.9] and in the rule that it calls do a mapping between the Thing and the Item to send the command to.
Outside of that, if you do not get some sort of way to tell when the lightbulb goes offline and returns back online there is nothing you can do. Most people who use light bulbs disable their light switches (or put up little signs to not turn them off). That way the bulbs always keep power.
For my setup as an example I have a dimmable Philips Hue model 9290024691a smart bulb that is connected via the Openhab ZigBee binding it is in a lamp if I unplug the lamp Openhab does not show the bulb item state change. Nor however, the bulb thing does not change to offline immediately either. If I plug it back in the bulb goes on and then since the bulbs was off based on Openhab it was goes on and Openhab updates its state to on as the bulb has now sent a event to the ZigBee controller that the bulb has now turned on to 100% level. If the bulb was on 100% already and I unplug it and plug it back it still comes on and the Openhab thing still shows it is online and the item value reflects 100% as the bulb still sends an event to the zigbee controller saying the bulb is on but Openhab does not indicate a change its indication because it already has the item value at 100%. now if I had the bulb on at say 41% and unplug it then plug it back in then then bulb comes on at 100% same as if it was off when the bulb sends its event to the Zigbee controller it updates that the bulb level is 100% and then Openhab updates the item state to 100%. As folks have said all these bulbs can behave differently. If I have a ZigBee smart plug like a Sengled and unplug it when it is in on state and plug it back in it will return to on. but if I had it in a off state and unplug it then plug it back in it will return to off state in all cases the Openhab will reflect what every state that item is currently in not what it was previous to my unexpected removal of power from the device. The ZigBee device things likely will not show offline until the next mesh update period.