Unusual LQI values when using Raspbee II with Zigbee2MQTT.

[m0wlheld]

Describe the question or issue you are having

When using Raspbee II with Zigbee2MQTT, LQI values of devices increase over time to 255, then fall to to zero. There is an issue report at Z2M suggesting this is a known firmware bug.

Looking for comments on this.

Screenshots

Visual LQI representation, based on values reported by Zigbee2MQTT.

Environment

• Host system: Raspberry Pi 4B 4GB
• Running method: Raspbian / Zigbee2MQTT (latest) in Docker / Home Assistant (latest) in Docker / MQTT Integration
• Firmware version: 0x26690700
• deCONZ version: n/
• Device: RaspBee II
• Do you use an USB extension cable: n/a
• Is there any other USB or serial devices connected to the host system? none

deCONZ Logs

n/a

Additional context

[Mimiix]

@ChrisHae I think this is your street?

[m0wlheld]

@Mimiix Nice try :)

ChrisHae commented on 1 Dec 2020

LQI problem is not in my hands and will be fixed with future firmware release.

https://github.com/Koenkk/zigbee2mqtt/issues/4039#issuecomment-736518177

[Mimiix]

@m0wlheld Not sure if that is sarcasm or anything....

AFAIK he does the firmwares.

[m0wlheld]

@m0wlheld Not sure if that is sarcasm or anything....

Just a smile.

AFAIK he does the firmwares.

He might do the firmware but the "LQI problem is not in his hands". So I assume that he depends on contribution of others.

[Mimiix]

He's a developer at Dresden-Elektronik. He works for Manuel.

[m0wlheld]

Okay. So, based on his comment, Dresden Elektronik should be aware of this issue. Hence the polite inquiry whether they want to address the problem and solve it shortly or consider it low priority or not relevant?

[Mimiix]

I've asked manuel internally. Not sure if this is the correct repository. Let's await him :)

[manup]

It's already on the internal issue list.

However to be honest I would not recommend to use the incoming message LQI value as indicator for signal quality since every device on the path can scramble the value how it likes. People often get a false impression wether the device connection is good without looking at the actual mesh.

I find the values coming from ZDP Mgtm_LQI_req to query neighbor tables much more suitable to reason about the Zigbee Mesh quality. These are usually shown in a map as in deCONZ GUI where the LQI in both directions between two devices can be seen. I think zigbee2mqtt also provides theses values in a visual map.

[m0wlheld]

Thank you, really appreciate your response.

[kwetnico]

It's already on the internal issue list.

However to be honest I would not recommend to use the incoming message LQI value as indicator for signal quality since every device on the path can scramble the value how it likes. People often get a false impression wether the device connection is good without looking at the actual mesh.

I find the values coming from _ZDP Mgtm_LQIreq to query neighbor tables much more suitable to reason about the Zigbee Mesh quality. These are usually shown in a map as in deCONZ GUI where the LQI in both directions between two devices can be seen. I think zigbee2mqtt also provides theses values in a visual map.

I was using LQI value under zigbee2mqtt before but no longer also works with Conbee2 key. I have no other feedback under zigbee2mqtt to get the signal. Too bad because the key works very well.

[s3frank]

I too have this issue and I am a bit confused with the response so far. Perhaps the Deconz repo developers are not the right group I am not sure, but I would expect Dresden's team to take such a bug serious and plan a fix in a future release. From the responses here I get the feeling you would rather not as you don't think the implementation today is worth fixing.

Forgive me but the stick should comply to standard and report correct value. Today it doesn't and even if what you say is true that "every device on the path can scramble the value how it likes" that is no reason to allow a faulty product in market to continue.

Shall we remove speedometers from our cars since people can choose to not follow the rules anyway at times?

I would really appreciate this bug to get fixed so that I can look at the scrambled values :-D

[craigmcgowan]

I too am having this issue and would appreciate a fix. Thank you

[TRIROG]

Just chiming in as another user pested by this issue. Please fix!

[Patrryk]

I also would be grateful for fixing this issue.

[kwetnico]

No news ? 😢

[Mimiix]

@kwetnico Nope. This is one of those things that probably takes a fairly long time to get fixed as there are other priorities.

[docpayce]

Yup, same problem here. Driving me crazy.

[thackel]

Just because its sooooo nice looking:

[kwetnico]

@kwetnico Nope. This is one of those things that probably takes a fairly long time to get fixed as there are other priorities. Hello There have been no firmware updates for weeks, and bad LQI failures should be a priority i think .. it's been a long time now ...

[Mimiix]

@kwetnico Please check @manup 's reply:

However to be honest I would not recommend to use the incoming message LQI value as indicator for signal quality since every device on the path can scramble the value how it likes. People often get a false impression wether the device connection is good without looking at the actual mesh.

_I find the values coming from ZDP Mgtm_LQIreq to query neighbor tables much more suitable to reason about the Zigbee Mesh quality. These are usually shown in a map as in deCONZ GUI where the LQI in both directions between two devices can be seen. I think zigbee2mqtt also provides theses values in a visual map.

[kwetnico]

@kwetnico Please check @manup 's reply:

However to be honest I would not recommend to use the incoming message LQI value as indicator for signal quality since every device on the path can scramble the value how it likes. People often get a false impression wether the device connection is good without looking at the actual mesh.

_I find the values coming from ZDP Mgtm_LQIreq to query neighbor tables much more suitable to reason about the Zigbee Mesh quality. These are usually shown in a map as in deCONZ GUI where the LQI in both directions between two devices can be seen. I think zigbee2mqtt also provides theses values in a visual map.

Hello i don't have this value on zigbee2mqtt interface.. I have just LQI

[Gr4ffy]

I have the same issue, fix it!

[m0wlheld]

I have the same issue, fix it!

The tone of voice may be inappropriate, but the fact that the incorrect LQI display is considered a problem for many should finally affect the urgency of a solution.

[Mimiix]

I have the same issue, fix it!

The tone of voice may be inappropriate, but the fact that the incorrect LQI display is considered a problem for many should finally affect the urgency of a solution.

It is inappropriate.

[Gr4ffy]

Sorry, but this is not free project, i paid for it. So, in my opinion it is appropriate. They know about it since Sep 2020.

[Mimiix]

You paid for a stick, which functions fine with it's shipped software 😅. Does it make your device completely not unusable? I don't think so.

[m0wlheld]

Let's just state that there is a great deal of interest in a short-term solution. The reproduction of correct, comparable LQI values is a necessary prerequisite for the analysis of a Zigbee network. Comparable to the bar graph on cell phones or the palm tree on WiFi.

[Mimiix]

That i can understand, but the answer has been given by Manup: It's on the internal issue list. I just want to reflect the truth here and provide a answer close to the reality.

I don't know about what's on that list, but if i compare this issue with what else is going on with deCONZ: It might be a low prio. Not because it's not a big issue, but mostly as there's a work around and that LQI isn't that reliable.

[kwetnico]

That i can understand, but the answer has been given by Manup: It's on the internal issue list. I just want to reflect the truth here and provide a answer close to the reality.

I don't know about what's on that list, but if i compare this issue with what else is going on with deCONZ: It might be a low prio. Not because it's not a big issue, but mostly as there's a work around and that LQI isn't that reliable.

It is sure that there are other priorities because no new Conbee2 firmware since the end of 2020 ... The LQI is a priority you have opened this key on other software (like zigbee2mqtt) and well done but you owe us the same support and not just display it as a commercial argument. (sorry for my English)

[Mimiix]

To make things clear: I am not employed or representing the manufacturer here. Everything i reply is on personal note. So i don't owe anything to anyone. If it was up to me, a lot was fixed already but i can't make that happen.

Just trying to provide a bit of realistic picture of how things are.

[s3frank]

I think what would be better to ask and understand at this point is what it would take for Dresden to change it's priorities and move this one up? It's a classic closed source problem that an open source model would have never allowed for. Perhaps you should trust the user community a bit more and seek out their help / contribution. I would even pay an upstream developer a bit of a bounty for example. But we now have no options....but move away.

On Mon, Mar 22, 2021 at 8:41 PM kwetnico @.***> wrote:

