So....
Looks like the CCAPI now wants the name, and not the CC ID - that's new to me 
the CCAPI is of a lesser API - so I don't use it as much, still now I know.
Don't ask me, this is similar to what i used to set the heating mode etc 
Looks like it is working:
2022-11-21T17:40:34.414Z NDERED « [EVENT] Payload received.
2022-11-21T17:40:34.414Z NDERED « [Node: 2] [API: CCAPI] [CC: Multilevel Sensor] [Method: sendReport]
└─[params]
0: 1
1: 0
2: 17.51
2022-11-21T17:40:34.416Z SERIAL » 0x01110013020a6c01a9063105014206d72503b7 (19 bytes)
2022-11-21T17:40:34.417Z DRIVER » [Node 002] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 3
└─[SupervisionCCGet]
│ session id: 41
│ request updates: true
└─[MultilevelSensorCCReport]
type: Air temperature
scale: Celsius
value: 17.51
2022-11-21T17:40:34.417Z NDERED « [EVENT] Payload received.
2022-11-21T17:40:34.417Z NDERED « [Node: 3] [API: CCAPI] [CC: Multilevel Sensor] [Method: sendReport]
└─[params]
0: 1
1: 0
2: 17.51
2022-11-21T17:40:34.418Z SERIAL « [ACK] (0x06)
2022-11-21T17:40:34.425Z SERIAL « 0x0104011301e8 (6 bytes)
2022-11-21T17:40:34.425Z SERIAL » [ACK] (0x06)
2022-11-21T17:40:34.425Z DRIVER « [RES] [SendData]
was sent: true
2022-11-21T17:40:35.711Z SERIAL « 0x010700130300008169 (9 bytes)
2022-11-21T17:40:35.712Z SERIAL » [ACK] (0x06)
2022-11-21T17:40:35.712Z DRIVER « [REQ] [SendData]
callback id: 3
transmit status: OK
2022-11-21T17:40:35.732Z SERIAL « 0x010b00040002056c0229ff004f (13 bytes)
2022-11-21T17:40:35.732Z SERIAL » [ACK] (0x06)
2022-11-21T17:40:35.732Z DRIVER « [Node 002] [REQ] [ApplicationCommand]
└─[SupervisionCCReport]
session id: 41
more updates follow: false
status: Success
duration: 0s
2022-11-21T17:40:35.734Z SERIAL » 0x01110013030a6c01aa063105014206d72504b2 (19 bytes)
2022-11-21T17:40:35.734Z DRIVER » [Node 003] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 4
└─[SupervisionCCGet]
│ session id: 42
│ request updates: true
└─[MultilevelSensorCCReport]
type: Air temperature
scale: Celsius
value: 17.51
2022-11-21T17:40:35.736Z SERIAL « [ACK] (0x06)
2022-11-21T17:40:35.743Z SERIAL « 0x0104011301e8 (6 bytes)
2022-11-21T17:40:35.743Z SERIAL » [ACK] (0x06)
2022-11-21T17:40:35.743Z DRIVER « [RES] [SendData]
was sent: true
2022-11-21T17:40:37.082Z SERIAL « 0x010700130400008669 (9 bytes)
2022-11-21T17:40:37.083Z SERIAL » [ACK] (0x06)
2022-11-21T17:40:37.083Z DRIVER « [REQ] [SendData]
callback id: 4
transmit status: OK
2022-11-21T17:40:37.101Z SERIAL « 0x010b00040003056c022aff004d (13 bytes)
2022-11-21T17:40:37.101Z SERIAL » [ACK] (0x06)
2022-11-21T17:40:37.102Z DRIVER « [Node 003] [REQ] [ApplicationCommand]
└─[SupervisionCCReport]
session id: 42
more updates follow: false
status: Success
duration: 0s
2022-11-21T17:40:39.301Z SERIAL « 0x010c00040003063105014205e060 (14 bytes)
2022-11-21T17:40:39.301Z SERIAL » [ACK] (0x06)
2022-11-21T17:40:39.302Z CNTRLR [Node 003] [Multilevel Sensor] Air temperature: metadata updated [Endpoint 0]
2022-11-21T17:40:39.302Z CNTRLR [Node 003] [~] [Multilevel Sensor] Air temperature: 14.43 => 15.0 [Endpoint 0]
4
2022-11-21T17:40:39.302Z NDERED » [Node: 3] [VALUE_UPDATED] [DIRECT] Forwarding payload...
2022-11-21T17:40:39.302Z NDERED » [Node: 3] [VALUE_UPDATED] [EVENT] Forwarding payload...
2022-11-21T17:40:39.303Z DRIVER « [Node 003] [REQ] [ApplicationCommand]
└─[MultilevelSensorCCReport]
type: Air temperature
scale: Celsius
value: 15.04
I am just a bit confused about the last line value: 15.04. I send it to be 17.51, i guess the internal temperature sensor is still measuring.
I believe it is 
I think I know why using the CC ID didn't work.
in code we do this, to invoke the CCAPI.
const EP = msg.payload.endpoint || 0
const CC = msg.payload.cc
const Params = msg.payload.params || []
const Node = msg.payload.node
const Method = msg.payload.method
Driver.controller.nodes.get(Node).endpoints(EP).invokeCCAPI(CommandClasses[CC], Method, ...Params);`
I think the collection exposed by CommandClasses was changed in the driver a version or 2 ago.
so only the names are now indexed (no longer their ID's)
I noticed something weird again.
Now I have set this TRV to use an external temperature sensor and the temperature gets injected with the commands above.
{
"valueId": {
"commandClassName": "Configuration",
"commandClass": 112,
"endpoint": 0,
"property": 8,
"propertyName": "Temperature Offset"
},
"meta": {
"type": "number",
"readable": true,
"writeable": true,
"valueSize": 1,
"min": -128,
"max": 50,
"default": 0,
"unit": "0.1 °C",
"format": 0,
"allowManualEntry": true,
"states": {
"-128": "Ext temp sensor be used for regul"
},
"label": "Temperature Offset",
"isFromConfig": true
},
"propertyid": "0-112-8-",
"endpoint": 0,
"valueData": {
"value": -128,
"unit": "0.1 °C"
}
}
What I noticed is that now the multilevel switch no longer gets updated, they will alway stay at the same value, eg:
"valueId": {
"commandClassName": "Multilevel Switch",
"commandClass": 38,
"endpoint": 0,
"property": "currentValue",
"propertyName": "currentValue"
},
"meta": {
"type": "number",
"readable": true,
"writeable": false,
"min": 0,
"max": 99,
"label": "Current value"
},
"propertyid": "0-38-currentValue-",
"endpoint": 0,
"valueData": {
"value": 32
}
}
Only when I heal the node(s), I see the values change. Is this a visual thing in the zwave ui panel or should that value always reflect the value of the device ?
Hi @bakman2
I'm guessing the Multilevel Switch is for the valve position?
The UI updates whenever the device sends a new position, and this under normal setup is driven by the air temp of the internal sensor.
In this mode, it likely sends updates to your controller = UI gets updated
As we are now sending known values ourself - it may no longer do so.
The UI is only a slave of any updates that come into the controller (well you can control things if course )
The UI responds to the same VALUE_UPDATED events, that you may use in your flows.
so with that in mind you could log any VALUE_UPDATED events from the Spirit?
To see if its just a behaviour when set to external temp, if you still do get unsolicited updates, then they should reflect in the UI - else I have a bug in the UI I should fix (but will come in v9) 
One thing to also check is the Associations, the Spirit may have a different setup of sending updates when using ext temp. it could be there is a different association that needs setting up when using ext temp, but it likely only has 1 - lifeline, and it should be addressed to the controller (1)
I do get VALUE_UPDATED but only for the air temperature, I am just wondering if the thing is now just on full blast all the time or that it internally gets regulated based on the temperature i am sending.
Perhaps I should use dynamic temperature offset's instead. (the thing is so far off with its temperature it is absurd.)
You could test...
- Set an absurd temp your self
- wait 1 min
- poll the switch (below)
let VID = {"commandClass": 38, "endpoint": 0,"property": "currentValue"}
let Message = {
"payload": {
"mode": "ValueAPI",
"node": 42,
"method": "pollValue",
"params": [VID]
}
}
return Message
repeat with another absurd temp - see if there is a change to the switch
Im guessing this device remain slightly awake, in order to receive updates from the 'external temp'
EDIT
it remains awake.
Spirit Z-Wave uses FLiRS to provide short latency and short responding times.
Ok maybe this never worked but i have not been bothered by it before. When I poll the value, it indeed updates the value in the panel.
Its very strange.
The temperature values being set by you are all valid
This is the device confirmation that all is well.
2022-11-21T17:40:35.732Z DRIVER « [Node 002] [REQ] [ApplicationCommand]
└─[SupervisionCCReport]
session id: 41
more updates follow: false
status: Success
duration: 0s
so unsure why you don't get Multi Level Switch reports when sending temp values manually, can only guess its a quirk of the device.
you do have poll (as above) but that is lame!
it might be worth checking the config parameter 6 Valve opening percentage report
set it to 1 (make sure its not 0), I didn't bring it up as we assumed you had always received the reports - it could well be disabled 
Link to config
it might be worth checking the config parameter 6 Valve opening percentage report
set it to 1 (make sure its not 0), I didn't bring it up as we assumed you had always received the reports - it could well be disabled
uhm yes they are 0, are those related ?
Will that eat the battery if set to 1 ?
If set to 0 will not send the Multi Level Switch value (valve position)
if you don't have a need to have the latest valve position, its not worth enabling it
1 Like
At least for understanding what the thing is actually doing when regulating the temp from another source it is good to have it for now, i do receive them now (the valve opening report) it did not occur to me that the valve opening = multilevel switch, which ofcourse makes a lot sense duh.
The ultimate Test!
- Enable Config 6 (1)
- Set an absurd temp your self
- you should get a valve change update ~1min (just a guess)
- Disable Config 6 (0) (to save battery)
It is done, i receive them, i could increase it to 5% or 10%, i will monitor all the data. Thanks a lot for all the support, the zwave realm remains a bit weird to me, but these valve have been working for a number of years and the batteries last quite some time, don't feel the need to switch to zigbee (although it would have my preference as i have many zigbee based devices).
1 Like
Yeah, ZWave is designed with a set number of Command Classes
- Binary
- Basic
- Multi Level Sensor/Switch
- Sound Switch
- Access Control
- Indicator
- Notification
- Countless others....
Bring in the CMD Factory Node, set it to CCAPI, and you can list some of the CC's
These CC's are then used in the best way for the target device type...
- Temp Sensor, Lux Sensor, Moisture Sensor etc etc -> Multi Level Sensor
- Valves, Brightness, Window shutters etc etc -> Multi Level Switch
- On/Off Devices (plugs), Motion Sensors, Door Sensors -> Binary
- Alarms / Sirens -> Sound Switch
- Security Keypads, Door Locks -> Access Control
Etc etc
These CC's then have a number of methods one can use.
I think the idea, is to cover all basis, then manufactures (like eurotronic) can use them in the best way, they see fit.
Zigbee, approaches it differently.
"its a light bulb, so give it brightness control and a switch"
so the type of control is more about the device, as opposed to a set standard.
I only have.... wait for it....2 zigbee devices (bulbs) so not really educated in the standards with it all
Yeah the difference comes in where in the zwave realm it appears that manufacturers can keep certain settings hidden/propriety/non-documented? In zigbee that is not really possible, i might be mistaken. Both protocols work pretty reliably, zigbee a bit easier for me
1 Like
Its interesting...
Propriety is probably the polar opposite in zwave (at least its designed to be )
Ring, a big Smart Security company in the UK (just using them as an example), uses ZWave for their devices.
"You must use our hub, otherwise it won't work blah blah blah blah"
Because ZWave has a defined set of CC's they can't do anything special or out of scope.
So I use them in ZWave quite often (Security Pin Pad that controls my DIY security system) - No Hub needed 
Indeed, they do make it harder (or not document it) to enforce you into there eco system - but if using ZWave - they are bound to a set standard 
1 Like
