Mutt
To clarify : -
Is this just for the current ozw 1.4 z wave implementation ? As fishwaldo implied that two methods are being developed for ozw 1.6
This makes it sound like its the ‘only way’, have I got this wrong ?
To clarify : -
Is this just for the current ozw 1.4 z wave implementation ? As fishwaldo implied that two methods are being developed for ozw 1.6
This makes it sound like its the ‘only way’, have I got this wrong ?
That’ll be OZW 1.6.
I would expect it to replace the current Z-Wave integration once it’s stable, it doesn’t make sense to keep the old integration around for long at that point. Of course, the old States UI is only just about to go away, so there may be a long overlap 
I’m interested in if the Aeotec siren/doorbell 6 would work with this as of now. I will try it out but if anyone gets there first, please do tell 
Great news! I bought two for my workplace and was disappointed that they didn’t work as expected right now, so this will be much appreciated. Will definitely help out with testing the custom component.
Your device pairings are stored on your stick so no worries, you won’t have to recreate your mesh.
1 reply
Thx, gr8, sounds good
I’ll have to wait for the lock and cover domains before I could really test this out 
No, it’s not integrated yet, when that happens it’ll be very clearly announced.
Yes, you add devices to the stick/HA just as you always did.
So if I’m correct this will work more or less the same as zwave2mqtt together with their hass integration via Mqtt?
The problem people are facing now is that the zwave controller restarts when home assistant is restarted. Will this problem be gone with this new integration ? Is the qt-openzwave running as add-on?
2 replies
That’s not really a problem.
It runs in a separate docker container from what I read.
Both the new methods (According to FishWaldo) will have z wave running in it’s own docker (probably the same one for both) and these will NOT be restarted when HA restarts (But will when you reboot, obviously)
The difference will be how HA communicates with this z wave docker, there may be an additional layer in the MQTT version, but this will allow consistency for current users of MQTT.
For ‘some’ reason the ‘feel’ is that the MQTT version ‘may’ be first out of the gate. But don’t put money on it either way.
Correct, at this time we’ve only implemented the most basic stuff like (binary) sensors, switches and lights. That part is actually pretty stable already and we’re now moving on into getting the other devicetypes integrated. As the foundation is solid, that should go pretty fast next couple of weeks. Check Github to see our progress and help us with submitting your own mqtt dump of devices.
1 reply
Hi Marcel.
I can see the pace is fast 
aeotec3|690x170
As of now - the devices seems fully discovered - and all the sensors are working.
it works stable.
So looking forward to the next step.
i will keep updating to the newest version released.
br Ronni
Is there any way for the non-hassio ( 
) users who run HA in Docker to easily get the OpenZWave daemon? Is there a Docker image already set up for it outside of the add-on?
Is there any way of seeing what the network contains? I can see in the mqtt messages that I have a node 1 and 2, but no other info, and I don’t have any entities in the integration.
I would really like to just reset everything and start over, but I don’t know if the messages are retained and that’s what I’m seeing.
edit: As a second thought I think I could disable this, start up the regular z-wave and check there maybe?
I removed everything and reconfigured from the beginning instead, and now I do see a sensor in the integration! However when I try to add another one I can see in the mqtt that it is discovered but it’s not present in the integration and it’s not showing the same information in the mqtt message as the first one (both are aeotec door/window sensors). Am I missing something maybe? Restart required?
How do you pair & manage new Z-Wave devices using this method?
Hi,
Maybe I am late to the party by we have been working on an integration using Z/IP Gateway from SiLabs rather than OpenZWave. Using this approach it may be possible to use more advanced Z-Wave features not yet available in OpenZWave such as S2 and SmartStart. This solution could also be certifiable since Z-Wave alliance only allows using Z/IP gateway rather than direct access to the Z-Wave chip.
The project is available here:
If anyone is interested in helping out integrating this into Home Assistant, please contact me.
2 replies
Pyzwave looks like an official and much better way to integrate Z-Wave. It would be able to support all current features lacking today and all upcoming features.
Can someone point me to a thread about what is going on with z-wave? All of the newer builds leave my 30+ nodes unavailable. I rolled back to 103.6 and some nodes work sometimes. This is really a bummer as z-wave has been stable for so long.
1 reply
Nothing to do with the new integration that’s being worked on - I’d start a separate thread.
@marcelveldt and @Tinkerer, forgive what may be a stupid question, but how does this differ from zwave2mqtt? I only ask as I am about to ditch my Vera and was planning on using zwave2mqtt until I saw this.
1 reply
The zwave2mqtt implementation is communication from HA to your zwave hub (the message protocol within the zwave network will not change, it can’t) For most people who run the zwave stick on their Pi’s this is a VERY short journey.
If you have a LOT of mqtt stuff going on anyway, then you might prefer to keep a standard look and feel to your config, in which case mqtt is the way to go.
If you read this whole thread it will give you an idea about why’s and wherefore’s.
The mqtt otherwise adds another layer to communication.
Both the standard zwave implementation AND the zwave2mqtt implementation are being updated to OZW 1.6 (any following upgrades (OZW 1.8 is being talked about) will be transparent given the new implementation methods). Both will run in their own docker.
It is likely that the zwave2mqtt version will get/has got it’s dockerised version first.
I’m going to be hanging on for the straight zwave version
You pays your money you takes your choice
I’m not sure I understand your response. I’ve read the thread but Both the OZWDaemon and zwave2mqtt implementations integrate with the core OpenZWave (and thus the USB stick), and according to the blog post, the OZWDaemon implementation also uses MQTT to communicate with HA. So in my head it seems like the software stack of the two are:
OpenZWave -> OZWDaemon -> MQTT broker -> HA
and
OpenZWave -> zwave2mqtt -> MQTT broker -> HA
I’m guessing that I am misunderstanding something, and of course that final arrow of getting the data into HA would be different for each approach, I’m just curious what is functionally different between the two.
2 replies
I read the front page of the attached link you gave to the github repository but I’m not sure I understand.
As I explained just a few posts above this one ‘we’ (as in HA users) will soon have a different access model which will allow a clearer modular api so that future zwave versions can be upgraded seemlessly.
Our upcoming implementations with both run dockerised and you will have options on the standard HA message structure (to communicate with the hub) or an mqtt’ised version for those who have extensive iot device landscapes.
From what it says on the link, it does not yet support unsolicited reports which may be an issue for many users, so I’m at a bit of a loss as what this brings to the party (excuse my ignorance).
I’m guessing from the name that you will be offering access to the zwave hub via an ip (network) port on the hosting machine. So continuing to follow this supposition, I’m assuming you could place the device central to the service area and access it from a remote location (say from HA) via tcp/ip ?
Edit: the link page talks about the api being subject to nda’s as a proprietary standard. Where will this lead you when the standard is to be opened up later this year/early next ?
Sorry if I’m being stupid
1 reply
There is no mqtt broker in the first option
The major difference is to how people like to construct their code, in mqtt style or vanilla HA format.
That’s my current understanding at least from ALL the posts I’ve read and the news from other sources.
I’m always open to correction but I’m pretty sure this is the case.
1 reply
Same, but different.
Ultimately the official integration should end up with a UI for managing things in HA, where Z2M won’t. That’s probably going to be the main difference.
It is correct that this is an issue that must be solved. But it is certainly solvable! It “just” needs the listening dtls socket setup correctly. The rest of the logic for receiving the frames is already implemented.
Yes, it could be setup like that. In many cases it will be the same machine.
What it brings to the table is that is does not use the reverse engineered OpenZWave for communication. Instead it uses the official implementation released by SiLabs. This has some benefits and mainly:
One of the drawbacks is the the Z-Wave USB adapter must be running a specific firmware version, so not all current adapters will work. That’s the comment about NDA. Because it is possible to make it work with any existing adapters but that will require work that I (and the company I work for) cannot release currently. If this may change when Z-Wave becomes fully open source then I will happily release it. And this “add-on” will require that S2 is implemented separately since the software from SiLabs will not be used at all. I hope this makes it clearer?
So:
Using compatible adapter => all bells and whistles will be available.
Using older adapter => all newer functionality must be implemented by the community.
Thanks a lot clearer.
Would it be possible to provide a list of currently certified adapters ?
Given that you say ip access would be available over ip to a device with a certified adapter attached how would this device look ? Hardware, OS, any software layers, device integration layers ?
I assume costs for such would just be time of the Tinkerer (pun as one of our moderators is called that too)
Thanks in advance
2 replies
I am not sure that exists currently. That’s up to the community to test, I guess. The firmware for the Z-Wave chip comes in different “flavors”. For Z/IP it needs the one called “Bridge Controller”. Some may have “Static Controller” that will not work (but could be reflashed).
Some more clarification.
Z/IP = Z-Wave over IP. This is a specification from SiLabs on how each Z-Wave node can be accessed over ip.
ZIPGateway = The software from SiLabs that implements Z/IP. This software exposes an API that is accessible over ip. This is what pyzwave connects to.
ZIPGateway could be running on the same machine as HA or it could be running on a separate. This is up to the user but I guess in most cases it will be the same.
ZIPGateway must be running on the same machine as the USB adapter is connected to. ZIPGateway will do the communication with the USB adapter.
I (and pyzwave) is not behind neither Z/IP nor ZIPGateway. Both is what SiLabs offer and the only allowed approach for implementing S2.
Z-Wave is now implemented in hass by leveraging a python wrapper around OpenZwave, this leads to multiple issues, most important that the python wrapper can’t cope up with changes in the (O)ZW specs. And there’s also usability. The Z-wave mesh takes a little time to start as it needs to interview all nodes. Because OZW is the controller and it’s directly attached to Home Assistant, restarting Home Assistant leads to restarting the Z Wave mesh.
What we want to do is detach the OZW Controller/mesh from Hass and that’s where the OpenZwave Daemon jumps in. It’s maintained by the developers of OpenZwave itself so directly at the source. It “translates” the Z-wave mesh (serial API) to deliver it to connected clients (such as Home Assistant). It uses MQTT as the transport protocol because it’s well known and easy.
So the new Home Assistant implementation is just one of the clients for the OZW Daemon, there will also be a control panel etc. Or attach OZW Daemon directly to other platforms like Node Red.
So you can see this OpenZwave Daemon as an alternative to the Z/IP specification, living in the open source/community world.
Zwave2mqtt is a node wrapper around the OpenZwave library, translating the mesh and it’s devices into MQTT topics. It’s goal is to use MQTT to communicate with Z Wave devices while in the OZW Daemon approach (where we’re working on), MQTT is only used as transport between clients, no translation happened yet.
Z/IP is the closed source approach but would require special hardware/hubs or additional software licensing costs. See it as a proprietary hub and OZW as the opensource software hub. It can also be implemented into Hass, just like other hubs like Hue, vera and such.
To sum it all up:
Current Z-Wave component in Hass: openzwave 1.4, wrapper around ozw. Will most likely be phased out once new implementation(s) are better.
Zwave2mqtt: NodeJS wrapper around OZW libs, very actively maintained and provides full functionality. Translates Z-Wave mesh with all it’s devices to MQTT world, to be used by every platform that understands MQTT, including Home Assistant offcourse.
New Z-Wave component (as discussed in this post): Will be an official homeassistant component to replace the current Z-Wave component and translates Z-Wave mesh/devices into something HomeAssistant can understand. It’s talking to the Z-Wave mesh through the OpenZwave daemon using mqtt as the transport protocol.
Z/IP: Is not supported yet by Home Assistant but in theory the new Home Assistant component should be able to also talk to Z/IP gateways instead of/in addition to the OZW “gateway”.
1 reply
@marcelveldt Thanks, that’s very informative.
So I was wrong when I told @zacs 'there was no mqtt in the “HA New Z-wave Implementation” ’
To be honest I’m not sure why it’s there as the MQTT structure doesn’t extend into the mesh (but then it’s a closed proprietary system, so maybe it does ! ) and I suppose any wrapper needs “A” protocol. and mqtt is a common open standard.
Given this, it sounds like the “HA New Z-wave Implementation” will be the one containing the extra layer and the Z-wave2MQTT one ‘more native’ - that is unless mqtt itself is a layer on HA itself so mqtt translated in, processed, and then translated out again.
This is all quite confusing 
Given that I generally run “as vanilla as possible” and as the statement by Fishwaldo and others that future ozw upgrades will be modular and transparent, I think I’ll stick with that.
Further, when the standards are ‘opened up’ then there will be ‘something’ put in the ozw slot so it will probably be rewritten as needed or as an ‘official core’ dropped in (with suitable modifications around it to accommodate it).
@Tinkerer given the current explanation of Z/IP, the avoidance of discussing cost and (to be honest) my conceptual usage scenarios … I don’t see what benefits Z/IP would bring me. So again I’ll be taking the vanilla route.
Thanks to all for educating me 
and the time (and patience) required to do it 
@marcelveldt - Thank you. This is a very helpful summary (and overview of the alternatives). I think it would be useful if this (or something like it) made it into the HA Z-wave docs at some point.
I have a question about topology:
For the new Home Assistant Z-wave component that uses MQTT as the transport to talk to the OpenZwave Daemon, is an MQTT broker required in the middle between the OpenZwave daemon and HomeAssistant?
(Or will the OpenZwave daemon essentially be it’s own broker to simplify deployment?)
2 replies
I didn’t see an answer above, but perhaps I just overlooked it. Would there be a possibility of migrating our existing zwave devices to this new configuration or will this require rebuilding our zwave network? I like this idea as this is a common pain for me to deal with, but I also don’t want to rebuild my network again as its always such a PITA to redo everything.
1 reply
Yes, you’ll need an MQTT broker you run. If you use Hass.io Home Assistant you’ll be able to install the Mosquitto add-on. If you use another install method just install Mosquitto.
The inclusions are stored on the stick, so as long as you use the same stick there’s no issues. I know the dev is looking at what they can do to migrate all the existing entity_ids so that you don’t have to change anything, but I don’t know what the state of that is.
Worst case, you’ll have to rename some things.
Thats totally tolerable and easy to get a backup of if needed. Thanks for the confirmation.
Anyone have tried and managed to use the set_config_parameter service call? I can’t seem to format it the right way.
Edit: I tried to do something else than what I thought
At this time you need to have a MQTT broker already setup but when we move towards official inclusion we will take care of that in some automagic way
I think it’s only a matter of time until Z/IP will also be supported. In an ideal world you will have just one Z-Wave component in HomeAssistant and it will take of handling the correct “route” for your situation. Our current route with detaching the hass component from the actual controller is preparation for that…
I am actually glad you guys are working on this and cannot wait to see it released in HA stable. Well done and thank you!
Is there any chance whatsoever that this will finally support the Enewrwave zwn-sc7 seven button scene controller? It has been supported by Vera for years and it is the only holdout I have for keeping the old Vera Plus running. I would love to finally get everything all under one roof…
1 reply
That seems to be up to the openzwave developers. Ask them.
EDIT: which I see you have already done.
Forgive me if it’s been answered, but I didn’t see as I scrolled through.
Will this new and improved Z-Wave system (working with OpenZWave Daemon), allow us to have the Z-Wave controller on a physically different computer?
I have a Razberry GPIO module set up on a Raspberry Pi 3 in one part of my home, but am running HomeAssistant on a Raspberry Pi 4 in a different area. The Pi 4 has a case on it for cooling and mounting, but while it has a GPIO extender built in to get around the fan and heatsink positioning, I’d rather not have the card poking out into the open, especially with 2 curious cats around 
Yeah since long time Z-wave user, this is what i look most forward to in Home assistant
Just got the new z-wave system up and going to test it out, and noticed that it is starting to get merged into the core repo! Thanks for all your work everyone!
Wanted to encourage @mickeprag to continue your work! A future where the one HA integration can work with either the OZW or Z/IP backend would be awesome! You might consider putting a MQTT frontend on your pyzwave work to leverage the work being done on the new HA zwave stuff. I wish I had the bandwidth to help out. Adding ZIP Gateway -> pyzwave -> MQTT broker -> HA would be awesome.
1 reply
Other than when it’s ready? I’d expect we’ll see the first sign of it in 0.110 or 0.111, though the existing integration will remain in place too.
Does this also work on a synology nas?
A minor question – I’ve tried current built in ZWave integration in HA, the zwave2mqtt add-on, and now this new pre-release yet to become the default integration. While most of my zwave requirements are only for door locks, and I realize this integration doesn’t yet have door locks programmed, I do see my door locks battery level with this new integration through mqtt.
My big question of the day is, 1) how do you add new zwave nodes with this new integration?
As far as I can tell, there is no way to add nodes or secure nodes through any sort of front end. I assume I have to use a CLI directly accessing the docker container. Can someone point me how to add new zwave devices with this integration?
1 reply
@Fishwaldo thanks for the feedback, and all of your hard work on OpenZWave, since it appears you’re now the main person driving that project. I look forward to the new integration when it’s complete.
1 reply
Could anyone please shed some light on which components are needed in the current 101 version to make zwave work? In the HA community addon-store there is Z-Wave to MQTT, in the official addon-store there is an Openzwave, and there is the Mosquitto broker. Among the integrations, there appeared the zwave integration, does it have to do anything with the addons at all? I might not be so knowledgeable, but I find it quite confusing. A single guide would be handy how to set it up properly.
Regards,
Gabor
The regular “Z-Wave” integration is the current integration. All it requires is a Z-Wave usb stick connected to your HA system, but it uses an older version of OpenZWave, so some device support is lacking.
The new integration is “OpenZWave (beta)” in the integrations list, and requires ozwdaemon (OpenZWave in the supervisor addon store) and MQTT to be running. The new component currently has limited platform support. Currently limited to binary_sensor, sensor, switch, and basic dimming lights. Climate just got merged in and should be available in .111. Cover, RGB light, lock, and fan support is still in progress as well.
Thanks for the explanation! Actually I have an AEON Stick Gen5, two Range exender 6, and a pile of Sensative Strips Comfort for lux measurement. I had it working with a Vera controller, I built some automations around it to control KNX-based rollershutters. It worked fine, but some time ago the Vera controller started acting very strange, at the and now it looks it’s brick. Now I want to move to the AEON USB stick. The regular zwave integration recognised my AEON Stick and also the range extenders, but I have difficulties adding the sensative strips. I’m just wondering if I should do it with the regular setup or move to the new beta? Please advise!
When the new z wave replaces the old system is it still going to require mqtt?
Seems like an additional component to fail will it be integrated directly into HA when it’s released?
1 reply
Yes it will require MQTT. The whole thing is built around MQTT to decouple OpenZwave from HASS. Has two main benefits: 1) Zwave network stays up when HASS reboots and 2) faster/easier updates to OpenZwave (straight from developer).
Good to know. I’ve read a few comments which stated that light_transition isn’t available over MQTT. Looks like they were wrong or, more likely, I misread the details.
Migrating from Wink-land, using an HZUSB1 (/dev/ttyUSB0 for zwave).
Here are the steps I used based on a the documentation linked from the 0.110.0 release post… Hopefully it’s helpful to others:
Requires: Home Assistant Core 0.110.0+
Supervisor -> Add-on Store
Configuration -> Integrations
MQTT
Supervisor -> Add-on Store
Configuration -> Integrations
OpenZWave (beta)
Developer Tools -> Services
Configuration -> Devices
All done!
A couple of questions:
The big picture is not yet super clear for noobs like me approaching this.
EDIT: I just spent a couple of hours trying to get my WD500Z-1 Linear Zwave switch to pair with the OpenZwave beta, I wasn’t successful. I added the older Zwave integration and was able to find it and add it in the older UI in 30 seconds.
Based on the lack of UI with the beta, my advice is for new users to stay clear of this… It’s a bit closer to Alpha atm.
1 reply
Hi,
I have spent some nights trying to figure this out.
I want to run Mosquitto on a different server, not within HA addon.
I am unable to get Open Z-wave Deamon to start. Mosquitto is running (checked) MQTT integration is pointing to that IP.
When I start OZW deamon addon. I see: [ERROR] No Hass.io mqtt service found!
I tested with mosquitto addon, it starts fine then.
Is the Mosquitto addon obliged instead of selfhosted server? or is this a bug / still being worked on?
kind regards,
PS great work !!! much appreciated !
1 reply
Did you try adding the external mqtt to home assistant integrations before starting ozw?
@nickrout
If the question is directed at me. Answer: Yes I think so, if that means:
add integration: MQTT > enter IP, User/Login, discovery Yes
Restart, go to development > MQTT > Add # to listen to, and then I see mqtt messages.
Go to integration, install OZW deamon, press start. >> I see this message. “[ERROR] No Hass.io mqtt service found!”. The icon color chages from green to grey again, indicating it has stopped. I can press start again.
I also tried deleting the mqtt integration again, adding mqtt: to the config.
mqtt:
broker: 192.168.4.13
port: 1883
username: user
password: login
discovery: true <tried adding this one as a third attempt.
all with the same result. OZW daemon does not start with the error message mentioned.
I am wondering if this is intended behaviour.
If it is not, I am happy to create an issue in github, help with logs, test etc.
Just to add info. If I install mosquitto add-on, install mqtt integration, install ozw-daemon and start it, there is no error message. I starts, and I see node information comming through in mqtt as expected.
If I install Zwave2mqtt, the external mosquitto server is seen as expected.
To make sure I am not the issue here with leftover bitsnbobs, I created a second fresh VM of homeassistant and did the above steps.
It feels to me that something is preventing ozw-daemon to see the external mqtt server.
regards,
OK. I was typing from memory.
The string I entered was exactly the string currently in my configuration.yaml. I just copied and pasted it.
Question.
If I were to install Mosquitto add-on, instead of self hosted mosquitto. Would that in anyway result in mqtt topic to change when I am switching over from one broker to the other?
I suspect switching broker doesnt change it, but I would like to have it confirmed.
Again, thanks to all the devs and the work on zwave integration. A lot of hard work and dedication. You guys are awesome.
Regards
OK, I have the daemon installed and running, and the integration.
HA recognised my TKB switches OK, but only partially recognised the Danfoss radiator valves. It recognised the device and the battery state entity, but not the set points and other entities. Looking at log.json, there’s plenty of traffic about full discovery of the rads, so I’m guessing that there’s something missing in the addon.
Luckily, I don’t need the rads right now - I hope - so I’ll stick with it.
I’ll dig deeper and raise an issue where appropriate.
EDIT: I see from github that the climate elements were only added to the codebase a couple of days ago. I’ll leave well alone for now as I’m running 110 rather than dev code.
Hi, there seem to be 2 repos for this integration:
The custom component:
Can anyone explain the difference? I would like to use a cover node but that is not included in the “core” version but it seems to be included in the custom component. Does it make sense to start an issue for the core version or will it be included in a next Home Assistant Core version?
1 reply
Can I run the OpenZwave daemon on a Raspberry Pi Zero and will a USB Zwave stick work with one?
So the HACS version, is the pre-release for early testers. This integration has been renamed to OpenZWave (beta) as it moved from the pre-release HACS repo to the official Home Assistant Core repo. It is the same integration. – It was renamed to avoid confusion with the existing zwave2mqtt project
There is no need to file a bug, the devs are already working to bring the remaining platforms from pre-release to beta. We should see more supported platform in HA 0.111 - You can use the HACS pre-release while we’re waiting.
Also if your handy with mqtt, it is possible to use most devices already even though they are not available in OpenZWave (beta)
1 reply
After few hours on this i’m unable to make it work. I have only fibaro fgd212 in my zwave network. I see that everything looks good from the ozw add-on but I can’t see any message on my mqtt so I think this is my issue. I did not found the reason for now…
Edit: seems that openzwave addon runs it’s own mosquitto. would it conflict with my mqtt that is already running with the official addon for zigbee2mqtt ?
1 reply
Yes, I recognise that.
I cant get the deamon to connect to my own mosquitto instance. It needs to be the mosquitto addon to connect to. Tried everything. I have asked about this above, but I got no reply, so I assumed I was the only one being stupid enough not to understand it. Or maybe this is the wrong topic as its the openzwave topic, not the daemon topic, I dont know.
No the topic is set by ozwdaemon it will not change if switch MQTT brokers -
You can check OpenZWave/# using mqtt explorer or even Home Assistant > developer tool > MQTT
Not everyone reads all the post, it’s easy for something to get lost in the shuffle or overlooked. I can’t tell you the number of times I’ve seen someone ask a question that was literally answered only one or two posts above their own ( I’m not saying you did that, just the point, it’s not people ignoring you, but could be people just aren’t reading your questions. ) Consider creating your own thread to ask for help or joining the discord server – Sometimes it quicker to get a reply, sometimes people may be able help in real time. No need to feel down on yourself – Everybody has to start somewhere
@RogTP pretty much said it here
So in total there are three parts to using this.
1 - ozwdaemon – This is either an add-on or it could be in a docker container ( Even a "bare-metal install but there are no instructions for this yet ). Just needs to running somewhere on your network ( I used a RPI to make dedicated device for ozwdaemon )
2 - A mqtt broker ( I use mosquitto ) running somewhere – This could be an add-on, a docker container, a “bare-metal” install or even in the 
cloud – ( I use a “bare-metal” install running from a jail on my FreeNAS server )
3 - Open ZWave (beta) - This is the new Z-Wave integration for Home Assistant – Install from the integrations page in Home Assistant – Also note, this is the same component as the HACS pre-release. The name has been changed as it moved from pre-release to beta. This name change was to aviod confusion with the unrelated zwave2mqtt project.
Hopefully something above could provide you with a clue to move forward. I’m sorry I can’t really help with anything specific to configuring an “addon” because I’m running Home Assistant Core from a virtualenv – I have never used an “addon” before
1 reply
So I’m maybe wrong but that means you can’t run ozw and a mqtt broker for other any application that needs it ? Like zigbee2mqtt.
Thanks for the explanation. I have it running now, including my Fibaro FGRM-222 roller shutter. Cover component is configured like this:
- platform: "mqtt"
name: "level_mqtt_ozw"
command_topic: "OpenZWave/1/command/setvalue/"
set_position_topic: "OpenZWave/1/command/setvalue/"
set_position_template: "{ \"Value\": {{ position }}, \"ValueIDKey\": xxxxx }"
position_topic: "OpenZWave/1/node/24/instance/1/commandclass/38/value/xxxxx/"
value_template: "{{ value_json.Value }}"
position_open: 99
position_closed: 0
payload_open: "{ \"Value\": 99, \"ValueIDKey\": xxxxx }"
payload_close: "{ \"Value\": 0, \"ValueIDKey\": xxxxx }"
The one thing not working is the stop functionality. But I am not really using that.
And while looking at the payload_open/payload_close I may need to check that again. It may be swapped.
It was not working. Now it does work. The QT-Openzwave endpoint does not accept a value of 100, only 99 as a value for open (up).