Less reliable Zigbee (range?) in 2.3.4.140?

💬 Lounge Debate Chamber
1

I have a very basic setup at home on my second HE (more extensive in my holiday home), so at home I tend to update more often when a new version comes out.

With the latest version 2.3.4.140, It seems that the Zigbee is less stable with devices on my network.

I currently only have 3 devices connected (battery), 2 Philips motion sensors and a Aqara temperature sensor. 2 of them are located on the second floor and the HE on the first. They all worked before I updated to 2.3.4, but since the update it seems they are less reliable than before, and do not always work, but the routing table still shows them as connected.

The Aqara sensor is still sending data, but the Philips motion sensor on the 2nd floor, in the same room as the Aqara, is not. I even re-paired it yesterday.

I noticed one Zigbee related change in 2.3.4.116 which I wonder if it could be the cause of this?:

  • Added a cooldown period between failed Zigbee restart and another attempt to avoid radio spamming.

As a test, I added a Philips Outlet about halfway to the upstair sensors for repeating purposes to see if that will fix it. As of now, it does not seem to have changed anything.

I don´t see the "Bathroom motion sensor" in the routing table, but by doing a refresh I get the temp. However the sensor will not trigger by motion. I went back to re-pairing the sensor with no success.

Periodically since re-pairing, it will send me the LUX and Temp, but will not trigger by motion. Although motion is now shown in the Events, it does not trigger the rules?

Now keep in mind that I am writing this while testing, so after some back and forth it now seems to work, after I enabled Debug logging?

However, the Bathroom motion sensor is not shown in the routing table?

Not sure what to make of this? All suggestions welcome. I have yet to revert to the previous firmware, not sure I will do that if this now works though.

New Routing Table

image
image780×445 7.19 KB

The routing table before adding the Outlet

image
image780×445 7.19 KB

2

Can you make a test?
Temporary change the Philips outlet driver to the HE inbuilt driver named "Ikea TRADFRI Signal Repeater"

image
image1079×297 18.4 KB

Make sure the 'enable route and LQI logging' is enabled:
image

Then click on the 'Get Link Quality' button.
Do you see logs like this?

image
image1238×104 16.5 KB

(Don't forget to return to the driver that you were using with the Philips Outlet before)

1 Like
3

That was interesting, it seems to confirm that the Bathroom motion sensor is indeed connected via the Outlet, but not shown in the routing table.

image
image1066×61 11.8 KB

The Philips Outlet just uses the Generic Zigbee Outlet driver.

4

I am not 100% sure how to interpret these logs..

Another repeating device has the "Get Route Table" command working :

image
image1177×390 51.2 KB

5

I did a retake, now also with Route info, but very sparse information:

image
image1082×449 81.3 KB

In any case, the motion sensor is working now, so I will just leave the plug as a repeater.

But with that said, the question still remains if a change in the latest 2.3.4.116 FW resulted in the devices dropping off in the first place?

1 Like
6

There were no changes in 2.3.4.116 that could have caused this.

2 Likes
7

The only end devices that will always show on the getchildandRouteinfo page are those that are direct-connected child devices of the hub and not going through other repeaters (if you had access to the child table of the other repeater, that's where the missing device would show up).

They may occasionally show up in the route table entry section (along with a reference to the first hop router used to reach them) but those entries are just recently cached route request references and not static entries.

4 Likes
8

No, this only matters if Zigbee goes down for some reason. There would be a location event for that, too.

2 Likes
9

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.