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
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?
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:
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 really don’t understand this fury against Sonoff ZBBridge.
The greater reliability of a wired line compared to a wifi link is obvious (as warned in the zigpy github) but somebody could be forced to use a wireless bridge for many reasons.
I personally use the sonoff device without any problem and the infamous error “NCP entered failed state” happens very rarely and does not affect my system reliability.
I am not able to uplaod the ncp-uart-sw_6.7.8_115200.ota file. I am still getting the invalid file signature message. I use tasmota 12.5.0. There was no reset action after the “Backlog Weblog 3; so65 1; Module 75” command given.
I have made a same mistake with the wrongly flashed tasmota (that fw doesn’t have a module 75). For the fix, I need to flash the minimal version first. Then the zb-version of tasmota and finally I was able to flash the uart fw.