Z Wave Trouble getting Vision ZD2102 Door and ZG8101 Garage sensors to report

brononius · July 23, 2016, 5:43pm

What’s the best way to see what version I’m running right now?
I think that I’m running already 1.8.3.

brononius@habirus:~$ ll /usr/share/openhab/addons/
totaal 7084
drwxr-xr-x 2 root root    4096 mei 25 11:29 ./
drwxr-xr-x 7 root root    4096 mei 25 09:03 ../
-rw-r--r-- 1 root root    7329 mei 14 16:28 org.openhab.action.astro-1.8.2.jar
-rw-r--r-- 1 root root   12239 mei 22 21:29 org.openhab.action.pushover-1.8.3.jar
-rw-r--r-- 1 root root  455601 mei 22 21:30 org.openhab.binding.asterisk-1.8.3.jar
-rw-r--r-- 1 root root   80985 mei 22 21:29 org.openhab.binding.astro-1.8.3.jar
-rw-r--r-- 1 root root   52119 mei 22 21:30 org.openhab.binding.dsmr-1.8.3.jar
-rw-r--r-- 1 root root   63850 mei 22 21:30 org.openhab.binding.exec-1.8.3.jar
-rw-r--r-- 1 root root   19566 mei 22 21:30 org.openhab.binding.http-1.8.3.jar
-rw-r--r-- 1 root root   29084 mei 22 21:30 org.openhab.binding.hue-1.8.3.jar
-rw-r--r-- 1 root root  430030 mei 22 21:29 org.openhab.binding.knx-1.8.3.jar
-rw-r--r-- 1 root root   29376 mei 22 21:31 org.openhab.binding.mqtt-1.8.3.jar
-rw-r--r-- 1 root root   15901 mei 22 21:31 org.openhab.binding.mqttitude-1.8.3.jar
-rw-r--r-- 1 root root   52533 mei 22 21:31 org.openhab.binding.netatmo-1.8.3.jar
-rw-r--r-- 1 root root   10714 mei 22 21:30 org.openhab.binding.networkhealth-1.8.3.jar
-rw-r--r-- 1 root root 1604725 mei 22 21:35 org.openhab.binding.plex-1.8.3.jar
-rw-r--r-- 1 root root 1132549 mei 22 21:30 org.openhab.binding.sonos-1.8.3.jar
-rw-r--r-- 1 root root    8272 mei 22 21:30 org.openhab.binding.wol-1.8.3.jar
-rw-r--r-- 1 root root 1237582 mei 22 21:31 org.openhab.binding.zwave-1.8.3.jar
-rw-r--r-- 1 root root 1134175 mei 10 18:02 org.openhab.io.habmin-1.7.0-SNAPSHOT.jar
-rw-r--r-- 1 root root  832951 mei 22 21:37 org.openhab.persistence.mysql-1.8.3.jar
-rw-r--r-- 1 root root     126 mei 22 21:44 README

sihui · July 23, 2016, 8:25pm

At least your bindings are almost all on version 1.8.3. To find out which runtime version you are running, take a look into your openhab.log: first line is:
openHAB runtime has been started (v1.x.x).

This means Chris suggests to update the zwave binding from 1.8.3 to the latest cloudbees version version 1.9.0.
Download the cloudbees zwave binding here, delete the org.openhab.binding.zwave-1.8.3.jar and copy the 1.9.0 to your addons folder.
Then restart openhab and see what happens …

brononius · July 24, 2016, 9:14am

After checking the log, I can confirm that openhab is the 1.8.3

Yesterday evening, I’ve also upgraded the zwave binding to 1.9.0-SNAPSHOT from cloudbees. And I must say, at first sight, the zwave devices (fe relays) seem to repsond faster. Before, it could take a second of 3, and now, it’s reacting right away. I had to reboot the whole server because I was getting an error “Network Monitor: Queue length is 5 - deferring network monitor functions”. And after the reboot, it all works fine.

But after 13 hours, the garage sensor was still not associated in a group.
So a few minutes ago, I’ve excluded and included the sensor once more. But no luck, when I hit the push button on the sensor, it starts sending a lot of data towards openhab. But when I open/close the garage door, nothing is being send. I guess this has still something to do with the association?
You can find the debug here 20160724005110. The new id of the node is now 41.

If you guys think on anything else that I can do/try/…

chris · July 24, 2016, 10:17am

I’m not sure why it’s not being set automatically - the database looks like it should set this.

Set it manually.

chris · July 24, 2016, 10:45am

Ok - so the reason it’s not setting automatically is I was only looking at the ZD2102 and not the ZG8101 which is what you have. This isn’t configured to set automatically - so that solves the mystery .

chris · July 24, 2016, 10:51am

And for the record…

brononius · July 25, 2016, 7:08am

One step closer to the solution…

After upgrade the zwave binding with last night build, the sensor is associated in the group.
I just needed to reinclude the sensor in order to get it right. But it’s in.

