Red switch not responding to zwave

Switches General Discussion
, , , ,
1

I just noticed an issue today with my red switch. It is not responding to any zwave commands. I tried turning it on and off remotely, as well as sending a value to the LED Strip effect parameter, but I get no response. My OZW_Log file shows that the request is timing out.

2019-10-29 17:49:45.036 Info, Node013, Value::Set - COMMAND_CLASS_SWITCH_BINARY - Switch - 0 - 1 - False
2019-10-29 17:49:45.036 Info, Node013, SwitchBinary::Set - Setting node 13 to Off
2019-10-29 17:49:45.036 Detail, Node013, Queuing (Send) SwitchBinaryCmd_Set (Node=13): 0x01, 0x0a, 0x00, 0x13, 0x0d, 0x03, 0x25, 0x01, 0x00, 0x25, 0x7c, 0x95
2019-10-29 17:49:45.036 Detail, Node013, Queuing (Send) SwitchBinaryCmd_Get (Node=13): 0x01, 0x09, 0x00, 0x13, 0x0d, 0x02, 0x25, 0x02, 0x25, 0x7d, 0x95
2019-10-29 17:49:45.037 Detail,
2019-10-29 17:49:45.037 Info, Node013, Sending (Send) message (Callback ID=0x7c, Expected Reply=0x13) - SwitchBinaryCmd_Set (Node=13): 0x01, 0x0a, 0x00, 0x13, 0x0d, 0x03, 0x25, 0x01, 0x00, 0x25, 0x7c, 0x95
2019-10-29 17:49:45.044 Detail, Node013, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2019-10-29 17:49:45.044 Detail, Node013, ZW_SEND_DATA delivered to Z-Wave stack
2019-10-29 17:49:45.087 Detail, Node013, Received: 0x01, 0x07, 0x00, 0x13, 0x7c, 0x00, 0x00, 0x05, 0x92
2019-10-29 17:49:45.087 Detail, Node013, ZW_SEND_DATA Request with callback ID 0x7c received (expected 0x7c)
2019-10-29 17:49:45.087 Info, Node013, Request RTT 50 Average Request RTT 68
2019-10-29 17:49:45.087 Detail, Expected callbackId was received
2019-10-29 17:49:45.087 Detail, Expected reply was received
2019-10-29 17:49:45.087 Detail, Message transaction complete
2019-10-29 17:49:45.087 Detail,
2019-10-29 17:49:45.087 Detail, Node013, Removing current message
2019-10-29 17:49:45.087 Detail,
2019-10-29 17:49:45.087 Info, Node013, Sending (Send) message (Callback ID=0x7d, Expected Reply=0x04) - SwitchBinaryCmd_Get (Node=13): 0x01, 0x09, 0x00, 0x13, 0x0d, 0x02, 0x25, 0x02, 0x25, 0x7d, 0x95
2019-10-29 17:49:45.095 Detail, Node013, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2019-10-29 17:49:45.095 Detail, Node013, ZW_SEND_DATA delivered to Z-Wave stack
2019-10-29 17:49:45.162 Detail, Node013, Received: 0x01, 0x07, 0x00, 0x13, 0x7d, 0x00, 0x00, 0x07, 0x91
2019-10-29 17:49:45.162 Detail, Node013, ZW_SEND_DATA Request with callback ID 0x7d received (expected 0x7d)
2019-10-29 17:49:45.162 Info, Node013, Request RTT 74 Average Request RTT 71
2019-10-29 17:49:45.162 Detail, Expected callbackId was received
2019-10-29 17:49:45.232 Detail, Node013, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x0d, 0x03, 0x22, 0x02, 0x00, 0xdc
2019-10-29 17:49:45.233 Detail,
2019-10-29 17:49:45.233 Info, Node013, Response RTT 145 Average Response RTT 170
2019-10-29 17:49:55.088 Error, Node013, ERROR: Dropping command, expected response not received after 1 attempt(s)
2019-10-29 17:49:55.088 Detail, Node013, Removing current message
2019-10-29 17:49:55.088 Detail, Node013, Notification: Notification - TimeOut

My other zwave devices appear to be working normally (I only have 1 red switch at the moment). I tried associating a battery-operated zwave switch with the red switch, and I am unable to control it that way either. Local control works fine. I can turn the light on and off manually without issue. The Red switch sends status messages back to the controller with out issue as well (if I manually turn the light on or off, I receive status updates). Scenes are also working properly. Its almost as if the transmitter is working fine, but the receiver is frozen.

I restarted OpenZwave (running zwave2mqtt in a docker container), but it had no effect.

I am fairly confident that pulling the air-gap to cut the power will resolve the problem, but before I do that, is there anything else I should test?

2

@EricM_Inovelli – can you check this out?

3

Hi @jtronicus, are you just running open-zwave or are you using it with Home Assistant or something else? It almost seems like “Rf Protection” was activated which is not too hard to find in Home Assistant.

4

I am using zwave2mqtt (which uses open-zwave)

image
image.png1228Ă—800 76.5 KB

You may be on to something with the Rf Protection (although I am unable to find a setting with that exact name). I was messing around with the “Protection” setting last night, trying to determine if this setting is responsible for disabling the internal relay (same as config button x8). I found that pressing config x8 will toggle this setting between “Unprotected” and “Protection by Sequence”. Setting this config option via zwave appeared to have the same result, but maybe there is more to it. This setting was set to “Unprotected” while I was having issues.

Protection (13-117-1-0)

Value Apparent function
Unprotected All features unlocked
Protection by Sequence Internal relay disabled, but scenes and remote operation still works
No Operation Possible Internal relay disabled AND scenes/remote operation disabled. Pressing config x8 also does nothing

I dont see any option to disable remote operation but still keep the relay enabled.

I did some additional testing, and managed to get it working without cutting power to the switch. I found that although I couldnt turn the switch on and off remotely, I was able to remotely change the Protection value from Unprotected to Protected by Sequence. Once I changed it back to Unprotected (again remotely), the switch started working again.

I will continue to keep an eye on it, and will report back here if I run into this issue again.

5

Ah, yeah, seems like protection was enabled. I’ve tested setting local and rf protection via z-wave command and it works well, but I haven’t tested it with open-zwave so maybe something funky happened there. With the protection command class there are two types and they each have 3 levels.

image
image.png978Ă—403 126 KB

image
image.png946Ă—291 77 KB

8x tap on the config button toggles local protection between 0 & 1. The local & rf command to change the setting (via z-wave) are in the same packet to the device. It is possible that open-zwave sent the wrong values which sounds like it might have happened.

6

Interestingly enough - one of my red switches is having same symptoms starting this morning - it is on and I couldn’t turn it off either physically or through ST Classic app. 8x tap of Config button had no effect

7

ST Dev Console is showing switch as inactive.

8

I think you are right. It is likely something to do with open-zwave. I can see on the z-wave alliance page that this switch supports Command Class Protection V2. However, in my open-zwave config file, it is listed as version 1:

		<CommandClass id="117" name="COMMAND_CLASS_PROTECTION" version="1" request_flags="4" innif="true">
			<Instance index="1" />
			<Value type="list" genre="system" instance="1" index="0" label="Protection" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
				<Item label="Unprotected" value="0" />
				<Item label="Protection by Sequence" value="1" />
				<Item label="No Operation Possible" value="2" />
			</Value>
		</CommandClass>

I dont even have an option to change the RF protection state. Since I am not knowledge enough to update open-zwave myself, and everything is currently working as it should, I am just going to leave this setting alone until an updated version of open-zwave is released for the docker image I am using.

Thanks for your help!

1 Like
9

This sounds like a slightly different issue from what I was experiencing. Im my case, the physical buttons were working just fine. It was only the remote control that was not working.

Is the issue you are experiencing more like the symptoms in this post?

10

yeah, more like that, right - switching the breaker helped

