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 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
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 -:
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 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
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.
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
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
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 . 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.