[SOLVED] Vision Door/Windows sensor zd2102 open/close and tamper are not triggered to different events

[B34N (Mark Bean)]

Progress!!! My door open/close now works! Thank you.

Yes, I had to redo my items file a bit after the change. Here is what I have now:

Contact SF_Emma_Entry_Sensor "Emma Entry [%s]" <door> (Test, SF_Emma, Door) {channel="zwave:device:cab10335:node29:sensor_door"}
Switch SF_Emma_Entry_Tamper "Emma Entry Tamper" <siren> (Test, Tamper) {channel="zwave:device:cab10335:node29:alarm_tamper"}
Switch SF_Emma_Entry_Alarm "Emma Entry Alarm [%s]" <switch> (Test, Alarm) {channel="zwave:device:cab10335:node29:alarm_entry"}
Number SF_Emma_Entry_Battery "Emma Entry Battery [%d %%]" <batterylevel> (Battery, Test) {channel="zwave:device:cab10335:node29:battery-level"}

While much less important, the switch alarm_entry does not send an update channel message.

When I remove the magnet I get:

2018-03-11 15:34:40.009 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 1D 03 20 01 FF 32 
==> /var/log/openhab2/events.log <==
2018-03-11 15:34:40.013 [vent.ItemStateChangedEvent] - zwave_serial_zstick_cab10335_serial_sof changed from 2324 to 2325
==> /var/log/openhab2/openhab.log <==
2018-03-11 15:34:40.021 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-03-11 15:34:40.025 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 1D 03 20 01 FF 32 
2018-03-11 15:34:40.028 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 1D 03 20 01 FF 32 
2018-03-11 15:34:40.031 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 1D 03 20 01 FF 
2018-03-11 15:34:40.039 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 29: Application Command Request (ALIVE:DETAILS)
2018-03-11 15:34:40.042 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 29: Incoming command class BASIC
2018-03-11 15:34:40.045 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 29: Received Basic Request
2018-03-11 15:34:40.048 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 29: Basic Set sent to the controller will be processed as Basic Report
2018-03-11 15:34:40.050 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 29: Basic report, value = 0xFF
2018-03-11 15:34:40.052 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2018-03-11 15:34:40.054 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-03-11 15:34:40.055 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2018-03-11 15:34:40.058 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Updating channel state zwave:device:cab10335:node29:sensor_door to OPEN [OpenClosedType]
==> /var/log/openhab2/events.log <==
2018-03-11 15:34:40.065 [vent.ItemStateChangedEvent] - SF_Emma_Entry_Sensor changed from CLOSED to OPEN
==> /var/log/openhab2/openhab.log <==
2018-03-11 15:34:40.061 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 27: Transaction not completed: node address inconsistent.  lastSent=27, incoming=255
2018-03-11 15:34:40.080 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 1D 0A 71 05 07 FF 00 FF 07 02 00 00 8A 
2018-03-11 15:34:40.083 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
==> /var/log/openhab2/events.log <==
2018-03-11 15:34:40.082 [vent.ItemStateChangedEvent] - zwave_serial_zstick_cab10335_serial_sof changed from 2325 to 2326
==> /var/log/openhab2/openhab.log <==
2018-03-11 15:34:40.085 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 1D 0A 71 05 07 FF 00 FF 07 02 00 00 8A 
2018-03-11 15:34:40.087 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 1D 0A 71 05 07 FF 00 FF 07 02 00 00 8A 
2018-03-11 15:34:40.090 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 1D 0A 71 05 07 FF 00 FF 07 02 00 00 
2018-03-11 15:34:40.091 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 29: Application Command Request (ALIVE:DETAILS)
2018-03-11 15:34:40.093 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 29: Incoming command class ALARM
2018-03-11 15:34:40.094 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 29: Received ALARM command V2
2018-03-11 15:34:40.095 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 29: Process NOTIFICATION_REPORT V2
2018-03-11 15:34:40.097 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 29: NOTIFICATION report - 7 = 255, event=2, status=255
2018-03-11 15:34:40.098 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 29: Alarm Type = BURGLAR (7)
2018-03-11 15:34:40.100 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2018-03-11 15:34:40.102 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-03-11 15:34:40.104 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2018-03-11 15:34:40.106 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-03-11 15:34:40.107 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 2, type OnOffType
2018-03-11 15:34:40.109 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-03-11 15:34:40.110 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 27: Transaction not completed: node address inconsistent.  lastSent=27, incoming=255

I see the Alarm Type BURGLAR but no update channel state afterwards.

Thank you,
B34N

[5iver (Scott Rushworth)]

It looks like you are not using the development binding with the changes Chris put in for handling Alarm V2. If you thought you were using the development binding, check with bundle:list | grep -i zwave. It’s could be possible you could have two versions installed, but the older version is running. Does alarm_tamper report anything?

[B34N (Mark Bean)]

@5iver I continue to appreciate your help. I eventually figured out that I needed to be in Karaf console to enter bundle:list | grep -i zwave so after I did openhab-cli console and used the standard password habopen I was able to issue the command and got back:

199 │ Active   │  80 │ 2.3.0.201803101457     │ ZWave Binding

I only spelled out the steps in case there are others who come across this thread and need help.

I thought I was on the development release but I learned that the snapshot that I’m on is different than the development. I’m using openhabian and openhab-cli console to do the updates.

Should I bother trying to figure out how to switch over to the development release or will those changes soon be on the snapshot release? I do use this openhab setup for our home and I need to maintain the WAF (wife acceptance factor) which has been really good so far.

Thank you,
B34N

[5iver (Scott Rushworth)]

@B34N

Should I bother trying to figure out how to switch over to the development release or will those changes soon be on the snapshot release?

