Item state not correctly updating after ItemCommand 'ON'

[QNimbus (Bas)]

Short screencast to better illustrate issue:

• https://www.useloom.com/share/e94e42984eaf47c793796169130b12b9

My config:

• OpenHAB 2.3.0 inside a docker container (RancherOS host OS)
• Zwave binding version 2.3.0

Hello community (and chris-jackson),

Recently I started using the Google Home Assistant to control some of my OpenHAB/ZWave devices. Using this integration exposed a problem that I hadn’t previously encountered before since I hardly ever post ItemUpdate or ItemCommand ON to my Zwave appliances.

When using a Dimmer item and sending it the ItemCommand 'ON' it will switch on the actual dimmer and it will go to it’s previous dim level (i.e. 45%). This is known behavior of the Fibaro dimmers I use. This also works when I manually switch on the dimmer using my wall contact switch (connected to Fibaro dimmer).

When I POST ItemCommand 'ON' to the dimmer item using the REST API (simulating what Google Home does when I ‘tell’ it to switch on my kitchen table lights), it correctly switches on my lights but the state in OpenHAB always incorrectly shows ‘100’ instead of the actual dim level (‘45’ in this case). Only manually ‘REFRESH’-ing the Item gets the correct item state. For clarification see the screencast in the top of my post)

Is this an issue with the ZWave binding? Should it poll/query the item for a state update after having received the ‘ON’ command?

I see several users reporting that adding autoupdate=false should fix this problem.

{channel=“zwave:device:controller:node8:switch_dimmer”, autoupdate=“false”}

However, when I add autoupdate=false to my item definition it will just leave the dimmer item state to ‘0’ after having switched on the lights using ItemCommand 'ON'. So this does not resolve the issue of not correctly updating that state - it just leaves the state at ‘0’ when the dimmer has been switched ‘ON’ even though that actually dimmer switches on to it’s previous state.

Short event log snippet for kitchen table lights:

ItemStateChangedEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights changed from 0 to 55
ItemCommandEvent - Item ‘GF_Kitchen_Dimmer_KitchenTableSpotlights’ received command 35
ItemStateEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights updated to 35
ItemStateChangedEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights changed from 55 to 35
ItemCommandEvent - Item ‘GF_Kitchen_Dimmer_KitchenTableSpotlights’ received command OFF
ItemStateEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights updated to OFF
ItemStateChangedEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights changed from 35 to 0
ItemCommandEvent - Item ‘GF_Kitchen_Dimmer_KitchenTableSpotlights’ received command ON
ItemStateEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights updated to ON
ItemStateChangedEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights changed from 0 to 100

Update 1:

A workaround for this issue to is create a rule that automatically sends ItemCommand 'REFRESH' after having received ItemCommand 'ON'. This is of course just that, a workaround. I would love to see this working straight out of the ZWave binding.

This issue seems related to:

• Z-Wave dimmer “restore last value” setting
• Dimmer Group not showing the right Value in BasicUI

Update 2:

After having updated to a more recent version of OpenHAB and the ZWave binding (2.4.0M6 to be precise) this issue was resolved.

[rossko57]

Begin by looking in events.log to see what openHAB thinks happens, then you can separate function issues from display issues

[QNimbus (Bas)]

@rossko57

Begin by looking in events.log to see what openHAB thinks happens, then you can separate function issues from display issues

As you can see in the event log snippet bellow, the binding sends ‘ItemStateChangedEvent’ from 0 to 100. (Which is obviously incorrect, it should have been ‘35’ in this case)

12:03:45.746 ItemStateChangedEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights changed from 0 to 55
12:03:51.982 ItemCommandEvent - Item ‘GF_Kitchen_Dimmer_KitchenTableSpotlights’ received command 35
12:03:51.983 ItemStateEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights updated to 35
12:03:51.985 ItemStateChangedEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights changed from 55 to 35
12:03:57.576 ItemCommandEvent - Item ‘GF_Kitchen_Dimmer_KitchenTableSpotlights’ received command OFF
12:03:57.578 ItemStateEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights updated to OFF
12:03:57.579 ItemStateChangedEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights changed from 35 to 0
12:04:03.321 ItemCommandEvent - Item ‘GF_Kitchen_Dimmer_KitchenTableSpotlights’ received command ON
12:04:03.322 ItemStateEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights updated to ON
12:04:03.322 ItemStateChangedEvent - GF_Kitchen_Dimmer_KitchenTableSpotlights changed from 0 to 100

[Branden_Smale]

Instead of turning it ON, try using numerical values. On and off are 0 and 100…this may not solve the issue, but it’s worth a shot.