Not sure where to look next, at the devices itselves, or at openhab (zwave). But when I open/close the garage door, no info is getting in the logs. Like the device isn’t doing anything. The debug log can be found at 20160725000109.txt. The node ID’s are now 42 and 43.

chris · July 25, 2016, 8:15am

Why do you need to re-include it? This should not be necessary.

brononius · July 25, 2016, 9:06am

When I pushed the (tamper?) switch, a lot of info was exchanged, but still no association. I’ve even rebooted the server, and waited for about 3 hours…

I’ve then excluded and included it, and afterwards, pushed the switch, and then it was fine.
Not sure if it was really needed, but at least it’s a member now.

Just a pitty that the sensor doesn’t say if the garage door is up or down (yet)…
After all, this is the goal…

chris · July 25, 2016, 9:22am

What do you mean by this? Do you mean the association wasn’t configured? This should be done as part of the initalisation - there’s an option in HABmin (I think in HABmin 1 as well) to reinitialise the device. Otherwise, delete the XML and restart the binding. Re-including will not help in any way.

sihui · July 25, 2016, 11:22am

Maybe there is some confusion about what “associations” means:
Read this wiki:

In short: you may setup association groups if you don’t want the controller to control other devices, but you want the ZG8101 device itself to control other devices directly → from reading your posts I guess that is not want you want.
You must setup one association group, that is the group “Controller updates”, this one must be member of the controller, normally node 1. This is needed to update the zwave controller with the correct states (= f.e. contact open or closed).
Maybe there is something wrong with your item setup, you should post it here if you can’t get it to work.

brononius · July 25, 2016, 4:33pm

Now, after the latest zwave binding update, it’s been associated into a group (see printscree). This is the first time it joined it.Not sure if it should be in anything else?

chris · July 25, 2016, 4:35pm

Great news .

Well, this is the only group that the device supports, so I don’t think so

brononius · July 25, 2016, 4:43pm

Just strange to me that no data is been send by the sensor if the door opens / close. You would except to see something in the logs. Even if the items are wrongly configured, no?

Every hour, some info is been send, but nothing when the door changes…

