@shorty707 (Shorty707) posted a new topic, subject "Zigbee Channel?". It read:

   Hi  
    sorry I just started to play with the zigbee binding.  
    I have some OSRAM devices. A mains powered plug and 2 RGBW garden pole sets.  
    My controller is a DIGI Xstick 2 ZB.
    
    I intented to use the Plug as a repeater to have a route to the garden.
    
    However I see a massive latency… and try to gain some knowledge here.
    
    –> Should I set the Baud rate to highest possible for the xbee?  
    –> I can not change the channel. When setting it over paper ui it always jumps back to 20 (which was automatically set when the thing was created via UI)  
    –> So … any hints how a channel can be changed?  
    –> and are there channels that don't interfere with a 2,4ghz wifi?
    
    -> what is the flowcontrol setting for? and is hardware or software setting better?
    
    thanks

Then @chris (Chris Jackson) said

    shorty707:
    
    > –> Should I set the Baud rate to highest possible for the xbee?
    
    It probably won't matter as this won't impact the speed over the air.
    
    shorty707:
    
    > –> I can not change the channel. When setting it over paper ui it always jumps back to 20 (which was automatically set when the thing was created via UI)
    
    This I'm not sure about - you might need to use the digi software (it's been a long time since I wrote the S2 driver).
    
    shorty707:
    
    > –> and are there channels that don't interfere with a 2,4ghz wifi?
    
    In general - no. In practice - yes…
    
    By this, I mean that the 2.4 GHz spectrum is used by WiFi, BLE, DECT, 802.15.4 etc, etc. Each protocol allocates the complete spectrum, and the question is what channels you and your neighbours are using. Normally it's possible to find a clear channel, but I can't tell you which one it will be in your house.
    
    I know that a large hotel chain use ZigBee in some hotels and it works well. They have a separate network for each room and also have WiFi throughout the hotel and it all co-exists well.

So @NilsOF (Nils) replied

    this article explains the channels well: https://www.metageek.com/training/resources/zigbee-wifi-coexistence.html
    
    However I can not change the zigbee channel, it goes back to channel 11.  
    I really want to use channel 25 as that is more out of the way from my WiFi.
    
    This is on openhab 2.5.4-1 with a Bitronvideo stick  
    On the previous version (2.5.3-1 i think) there was a exception thrown.  
    I did not make any notes of that one…

@chris (Chris Jackson) replied

    I meant to post this earlier - this is a chart I use when I'm doing ZigBee training that shows the frequencies-:
    
    image711×262 19.1 KB

Then @chris (Chris Jackson) said

    NilsOF:
    
    > However I can not change the zigbee channel, it goes back to channel 11.
    
    I think I didn't provide this function in the binding since it can cause all sort of problems as there's no guarantee that all devices will change channels. If devices miss the channel change notification, then you can loose devices - depending on how well they implement the search to try and find the network again.

To which @NilsOF (Nils) replied

    I understand the implications with a channel change.  
    In my case I just started some testing with zigbee and want get it right from the start.

@shorty707 (Shorty707) replied

    chris:
    
    > I think I didn't provide this function in the binding since it can cause all sort of problems as there's no guarantee that all devices will change channels. If devices miss the channel change notification, then you can loose devices - depending on how well they implement the search to try and find the network again.
    
    So it is the channel should be set one time and FIRSt when the usb stick is created as thing? and then include all the devices with the intented channel?
    
    if so … Is there a way to describe the channel in the things file?  
    its not in the example.
    
    when created via the UI it actually offers baud rate, channel change etc. … all of it does not really work … so might confuse users   
    thanks

To which @chris (Chris Jackson) replied

    shorty707:
    
    > if so … Is there a way to describe the channel in the things file?
    
    The configuration name is `zigbee_channel`. I just checked though and for the S2 it is not implemented so you'd need to use the digi commander as I mentioned earlier.
    
    shorty707:
    
    > when created via the UI it actually offers baud rate, channel change etc. … all of it does not really work … so might confuse users 
    
    Well, if you find problems, then it is useful to report them  Otherwise we don't know. I will remove the channel setting from the S2 as I've just confirmed this isn't implemented.

