Closed TilmanK closed 4 years ago
Same here with Paulmann Rgb 50049. Same Stick and Z2M version.
After deleting the device I was thrown back to receiving timeouts all the time while pairing.
@Koenkk Would you be so kind to take a look at the logs and the sniffed traffic and confirm my assumption (or any other one that has more knowledge of Zigbee than I have) :)? From what I can see, the device does not respond to the message to read model while pairing etc.:
Frame 197: 65 bytes on wire (520 bits), 65 bytes captured (520 bits) on interface \.\pipe\zboss_sniffer, id 0 ZBOSS dump, IN, page 0, channel 24 IEEE 802.15.4 Data, Dst: 0x2b1b, Src: 0x0000 ZigBee Network Layer Data, Dst: 0x2b1b, Src: 0x0000 ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1 ZigBee Cluster Library Frame, Command: Read Attributes, Seq: 2 Frame Control Field: Profile-wide (0x10) Sequence Number: 2 Command: Read Attributes (0x00) Attribute: Model Identifier (0x0005) Attribute: Manufacturer Name (0x0004) Attribute: Power Source (0x0007)
Is this correct? I switched to a CC26X2R1 some days ago (much more reliable btw.). pcap_and_herdsman.zip
Filter for Wireshark file: "zbee_nwk.addr eq 0x2B1B or zbee_nwk.addr eq 0x2B1B"
@TilmanK it indeed doesn't respond to the model read, can you try pairing it a few times more and see if it always fails at this point?
It does. Does it make sense to try with the CC2531 and a different firmware?
Strange, because in the OP it did right? ( i see you have the modelid), you can always try with a different firmware (but there shouldn't be a difference).
Yes it did. But only after some tries. And then I ran into the initially described problem. I'll try to get it paired with some other firmware on the stick and maybe an older version of Z2M. If this doesn't work, I'll close the ticket and contact the device manufacturer.
Did you achieve anything? I have the same problem with a CC2531.
@oepoemoepoe Not yet, but I hope I'll find some time this weekend to run some further tests. Do you have exactly the same device and exactly the same problem?
I have this light, which however is an RGB light: https://www.paul-neuhaus.de/shop/de/led-strahler-smart-home-alexa-tauglich-100-082-47.html It is working (I don't know exactly how long, maybe it would also stop after some time) until I turn it off by its hardware switch or I restart zigbee2mqtt. It does not respond to any /get /set commands. Strangely, another Paul Neuhaus light (color temp only) I have does not have these issues.
It appears to me that more users/devices have this problem.
If I can assist, please let me know. I don't know what to start with at the moment.
Are you able to sniff Zigbee traffic or provide herdsman debug logs from a pairing atempt?
https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html https://www.zigbee2mqtt.io/information/debug.html
It would be interesting to know if your device fails to respond at the same point.
The device stays the way it was. It doesn't respond to the model read...
I wrote Paul Neuhaus to see if they can help. In the meantime I sniffed traffic when pairing it with my Hue Bridge. Pairing works except that also my Hue bridge thinks that the lamp is an RGB device (address is 0x000a): q_malina_hue.zip
@Koenkk: Can you see any difference in the communication? It seems as if my CC2531 did not capture all the responses.
It doesn't respond to the model read...
@TilmanK I've looked at the herdsman logs again and found the issue. Actually it has already been fixed in another issue (https://github.com/Koenkk/zigbee2mqtt/issues/2780). With the latest zigbee2mqtt dev branch the device should pair and interview successfully.
Btw I cannot decrypt the Hue traffic as I don't have your network key, feel free to send it to me on telegram (@koenkk).
The Hue keys are the default keys: https://hal9k.dk/sniffing-philips-hue-zigbee-traffic-with-wireshark/. It's no secret, I use that bridge for testing stuff only (and updates...).
I pulled the dev branch and voilà - pairing is successful. But I'm now back to the fun part. The device identifies itself as Status Record, String: NLG-RGBW light Attribute: Model Identifier (0x0005) Status: Success (0x00) Data Type: Character String (0x42) String: NLG-RGBW light Status Record, String: Neuhaus Lighting Group Attribute: Manufacturer Name (0x0004) Status: Success (0x00) Data Type: Character String (0x42) String: Neuhaus Lighting Group
We're back where the device is identified as an RGBW light - I guess they're just using the same ZigBee module (it's something from Jennic) for every light - we won't be able to identify the lights of this manufacturer correctly, right?
It's not a problem I guess, except that I don't get the correct picture in Zigbee2Mqtt assistant. I just don't send any color commands from NodeRed.
@Koenkk: Could you do me a favor and point me to the commit that fixed the problem you're talking about? Unfortunately it's not linked to the issue and I'd like to have a look - just out of interest. And if there's nothing we can do with the identification, just close the issue.
Ahhh, and thanks a lot for the fix! :)
So does that commit only solve your pairing problem or also the issue of the light timing out after a while?
@TilmanK https://github.com/Koenkk/zigbee-herdsman/commit/8b8e77e79f32e02dc38fa9c4e10a0093962059dd
This is what happend:
[2, 1]
(so two endpoints), list is sorted here -> [1,2]
genBasic
cluster (which contains modelID
, endpoint 1 doesntgenBasic
cluster. <--- bugFix: read modelID from endpoint which supports genBasic
cluster: https://github.com/Koenkk/zigbee-herdsman/commit/8b8e77e79f32e02dc38fa9c4e10a0093962059dd#diff-3a4a6c17eb7d440e4529b0721a7836faR381
@TilmanK let's continue the identification issue here; https://github.com/Koenkk/zigbee2mqtt/issues/2778#issuecomment-578426574
@oepoemoepoe. Well, I totally forgot. I'm back with receiving timeouts from the paired device. I know that it works with the Hue bridge so'll get some traces from both communications and will compare them.
@Koenkk Thanks for the explanation. Makes sense ;)
@Koenkk Ok, I guess I've hopefully found the issue. Could it be that Z2M is still messing up the endpoints when sending to Cluster On/Off?
My Hue bridge talks successfully to endpoint 2:
ZigBee Application Support Layer Data, Dst Endpt: 2, Src Endpt: 64
Frame Control Field: Data (0x00)
Destination Endpoint: 2
Cluster: On/Off (0x0006)
Profile: Home Automation (0x0104)
Source Endpoint: 64
Counter: 195
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x11)
Sequence Number: 63
Command: Off with effect (0x40)
Payload
But Z2M sends the same command to endpoint 1:
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
Frame Control Field: Data (0x00)
Destination Endpoint: 1
Cluster: On/Off (0x0006)
Profile: Home Automation (0x0104)
Source Endpoint: 1
Counter: 78
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x01)
Sequence Number: 9
Command: Off (0x00)
Attached are the sniffed traffic and the debugslogs.
@TilmanK well found, you can specify the default endpoint like this: https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices.js#L556 (you can leave out the system one)
As the pr has been merged, I assume this issue is solved and can be closed.
Thanks a lot you two!
I am still getting this error when reporting, although anything else seems to work fine.
zigbee2mqtt:error 2020-02-07 17:40:36: Failed to setup reporting for '0x00158d0002574367' - Error: ConfigureReporting 0x00158d0002574367/2 genOnOff([{"attribute":"onOff","minimumReportInterval":0,"maximumReportInterval":300,"reportableChange":0}], {"timeout":10000,"defaultResponseTimeout":15000,"manufacturerCode":null,"disableDefaultResponse":true}) failed (Error: Timeout - 57019 - 2 - 2 - 6 - 7 after 10000ms) at Endpoint.<anonymous> (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:316:23) at Generator.throw (<anonymous>) at rejected (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:6:65)
Bug Report
What happened
I bought the following device for my living room: https://www.paul-neuhaus.de/shop/de/led-deckenleuchte-smart-home-design-modern-welle.html
The device paired as follows (Doesn't seem correct, it's not an RGB capable device and not supported yet): {"id":28,"type":"Router","ieeeAddr":"0x00158d0002a6d294","nwkAddr":11097,"manufId":4151,"manufName":"Neuhaus Lighting Group ","powerSource":"Mains (single phase)","modelId":"NLG-RGBW light ","epList":[1,2],"endpoints":{"1":{"profId":49246,"epId":1,"devId":4096,"inClusterList":[4096],"outClusterList":[4096],"clusters":{},"binds":[]},"2":{"profId":49246,"epId":2,"devId":528,"inClusterList":[0,4,3,6,8,5,768],"outClusterList":[0,25],"clusters":{"genBasic":{"attributes":{"modelId":"NLG-RGBW light ","manufacturerName":"Neuhaus Lighting Group ","powerSource":1,"zclVersion":1,"appVersion":1,"stackVersion":2,"hwVersion":1,"dateCode":"20150821","swBuildId":"1001-0007"}}},"binds":[]}},"appVersion":1,"stackVersion":2,"hwVersion":1,"dateCode":"20150821","swBuildId":"1001-0007","zclVersion":1,"interviewCompleted":true,"meta":{}}
Nonetheless, the device will work for some minutes after pairing. Afterwards, it will announce itself when powered, but will then not accept any commands. Everything I send to the device results in a timeout (see logs, announce works, nothing else).
The device is ~4m line of sight away from the coordinator (with only one door in between). In the same room I have 3 Osram Smart plugs working without problems and another Phillips Hue light (router) between coordinator and the affected device is also working flawlessly.
Debug Info
zigbee2mqtt version: Dev from 03.01.2020 CC253X firmware version: CC2531_SOURCE_ROUTING_20190619 Logs: https://pastebin.com/Gc5sZi9S
Thanks for your support!