To answer my own questions: I upgraded to the latest HA this morning and my Z-Wave JS has been stable for about 5 hours - longest so far. I’m cautiously optimistic.
My KwikSet door locks are just a disaster, but I’m not the only one at least. I’ll patiently wait for things to get better with the integration and/or the Z-Wave JS front. Worse case I may see what I can do on the MQTT side to get some basic functionality back. I’d think in 2021 I should be able to set my door to lock at night at the very least.
BUT, this is all new and I should point out that I’m super-thankful for the devs for whipping this up so quickly!
Im looking forward to try zwave JS in the near future but I came here just to so say thank you @petro, you do a hell of job explaining, providing a guide to shift from 1.4 and giving out support etc. Thanks!
I updated Home Assistant OS to Version core-2021.2.1 this morning and now Z-Wave JS for my blinds seems to be broken.
Logger: homeassistant.core
Source: components/zwave_js/cover.py:76
First occurred: 8:40:36 AM (2 occurrences)
Last logged: 8:41:46 AM
Error executing service: <ServiceCall cover.set_cover_position (c:139dafeb401c61abb248229316162ed5): entity_id=['cover.kitchen_2'], position=40>
Error executing service: <ServiceCall cover.set_cover_position (c:7c7fdb5f85ca035ac20d414329bc9241): entity_id=['cover.kitchen_2'], position=40>
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/core.py", line 1471, in catch_exceptions
await coro_or_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1490, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 595, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 664, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 632, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/zwave_js/cover.py", line 76, in async_set_cover_position
await self.info.node.async_set_value(
File "/usr/local/lib/python3.8/site-packages/zwave_js_server/model/node.py", line 250, in async_set_value
result = await self.client.async_send_command(
File "/usr/local/lib/python3.8/site-packages/zwave_js_server/client.py", line 64, in async_send_command
return await future
zwave_js_server.exceptions.FailedCommand: Command failed: unknown_error
service cover.xxx works for my garage door opener and also for the one blind I still have in HomeSeer (integrated via marthoc’s integration) but the service call fails for the blinds in JS…
I did the migration last night also and had the same experience. Everything worked but I didn’t move the config I just renamed all my devices and updated scripts and automations. I really needed to clean up my naming conventions anyway.
I just hope in the future the parameter passing will work AND someone creates a blueprint for it.
This is the driver to interface with ZWave created in Javascript. You can run it in NodeJS and it will give you an API to talk to your ZWave devices. This is still very low level and would not be used by an end user.
A NodeJS wrapper which adds a websocket to the above driver. This can be run within any NodeJS compatible environment and consumed by the Home Assistant Integration.
This is the docker container I’ve explained how to use. It enables you to control Z-Wave via MQTT or a WebSocket which can also be consumed by the Home Assistant Integration. When using MQTT anything that can pub/sub to MQTT can then control the network. This container also has the option to disable the MQTT Gateway or enable the web socket as per the ZWaveJS Server. It also has a control panel to see your network and manage your devices. Home Assistant can integrate with this either over MQTT or using the new Z-Wave integration to the websocket.
This is a minimal container for the Z-WaveJS Server (2). It’s deployed either as part of the Integration installation or from the Supervisor / Addons menu. The Home Assistant integration will connect to it over WebSocket as per the ZWaveJS2MQTT container (3).
Lastly there’s the Integration that was added in Home Assistant 2021.2. This can OFFICIALLY connect to either the Z-WaveJSServer (2), ZWaveJS2MQTT container (3), or the Home-Assistant Addon (4).
Yes it seems that whenever zwavejs restarts that HA restarts. I use docker for all of mine so I told HA that it depends on zwavejs so this way when zwavejs gets an update and restarts it will force HA to restart. If I have to bounce zwavejs manually I’ll just have to remember to bounce HA at the same time.
position & up & down arrows work. But mine needs to be inverted. In the old zwave 1.4 integration you could add something like this to the yaml file :
cover.rolluik:
invert_openclose_buttons: true
invert_percent: true
Is this already possible with the new ZwaveJS integration ?
@JumpMaster, thanks for this. This level of detail and delineation between the two efforts has helped me tremendously to understand what the options really are, and what each piece of the puzzle plays.
Just so I’m clear, in your final comment above, the first of the three options is NOT available to those of us running HASSOS, right? That is, we can either choose #5 to interface to #3 (either using MQTT or sockets) OR #5 to interface to #4, since if I understand it correctly, #4 is needed to interface #5 to #2 in the HASSOS environment. Do I have that right?
I’ll repost here my question that I already asked on GitHub:
The latest available version I can see of the Z-Wave JS to MQTT add-on is v0.2.3 and it still is not working. @DelusionalAI mentioned the docker image v1.0.5, any correlation to the standard supervisor add-on?
Trying to get an ETA here…
This comment is helpful. I’ve never (believed I) needed to use MQTT because I’m currently running HASSOS on a single RPi4 for everything, and only to control a BUNCH of zwave devices. Although I dug into it a little, I never really understood why or how one might choose to use MQTT in HA. I get the idea of using it to synchronize multiple instances of ‘systems’ on different HW, with publish/subscribe, but it never made sense for a single instance, as you appear to be pointing out. That always made me wonder why, other than to avoid network restart with HA, OZW chose to use MQTT, which did seem to only addl complexity and delay for a single instance. Perhaps I’m missing other benefits that are obvious to others. I’d love to find a resource that could help me put MQTT in perspective in relation to HA, if you know of any.
Ah ok, I see. I don’t use a docker install, but the supervisor version. So, I guess I have to wait for a fix then.
It’s good to know it’s not just me then.
Home-Assistant uses Integrations to talk out. So your options are either MQTT or the ZWaveJS Integrations (Web Socker).
If you want to use MQTT you need to use ZWaveJS2MQTT. That is hosted in docker.
If you want to use WebSocket you can use any one of the four options. But only The Home-Assistant Z-WaveJS Addon will work inside of HassOS.
I’d be interested to learn more about how all of that works, and is set up.