I doubt that Zigbee2MQTT would be more stable as your issue is more likely due to things like noisy RF environment, old firmware, poor Zigbee network mesh or one or more bad Zigbee router device. Read:
Do you happen to have several spinning hard-drives in thatNAS? Those will also cause EMF/EMI/RMI!
Have you connected the dongle in USB 2.0 port or a USB 3.0 port in that Synology NAS or a computer? USB 3.0 ports/peripherals/devices/cables are known to cause A LOT of interference with 2.4GHz radios. Just browse this USB 3.0 EMF report from Intel → https://www.usb.org/sites/default/files/327216.pdf
Tip there is to find a longer and thicker USB 3.0 classified extension cable as those will normally have more/better electromagnetic shielding than a thinner cable, and then get the dongle even further away.
The point is that Zigbee Coordinator adapters are very sensitive to EMI/RFI interference. Having a noisy RF environment will jam the signal and prevent adapter from receiving all messages to it without errors.
This is why connecting the dongle via a very long “shielded” USB extension cable in a USB 2.0 port or USB 2.0 hub (and not a USB 3.0 port) is recommended as it is the easiest way to get further away from
well known strong sources of EMF. Wi-Fi router and Wi-Fi access points are of course also well known. Also, make sure that you use enclosures/chassis/casing for hard-drives and computer/single-board-computers/network-attached storage that are made of all-metal instead of plastic for EMF shielding.
Search this thread as it has been covered several times before.
Summery: You can enter boot mode (Bootloader/BSL) via software if application/script support it or by holding the boot button when plug it in to your computer.
BSL was formerly known as the bootstrap loader but is now commonly known as a ROM Bootloader or just Bootloader. It is basically its own firmware on a microcontroller which allow customers to flash the main application firmware without having to have separate a JTAG/cJTAG/TTL adapter. As long as you have a functioning Bootloader then you can upgrade and/or recover a bad/corrupt application firmware via USB without any special tools. You can kind of think of a Bootloader as a microcontroller’s equivalent to the BIOS/UEFI on a computer’s motherboard with will allow you to install a new operating system to the storage.
Depends on which Zigbee implementation you are using. Easiest way is probably to backup the Zigbee network and restore to the new Zigbee network. That can be done via zigpy-znp CLI tools or with other tools depending on which Zigbee implementation you are using.
Appreciate the time you took to answer.
I think my problem is a bit more complex and may not need ieee address writing on a new zigbee stick.
I have RPi4 with zigbee2mqtt installed and a Sonoff Zigbee 3.0.
In case something is failing to work suddenly (RPi4 or Sonoff gateway), I would like to use a miniPC (which is already with HA and weekly backups installed) with another gateway or the same (if only RPi4 will fail).
Questions are:
In case, the Sonoff gateway will fail, can I just plug in another gateway in the RPi4 without doing other operations?
In case the RPi4 will fail, can I use the existing (in use gateway) and just plug it in mini PC? Answer should be yes, should work.
In case RPi4 + gateway will fail, can I just start the mini PC with another gateway (backup one)? Will the zigbee devices look for the gateway automatically or will they look for a certain gateway with a certain ieee address?
I believe that the FAQ on Zigbee2MQTT website does cover most if not all of the disaster recovery scenarios scenarios you list and as a summary should at a minimum consider regular replica of the data/ directory to external storage as a secondary backup that is not on the same computer or storage where you are running Zigbee2MQTT. At least if you often make changes in your Zigbee network.
PS: NVRAM backup should not really be needed but even if overkill you could play it safe and save a NVRAM backup image file to a backup storage location every time do a firmware upgrade to be sure.
Hi, I’m currently using CC2652P based dongle with CC1352P2_CC2652P_other_coordinator_20211217 firmware. This CC2652P was from third party vendor with some 3D printed casing and the build quality is poor.
And recently I bought the Sonoff Zigbee 3.0 USB Dongle Plus and I’m planning to replace the existing CC2652P dongle with Sonoff dongle as coordinator. I believe the Sonoff dongle will perform better and I know we have to use the CC1352P2_CC2652P_launchpad_coordinator_20211217 firmware instead.
My question is, do I need to repair the all the devices since I’m switching from other_coordinator firmware to launchpad_coordinator firmware?
There should be no issue for zigbee2mqtt side as I’m currently running the latest version which has the backup capability.
For what it’s worth, I flashed mine with the router firmware after switching to zigbee2mqtt and it added immediately. So I can’t speak to ZHA, but it works that way at last.
yes it’s on build 20211217.
I moved to zigbee2mqtt, more control IMO, but the values remain low.
I guess it’s because my Synology is next to the Wifi router
I was wondering if you could give me a hand - getting this Sonoff Zigbee 3.0 USB Dongle Plus working with my HA via Docker on a QNAP NAS.
I’m somewhat confident with containers - I’ve set them up on my QNAP NAS for other things using YAML text - with multiple services etc to group containers, passed ports from router, setup NGINX, reached the HomeAssistant instance via DNS etc.
(So I’m not a complete noob! - but no means an expert)
I’ve been quietly enjoying learning the linux command lines (reminds me of MSDOS from my youth!) and was able to SSH into the NAS, realise the Sonoff USB device wasn’t detecting - found a QPKG that I think has the right drivers - and when this QPKG is in place - I can see the TTYUSB0 (I think)
I preferred using this for the drivers as it will mean the drivers stay in place when the system updates.
I’ve tried passing the device with a line in the YAML file - and passed through ‘as is’ - and I get the prompt to try ZHA, but if I do it manually or via ‘add integration’ for ZHA - I select the right ‘ZHA chipset’ as instructed (Option 4 from memory) (I also tried all of them in frustration) but then get an error about cannot initialise.
I tried it on the front USB port in frustration - and it crashed the NAS. SIGH (Hence the lack of detail as it’s taking FORVER to reboot)
Is there something obvious I’m missing?
Maybe the driver on the QPKG is the wrong one?
Maybe I need to update the firmware in the stick?
Maybe I’m missing something obvious when passing the device to the container?
Maybe I should install HASS on a seperate machine never surrender!!
thank you - sounds like an excellent diagnostic next step - will give it a try… later
had to hard power off NAS as it had totally hung - I thought maybe it was stuck after trying to reboot it once - so held powere button again - this time I’m giving it ‘as long as it wants’ and will leave it overnight.
I can here the drives rumbling away on and off - so it’s ‘alive’ but LCD screen still says ‘Booting’ and it wont respond to pings