[UPDATE] node-red-contrib-zwave-js 6.3.0

[marcus-j-davies]

I often get asked, 'What is the command being sent, when I manipulate my devices from the UI'
until now, the answer has been 'It uses the ValueAPI'.

6.3.0 Adds a new UI Monitor, that allows you to see how a command was executed.
This command can then be used in your flows, allowing you to manipulate the command as you see fit.

The idea, is to simply copy/paste.

Change Log:

Fixes

• Fixed duplicated event handlers, after a new interview.

New Features

• Lock User Codes can now be optionally interviewed.
  Note: This will cause an increase in traffic - especially if your lock has many codes to query.
• Opt-in to Soft Reset USB device.
  This is needed for certain commands, like changing the RF.
• A new "UI Monitor", allowing you to capture/use the commands that are sent to the controller

Changes

• Changes to package content to reduce size (~9.0MB -> ~1.3MB)
• The node list is now sorted by Node ID
• Bump ZWJS to 8.5.1

node-red-contrib-zwave-js

Enjoy

[JGKK]

Just wanted to say thank you for the amazing work on this node and zwave-js in general.
Its been the most user friendly and robust z-wave solution ive used so far and allowed me to drop openhab completely which at this point i was only using for its z-wave binding.
Keep up the great work

Best regards Johannes

[marcus-j-davies]

You are very welcome Johannes. Many thanks for the kind words.
Though I can't take credit for the backend javascript z-wave driver it uses.

[bakman2]

@marcus-j-davies

Adds a new UI Monitor , that allows you to see how a command was executed.

Nice work, but where does the UI monitor window come from ? From the screenshot I cannot determine how this shows up.

edit; ok found it. Wouldnt it be easier for users to add an little icon or "example" link that generates an example config when clicked ? Now it requires a config change first.

[marcus-j-davies]

Hi @bakman2,

indeed that is possible - almost a Dummy Command button, that creates the command, but doesn't commit to the controller.

I will look at that in the future

[alex88]

Hey @JGKK

A friend mentioned to me node-red-contrib-zwave-js (node) - Node-RED
I hadn't realised that zwave-js had been ported into NR... wow!!!
How the world moves on.

Reading your post, I can only think, how fortuitous for me to come across this thread.

I've been mulling over HASS vs openHAB for some time now and finally installed openHAB to start playing around with it a few weeks ago. FYI, I'm in the process of migrating away from Fibaro.

The main reason I want controller software (read: openHAB) is:

1. as a zwave antenna - first and foremost
2. definitely for device state history
3. definitely for detailed device trigger information
4. to structure my system into rooms/devices - but could do this in NR
5. Maybe to infrequently use the mobile app

All of my main HA is in Node-RED or is being ported into NR, as so I now need to play around with NR zwave-JS contrib and see what it can/can't do, but it looks mighty promising, as it stands.

A question to anyone: Can you tell me if/how you implemented item 2-3 above without separate controller software to do it for you?

I'm getting a good feeling I'm going to be running 100% NR for my automation soon

Then the big question... has anyone installed more than 1x zwave stick per NR instance, is it possible?
This is important to me as I need to setup 4x devices (3x Pis and a Debian PC) with 2x zwave sticks on each, to adequately split my network.

I would like to end up with 1x master that combines the other 7 sticks into a single view of the 8 sticks combined, but this were I am concerned if the NR contrib will work??

At the end of the day I somehow need all 8 sticks (across the 4x devices) to roll-up into 1x NR instance. I think that's the more important question.

It could be possible that if there is a way to run 8x sticks on 1x device (my debian PC) and connect them reliably via Rj45, using USB adaptors, that his would be an option, but I'm less confident that this will work, or at least, that this would be reliable.

No need for responses on the wisdom of running 8x zwave sticks in one solution. I've been playing with zwave for almost a decade now and (think I) know what I'm doing / what I need to do to get over 200 physical zwave devices to sing.

@marcus-j-davies as I read up more, I am tending to think the question above might be directed to you, especially the one about multiple sticks ultimately feeding into one 1x NR instance.

PS: Apologies if this is the wrong place to post. I'll move to a new thread if required....

[marcus-j-davies]

Hi @alex88,

I'll try and answer as best as I can.

Point 2:
The Module in NR (or more accuretly ZWave JS) has an internal/persistent state engine, so you can query the current status of your devices without the devices needing to be a wake.

See
https://github.com/zwave-js/node-red-contrib-zwave-js/wiki/Value-API#getvalue
And
https://github.com/zwave-js/node-red-contrib-zwave-js/wiki/Driver-API#getvaluedb

This state is also recovered at start up, so values will be available to read, after a restart.

