Ecolink dwzwave2.5 door contact

Setup, Configuration and Use Items & Sitemaps
21

Edit this file: userdata/etc/org.ops4j.pax.logging.cfg

Change this line

log4j2.logger.smarthomeItemStateEvent.level = ERROR

to this.

log4j2.logger.smarthomeItemStateEvent.level = DEBUG

Some people shutdown openHAB to make these edits. I typically edit this file while OH is running.YMMV.

22

One other thing to make note of… Doubtful that it’s relevant here, but thought I would mention it anyway.

Up until late November last year, there wasn’t a separate database entry for the DWZWAVE version 2.5 device. Prior to November, the DWZWAVE 2.5 device was lumped in with the DWZWAVE 2 device. In late November, I created a separate database entry for the 2.5 device because it had some additional feature/channels from the version 2 device.

23

The sensor_binary items are showing up in the log. This isn’t being reflected on the site map in basic UI, or in paper UI under control. The sensor_door channels are not showing up in the log.
Also, I’m at a complete loss as to why one of these is reporting Open/Closed and the other On/Off. Both are defined as sensor_binary.

2019-04-29 16:46:05.650 [thome.event.ItemStateEvent] - Garage_Door_Binary updated to OPEN
2019-04-29 16:46:06.598 [thome.event.ItemStateEvent] - Garage_Door_Binary updated to CLOSED
2019-04-29 16:46:09.185 [thome.event.ItemStateEvent] - GDBS updated to ON
2019-04-29 16:46:09.189 [vent.ItemStateChangedEvent] - GDBS changed from OFF to ON
2019-04-29 16:46:09.841 [thome.event.ItemStateEvent] - GDBS updated to OFF
2019-04-29 16:46:09.843 [vent.ItemStateChangedEvent] - GDBS changed from ON to OFF
24

And I just checked, both are showing up as DWZWAVE25 devices and as far as I know are identical, though purchased at different dates.

25

That’s not true.

This device has the:

  • SENSOR_BINARY command class mapped to the sensor_binary channel, and
  • ALARM command class mapped to the sensor_door channel.

The sensor_binary channel is defined as a Switch.
https://github.com/openhab/org.openhab.binding.zwave/blob/master/ESH-INF/thing/channels.xml#L913

And the sensor_door channel is defines as a Contact.
https://github.com/openhab/org.openhab.binding.zwave/blob/master/ESH-INF/thing/channels.xml#L968

I think this is the way @chris recommends to do this for devices of type Door/Window sensors.

Your item definitions look right, so I’m not sure why they are not showing on the sitemap.

26

I understand that there are multiple channels per sensor. What is baffling is the sensor_binary channel of node 36 (GDBS) is reporting ON/OFF rather than OPEN/CLOSED in the logs.

27

Sorry, I have that backwards. The other sensor GARAGE_DOOR_BINARY should also be reporting ON/OFF, but is reporting OPEN/CLOSED. Coffee hasn’t kicked in yet.

28 
Switch Garage_Door_Binary "Big Garage Door Binary (35) [%s]" <garagedoor> (Garage) {channel = "zwave:device:9305b102:node35:sensor_binary"} 
Contact Garage_Door_Contact "Big Garage Door (35) [%s]" <garagedoor> (Garage) {channel = "zwave:device:9305b102:node35:sensor_door"}

Yes, that’s odd. Garage_Door_Binary is linked to sensor_binary, which should be reporting ON/OFF.

If you provide a debug log file I can take a look. But I won’t be able to look at it until later this afternoon as I’m off to play some golf. :smile:

29

Openhab.log? Do I need to set any debug flags besides the zwave?

30

Yes.

No.

31

openhab~.log (1008.0 KB)

Ok. Here’s a snippet. I turned some debug flags on and opened and closed the garage doors, node 35 and node 36, before reading your last message. Node 36 isn’t showing up at all.

32

I don’t know where you live, but it would be a good day for it here in western Washington. Thanks for your help.

33

There is nothing received in the log from this node - that’s why it’s not showing up.

Node 36 appears to be working ok -:

image
image710×436 85.7 KB

sensor_door reports OPEN/CLOSED
sensor_binary reports ON/OFF

This looks fine?

The only message that isn’t being decoded is the BASIC message. It looks like it is probably mimicking the SENSOR_BINARY class, so this is probably an issue with the database configuration, although as you should use the sensor_door class, this shouldn’t matter.

In this log, the garage_door_binary is linked to sensor_binary, and this IS reporting OnOffType - ie ON/OFF and not OPEN/CLOSED.

34

My problem is that none of the (ZW) sensor_binary or sensor_door item status changes are reflected in the site map or the control section of paperUI or Habmin and my rules are no longer responding to those item status changes. I describe the history at the bottom.

Node 36 missing from logs this morning is unique. It was showing up yesterday. Item ‘GDBS’ shown in log from yesterday is node 36. This isn’t my primary focus though.

2019-04-29 16:46:05.650 [thome.event.ItemStateEvent] - Garage_Door_Binary updated to OPEN
2019-04-29 16:46:06.598 [thome.event.ItemStateEvent] - Garage_Door_Binary updated to CLOSED
2019-04-29 16:46:09.185 [thome.event.ItemStateEvent] - GDBS updated to ON
2019-04-29 16:46:09.189 [vent.ItemStateChangedEvent] - GDBS changed from OFF to ON
2019-04-29 16:46:09.841 [thome.event.ItemStateEvent] - GDBS updated to OFF
2019-04-29 16:46:09.843 [vent.ItemStateChangedEvent] - GDBS changed from ON to OFF

See the log snippet just above. Both of those channels GDBS (node 36) and Garage_Door_Binary (node 35) are defined as sensor_binary. The item file snippet is above. One is reporting correctly, one isn’t.

History:
All had been working fine for many months. I hadn’t even logged into that computer in months. Last week, the laptop running OH fell asleep for mysterious reasons. It has never happened before. When it restarted, the zwave controller was offline. I rebooted and it was still offline. After a few restarts I gave up and deleted then recreated the the controller thing (AEON Z-Stick) and in the process named it the same as before so I wouldn’t have to change the names of all of my channels in the items file. At that point, all of my ZW things were still offline. I rebooted or restarted OH, I don’t recall. Still offline. So I deleted all of them, scanned and recreated all of them. All of the ZW things (about 20) worked after that, except the door sensors and PIR sensors, one Aeon on mains and one Eco on battery.

At this point, the only reason I have not wiped the whole thing clean and re-installed is in case there is some benefit to the OH community in learning why this happened. Please let me know if you would like me to keep chasing this, otherwise I will just reinstall.

35

I’m not sure what snippet you refer to here. If I look just above I don’t just see sensor_binary - I also see sensor_door.

In any case, from a binding perspective, it looks fine. The channels are being updated, so I’m not sure why it’s not flowing through the rest of the system.

From a binding perspective, there is nothing wrong as far as I can see here. The channels are being decoded correctly, and updating the system. If it were me with this problem, I’d reinstall :wink: