Z-WAVE device being fired without being commanded

Setup, Configuration and Use Beginners
1

This may be more an issue with the z-wave protocol, but the other night I was playing with some siren groups. Fortrezz SSA-01 sirens which appear as a dimmer and only flash their LEDs when set to 20%. I turned the group on - everything worked as expected. I turned the group off - everything worked as expected. I then went to turn on my lamp installed on a GE lamp dimmer (#45602). The light turned on, but so did the siren. I quickly unplugged the siren as it was late (11PM). Logs show nothing was commanded by OpenHAB for the Siren, so it must be a problem with the z-wave protocol somewhere. Anyone ever see such behavior before?

Logs below show the behavior. Node 31 was the powered siren. Nodes 27 and 28 are other sirens not currently powered up. I restarted OpenHAB after this incident.

events.log:
2016-01-29 23:06:01 - gSirens received command 20
2016-01-29 23:06:01 - Siren1 received command 20
2016-01-29 23:06:01 - Siren2 received command 20
2016-01-29 23:06:01 - Siren3 received command 20
2016-01-29 23:06:01 - Siren1 state updated to 20
2016-01-29 23:06:01 - Siren2 state updated to 20
2016-01-29 23:06:01 - Siren3 state updated to 20
2016-01-29 23:06:05 - gSirens received command 0
2016-01-29 23:06:05 - Siren1 received command 0
2016-01-29 23:06:05 - Siren2 received command 0
2016-01-29 23:06:05 - Siren3 received command 0
2016-01-29 23:06:05 - Siren1 state updated to 0
2016-01-29 23:06:05 - Siren2 state updated to 0
2016-01-29 23:06:05 - Siren3 state updated to 0
2016-01-29 23:06:14 - Dimmer_Lamp received command 100
2016-01-29 23:06:14 - Dimmer_Lamp state updated to 100
2016-01-29 23:06:28 - Dimmer_Lamp received command 87
2016-01-29 23:06:28 - Dimmer_Lamp state updated to 87
2016-01-29 23:06:28 - Dimmer_Lamp received command 100
2016-01-29 23:06:28 - Dimmer_Lamp state updated to 100

Openhab.log:
2016-01-29 23:02:03.682 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 28: Node is DEAD. Dropping message.

2016-01-29 23:06:08.081 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 27: Node is DEAD. Dropping message.
2016-01-29 23:06:08.601 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 28: Node is DEAD. Dropping message.
2016-01-29 23:06:08.837 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 31: Got an error while sending data. Resending message.
2016-01-29 23:06:12.984 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 27: Node is DEAD. Dropping message.
2016-01-29 23:06:17.889 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 28: Node is DEAD. Dropping message.
2016-01-29 23:06:17.990 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 31: Got an error while sending data. Resending message.

2016-01-29 23:15:56.904 [INFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.8.0).
2016-01-29 23:15:57.312 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - mDNS service has been started
2016-01-29 23:15:57.377 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - Service Discovery initialization completed.

2

Looks like you might have your siren associated directly to your switch. Z-Wave supports direct associations, for the cases when you don’t have a hub or centralised controller. So you have associate a Z-Wave light switch with a Z-Wave motion sensor - when the sensor detects movement it will automatically switch on the light, and off again when the movement ends.

Typically openHAB users don’t use this feature however, as you control everything by rules. Check the configuration of your dimmer in Habmin and see if there are any associations other than the standard one back to the controller (i.e. Node 1).

3

Thanks for the response! Quicker than I expected.

The dimmer doesn’t support associations, and is why I’m wanting to ditch GE gear and go to Cooper (so I can run rules sooner than slow polling intervals).

Here are the only things defined regarding these devices, and nothing in habmin to configure (the siren has a single parameter of “Delay before accept of Basic Set Off” set to a default of 0)

items:
Group:Switch:OR(ON,OFF) gLights
Group:Dimmer gSirens "all sirens"
Dimmer Siren1 (gSirens) { zwave=“27:command=SWITCH_MULTILEVEL” }
Dimmer Siren2 (gSirens) { zwave=“28:command=SWITCH_MULTILEVEL” }
Dimmer Siren3 (gSirens) { zwave=“31:command=SWITCH_MULTILEVEL” }
Dimmer Dimmer_Lamp (gLights) { zwave=“26:command=SWITCH_MULTILEVEL,refresh_interval=30” }

sitemap:
Slider item=Dimmer_Lamp label="Lamp Dim [%s %%]"
Switch item=gSirens label=“Flash all sirens” mappings=[0=“OFF”, 20=“Strobe”]

No rules.

4

Could it be sending a broadcast message of some sort that the siren is picking up?

5

I recently got struck by something similar.
Craftsmen working my house caused an ‘earthquake’ (tamper alarm) on a motion sensor which then broadcasted ‘ALARM’. All of a sudden, half of all the lights all over my house started to blink.
Took me a couple of minutes to find out what happened. No siren, fortunately :smile: Turned out I had not paid attention to this part of the device config before, so they were still set to default values.
I suggest you increase zwave logging level to see zwave messages. Insert or edit a line in logback.xml saying
<logger name="org.openhab.binding.zwave" level="DEBUG" />

6

You can set different logging levels on different bindings? Interesting.

Added this specific one. Will have to see if/when it happens again. I have no idea how to reproduce. I assume it’s one of those things where everything needs to align just right to break.

I just don’t want to have a z-wave controlled garage door and have it randomly open from some bug.