[QNimbus (Bas)]

@Branden_Smale

Instead of turning it ON, try using numerical values. On and off are 0 and 100…this may not solve the issue, but it’s worth a shot.

I know that using numeric values will circumvent this issue.

Aside from the fact that ‘ON’ should work and correctly update to the actual state of the dimmer, the Google Home integration sends ‘ON’ and ‘OFF’ to the items when receiving a spoken command like ‘Kitchen table lights on/off’.

I noticed this issue first after starting to use the Google Home integration - I was then able to reliably reproduce the problem in OpenHAB using the REST API (and had a friend test the same scenario on his OpenHAB instance). This seems a problem with the ZWave binding that needs to be resolved if I’m not mistaken.

I updated my original post showing another working workaround - you would have to trigger in item REFRESH everytime the item receives ItemCommand 'ON'. Of course this is not a very nice workaround and ideally the ZWave binding would properly refresh item states instead of having to rely on extra DSL Rules.

[5iver (Scott Rushworth)]

Command polling was introduced somewhat recently in the zwave binding. This will poll the device after every command. Your issue may be resolved by an upgrade.

[QNimbus (Bas)]

@5iver

Command polling was introduced somewhat recently in the zwave binding. This will poll the device after every command. Your issue may be resolved by an upgrade.

Thanks for your reply - do you happen to know how recent this change was made? I’m using the fairly recent 2.3.0. zwave binding.

[5iver (Scott Rushworth)]

I believe it was back in August. So M3 or newer should do (I’d stay away from M7 though… and the current snapshots still look to have the same issues). Be aware this will include…

ZWave binding updates

I have now merged the development version of the ZWave binding into master, so it will be available in the 2.4 snapshot version. If you are using the ZWave binding, please read this post as the binding contains some breaking changes so you will need to manually update your configuration. Firstly though - the major enhancements (there are tons more smaller updates) -: Security has been added using the S0 security class. This should allow all devices supporting security to be included into the…

[QNimbus (Bas)]

@5iver

I believe it was back in August. So M3 or newer should do (I’d stay away from M7 though… and the current snapshots still look to have the same issues). Be aware this will include…

ZWave binding updates

Thanks Scott,

I will try to update/upgrade my OpenHAB version to M6 and see if that resolves this issue - I will keep everyone watching this thread posted. (also for future reference for myself )

[chris (Chris Jackson)]

@5iver

Command polling was introduced somewhat recently in the zwave binding.

For most channels, this was always in the binding - what changed is I made the time between the command and poll a configurable parameter.

@QNimbus

I’m using the fairly recent 2.3.0. zwave binding.

Note that there is no such thing as a “fairly recent 2.3 binding”. 2.3 was released in May I think, so it’s 6 or 7 months old now.

[QNimbus (Bas)]

@chris

@5iver

Command polling was introduced somewhat recently in the zwave binding.

For most channels, this was always in the binding - what changed is I made the time between the command and poll a configurable parameter.

@QNimbus

I’m using the fairly recent 2.3.0. zwave binding.

Note that there is no such thing as a “fairly recent 2.3 binding”. 2.3 was released in May I think, so it’s 6 or 7 months old now.

With regard to the configurable time between command and poll - how is this configured? On the binding itself? Or using a parameter in the item/thing definition?

With regards to ‘fairly recent’, I just meant to say that (in my opinion) the 2.3.0. binding that I’m using is still fairly recent (and by no means outdated). I had some problems a while ago when I ran the 2.4.0 M4 release of OpenHAB (forgot exactly what unfortunately) and reverted to 2.3.0. stable and had no issues since. This is why I’m still on the 2.3.0. version and not one of the milestone releases.

Having said that, I will now try to install milestone 6 (M6) and see if I can get everything to work, including the issue I was raising in this post/thread.

@chris Thanks for taking the time to reply to this thread - is this issue I’m raising something that seems familiar or have you run into this as well? And is it possibly solved by running a newer milestone release?

[chris (Chris Jackson)]

@QNimbus

With regard to the configurable time between command and poll - how is this configured?

It’s a configuration option on each thing - not the binding.

@QNimbus

the 2.3.0. binding that I’m using is still fairly recent (and by no means outdated).

That’s fine - it’s not outdated, but it’s certainly quite old now, and doesn’t contain any new features for well over a year (likely a lot more).

@QNimbus

is this issue I’m raising something that seems familiar or have you run into this as well?

I don’t think what you report in the first message is a binding issue. The binding should send the command (which I guess it does) and the system should update the item state. That said, as @5iver points out, the repoll feature will likely also solve this by refreshing the data shortly after the command is sent, so updating to 2.4 should solve the issue.