That i can understand, but the answer has been given by Manup: It's on the internal issue list. I just want to reflect the truth here and provide a answer close to the reality.

I don't know about what's on that list, but if i compare this issue with what else is going on with deCONZ: It might be a low prio. Not because it's not a big issue, but mostly as there's a work around and that LQI isn't that reliable.

It is sure that there are other priorities because no new Conbee2 firmware since the end of 2020 ... The LQI is a priority you have opened this key on other software (like zigbee2mqtt) and well done but you owe us the same support and not just display it as a commercial argument. (sorry for my English)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4234#issuecomment-804030953, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQW7CTSFWCXMY55IFCLPMTTE43I3ANCNFSM4WI2NC6Q .

-- Best regards,

-FF

[s3frank]

Sorry about that Dennis, but could you point us all in the right direction so that our thoughts end up at least with someone who can potentially influence things?

On Mon, Mar 22, 2021 at 8:44 PM Dennis D @.***> wrote:

To make things clear: I am not employed or representing the manufacturer here. Everything i reply is on personal note.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4234#issuecomment-804032692, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQW7CR4Z6NQ7Y3QHMCQUWLTE43UHANCNFSM4WI2NC6Q .

-- Best regards,

-FF

[Mimiix]

@s3frank I agree with you. And i wish i could do that as the community manager.

I already send a PM to Manup to adress this and i hope he replies soon. There's a lot on my list currently that i want fixed for the community, including this issue.

So there's things in motion, but i can't force him to read and reply.

[nilvanis]

I'm observing exact same issue with Conbee II with Z2M, it's really annoying. I really hope this can be sorted out in a reasonable future.

[kwetnico]

Latest firmware released for the Conbee2 on 11/30/2020 I think that the LQI problem will not be fixed, unfortunately, a real shame because it works very well otherwise ... no more updating ...

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[kwetnico]

Always not news for update firmware and LQI problem fixed

[Gr4ffy]

Still not fixed, waiting for support @ dresden-elektronik

[manup]

Hi everyone, after deep digging into the stack sources I found that the LQI value delivered from the MCU in the PHY frame was modified with some obscure ED value from another register. I'm not sure what to make out of this but have now changed the code to just take the raw value (I guess that's what other stacks do as well).

Here is the corresponding firmware if you like to give it a try:

deCONZ_ConBeeII_0x266d0700.bin.zip

Important: As I have written above, I highly advise AGAINST using the frame LQI value because it doesn't provide the information you are looking for. Every device on a route can and does mess with this value by some random interpretation of the standard, also a person moving around devices affects this value immediately.

A much better way to look at mesh quality is to use the LQI values provided by the ZDP Mgmt_Lqi_rsp which are usually shown in a visual map like in deCONZ / Zigbee2Mqtt and ZHA. This LQI value is build up over time without the noise and comes straight from a device without other devices messing around with it on the route.

[s3frank]

Is this an official build from the company that has gone through QE and release management?

On Thu, May 13, 2021 at 11:39 PM Manuel Pietschmann < @.***> wrote:

Hi everyone, after deep digging into the stack sources I found that the LQI value delivered from the MCU in the PHY frame was modified with some obscure ED value from another register. I'm not sure what to make out of this but have now changed the code to just take the raw value (I guess that's what other stacks do as well).

Here is the corresponding firmware if you like to give it a try:

deCONZ_ConBeeII_0x266d0700.bin.zip https://github.com/dresden-elektronik/deconz-rest-plugin/files/6473444/deCONZ_ConBeeII_0x266d0700.bin.zip

Important: As I have written above, I highly advise AGAINST using the frame LQI value because it doesn't provide the information you are looking for. Every device on a route can and does mess with this value by some random interpretation of the standard, also a person moving around devices affects this value immediately.

A much better way to look at mesh quality is to use the LQI values provided by the ZDP Mgmt_Lqi_rsp which are usually shown in a visual map like in deCONZ / Zigbee2Mqtt and ZHA. This LQI value is build up over time without the noise and comes straight from a device without other devices messing around with it on the route.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4234#issuecomment-840646221, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQW7CV4AX2IS5AWNDJ3LHTTNPXEZANCNFSM4WI2NC6Q .

