Giter Site home page Giter Site logo

Comments (11)

cdjackson avatar cdjackson commented on June 21, 2024

@openhab-5iver I guess that this isn't completely reproducible? If it is, can you provide a log of what's happening? Or is this always happening with a specific device?

The library sends a ReadAttributesCommand command, and it seems that we've correlated a ReportAttributesCommand when we expected a ReadAttributesResponse. I'll take a look at the code later, but I think the main thing used for the correlation is the transaction ID. So, it might be that a device is responding with the wrong response packet - or it might be that both are allowed.

Probably the solution will be to allow both responses, but it would be good to understand a bit what is happening if you can reproduce a log.

from com.zsmartsystems.zigbee.

5iver avatar 5iver commented on June 21, 2024

I guess that this isn't completely reproducible? If it is, can you provide a log of what's happening? Or is this always happening with a specific device?

Nope. Never seen it before. At the time, I noticed a bulb turn on and drop offline (not the bulb in the error). Power cycling it and restarting the binding did bring it back online. It was about 4 minutes after the last restart that this came up. I'll turn on debug and restart the binding a few times to see if I can reproduce it.

from com.zsmartsystems.zigbee.

cdjackson avatar cdjackson commented on June 21, 2024

Ok, thanks. If it's not systematic, then it might be a bug with the transaction correlation, or it might still be that the device decided to use the different response frame for some reason (eg if the device was just about to send a report). Seems strange, but who knows.

If you do catch a log of this any time, please attach, but I'll look at a few possible options anyway...

from com.zsmartsystems.zigbee.

5iver avatar 5iver commented on June 21, 2024

Here is a debug log with a new one, but I think you can recreate it yourself by shutting the binding down and then immediately starting the binding. Doing a bunde:restart may do it too. The exception comes up a few minutes later. There are also a few other exceptions that came up in this log, likely related to the binding not completely shutting down when the bundle is stopped. After a bundle:stop, the logs keep going. Yes, I only have one instance of the binding running :). But I don't think I have restarted OH since dropping in an updated jar, so maybe this is all just be due to that?

The exception in question is at 2018-01-04 04:52:13.605, but if you search for exception, you'll find others.
exception creating channels.zip

from com.zsmartsystems.zigbee.

cdjackson avatar cdjackson commented on June 21, 2024

There are also a few other exceptions that came up in this log, likely related to the binding not completely shutting down when the bundle is stopped.

I assume you mean the InterruptedExceptions? These are caused by the shutdown itself - you closed the binding, so various threads have exited -:

2018-01-04 04:50:00.161 [DEBUG] [org.openhab.binding.zigbee                        ] - BundleEvent STOPPING - org.openhab.binding.zigbee
2018-01-04 04:50:00.414 [DEBUG] [.openhab.binding.zigbee.handler.ZigBeeThingHandler] - 7CE5240000139646: Handler dispose.
2018-01-04 04:50:00.417 [DEBUG] [org.openhab.binding.zigbee                        ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.core.thing.binding.firmware.FirmwareUpdateHandler}={service.id=1042, service.bundleid=16, service.scope=singleton} - org.openhab.binding.zigbee
2018-01-04 04:50:00.419 [DEBUG] [artsystems.zigbee.internal.ZigBeeNetworkDiscoverer] - Error in rediscoverNode 
java.lang.InterruptedException: null

from com.zsmartsystems.zigbee.

cdjackson avatar cdjackson commented on June 21, 2024

I'm unable to replicate this. I'm also unable to tie together your log - I can't find the request that is being made, with the response...

What happens is the transaction is correlating based on the transaction ID - it a message comes in with a transaction ID matching the requests transaction ID, then it's considered a match. I will modify this to also check the addresses are from the correct endpoint - that ought to limit the opportunity for false matches.

In the log here though, I don't see the request being made so I can't work out if the TID is matching with the response - I have to assume it is as the tests on the transaction matcher are working fine.

Given that you seem to be able to repeat this, I'm not sure it will solve the issue - if you get any other logs showing the 10 seconds or so before the exception that would be good...

from com.zsmartsystems.zigbee.

cdjackson avatar cdjackson commented on June 21, 2024

Please let me know if this is still occurring with the latest binding...

from com.zsmartsystems.zigbee.

5iver avatar 5iver commented on June 21, 2024

I could not get this exception to reoccur with the latest (2.3.0.201801052345).

from com.zsmartsystems.zigbee.

cdjackson avatar cdjackson commented on June 21, 2024

Ok, thanks for testing - I'll close this.

from com.zsmartsystems.zigbee.

puzzle-star avatar puzzle-star commented on June 21, 2024

Hi @cdjackson

For some reason I always reproduce the strangest errors... :-)

My understanding from looking at the logs below:

  • This is happening not because the device sends the wrong respone, but because by "chance" a report comes from the device with the same TID as the last command sent to the device
  • The probability of this happening is low, but not negligible
  • It is easy to reproduce in my case, as I was keeping alive the device to register it by pushing its button at half second intervals. In turn, the device is responding with an attribute report (Xiaomi...), so we have plenty of reports (but this just increases the probability of the issue, and is not responsible for the error itself)