11

Hey just wanted to throw this out there, but you can pull the air-gap (little button at the bottom left) instead of flipping the breaker if this happens again.

I saw your post in the other thread and will respond there in regards to the freezing!

12

I’m having same problem with one of my switches now (the one that was completely freezing before). Physical buttons will turn it on and off but none of the automations won’t work and I cannot control it from ST. Flipping the air gap won’t solve the problem
Load: bathroom fan. I had another bathroom with exactly same fan and switch and never had a problem with it.
In ST IDE:
Status INACTIVE

  • networkSecurityLevel: ZWAVE_S0_DOWNGRADE
    Last Activity At 2019-11-09 10:56 AM PST (2 days ago)
13

I had this problem as well. I have to factory reset the switch by holding config for 20 seconds. It fixed it but had to be reincluded. I also noticed that when this happened inclusion and exclusion would not work until I reset the switch. Air gap did nothing except fix local control.

14

Resurrecting this old thread because I managed to break things again, but this time with a Red Dimmer.

I am currently unable to change any parameters or control the dimmer via zwave. I can still control the switch locally, and I receive status updates from the dimmer. The only thing I seem to be able to do remotely is change the Protection Status.

I suspect I somehow managed to change the RF Protection status. The problem is, I dont have an option for RF Protection in OpenZwave
image

Do any of you using Home Assistant or OpenZwave have separate options for Local Protection vs RF Protection? If so, would you be willing to send me the information from your zwcfg_*.xml or ozwcache_*.xml file so I can see how it should be set up?

15

So it’s been over a year here, but I ended up here with the same issue others have been having. I couldn’t find any solution out there, and the OpenZwave config files are still broken it seems.

I tossed this into mine and it seems to work (tho I haven’t tested disabling RF control, as I don’t want to have to factory reset my dimmers):

<CommandClass id="117">
      <Value type="list" genre="config" index="0" label="Local Protection" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
        <Item label="Unprotected" value="0" />
        <Item label="Protection by Sequence" value="1" />
        <Item label="No Operation Possible" value="2" />
      </Value>
      <Value type="list" genre="config" index="1" label="RF Protection" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
        <Item label="Unprotected" value="0" />
        <Item label="Protection by Sequence" value="1" />
        <Item label="No Operation Possible" value="2" />
      </Value>
  </CommandClass>

Maybe someone at Inovelli could take a look, clean it up and bit and submit a PR over on OpenZwave to get this updated for everyone? Currently the .xml on OpenZwave entirely lacks id 117. Which from what I can figure out causes stuff like Zwave2MQTT to fill it in with a very basic default, which seems to result in it using Protection Command Class, version 1 instead of version 2. The result of this is that anyone changing the setting ends up sending the wrong version and it disables RF control, causing all sorts of issues as it doesn’t appear to set it back properly when selecting “Unprotected”.

16

I tried this at one point in the past, and unfortunately it doesnt work. Since OZW only supports Command Class Protection v1, it sends the same command regardless of which setting you choose.

However, @Eric_Inovelli, I think I found a firmware bug that is causing the problem.

Protection Status before sending any Protection commands:
image

Sending Command Class Protection v1 with value 0x00 (Unprotected):
image
image

Everything looks fine:
image

Sending Sending Command Class Protection v1 with value 0x00 again:
image

Now the report shows that RF protection has been set to NOP:
image

I think this might be a firmware bug with the way the switch handles v1 of this command class. Hubs that do not support v2 (such as Home Assistant) are likely to run into this issue if setting protection via zwave.

17

Ah, yep. I can confirm that OpenZwave does indeed seem to bug out exactly like described here when sending repeated messages.

18

Let’s tag @EricM_Inovelli.

19

I have confirmed this on firmware 1.09, but it isn’t happening for me on firmware 1.21. Which firmware version are you guys using?

Edit: nm, I was able to get it to do this on 1.21 as well. I’ll do some more digging and let you know what I find.

20

The Red Series dimmer is affected too