After discovery/re-start item state remains undefined until the item state changes

[m4rky-m4rk]

Hi,

After discovery an items state remains in the undefined state until the state is used in the real world, or switch via GUI, and the state is then toggled. e.g. switch turned to ON or OFF

Items left in the undefined state can cause some rules to fail to execute after discovery because the initial undefined state is not accounted for in the rule.

M

[mvalla]

The solution for this would be to request a status update each time a thing is initialized, which happens:

1. first time thing is added after discovery
2. each time thing is re-created, for example after openHAB restarts, after changing the thing parameters from .things file configuration, etc.

This would mean that each time new item is added or openhab restarted each light/dimmer will receive a ON/OFF notification, thus possibly triggering rules on the BUS if rules are set to be run each time ON/OFF state is notified. @m4rky-m4rk Could you comment on this behavior ?

[m4rky-m4rk]

I got around most of my issues with MapDB persistence and with the strategy restore on startup. That works for openhab restarts and I no longer use discovery as all my items are now in .items file. However, the problem would still be present for a completely new item but then I most likely have't created a rule for that until after the new item has been created.

Maybe its not really a limitation of the binding after all but just how Openhab works

[Gozilla01]

I also use Mapdb persistence, there are some things to watch out for: 1) during the rasberry reboot or gateway could change the status is persistence is not updated. On the web, app I will not be sure that I see the real situation, even some rules may not start. For me it's better to update the binding status *#1*0## *#2*0## *#9*0## After this improvement I think to disable persistence for Openwebnet. 2) Pay attention to the updating of the states part after persistence 3) During the insert new or updating of a items instead of updating all the states, send the request of the single status. Example *#1*23## status request WHERE = 23 *#2*96## WHERE status request = 96 *#9*7## status request WHERE = 7 4) I think that in the rules it is better to use Item <item> changed [from <state>] [to <state>] that Item <item> received command [<command>] this should avoid unwanted start rules, I still have to do some evidence.

[mvalla]

The last point 4. from @Gozilla01 is correct. However there are installations where rules and scenarios are present on the BTicino/BUS side and asking for state update means to activate the BTicino rule/scenario. Probably the best solution would be to make the user decide with some parameter on the Gateway Thing. Default will be no update at restart/new thing, but one can choose to change it and configure the gateway thing to ask for updates after a restart/new thing. Does it make sense?

[weltraumbagger]

as i work with "visibility" in sitemap like here it would be very usefull if the state would be updated at last for new items. for me it seems that on restart the last state is taken, but for new items i have wrong behaviour on sitemap

[mvalla]

I have done a detailed test, but with the current binding implementation (beta9-2) and OH-2.4.0 each time a thing is initialized for each channel connected to an item a "refresh status" is already called automatically by the framework.

So for example if I start from empty (no things/items), add a new gateway, then add one switch (status OFF) and one thermostat (mode OFF) from inbox, they are initialized correctly and each channel has the correct value. Then if I stop OH, change the switch status (ON) and the thermostat mode (Protection), and then start OH again, the channel values in paperUI are automatically updated to the new values (ON and Protection).

So basically I cannot reproduce the issue.

A debug-level log is needed here with only one thing/item configured (for example a switch), then the item is initially OFF (aslo on PaperUI), then OH2 is stopped, then while OH is down the switch is changed to ON on the physical device, then OH2 is started again and the log should show that the item/channel has an UNDEF/OFF state and is never updated to ON.

[weltraumbagger]

to have a minimal-configuration i removed all things and items, cleared the cache (after that the openwebnet 2.x binding was gone and i had to install again) then i added the gateway manually and one thing "bus_thermostat". for this thing i added the items i use. and the most items were updated correct. the only problems i see at the moment with items "heating" and "cooling". this items are not refreshed and sometimes show wrong states. even more: sometimes this switches are not read-only, they can be switched in paperui. i tried to change the item-name, then they were ok, when using the old name again problems. so it seems there is something wrong with earlier used item-names. and this was not to be solved by clearing the cache.

[mvalla]

for heating and cooling you have to check the correct actuator IDs are used. See this comment on README.

the channels are in fact readonly and the fact you can change their values is a problem of OH2/PaperUI. But let's not discuss further the heating/cooling channel here. Do some more test about this issue (using for example a dimmer or a switch/light), an if items are updated after restart/item added, I will close this issue.

[weltraumbagger]

this is what i did now: in openhab-app i switched several items on and others off, then stopped oh-service, then switched other items on or off, started service again and checked if the state will be updated correct. this i did for

• dimmers (ok)
• switches (ok)
• dry-contacts (ok)
• shutters: for shutters they will always be initialized as "open" no matter what was the last state. of course it is not possible to get the actual position. this is a bit problematic for me because my garage-door always is shown as "open" when i restart openhab. but there i will fix the problem with a rule that asks contact-state of the door so i cannot reproduce this issue

[mvalla]

based on the feedback received this issue is no longer valid.

Probably this was solved in OH2.4.0 where after a re-start or discovery (Thing initialize), a request to refresh each channel/item is send by OH itself.

For shutters it's a bit more complicated since of course the new position cannot be know until the shutters is 1) calibrated (shutterRun parameter) 2) goes to a full open/full close, so its position is correctly set to UNDEF after a re-start or when the shutter is just created.