memory as above 20% now
threads if my linux knowledge is right
Total running: 1262
For openhab: 611
MAx possible: 125610
really unsure what happens. just can tell before I used zigbee the uptime was a couple months.
I will continure to monitor and post here if I come to a conclusion
:~$ ps -eo nlwp | tail -n +2 | awk '{ num_threads += $1 } END { print num_threads }'
1262
:~$ ps -o nlwp 1193
NLWP
611
:~$ cat /proc/sys/kernel/threads-max
125610
If you keep using more resources though, then something will give. If you stop using some other bindings this will also help - it’s not the zigbee binding as such, but the total system. It’s like the old (english) saying - “the straw that broke the camels back” - each little bit of straw is fine, but sooner or later it’s too much 
well but my threads are at 1% of the max and memory at 20%
So I am not sure if the straw is that big or the camel that small :D:D:D
I will check the metrics again when it stalls next.
Ok, I’m not sure then - sorry. It doesn’t seem to be a generic problem, and the issue seems to be thread related, unless I’m reading this wrong -:
this morning the threads for openhab went up.
in 12 hours uptime they went from ~600 to ~2200 (only reporting the threads for the openhab pid)
almost 400% increase. while my thread max cap is at 120k this should still be no issue. however if they increase so strong in the next days it fits to my observation that it stalls after only few days.
any possibility to check within openhab what is using that threads?
best
ok for my future me
shell:threads --list
this shows that almost all threads go to
Mi IO MessageSenderThread: TIMED_WAITING
I will try to get some insights from @marcel_verpaalen on this
from ~2200 threads this process is consuming ~1900
You don’t say what process is consuming the threads? Can you see the thread names? Possibly there’s an issue with the S2 driver as that hasn’t had extensive testing (although I know people are using it and haven’t reported this in the past).
@chris
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
https://drive.google.com/file/d/100MH6MilJfz7Q6qFIwvOfu9SGQWnHwMc/view?usp=sharing
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 
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:
https://drive.google.com/file/d/1yc-Ks6_y25DFWRysPU_HE0vB8Ao3bPGA/view?usp=sharing
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 
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 -:
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
or
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.