@chris (Chris Jackson) replied

    I should add that baud rate does work - but you need to understand that it is to configure the baud rate of the link to the S2 in the binding - it can't change the baud rate of the S2 itself since since that would require a before and after setting

Then @shorty707 (Shorty707) said

    chris:
    
    > digi software
    
    well thanks for pointing me a step further
    
    I now used the Digi Software XCTU and flashed to a newer version  
    Now I could configure the device a little further  
    but more newbie questions come up 
    
    –> it allows me to disable security. Can I use it without in the binding? and is it advisable?  
    
    
    image1040×175 3.89 KB
    
    –> must the config for Baud Rate and e.g. CTS flow control match my thing definiton in openhab?  
    
    
    image1053×256 10.4 KB
    
    –> I cant edit the channel (after flashing the firmware its 14). anyone who knows this tool better if I can change it somewhere?  
    
    
    image1091×361 17.6 KB
    
    best

So @chris (Chris Jackson) replied

    shorty707:
    
    > –> it allows me to disable security. Can I use it without in the binding? and is it advisable?
    
    ZigBee won't work without security so I'd recommend not to do this. ZigBee uses multiple layers of security, but pretty much everything requires at least transport layer security.
    
    shorty707:
    
    > –> must the config for Baud Rate and e.g. CTS flow control match my thing definiton in openhab?
    
    Yes - this allows you to configure the S2 to some definition. You then need to make the binding exactly the same configuration so that the binding can communicate with the stick.
    
    shorty707:
    
    > –> I cant edit the channel (after flashing the firmware its 14). anyone who knows this tool better if I can change it somewhere?
    
    Sorry - I'm not sure about that.
    
    I see you hid your PANID - I wouldn't bother as it is 100% in the open anyway if someone wanted to sniff your network. ZigBee is a secure system - it doesn't rely on obscuring information such as the network ID etc. The network ID is sent in broadcasts and could be easily picked up by anyone in range.

After which, @shorty707 (Shorty707) added

    chris:
    
    > Sorry - I'm not sure about that.
    > 
    > I see you hid your PANID - I wouldn't bother as it is 100% in the open
    
    thanks wasnt sure … when I see an uneditable ID i tend to hide it :D:D:D
    
    I read more docu from DIGI now and it says their ZB series of zigbee coordinators scans the channels and selects automatically one which is not so crowded …  
    you said before to change a channel is not a good idea so I hope the firmware got a good glass bowl to know which channel stays less crowded in the future

Then @chris (Chris Jackson) said

    I don't think the firmware will change the channel - Embers don't typically do this and I'd be a little surprised if Digi decided to change the Ember default too much - I think they've basically just added a different API.
    
    Maybe one day I'll look at adding this - it's just for now something more to cause problems so best left out

To which @shorty707 (Shorty707) replied

    chris:
    
    > I don't think the firmware will change the channel
    
    yes I meant to say it does a scan and self detects a good channel
    
    image949×153 28.1 KB

Then @chris (Chris Jackson) said

    shorty707:
    
    > yes I meant to say it does a scan and self detects a good channel
    
    Currently the binding does this when creating a new network, but it will still use the channel that you request rather than the quietest channel - it's something I need to change when I get a chance…

@NilsOF (Nils) replied

    a autoscan can be a good thing as a default on a new network.  
    Unless I told it to use channel x. I then expect it to stay there   
    The binding can not see the rf situation at the not yet installed future third zigbee-hop.
    
    In my case I planned to use zigbee channel 25 before I ordered the USB stick. Plan B was to shift up all my WiFi APs a notch and use channel 11.
    
    Do a tool for the Bitronvideo stick exist?

