Strange behavior of Z-Wave and dimmer items

dimmer
openhab2
z-wave
Tags: #<Tag:0x00007f51defa7210> #<Tag:0x00007f51defa7030> #<Tag:0x00007f51defa6ea0>

(davorf) #1

Hello!

I’ve upgraded OH2 to snapshot #906 few days ago, and after this upgrade, dimmers started to behave oddly. I haven’t changed items or rules files for at least 3 months and did last OH upgrade a month ago. The odd behavior manifests by setting dimmers to some (random) percent, after they’re turned off. For example, a light in the living room is turned on. After it’s turned off using dimmer/slider in the UI (or a wall switch), it turns the light bulb off, but then dimmer jumps to a random percent (light bulb doesn’t turn on, just UI dimmer representation of it). I wouldn’t even notice this, but I have LED strip connected to a kitchen light, so, when I turn a kitchen light on/off via wall switch, it turns a LED strip on/off using OH rule. Since it turns a UI dimmer off and then again on, LED strip turns on again (even thought light in the kitchen is off).

Anyone experienced similar behavior lately? I’ve tried upgrading to nightly #910 today, but it behaves the same.

Best regards,
Davor


Is there a way to extract and use binding from a back-up?
(houz) #2

I see similar issues. To me it feels like the slow dimming down of lights causes the dimmer to report some intermediate value via zwave which is then considered the latest setting. Similarly I can’t set a dimmer to 100% (or other precise values) with the sliders in Paper UI. Dragging it to the right will make it jump to slightly lower values while dimming up.


(davorf) #3

Hello!

It sounds like a different issue to me. Random dimmer value is displayed a few seconds after turning it off, and a wall switch shouldn’t slowly dim a light down, but set it to zero immediately. The same thing happens when lights are turned off via a rule (when Plex binding reports a Playing state), and, in this case, dimmer is set to 0 via rule, not dimmed down, but it still goes back to some random dimmer value after a few seconds.

Best regards,
Davor


(davorf) #4

Hello @chris !

Sorry for disturbing you, but I was wondering if there were any breaking changes in the latest z-wave binding that could cause this issue, or it’s strictly ESH/OH core related?

Best regards,
Davor


(Chris Jackson) #5

There have been very few changes in the ZWave master binding for quite a while - but you don’t say when you upgraded from (ie what version you were running before).


(davorf) #6

Hello @chris !

I was running nightly #856 (I think that build was from 29.03.2017). And I’ve tried nightly #906 and #910. They both behave the same.

Best regards,
Davor


(davorf) #7

Hello!

After a more thorough test, I’ve noticed that a wall switch definitely works OK (turning a wall switch off sets UI dimmer to 0, and it stays there). Issue surfaces when using UI dimmer (setting it to 0 manually - after a few seconds it jumps to a totally random value, but does not turn the light on). Issue also manifests itself when rules are used for a dimmer control (setting a dimmer to 0 via rule behaves the same as setting a dimmer to 0 via UI).

I’ve noticed there are a few settings in Z-Wave things that weren’t there before - Remove device from controller; Set device as FAILed; Reinitialize the device; Heal the device.

Any help regarding this would be greatly appreciated.

Best regards,
Davor


(Mark) #8

Are you seeing the behavior described here.

And here.


(davorf) #9

Hello!

This issue looks similar to a problem I’m having, but it surfaces when I’m turning lights, both, on and off. When turning it to 100%, it shows 100%, then some random value, but then jumps to 100% (which is, kinda, OK). But when turning it to 0%, it shows 0%, then jumps to a random value and stays there. This behavior causes issue, because I have some rules for connected LED strips that are depending on the dimmer level. I guess the only work-around would be restoring back-up on an older OH2 nightly I was using.

Thank you for your help.

Best regards,
Davor


(Mark) #10

Sounds very similar to me too. The exact behavior you see will depend on how the specific dimmer device responds to the poll for dimmer level that comes in immediately after the command to set a new dimmer level.

Another option would be for @chris to revert the above change to see if these issues go away.


(Chris Jackson) #11

These have always been there since the very first version of the OH2 binding. Maybe you didn’t notice them - they are only displayed in HABmin if you select advanced mode.

Yes - I agree that this is the likely culprit. This was merged I think just after the version that @davorf has last time. I will take a look at reverting for now.


(davorf) #12

Hello!

Any news regarding this issue, or should I revert to some older build?

Best regards,
Davor


(davorf) #13

Hello!

Is there any way I could install a new OH nightly, but use the old Z-Wave binding? I have tried installing an older version of OH nightly, but it obviously downloaded a new Z-Wave binding after install, so the problem persisted. I have a back-up of the OH nightly that worked correctly, but not sure how to use a Z-Wave binding it contains. I’ve tried overwriting files in

OpenHAB\userdata\tmp\mvn\org\openhab\binding\org.openhab.binding.zwave

, but after running OH, bundle:list still shows the newest Z-Wave binding (15.05.2017). I would like to avoid using this back-up as a complete replacement of the running version, because I would like to retain persisted data.

Best regards,
Davor


(Marty Christiansen) #14

These posts are a little old, but I was seeing some issues similar to this recently. I updated my zwave dimmer Thing and changed all of the “step” configuration values from 1 to 10. It’s probably just working around the underlying problem, but it worked for me.