HI, z-wavwe integration details put aside, cant we just use the core mqtt integration?I mean, I use that currently, to propel the necessary topics of the Z-wave integration into the various HA instances.
I take it the new Z-wavejs integration simply creates entities with states, just like the former (now deprecated…) integration does?
I simply use mqttstatestream to take care of all publishing, and it is flawless, and very ecomomical.
Or am I missing something fundamental in my understanding of the architecture?
In line with @Mariusthvdb questions I am curious what people see as the Pros/Cons of using the now in beta
zwave -> zwave-js-server HASS addon -> zwave_js HASS integration (what I have been currently playing with)
vs
zwave -> zwavejs2mqtt custom container -> mosquitto -> mqtt HASS integration
It seems to me all the HASS dev work right now is going into doing the web service integration vs the mqtt intgration/addon but that plenty of people here have gotten the mqtt going.
Has anyone compared how devices come into HASS and react using the two different flow paths?
Is anyone working on a zwavejs2mqtt addon as a sibling to the zwave-js-server addon thats now already in the latest beta bits for HASS?
Removing the middle man MQTT server is a good step forward. It removes issues with MQTT discovery and it allows us to expand on functionality for each domain, functionality that may not exist if we stuck with MQTT.
Yes, if you are using the zwavejs2mqtt platform (I won’t call it an integration since it really isn’t yet) and using the mqtt portion you will need some sort of broker. You can use any broker you want. Either the core mqtt or, as in my case, mosquitto running directly on the host.
Probably.
I wonder how that will work using the zwavejs integration along with the mqtt portion of the zwavejs2mqtt platform?
I would guess it would create two sets of entities for each zwave device end point - one from the WS server and one from the mqtt portion?
I can see that getting confusing fairly quickly. So we would definitely need to disable the mqtt portion.
@makai thank you, good to know to play with zwavejs2mqtt myself
Removing the middle man MQTT server is a good step forward. It removes issues with MQTT discovery and it allows us to expand on functionality for each domain, functionality that may not exist if we stuck with MQTT.
@petro am I to take this that you think the zwavejs-server → home assistent intigraiton for WebSocket is ideal way forward vs the mqtt discovery route? Curious for more details as what you see pro/con to using web socket v mqtt.
One thing that I am missing from the websocket intigraiton is that it doesn’t have any of the add/remove node fucntionality or the device map. I am assuming tyhat is coming eventually via the websocket intigration, but curious what others are seeing/thinking/encoutered as they are playing with all of this.
Yes, it removes the middle man. Short term, it’s lacking at the moment. But it’ll get better over time. MQTT discovery only handles a few domains, any changes to MQTT discovery will also require changes for the middle man. Where as websocket is independent. Also, with websockets we can make custom services. With MQTT, you’ll be stuck with whatever mqtt has. This is just the tip of the iceberg.
It does, click on the zwave_js integration, click configure, and there’s a series of zwave management functions there. This will expand in the future. Also, expect services that’ll handle most of the basic/advanced zwave needs.
Most people trying out Zwave JS integration are using the ZwaveJS2MQTT addon without the MQTT server. This gives them the UI for ZWaveJS for management that doesn’t exist yet in the integration.
I thought this new JS variant of ZWave was supposed to stop the user confusion. I’m already confused how I should be upgrading and what I should be using once 2012.2 releases. I’m on a Home Assistant Blue and am currently using the OpenZWave add-on and the OpenZWave (beta) integration with the Mosquitto broker add-on in the middle.
No, it’s not to stop confusion. It’s to add a potential new path for users having issues with OpenZwave. OpenZwave’s development has slowed to a rate which caused many users to be upset because there are outstanding issues that have not been solved. OpenZwave will still exist and you should keep it if it works for you.
Jumped on to the Zwave JS bandwagon today. Seems to be much more user friendly than the OZW beta so far! I reset my z-stick to start my network from scratch (doesn’t bother me, its good exercise to add my 35+ zwave devices back in again!! The wife disagrees when everything stops working though )
Is there a user friendly way to add support for “unknown” devices at this time? I have an older model Aeonlabs HEM that worked in OZW but shows as unknown in Zwave JS. As well as several other devices that are a not so popular brand that probably wont ever get support if I dont try something on my own
Not yet, pretty much just open a GitHub issue for your device on the “node” entry. A lot of devices show up under “unknown” at first though, and as the network gradually sorts out its neighbours and completes various interview steps, it sorts itself out and becomes recognised.
If you’re waiting on this, avoid the mistake most people seem to make by contesting their networks with new interview attempts. The response for a earlier interview just gets discard if it’s received after a new interview is attempted >.<
I switched yesterday to the Integration from frenck. Startet with my 7 Devices from scratch.
All works fine till now.
BUT:
I can’t control my fibaro roller shutter 3 within HA. When I try to open or close with the buttons, I get an error-message (translated from German): "error to call Service cover/close_cover. None"
I can control the roller blinds from Apple HomeKit over the Integration.
Restart HA itself and Server don’t help…
Any Ideas?
EDIT:
With the Slider it works only the up- and down-buttons are bring this error
this sounds tempting… I wonder (and of course tried to find) if there is a place we can see with several screenshots jut how tempting this is, and how this compares to the current core, but deprecated, integration.
about the confusing but: right now, I have the Z-Wave integration and use core Mqtt integration (not the add-on which runs the broker, but the integration to publish ) with a few automations to publish entities and states.
With the new Z-Wave JS add-on, I would still need to publish the states using a separate integration? And apparently this new add-on ZwaveJS2MQTT does that?
Am I correct understanding this would still need a broker installed somewhere? Iow, Add-on ZwaveJS2MQTT is a direct replacement for the use of the Mqtt integration…? If so, what are the advantages of that add-on over the core Mqtt integration. Or is it only used for the Z-Wave JS communication, and would I still require the MQTT integration to publish my other states of that system.
My Architecture:
Production system: runs HA with core MQTT integration installed, publishes (eg commands the Z-Wave switches) and subscribes to topics (eg the sensors of the Z-Wave entities) of the Z-Wave system
MQTT system: runs HA with the core MQTT broker Add-on and MQTT integration only.
Z-Wave system: runs HA with the current core Z-Wave integration only, and publishes its states/entities as described above per core MQTT integration and automations.
In the above, I should replace the Z-Wave integration with the Z-Wave JS add-on, but also the Mqtt systems Broker add-on? …
I tried the installation of zwave2mqtt, only finding out that I have a problem with my network key. My key is a Hex key. And the webinterface does not allow me to enter it (it says the key is incorect). Is there any way I can convert it to a format that is supported?
step 2 it literally says:
Set your 16-byte network key in the form 0x01, 0x02... used in order to connect securely to compatible devices. It is recommended that a network key is configured as security enabled devices may not function correctly if they are not added securely.
Either that documentation is not correct or… I am also stupid
)
only the up- and down-buttons are bring this error
Oh really? How stupid of me. I did not know it was that easy.