Dimmer lights show as 'on' even when turned off

Configuration
1

I’ve got some dimmer switches (Jasco Products 12724). If I turn them off manually or via HA, they will turn off. But the status of the switch shows them as still on, just dimmed.

I am guessing they are getting polled in the process of getting turned off?

I have tried sending config parameters to get them to turn off faster, but that doesn’t seem to have any affect.

2

You need to specify refresh_value & delay. E.g., in my zwave_device_config.yaml file I have:

light.master_bedroom_lamp:
  refresh_value: true
  delay: 4

This is for a GE/Jasco Z-Wave Plus plug-in dimmer. For an older (just Z-Wave, not Z-Wave Plus) GE/Jasco dimmer I also have polling enabled:

light.family_room_lamp:
  refresh_value: true
  delay: 4
  polling_intensity: 1

And, for completeness, in my main configuration.yaml file:

zwave:
  polling_interval: 10000
  device_config: !include zwave_device_config.yaml
3

Thanks! I’ll try that as soon as I figure out how to put in a z-wave configuration file with hass.io.

4

Can’t help you with that.

5

This has been working reliably for me now. Thanks for taking the time to answer.

1 Like
6

Does anyone have a solution that works with the new openzwave (beta) integration ? (i.e. the mqtt based one)

7

With the new beta you need to add

  <CommandClass id="38">
    <Compatibility>
      <VerifyChanged index="0">true</VerifyChanged>
    </Compatibility>
  </CommandClass>

to the manufacture config files. If you’re running the add-on, it will be impossible to do this.

2 Likes
8

If you send me a list of devices that need it, I’ll add it to the upstream config files

9

I think it’s a band aide. @freshcoast knows the details. I guess we are waiting on a fix that has been in the works for some time.

10

Its the only band aide available for dimmers that support MultiLevelSwitch CC Version 3 or less, and BinarySwitch CC Version 1

The problem is the specifications in these versions did not say if the value returned should be the “instant” value, or the final value. Each Vendor did what they wanted and hence we have some devices that “work” and some that exhibit this behavior.

That config block forces OZW to ask a 2nd (or 3rd or 4th…) time for the value and doesn’t publish it to the application till the last 2 values retrieved from the device match (ie, have the same value).

The issue that @freshcoast reports is if you have a very long duration value for a dimmer. OZW will ask in quick succession for values, and its possible that 2 consecutive values come back the same. I will look incorporating the “duration” value into this check and delay the consecutive gets so its more likely we don’t run into that situation.

In Version 4 of MultiLevelSwitch CC and Version 2 of Binary Switch - the devices now send a “instant” value, and a “target” value - I’ve explained how this works to the integration team and asked them to use the Target Value instead of “level” but I’m not sure how many devices in reality are out there currently that meets this criteria.

11

I added that to the following files:

/ge/14294-dimmer.xml
/ge/12724-dimmer.xml

  <CommandClass id="38">
    <Compatibility>
      <VerifyChanged index="0">true</VerifyChanged>
    </Compatibility>
  </CommandClass>**
12

This is awesome! Thank you Petro and Fishwaldo for your great work! Indeed i was arriving at that conclusion based on the similar report here:

Thanks for incorporating into upstream.

Indeed I’m running this as an add-on in Hassio. I wonder if I could just SSH into the host, bash into the add on container and edit the config XML files directly there similarly to what this PR seems to do ? https://github.com/OpenZWave/open-zwave/pull/2272/files

13

I am seeing this with a Lutron Caseta HA integration as well. Checking the status it reports brightness as “0” and “on”.

14

If you restart the container it should grab the latest config files for you and automatically refresh

15

So please test the VerifiedChanges flag posted above and let us know if it works. I wont add it till someone confirms they see success after testing.

16

So, i did try adding the above change to:

/ge/14294-dimmer.xml
/ge/12724-dimmer.xml

which are effectively my devices and restart the container. It didn’t appear to work - which is odd given above description.

Is it possible i need to rediscover the devices ? Any logs i can look at to confirm the option is actually taking effect ?

I’ll try to debug some more later today once i have more time outside of regular work hours (PST timezone).

17

You need to refresh the node after adding that param. In mqtt explorer (assuming you only have 1 zwave network):

OpenZWave/1/command/refreshnodeinfo/

with

{
  "node": 14
}

change the node to whatever you need it to be

18

I suspect my verifychange xml change is not kicking in for whatever reason. Even after the refreshnodeinfo i still see the response yielding (“ChangeVerified”: false, looks suspicious):

{
“Label”: “Level”,
“Value”: 0,
“Units”: “”,
“ValueSet”: true,
“ValuePolled”: false,
“ChangeVerified”: false,
“Min”: 0,
“Max”: 255,
“Type”: “Byte”,
“Instance”: 1,
“CommandClass”: “COMMAND_CLASS_SWITCH_MULTILEVEL”,
“Index”: 0,
“Node”: 10,
“Genre”: “User”,
“Help”: “The Current Level of the Device”,
“ValueIDKey”: 172589073,
“ReadOnly”: false,
“WriteOnly”: false,
“Event”: “valueChanged”,
“TimeStamp”: 1593186220
}

19

Actually, i take it back. The problem was the topic name should be:
OpenZWave/1/command/refreshnodeinfo/

Rather than
/OpenZWave/1/command/refreshnodeinfo/

(heading slash). Waiting for it to complete refreshing…

20

Yeah i was going off memory. Removed the / from my post.