[SOLVED] openHAB 2.4 Z-Wave Dimmers update issue

Tags: #<Tag:0x00007f2fc040ed30>

Hi All,
Tried searching for this but couldn’t find it so apologies in advance if it has already been answered. I tried upgrading to 2.4 but noticed the following problems with dimmers in the Z-Wave binding. I did following when updating.

  1. Removed all Z-wave devices
  2. Removed binding
  3. Updated to openHAB 2.4
  4. reinstalled binding
  5. Searched and added all things again.
  6. Linked items to channels using PaperUI (also tried Habmin)

Other info:

  • Platform information:
    • Hardware: Raspberry Pi 3
    • openHAB version: 2.4

What happens is that I can turn off the device using the UI but it remains on even though the device itself is off. So far I have seen it only happen to dimmers. It looks like the dimmer is getting a value of 49 (always 49 no matter what dimmer), even though the physical device is off.

Here’s what I have as one example:

Item

Switch Entryway "Entryway Light" (gWakeup,gWatchTV, gBed, gLights) {channel="zwave:device:b776346d:node12:switch_dimmer"}
Dimmer Entryway_Dimmer "Entryway Light"  ["Lighting"]{channel="zwave:device:b776346d:node12:switch_dimmer"}

Sitemap

Switch item=Entryway label="Entryway"
Slider item=Entryway_Dimmer label=".....Dimmer" visibility=[Entryway==ON]

Log

2018-12-20 15:02:28.317 [ome.event.ItemCommandEvent] - Item 'Entryway' received command OFF
2018-12-20 15:02:28.328 [nt.ItemStatePredictedEvent] - Entryway predicted to become OFF
2018-12-20 15:02:28.353 [vent.ItemStateChangedEvent] - Entryway changed from ON to OFF
2018-12-20 15:02:29.906 [vent.ItemStateChangedEvent] - Entryway_Dimmer changed from 100 to 49
2018-12-20 15:02:29.922 [vent.ItemStateChangedEvent] - Entryway changed from OFF to ON

Any ideas? Thanks in advance,

I had the same issue. You need to change your channels to switch_binary1 (with the 1 at the end) or switch_dimmer1

The binding changed which caused this. If you open PaperUI and inspect the Channels on your respective ZWave device you’ll see this. Update your items file with the 1 at the end of the channels and things will work.

Took me a while to! Another ‘BREAKING CHANGE’ not mentioned anywhere.

So should I change the switch to switch_binary1 and then the dimmer to switch_dimmer1 ? Or both the same?

Thanks for your help!

Show us a screenshot of the PaperUI channels for your item and I can tell you Adam

Ahh. Different issue it seems as your channel name appears correct

I’ve been having an issue with my GE dimmers for a while - at least since 2.3 where it will send the “current” dim level instantly (although never 0 or 100 it seems) before changing so the binding reports it wrong initially until it catches up in a minute or so when it polls the dimmer. At least I am assuming it’s the dimmer sending to the binding improperly. Perhaps you are seeing similar behavior?

For example:
Dimmer is off, I tap it on and the binding sets the item to dim level, say, 23 even though the dimmer now is physically on.

Dimmer is on and I tap it off, the binding sets the item level to, say, 92 even though the dimmer is now physically off.

I haven’t seen that or this behavior prior to 2.4. 2.3 everything seemed fine. What I also noticed is that if I press OFF twice in the UI it will reflect the status. I don’t know why when I hit off it goes to 49, and then again to 0. Also there are two different items here. Don’t know why the _dimmer item is getting stuck as it is.

 Item 'Entryway' received command OFF
2018-12-20 18:13:37.952 [nt.ItemStatePredictedEvent] - Entryway predicted to become OFF
2018-12-20 18:13:37.987 [vent.ItemStateChangedEvent] - Entryway changed from ON to OFF
2018-12-20 18:13:39.565 [vent.ItemStateChangedEvent] - Entryway_Dimmer changed from 100 to 49
2018-12-20 18:13:39.571 [vent.ItemStateChangedEvent] - Entryway changed from OFF to ON
2018-12-20 18:13:46.692 [ome.event.ItemCommandEvent] - Item 'Entryway' received command OFF
2018-12-20 18:13:46.702 [nt.ItemStatePredictedEvent] - Entryway predicted to become OFF
2018-12-20 18:13:46.712 [vent.ItemStateChangedEvent] - Entryway changed from ON to OFF
2018-12-20 18:13:48.301 [vent.ItemStateChangedEvent] - Entryway_Dimmer changed from 49 to 0

Hi All,

I am seeing the same issue after upgrading from 2.3 to 2.4 tonight. It seems like openhab is updating with an intermediate value while the dimmer is ramping to it’s final setting, and then is not updating once the dimmer actually reaches its final state. I see it happening when turning the dimmer off or on as well as when changing the set point. It seems to happen any time the setting is changed by more than approximately 50% on my setup.

Thanks

Switch and Dimmer itemtype needs to be both linked to the switch_dimmer1 channel.

Switch FibFGD212_1_Sw  { channel="zwave:device:uzb:node37:switch_dimmer1" }
Dimmer FibFGD212_1_Dim  { channel="zwave:device:uzb:node37:switch_dimmer1" }

As a general rule, you should not use the switch_binary channels - just use the dimmer channels. The binary switch channels may be removed in future where there is already a dimmer channel…

Hi Chris,

Items updated to using switch_dimmer1 and still seeing same results. Physical device is off but the dimmer status jumps by 50 so the switch returns to on. Can be adjusted with a rule but that seems unnecessary.

Any ideas on this?

Thanks,

Switch Entryway "Entryway Light" (gWakeup,gWatchTV, gBed, gLights) {channel="zwave:device:b776346d:node12:switch_dimmer1"}
Dimmer Entryway_Dimmer "Entryway Light"  ["Lighting"]{channel="zwave:device:b776346d:node12:switch_dimmer1"}

You might want to look at the “Command Poll Period”. This is an adjustable time after the command is sent after which the binding will check the status of the device. If the device updates slowly, then this could cause this and you might want to extend the interval.

That seemed to work. Changed from 1500 to 3000 and seems to work correctly now.

Thank you!

1 Like