ebaauw
commented
3 years ago Looking at the sniffer, the TRV and the RaspBee seem to be in a Rejoin Request/Response loop.
The TRV continuously sends:
IEEE 802.15.4 Data, Dst: 0x0000, Src: 0xb64b
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: 159
Destination PAN: 0x476f
Destination: 0x0000
Source: 0xb64b
[Extended Source: Jennic_00:01:92:2b:01 (00:15:8d:00:01:92:2b:01)]
[Origin: 63]
TI CC24xx-format metadata: FCS OK
ZigBee Network Layer Command, Dst: 0x0000, Src: 0xb64b
Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
Destination: 0x0000
Source: 0xb64b
Radius: 1
Sequence Number: 147
Destination: dresden-_ff:ff:01:04:1e (00:21:2e:ff:ff:01:04:1e)
Extended Source: Jennic_00:01:92:2b:01 (00:15:8d:00:01:92:2b:01)
ZigBee Security Header
Command Frame: Rejoin Request
Command Identifier: Rejoin Request (0x06)
Capability Information: 0x00And the RaspBee responds:
IEEE 802.15.4 Data, Dst: 0xb64b, Src: 0x0000
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: 14
Destination PAN: 0x476f
Destination: 0xb64b
Source: 0x0000
[Extended Source: dresden-_ff:ff:01:04:1e (00:21:2e:ff:ff:01:04:1e)]
[Origin: 22]
TI CC24xx-format metadata: FCS OK
ZigBee Network Layer Command, Dst: 0xb64b, Src: 0x0000
Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
Destination: 0xb64b
Source: 0x0000
Radius: 1
Sequence Number: 97
Destination: dresden-_ff:ff:01:04:1e (00:21:2e:ff:ff:01:04:1e)
Extended Source: dresden-_ff:ff:01:04:1e (00:21:2e:ff:ff:01:04:1e)
ZigBee Security Header
Command Frame: Rejoin Response
Command Identifier: Rejoin Response (0x07)
Address: 0x0000
Status: Success (0x00)It it supposed to respond with address 0x0000? Shouldn't that be the address of the end device?
manup
github-actions[bot]
Describe the bug
I have a Eurotronic Spirit TRV connected directly to the RaspBee. The light on the node blinks green to indicate it's polling the RaspBee. Yet, deCONZ won't send any messages to the TRV, claiming the node queue is full. I tried power cycling the TRV (that usually remedies connection issues), resetting the RaspBee (using GCFFlasher), power cycling the RaspBee (by power cycling the Pi), but nothing seems to remedy the situation.
Steps to reproduce the behavior
It's a bit intermittent, but it seems to happen every time one of my TRVs selects the RaspBee as parent. This is on my second network, with only 8 Eurotronic Spirit TRVs, a FYRTUR blind, a TRÅDFRI open/close remote, and a TRÅDFRI repeater. The FYRTUR seems to prefer the RaspBee as parent, the others seem to prefer the TRÅDFRI repeater. But sometimes they switch parent.
The FYRTUR has been stable ever since I created the second network and moved the devices over. The TRVs are stable as long as they remain connected to the repeater. I've seen this issue with three or four different TRVs so far, every time they would connect to the RaspBee.
Interestingly,
lastseenon the ZHAThermostat resource is updated;state.lastupdatedisn't, suggesting the TRV isn't sending reports, or the RaspBee isn't forwarding them to deCONZ.Expected behavior
Obviously, deCONZ and the TRV should communicate.
Screenshots
Environment
deCONZ Logs
Additional context
All TRVs are on firmware 18181120, dated 20190408.
I've replaced the batteries on the TRV gone MIA with professional-grade lithium AA batteries (1.7V at 100%). I'm half suspecting the consumer-grade IKEA AA batteries; they drop voltage pretty quickly (under 1.4V at 80%, according to my battery tester), and the TRVs don't seem to like that.