ZWave - Vision Garage Door Detector ZG8101 doen't work with OH2

Add-ons Bindings
, ,
1

After Migrationg from openHAB 1.8 to OH2 many things are working, but unfortunately not all. One of those is the ZWave Garage Door Detector ZG8101. Im am not able to get the binary sensor events.

First, I had multiple item links with the same name. After studing this article I could delete this links with the smarthome:link command in the Karaf console.

Now I have only one item link in my item File:

Contact Sens4_GarageDoor    	"GA Garagentor Status [MAP(garage.map):%s]"<garagedoor>	(GT_Ga) 	{channel="zwave:device:2e1cf86f:node47:sensor_binary"}

When I tilt the sensor, I dont’t get an ON/OFF event. What am I doing wrong?

2

Hi,

My own VIS-ZG8101 works fine, although it has been reconfigured from tilt switch to magnetic reed and changed from NO to NC.

I’d first check the syntax of the items file, as OH2 can fail to parse an Item.
My own device is defined with:

Switch  sGrge_Door      "Garage Door [%s]"      <door>          {channel="zwave:device:aaaaaaaa:node99:sensor_binary"}

Note - no map, space before the group name, and the sensor_binary is defined as a Switch not a Contact. I found other Contact devices would not trigger until changed to Switch.

That may well fix matters, but if not, look at the console log for events with the Z-Wave binding set to DEBUG: http://docs.openhab.org/administration/console.html

Good luck,

3

That’s great, now it works! Thank you James.

The only thing I had to change was the item type from Contact to Switch. I can’t remember why, but with OH1 I had it configured as a Contact. That worked without any problems for mor than a year. However, with type=Switch it woks also on OH2.

Spaces and maps are no problems. I use it this way now:

Switch	Sens4_GarageDoor		"GA Garagentor Status: [MAP(garage.map):%s]"<garagentor>	(GT_Ga)		{channel="zwave:device:2e1cf86f:node47:sensor_binary"}
4

Hi there,

I proposed to update channel type to contact item. So it make sense with the device type.

Here is the device information : http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/103 and my comment :slight_smile:

Everybody agree ? @chris ?

5

If you change the channel type to sensor_door it should do what you want.

6

Thanks Chris, I did proceed

1 Like
7

Thanks - I’ll merge it into the binding…

8

That was quick, thanks @chris for your work !

You made huge effort on openhab/zwave support, that’s considerable !

1 Like
9

Will it work as a Contact if I update the Binding?

10

@luma: I don’t understand the change you made. It was working before with item type = switch, but it doesn’t work anymore after your change. How do I have to configure now?

Item type = contact
channel = zwave:device:2e1cf86f:node47:sensor_door

I have tried it with this configuration, but it doesn’t work anymore… :confused:

11

Hi,

I’ve just worked out why my garage door rule was not triggering in OH2 with recent snapshots:

  • The device database entry from the FGK101 Door Sensor changed from Switch to Contact.
    (e.g. zwave:device:99999999:node99:sensor_door changed data type)
  • When OpenHAB2 was restarted, this meant the Item defined in the Items file was no longer linked to the Item, so it was not updated.
  • This gave a silent failure.

Thankfully, the fix was relatively easy:

  • Check in the OpenHAB-2 Channel Types list for Switch and Contact.
  • Update OpenHAB2, reboot, and delete the garage door Thing and add it back from the Inbox to make sure the new binding details are picked up.
  • Check the Thing in PaperUI (other other GUI) exists and has at least three Channels (sensor_door, alarm_burglar, battery-level).
    If you still see Switch for sensor_door, you have the old device database.
  • If you use a text-file items file, change the definition of the sensor_door:
OLD: Switch sGrge_Door      "Garage Door [%s]"      <door>          {channel="zwave:device:999999999:node99:sensor_door"}
NEW: Contact cGrge_Door      "Garage Door [%s]"      <door>          {channel="zwave:device:99999999:node99:sensor_door"}

As I use a character prefix to show the data type (s = Switch, c = Contact) I also had to update my rules files with the new name, and also all tests from ON / OFF to OPEN/ CLOSED as the state values also change with the channel type.

12

Hi James
Thank you for your explanations. Now, after I have tryed the following, my contact is still not working:

  • updated and rebooted openhab2 to the latest snapshot (build 932)
  • excluded the ZG8101 from zwave controller (node47)
  • included the ZG8101 again to zwave controller (node49)
  • deleted the old thing (node47) since it is not used anymore
  • checked in the Channel Types list: my ZG8101 has a channel with name=sensor_door, which means that it is a contact
  • changed the item definition in the items file to type Contact
  • The thing (node49, after the new inclusion to zwave controller) has three channels in PaperUI (sensor_door, alarm_burglar, battery-level). All of them are “connected” to an item (Contact, Switch, Number)

The item configuration looks like this:

Contact	Sens4_GarageDoor		"GA Garagentor Status"				<garagentor>(GT_Ga)				{channel="zwave:device:2e1cf86f:node49:sensor_door"}

In the debug log I receive messages like the following:

2017-06-01 21:27:48.946 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 00 E9 
2017-06-01 21:27:48.963 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-06-01 21:27:48.967 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 49: Command received zwave:device:2e1cf86f:node49:alarm_burglar --> REFRESH
2017-06-01 21:27:48.970 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 00 E9 
2017-06-01 21:27:48.970 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 49: Polling intialised at 3600 seconds - start in 50 milliseconds.
2017-06-01 21:27:48.973 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 00 E9 
2017-06-01 21:27:48.978 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=00 
2017-06-01 21:27:48.982 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 48: Sent Data was not placed on stack due to error 0.
2017-06-01 21:27:48.988 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 49: Command received zwave:device:2e1cf86f:node49:battery-level --> REFRESH
2017-06-01 21:27:48.992 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 49: Polling intialised at 3600 seconds - start in 50 milliseconds.
2017-06-01 21:27:48.994 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 49: Command received zwave:device:2e1cf86f:node49:sensor_door --> REFRESH
2017-06-01 21:27:48.995 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 49: Polling intialised at 3600 seconds - start in 50 milliseconds.
2017-06-01 21:27:49.045 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 49: Polling...
2017-06-01 21:27:49.047 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 49: Polling deferred until initialisation complete

Do you know, what this means? Seems like the node 49 is not initialized correctly…

13

That’s not what this is saying - it’s saying that the node isn’t initialised. This is normal if the binding has just started - the device will need to wake up a few times to move past this stage.

14

Thank you @chris, that’s exactly what happend. Today morning this device is working correctly again.
Also thanks to @FloatingBoater

15

I don’t know why, but everything was working correctly (configured as a Contact) up until my latest pull of the Nightly. There appears to of been an update to the device in the ZWave database 1/19/19 adding the ALARM channel which appears to of triggered a refresh of my device which made it STOP working.

I’ve changed the Thing to a Switch and it appears to at least be mapping now to an OFF/ON state.

Now I just need to review my rules for changes.

A little disgruntled as my garage door kept opening last night every hour thinking it was Open and needed to be closed. Need more sleep.:face_with_raised_eyebrow: