node-zwave-js: Second Thermostat Setpoint not being found for Intermatic PE653 z-wave pool controller

That would be @philh30 in https://github.com/zwave-js/node-zwave-js/pull/5822 Sorry for the tag, but credit where credit is due 😃

FYI, there’s already an issue for this, https://github.com/zwave-js/node-zwave-js/issues/4588, along with a POC PR to allow for overriding the auto-detected setpoints.

@AlCalzone why don’t the interview logs here show the setpoint interpretation selection since the CC is v1? I see the logs on my v2 ("Thermostat Setpoint bitmap interpretation is unknown, assuming B for now"). Not that it would help here, just curious.

@bluemantwo You can try manually programming setpoint 7 with a HA Dev Tools Service call:

service: zwave_js.invoke_cc_api
data:
  command_class: "67"  # thermostat setpoint cc
  method_name: set
  endpoint: "1"
  parameters:
    - 7   # setpoint
    - 78  # temperature
    - 1   # scale: 1 == F
target:
  entity_id: climate.z_wave_thermostat

In my testing, Z-Wave JS does not care whether the setpoints are supported or not, it will just do as you say. You will not be able to view the setpoint values in HA.

As an aside, seems like your ZUI’s device DB is corrupted. Might want to get the fixed somehow. No idea how to do that if this is the HAOS add-on.

2023-01-16T01:42:26.630Z CONFIG   version 10.3.1
2023-01-16T01:42:27.862Z CONFIG   Error parsing config file dsb09.json: Could not parse config file /data/store/
                                  config/templates/aeotec_template.json: ENOENT: no such file or directory, open
                                   '/data/store/config/templates/aeotec_template.json'
                                  Import stack: 
                                    in #selective_reporting
                                    in /data/store/config/dsb09.json (ZW0340)

zwave_js-3a152d2a5cd6e4dafe5146f53abf5151-Pool-dea02e849740113a6c5c426a9b4d5eb1.json (1).txt

I really appreciate the work of whoever created all the parameter values for the PE653. There were several that I never knew existed, and a couple I had guessed wrong on. HUGE thanks to whoever did all the research and detective work to get those parameters. My experience has been that Intermatic has been terrible at documenting their pool controller in the past.

@bluemantwo did you manage to improve the connectivity? Problems 1 and 3 above are fixed, so we should be able to continue.

but for some reason it always wants to go direct

The latest Z-Wave JS UI lets you configure priority (return) routes which are always attempted first.

Hmm I think this is a combination of a handful of semi-related issues:

1. I suspect that firmware 3.9 also only supports Multi Channel CC v1, but it reports support for V2 like firmware 3.4 where we forced the use of v1. As a result a lot of queries for the endpoints fail.
2. Your device seems to have bad connectivity. I see several communication attempts falling back to 9.6 kbit/s and many RSSI readings below -90 dBm which is terribly close to background noise.
3. Lots of responses to endpoint functionality queries are delayed and/or repeated (probably due to the above), and Z-Wave JS currently fails to check that the received one matches the queried one, so there is a bit of chaos in the interview (which also fails a couple of times).

I suspect these problems are also the reason why the compat flag does not get applied. We shouldn’t actually see the thermostat setpoint query go out, but it does.

You’ll need to look into 2., I’ll have to fix 1. and 3. before we can retry.

I will do. Thank you so much for the exceptional work you are doing for the community.

That API is specifically built to support all possible time related CCs a device may use.

maybe this api is simpler? https://zwave-js.github.io/node-zwave-js/#/api/node?id=setdateandtime

ClockCC.get() doesn’t have any parameters, not sure if they are just ignored or if that’s causing an error. I can see the interview does a get and succeeds. It’s also using endpoint 0, not 1. Then the service should be:

service: zwave_js.invoke_cc_api
data:
  command_class: "129"
  method_name: get
  parameters: []
target:
  device_id: dea02e849740113a6c5c426a9b4d5eb1

You also won’t get any kind of response in HA, you’ll have to look at the driver logs to see the result. Doesn’t seem useful then, so just updating the clock on an interval sounds like the right approach.

why don’t the interview logs here show the setpoint interpretation selection since the CC is v1?

Probably because the endpoints are set up differently for Multi Channel CC v1 and that information is lost in translation.