Thanks for the link and details. I will have to spare couple hours this weekend!
I still stumble on that too. When I see Z my brain thinks Z-Wave but ZHA is Zigbee!
I’m running HA in docker so I cannot comment on that bit but it looks like a normal USB port to the server so anything running on the host should see it as such. Like I said it shows up under /dev/tty like any other thing.
Been there, tried it before (not with Z-WaveJS) and no, there are calls that code can make that even USBIP cannot emulate the real hardware. OZW being one example… Either that or I did something wrong before, but I’ll try it again…
I said it’s like the zwave integration. I didn’t say it was the zwave integration…
Apologies! I guess we both misread that the same way…
I do still have to stop and think though when I see ZHA…it’s zigbee; and vice-versa when I want to refer to zigbee, it’s z h a. shoulda been ZBHA!
No offense taken, just had to set the record straight. Reputations are at stake here! 
Anyone with zwave rgb light? Do you all have color picker?
Yes, a Fibaro RGBW 441 and a Fibaro RGBW 442. Both were showing the color wheel in Lovelace using the OZW integration. Having switched to ZWave JS, both have lost the color wheel. Others are seeing the same:
1 Like
this comes close to what I have, 2 separate systems, and the 1 dedicated to zwaveJS. I thought to be forced now to have both add-on and integration on the dedicated instance (and now am communicating over MQTT between the 2 systems.)
It would indeed be way preferable if we could connect over ws:// at all as you suggest above.
ws://[ip-of-pi]:3000
isnt accepted unfortunately… But what a great idea! it would make a lot of extra code and confirmation unnecessary, yet maintain the separation of hardware, with all advantages that has.
Just like we can now do with the MQTT add-on (have it setup on 1) and integration(set up on 3 instances subscribing to the 1 add-on) where this exact architecture is base material. Nothing advanced about it 
Here’s the documentation for zwavejs2mqtt
https://zwave-js.github.io/zwavejs2mqtt/#/
Here is a quick guide to setup a docker container with zwavejs2mqtt
https://zwave-js.github.io/zwavejs2mqtt/#/getting-started/quick-start
Here’s a forum post with a person posting the docker compose (which makes docker easier)
Lastly, here’s how to install it without docker:
https://zwave-js.github.io/zwavejs2mqtt/#/getting-started/quick-start?id=nodejs-or-pkg-version
The last option requires npm, you don’t need to know anything about it. Just look up how to install npm. npm just manages packages, i.e. makes it easier for you to install things that don’t have installers.
2 Likes
Yeah, I’m also looking forward to support for NGD00Z-4 to be added. I can control it from the zwave control panel on port 8091, just does not show up as a cover yet in HA. I suspect it will be pretty soon. Very impressed with the integration so far.
1 Like
Trying to figure out how to re-write my scene automations for double clicking the HS-WD100+ dimmers - tried the examples above but not working:
Event Output
{
"event_type": "zwave_js_event",
"data": {
"type": "value_notification",
"domain": "zwave_js",
"node_id": 31,
"home_id": 4169402847,
"endpoint": null,
"device_id": "33d2a05738c6a33756151c6faca2b2bf",
"command_class": 91,
"command_class_name": "Central Scene",
"label": "Scene 002",
"property_name": "scene",
"property_key_name": "002",
"value": "KeyPressed2x"
},
"origin": "LOCAL",
"time_fired": "2021-02-12T14:43:55.236607+00:00",
"context": {
"id": "24ccf0670fb120169b38a727472be140",
"parent_id": null,
"user_id": null
}
}
Automation Test
- alias: Double Click Dimmer Automation
trigger:
- platform: event
event_type: zwave_js_event
event_data:
node_id: 31
property_name: scene
property_key_name: 002
Any help greatly appreciated!
I have just a general question. I’m not an expert on how HA, Z-Wave JS Websockets, etc work in the background, but I generally understand what’s going on in the foreground. Here is my question.
If I can control a device in the Z-WaveJS Dashboard on port 8091, does that mean it’s supported in Home Assistant as well? In this case I’m asking about my Garage Door opener. I can open and close it via the dashboard, it shows up as a zwave device in HA, but not the cover component.
I’ve seen in the wiki that covers, specifically garage door covers are not yet supported, and it’s a WIP in progress, but I’ve also seen a few comments from people talking about garage door openers working. At least that’s what it seems like. And Since I can control it from the Z-WaveJS dashboard, it makes me wonder. It is supported now or what. 
BTW, I’ve only played around with this for a couple of hours yesterday and using the guide from @petro I was able to migrate from OWZ and rename 44 devices, and 130 entities in less than an hour. Great work everyone working on this. Very smooth
Well, it depends on the garage door type. My garage door opener is a 2 separate zwave devices that are not ‘barrier devices’. What’s being added is ‘Barrier devices’. Yours is most likely that. I think that’s coming rather soon.
the only thing available on 8091 is the dashboard. You can’t send commands to that port.
It means the device is capable of being supported in HA, not necessarily that it’s supported now. Depending on the functionality and device properties, HA might need to add new implementation (like covers).
Can you post a network dump from HA and post it on a pastebin so I can see the garage opener node?
I will definitely do that (after I read up on how to do that, haha).
but in the mean time this is what I meant by control from the dashboard, which did open and close my garage door. I’ve seen other mention my same garage door opener, so I’m not suprised it’s not quite working yet, not trying to rush at all, just trying to understand. in OZW I could look through all the configuration files for GE, schalge,etc (100’s of them) to kinda see what was supported, etc. Just not sure if there was a similiar set of files with this.
zwavejs2mqtt is basically showing you the “raw” values that are provided by zwave-js. HA uses those same values to implement the associated entities. The code necessary to wrap the barrier values as a cover and implement the set/get behavior, along with the discovery code (i.e. is this node and its values a barrier device?), needs to be implemented in HA (in progress).
Here are instructions on getting a dump. If you post the dump I can make sure your GDC is supported in HA.
2 Likes
I am struggling with configuration.yaml file. I did edit the file to change the entity name for original alarm type/level sensor without changing anything else. I did put it end under sensor: any recommendation?