2021.2: Z-Wave... JS!

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 :slightly_smiling_face:

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.

1 Like

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

1 Like

I’m experiencing similar problems as jds using the RP4 version. Multiple services fail to start, including ozw (but many others do run.) I tried restoring a snapshot, system messages say success, but there it wasn’t restored. I tried downgrading to previous core through CLI, but nothing happens despite a CLI message that it was completed. Restarts don’t help. Unlike jds, I’m not seeing a 401 error. I haven’t found anything in the log that has been helpful.

This is a fantastic release yet again, amazing work all.

Have just migrated over from zwave to zwaveJS and I have to say - the fact that this works so well yet has been developed in less than a month is staggering!

A few questions I’ve yet to be able to find the answers for:

  1. I expose my devices to Homekit with auto-start disabled, I don’t run Homekit until the event zwave_network_ready event gets fired. I can’t see anything documented about a similar event from ZwaveJS, does it exist? Or is it not required if running constantly in a separate container?

  2. Not a problem, but I’m getting the following warning on startup now:

Logger: zwave_js_server
Source: /usr/local/lib/python3.8/site-packages/zwave_js_server/client.py:95 
First occurred: 11:24:51 (1 occurrences) 
Last logged: 11:24:51

Connected to a Zwave JS Server with an untested version, you may run into compatibility issues!

Is this a known warning? Anything I need to fix?

  1. I don’t need it at the moment, but is setting node configurations from the UI in the pipeline for ZwaveJS development?

Again, amazing work all. Really impressive stuff.