FOSCAM Integration seems to have an issue. Old configuration is pulled and does not work anymore while new UI integration failed in different cases. Waiting for upgrade.
Went back to 2021.1.5 (complete restore!) in order to continue to use and see Foscam security cams.
Unfortunately same issue here
Good Morning,
I’m seeing this error after updating. Supervised installation with docker in 20.04 Ubuntu. The recorder fails to start after this error:
Error during connection setup: (psycopg2.errors.DuplicateTable) relation "ix_states_old_state_id" already exists [SQL: CREATE INDEX ix_states_old_state_id ON states (old_state_id)] (Background on this error at: http://sqlalche.me/e/13/f405) (retrying in 3 seconds)
I’m running a postgres backend and have not had any issues previously.
No really, just remove the “, 0x” from the OpenZWave key and you are there 
Similar to my problem, perhaps, so let’s hope some bright persons can help.
To me, it looked like it’s just the zwave devices that have disappeared, but even after restoring the whole config it’s still the same. And I got the same message as you. I’m on Intel NUC, debian 10, supervised. It was very stable in 2021.1.5.
There is whole thread regarding downgrade.
I’d assume you should use from SSH:
hassio ha core update --version=2021.1.5
OK. I have a lot of zwave devices from locks, dimmers and switches. And Im currently not home to troubleshoot if something goes wrong. Is it safe to update my HA? I’m kinda scared to hit that update button.
Same issue - quick Google search tells me to login as root. Using a monitor and keyboard on my rpi3. App still can’t login due to «SSL error». In hassio click, command “core check” reveals “error 500: server error […] lookup registry-1.docker.io: no such host”
This is the first time I’m having an issue upgrading.
It crashed my installation too. Nothing works. I first thought it was only zwave that had died, but there’s more. IKEA tradfri, node red, … When I try to restart the core from within HA it gives an error saying it can’t restart because a task is running. So my guess is that there’s some startup task that’s stuck in a loop and preventing everything else from starting. Debian 10 supervised installation on a nuc.
I have tried the /dev/serial/by-id way of identifying the usb stick. But that’s useless in my installation because I have two aeotec sticks running two separate zwave networks (built-in and ozw). They both have the same serial number! Bad job by Aeotec. So I use the usb position instead to keep them apart.
so I bit the bullet, and deleted the deprecated Z-Wave, installed the new Add-on JS and after that it auto-installed the integration JS
Found all of my devices, albeit many without any info I had before. Maybe it will take some time?
still, let me ask this: is it correct we don’t have a domain zwave. anymore? With the deprecated integration all devices were from the zwave. domain and easily found like that. Right now, there’s no such thing?
though my Aeotec stick is found and listed in the device list, I cant find any of them like before, so cant list the devices in the frontend ?
Same here. Doesnt seem to work as before. Full permissions shouldnt be necessary in my opinion. Except the author of the component had a reason for this.
Hi
how will this Zwave JS work together with the card RaZberry(connected via the GPIIO bus)
The user now needs access to FritzBox settings which wasn’t necessary before.
After choosing the ‘google’ phonebook, name lookup is working again (after updating sensor names to the ‘old’ names).
Upgrade question here: If there are upgrades available for Core, Supervisor and Home Assistant, is there an order in which to do that, or does it not really matter? I would guess order as I described here, but was just wondering…
Working up from the host to the software I would do it in the exact opposite order. OS, Supervisor, Core.
But I doubt it makes much difference.
Did the check and again I get a error on IDNA.
Testing configuration at /tmp/config
Fatal error while loading config: (idna 3.1 (/usr/local/lib/python3.8/site-packages), Requirement.parse('idna<3,>=2.5'), {'requests'})
Failed config
General Errors:
- (idna 3.1 (/usr/local/lib/python3.8/site-packages), Requirement.parse('idna<3,>=2.5'), {'requests'})
Successful config (partial)
pip install idna==2.6
Error still there.
What can I do to solve this now? The pip install always worked…
| Version | 2021.1.5 |
|---|---|
| Installation Type | Home Assistant Supervised |
| Development | false |
| Supervisor | true |
| Docker | true |
| Virtual Environment | false |
| Python Version | 3.8.7 |
| Operating System Family | Linux |
| Operating System Version | 5.4.79-v8+ |
| CPU Architecture | aarch64 |
| Timezone | Europe/Amsterdam |
That doesn’t work because it thinks that it is still starting up:
sudo ha core update --version=2021.1.5 ⣾ Processing... ERRO[0000] Unexpected server response. Status code: 401
Processing... Done.
Unexpected server response. Status code: 401
If I don’t use sudo, it claims that it processed fine, but it didn’t actually do anything.
After a reboot everything is okay
Won’t complete startup, many services never start, no zwave devices visible, and no errors shown in supervisor. Last message is that new HA API token is updated. I try reboot, same thing. I delete OZW addon, reboot, and same thing. I try to downgrade to previous version by CLI on SSH, but that won’t happen because of 401 error. Install ZwaveJS, add correct data to config, start addion, things look correct in log file and devices discovered. Reboot, and same thing. Can not find any error messages that look new or helpful.
System: Home Assistant OS 5.10 (aarch64 / raspberrypi4-64)
Home Assistant Core: 2021.2.0
Home Assistant Supervisor: 2021.01.7