[Help]: How to use ? ValueID

[bakman2]

The wiki describes:

Get the list of ValueIDs for a Node

let Message = {
    payload: {
        mode: "ValueAPI",
        node: 2,
        method: "getDefinedValueIDs",
    }
}
return Message

getValueMetadata

let Message = {
    payload: {
        mode: "ValueAPI",
        node: 2,
        method: "getValueMetadata",
        params: [<ValueID>]
    }
}
return Message

I send (preselected 1 specific node) :

{
        mode: "ValueAPI",
        method: "getDefinedValueIDs",
    }

I get 2 (duplicated) messages back with an array (?)

Lets say I need this part from the array:

{"commandClassName":"Thermostat Mode","commandClass":64,"endpoint":0,"property":"manufacturerData","propertyName":"manufacturerData"}

I want to get the getValueMetadata, so I send:

{
        mode: "ValueAPI",
        method: "getValueMetadata",
        params: [64]   
}

Result:

"ZWaveError: Invalid ValueID passed!"

What is the ValueID here, this is not clear to me.

Any more details?

If this is specific to some hardware or specific software version, please explain here.

Version

6.1.1

Node-RED Version

2.0.6

What hardware are you using?

Other Linux

Any code to add?

No response

[marcus-j-davies]

Hi @bakman2,

The ValueID must be passed as an object - not an index of the array.

So to get a value for a given ValueID.

let MyValueID = {
  "commandClassName": "Thermostat Mode",
  "commandClass": 64,
  "endpoint": 0,
  "property": "manufacturerData",
  "propertyName": "manufacturerData"
}

let Message = {
    payload: {
        mode: "ValueAPI",
        node: 2,
        method: "getValue",
        params: [MyValueID]
    }
}
return Message

getDefinedValueIDs
gives you the available ValueID's - but you must use them in there entirety (and not based on the index they appear)

[bakman2]

Ok thanks that works, that is not what I was expecting (I have never seen an "ID" been described as an object). Note I assumed that the commandclass was the valueid.

So how would I update a "ValueID" ? You pass in the same full object and as value the same full object with updated values ?
I am sorry for the silly questions, but the wiki is not clear to me with examples.

[marcus-j-davies]

Yeah, the backend driver refers to an ID - so I do agree its a little confusing.

so, to update a value using the ValueAPI

let MyValueID = {
   .......
}

let Message = {
    payload: {
        mode: "ValueAPI",
        node: 2,
        method: "setValue",
        params: [MyValueID, your-value]
    }
}
return Message

the CCAPI - is easier, if you want to start there, but by all means go with ValueAPI if you want.

[marcus-j-davies]

I am sorry for the silly questions, but the wiki is not clear to me with examples.

don't be sorry 👍

[bakman2]

I want the easiest path, I went in this completely blind, I need to migrate from another zwave node-red node.
So I wanted to "translate" my previous flow to this.

Tbh it is easier to look in the cache files than to retrieve the values via node-red.

Now i will look into the "CCAPI". Thanks again for the quick support.

[marcus-j-davies]

CCAPI - will require a device to be awake to retrieve data at that moment (or it will be retuned to you, when the device wakes up)

where-as the ValueAPI will use stored values (at least for returning data)
the stored values are updated - when your device send updates of course.

but there is no need for the device to be awake to fetch data if using ValueAPI

CCAPI is easier to use - but it does have draw backs (for battery devices) - at least if you want to fetch data, due to the wait that may occur

[marcus-j-davies]

@bakman2
I have moved this to a discussion - so holla if you need anything 👍

[bakman2]

Thanks.

Shouldn't one be able to build a single array of objects for the whole topology in the network with all their properties and values ? It boggles my mind why these specifics are split up in by metadata and values separately as they belong together. Then again I only have 2 zwave devices so don't mind my oversimplification.

I tried:

getDefinedValueIDs > split > for each getValueMetadata, but this ends up in an infinite loop with errors that not all ValueIDs cannot be found somewhere in between the messages, but I digress.

I think it could be more user friendly to provide additional nodes that do the translation mapping in the background with dynamically populated fields, something like:

where the commands are dynamically retrieved based on node selection
and the input payload input suggestion based on the command selection as a translation layer to generate the messages

It is all kind of convoluted in my eyes, especially when dealing with the valueAPI - i am using battery powered devices.

[marcus-j-davies]

Thanks.

Shouldn't one be able to build a single array of objects for the whole topology in the network with all their properties and values ? It boggles my mind why these specifics are split up in by metadata and values separately as they belong together. Then again I only have 2 zwave devices so don't mind my oversimplification.

I tried:

getDefinedValueIDs > split > for each getValueMetadata, but this ends up in an infinite loop with errors that not all ValueIDs cannot be found somewhere in between the messages, but I digress.

I think it could be more user friendly to provide additional nodes that do the translation mapping in the background with dynamically populated fields, something like:

where the commands are dynamically retrieved based on node selection and the input payload input suggestion based on the command selection as a translation layer to generate the messages

It is all kind of convoluted in my eyes, especially when dealing with the valueAPI - i am using battery powered devices.

As mentioned I am working on this ability already here.
#113

[marcus-j-davies]

So,

A ValueID describes:
The CC, the Nodes endpoint and the property for that CC.

example.

You have a device that has 2 batteries.
Each battery is served by a different endpoint (think of a Z-wave switch with 2 outlets = 2 endpoints, but still one node)

