Just upgraded to 0.110.0 (without fully reading the release notes -my bad) and my whole zigbee integration went belly up. Gone are my Silicon Labs EZSP coordinator and all of my zigbee devices (all of my zigbee devices are light bulbs). I have done a little digging and discovered two things:
a) The zha integration has been demoted out of configuration.yaml; now it has to be brought in through GUI (nice for novices and first timers moving forward) but not so nice for users who have it setup and v 0.110 upgrade brings a breaking change to ZHA.
b) v 0.110 now supports python 3.8 and I’m suspecting this has to do with some of the errors I see in the home-assistant.log file:
2020-05-20 19:04:22 ERROR (MainThread) [zigpy.application] Couldn't start application
2020-05-20 19:04:22 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry /dev/ttyAMA0 for zha
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 217, in async_setup
hass, self
File "/usr/src/homeassistant/homeassistant/components/zha/__init__.py", line 100, in async_setup_entry
await zha_gateway.async_initialize()
File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 141, in async_initialize
app_config, auto_form=True, start_radio=True
File "/usr/local/lib/python3.7/site-packages/zigpy/application.py", line 65, in new
await app.startup(auto_form)
File "/usr/local/lib/python3.7/site-packages/bellows/zigbee/application.py", line 138, in startup
await self.initialize()
File "/usr/local/lib/python3.7/site-packages/bellows/zigbee/application.py", line 88, in initialize
await self._cfg(t.EzspConfigId[config], value)
File "/usr/local/lib/python3.7/site-packages/bellows/zigbee/application.py", line 230, in _cfg
assert v[0] == t.EmberStatus.SUCCESS # TODO: Better check
AssertionError
2020-05-20 19:04:22 DEBUG (bellows.thread_0) [bellows.uart] Closed serial connection
Any clues, anybody?
Thank you!
PS I had wipe and restore back to v 0.109.6; first time I had to do that, an odyssey indeed, but got everything back as it was.
I also have this problem, but as I am just testing zha integration I can live few days with this broken. I know one more person with exact same problem.
In my case it’s on pi4 with hassOS, Elelabs serial(hat) coordinator.
Same boat as you. Just started testing out Elelabs Zigbee USB and getting similar errors. Wondering if we’ll start to see more ppl encounter this as they upgrade to 110.
Long story short, if upgrading from 109.6 to 110 not yet investigated by Elelabs. However, they stated that it works as stated via GUI on a FRESH install.
I emailed Elelabs with my question about update and this is their response:
Hello Fernando,
We have tested our products with the latest 0.110.1 version.
It works as expected on a fresh setup.
You just need to add the product configuration through the GUI as you stated yourself.
However we still need to investigate if the update procedure from 0.109.6 to 0.110.0 works as expected or breaks the existing Zigbee configuration.
Unfortunately right now we can only advise you to reconfigure the product. Should work as expected.
It makes sense since I had been digging around the /.storage directory and there are quite a few entries that refer to ZHA and the Elelabs hardware specifically on the core.device_registry and obviously the zha.storage files; perhaps there are registry entries upon upgrade and config migration (moving zha entries frm config.yaml to GUI) that might get duplicated, rendering ZHA usless.
I have two options:
a) dig further and find every last bit of zha configuration, erase, upgrade and bring zha back or
b) start with a brand new install and bring everything else back (ugghhhh!)
This is completely ridiculous. I was running 0.109.6 with the Elelabs Zigbee Shield running on my Raspberry Pi 4 and it was working perfectly. I upgraded to 0.111.0 and my whole home went down. Same error as above.
Tried a fresh install with setting the config only in GUI, but the same error occur.
I tried downloading an old HassOS package hoping I would get an older version, but you guys have seriously not added the core package in the release. Instead it is mandatory to have an internet connection and the newest stable package is downloaded. You have now effectively locked me out of getting a working system in any way, shape, or form. This is the worst deployment model I have ever encountered.
Tried using the command “ha core update --version=0.109.6”, but it will not roll back. The lowest version I can roll back to is 0.110.0, but the problem exists in that version.
How do you expect me and probably others to get out of this current state?
This is clearly not thought through. Using these kinds of systems make you completely dependent on them. To get normal lighting I now have to put in my regular bulbs in the whole house. I am already considering moving over to OpenHAB. Feels bad.
Haven’t it been for the fix I would still be without Zigbee. I have been working within IT for over 10 years. Been serving complex solutions to both the government and private sector to 10.000 of users and being locked to the newest or the previous before newest version is unheard of. It would be unheard of even with the hot dog stand on the corner as a customer/user. It is a necessity to be able to install whichever version, whenever. The only way to get up and running on an older version for me today would be to pull docker images and install everything manually. Trying to help my colleagues with their installations the administration overhead would become to big. It needs to be Hass.OS with an easy way to downgrade, or flash the SD card with a fresh specific version.
With today’s deployment structure a similar issue will happen again and the affected user will again be painted in a corner with only the newest or the previous before newest version.
The only way to use an older version per now is to build the whole solution manually with docker images, or to build everything from source modifying the github pull info to pick the wanted version instead of “latest”.
You should be able to take components from previous builds and add it to your config/custom_components to override the current version. I got hit by a change to Z-Wave climate entities a few weeks back and used that as a work around until it was fixed.
Thank you for the tip! I installed HACS for the first time last week and was then introduced to the custom_components folder. I will try that in case something breaks in the future.
UPDATE July 19, 2020. Just updated to v0.112.4 from the v0.109.6 originally cited. Zigbee devices (Elelabs rb-pi shield and associated entities) migrated to 0.112.4 without a hitch. The process took a bit of time @~5min. to complete.
I’m just starting to try and get this working for the first time HassOS 114.2. Not coming up the the hardware port for the RPi4B (DEV/ttySO) only for the Pi3 (DEV/ttyAMAO). Did you upgrade to 114.2? Is it working for you? Are you seeing the port DEV/ttySO in hardware? What add-on app are you using?
Hi Eric.
Perhaps you’re referring to 112.4 not 114.2. As of right now latest version is 113.2. Anyway, my hardware is Elelabs Zigbee shield on a RBPi3B+, and It comes up just fine as /dev/ttyAMA0. In your case (RBPi4) you should use the /dev/ttyS0.
I remember having to do some configuration changes to the RBPi to disable the Serial Console. If this is the hardware you have, I would point you out to the instructions from elelabs. They have well written instructions on how to do the config changes here. Worse case scenario, you can contact them and they do respond, nice!
Once it is working, I have noticed the zigbee devices take around 3 minutes before they’re available after hassio reboots and comes back on line, this happens since I resolved the v110 hurdle. This behavior is not the best but perhaps my config might be to blame because is full of ghosts (started on v0.76), time for a clean install.
I just switch from Élelabs to Dekonz Conbee II because I was tired of fiting with Elelabs not restarting after HA restart. Each time I had to completely stop my Rpi4 and unplug the dongle then replug and retart. This was the only fix to get rid of assertion error on loading the device in ZHA. Once loaded it works just fine but it should be able to restart properly if HA restart or many zigbee devices won’t be available.
Also Elelabs do not work with HA 0.114 and 0.114.1. I’ve spent many hours trying to load it on HA 0.114
I just installed HA 0.114.3 on a pi 4, 4gb.
I also have an Elelabs zigbee shield.
I seem to have similar issue to yours where I cannot connect to /dev/ttyS0 and the device is not found.
I’m pretty new and will try to downgrade HA for now and see what happens.
I would also recommend to watch out for power supplied to your RB-Pi, specially with a Pi 4. Just last night I happen to notice after a soft reboot that my Zigbee shield items were missing again but also noticed a second RB-Pi 3B+ blinking on the red power led. Blinking power LED condition means the boards are starving for power.
The power supply I’m currently using is a supposedly 4.8 Amp that appears not to be up to the task. This is the replacement I got after one of the original poer supplies that came with my RB Pi Kits went bad.
To get the Elelabs back up, I had to power off my pi4 . Just restarting HA was not enough.
I also add a small fan to keep my pi cool. I bought a Pimoroni fan shim that just fit on the gpio, no solder nothing to connect and it keep my pi very cool. I can even control the fan via HA
