Hi!
I have the “beta version” op and running.
As of today - i can see the Aeotec Siren 6 - all the sensors.
I am however - still not able to make it “ring” from inside HA - and it’s not “fully” detected as an aeotech device yet.
But progress 
br Ronni
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.
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.
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.
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.
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 
Great! Sounds like the way to go instead of the MQTT way mentioned in this thread. Much closer to the source
Awesome. I just need some help from someone with experience with Home Assistant development since I have no experience there.
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.
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
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.
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.