This team is just bloomin’ awesome - thanks for all the hard work - looking forward to DHCP Discovery, deCONZ logging, and seeing Tasmota is out of beta give me confidence to sever some server ties
Thanks
Since the installation of this version my memory usage has gone to 80% instead of 30% and nothing has changed in the installation only this core update are more people affected by this?
I have tried restoring from backup and my zwcfg looks fine. I restored the entire config directory structure, which I make a backup of every night, but HA still is 2021.2 and no problems are solved.
How can I go back to 2021.1.5? I’m on a NUC, debian 10, supervised
I had the same “issue”.
I had to configure it via the UI now.
I gave the user full permission, then configured the integration and then removed the permission from the user.
Seems to work fine.
But of cause, all my automations don’t work anymore…
Did I miss the information about this change anywhere?
Unfortunately with this version, my Foscam´s are not working anymore. I use the Foscam 9902 which need the rtsp port setting in the configuration.yaml to be able to see the live stream. As Foscam is now an integration, the rtsp port cannot be set anymore and therefore all my cams are not visible anmore, also not in “auto” mode, which gave me a “freeze picture” before.
I’ve been playing around with the newly added ability of using input numbers for threshold values in numeric state triggers.
trigger:
# - platform: template # OLD CONFIG
# value_template: "{{ states('sensor.cpu_temperature')|float >= states('input_number.rack_fan_on_temp')|int }}"
- platform: numeric_state # NEW CONFIG
entity_id: sensor.cpu_temperature
above: input_number.rack_fan_on_temp
However it looks like I will be sticking with the template trigger as this monitors both the input number and sensor for changes. Where as the numeric state trigger only listens for the sensor crossing the threshold set by the input number.
e.g. for the config I pasted above, if I adjust the input number below the current sensor state the template trigger will occur immediately but the numeric state trigger will not occur until the sensor updates (and crosses above the value held by the input number).
It’s an edge case, and won’t be of much significance to most people, just something to be aware of.
2 Likes
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.
1 Like
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).