2016-07-25 15:54:45.421 [DEBUG] [ApplicationCommandMessageClass:40  ]- NODE 42: Application Command Request (ALIVE:DONE)
2016-07-25 15:54:45.421 [DEBUG] [ApplicationCommandMessageClass:58  ]- NODE 42: Incoming command class WAKE_UP
2016-07-25 15:54:45.422 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:140 ]- NODE 42: Received Wake Up Request
2016-07-25 15:54:45.422 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:199 ]- NODE 42: Received WAKE_UP_NOTIFICATION
2016-07-25 15:54:45.422 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:449 ]- NODE 42: Is awake with 0 messages in the wake-up queue.
2016-07-25 15:54:46.422 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:544 ]- NODE 42: No more messages, go back to sleep
2016-07-25 15:54:46.422 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:218 ]- NODE 42: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
2016-07-25 15:54:46.422 [DEBUG] [o.b.z.i.protocol.SerialMessage:113 ]- NODE 42: Creating empty message of class = SendData (0x13), type = Request (0x00)
2016-07-25 15:54:46.423 [DEBUG] [WaveController$ZWaveSendThread:1301]- NODE 42: Sending REQUEST Message = 01 09 00 13 2A 02 84 08 25 D0 B4 
2016-07-25 15:54:46.440 [DEBUG] [b.z.i.p.s.SendDataMessageClass:38  ]- NODE 42: Sent Data successfully placed on stack.
2016-07-25 15:54:46.455 [DEBUG] [b.z.i.p.s.SendDataMessageClass:73  ]- NODE 42: SendData Request. CallBack ID = 208, Status = Transmission complete and ACK received(0)
2016-07-25 15:54:46.455 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:409 ]- NODE 42: Went to sleep
2016-07-25 15:54:46.455 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:472 ]- NODE 42: Is sleeping
2016-07-25 15:54:46.455 [DEBUG] [WaveController$ZWaveSendThread:1364]- NODE 42: Response processed after 32ms/5606ms.
2016-07-25 16:55:03.368 [DEBUG] [ApplicationCommandMessageClass:40  ]- NODE 42: Application Command Request (ALIVE:DONE)
2016-07-25 16:55:03.368 [DEBUG] [ApplicationCommandMessageClass:58  ]- NODE 42: Incoming command class WAKE_UP
2016-07-25 16:55:03.368 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:140 ]- NODE 42: Received Wake Up Request
2016-07-25 16:55:03.368 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:199 ]- NODE 42: Received WAKE_UP_NOTIFICATION
2016-07-25 16:55:03.368 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:449 ]- NODE 42: Is awake with 0 messages in the wake-up queue.
2016-07-25 16:55:04.368 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:544 ]- NODE 42: No more messages, go back to sleep
2016-07-25 16:55:04.369 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:218 ]- NODE 42: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
2016-07-25 16:55:04.369 [DEBUG] [o.b.z.i.protocol.SerialMessage:113 ]- NODE 42: Creating empty message of class = SendData (0x13), type = Request (0x00)
2016-07-25 16:55:04.369 [DEBUG] [WaveController$ZWaveSendThread:1301]- NODE 42: Sending REQUEST Message = 01 09 00 13 2A 02 84 08 25 42 26 
2016-07-25 16:55:04.382 [DEBUG] [b.z.i.p.s.SendDataMessageClass:38  ]- NODE 42: Sent Data successfully placed on stack.
2016-07-25 16:55:04.404 [DEBUG] [b.z.i.p.s.SendDataMessageClass:73  ]- NODE 42: SendData Request. CallBack ID = 66, Status = Transmission complete and ACK received(0)
2016-07-25 16:55:04.405 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:409 ]- NODE 42: Went to sleep
2016-07-25 16:55:04.405 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:472 ]- NODE 42: Is sleeping
2016-07-25 16:55:04.405 [DEBUG] [WaveController$ZWaveSendThread:1364]- NODE 42: Response processed after 36ms/5606ms.
2016-07-25 17:55:20.868 [DEBUG] [ApplicationCommandMessageClass:40  ]- NODE 42: Application Command Request (ALIVE:DONE)
2016-07-25 17:55:20.868 [DEBUG] [ApplicationCommandMessageClass:58  ]- NODE 42: Incoming command class WAKE_UP
2016-07-25 17:55:20.868 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:140 ]- NODE 42: Received Wake Up Request
2016-07-25 17:55:20.868 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:199 ]- NODE 42: Received WAKE_UP_NOTIFICATION
2016-07-25 17:55:20.868 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:449 ]- NODE 42: Is awake with 0 messages in the wake-up queue.
2016-07-25 17:55:21.868 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:544 ]- NODE 42: No more messages, go back to sleep
2016-07-25 17:55:21.868 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:218 ]- NODE 42: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
2016-07-25 17:55:21.869 [DEBUG] [o.b.z.i.protocol.SerialMessage:113 ]- NODE 42: Creating empty message of class = SendData (0x13), type = Request (0x00)
2016-07-25 17:55:21.871 [DEBUG] [WaveController$ZWaveSendThread:1301]- NODE 42: Sending REQUEST Message = 01 09 00 13 2A 02 84 08 25 CA AE 
2016-07-25 17:55:21.884 [DEBUG] [b.z.i.p.s.SendDataMessageClass:38  ]- NODE 42: Sent Data successfully placed on stack.
2016-07-25 17:55:21.899 [DEBUG] [b.z.i.p.s.SendDataMessageClass:73  ]- NODE 42: SendData Request. CallBack ID = 202, Status = Transmission complete and ACK received(0)
2016-07-25 17:55:21.899 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:409 ]- NODE 42: Went to sleep
2016-07-25 17:55:21.900 [DEBUG] [.i.p.c.ZWaveWakeUpCommandClass:472 ]- NODE 42: Is sleeping
2016-07-25 17:55:21.900 [DEBUG] [WaveController$ZWaveSendThread:1364]- NODE 42: Response processed after 29ms/5606ms

My item config:

Number Sensor09_Batterij “Werkplaats Poort [%s %%]” (ALL_bat,AT_bat) { zwave=“42:command=BATTERY” }

Contact Sensor09 “Werkplaats Poort [%s]” (AT_con,ALL_con) { zwave=“42:command=sensor_binary,sensor_type=10,respond_to_basic=true” }

chris · July 25, 2016, 4:53pm

Correct. You’re getting the wakeup, but no notifications. I do suspect that your item config might be incorrect, but until you’re seeing the notifications in the log when the door state changes, it’s a bit irrelevant.

brononius · July 25, 2016, 7:20pm

You won’t believe it, but the sensor was mounted upside down. Apparantly it’s import how it’s been mounted on the garagedoor, Led down, else it won’t been triggered if goes from vertical to horizontal position.

But now everything is working as it supposed to!

Following item config is been used:

Number Sensor10_Batterij “Atelier Poort [%s %%]” (ALL_bat,AT_bat) { zwave=“42:command=BATTERY” }
Contact Sensor10 “Atelier Poort [%s]” (AT_con,ALL_con) { zwave=“42:command=sensor_binary,parameter=10,respond_to_basic=true” }

Thanks a lot guys for your support and your patience!!!

chris · July 25, 2016, 7:55pm

What is the parameter=10 meant to do? I suspect nothing?

brononius · July 26, 2016, 4:53am

Indeed, it works fine without the parameter.
This was a copy/paste from anohter item.

So the new item config is now:

Number Sensor10_Batterij “Atelier Poort [%s %%]” (ALL_bat,AT_bat) { zwave=“42:command=BATTERY” }
Contact Sensor10 “Atelier Poort [%s]” (AT_con,ALL_con) { zwave=“42:command=sensor_binary,respond_to_basic=true” }