link_quality is always 255

[gemo-bi]

Hello, the link_quality of my devices are 255 or 10 Zigbee-Adapter 1.8.10 Nodejs: v18.14.2 few days ago it still worked. Is it related to a firmware update from the Conbee2 stick?

debug-log in ioBroker: zigbee.0 | 2023-02-28 18:55:13.671 | warn | ELEVATED publishToState: value generated '255' from device a4c13804e80ab84a for 'Link quality'

Issue in zigbee: https://github.com/ioBroker/ioBroker.zigbee/issues/1692 asgothian's commented: This is an issue with the implementation of the deconz hardware in the zigbee-herdsman. There is nothing the zigbee adapter can do to fix this.

[FredWst]

Hi,

I've the same issue with 2 dongles ZBDongle-E sonoff (@ksjh firmware) and SkyConnect (original firmware). with NCP firmware all is fine but with RCP firmware had 255 LQI on all devices with both dongle.

[mamrai1]

but ZBDongle-E has no hardware cts/rts. Does it?

[ksjh]

It has. Not sure the original Sonoff Firmware supports hardware handshaking, but the ZBDongle-E uses Port D Pin 3 as CTS and Port D Pin 4 as RTS, so you can flash a firmware which supports RTS-CTS handshaking. EDIT: Not really, looking at the hardware, the RTS and CTS pins are unconnected on my ZBDongle-E.

[mamrai1]

:) it really does.. I just flashed ncp 7.1.40 with hardware flow control, adjusted configuration.yaml to rtscts: true and it works!! Thanks for the tip

[ksjh]

Attention: Even if my hardware flow control firmware somehow works, darkxst inspected his ZBDongle-E and found that the pins I used in my firmware based on information on github are unconnected. So, I did the same and found that this is also true for my ZBDongle-E v1.0 2022-03-22. Strange that my firmware somehow worked, but I will change my builds for this dongle in future not to include hardware handshaking any more. So, the current ZBDongle-E does not support RTS-CTS hardware handshaking, sorry for the confusion.

[mamrai1]

Weird.. Also all firmware builds from xs1989 with hw flow control also work with zbdongle e...

[MattWestb]

Flow control hard or software is only blocking then the buffer is being full and normally is not happening so you need filling up the buffer for see if its haling sending or you is loosing packages.

[ksjh]

So the hardware is luckily implemented in a way that the software sees both RTS and CTS as asserted. Good. If one or both would always be seen as cleared (not set), the communication would never start.

The limit on the buffer size was also the reason why I never configured baud rates higher than 115200 for devices without flow control. At least, when sending to Zigbee, you should be safe. But on the other hand, when you receive data from Zigbee, you might have a problem with low data rates on the interface to the host.

Is there any experience how well software flow control works and/or up to which data rates buffers do not or seldomly overflow? Of course, you would need a high rate of messages, so possibly a very large Zigbee net to gain meaningful experience here.

[MattWestb]

Very unlikely with one Zigbee network but 230400 shall being better if your hardware is OK with it (802.15.4 is max 256K). Im running 3 RCP with Zigbee and OTBR without flow control and one with 115200 then the comport is not liking it higher (is getting CRC failure) and the other 2 with 230400 but ideal for multi pan is 460800.

If the flow control is needed and not working you is getting lost packages and the protocol is complaining if sequence numbers is wrong or broken frames so you is knowing it very well if its problems.

[ksjh]

@MattWestb great, thank you for quick answer. I will experiment a bit. I was aware of the 250 kbit/s in IEEE 802.15.4 per channel, but uncertain how the RTS/CTS is used in this implementation. I will experiment a bit more with higher data rates, since in normal cases, I expect much more messages from the wireless side to the host than from the host to the wireless side ("air interface") except for special occasions like OTA updates. My CH9102F on the ZBDongle-E should support data rates of up to 4 Mbps if they did not mess up the routing of the board. I mean, it does not look great, 2 vias each, a few centimeters track, but mainly separated through a ground fill, but also not awful. So, I expect 460800 baud should be not that much of a problem.

[mamrai1]

@ksjh just tried the ncp firmware for zbdongle-none but it doesn't connect at all with z2m.. Had to manually put it in bootloader to reflash it.. 'None' is supposed to be software flow control or none? I flashed it with elelabs ezsp utility. Does it matter?

[ksjh]

@mamrai1 The zbdongle-none uses uartdrvFlowControlNone. Some other person tried it, and for them, it basically worked (please note: 115200 baud, also when flashing from a running application, i.e., not bootloader). But may I suggest that we continue this discussion somewhere where it is more relevant, i.e. here or here? Thank you!

[MattWestb]

Sky Connect can running without problem with 460800 if the host side have OK USB implantation. And you mus calculating the overhead in every layer of all protocols for knowing where the bottleneck is and one user with Zigbee and OTBR have have problems with 60 OT devices with 115200 but the Zigbee is working OK at the same time.

HA have changing the standard for RCP to 460800 for not getting problems with much IPV6 traffic to and from the 802.15.4 mesh network over the comport bottleneck.

[ksjh]

Of course, you are right, there might be overhead from other layers, especially with zigbeed and the resulting encapsulation, the ballpark figures often provide a good enogh estimate (plumbing analysis). But I know, you are right, I should be more careful here, especially since I work at a university in the field of network performance evaluation...

[MattWestb]

Then you shall knowing how the flow control is working and can doing nice performance test on the 802.15.4 network :-))

[ksjh]

@MattWestb Would be a nice project. The flow control just confused me since I was not expecting that unconnected RTS and CTS pins in this hardware implementation are regarded as asserted, i.e., the signals are active low and the pins pulled to ground. If the manufacturer would have them left floating, communication would not have worked and I would have noticed earlier.

[darkxst]

eless side to the host than from the host to the wireless side ("air interface") except for special occasions like OTA updates. My CH9102F on the ZBDongle-E should support data rates of up to 4 Mbps if they did not mess up the routing of the board. I mean, it does not look great, 2 vias each, a few centimeters track, but mainly separated through a ground fill, but also not awful.

In terms of RF design 4mbps is still very slow, you generally dont need to worry too much about impedance matching and all that fun transmission line stuff, like you would with say the differential pairs of High Speed USB.

[github-actions[bot]]

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