My sonoff ZBBridge tasmota flashed coordinator appears offline after a while even if it’s online and working.
Using zha-network-card or zigzag graphical layout, the coordinator appears “Online: false” in zha-network-card and red colored (offline) in zigzag after a couple af hour from last seen timestamp. In this seeming offline period the coordinator is indeed online and works as usual.
When last seen timestamp updates for some reason, the coordinator changes to “Online:true” or colored green again.
I’ve the same issue. I was looking to detect offline status and send notification so I could be alerted if it failed or was plugged out but I just end up getting multiple notifications a day
What version of HA are you using? I ask because similar issue jumped out in my HA in latest beta after 2 days of use
Lots of errors in logs albeit all working I guess, then all door/window sensors became unavailable etc.
So I guess it is not related to beta as problem persisted after downgrade to stable 2021.1.5.
Only way to tame it was to reflash my ZbBridge with latest firmware- and here it was I mean ncp-uart-sw_6.7.8_115200.ota and all OK again
But no idea what was changed in meantime…
Best, JR
I’m running ncp-uart-sw_6.7.6_115200.ota. I just tried upgrading to 6.7.8 but I get an error “Upload Failed Invalid file signature”
Not sure if I’m doing something wrong and I need to change some settings before it will let me update the ZigBee module.
Thanks, Figured I might need to do something like that.
I think I might just have needed to set the module to 75 (Sonoff ZBBridge) before I performed the update and then back to 0 after but used the full backlog commands you posted and it worked. I’ll have to wait and see if I keep getting random offline notifications now
The only way (which I’m aware of) to make the coordinator appear online again is to install the zha-map custom component by @Adminiuga and call the zha_map.scan_now service.
This will touch the last seen value and refresh your zigbee network map(s)
I’m not clear what functionality this offers that is not in current zha that is current release of HA, say 2021.1.5. @Dueller@Adminiuga can you verify that this is to be used with current releases of ZHA. In reading some of the issues at this github, it is indicated that the functions of this utility are in ZHA.
Starting from HA 1.0 the zha-network-visualization-card is built in. This deprecated custom component depended on the zha-map custom component by Adminiuga which is not deprecated.
Anyhow the author of zha-network-visualization-card ( @dmulcahey ) says to uninstall both custom components.
I uninstalled only dmulcahey’s component (now built in) and not the Adminiuga’s one because I find the zha_map.scan_now service still useful for the reasons we talked about above.
Thanks for helping me understand. So is all running this service doing is setting the coordinator’s online/offline value to online in the zigbee.db? In current release of ZHA addin, I get a visual map of devices, connections and lqi values. Is there something different generated by this module?
For some reason the coordinator appears offline after two hours since the last timestamp. That service refreshes the timestamp (and the visual maps as well).
As stated here by the ZigZag developer ( @Samantha ) and reported here by @drcoolzic, there’s a way to shorten the zigbee network scan interval putting the following code in configuration.yaml:
zha:
zigpy_config:
topology_scan_period: 20
20 is the scan interval in minutes (and is the lowest admitted value)
I set 119 minutes because every 2 hours my coordinator starts appearing offline (and it works).
Seems that in the near future will be added a service which allows to force the scan on demand like the zha_map.scan_now we talked about above. Until that time I will leave the zha-map custom component installed.
Basically the serial protocol API for EmberZNet Zigbee coordinator application running on the Silicon Labs SoC/MCU does not deal well with unexpected loss of communication caused by network drops. The reason Ember remote bridges over serial-to-IP proxy server is not recommended is that clients using the EZSP serial protocol requires a robust connection between the EmberZNet Zigbee stack running on EFR32 MCU and the serial port of the Zigbee radio. With solutions such as ITEAD Sonoff ZBBridge or a Ser2Net serial proxy connection over a WiFi network it is expected to see NCP entered failed state. Requesting APP controller restart in the logs. This is a normal part of the operation and indicates there was a drop in communication which caused packet loss to occurred between the zigpy radio library and the Zigbee radio. The use of serial network proxies/bridges/servers over WiFi is therefore not recommended when wanting a stable Zigbee environment with Silicon Labs Ember based Zigbee radios. The developers of the bellows radio library for the zigpy project has more information about this if needed.
PS: Recommendation is to use a USB extension cable with any USB radio adapter (Zigbee, Bluetooth, other RF or WiFi) just in order to get them away a little from possible signal interference if nothing else.
I have small under 20 device ZHA setup running with the Sonoff Tasmota Zigbee hub as well. It has been pretty stable as well. I do get a few ‘crc’ errors in bellows.uart log per day, I am guessing this is in line with what the developers are pointing out. With so many folks have struggles to get a stable ZHA network running, some with Sonoff hub, it’s pretty tough to recommend against the devs advice. I really like the architecture of having the zigbee coordinator easily movable to find an optimal place for it in home, but if cost is a less stable coordinator operation with great reception, the Sonoff hub is not the way to go.
I mean 