So @chris (Chris Jackson) replied

    NilsOF:
    
    > a autoscan can be a good thing as a default on a new network.
    
    The binding does already perform a scan on a new network. Currently it just prints the results in the log - it doesn't use the channel.
    
    NilsOF:
    
    > The binding can not see the rf situation at the not yet installed future third zigbee-hop.
    
    Sure - but it does get this information later once the network is established. I've posted elsewhere, but one of my customers is a large hotel chain that has a ZigBee network in each room. We tested this in a hotel with hundreds of room, and WiFi - all co-existing together just fine. The binding was configured to use the scan information, but still with such a large system it works well.
    
    NilsOF:
    
    > Do a tool for the Bitronvideo stick exist?
    
    No - the binding controls this.

After which, @NilsOF (Nils) added

    chris:
    
    > No - the binding controls this.
    
    ok, I tried to add “zigbee_channel=25” to my .things file, but paperui still reports channel 11.  
    In this process I watched the logs. I could not see anything that looked like a channel change, or a channel scan.  
    Do I have to set some debug logging to see this?

So @chris (Chris Jackson) replied

    Are you initialising the network? Please debug provide the log so I can see what you are doing.
    
    NilsOF:
    
    > Do I have to set some debug logging to see this?
    
    If you don't have debug logging set, then the logging will be minimal and you won't really see much, so yes, if you're debugging, please use DEBUG log level

To which @NilsOF (Nils) replied

    chris:
    
    > Are you initialising the network?
    
    Do I have other options than restarting the binding?  
    The Thing for the USB stick is probably marked as not editable in the rest api so paperui give a error when trying the “reset”…  
    Or are there other ways?

Then @chris (Chris Jackson) said

    NilsOF:
    
    > Do I have other options than restarting the binding?
    
    If you are using text files, then the only way is going to be to restart the binding. Unfortunately openHAB blocks any configuration for devices that are configured through files.

Then @NilsOF (Nils) said

    I have a debug log file, and it looks like the channel is changed, but paperui does not pick it up.  
    I have to go out right now, will massage down the log (it is HUGE) and upload it somewhere later tonight if it is still of interest.

So @shorty707 (Shorty707) replied

    chris:
    
    > Are you initialising the network? Please debug provide the log so I can see what you are doing.
    
    just to fully understand this.
    
    via text config I can change the channel.  
    it will be used when I restart the binding.
    
    or I can only set a channel once when no device is paired to the coordinator?
    
    best

@chris (Chris Jackson) replied

    You can only set the channel when the network is first initialised. There is an “Reset Controller” option in the coordinator - you can generally only set the channel when this is set.

After which, @shorty707 (Shorty707) added

    chris:
    
    > There is an “Reset Controller” option in the coordinator - you can generally only set the channel when this is set.
    
    Thanks. I think I will try it as my current channel is 20 and I would rather go to 26 in the hope to be at the edge of wifi … and I am mostly ybluetooth free.

After which, @NilsOF (Nils) added

    @chris  
    Do the “reset” do the same as a restart of the binding, or is it a more gentle approach?
    
    There must be something that is out of sync somewhere as paperui say channel 11 and the logs say channel 25.
    
    The most accessable check is in paperui, so I do not know when the cannel changed.  
    I better rerun some channel changes (and look for devices that did not follow)  
    Likewise test the autochannel thingie just to see what it put out.

@chris (Chris Jackson) replied

    NilsOF:
    
    > Do the “reset” do the same as a restart of the binding, or is it a more gentle approach?
    
    Restarting the binding doesn't really do anything other than start everything up - it assumes the network has been established already and it just continues.
    
    Reset the network completely resets the coordinator and establishes a new network. All devices will need to join the new network.
    
    NilsOF:
    
    > The most accessable check is in paperui, so I do not know when the cannel changed.
    
    You can only change the channel when the network is initialised - ie reset as described above.

@NilsOF (Nils) replied

    chris:
    
    > Reset the network completely resets the coordinator and establishes a new network. All devices will need to join the new network.
    
    Oh, I think I understand.  
    I will keep the settings in my .things file then.
    
    Thank you for answering these questions.  
    I learned a lot

After which, @NilsOF (Nils) added

    chris:
    
    > You can only change the channel when the network is initialised - ie reset as described above.
    
    Paperui fooled me for many days…

