CT100 doesn't show current temperature w/ Zwavejs2mqtt

Configuration Z-Wave
1

I moved to zwavejs2mqtt a few months ago. I never really noticed it before because i guess it wasn’t cold enough. Now I know the current temp reported on both thermostats is not right. Any ideas. I searched threads but nothing came up.

zwavejs2mqtt docker 5.11.0 zwavejs 8.7.5
home assistant docker 2021.11.1 at the moment. , went back to 2021.10.7 but was broke as well.
Any ideas.

Update:
Found the work around in this thread zwave_js.refresh value. Stuck a timer in nodered to refresh both ct1000

1 Like
2

Just an update for anyone coming across this thread and having similar issues. The issue with the CT100 not updating automatically seems to be fixed as of zwave-js v9.4.0 (June 2022) where the device config file ct100.json was improved. See https://github.com/zwave-js/node-zwave-js/pull/4686.

The new config file is at node-zwave-js/ct100.json at e783120f06422528e24b3ebbd41ff4604501a3b8 · zwave-js/node-zwave-js · GitHub.

If you prefer you can try this new config file without upgrading zwave-js by replacing your current ct100.json file with the new one, restarting zwave-js (or rebooting) and then re-interviewing your CT100. After doing this I no longer need to refresh or poll the device to get it to update.

1 Like
3

I am running zwavejs in a docker container, how would I replace the ct100.json file

4

You are running the zwave-js server on your own, or are you using zwavejs2mqtt?

For the former, you need to configure the deviceConfigPriorityDir directory option in the driver configuration, then copy the file to that directory.

For the latter, create a config directory in your data store directory, and copy the file there. See custom device files docs.

Restart the container afterwards and re-interview.

5

I got it that was mapped to a /config director in my docker setup . I copied it there . seems to be working

6

An additional update:

It appears that the newer ct100.json config file is now packaged with zwavejs2mqtt version 0.44 (as of July 2022).

You can see the key evidence for this by navigating to the zwavejs2mqtt dashboard, selecting the control panel view, and then expanding the device details for your CT100 thermostat.

It defaults to showing the node information. Select instead the groups information for the device. With the old configuration file, the group for endpoint 0 is labeled “Group 1” whereas with the newer configuration file, the group for endpoint 0 is labeled “Lifeline.”

The relevant configuration clause in ct100.json is:

	"associations": {
		"1": {
			"label": "Lifeline",
			"maxNodes": 2,
			"isLifeline": true
		}
	},

While I can’t be certain of this, I suspect this is fundamentally the reason for the CT100 not automatically reporting changes to Home Assistant. Even though the old config file still tags the association as “Lifeline”, for some reason the fact that this association was labeled “Group 1” instead of “Lifeline” seems to prevent the CT100 from automatically reporting to the controller via the Lifeline group association.

In any case, it appears that the updated CT100 config file has now propagated to zwavejs2mqtt as of v0.44

7

Hey all. Config file updater here. I wanted to check in and inquire if your thermostats are still working properly. Its obviously been quite some time since the merge, but zwave js has seen lots of updates and changes. As such, I have noticed that the Ct100 in my house reports cooling state in the second node thermostat state. However, the thermostat setpoint from the physical thermostat does not update in the second node, but on the first one. However, state changes seem to update on the second node in zwave, but not temperature setpoints. I am personally at a loss as to how to troubleshoot this. Reverting to polling is probably not ideal, so I wanted to know how its going for you all. Thanks!

8

I periodically reinterview the tstats, which seems to help. Curiously the last reinterview invalidated some of the sensors, which I deleted manually.

9

I wish we could get these CT100 thermostats working better. I have two of them in my home (two furnaces). I haven’t exactly figured out what is causing it, but after certain updates to Home Assistant, I get two extra thermostat controls, and 1 extra air temperature sensors per thermostat. I have to re-interview each device and then delete them manually (after the re-interview they appear as deactivated). If I don’t do this, I can’t use the Climate Service to control the temperature in my automations.

If there was something I could do to fix this, I definitely would. I’m not sure what exactly triggers these defunct components to come back after an update.

10

Usually a problem with multiple endpoints. The device is configured by the driver to act as a single endpoint, but then later on something causes it to report multiple endpoints.

