Zigbee Channel?

no I actually found out its a Mi IO problem

the issue gone from the Mi IO Binding as Marc provided a fix and threads are back to normal.
however I still see a extremely volatile performance on zigbee

few times its almost instant … but often it seems to timeout fully
I put the binding to debug but dont see as much as for zwave in the log

is there more from the zigbee bundles I need to put into debug?

334 │ Active │ 80 │ 1.3.4 │ com.zsmartsystems.zigbee
335 │ Active │ 80 │ 1.3.3 │ com.zsmartsystems.zigbee.console
336 │ Active │ 80 │ 1.3.4 │ com.zsmartsystems.zigbee.console.ember
337 │ Active │ 80 │ 1.3.3 │ com.zsmartsystems.zigbee.dongle.cc2531
338 │ Active │ 80 │ 1.3.3 │ com.zsmartsystems.zigbee.dongle.ember
339 │ Active │ 80 │ 1.3.4 │ com.zsmartsystems.zigbee.dongle.telegesis
340 │ Active │ 80 │ 1.3.4 │ com.zsmartsystems.zigbee.dongle.xbee
341 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons :: Bundles :: ZigBee Binding
342 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons :: Bundles :: ZigBee CC2531 Bridge
343 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons :: Bundles :: ZigBee Console
344 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons :: Bundles :: ZigBee Console Ember
345 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons :: Bundles :: ZigBee Ember Bridge
346 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons :: Bundles :: ZigBee Telegesis Bridge
347 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons :: Bundles :: ZigBee XBee Bridge

I’m not sure what you’ve already done, so it’s hard to say if you need to add more… Check the binding docs - that provides the debugging log information.

So I created a log when the performance was very low or the devices just do not react.
Could you look at it if you find something?
I see retries and adress unknown e.g.
I have a very small zigbee network of 3 mains devices.

It is very volatile … sometimes instant (mostly after a restart of openhab) and then it gets worse up to devices just don’t react anymore to any actions


I can’t see any reason for any delays - it seems most of the time (in this log at least) it works well and the delays are minimal (ie there are no delays other than what you’d expect) -:

In each of these commands, the response is received around 125ms after the command.

I do spot one command that seems to take longer, but there’s no clear reason why. There is no retry, so I can only guess there are delays outside of the binding somewhere.

@chris phew.
I moved one plug really close to the coordinator.
like 2 meters… works better now. when the first mains device was like 5 meters away I barely could switch that plug. so either my xbee sucks or zigbee range :wink:

I will further test…

EDIT: now I got it again - also with the plug close. I think maybe the pattern is when I start to use the item for “Color” selection.
thats the debug log:
I see a lot of “deliveryStatus=ADDRESS_NOT_FOUND” as soon when I use “color” the initally

another thing I stumbled over:
for the OSRAM lightfy I see in the documentation they have dynamic scened.
should that be discovered as a channel?

Maybe you’ve said earlier, but I can’t see it - what is this device?

No. the binding doesn’t support scenes.

created a visual for you :joy: with my huge zigbee network.

full size: https://drive.google.com/file/d/172L7yhVnQm_oHVBH-Aaw1ijg-tey7bz8/view?usp=sharing

I’m actually surprised that your system works at all. The signals are really extremely poor according to this graphic.

well it works sometimes…
where do you read poor signal in the device information in the graphic (lqi?) and is it related to the old zigbee standard from the devices or any tips what could help?

ah and thats the coordinator:

Yes, but you are asking me why it’s not working, and I can say it is due to poor signal. It’s quite clear.

Yes, LQI - Link Quality Indicator - it should be well above 200, and I see numbers like 20 in your system.

No - it’s related to poor wireless conditions. Either poor signal, or interference. LQI is link quality - not signal strength. So it’s an indicator of the number of packets that will successfully be received. Generally these values should be well above 200 - even at 200, the packet throughput is likely to result in 20% loss - at values around 50, you’re going to have a very high loss.

For information, below is what Silabs say about LQI for the Ember that you have -:

1 Like

thanks - its helpful for me to further look how I can solve it.

considering that even my close to coordinator wallplug has “only” and lqi ~200 this seems really strange.
I even switched the coordinator to channel 25 to get away from crowded wifi channels and I don’t have relevant bluetooth devices

I wonder if my xbee might be the problem

I tried and turned of my own wifi from the router which is close to the openhab server…
the devices are much more responsive. however LQI does not show that improvement. not sure if that value is maybe updated only when the mesh heal is done.

so I need
a) find a better channel
b) find another location for my openhab server
c) solve it with a zigbee dongle which has more power

I think the xbee has 4dbm and the bitron says their stick has 20dbm

Limited value in a mesh, though? Each pathway only as good as its weakest link, etc.

1 Like

It’s updated periodically - there’s a setting in the coordinator that sets how often this is updated.

This probably won’t help - it’s not about the server - it also affects other links.

As @rossko57 said, increasing the power in the dongle won’t help - you can see that in one device you have a depth = 2, and LQI=20. This means that this device is 2 hops away, and therefore increasing the coordinator power most likely won’t help. It might (maybe!) allow the coordinator to talk directly to a device, but it doesn’t mean that the device can talk directly back again as the link budget will only be improved in one direction.

I have a Intel NUC with a wifi card that is not used. Turning off wifi radio with rfkill improved zigbee quite a bit.
Likewise I see some people use a stright USB cable to get the stick at some distance from wifi radio.

1 Like

I have a zbox with wifi / Bluetooth.
It’s disabled in Ubuntu. Yet maybe it still is not really silent? I will check rfkill.


I guess some oscillators is running and creates interference.
Rf shielding was something we had in the past century…

Edit: But it would not help much 2 zigbee hops from the stick.
Only for interference between wifi radio and zigbee stick when they are close.
Anyway; Shutting down unused radios is a good thing :slight_smile:

Well I see that RFKILL actually shows already wifi and bluetooth as BLOCKED for my system
So I think the soft off from ubuntu itself did the job.

If I ever attach again a monitor to the server I would also disable it in the bios :wink:

the LQI is still the same and was not updated yet.
I looked up the the debug when the stick is initalized to see what parameter it is and what it is set to but did not see a specific parameter for this.
The “Mesh update intervall” I tried to change from the UI (my Coordinator is created via UI not a things file).
If I change the intervall there I see

09:49:27.570 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - null: Configuration received (Coordinator).
09:49:27.572 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - null: Configuration update: Processing zigbee_meshupdateperiod -> 86400
09:49:27.573 [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - null: Unhandled configuration parameter zigbee_meshupdateperiod >> 86400.


So I got a set of 4 mains plugs to have a better mesh… at least what I was hopeing for.
What I see now is my debug is spammed with NetworkAdressRequests

I don’t find a solution here. Could the Digi XBEE be the problem?

Edit: to add 1 More Observation I Made.
When I Switch the Plug on the Device it Instantly Updates the Status in openhab. When I try to Switch the Device from openhab it Takes very Long / multiple times to get it through

I see very few of these in your log :confused:. There are 4 in the log over a 1 minute period - this seems normal. If the device doesn’t respond, the binding asks again and it’s only happening every 10 seconds or so so I don’t really thing is is spam?

If you provide a log showing this issue I’ll take a look. It’s hard to comment otherwise - it is presumably because the device has other communications going on, or the network is not good since that’s the normal reason.