So the way to fix it is probably considering not only the source address/endpoint of the device to match the response, but also the destination address/endpoint, as, at least from my logs:

  • The destination address/endpoint of a response matches the one of the originating command (0/0 as I see in the logs, but could be any)
  • The destination endpoint of the report is the one used when binding (0/1 in my case)

Or maybe we should just not match commands as responses

Could you please reopen the issue? (or should I open a new one?)

Here the relevant parts of the log:

2018-09-03 18:58:24.268 [DEBUG] [.zsmartsystems.zigbee.zcl.ZclCluster] - readSync request: ZclAttribute [cluster=RELATIVE_HUMIDITY_MEASUREMENT, id=0, name=MeasuredValue, dataType=UNSIGNED_16_BIT_INTEGER, lastValue=null]
2018-09-03 18:58:24.270 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ReadAttributesCommand [Relative humidity measurement: 0/0 -> 16824/1, cluster=0405, TID=08, identifiers=[0]]
2018-09-03 18:58:24.272 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=CLIENT_TO_SERVER, disableDefaultResponse=false, manufacturerCode=0, sequenceNumber=8, commandId=0]
2018-09-03 18:58:24.274 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/1, destinationAddress=16824/1, profile=0104, cluster=1029, addressMode=DEVICE, radius=31, apsCounter=8, payload=00 08 00 00 00]
2018-09-03 18:58:30.288 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Basic: 16824/1 -> 0/1, cluster=0000, TID=05, reports=[Attribute Report: attributeDataType=CHARACTER_STRING, attributeIdentifier=5, attributeValue=lumi.sensor_ht]]
2018-09-03 18:58:30.661 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Basic: 16824/1 -> 0/1, cluster=0000, TID=06, reports=[Attribute Report: attributeDataType=CHARACTER_STRING, attributeIdentifier=5, attributeValue=lumi.sensor_ht]]
2018-09-03 18:58:31.406 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Basic: 16824/1 -> 0/1, cluster=0000, TID=07, reports=[Attribute Report: attributeDataType=CHARACTER_STRING, attributeIdentifier=5, attributeValue=lumi.sensor_ht]]
2018-09-03 18:58:32.192 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=16824/1, destinationAddress=0/1, profile=0104, cluster=0, addressMode=null, radius=0, apsCounter=0, payload=18 08 0A 05 00 42 0E 6C 75 6D 69 2E 73 65 6E 73 6F 72 5F 68 74]
2018-09-03 18:58:32.193 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=8, commandId=10]
2018-09-03 18:58:32.195 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Basic: 16824/1 -> 0/1, cluster=0000, TID=08, reports=[Attribute Report: attributeDataType=CHARACTER_STRING, attributeIdentifier=5, attributeValue=lumi.sensor_ht]]
2018-09-03 18:58:32.198 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction complete: ReadAttributesCommand [Relative humidity measurement: 0/0 -> 16824/1, cluster=0405, TID=08, identifiers=[0]]
2018-09-03 18:58:32.200 [ERROR] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0002379093: Exception creating channels
java.lang.ClassCastException: com.zsmartsystems.zigbee.zcl.clusters.general.ReportAttributesCommand cannot be cast to com.zsmartsystems.zigbee.zcl.clusters.general.ReadAttributesResponse
        at com.zsmartsystems.zigbee.zcl.ZclCluster.readSync(ZclCluster.java:247) [188:com.zsmartsystems.zigbee:1.0.14]
        at com.zsmartsystems.zigbee.zcl.clusters.ZclRelativeHumidityMeasurementCluster.getMeasuredValue(ZclRelativeHumidityMeasurementCluster.java:163) [188:com.zsmartsystems.zigbee:1.0.14]
        at org.openhab.binding.zigbee.internal.converter.ZigBeeConverterRelativeHumidity.handleRefresh(ZigBeeConverterRelativeHumidity.java:64) [224:org.openhab.binding.zigbee:2.4.0.201808311821]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:294) [224:org.openhab.binding.zigbee:2.4.0.201808311821]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.access$000(ZigBeeThingHandler.java:71) [224:org.openhab.binding.zigbee:2.4.0.201808311821]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:153) [224:org.openhab.binding.zigbee:2.4.0.201808311821]
        at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:150) [224:org.openhab.binding.zigbee:2.4.0.201808311821]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
        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) [?:?]

Best Regards,
Pedro

from com.zsmartsystems.zigbee.

cdjackson avatar cdjackson commented on June 21, 2024

I've sen this sort of issue in the past and I'd already added some checks in the response matcher to combat this (this is the request.getDestinationAddress().equals(response.getSourceAddress() check).

I'd suggest to open another issue with a more targeted title (ie one that better represents this issue).

So the way to fix it is probably considering not only the source address/endpoint of the device to match the response, but also the destination address/endpoint, as, at least from my logs:

I'm not completely sure this will resolve it. Given that TIDs are allocated by the sender, there is nothing to stop such a mismatch if they happen to coincide (if that makes sense).

Or maybe we should just not match commands as responses

Maybe, but this again isn't so easy as you can't be sure that a command will be met with a response (I think!). I'd need to check this, but I think there are instances where this doesn't work and it could be complex. Unless we somehow match specific commands to specific responses - and that is a total nightmare.

Anyways, I'd suggest to open a specific issue on this and we can discuss potential solutions.

from com.zsmartsystems.zigbee.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.