You have to stop bridge before OTA upgrade:
Backlog Weblog 3; so65 1; Module 75
then update and start again:
backlog rule1 on system#boot do TCPStart 8888 endon ; rule1 1 ;template {"NAME":"Sonoff ZHABridge","GPIO":[56,208,0,209,59,58,0,0,0,0,0,0,17],"FLAG":0,"BASE":18} ; module 0
Hope this helps, JR
PS reference is from: Digiblur
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
BTW updating the module to fw 6.7.8 does not solve the “offline” issue.
Two hours after the last seen timestamp the coordinator appears offline again.
OK, my scenario was much worse- tons of Zb errors in logs before- source not clear yet 
Now runs OK 
Best, JR
I also have the offline issue. Strange 
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.
Thx!
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.
Sonoff ZBBridge WiFI bridge from Itead is not a robust solution with ZHA because the protocol it uses.
Read zigpy devs warning here: https://github.com/zigpy/bellows#warning-about-zigbee-to-wifi-bridges
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.
Ember USB Zigbee adapters/dongles/sticks (like this) are highly recommended over using a remotely network connected Ember module using a serial-to-ip bridge / serial forwarding server like ser2net.
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.
Mine has been running for a month straight, never once saw this in any logs.
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.
Suggest that you checkout this project as it works the same but use wired Ethernet instead of WiFi:
It doesn’t entirely solve the issues but using wired Ethernet instead of WiFi is a more robust solution.
Appreciate constructive feedback in home-assistant.io/issues/17170 if think Sonoff ZBBridge should be lísted in ZHA integration documentation as in the top of the list of “known working radio modules” or not:
That way all those comments for and against can be collected in a single place for considerations.
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.
Hello,
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.
Strange, just did the upgrade to 6.7.9 for a curiosity- all went smooth as defined in my previous post 
Best, JR
BTW are You using a downloaded ota file?- I do…
Hi,
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.