If you need to store the historical device events - you could write them to file (JSON) and query it as you see fit - there are endless modules to help with data storage (SQLite being one)

Point 3:
Whenever a device sends an update, you are provided with events of various shape (CC dependant)
These event are quite detailed (Time/Date, endpoint, cc, property, etc etc)

See
https://github.com/zwave-js/node-red-contrib-zwave-js/wiki/Payload-Messaging-Format#incoming-messages-messages-from-z-wave-into-node-red
And
https://github.com/zwave-js/node-red-contrib-zwave-js/wiki/Payload-Messaging-Format#event-table

especially the one about multiple sticks ultimately feeding into one 1x NR instance.

This is where it will get hairy - the module is designed to have 1 controller node and many device nodes per NR, so you will get trouble having 1 NR instance running 2 sticks

There is a custom UI panel with this module that will communitcate with the controller node that you deploy.

The controller node acts like a singleton, where the UI and individual device nodes will communicate with the mother ship so to speak in your flows.

see
https://github.com/zwave-js/node-red-contrib-zwave-js/wiki/node-types#zwave-js

You can do it - but you need an NR instance per stick - using a common transport between the 2.

node-red-contrib-aedes comes to mind

4x Machines (each with 2 instances of NR) - you can then allocate one of your machines/NR instance as the main MQTT broker - allowing your NR instances to communicate.

My entire home automation is done in NR - I have never used OpenHAB/HASS

PS: Apologies if this is the wrong place to post. I'll move to a new thread if required....

If you you go deeper into exploring the module - it will be easier to spark up a discussion here. ↓

zwave-js/node-red-contrib-zwave-js · Discussions

[alex88]

@marcus-j-davies

My entire home automation is done in NR - I have never used OpenHAB/HAS

@marcus-j-davies
Thanks for the prompt response.

What I've understood from your responses to my points from above:
Point 2. I need to build my own state history - which of course is doable, just adds another layer to deal with querying it as well

Point 3. I will read further, but from a first scan I can't see the source of the trigger anywhere. I appreciate I wasn't clear in my OP, but it is the "exact" source of the trigger that I'm interested in e.g. did it come from a wall switch, a scheduled task. I'm starting to think that for me to get this I will also need to build it myself in NR as everything is going to be in NR
4. On the rooms front, I guess I just build a simple JSON mapping - it's not an issue, but the question still to you, is how do you manage this in your solution?
I currently use node-red-contrib-fibaro-devices and have it setup so that each message comes through and is sent back to the Fibaro controller in the format of "room/device name", this allows duplicate device names across rooms. How have you managed your own setup?

The big one
For the zwave part, that's the bit that interests me the most. I already use node-red-contrib-aedes to pick up messages from air quality sensors, so it's not a stretch to have it installed for my zwave setup.
I'll have to wrap my head around installing NR 8x and then feeding the 7 into one master NR install.
Will need to think about how to manage the data flow and recognition of the source it came from etc etc.

Thank you again for getting back to me.

Lots of food for thought, but the lesson I'm getting is that the cost of moving to NR 100% is that you have to build everything in NR. I know, it's sound dumb when you say it like that, but there are things we take for granted with controller software and those things need to be considered.

[marcus-j-davies]

Hi @alex88.

On point 3, you can tag your zwave nodes with a name and location.

This name and location is also inside the events that gets triggered if say, a sensor has been tripped.
example of my motion sensor being tripped.

As for updating/controlling devices where you have : room/device as a path to a device
ZWave JS simply uses the node ID.

example: if I wanted to turn on a switch where I know Its id is 2

The CCAPI is not best API here - but its just an example.

let Message = {
    payload: {
        mode: "CCAPI",
        node: 2,
        cc: "Binary Switch",
        endpoint: 2,
        method: "set",
        params: [true]
    }
}
return Message

You can recreate the room/device approach by mapping IDs to JSON paths maybe?
where the JSON map is in your global context

let Message = {
    payload: {
        mode: "CCAPI",
        node: global.get("Nodes").Kitchen.MainLight,
        cc: "Binary Switch",
        endpoint: 2,
        method: "set",
        params: [true]
    }
}
return Message

where : global.get("Nodes") is

{
  Kitchen: {
    MainLight: 2,
    IslandLight: 3
  },
  FamilyRoom: {
    TV: 6,
    Projector: 4
  }
}

with this module, there is a filter node - this allows to split events to different paths - used right, its quite a potent mix when used with device nodes - device nodes allows you to group 1 or many devices to a single node in your flow.

The way I have it setup.

I have a tab (or flow per room).
and in each flow I group various blocks of logic.