Idea: consider adding the LinkQuality value for device reporting

Frans-Willem / AqaraHub

AqaraHub is an open-source Zigbee hub for Xiaomi Aqara devices. It aims to be a replacement to the Xiaomi Gateway that does not require communication to outside servers, and uses a saner communication option (e.g. MQTT).

252 stars 34 forks source link

Idea: consider adding the LinkQuality value for device reporting #19

Closed Gabor9 closed 6 years ago

Gabor9 commented 6 years ago

LinkQuality value reported in znp(?) level messages and related to wireless coverage of end devices. Bringing it up to mqtt level it could be vital to check the health of the network.

Frans-Willem commented 6 years ago

How do you think it should be reported? Technically it's sent with all received messages, even non-reports. Maybe we should send it to a seperate topic? e.g. AqaraHub/report/12345678/linkquality ?

Frans-Willem commented 6 years ago

I've implemented something that will send the link quality for each received message. Example:

AqaraHub/report/158D000152D7B2/linkquality 115
AqaraHub/report/158D00015D231D/linkquality 118

Hope this is what you were expecting :)

Gabor9 commented 6 years ago

Ideally should be sent together with extended status reports only (like the Battery reports in xFF01, xFF02) - to keep the traffic light. Separate topic sounds good

Gabor9 commented 6 years ago

Great! I can live with the "on each message version too" :)

Gabor9 commented 6 years ago

Additional info:

If a sensor comes online and choose to connect through a Repeater node (i.e the lumi.plug) then Linkquality is reported for the sensor is actually the Repeater's Linkquality value.
The signal range is better with lumi.plug than with CC2531 USB stick from the same location.

Frans-Willem commented 6 years ago

I'd already noticed the reception with the CC2531 stick was rather bad. Good to hear just plugging in a lumi.plug increases the range :)