Mains-powered Zigbee Router devices will usually reconnect by themselves after a while if you just wait a few hours (though sometimes up to 24-hours at longest), however any sleeping Zigbee end-device like battery-powered sensors devices will normally need to be manually woken up.
If you have for example a door/window sensor then you will need to activate it by open or close the door/window so it will send a state update in order for it to connect again, similarly temperature
sensors need the temperature to change to send state update in order to connect again.
So a workaround for quicker reconnections is to take out and put back batteries in any battery-powered devices and just unplug and replug any mains-powered devices if can not make it force a state chnage.
My battery powered sensors came in directly, the smart plugs I turned off and on and came back. So for my it wasn’t a huge issue. Not sure why the sensors directly reconnected. I do have availabilty check set to true in Zigbee2mqtt, but that should cause the plugs to be pinged, not the battery powered sensors. I’m glad it’s flashed and all working well
Thanks, it does appear to be a ZHA issue. Should I sit tight and hope for an update? Or do I bite the bullet and migrate again over to MQTT? It’s still odd that ZHA did control the Lutron Aurora before I updated to the Sonoff 3.0.
Regarding the Lutron Aurora. I finally moved the Aurora I am testing from ZHA with Sonoff zbbridge coordinator to zigbee2mqtt with Sonoff 3.0 dongle plus. I was only able to receive the dimming events on ZHA config cite, the on/off came thru maybe 10% of time. This is a bit of a hack solution in order to get both the on/off and dimming info into Home Assistant. The Aurora seems to send messages in a way that make if hard to capture the actionable events. This combined with it’s kind of poor physical UX design and high price make for not a good choice IMHO. Link to the steps I did below:
Hello,
In case of a machine failure (RPi4) which is running with HA and Sonoff stick installed, can I just use another machine (for example a mini PC) and plug in another Sonoff stick?
Or do I need the same stick plugged in to the new machine?
Or in case the Sonoff gateway may get damaged, can I just plug in another one (backup)?
Or do I need to do update the adrress, etc?
It depends if properly backup Zigbee network then restore backups to another computer and/or dongle.
Zigbee2MQTT does perform automatic backups to local storage by default so if you restore that backup on another computer then yes it should work with any other CC2652 backed stick, see their FAQ here:
ZHA does however not yet have perform automatic backups to local storage by default so you would need to setup daily/nightly backups yourself and make sure it is replicated to separate storage. See:
Anyway, restoring a proper Zigbe network backup should also restore the address, etc. needed, but note that it will take many hours for devices to connect and Zigbee network to repair itself, and some devices might need to be manually woken up by pressing buttons on them, etc. to force a state change.
I recently got Sonoff Zigbee 3.0 Dongle plus (firmware: 20210708).
I am using zigbee2mqtt with Electrolama ZZH (CC2652R Stick).
My plan was to replace coordinator to Sonoff stick and make ZZH stick as router.
I changed sticks - Sonoff dongle is up and running, all devices stayed connected and working ok.
Next plan to make ZZH as router. I flashed ZZH stick with router software with FlashProgrammer.
Now when I plug this stick in - i can’t see it in zigbee network - it doesn’t try to join network.
My question - what am i doing wrong? Is there any additional actions needed? I have 23 devices in zigbee network, couple relays working as router, i’ve never added stick as router before.
Will it autojoin or do i need to make it somehow in pairing mode?
I have had this dongle for a few weeks, installed it using ZHA.
It worked, but I never felt it was reliable: slow reaction time, automations/scripts partially interpreted (like lights not always picking the right level)…
So, I tried to clean and reinstall. In doing so I noticed that the LQI of my devices was 100 at the very best (when the device is 2 meters away from the dongle), usually it’s around 40…
Could it explain my “disappointment”?
Would Zigbee2mqtt work better?
My HA is running on a virtual machine on a synology nas.
So I just came here to look for opinions on the previous firmware, but spotted this. I am using the CC1352P2_CC2652P_launchpad_coordinator_20210708 without any real issues… I was looking into backing up and upgrading to the CC1352P2_CC2652P_launchpad_coordinator_20211217 with the increased gain… but am wondering if I should just leave well-enough alone. I have an occasional disconnected bulb that just power cycling resolves but that has been pretty rare lately. Seeing that another update is on the way maybe I should just wait for that one to get ironed out? Am I missing out on anything by not upgrading? As I said no “real” issues… just the desire for the latest and greatest. But also don’t want to open a can of worms for no reason.
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.
