Zigbee Devices Going Offline

I have few Zigbee devices that goes to offline after random periods of time. I have two plug-in switches and four Aquara temp sensors. I am aware there are issues with Aquara but the issue is with the plugin switches. After a while it will show offline in PaperUI but can actually turn them on and off through the app just fine.

Using Openhab 2.5.6
Device: HUSBZB-1 (Boost Mode, High Power)

Openhab-cli shows the devices are still online even though PaperUI/HABmin shows them offline.

openhab> zigbee nodes
Network  Addr  IEEE Address      Logical Type  State      EP   Profile                    Device Type                Manufacturer     Model          
      0  0000  000D6F001200B3E3  COORDINATOR   UNKNOWN  
    673  02A1  00158D000238C33E  END_DEVICE    ONLINE      1  ZIGBEE_HOME_AUTOMATION     5F01                       LUMI             lumi.weather   
   3037  0BDD  00158D00023008C9  END_DEVICE    ONLINE      1  ZIGBEE_HOME_AUTOMATION     5F01                       LUMI             lumi.weather   
   5647  160F  00158D000232925E  END_DEVICE    ONLINE      1  ZIGBEE_HOME_AUTOMATION     5F01                       LUMI             lumi.weather   
   6080  17C0  F0D1B80000121FED  ROUTER        ONLINE      1  ZIGBEE_HOME_AUTOMATION     SMART_PLUG                 LEDVANCE         PLUG           
  28896  70E0  F0D1B800000736F7  ROUTER        ONLINE      1  ZIGBEE_HOME_AUTOMATION     SMART_PLUG                 LEDVANCE         PLUG           
  49303  C097  00158D000238C442  END_DEVICE    ONLINE      1  ZIGBEE_HOME_AUTOMATION     5F01                       LUMI             lumi.weather

Distance relative to devices:

Dongle --(3ft)ā€“> 1FEDā€“(15ft)ā€“>36F7-- all Aquara sensor within 5ft of 36F7 except sensor C442

EDIT: Added more information.

Same is true at my site:

rpi openhabianpi, openhab 2.5.6-2 + telegesis ETRX3

Things are shown offline in paperui ā€œConfiguration Thingsā€ but maybe switched on/of f.e. in paperui using ā€œControlā€. Even after switching on/of the Thing(s) stay marked offline.

Everything/item seems to work anyway.

openhab> zigbee nodes
Network  Addr  IEEE Address      Logical Type  State      EP   Profile                    Device Type                Manufacturer     Model
      0  0000  000D6F00108DD32B  COORDINATOR   UNKNOWN
   4847  12EF  00178801045965BB  ROUTER        UNKNOWN    11  ZIGBEE_LIGHT_LINK          ON_OFF_LIGHT               Philips          LWB010
                                                         242  A1E0                       ZGP_PROXY_BASIC                          
  20787  5133  001788010337DD9F  ROUTER        ONLINE     11  ZIGBEE_LIGHT_LINK          POINT_OF_SALE              Philips          LTC001
                                                         242  A1E0                       ZGP_PROXY_BASIC                          
  45271  B0D7  EC1BBDFFFE271435  ROUTER        ONLINE      1  ZIGBEE_LIGHT_LINK          0210                       MLI              RGBW Lighting
                                                         242  A1E0                       ZGP_COMBO_BASIC                          
  51441  C8F1  7CB03EAA00AD44C7  ROUTER        ONLINE      3  ZIGBEE_LIGHT_LINK          DATA_COLLECTION_UNIT       OSRAM            Plug 01
  59626  E8EA  7CB03EAA00ACEBF6  ROUTER        UNKNOWN     3  ZIGBEE_LIGHT_LINK          DATA_COLLECTION_UNIT       OSRAM            Plug 01
  61386  EFCA  CCCCCCFFFEBB12F0  ROUTER        ONLINE      1  ZIGBEE_LIGHT_LINK          0210                       MLI              RGBW Lighting
                                                         242  A1E0                       ZGP_COMBO_BASIC

The first Philips is really offline. The second OSRAM is the same device as the first but configured to ā€œfollowā€ some other device status in paperui. Both ORAMS work as desired.

How far away is your rpi relative to your devices? Is it near the center or at one end?

Itā€™s quite centered. The online plug is ~6m to the east and the oflline is ~6m to the southwest.

From upper to lower: 5m 6m 5m 6m 6m 4m

BTW: one of the MLI is online in paperui -> config -> things. Itā€™s about 1m more away as the other which is shown offline in paperui.

Note tat the State shown in the console is not linked at all to the state of the Thing. This state comes from the lower level zigbee libraries and is not used in the binding.
The binding will use reports from the device to decide if a device is online or not. If it doesnā€™t receive a report when it expects, then it will mark it offline. This assumes that a device respects the reporting that the binding configures (which it should as itā€™s part of the standard) and some cheaper devices (eg Xiaomi) will ignore this. The lights I see in your device list should be fine, but if the RF link is not perfect, it could miss some reports.

Log files may help understand what is happening.

Distance isnā€™t everything. It depends on many other factors - antennas, antenna alignment, walls, radios, TVs and other devices nearly, any metal in the area, etc, etc. Distance is a good first approximation, but there can be a lot more to establishing if the RF link will work.

Thanks for explaning this. I didnā€™t know and just wanted to give some informations which might help.

Before grabbing the logs or generate some meaning full let me emphasize on the essential observation:

  • THINGS are marked offline i pUI
  • every ITEM is working as disired (afaik)

I never saw this before openhab 2.5.6

