How difficult would it be to add new attributes to the mqtt messages ?
running zigbee2mqtt with DEBUG=* I can see attributes I would find useful to report:
what's the timestamp reference btw ? is that something the device reports or is that a timestamp the gateway creates ?
I really think that link quality would be a handy thing to track. I am just now realising how poor the range is on these devices.
If I may, could it be possible to add a last_seen attributes to every mqtt payload ?
this timestamp would be generated by the host, and would help to know when was the last update.
it could also be of some use for retained messages.
While being wary of json bloat these would be useful to use
Sent with GitHawk
@lolorc yes, this is indeed nice to have.
@Koenkk We should use the pollTimer function from controller.js and use the
Query the link quality index from a certain device by its ieee address. function from zigbee-shepherd.
Or maybe you麓v got another idea :) ?
@tb-killa I think for every received zigbee message we should parse the linkquality and add it to the message.
I found this information with DEBUG=* npm start, it parsed from cc-znp like this
cc-znp:AREQ <-- AF:incomingMsg, { groupid: 0, clusterid: 3, srcaddr: 14129, srcendpoint: 3, dstendpoint: 1, wasbroadcast: 0, linkquality: 0, securityuse: 0, timestamp: 12584614, transseqnumber: 0, len: 7, data: <Buffer 18 09 0d 01 00 00 21> } +2s
@Koenkk Do you know if we got this Information inside zigbee-shepherd too ?
I search for link and found references inside lib/components/af.js
It seems to be that it could be available via
case 'incomingMsg':
..
case 'incomingMsgExt':
..
case 'zclIncomingMsg':
..
If you point me i could maybe help :)
Added the linkquality attribute to the messages.
E.G.
2018-7-29 22:08:54 INFO MQTT publish, topic: 'zigbee2mqtt/0x00158d0001d8e1d2', payload: '{"click":"double","linkquality":36}'
Regarding link quality, what do the numbers represent? Lower the number = better or worse signal for example? What's the number range?
TIA
My routers are both at 2 and 5, not a good sign. :(
The lower the number the worst the signal, 2 and 5 are indeed very low.
In the same room I get somewhere between 50-100.
Hi there,
I've just updated from your latest changes, I correctly get the linkquality attribute, Thanks a lot.
Any idea what would be the higher value ? Been able to get 148 by bringing a device just in front of the coordinator.
how do you plan on implementing the last_seen attribute ? Would it be a simple timestamp locally generated from the local time of the computer running the zigbee2mqtt daemon ?
I guess that would be enough since the zigbee timestamp attribute is holding a relative number.
Found some interesting how to get RSSI value
https://sunmaysky.blogspot.com/2017/02/conversion-between-rssi-and-lqi-in-z.html
closing, reporting timestamp/last_seen for later :)
Most helpful comment
The lower the number the worst the signal, 2 and 5 are indeed very low.
In the same room I get somewhere between 50-100.