search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
12.05k stars 1.67k forks source link

devices always fall off alone for no reason. These are Legrand (412015) and Xiaomi devices (RTCGQ01LM, WXKG01LM,MCCGQ01LM) #12533

Closed VOVAiS closed 2 years ago

VOVAiS commented 2 years ago

What happened?

devices always fall off alone for no reason. These are Legrand (412015) and Xiaomi devices (RTCGQ01LM, WXKG01LM,MCCGQ01LM) There is nothing in the z2m logs. I scanned the traffic and found that the router was sending requests. short address of the legrand device 0x7400 Frame 649: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface \\.\pipe\zboss_sniffer_COM23, id 0 ZBOSS dump, IN, page 0, channel 11 IEEE 802.15.4 Data, Dst: Broadcast, Src: 0x7400 ZigBee Network Layer Command, Dst: Broadcast, Src: 0x7400 Frame Control Field: 0x1209, Frame Type: Command, Discover Route: Suppress, Security, Extended Source Command Destination: 0xfffc Source: 0x7400 Radius: 20 Sequence Number: 218 Extended Source: Legrand_00:00:a1:80:22 (00:04:74:00:00:a1:80:22) ZigBee Security Header Security Control Field: 0x28, Key Id: Network Key, Extended Nonce Frame Counter: 20545469 Extended Source: Legrand_00:00:a1:80:22 (00:04:74:00:00:a1:80:22) Key Sequence Number: 0 Message Integrity Code: e3409433 [Key: decb9489baf7d09556e3cc61b28f88ed] [Key Label: ] Command Frame: Route Request Command Identifier: Route Request (0x01) Command Options: 0x00, Many-to-One Discovery: Not Many-to-One Route ID: 244 Destination: 0x0000 Path Cost: 0 But it does not return to the network

The motion sensor has the address RTCGQ01LM 0xA964 It is also clear from the sniff that it sends data Frame 787: 63 bytes on wire (504 bits), 63 bytes captured (504 bits) on interface \\.\pipe\zboss_sniffer_COM23, id 0 ZBOSS dump, IN, page 0, channel 11 IEEE 802.15.4 Data, Dst: 0x00d9, Src: 0xa964 Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit Sequence Number: 157 Destination PAN: 0xd020 Destination: 0x00d9 Source: 0xa964 [Extended Source: Jennic_00:03:d1:6f:ce (00:15:8d:00:03:d1:6f:ce)] [Origin: 784] TI CC24xx-format metadata: FCS OK ZigBee Network Layer Data, Dst: 0x0000, Src: 0xa964 Frame Control Field: 0x0248, Frame Type: Data, Discover Route: Enable, Security Data Destination: 0x0000 Source: 0xa964 Radius: 30 Sequence Number: 57 [Extended Source: Jennic_00:03:d1:6f:ce (00:15:8d:00:03:d1:6f:ce)] [Origin: 784] ZigBee Security Header Security Control Field: 0x28, Key Id: Network Key, Extended Nonce Frame Counter: 1930 Extended Source: Jennic_00:03:d1:6f:ce (00:15:8d:00:03:d1:6f:ce) Key Sequence Number: 0 Message Integrity Code: 2eb38560 [Key: decb9489baf7d09556e3cc61b28f88ed] [Key Label: ] ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1 Frame Control Field: Data (0x00) Destination Endpoint: 1 Cluster: Occupancy Sensing (0x0406) Profile: Home Automation (0x0104) Source Endpoint: 1 Counter: 228 ZigBee Cluster Library Frame, Command: Report Attributes, Seq: 71 Frame Control Field: Profile-wide (0x18) Sequence Number: 71 Command: Report Attributes (0x0a) Attribute Field Attribute: Occupancy (0x0000) Data Type: 8-Bit Bitmap (0x18) Occupancy: 0x01, Occupied .... ...1 = Occupied: True And there is no data in z2m

What did you expect to happen?

Happens by itself at any given time. It can work stably for a month, a week or three days.

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.24.0

Adapter firmware version

2103 and others

Adapter

Zigate

Debug log

sniff 7400.zip

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days