Make sure you are on the latest version of Z-Wave JS, and don’t have any custom device files as this device (assuming CT100, not the Plus model) has had relevant changes to handle endpoint issues, as of about 5 months ago.

Driver debug logs would tell you why. You can create a new issue at node-zwave-js, making sure to create a driver debug log that captures a re-interview and the problem.

11

I’m on the latest versions of everything (the update that I took today for either the HomeAssistant OS or the latest dot release of HomeAssistant) caused the extra devices to show up. I don’t have a Plus model, just the CT100.

Should I (can I) get Driver debug logs at update time? Or just during the re-interview? To be clear, the re-interview fixes the problem, it’s the upgrade that seems to cause the issues again.

12

Upgrade of what? Upgrading Home Assistant wouldn’t have anything to do with it. More likely it was just the restart that would happen after the update. You want debug logs of the interview, and then including whenever the problem appears. If it doesn’t show up until a restart, maybe just operating the thermostat will trigger it.

13

Hmm, let me play around a bit. Perhaps it is the restart of Home Assistant that causes the issue to come back.

14

You can watch the debug log file and look for reports coming from the node. It will tell you which endpoints they are coming from. You can compare what is being reported in the device diagnostic file, which will have all of the backing values for the thermostat entity, which are what HA uses.

15

So restarting HomeAssistant did not cause the problem to re-occur. I am guessing that some type of upgrades of HomeAssistant or maybe zwave-js is what triggers the problem. Also, the debug logging for zwave-js did not survive the reboot.

16

The device would need to send some reports to cause the issue though, so if you aren’t waiting long enough, nothing will change. I cannot see how HA or Z-Wave JS upgrades specifically, where each version has different changes, would continue to cause the same issue. It’s more likely it’s a coincidence because you are also also restarting HA or causing the integration to re-load when you do an upgrade.

Reboot? Are you restarting HA, Z-Wave JS UI, or rebooting your server? All that needs to be done for this experiment is to restart HA, as that is what happens when you upgrade it. To clarify, are you actually using Z-Wave JS UI (“zwave-js” is ambiguous), and if so did you click the Save button when you made the logging changes? If you aren’t using Z-Wave JS UI, how did you enable logging?

17

I did a full restart of HA. (Settings->System->Click on Power button->Select “Restart Home Assistant”). I have checked again (it’s been an hour or so) and the extra components on the CT100 devices did not reappear. I also changed the temp from HA and the extra components did not appear.

I am using Z-Wave JS that is integrated in with HA (this is the Z-wave JS UI add-on). I neglected to click the ‘Save’ button, oops. Since I can’t repro the issue with the HA reboot, I’m at a bit of a loss as to how to reproduce this. If you have some other suggestions, I’d be open to try them out. The only time I’ve seen these reappear is after an upgrade, but not all upgrades seem to trigger it…

18

The official add-on that is integrated with HA is called “Z-Wave JS”. The “Z-Wave JS UI” add-on is a community add-on (not integrated with HA) that is based on “Z-Wave JS UI”. Both add-ons use the driver which is also usually called “Z-Wave JS”. You can probably see how confusing it is if you only say you are using “Z-Wave JS” without any other qualifiers, which is why I had to ask.

Since I can’t repro the issue with the HA reboot, I’m at a bit of a loss as to how to reproduce this.

When was the last time it happened? Are you sure it wasn’t fixed? That would have been with driver v11.13.0, available from Aug 2023.

19

Yeah, I see why it’s confusing, sorry I wasn’t more clear (I’m a software engineer and I am constantly sending bugs back to the filer because the repro steps aren’t clear or precise enough). It happened today when I installed some updates. It happened a week or two ago right after I installed some updates. So, yeah, I’m pretty sure it hasn’t been fixed yet. What I can do is the next time there is an update I’ll try to remember to enable the logging (and click save), then see if it breaks again. Then I can collect the logs when I re-interview. I’ll open a bug with that info (at the location you provided) and I’ll post an update in this thread with a link to the issue. Hopefully we can get it isolated…

20

I would save a copy of the device diagnostic in the current working state, and keep it to compare to the device in its bad state. I would expect the current values are all corresponding to only one endpoint (you can verify that now) and in the bad state there will be multiple endpoints, none of them matching the previous one, or something similar to that.

Make sure the logging is set to log to file (I think that’s default) and is on debug level, and is the driver setting.