After finally trying Zigbee2MQTT for the first time recently, it made me realize how much deconz is missing, along with LQI values for each device in the API (something Z2M exposes along with all the clusters). Have the LQI values exposed is extremely valuable for tracking network issues over time, one can then use a device database (built into many home automation platforms) to store the LQI readings over time and see when degradation happens due to environment issues/changes.
We can obviously see the LQI values in the deconz GUI map, why can’t we see them via the API?
In short: Because they (one LQI value for device X) are useless and the cause of totally misleading and wrong assumptions.
To make more sense of of network quality all values between nodes need to be considered, which basically are the neighbor tables of routers, these are visualized by deCONZ and other projects in the network graph. But here is the bummer, even with all these values this should only be seen as a coarse indicator how things are. Calculation of LQI values is device dependent and sometimes completely wrong (looking at OSRAM / LEDVANCE). More problematic is also that the neighbor tables tell nothing about the actual routes being used between devices and how the ok/error rate is.
Note: The neighbor tables are currently not exposed via REST-API but will be with the move to a different model which is needed for the new GUI.
Imho, although many projects including deCONZ use LQI stuff to determine network quality it is often misleading. I think the application based source routes in deCONZ are a better way to determine network quality since it only uses LQI values as starting factor but then actually observes how reliable routes are and records TX ok/errors, or put it in a another way the mechanism never trusts LQI values.
The source routes and their stats will also be exposed via API to provide an actual picture which paths through the network are reliable.