To which @shorty707 (Shorty707) replied

    @chris
    
    since I installed the zigbee binding my openhab stalled fully 2 times in a few days  
    could it be related to the binding?
    
    tons of this in the log when it stalls
    [code] 
        2020-05-16 10:20:27.558 [WARN ] [zsmartsystems.zigbee.ZigBeeExecutors] - Uncaught exception in thread NotificationService-thread-1870
        java.lang.OutOfMemoryError: unable to create new native thread
        	at java.lang.Thread.start0(Native Method) ~[?:1.8.0_191]
        	at java.lang.Thread.start(Thread.java:717) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1025) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_191]
        	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
        2020-05-16 10:20:27.678 [DEBUG] [converter.ZigBeeConverterSwitchOnoff] - 7CB03EAA00ACF5AF: ZigBee attribute reports ZclAttribute [cluster=On/Off, id=0, name=On Off, dataType=BOOLEAN, lastValue=false, lastReportTime=Sat May 16 10:20:27 CEST 2020, implemented=true]
        2020-05-16 10:20:27.679 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 7CB03EAA00ACF5AF: Channel zigbee:device:c890ebfb:7cb03eaa00acf5af:7CB03EAA00ACF5AF_3_switch updated to OFF
        2020-05-16 10:20:27.680 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 7CB03EAA00ACF5AF: Updating ZigBee channel state zigbee:device:c890ebfb:7cb03eaa00acf5af:7CB03EAA00ACF5AF_3_switch to OFF
        2020-05-16 10:20:27.682 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - Reset timeout for handler with thingUID=zigbee:device:c890ebfb:7cb03eaa00acf5af
        2020-05-16 10:20:27.683 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - Scheduling timeout task for thingUID=zigbee:device:c890ebfb:7cb03eaa00acf5af in 1830 seconds
        2020-05-16 10:20:27.684 [WARN ] [zsmartsystems.zigbee.ZigBeeExecutors] - Uncaught exception in thread NotificationService-thread-1867
        java.lang.OutOfMemoryError: unable to create new native thread
        	at java.lang.Thread.start0(Native Method) ~[?:1.8.0_191]
        	at java.lang.Thread.start(Thread.java:717) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1025) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_191]
        	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
        
        2020-05-16 10:36:32.697 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 7CB03EAA00ACF5AF: Polling...
        2020-05-16 10:36:32.698 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 7CB03EAA00ACF5AF: Polling zigbee:device:c890ebfb:7cb03eaa00acf5af:7CB03EAA00ACF5AF_3_activepower
        2020-05-16 10:36:32.700 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
        java.lang.OutOfMemoryError: unable to create new native thread
        	at java.lang.Thread.start0(Native Method) ~[?:1.8.0_191]
        	at java.lang.Thread.start(Thread.java:717) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378) ~[?:1.8.0_191]
        	at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) ~[?:1.8.0_191]
        	at com.zsmartsystems.zigbee.dongle.xbee.internal.XBeeFrameHandler.sendRequestAsync(XBeeFrameHandler.java:554) ~[?:?]
        	at com.zsmartsystems.zigbee.dongle.xbee.ZigBeeDongleXBee.sendCommand(ZigBeeDongleXBee.java:347) ~[?:?]
        	at com.zsmartsystems.zigbee.aps.ApsDataEntity.send(ApsDataEntity.java:168) ~[?:?]
        	at com.zsmartsystems.zigbee.ZigBeeNetworkManager.sendCommand(ZigBeeNetworkManager.java:881) ~[?:?]
        	at com.zsmartsystems.zigbee.transaction.ZigBeeTransactionManager.send(ZigBeeTransactionManager.java:444) ~[?:?]
        	at com.zsmartsystems.zigbee.transaction.ZigBeeTransactionManager.sendNextTransaction(ZigBeeTransactionManager.java:670) ~[?:?]
        	at com.zsmartsystems.zigbee.transaction.ZigBeeTransactionManager.queueTransaction(ZigBeeTransactionManager.java:372) ~[?:?]
        	at com.zsmartsystems.zigbee.transaction.ZigBeeTransactionManager.sendTransaction(ZigBeeTransactionManager.java:356) ~[?:?]
        	at com.zsmartsystems.zigbee.ZigBeeNetworkManager.sendTransaction(ZigBeeNetworkManager.java:1915) ~[?:?]
        	at com.zsmartsystems.zigbee.ZigBeeNode.sendTransaction(ZigBeeNode.java:894) ~[?:?]
        	at com.zsmartsystems.zigbee.ZigBeeEndpoint.sendTransaction(ZigBeeEndpoint.java:591) ~[?:?]
        	at com.zsmartsystems.zigbee.zcl.ZclCluster.sendCommand(ZclCluster.java:292) ~[?:?]
        	at com.zsmartsystems.zigbee.zcl.ZclCluster.readAttributes(ZclCluster.java:454) ~[?:?]
        	at com.zsmartsystems.zigbee.zcl.ZclCluster.read(ZclCluster.java:1693) ~[?:?]
        	at com.zsmartsystems.zigbee.zcl.ZclCluster.read(ZclCluster.java:1668) ~[?:?]
        	at com.zsmartsystems.zigbee.zcl.ZclCluster.read(ZclCluster.java:1680) ~[?:?]
        	at com.zsmartsystems.zigbee.zcl.ZclCluster.readSync(ZclCluster.java:1610) ~[?:?]
        	at com.zsmartsystems.zigbee.zcl.clusters.ZclElectricalMeasurementCluster.getActivePower(ZclElectricalMeasurementCluster.java:3552) ~[?:?]
        	at org.openhab.binding.zigbee.internal.converter.ZigBeeConverterMeasurementPower.handleRefresh(ZigBeeConverterMeasurementPower.java:118) ~[?:?]
        	at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$2.run(ZigBeeThingHandler.java:586) ~[?:?]
        	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_191]
        	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_191]
        	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_191]
        	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_191]
        	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
        2020-05-16 10:36:33.668 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.669 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.670 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.671 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.672 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.673 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.673 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.674 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.674 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.675 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.675 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.676 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.676 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.677 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.678 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:33.678 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:34.739 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:34.742 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:34.743 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        2020-05-16 10:36:34.744 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@16fbe655' takes more than 5000ms.
        
        
        2020-05-16 13:09:38.420 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:38.421 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:38.423 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:38.424 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:38.429 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:46.599 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
        java.lang.OutOfMemoryError: unable to create new native thread
        	at java.lang.Thread.start0(Native Method) ~[?:1.8.0_191]
        	at java.lang.Thread.start(Thread.java:717) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.ensurePrestart(ThreadPoolExecutor.java:1603) ~[?:1.8.0_191]
        	at java.util.concurrent.ScheduledThreadPoolExecutor.reExecutePeriodic(ScheduledThreadPoolExecutor.java:350) ~[?:1.8.0_191]
        	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:296) ~[?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_191]
        	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
        2020-05-16 13:09:48.301 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.302 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.302 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.303 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.303 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.304 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.325 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.325 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.326 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.327 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.328 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.349 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.350 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.350 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.351 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.351 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.352 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.353 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.353 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.354 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.354 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.355 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.356 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.356 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        2020-05-16 13:09:48.357 [WARN ] [ding.zigbee.handler.ZigBeeSerialPort] - Processing DATA_AVAILABLE event: Serial buffer overrun
        
    [/code]
    
    edit:  
    it is joined by some zwave logging which I have not seen before:
    [code] 
        2020-05-16 10:51:50.397 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling aborted due to exception
        java.lang.IllegalStateException: Timer already cancelled.
        	at java.util.Timer.sched(Timer.java:397) ~[?:1.8.0_191]
        	at java.util.Timer.schedule(Timer.java:208) ~[?:1.8.0_191]
        	at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.startTransactionTimer(ZWaveTransactionManager.java:1005) ~[bundleFile:?]
        	at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.addTransactionToQueue(ZWaveTransactionManager.java:376) ~[bundleFile:?]
        	at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.queueTransactionForSend(ZWaveTransactionManager.java:332) ~[bundleFile:?]
        	at org.openhab.binding.zwave.internal.protocol.ZWaveController.enqueue(ZWaveController.java:505) ~[bundleFile:?]
        	at org.openhab.binding.zwave.internal.protocol.ZWaveController.sendData(ZWaveController.java:889) ~[bundleFile:?]
        	at org.openhab.binding.zwave.handler.ZWaveControllerHandler.sendData(ZWaveControllerHandler.java:472) ~[bundleFile:?]
        	at org.openhab.binding.zwave.handler.ZWaveThingHandler$1.run(ZWaveThingHandler.java:427) [bundleFile:?]
        	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_191]
        	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_191]
        	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_191]
        	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_191]
        	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_191]
        	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
    [/code]

To which @chris (Chris Jackson) replied

    It looks like your system is running low on resources. In general, the binding tries to be a low resource user, but it does make use of a number of threads within the zigbee libraries to monitor transactions etc.

To which @shorty707 (Shorty707) replied

    @chris what resources?   
    its quite a overspeced dedicated openhab server with 16gb ram. cpu Intel N3450 quad-core. OS Ubuntu
    
    edit:  
    just checked it allocated 20% RAM now overall incl. whatever linux preallocates  
    and openhab is more or less idling on 0-2% CPU

After which, @chris (Chris Jackson) added

    shorty707:
    
    > @chris what resources? 
    
    Threads / memory. The error is about threads creation.

To which @shorty707 (Shorty707) replied

    chris:
    
    > Threads / memory.
    
    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
    [code] 
        :~$ 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
    [/code]

To which @chris (Chris Jackson) replied

    shorty707:
    
    > just can tell before I used zigbee the uptime was a couple months
    
    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

After which, @shorty707 (Shorty707) added

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

Then @chris (Chris Jackson) said

    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 -:
    
    shorty707:
    
    > java.lang.OutOfMemoryError: unable to create new native thread

To which @shorty707 (Shorty707) replied

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

@shorty707 (Shorty707) replied

    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

So @chris (Chris Jackson) replied

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

After which, @shorty707 (Shorty707) added

    shorty707:
    
    > this shows that almost all threads go to  
    >  Mi IO MessageSenderThread: TIMED_WAITING
    
    @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 8b7c:f320:99b9:690f:4595:cd17:293a:c069 Bundles 8b7c:f320:99b9:690f:4595:cd17:293a:c069 ZigBee Binding  
    342 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons 8b7c:f320:99b9:690f:4595:cd17:293a:c069 Bundles 8b7c:f320:99b9:690f:4595:cd17:293a:c069 ZigBee CC2531 Bridge  
    343 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons 8b7c:f320:99b9:690f:4595:cd17:293a:c069 Bundles 8b7c:f320:99b9:690f:4595:cd17:293a:c069 ZigBee Console  
    344 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons 8b7c:f320:99b9:690f:4595:cd17:293a:c069 Bundles 8b7c:f320:99b9:690f:4595:cd17:293a:c069 ZigBee Console Ember  
    345 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons 8b7c:f320:99b9:690f:4595:cd17:293a:c069 Bundles 8b7c:f320:99b9:690f:4595:cd17:293a:c069 ZigBee Ember Bridge  
    346 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons 8b7c:f320:99b9:690f:4595:cd17:293a:c069 Bundles 8b7c:f320:99b9:690f:4595:cd17:293a:c069 ZigBee Telegesis Bridge  
    347 │ Active │ 80 │ 2.5.5 │ openHAB Add-ons 8b7c:f320:99b9:690f:4595:cd17:293a:c069 Bundles 8b7c:f320:99b9:690f:4595:cd17:293a:c069 ZigBee XBee Bridge

To which @chris (Chris Jackson) replied

    shorty707:
    
    > is there more from the zigbee bundles I need to put into debug?
    
    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.

To which @shorty707 (Shorty707) replied

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

So @chris (Chris Jackson) replied

    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) -:
    
    image1690×876 238 KB
    
    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.

To which @shorty707 (Shorty707) replied

    @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?
    
    image1680×1320 301 KB

After which, @chris (Chris Jackson) added

    shorty707:
    
    > I moved one plug really close to the coordinator.
    
    Maybe you've said earlier, but I can't see it - what is this device?
    
    shorty707:
    
    > for the OSRAM lightfy I see in the documentation they have dynamic scened.  
    >  should that be discovered as a channel?
    
    No. the binding doesn't support scenes.

Then @shorty707 (Shorty707) said

    chris:
    
    > Maybe you've said earlier, but I can't see it - what is this device?
    
    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
    
    image3079×1724 632 KB

@chris (Chris Jackson) replied

    I'm actually surprised that your system jchristensen@example.net. The signals are really extremely poor according to this graphic.

Then @shorty707 (Shorty707) said

    chris:
    
    > 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:  
    
    
    image2124×287 43.4 KB

To which @chris (Chris Jackson) replied

    shorty707:
    
    > well it works sometimes…
    
    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.
    
    shorty707:
    
    > where do you read poor signal in the device information in the graphic (lqi?)
    
    Yes, LQI - Link Quality Indicator - it should be well above 200, and I see numbers like 20 in your system.
    
    shorty707:
    
    > is it related to the old zigbee standard from the devices
    
    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 -:
    
    image1662×512 82.1 KB

@shorty707 (Shorty707) replied

    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  
    
    
    image3218×488 29.8 KB
    
    image3122×413 222 KB

So @shorty707 (Shorty707) replied

    shorty707:
    
    > switched the coordinator to channel 25 to get away from crowded wifi
    
    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

So @rossko57 (Rossko57) replied

    shorty707:
    
    > solve it with a zigbee dongle which has more power
    
    Limited value in a mesh, though? Each pathway only as good as its weakest link, etc.

To which @chris (Chris Jackson) replied

    shorty707:
    
    > 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.
    
    It's updated periodically - there's a setting in the coordinator that sets how often this is updated.
    
    shorty707:
    
    > b) find another location for my openhab server
    
    This probably won't help - it's not about the server - it also affects other links.
    
    shorty707:
    
    > c) solve it with a zigbee dongle which has more power
    
    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.

@NilsOF (Nils) replied

    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.

So @shorty707 (Shorty707) replied

    NilsOF:
    
    > rfkill
    
    Interesting  
    I have a zbox with wifi / Bluetooth.  
    It's disabled in Ubuntu. Yet maybe it still is not really silent? I will check rfkill.
    
    Thanks!

So @NilsOF (Nils) replied

    shorty707:
    
    > Yet maybe it still is not really silent?
    
    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

After which, @shorty707 (Shorty707) added

    NilsOF:
    
    > I guess some oscillators is running and creates interference.  
    >  Rf shielding was something we had in the past century…
    
    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 
    
    chris:
    
    > It's updated periodically - there's a setting in the coordinator that sets how often this is updated.
    
    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
    [code] 
        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.
    [/code]

After which, @shorty707 (Shorty707) added

    @chris
    
    chris:
    
    > 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.
    
    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  
    thanks
    
    image652×1672 294 KB

To which @chris (Chris Jackson) replied

    shorty707:
    
    > What I see now is my debug is spammed with NetworkAdressRequests
    
    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?
    
    shorty707:
    
    > 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
    
    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.

To which @shorty707 (Shorty707) replied

    chris:
    
    > 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.
    
    I sent 10 meg by mail. Thank you!


{'source': 'discourse', 'url': 'https://community.openhab.org/t/zigbee-channel/98588', 'title': 'Zigbee Channel?', 'views': 2586, 'has_accepted_answer': False, 'word_count': 7457, 'like_count': 5, 'reply_count': 54, 'participant_count': 4, 'posts': 61, 'tags': 'zigbee zigbee-binding', 'author': '@shorty707 (Shorty707)', 'participants': '@shorty707 (Shorty707), @chris (Chris Jackson), @NilsOF (Nils), @rossko57 (Rossko57)', 'image_url': [None], 'created_at': '2020-05-11T11:46:04.844Z', 'last_posted_at': '2020-06-19T10:23:20.480Z'}