Each battery has the % level, charging state and a isLow property.
So each battery has 3 values (each of these values Is given a valueID)

but we have 2 batteries, so we need 6 ValueIDs (and the only real difference is the endpoint)
a valueID also includes the endpoint.

HINT
double click a value in the UI - you will see its ValueID 😄

[marcus-j-davies]

PS I have a node being developed where it will generate commands for you 👍
#113

[bakman2]

Hold on one second, i was not even aware there was a tab!

[marcus-j-davies]

Really? - I also added a network map.

Happy Friday! 😆

[marcus-j-davies]

https://github.com/zwave-js/node-red-contrib-zwave-js/wiki/User-Interface

[marcus-j-davies]

My screenshot is showing my development version - new icons and such for node status'

[bakman2]

It all looks great, fantastic stuff. If the "basic editing" could also be translated to separate nodes, or something like that, that would be awesome. Let me first try to get this all working, i am able to turn on the valves and set the setpoints (took me a while tbh).

[marcus-j-davies]

the new cmd-factory node will;

• Ask for the CC (dropdown)
• Ask for the method on that CC (dropdown)
• and will take JSONata values to dictate the params for the method, node and endpoint if needed.

the cmd-factory node will then spit the command out to its sibling - which you can send directly to the controller or utilise in another node from NR

[bakman2]

This looks indeed what i was referring to, really nice!

[marcus-j-davies]

This looks indeed what i was referring to, really nice!

I am not far from doing this - if you want to be a beta tester when its ready (and your still with us 😉)
I have 2 beta testers - but more the merrier of course.

[marcus-j-davies]

Do look at the CCAPI - its much much much easier (to get started with)
The only draw back in CCAPI - is that the UI wont update itself (unless the device acknowledges it with an update event)

You can force a UI update from CCAPI using forceUpdate I want bombard you, but it's on the wiki.

changing the thermo
https://zwave-js.github.io/node-zwave-js/#/api/CCs/ThermostatSetpoint?id=set

let Message = {
    payload: {
        mode: "CCAPI",
        node: 56,
        cc: "Thermostat Setpoint",
        method: "set",
        enums: {
            0: "ThermostatSetpointType"
        },
        params: ["Heating", 15, 0x00] /*0x00 - for Celsius */
    }
}
return Message

[marcus-j-davies]

the zwave protocol has integers for the type of setpoint (its not the only CC in the spec)

"N/A" = 0x00,
"Heating" = 0x01, // CC v1
"Cooling" = 0x02, // CC v1
"Furnace" = 0x07, // CC v1
"Dry Air" = 0x08, // CC v1
"Moist Air" = 0x09, // CC v1
"Auto Changeover" = 0x0a, // CC v1
"Energy Save Heating" = 0x0b, // CC v2
"Energy Save Cooling" = 0x0c, // CC v2
"Away Heating" = 0x0d, // CC v2
"Away Cooling" = 0x0e, // CC v3
"Full Power" = 0x0f, // CC v3

instead of remembering these numbers, we can just give it a name like "Heating"
but then we need to convert "Heating" into the proper zwave spec numerical number.

we do that with an enum
But what enum should we use... we say that here.

enums: {
 0: "ThermostatSetpointType"
}

so pass parameter 0 (zero) though the enum of ThermostatSetpointType
what then gets sent to the device for the type of Set point is 0x01 ("Heating")
if we were to set parameter 0 to 'Dry Air' - 0x08 will be used in the message to the device

[marcus-j-davies]

a thermostat can control anything from central heating, cooling, a furnace etc etc hence the need to specify the setpoint type.
indeed the thermo may only do one i.e Heating. but the specification still insists it needs to be sent 🤷

[marcus-j-davies]

here is all the CC's that you can use (albeit if your have such devices)

https://zwave-js.github.io/node-zwave-js/#/api/CCs/index

[bakman2]

As a sidenote; with the previous node I could send the following, which clicked in my mind.

{"nodeid":3,"cmdclass":67,"cmdidx":1,"value":23}

This node is more verbose in a complex manner, but I got it working ;) thanks for your time and effort for creating it!

[marcus-j-davies]

Well if you do stick around 😉 the cmd-factory node will offer a very slimline approach to it all
(have been asked of this by current users - so I better do it 😆 )

BTW, if using the CCAPI - you dont have to use the CC Name, you can use the hexadecimal ID, as displayed here if you prefer
https://zwave-js.github.io/node-zwave-js/#/api/CCs/index

let Message = {
    payload: {
        mode: "CCAPI",
        cc: 0x43,
        method: "set",
        enums: {
            0: "ThermostatSetpointType"
        },
        params: ["Heating", 15, 0x00]
    }
}
return Message

believe it or not, ZWave-JS - the backend driver to this, is the only open-source driver that strictly follows specifications, and one that offers the complete package Including S2 security) - click on include/exclude in the UI.

https://github.com/zwave-js

(and I do agree, in that it strips away a lot of colour)

I think my aim here was to have a 1:1 relationship with the driver.
it takes a little leaning - but it ends up being a very robust setup

[endSalesPitch]

😉

any problems - please reach out to us.

[marcus-j-davies]

@bakman2,

we will soon have a much friendlier way to produce commands.
this allows a drop down of your target CC and the method to execute on that cc.