Changing the thermostat setpoint doesn't generate an event

[fabnavigator]

I thought that when I changed the thermostat setpoint by sending a message to the controller that the controller then sent out a message saying that the setpoint was updated. I'm not seeing that message generated in V8. The thermostat setpoint changes as it should. I'm think I got that message in V7.

[marcus-j-davies]

The value updated events are triggered when:

• A device has confirmed it's been changed
• A device sends an unsolicited report of a value.

I know v10 is working on updating the mechanism quite a bit, so this may be just a teething issue whilst it's under WIP.
I would hold fire about raising this with the driver repo until my next beta release.

All events are coming from the driver, so if you're not seeing them, they are not being generated by the driver.
but again - hold fire to see if it improves, I raised a bug about some supervised queries, that resulted in odd behaviour, that was fixed, but not yet merged.

[marcus-j-davies]

@AlCalzone.

In v10, setting a thermo set point does not yield a value updated event < v10 does so.
I initially thought it was tied to the nested supervision bug - but I cant see any evidence of it here 😅

Node 109

2022-08-09T17:26:25.354Z NDERED « [CONTROLLER] Payload received.
2022-08-09T17:26:25.355Z NDERED « [Node: 109] [API: ValueAPI] [Method: setValue]
                                  └─[params]
                                      0: {"commandClass":67,"endpoint":0,"property":"setpoint","propertyKey":2}
                                      1: 82
2022-08-09T17:26:25.437Z SERIAL » 0x010f00a9016d039f01c225000000001d52                                (17 bytes)
2022-08-09T17:26:25.438Z DRIVER » [Node 109] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      29
                                  └─[Security2CCNonceGet]
                                      sequence number: 194
2022-08-09T17:26:25.444Z SERIAL « [ACK]                                                                   (0x06)
2022-08-09T17:26:25.446Z SERIAL « 0x010401a90152                                                       (6 bytes)
2022-08-09T17:26:25.446Z SERIAL » [ACK]                                                                   (0x06)
2022-08-09T17:26:25.447Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2022-08-09T17:26:25.453Z NDERED « [CONTROLLER] Payload received.
2022-08-09T17:26:25.454Z NDERED « [Node: 99] [API: ValueAPI] [Method: setValue]
                                  └─[params]
                                      0: {"commandClass":37,"endpoint":0,"property":"targetValue"}
                                      1: true
2022-08-09T17:26:25.500Z SERIAL « 0x011d00a91d00000100bb7f7f7f7f00000300000000030100007f7f7f7f7f92    (31 bytes)
2022-08-09T17:26:25.501Z SERIAL » [ACK]                                                                   (0x06)
2022-08-09T17:26:25.502Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            29
                                    transmit status:        OK, took 10 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 100 kbit/s
                                    ACK RSSI:               -69 dBm
                                    ACK channel no.:        0
                                    TX channel no.:         0
2022-08-09T17:26:25.511Z SERIAL « 0x011d00a800016d149f02b6014183bc7809c4de8bb79fcc5759a8893200bbc4    (31 bytes)
2022-08-09T17:26:25.513Z SERIAL » [ACK]                                                                   (0x06)
2022-08-09T17:26:25.514Z DRIVER « [Node 109] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -69 dBm
                                  └─[Security2CCNonceReport]
                                      sequence number:  182
                                      SOS:              true
                                      MOS:              false
                                      receiver entropy: 0x4183bc7809c4de8bb79fcc5759a88932
2022-08-09T17:26:25.527Z SERIAL » 0x013300a9016d279f03c30112416b2b62fa91c6cf18ba03533c79c97d9cdaf8159 (53 bytes)
                                  a71f56134b97ca5851bebe3f3fb25000000001e45
2022-08-09T17:26:25.529Z DRIVER » [Node 109] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      30
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 195
                                    │ extensions:
                                    │ · type: SPAN
                                    │   sender EI: 0x6b2b62fa91c6cf18ba03533c79c97d9c
                                    └─[SupervisionCCGet]
                                      │ session id:      1
                                      │ request updates: true
                                      └─[ThermostatSetpointCCSet]
                                          setpoint type: Cooling
                                          value:         82 °F

Is this on the radar, or would you like it logged?
@fabnavigator if a bug report is required, use the below template (attaching this log file)

https://github.com/zwave-js/node-zwave-js/issues/new?assignees=&labels=&template=bug_report.yml

[AlCalzone]

The ThermostatSetpointCCSet (like many other commands) is now sent using Supervision, which means we know from this response

2022-08-09T17:26:25.613Z DRIVER « [Node 109] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -69 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 183
                                    └─[SupervisionCCReport]
                                        session id:          1
                                        more updates follow: true
                                        status:              Success
                                        duration:            0s

that the value was updated on the device. Previously this had to be verified separately by querying the device again, or waiting for an unsolicited update.

The difference is that the value is updated in the DB, but without emitting an event. This is probably an oversight, since not emitting the event was done to avoid double triggering (configurable).

[AlCalzone]

Fixed in the upcoming beta.6

[marcus-j-davies]

@fabnavigator.
I'll advise when I release.

[fabnavigator]

@AlCalzone, @marcus-j-davies, Thanks!