You don’t need both channels, since they provide the same information, so I’d say wait. In fact, you’ll find sensor_door comes in just a tiny bit faster (you can see it in the log).

Just for reference though, the development version of the zwave binding is here…

OH2 Z-Wave refactoring and testing... and SECURITY

The latest version of the development binding dated 8th Sep 2018 is here. Toward the end of last year I spent some time doing some initial refactoring of the ZWave binding in OH2. This focussed on rewriting the way transactions work as this is an enabler for other areas of the code. At the same time I also restructured the different layers of the binding to make things cleaner, and done some changes to support a system of autocoding the command classes directly from the Z-Wave standard which s…

[Doc]

Was anyone able to get the WADWAZ-1 to work with the external contacts in OH2 ?

[5iver (Scott Rushworth)]

@Doc

Was anyone able to get the WADWAZ-1 to work with the external contacts in OH2 ?

Yes! I just updated the database with a new channel for the external switch. I’ve been testing it this weekend. If it works for the WADWAZ-1, then it should work for the other rebranded devices too. If someone would like to try it on one of those devices, just add the channel like in the WADWAZ-1 or I can do it for you.

[Doc]

I tried the binding dated 9th April 2018 from the security page with no luck. Are you using a different .jar binding ?

[5iver (Scott Rushworth)]

@Doc

Are you using a different .jar binding ?

Yes. The database was just updated, so you will need to wait for it to be exported, merged, and a build to be done. I was hoping Chris would have kicked this off today, but it shouldn’t be long! i finally have functioning leak sensors, and an alert to put salt in the water softener!

[Doc]

The 17th April 2018 binding has the updated support for the external contacts. It also appears that you can use it as a dual sensor now. No need to always have the magnet connected for the external contacts to work!

[HomeAutomation]

Just to be sure.

Now all 3 event can be triggered independent?

door open/close
binary switch open/close
alarm

Becasue I want to use door and binary for two different things. door as door and bianry as glas break event wit han external sensor connected.

[orc_trial]

I haven’t had much luck with this other than getting the open and close to work. I don’t think the battery worked as well for me nor did the tamper. If you can get all 4 channels to work, please post what you did

[HomeAutomation]

I’ve upgraded to OH 2.4 snapshot now.

Tamper is no longer working.

[chris (Chris Jackson)]

Please provide a debug log showing what is received, and also please be explicit with what device we are talking about as there are 3 x ZD2102 in the database from different manufacturers.

[HomeAutomation]

I have to vision one.

Only three channels are available:

My config. Note alarm_burglar was working with the old config of z-wave 2.2 binding. Now no longer there

Contact DoorSensor03				"working [MAP(de.map):%s]"	        {channel="zwave:device:xxx:node6:sensor_door"}
Number DoorSensor03_Battery  			"working not sure [%d %%]"  			{channel="zwave:device:xxx:node6:battery-level"}
Switch DoorSensor03_BurglerAlarm		"not working [%s]"			{channel="zwave:device:xxx:node6:alarm_burglar"}
Switch DoorSensor03_TamperAlarm			"not working [%s]"			{channel="zwave:device:xxx:node6:alarm_tamper"}

Logs:
tamper open and close - log.txt (21.2 KB)
binary sensor open and close - log.txt (10.5 KB)
door sensor open and close - log.txt (10.5 KB)

[HomeAutomation]

I delete and re-add the device and get this error:

2018-11-25 21:48:44.082 [hingStatusInfoChangedEvent] - 'zwave:device:15a7a49f3a6:node6' changed from ONLINE to UNINITIALIZED (HANDLER_INITIALIZING_ERROR): 1

2018-11-25 21:48:44.053 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.zwave.handler.ZWaveThingHandler@36b614': 1
java.lang.ArrayIndexOutOfBoundsException: 1
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialiseNode(ZWaveThingHandler.java:226) ~[?:?]
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.bridgeStatusChanged(ZWaveThingHandler.java:512) ~[?:?]
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialize(ZWaveThingHandler.java:164) ~[?:?]
        at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [101:org.eclipse.smarthome.core:0.10.0.201811171951]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [101:org.eclipse.smarthome.core:0.10.0.201811171951]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
2018-11-25 21:48:44.080 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'zwave:device:15a7a49f3a6:node6': 1
java.lang.ArrayIndexOutOfBoundsException: 1
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialiseNode(ZWaveThingHandler.java:226) ~[?:?]
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.bridgeStatusChanged(ZWaveThingHandler.java:512) ~[?:?]
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialize(ZWaveThingHandler.java:164) ~[?:?]
        at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [101:org.eclipse.smarthome.core:0.10.0.201811171951]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [101:org.eclipse.smarthome.core:0.10.0.201811171951]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

maybe this helps

[chris (Chris Jackson)]

@HomeAutomation

Only three channels are available:

How many channels should there be, and what are they?

[HomeAutomation]

I deleted the device and re-add it. Here is the log:

inclusion log.txt (79.2 KB)

[HomeAutomation]

I think it should be four:

door open/close
tamper
battery
binary switch (if this is really supported)

But a working tamper will be good. Works before as burglar but is no longer there.

[chris (Chris Jackson)]

@HomeAutomation

I think it should be four:

door open/close
tamper
battery
binary switch (if this is really supported)

Why four? What do they do? What is the binary switch? For most devices, there are multiple ways to send the same data (eg alarm, and binary sensor) - if you can confirm that there is an external input, or some other feature of this device, then we can add this, but I’m not sure that’s right is it?

[HomeAutomation]

Hello chris,

the device has this feature:
door sensor
external binary contact
battery level
tamper

There is another post here. The result of that oen is that the binary switch is hard to implement. Maybe we skip that implementation. But it will be good to get tamper back. (was buglar in earlier bindings). And it looks like there is a general problem with adding the device. See my last log.