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.
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.
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.
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?
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).
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.
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.
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.
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.
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
, 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.
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.
So I’ve been having this same problem and happy I found the thread recently. What actually seems to have been my problem was the (default?) 1500 ms “Command Poll Period” of the dimmers.
Command Poll Period - “Set the period to wait (in milliseconds) after a command is sent to a device before polling its state”
I changed my dimmers to 5000 (5 seconds) and I haven’t seen this occur again.
I only have a 2 level zwave topology, but perhaps there is even a short delay from when the OH server sends the “OFF” / “0” command and when the switch receives the command. The switch then starts slowing fade off, it receives a poll for status and responds with whatever the partial # is that it was at during the dim.
Mine are mostly GE branded Jasco switches, but this probably applies to all of the switches that are configured to slowly dim off vs just turn off. The dimming speed is a configurable setting on mine, but I like the slow fade.