The attached logfile is default loglevel and starts right after the update to 2.5.6-2. there are errors an warning at the beginning, i normally ignore until i did the 2cnd or 3rd restart of openhab. This seems to be a known problem while starting after cache cleared: ITEMS not loaded when RULE already starts - you may know about that.

If this log does not show the information required, please let know, which actions to take. Iā€™ll set the loglevel to debug as described for the binding and take the actions then.

2020-06-22 - 25 openhab default level.log (575.9 KB)

There has been no change in how this works from 2.5.5 (or in fact from 2.5.0 for that matter)

Unfortunately this doesnā€™t really provide any useful information - we need to have debug logging enabled as per the binding docs.

I will generate one later this evening. Let me know, if i should do anything which youā€™d like to be visible in the logs.

I have had this issue for years.
I have two Zigbee dongles, and they both behave the same. Devices simply stop responding randomly and switch to offline. Only chances of getting them back is to remove the thing and include them again.
The distance is very close, aprox 1-5 meters.

I wonder if this will ever gona be stable. After my last try, it took a few weeks, and now the only device online is, funny enough, a xiaomi mija motion sensor.

Thatā€™s interesting. I thought it was a dongle issue. Other than the Aquara temp sensors which gives no response, found out that they work just fine connecting to the dongle directly and not part of a hop. The switches still work and responsive but shows offlineā€¦

So the channel I have my Zigbee is set to has no interference. I did a wifi scan and moved everything over to a different channel so make sure there were no overlap.

To get everything back online in PaperUI, I do a zigbee scan from inbox and just reset the devices. I donā€™t bother with removing the item.

I will reset all my zigbee devices so they are all working, then set my log to debug and attach it.

I appreciate you have had continued issues, and I donā€™t know why - Iā€™m sorry Iā€™ve not been able to help. This binding and libraries are used commercially by a number of companies - most of which I canā€™t mention, but I think itā€™s clear that Qivicon / DT are using this since they were helping with the development for quite some time. Itā€™s just a shame that weā€™ve never got your system working, but thousands of other systems out there work very well.

Ok, hereā€™s the debug log. Please download the zip file from here. The log is to big to place it here (only because of zigbee entries for one hour - hopefully this is ok for you).

I restarted openhab at the beginning and left it alone for about one hour. This is what i was presented in paperui, when i came back:

001788010337dd9f is really offline (no power intentionally). The others work as required even though shown as offline.

EDIT:
Just had a look at the online logviewer:
at ~18:14 there is ā€œat system start ruleā€ running
near the end 7cb03eaa00acebf6 has been switched by hardwareswitch

So this all looks ā€œokā€ to me. By this, I mean it is working as it is designed - there are no reports during this period (30 minutes) so the device is set to OFFLINE. This is how it is meant to work.

The question is why there is no reporting. A device should be configured to report every 15 minute in theory. This log does show the startup of the binding so I can confirm that this is what is happening (see below), and the binding sets the device OFFLINE if it doesnā€™t send 2 reports, so this all looks correct.

So everything is working correctly, but the device is not sending the reports that are expected.

Maybe Iā€™ll look at changing the logic to send a poll after the reporting period to give it a last chance to stay ONLINE.

Ok, i understand. Thanks for taking your time.

What i changed lately was the setup of the telegesis (19200 to 56700), while investigating these problems. This has been at about the same time i updated openhab and realized what we are writing about here.

My openhab needs some maintenance, some sort of backup/restore and i just received an ups for my rpi. When i implemented these topics, iā€™ll give an other zigbee controler a chance i think.

Iā€™ve changed the way this works now - after the ONLINE timer times out, it will attempt to poll the device. If there has still not been an update 30 seconds later, then it will set the device OFFLINE.

This should prevent the issue we see here where the device is not reporting for some reason. Please let me know if it helps.

2 Likes

I know you have tried Chrisā€¦ And I know others out there are using Zigbee without any hassle. That just makes this (my problem) much more strange. Remember, I have been trying for a coupple of years now, with several different openhab setups and two different Zigbee coordinators. The only thing I can think of is some external devices which is messing things up. I have no idea how this should be possible, but I really doubt its a openhab core/dongle issue anymore. For the last year, my Odroid C2 has been used to test Zigbee only, except for running Velbus server. Thats all there is install on that openhab setup.

As for external devices, IĀ“ve got two. One is my Philips Hue brigde and then a Xiaomi hub (v2). They both communicate ā€œalmostā€ the same 2.4ghz , but they havnt got any issue at all.

One of the latest Zigbee binding and lib released wouldnt even connect to my Philps Hue devices. They usually were the devices which only gave problems in the long run. A big surpise was, that I was able to add a Xiaomi motion sensor. This has always failed. But now its the only device running after weeks, and its still running. The rest eventually stopped responding, and after a while went offline, just as they used to, (beside the Hue devices wouldnt even connect).

I really have no idea whats going onā€¦ But I have to be honest with you, I doubt IĀ“m the only one with this issue. As you can tell from this thread, there are a few more out there with the same experienceā€¦ Maybe I have just been more patient than others, how may have given up insted.

Iā€™m late to this party, so you may have already tried this: Iā€™m using a USB CC2531 dongle on a Raspberry Pi 3B+. Iā€™m using zigbee2mqtt rather than the Zigbee binding. Iā€™d find that my device (yeah, Iā€™ve only got one!) would go offline randomly, and the thing that seems to have fixed it is putting the dongle on a USB extender, and then plugging that extender into the Pi - i.e. moving the dongle away from the Pi.

Hmm, so you believe the Rpi is causing the mess? Might be worth a try for sure.

I donā€™t believe much, to be honest! Could all just be coincidence. See if it works - at least itā€™s cheap!