Specifically I would like to add a couple of “Command Classes” to my devices.
My Thermostats will support Command Class 129 (Clock Update) and It also reports relative humidity under Command Class 49, but only it I can turn on MultiCast , but the driver built into ZWave JS does not do either. There are others who have written Custom Drivers for Hubitat and Smartthings I have examples of both, and both not only use system time to update the clock on the thermostat but will also report humidity.
Would love to automate my Air Exchange unit in my house…
Is there way to download the Zwave Device files and then adjust them?
Are you certain your problems are not with HA? Z-Wave JS supports both the Clock CC and Multilevel Sensor (Humidity), and usually device support is detected automatically. It’s very rare to need to add them manually, but does happen occasionally.
You cannot control Clock in HA without using low level commands. Humidity should be represented by sensor.
If you upload the Device Diagnostic data (preferably to a Pastebin site), I could confirm whether your device should be working without any config file changes.
Link to Device Diagnostics posted below.
.
You can see the “Air temperature” is identified with “sensor type 1” I’m pretty sure the humidity value is at Sensor type 5. You can also see that the Driver knows that the device can take clock setting commands, but again no definition of them.
The thermostat is talking via Zwave Js / Zwave2MQTT I get lots of MQTT events from it too, Nothing from the humidity sensor. Also Ironic that the “stock” driver can change the sensitivity of the humidity sensor… it just seems to omit defining its value… My goal is to run a simple automation… based on a Humidity Trigger, I turn on the air exchange system ( or a bathroom exhaust fan) .
According to the dump, the device reports temperature, but not humidity. Do you see any humidity value in the zwavejs2mqtt control panel? You’ll have to create an issue in the node-zwave-js project to get this fixed. According to the OpenHAB database, humidity is reported on endpoint 2. Perhaps Z-Wave JS is not handling the multi-channel configuration of this device correctly. It appears to be consolidating them into a single endpoint (root, aka 0).
You can also see that the Driver knows that the device can take clock setting commands, but again no definition of them.
Correct, as I said, HA nor zwavejs2mqtt currently provide an interface to set the clock, except via raw driver commands. This service call from HA will do it. Click to go to Services, switch to YAML mode, copy and paste this, then switch back to UI mode and choose your device, and click Call Service. This example sets to time to 5:30 PM.
The thermostat is talking via Zwave Js / Zwave2MQTT I get lots of MQTT events from it too, Nothing from the humidity sensor. Also Ironic that the “stock” driver can change the sensitivity of the humidity sensor… it just seems to omit defining its value…
FYI, there aren’t any custom “drivers” (or device handler, I presume you really mean) in Z-Wave JS like Smart Things. The value of the humidity sensitivity configuration is set to 5%. Is the humidity changing by that much? Regardless, it wasn’t detected as supported, so that would need to be addressed first.
Lots to work with there! Thanks so much. And sorry in advance, my use of proper nomenclature is the pits. But in spite of me misnaming things we are on the same page.
In my Zwave2MQTT control panel not have a value for humidity, but it does have a value for humidity sensitivity. (which can be changed as a setting) 3 or 5, 10%.
So first things first… I will try the re-interview process now…
Z-Wave JS has the ability to auto-correct the clock based on the system time, however it seems that only happens if the node sends an unsolicited Clock report. I have a CT32 thermostat, and I don’t think it sends any reports on its own. I would guess the CT101 doesn’t either. So manually setting the time does seem to be required.
service: zwave_js.invoke_cc_api
data:
command_class: '129'
method_name: set
parameters: >-
{% set t = now() %}
{{ [t.hour, t.minute, t.weekday()+1] }}
Just because I was interested in figuring out how, I think this version will set a more accurate time by rounding to the nearest minute (solution from SO). I don’t think there’s any reason to use this version though. If your automation trigger is based on a time with minute resolution, it should be executed well before rounding would even be a consideration, e.g. an automation scheduled at 2:00 AM should run before the time 2:00:30 AM is reached.
service: zwave_js.invoke_cc_api
data:
command_class: '129'
method_name: set
parameters: >-
{% set t = now() + timedelta(seconds=30) %}
{% set t = t - timedelta(seconds=t.second, microseconds=t.microsecond) %}
{{ [t.hour, t.minute, t.weekday()+1] }}