-- Best regards,

-FF

[kquinsland]

Is this an official build from the company that has gone through QE and release management?

It's published in the beta directory, so perhaps not fully?

[manup]

Right this version is currently in beta for testing I expect one or two more smaller versions until it hits stable within the deCONZ v2.12.x release cycle.

[kwetnico]

Who is going to test the beta and see if the lqi is fixed ?

[Mimiix]

@kwetnico why don't you test it yourself 😅? As far as manup can tell it's fixed. It's not that anything breaks.

[kwetnico]

@kwetnico why don't you test it yourself 😅? As far as manup can tell it's fixed. It's not that anything breaks.

The last time I flashed the Conbee2 I lost the visual links on the z2m map ... I would like to be sure it works and not have to reassociate all my devices

[manup]

@kwetnico why don't you test it yourself 😅? As far as manup can tell it's fixed. It's not that anything breaks.

The last time I flashed the Conbee2 I lost the visual links on the z2m map ... I would like to be sure it works and not have to reassociate all my devices

I've seen this a few days ago as well, this is currently under investigation. In case this happens unplug / reattach of ConBee should bring it all back. Note you never need to reassociate all devices again. All devices keep the network configuration in NVRAM in worst case the configuration in ConBee needs to be checked and updated.

[kwetnico]

I will wait for a sacrifice from one person to test this latest firmware ..☺️

[Gr4ffy]

Hi everyone, after deep digging into the stack sources I found that the LQI value delivered from the MCU in the PHY frame was modified with some obscure ED value from another register. I'm not sure what to make out of this but have now changed the code to just take the raw value (I guess that's what other stacks do as well).

Here is the corresponding firmware if you like to give it a try:

deCONZ_ConBeeII_0x266d0700.bin.zip

Important: As I have written above, I highly advise AGAINST using the frame LQI value because it doesn't provide the information you are looking for. Every device on a route can and does mess with this value by some random interpretation of the standard, also a person moving around devices affects this value immediately.

A much better way to look at mesh quality is to use the LQI values provided by the _ZDP Mgmt_Lqirsp which are usually shown in a visual map like in deCONZ / Zigbee2Mqtt and ZHA. This LQI value is build up over time without the noise and comes straight from a device without other devices messing around with it on the route.

Same behavior, LQI 0-> 255-> 0-> 255 ....

Zigbee2MQTT version
1.18.3 commit: f2e39af
Coordinator type
ConBee2/RaspBee2
Coordinator revision
0x266d0700

[s3frank]

Thanks for trying that out mate....and sad to see this didn't do the trick :-(

On Sat, May 15, 2021 at 10:37 PM Gr4ffy @.***> wrote:

Hi everyone, after deep digging into the stack sources I found that the LQI value delivered from the MCU in the PHY frame was modified with some obscure ED value from another register. I'm not sure what to make out of this but have now changed the code to just take the raw value (I guess that's what other stacks do as well).

Here is the corresponding firmware if you like to give it a try:

deCONZ_ConBeeII_0x266d0700.bin.zip https://github.com/dresden-elektronik/deconz-rest-plugin/files/6473444/deCONZ_ConBeeII_0x266d0700.bin.zip

Important: As I have written above, I highly advise AGAINST using the frame LQI value because it doesn't provide the information you are looking for. Every device on a route can and does mess with this value by some random interpretation of the standard, also a person moving around devices affects this value immediately.

A much better way to look at mesh quality is to use the LQI values provided by the ZDP Mgmt_Lqi_rsp which are usually shown in a visual map like in deCONZ / Zigbee2Mqtt and ZHA. This LQI value is build up over time without the noise and comes straight from a device without other devices messing around with it on the route.

Same behavior, LQI 0-> 255-> 0-> 255 ....

Zigbee2MQTT version 1.18.3 commit: f2e39af Coordinator type ConBee2/RaspBee2 Coordinator revision 0x266d0700

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4234#issuecomment-841668522, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQW7CQRKR6NMVOKFY5RQK3TN2BK3ANCNFSM4WI2NC6Q .

-- Best regards,

-FF

[kwetnico]

Me too sad