openhab / org.openhab.binding.zigbee

openHAB binding for ZigBee
Eclipse Public License 2.0
73 stars 111 forks source link

Danalock V3-BTZB Zigbee version does not report Door State #685

Closed YuriyKu closed 2 years ago

YuriyKu commented 2 years ago

Outline

Hello,

I have problem with reporting doorlockstate channel value using Zigbee binding for Danalock V3-BTZB Zigbee version. Another two chanels batterylevel and batteryalarm works good and reports their values as expected. According to traces there is problem with Door State unsupported attributes.

2021-10-16 23:17:20.012 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ConfigureReportingResponse [Door Lock: C5B6/1 -> 0000/1, cluster=0101, TID=21, status=null, records=[Attribute Status Record [status=UNSUPPORTED_ATTRIBUTE, direction=false, attributeIdentifier=3]]]

As I found there are two places in ZigBeeConverterDoorLock.java related to this functionality:

  1. Method initializeDevice() (Line 71): // Configure reporting - no faster than once per second - no slower than 2 hours. CommandResult reportingResponse = serverCluster.setDoorStateReporting(1, REPORTING_PERIOD_DEFAULT_MAX).get();

  2. Method handleRefresh() (Line 108): cluster.getDoorState(0);

Both methods works with ATTR_DOORSTATE (attributeIdentifier=3) which is not supported by Danalock V3.

How about adding additional verification whether attribute is supported, somthing like:

  1. Line 71

    CommandResult reportingResponse = null; if (serverCluster.isAttributeSupported(ZclDoorLockCluster.ATTR_DOORSTATE)) { reportingResponse = serverCluster.setDoorStateReporting(1, REPORTING_PERIOD_DEFAULT_MAX).get(); } else if (serverCluster.isAttributeSupported(ZclDoorLockCluster.ATTR_LOCKSTATE)) { reportingResponse = serverCluster.setLockStateReporting(1, REPORTING_PERIOD_DEFAULT_MAX).get(); }

    if (null != reportingResponse) { handleReportingResponse(reportingResponse, POLLING_PERIOD_HIGH, REPORTING_PERIOD_DEFAULT_MAX); } else { logger.debug("{}: No supported ReportingResponse found", endpoint.getIeeeAddress()); }

  2. Line 108

    public void handleRefresh() { if (cluster.isAttributeSupported(ZclDoorLockCluster.ATTR_DOORSTATE)) { cluster.getDoorState(0); } else if (cluster.isAttributeSupported(ZclDoorLockCluster.ATTR_LOCKSTATE)) { cluster.getLockState(0); } else { logger.debug("{}: No supported ZigBee attributes found", endpoint.getIeeeAddress()); } }

What do you think about it?

Configuration

Configuration Description
Coordinator used Ember EM35x Coordinator
openHAB version 3.2.0-SNAPSHOT - Build #2527
Hardware Raspberry Pi 4 Model B Rev 1.2
Memory 4 Gb
Java version openjdk version "11.0.12" 2021-07-20 LTS
Devices Danalock V3-BTZB Zigbee version

Logs

I have used the following logging settings to gain the attached log files:

log:set DEBUG org.openhab.binding.zigbee log:set DEBUG com.zsmartsystems.zigbee log:set DEBUG com.zsmartsystems.zigbee.dongle.ember.internal.ash

I have saved the log file to gist: https://gist.github.com/YuriyKu/27c37d1d63f2083c054d7c1e74fce497

cdjackson commented 2 years ago

How about adding additional verification whether attribute is supported,

Sure - this seems reasonable since it is an optional attribute. I will take a look at this shortly.

cdjackson commented 2 years ago

Having looked at this a bit closer, I think this is just a bug. The converter used a mixture of DOORSTATE and LOCKSTATE when it should really just use LOCK_STATE. The actual state update only used LOCKSTATE, but the refresh request used DOORSTATE, as did the reporting configuration,

LOCKSTATE is a mandatory attribute so no additional checking is required.

I'll fix this for starters, and will likely add another converter for the actual door state.