Hi,
I’m using an ember Stick. Works fine so far.
The only strange thing is that sometimes devices are shown as offline but they work immedately if I use them. Also the console says online, but the UI says offline.
Anyone else faced this issues?
Thanks a lot!
/Franz
These are totally different things so you can’t really compare them. The binding uses a different reporting system to monitor if a device is “online”. It expects reports with a certain time, and if it doesn’t hear from the device within twice this reporting time, it assumes the device is offline. That doesn’t mean that if you send a command to it, it won’t respond, but if it’s not sending regular reports when the binding is expecting, the binding will tell you it hasn’t heard from the device in a while.
Hi @chris,
thanks for that great answer this helps a lot to understand this better.
If I understood you right this means i could detect earlier if a device switches from offline to online (In my case I have one bulb that still has a traditional switch) if i reduce the reporting time?
BR
Ok, so if you are turning the bulb off at the mains, then this will be a problem, and yes, it will cause this issue. That said, in theory the bulb should show ONLINE when it is turned back on as the bulb will send out a notification to say that it’s back. I think the binding should monitor these notifications, but from what you’ve said here, it might not.
I’ll take a look at this before you mess with the reporting configuration as this shouldn’t be required and is really a bit of a messy workaround.
Hi @Chris,
thanks for that feedback. So in general nearly all my bulbs are not switched by the mains.
There are only 2 which are switched by the mains.
For this issue I’ve tried already to send the desired values in a cycle (like every 30 seconds) but it seems to slow down the other bulbs in case i would turn them on by a zigbee switch.
Is there any strategy how to deal with those bulbs?
BR
/Franz
It’s really hard to comment here without really understanding why the devices aren’t reporting. The should send reports, and therefore they should stay online. If sending them commands slows everything down, then maybe there’s another issue - either the devices aren’t really contactable in the network, or your coordinator has limited memory to store routes so has to search for the devices - I don’t really know.
I would suggest that you get a log and take a look at what is happening for starters. This might help to understand the issue, and from there you can try and resolve it.
Hi Chris,
So my Zigbee stick as a “EFR32MG21A020F1024IM32” on board. Specs see below.
In general it behaves a bit like if the bulb did not received a command for a certain time then it’s offline in Openhab but online the level below.
Here is the setting of my Zigbee Stick in OH:
UID: zigbee:coordinator_ember:62ec522f14
label: Zigbee Ember EM35x Coordinator
thingTypeUID: zigbee:coordinator_ember
configuration:
zigbee_port: /dev/ttyACM0
zigbee_channel: 17
zigbee_initialise: false
zigbee_concentrator: 1
zigbee_trustcentremode: TC_JOIN_SECURE
zigbee_extendedpanid: D1EDA82EE0404XXX
zigbee_baud: 115200
zigbee_flowcontrol: 2
zigbee_panid: 55446
zigbee_powermode: 1
zigbee_txpower: 0
zigbee_networksize: 25
zigbee_linkkey: 5A6967426565416C6C69616E63653XXX
zigbee_childtimeout: 86400
zigbee_networkkey: 332178E8CFF39159DDEF1A49A29F9XXX
zigbee_meshupdateperiod: 86400
BR
/Franz
In general, the hardware doesn’t matter. I would check that the firmware is reasonably new - at least newer than 6.4.
Otherwise I can just reiterate my suggestion to check the logs as mentioned above. You should not see these devices being offline unless they are not configured to send reports and you should see this in the logs during initialisation.
Hi Chris,
Thanks for the fast answer.
I’ll check for a log tomorrow.
Currently i have ncp-uart-sw_v6.10.3_115200.gbl installed.
Have a good day and thanks alot so far.
/Franz
Hi @chris,
so it took me some times to create the logs but I hope I did it the proper way.
This chapter should just show the issues I have with the deviation between Online and Offline.
For the “Mains” and it get’s slow I will create a second test Scenario.
The logfiles can be downloaded here:
https://drive.google.com/file/d/1vI_NRIWAyP7H5ktw6M8qCm3ybC20SNdp/view?usp=sharing
I will send you the password for the file.
Some things that can be seen in there:
~ 12:24 (shortly before start I see that Error Handlers and Error Bridge appear
~ 12:43 First deviation between console and OH GUI. (OH Online but Console Offline)
Later on I reset this device - zigbee:philips_sml001:62ec522f14:0017880104b777d4 - and learn it again because it remains offline
~ 12:47 The device (zigbee:device:62ec522f14:84182600000fad3f) shown in that image is not plugged into the MAINS.
It’s offline in the Console but Online in OH. (The Switch is used for the Christmas Tree that is not yet installed therefore the SmartPlug is in the Box for Christmas things)
~12:57 Device “Zigbee Hue FlurUG Panel” (00178801042F8978) reports offline in OH, but is online in the console and reacts instantly on command on his LevelControl.
~13:07 Added Motion Sensor again (reset) → working( zigbee:philips_sml001:62ec522f14:0017880104b76da0)
~13:08 Seen that Wohnzimmer Panel (00178801042f71ee) is offline in OH but shows online in the Console)
~ 13:14 Learned Motion sensor again because it was offline too (0017880104B777D4)
~13:15 Finally the Dimmer Switch in the Sleeping room is working again (before it was just showing a red led) - 0017880103E77CE7
Thank you so much for your support.
I really appreciate it.
/Franz
Hi @chris ,
next log next luck. Here is the behaviour if I disconnect a Bulb from the MAINS, continue sending commands to the item and the whole system gets slow.
Here is the Link, the PWD is the same:
https://drive.google.com/file/d/1Za1BMVsLaaZlzogLiP0njUu6fg8KawhA/view?usp=sharing
And here is what happened
2021-12-19 14:11:56.455 => Started a rule to send every 10 Seconds Current Brightness and Color Temperature to 3 Lights.
~ 2021-12-19 14:13:00 => Physically used the mains switch to turn of the Panel (zigbee:device:62ec522f14:00178801045014fa) - In the Kitchen
2021-12-19 14:13:10.137 => The device switched to Offline ‘zigbee:device:62ec522f14:00178801045014fa’ changed from ONLINE to OFFLINE
|-> This is great
2021-12-19 14:17:46.506 => Pressed the Hue Dimmer Switch in my living Room (zigbee:philips_rwl021:62ec522f14:0017880106700377:buttonI)
|-> Nothign happens
2021-12-19 14:19:21.246 => Pressed the switch again (zigbee:philips_rwl021:62ec522f14:0017880106700377:buttonI)
|-> Nothing happens
~ 2021-12-19 14:20 => Now the light turned on in the Living Room
Thanks a lot!
/Franz
I did some sniffing some months ago.
The sniffing revealed quite a lot of routing messages where the “system” is trying to find the offline device.
I have not sniffed lately, but I get the same slow and delayed behavior when sending something to a offline device. It can get really slow if there are many offline devices.
My solution is to not send anything to offline devices. Ikea bulbs are quite notorious to fall into a offline state. I belive this is a bug in Ikeas firmware, where routing messages is triggering the flaw. IE, you get a kind of amplifier effect…
However, my Philips Hue bulbs do get marked as offline in UI while they do react to dimming, so I have to send commands to them regardless online/offline state.
Just my observations, but somehow related.
Hi @NilsOF
thanks for the confirmation that this phenomenon is happening.
From my side I just own Hue Panels/Bulbs/Switches/Motion sensors and 3 Smart Plugs from OSRAM that where upgraded with an OTA Upgrade to the latest lightify version.
As you’ve already found out, stop sending things to Offline devices would cause that sooner or later my whole house would be dark because if the Hue bulbs do not receive a command from time to time they are displayed as offline.
BTW: could you please share how you check that the device is offline, As of today I could not find a way to get the linked channel for an Object in JS Scripts.
Thanks
/Franz
I have used the DSL rule engine for lightning control so far.
A snippet from one of my rules:
var lpStatus = getThingStatusInfo("zigbee:device:01381602:ec1bbdfffe8eae4b")
if ( lpStatus !== null && (lpStatus.getStatus().toString() == "ONLINE") ){
Lp1Lysekrone_StueN_dimmer.sendCommand(newdimmervalue)
}
More elegant ways probably exists 
As my rules slowly becomes more complicated over time I will rewrite my rules in python (HabApp) when I get some spare time.
I have no clue on how to do this in JS.
There is a thread somewhere here where offline detection is discussed.
I am sending colortemperature change to my Hue bulbs every minute or two, but that do not appear to be enough.
Thinking of trying to refresh the dimmer settings at a regular interval to see how that goes.
While these sorts of workarounds may be necessary - eg if as stated the Ikea devices have a bug - I would really try and focus on understanding why devices are OFFLINE. Unless the devices are physically powered off, they shouldn’t really go offline as they should report back to the binding, or the binding will also poll them to see if they are there before marking them offline.
I would generally discourage sending refresh commands regularly - this sort of thing can clog up the network as already stated above if devices are really offline, and if they are online, they should be reporting (so really should not go offline).
The IKEA bulbs get unresponsive. I have two different models, one are notorious, the other not quite as bad. IKEA is aware of the problem, but to my knowledge no new firmware is published.
I agree with what you are saying.
One is to find out why the Hue bulbs is marked offline while they are online and do respond to commands.
Then there is the problem with clogged up mesh when sending commands to offline devices.
This is very noticeable when using the Hue remote and one or more of the target lights are offline.
Is the “routing” traffic generated by the binding or from the coordinator when a command goes out to a offline device?
(I name it “routing” traffic, not knowing better 
)
Edit: Personally I find it reasonable to not send commands to offline devices.
Is this a common problem with Hue bulbs then, or just a problem with @FranzS system? I’ve not been able to get hold of the logs yet so can’t assess the issues there. One thing I know with older Hue bulbs is the binding table only had a single entry which means some reports aren’t sent. This shouldn’t cause them to be marked offline, but can cause other status update issues.
The binding uses reporting to keep tabs on a device, and if it doesn’t receive a report in twice the reporting period, plus 30 seconds, then it will send a poll to try and get the status, and if that also fails, it will be marked offline. So the binding is trying quite hard to see if the device is really there or no before marking offline and I think that after this, if it’s offline, then there’s probably a communication issue down in the network.
There’s no real fix to this. Once you send a command, you have to go through the motions, and it takes up to 8 seconds for this to timeout due to the way 802.15.4 works. The NCP can handle around 5 or 6 commands at a time, and the binding (actually the zigbee libs) will pace this - only sending enough commands to keep the NCP busy, but not choke. If you try and send more commands, then it will slow down in the binding.
Sending commands to devices that the coordinator hasn’t seen for a while can cause it to perform a route discovery - this is dependant on a bunch of things, including the way memory is configured in the devices so it’s hard to provide general answers here. For commercial customers where there is some control over the firmware, there are changes that can be made to improve this for larger networks, but here people get firmware from “somewhere on the net” so it’s hard to be sure how this is all configured.
It’s sort of both. The binding “allows” the NCP to discover routes if it doesn’t know the route. Actually this isn’t something the binding can control as it’s managed down in the zigbee library. I don’t think there’s a lot of option here though - if the device route isn’t known, then it needs to be discovered otherwise it’s not possible to communicate with it.
I don’t know if this is a good idea either. The problem here is that if it’s offline, and we never send commands, and the device isn’t reporting for some reason, then it will never come online, and therefore never work.
I am open to good ideas here though so feel free to offer solutions - even if they don’t make sense, they might inspire something in my mind that does make sense (but don’t be offended if I shoot them down - it’s just part of the engineering process ).
Thank you for the informative answer!
Hehe, no I do not easily get offended I have been in IT and tech for so long that my skin has hardened
And, yes my Hue bulbs do get marked offline too.
I have to rig up some test system, but first I have to help the wife with this christmas thing.
Hello @chris ,
thanks a lot for that technical details too. Similar to NilsOF I have an IT Background therefore I’m also used to get honest feedback.
How can i check the binding table?
If I check it like below I always have just one direct connection from the router to the coordinator.
(But maybe I’m wrong)
openhab> zigbee nodes | grep ROUTER
194 00C2 0017880102B8D37E ROUTER ONLINE 11 ZIGBEE_LIGHT_LINK 0210 Signify Netherlands B.V. LCT003
2535 09E7 0017880103342A12 ROUTER ONLINE 11 ZIGBEE_LIGHT_LINK ZLL_COLOR_TEMPERATURE_LIGHT Signify Netherlands B.V. LTC012
3297 0CE1 001788010204ACCE ROUTER UNKNOWN 11 ZIGBEE_LIGHT_LINK ZLL_COLOR_TEMPERATURE_LIGHT Signify Netherlands B.V. LTW001
4765 129D 00178801042F8978 ROUTER ONLINE 11 ZIGBEE_LIGHT_LINK ZLL_COLOR_TEMPERATURE_LIGHT Signify Netherlands B.V. LTC013
5562 15BA 84182600000FAD3F ROUTER ONLINE 3 ZIGBEE_LIGHT_LINK ZLL_ON_OFF_PLUG_IN_UNIT OSRAM Plug 01
16577 40C1 7CB03EAA00B0C923 ROUTER ONLINE 3 ZIGBEE_LIGHT_LINK ZLL_ON_OFF_PLUG_IN_UNIT OSRAM Plug 01
18360 47B8 001788010204B546 ROUTER UNKNOWN 11 ZIGBEE_LIGHT_LINK ZLL_COLOR_TEMPERATURE_LIGHT Signify Netherlands B.V. LTW001
21362 5372 0017880103369835 ROUTER ONLINE 11 ZIGBEE_LIGHT_LINK ZLL_COLOR_TEMPERATURE_LIGHT Signify Netherlands B.V. LTC001
21702 54C6 0017880102B9F368 ROUTER ONLINE 11 ZIGBEE_LIGHT_LINK 0210 Signify Netherlands B.V. LCT003
22216 56C8 00178801045014FA ROUTER UNKNOWN 11 ZIGBEE_LIGHT_LINK ZLL_COLOR_TEMPERATURE_LIGHT Signify Netherlands B.V. LTC015
22294 5716 00178801042F514E ROUTER ONLINE 11 ZIGBEE_LIGHT_LINK ZLL_COLOR_TEMPERATURE_LIGHT Signify Netherlands B.V. LTC013
23792 5CF0 0017880106FC1E31 ROUTER ONLINE 11 ZIGBEE_LIGHT_LINK 0210 Signify Netherlands B.V. LCW002
34751 87BF 8418260000102DAF ROUTER ONLINE 3 ZIGBEE_LIGHT_LINK ZLL_ON_OFF_PLUG_IN_UNIT OSRAM Plug 01
51811 CA63 00178801069290BC ROUTER ONLINE 11 ZIGBEE_LIGHT_LINK ZLL_COLOR_TEMPERATURE_LIGHT Signify Netherlands B.V. LTC013
53936 D2B0 00178801042F71EE ROUTER ONLINE 11 ZIGBEE_LIGHT_LINK ZLL_COLOR_TEMPERATURE_LIGHT Signify Netherlands B.V. LTC015
64553 FC29 7CB03EAA00B0D5ED ROUTER ONLINE 3 ZIGBEE_LIGHT_LINK ZLL_ON_OFF_PLUG_IN_UNIT OSRAM Plug 01
openhab> zigbee bindtable 194
Binding table for node 194 [0017880102B8D37E]
Src Address | Dest Address | Group | Mode | Cluster
0017880102B8D37E/11 | 04CD15FFFEBB3E7B/1 | | Address | 0300:COLOR_CONTROL
openhab> zigbee bindtable 2535
Binding table for node 2535 [0017880103342A12]
Src Address | Dest Address | Group | Mode | Cluster
0017880103342A12/11 | 04CD15FFFEBB3E7B/1 | | Address | 0300:COLOR_CONTROL
openhab> zigbee bindtable 3297
Binding table read error: FAILURE
openhab> zigbee bindtable 4765
Binding table for node 4765 [00178801042F8978]
Src Address | Dest Address | Group | Mode | Cluster
00178801042F8978/11 | 04CD15FFFEBB3E7B/1 | | Address | 0300:COLOR_CONTROL
openhab> zigbee bindtable 5562
Binding table for node 5562 [84182600000FAD3F]
Src Address | Dest Address | Group | Mode | Cluster
84182600000FAD3F/3 | 04CD15FFFEBB3E7B/1 | | Address | 0B04:ELECTRICAL_MEASUREMENT
84182600000FAD3F/3 | 04CD15FFFEBB3E7B/1 | | Address | 0006:ON_OFF
openhab> zigbee bindtable 16577
Binding table for node 16577 [7CB03EAA00B0C923]
Src Address | Dest Address | Group | Mode | Cluster
7CB03EAA00B0C923/3 | 04CD15FFFEBB3E7B/1 | | Address | 0006:ON_OFF
7CB03EAA00B0C923/3 | 04CD15FFFEBB3E7B/1 | | Address | 0B04:ELECTRICAL_MEASUREMENT
openhab> zigbee bindtable 18360
Binding table read error: FAILURE
openhab> zigbee bindtable 21362
Binding table for node 21362 [0017880103369835]
Src Address | Dest Address | Group | Mode | Cluster
0017880103369835/11 | 04CD15FFFEBB3E7B/1 | | Address | 0300:COLOR_CONTROL
openhab> zigbee bindtable 21702
Binding table for node 21702 [0017880102B9F368]
Src Address | Dest Address | Group | Mode | Cluster
0017880102B9F368/11 | 04CD15FFFEBB3E7B/1 | | Address | 0300:COLOR_CONTROL
openhab> zigbee bindtable 22216
Binding table read error: FAILURE
openhab> zigbee bindtable 22294
Binding table for node 22294 [00178801042F514E]
Src Address | Dest Address | Group | Mode | Cluster
00178801042F514E/11 | 04CD15FFFEBB3E7B/1 | | Address | 0300:COLOR_CONTROL
openhab> zigbee bindtable 23792
Binding table for node 23792 [0017880106FC1E31]
Src Address | Dest Address | Group | Mode | Cluster
0017880106FC1E31/11 | 04CD15FFFEBB3E7B/1 | | Address | 0300:COLOR_CONTROL
openhab> zigbee bindtable 34751
Binding table for node 34751 [8418260000102DAF]
Src Address | Dest Address | Group | Mode | Cluster
8418260000102DAF/3 | 04CD15FFFEBB3E7B/1 | | Address | 0B04:ELECTRICAL_MEASUREMENT
8418260000102DAF/3 | 04CD15FFFEBB3E7B/1 | | Address | 0006:ON_OFF
openhab> zigbee bindtable 51811
Binding table for node 51811 [00178801069290BC]
Src Address | Dest Address | Group | Mode | Cluster
00178801069290BC/11 | 04CD15FFFEBB3E7B/1 | | Address | 0300:COLOR_CONTROL
openhab> zigbee bindtable 53936
Binding table for node 53936 [00178801042F71EE]
Src Address | Dest Address | Group | Mode | Cluster
00178801042F71EE/11 | 04CD15FFFEBB3E7B/1 | | Address | 0300:COLOR_CONTROL
openhab> zigbee bindtable 53936
Binding table for node 53936 [00178801042F71EE]
Src Address | Dest Address | Group | Mode | Cluster
00178801042F71EE/11 | 04CD15FFFEBB3E7B/1 | | Address | 0300:COLOR_CONTROL
openhab> zigbee bindtable 64553
Binding table for node 64553 [7CB03EAA00B0D5ED]
Src Address | Dest Address | Group | Mode | Cluster
7CB03EAA00B0D5ED/3 | 04CD15FFFEBB3E7B/1 | | Address | 0B04:ELECTRICAL_MEASUREMENT
7CB03EAA00B0D5ED/3 | 04CD15FFFEBB3E7B/1 | | Address | 0006:ON_OFF
What I also tried is to query the ncprouting, but ends up with an error message
openhab> zigbee ncprouting
An unexpected error occurred during execution.
2021-12-21 15:05:03.062 [ERROR] [b.core.io.console.ConsoleInterpreter] - An error occurred while executing the console command.
java.lang.NullPointerException: null
at com.zsmartsystems.zigbee.console.ember.EmberConsoleNcpRoutingCommand.process(EmberConsoleNcpRoutingCommand.java:79) ~[?:?]
at org.openhab.binding.zigbee.console.internal.ZigBeeConsoleCommandExtension.handleZigbeeCommand(ZigBeeConsoleCommandExtension.java:149) ~[?:?]
at org.openhab.binding.zigbee.console.internal.ZigBeeConsoleCommandExtension.handleCommand(ZigBeeConsoleCommandExtension.java:117) ~[?:?]
at org.openhab.binding.zigbee.console.internal.ZigBeeConsoleCommandExtension.execute(ZigBeeConsoleCommandExtension.java:89) ~[?:?]
at org.openhab.core.io.console.ConsoleInterpreter.execute(ConsoleInterpreter.java:55) [bundleFile:?]
at org.openhab.core.io.console.karaf.internal.CommandWrapper.execute(CommandWrapper.java:78) [bundleFile:?]
at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) [bundleFile:4.3.4]
at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) [bundleFile:4.3.4]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) [bundleFile:4.3.4]
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526) [bundleFile:4.3.4]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) [bundleFile:4.3.4]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) [bundleFile:4.3.4]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) [bundleFile:4.3.4]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) [bundleFile:4.3.4]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Is there anything else that could help for better diagnostics?
Different question, but maybe reasonable. If a bulb is not connected to the mains, would it (or can it be done) to set this device as end point (to avoid chaotic routing)?
BR
/Franz
Hi @chris,
(Putting the Trenchcoat on) … one more thing, could it be related to the endpoints ending with 242 / ZIGBEE_GREEN_POWER?
BR
/Franz
