I guess what should really be added in a nice graphical way is that the MQTT broker also handles other Mqtt events, than only those events coming from and going to the ZwaveJS Add-on. It is after all the main distinction between this 2 architectures, and does make the world of difference.
Like this stuff?
Maybe depending on your use case.
But in this discussion it only would tend to confuse things even further.
I’m not sure I really know the nuts and bolts of things deep in the code but they should be very similar if not the same.
The only difference between the various incarnations is the way that they communicate with HA.
And that the zwavejs2mqtt incarnation has a UI control panel while the others don’t.
I don’t think they will add it into the add-on. it will make more sense to add it into the zwave js integration itself.
Yes, sorry, I’m still using HASSOS as shorthand. I’ll stop to avoid confusion. I’m talking about the basic Home Assistant OS installation on a Pi.
Where did you get this list of requirements? I’m pretty sure you can’t run NodeJS and therefore #1 on a Home Assistant OS Supervised installation, can you? We don’t have that access to the system. Similarly with #2, since that is what the new Zwave JS Add-on is for, the wrapper for the zwavejs server (which is included in #3). We can, however run #3 as an Add-on, and of course, #4 and #5 are specific for our basic installation. But to run #5, we need either #4 or #3. Hopefully someone can confirm/correct.
I can install #1…
…but I’m sure I don’t want to!
No, the new Z-Wave JS is not a wrapper for OpenZWave (Beta) 1.6.
I was running that until a couple of days ago.
The absolute core for both might be the generic OpenZWave project but OpenZWave (Beta) was basically a pull from Justin’s QT-OpenZwave.
Ah, OK, that expains it. You’re 1,2,3,4,5 are different than my 1,2,3,4,5. I was referring to the 5 different elements of ZWave JS described by @JumpMaster to which I was replying. I think you took those to mean the five things listed in Petro’s post. We are talking two different things. 
Ah! Apples vs Oranges! Native Indian vs Asian Indian. Male brain vs Female brain…
We need to use the same dictionary!
So, I am using @JumpMaster’s #4. Home-Assistant Z-WaveJS Addon & #5. Home-Assistant Z-WaveJS Integration
1 Like
What do you mean? Like this?
Yep, exactly like that! Cool! 
I don’t have a need for it but I’ve seen others talking about using zwave like that many times in the past.
I guess I shouldn’t have made an assumption that you could only have one instance like most of the other stuff only allows.
So, I three anomalies with my blinds…
- For one of the 6 nodes, battery entity is available and status is reported but the item is not showing in the Devices listing page, which may just be an HA UI anomaly…
- Two blinds have no multilevel switch entities…
15:52:43.132 CNTRLR starting inclusion process...
15:52:43.157 CNTRLR handling add node request (status = Ready)
15:52:43.158 CNTRLR the controller is now ready to add nodes
15:52:57.158 CNTRLR handling add node request (status = NodeFound)
15:52:57.163 CNTRLR handling add node request (status = AddingSlave)
15:52:57.168 CNTRLR handling add node request (status = ProtocolDone)
15:52:57.168 CNTRLR stopping inclusion process...
15:52:57.230 CNTRLR handling add node request (status = Done)
15:52:57.231 CNTRLR done called for 30
15:52:57.231 CNTRLR finished adding node 30:
basic device class: Routing Slave
generic device class: Multilevel Switch
specific device class: Unused
supported CCs:
· Basic (0x20)
· Multilevel Switch (0x26)
· Z-Wave Plus Info (0x5e)
· Association (0x85)
· Association Group Information (0x59)
· Version (0x86)
· Manufacturer Specific (0x72)
· Device Reset Locally (0x5a)
· Powerlevel (0x73)
· Binary Switch (0x25)
· Battery (0x80)
· Configuration (0x70)
controlled CCs:
15:52:57.231 CNTRLR » [Node 030] Assigning return route to controller...
15:52:57.238 CNTRLR the inclusion process was stopped
15:52:57.741 CNTRLR [Node 030] Configuring Z-Wave+ Lifeline association...
15:52:57.824 CNTRLR [Node 030] Beginning interview - last completed stage: None
15:52:57.825 CNTRLR [Node 030] new node, doing a full interview...
15:52:57.825 CNTRLR » [Node 030] querying protocol info...
15:52:57.839 CNTRLR « [Node 030] received response for protocol info:
basic device class: Routing Slave
generic device class: Multilevel Switch
specific device class: Unused
is a listening device: false
is frequent listening: true
is a routing device: true
is a secure device: unknown
is a beaming device: true
maximum baud rate: 40000 kbps
version: 4
15:52:57.847 CNTRLR [Node 030] Interview stage completed: ProtocolInfo
15:52:57.847 CNTRLR » [Node 030] pinging the node...
15:52:57.915 CNTRLR « [Node 030] ping successful
15:52:57.915 CNTRLR » [Node 030] querying node info...
15:52:58.079 CNTRLR « [Node 030] node info received
supported CCs:
· Z-Wave Plus Info
· Association
· Association Group Information
· Version
· Manufacturer Specific
· Device Reset Locally
· Powerlevel
· Multilevel Switch
· Binary Switch
· Battery
· Configuration
controlled CCs:
15:52:58.087 CNTRLR [Node 030] Interview stage completed: NodeInfo
15:52:58.089 CNTRLR [Node 030] ManufacturerSpecificCC: doing a partial interview...
15:52:58.090 CNTRLR [Node 030] VersionCC: doing a partial interview...
15:52:58.090 CNTRLR [Node 030] trying to load device config
15:52:58.095 CNTRLR [Node 030] device config loaded
15:52:58.095 CNTRLR [Node 030] ZWavePlusCC: doing a partial interview...
15:52:58.096 CNTRLR [Node 030] BatteryCC: doing a partial interview...
15:52:58.097 CNTRLR » [Node 030] querying battery status...
15:52:58.364 CNTRLR « [Node 030] received response for battery information:
level: 100
15:52:58.365 CNTRLR [Node 030] MultilevelSwitchCC: doing a partial interview...
15:52:58.366 CNTRLR » [Node 030] requesting current switch state...
15:52:58.617 CNTRLR [Node 030] BinarySwitchCC: doing a partial interview...
15:52:58.618 CNTRLR » [Node 030] querying Binary Switch state...
15:52:58.866 CNTRLR « [Node 030] received Binary Switch state:
current value: true
15:52:58.866 CNTRLR [Node 030] ConfigurationCC: Loading configuration parameters from device confi
g
15:52:58.868 CNTRLR » [Node 030] querying parameter #1 value...
15:52:59.072 CNTRLR « [Node 030] parameter #1 has value: 1
15:52:59.073 CNTRLR [Node 030] AssociationCC: doing a partial interview...
15:52:59.074 CNTRLR » [Node 030] querying association group #1...
15:52:59.282 CNTRLR « [Node 030] received information for association group #1:
maximum # of nodes: 1
currently assigned nodes: 1
15:52:59.284 CNTRLR [Node 030] AssociationGroupInfoCC: doing a partial interview...
15:52:59.284 CNTRLR [Node 030] Interview stage completed: CommandClasses
15:52:59.285 CNTRLR [Node 030] Interview stage completed: OverwriteConfig
15:52:59.285 CNTRLR » [Node 030] requesting node neighbors...
15:52:59.300 CNTRLR « [Node 030] node neighbors received: 1, 3, 8, 9, 12, 21, 22, 23, 26, 27
15:52:59.300 CNTRLR [Node 030] Interview stage completed: Neighbors
15:52:59.301 CNTRLR [Node 030] Interview completed
15:52:59.301 CNTRLR [Node 030] The node is ready to be used
Client disconnected
Code 1000:
New client
Not that it matters, but OZW Beta allows it too. Very useful for testing.
1 Like
I’ve tried excluding/including one of the stubborn nodes but end up with the same result. I’ve restarted the ZWJS server, the integration, HA and the entire box…
Any suggestions?
To resolve my issue I ended up just rolling back to a full snapshot I had before I installed zwave JS. Everything works with the legacy integration as soon as I restarted.
So it’s definitely some issue with the ZJs integration and how that’s working to pickup devices. Maybe I had bad luck the first time around?
I’ll retry adding ZJS again and see what happens.
I had to repair both of my 910’s a few times to get things working. One I full on factory reset. I’m now happy to say both my locks change respond to service calls. Only thing I see is that the state doesn’t update.
I have a problem with my fibaro rollershutter 3:
I use the homekit integration to controll the rollershutter with siri. With the old openzwave-beta integration all 3 rollershutter start at the same time to open / close when i say it to siri.
With the new integration (zwafejs2mqtt community add-on) one of 3 startet instantly, the second maybe 3 or 5 seconds later and the third 5-10 seconds after the second one….
Always in a different order, so its not spezific a problem from one device.
I saw over at the Z-wave JS github that the lock state is a known issue on that end. I’ll be darn if I can find it again, but I’m patiently waiting for this too.
My Kwikset locks, an 888 and a 910 aren’t responding to service calls (but work in the Z-wave JS Control Panel). Do you have any hints for me to get that going like you did? Did you do a repair in the Control Panel or a full exclude and include again?
Yeah i saw that issue too. It looks like they are on it.
I have two zwave 910’s (not plus) and they are kind of far from my controller, so they need to hop through a nearby mains powered node to mesh up. They have always been spotty at best, with like 1 in 8 messages failing. They were also just super slow to respond when they did (sometimes up to 10 seconds after the service call went out).
I tried OpenZWave and they did not work at all. I had been ebay hunting for two zigbee modules for the past two months when ZWaveJS popped up.
I started with the ZWaveJS addon, but really wanted to be able to see the mesh to better understand how the locks were routing. I uninstalled that and installed the ZWaveJStoMQTT addon, set it up to act as a controller and ZWaveJS server only (I’m using the websockets integration), and then removed my two lock nodes.
I brought each of them over to the controller and added them back in secure mode one by one, through the addon interface. I gave them plenty of time near the controller to complete the interview process and then reinstalled them. I then healed the network with them in place.
The locks are now waaaaaaaaay more responsive. Still slow, but not as slow as before. I click unlock now and in two seconds the lock unlocks. It’s so awesome. These were my most troublesome devices in the house.
1 Like