Open kurts-gmail opened 6 months ago
I extracted a failed exchange vs a good one. The good one sends back some extra data {"name":"attrData","type":1000} vs the failed one. In both cases it seems that it did make initial contact with the endpoint.
kurts@M1-Macbook-Air ~ % grep 23137 z2mFyrturFailMasterBedBlindRight [2024-05-27 21:58:15] debug: zh:zstack: sendZclFrameToEndpointInternal 0x804b50fffe166227:23137/1 (0,0,4) [2024-05-27 21:58:15] debug: zh:zstack:znp: SREQ: --> AF - dataRequest - {"dstaddr":23137,"destendpoint":1,"srcendpoint":1,"clusterid":258,"transid":55,"options":0,"radius":30,"len":3,"data":{"type":"Buffer","data":[1,17,0]}} [2024-05-27 21:58:16] debug: zh:zstack:znp: AREQ: <-- ZDO - srcRtgInd - {"dstaddr":23137,"relaycount":1,"relaylist":[38443]} [2024-05-27 21:58:16] debug: zh:zstack:znp: AREQ: <-- AF - incomingMsg - {"groupid":0,"clusterid":258,"srcaddr":23137,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":76,"securityuse":0,"timestamp":12028887,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[8,17,11,0,0]}} [2024-05-27 21:58:16] debug: zh:controller: Received payload: clusterID=258, address=23137, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=76, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":17,"commandIdentifier":11},"payload":{"cmdId":0,"statusCode":0},"command":{"ID":11,"name":"defaultRsp","parameters":[{"name":"cmdId","type":32},{"name":"statusCode","type":32}]}} [2024-05-27 21:58:16] debug: zh:zstack:znp: AREQ: <-- ZDO - srcRtgInd - {"dstaddr":23137,"relaycount":1,"relaylist":[38443]} [2024-05-27 21:58:16] debug: zh:zstack:znp: AREQ: <-- AF - incomingMsg - {"groupid":0,"clusterid":258,"srcaddr":23137,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":69,"securityuse":0,"timestamp":12031655,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[8,17,11,0,0]}} [2024-05-27 21:58:16] debug: zh:controller: Received payload: clusterID=258, address=23137, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=69, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":17,"commandIdentifier":11},"payload":{"cmdId":0,"statusCode":0},"command":{"ID":11,"name":"defaultRsp","parameters":[{"name":"cmdId","type":32},{"name":"statusCode","type":32}]}} kurts@M1-Macbook-Air ~ % kurts@M1-Macbook-Air ~ % kurts@M1-Macbook-Air ~ % kurts@M1-Macbook-Air ~ % kurts@M1-Macbook-Air ~ % kurts@M1-Macbook-Air ~ % grep 58325 z2mFyrturFailMasterBedBlindRight [2024-05-27 21:58:15] debug: zh:zstack: sendZclFrameToEndpointInternal 0x588e81fffe623b60:58325/1 (0,0,3) [2024-05-27 21:58:15] debug: zh:zstack:znp: SREQ: --> AF - dataRequest - {"dstaddr":58325,"destendpoint":1,"srcendpoint":1,"clusterid":258,"transid":54,"options":0,"radius":30,"len":3,"data":{"type":"Buffer","data":[1,16,0]}} [2024-05-27 21:58:16] debug: zh:zstack:znp: AREQ: <-- ZDO - srcRtgInd - {"dstaddr":58325,"relaycount":1,"relaylist":[38443]} [2024-05-27 21:58:16] debug: zh:zstack:znp: AREQ: <-- AF - incomingMsg - {"groupid":0,"clusterid":258,"srcaddr":58325,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":69,"securityuse":0,"timestamp":12008155,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[8,16,11,0,0]}} [2024-05-27 21:58:16] debug: zh:controller: Received payload: clusterID=258, address=58325, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=69, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":16,"commandIdentifier":11},"payload":{"cmdId":0,"statusCode":0},"command":{"ID":11,"name":"defaultRsp","parameters":[{"name":"cmdId","type":32},{"name":"statusCode","type":32}]}} [2024-05-27 21:58:17] debug: zh:zstack:znp: AREQ: <-- ZDO - srcRtgInd - {"dstaddr":58325,"relaycount":1,"relaylist":[38443]} [2024-05-27 21:58:17] debug: zh:zstack:znp: AREQ: <-- AF - incomingMsg - {"groupid":0,"clusterid":258,"srcaddr":58325,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":76,"securityuse":0,"timestamp":12072087,"transseqnumber":0,"len":7,"data":{"type":"Buffer","data":[8,37,10,8,0,32,98]}} [2024-05-27 21:58:17] debug: zh:controller: Received payload: clusterID=258, address=58325, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=76, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":37,"commandIdentifier":10},"payload":[{"attrId":8,"dataType":32,"attrData":98}],"command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},**{"name":"attrData","type":1000}]**}} [2024-05-27 21:58:17] debug: zh:zstack: sendZclFrameToEndpointInternal 0x588e81fffe623b60:58325/1 (0,0,1) [2024-05-27 21:58:17] debug: zh:zstack:znp: SREQ: --> AF - dataRequest - {"dstaddr":58325,"destendpoint":1,"srcendpoint":1,"clusterid":258,"transid":61,"options":0,"radius":30,"len":5,"data":{"type":"Buffer","data":[24,37,11,10,0]}}
I have a very similar issue with my TREDANSEN blinds. It might have started happening after the last firmware upgrade (24.4.13). Its intermittent nature makes it very hard to track down.
@kurts-gmail Do your problematic blinds move at all when this happens? When I have this issue the blind actually receives the command, but it stops moving after a split second. It's like it received two commands, where the second command cancels out the first one.
The issue also happens sometimes when I bind a remote directly to the blind. Have you tried that?
What happened?
I have a group of Ikea Fyrtur blinds that I control together with a switch. For more scripting control I use Home Assistant automations instead of native group binding. Intermittently and frequently one or more of the blinds doesn't respond to the command. Manually repeating the command usually causes the blind to respond.
What did you expect to happen?
All blinds to open or close as commanded
How to reproduce it (minimal and precise)
Open / close until failure ~20% of the time in the group of 6 blinds.
Zigbee2MQTT version
1.37.1
Adapter firmware version
20240315
Adapter
Smartlight SLZB-06
Setup
Home assistant addon, hardwired ethernet between HA and coordinator
Debug log
z2mFyrturFailMasterBedBlindRight.txt
In this log MasterBedBlindRight fails to open. The log starts at the button push to open them. For blinds that responded I see messages like closuresWindowCovering.defaultRsp after the command. This isn't seen for the failed blinds.