[ANNOUNCE] node-red-contrib-zwave-js V8 Baby!

Here it is...... V8 of node-red-contrib-zwave-js

After

  • 3+ Months
  • 120 Commits
  • 14 changed files
  • Various UI design discussions

i present the below change log

Breaking

  • Dropped support for Node 12 (min required is now 14.13.0)
  • If you use the set method of the Configuration CC in CCAPI mode, the arguments must now have one object (see Github CL)
  • ValueAPI is now default on the CMD Factory node. If you have problems with this node after the update, please open it up, and select your API, then save.

New Features

  • Default scales can now be applied inside the controller config
  • Added ability to export/import node name & location maps
  • Implemented a Firmware Update Service, that allows to install Firmware on devices that have known updates - Please double click controller!
  • 2 new event types have been added : ALIVE, DEAD - these allow you to monitor if a device has been marked dead or alive accordingly.
  • Added a color chooser for color input types in the UI
  • Added a new Driver function getLastEvents
  • Device last seen timestamp is now shown in the UI
  • Node list now contains the date when the device was last seen.

Bug Fixes

  • Modal alerts are now rendering HTML content once again
  • Missing normalizedObject.label for Thermostat devices
  • Fix some data type odities in the UI editor
  • msg properties are now carried through the CMD Factory node

Changes

  • Current Value(s) who's type is an object have been changed to prompt for a double click in the UI
  • Association Management has been updated, and changes are now applied in batch.
  • For battery operated devices, certain UI actions now ask you to wake up said device before anything is comit
  • Various performance boosts in the UI
  • Bump ZWave JS to V10
  • Bump Winston
  • Bump ESlint

Sorry for the delay in updates - but never the less enjoy!

4 Likes

Thanks a lot for all the support and maintenance.

I am running into some issues, maybe you are familiar with this use case, but I am running node-red in a LXC container (using proxmox) and am passing through my zwave usb device to the container, when the controller tries to initialize, i get the following error:

ZWaveError: Failed to open the serial port: Error: Inappropriate ioctl for device setting custom baud rate of 115200 (ZW0100)

Is this something i can set/configure or should it actually be 115200 ?

Hi @bakman2
I can't say I have ever seen this.

115200 is pretty standard for a z-wave serial module.

The driver (zwave-js) will set the following when connecting :

  • baudrate: 115200
  • data bits: 8
  • parity: none
  • stop bits: 1

Maybe check if the LXC container is setting stuff (when it should be left to zwave-js)
Sadly I know nothing about container based setups.

I did find this that also refers to LXC (but for Zigbee)

Ignore me, i used wrong device file/permissions, controller started now. Thanks for the quick response!

1 Like

Hi Marcus,

any known problems when updating from V7 to V8?

regards
Hannes

No problems I know of :wink: - but some potential breaking changes, extremely minor however.

See the breaking changes section.

Hi Marcus,
version 8 runs perfectly :+1:

One other question. I have upgraded my Z-Pi 7 controller to 7.18.1.
It works ok but instead of 2 green leds i now have one green and one red. I send a message to aeotec support and received this:
One of the LEDs typically indicates the z-wave frequency of the Z-Pi 7, if you are having issues with controlling your devices, then try changing the Z-Pi 7 Z-Wave Frequency which can be done in Z-WaveJS UI
I checked your UI and I have power level 9.5 and Measured 0dbm 0.
What would you do in this case? Run with the red led?
Appreciate your input on this matter,
Johannes

Hi @juntiedt - Glad V8 is up and running for you.

I wouldn't change the power levels unless there is a very specific reason for doing so.
sometimes you get worst performance and increased noise on the network.

The LED's might indicate the region frequency (which can also be set) - but it needs to be supported by the radio its self.

My advice would be - if you see no issues, I would leave as is - if you find you do need to increase it - Aeotec are more equipped to offer the optimum levels guidance (i'm still using Gen 5 Sticks :sweat_smile: )

ok, thanks.

@marcus-j-davies What is the use case for the normalizedObject ? I mean i can see a use case (ie, dumping it into a db), but in that case it missed the nodeId and nodeName, could those be added (if that is the purpose) ?

Hi @bakman2

normalizedObject is an attempt to simplify the payloads, so it’s easier to understand what just happened.

The module does not interfere with what is being received, I.e the object is not being modified since leaving the driver.

As this contains quite a lot of data - the object you are referring to is a slimmed down / to the point alternative that’s aims to be uniform.

V9 is in the works, that could change a lot of this (it’s a typescript refactor), but that won’t drop until next year.

@marcus-j-davies

Another question, I am struggling with the "ValueAPI" "CCAPI" concepts, I want to set some undocumented value by manufacturer, I see in the home assistant forums that folks managed to do it, but i have no idea how to translate this in NR.

  command_class: "49"
  method_name: sendReport
  parameters:
    - 1
    - 0
    - 20.00
  endpoint: "0"
....

3105014207d1
31 -> Command Class 49 (hex 31)
  05 -> Command SENSOR_MULTILEVEL_REPORT
    01 -> Sensor Type == 1 == Air Temperature
      42 -> 0b1000010 -> Precision = 2, Scale = 0, Size = 2 bytes
        07d1 -> Temp value 20 (hex 14) 2001, which is 20.01 with precision 2

Source info

Which node(s) do i need to use for this ? the cmd factory ? or just the device node and what should the message look like ?

Hi @bakman2 try this.

let Message = {
    payload: {
        mode: "CCAPI",
        node: 2,
        cc: 49,
        method: "sendReport",
        params: [1,0,20.00]
    }
}
return Message

Thanks, i received an error, might be related to the device itself

ZWaveError: Invalid CC Multilevel Sensor! (ZW0300)

Here:
params: [1,0,20.00]

is the following.

  • sensorType = 1 (Temp)
  • scale = 0 (Celsius (°C))
  • value = 20.00

Send it to the controller and ensure node is correct (and the device is awake :sweat_smile:)
The CCAPI is an untethered API i.e your on your own, where as the ValueAPI has all sorts of magic to ensure local data caches are in sync

See here.

Ok thanks and to which node do i send this, controller, command, device?

Send this to the controller node or a device node. If using device node and your device node is enabled for multiple devices, ensure you include node else it will target the node that is addressed in the config on the device node

This message can be created using CMD Factory also.
The CMD Factory node just creates ready to use messages.

/* 0x01 - Temperature */ 
/* 0x00 - Celsius */
let Message = {
    payload: {
        mode: "CCAPI",
        node: 2,                     /* The node ID it should target */
        cc: 0x31,                    /* Multi Level Sensor */
        method: "sendReport",        /* Function on this CC */
        params: [0x01,0x00,20.00]    /* Function params -> Sensor Type, Scale, Value*/
    }
}
return Message

I receive the same error, I will search a bit further how this thing can be set.

I think I got it working by using:

const temperature = RED.util.cloneMessage(global.get("state.netatmo_temperature"))
const temperature_formatted = Number(temperature.toFixed(1) + "1");
node.warn(temperature_formatted)

const nodes = [2,3]

nodes.forEach(n=>{
    let payload = {
        mode: "CCAPI",
        node: n,
        cc: "Multilevel Sensor",
        method: "sendReport",
        params: [1, 0, temperature_formatted]
    }
    node.send({payload})

})

If you did not receive any error - it likely would have.
if you enable Driver logging (at least debug level) and paste the output, I can confirm.