Eurotronic CometZ TRVs dont/stop reporting temperature incrementally as configured

[cadwizzard]

Checklist

• I have read and followed the above instructions

• I have checked the troubleshooting section and my problem is not described there.

• I have read the changelog and my problem was not mentioned there or the fix did not work.

Describe the issue

What is happening?
The multilevel sensor reports are not happening consistently and as configured (0.5 degree) unless manual refresh in JSUI is made. Then they reflect current temperature. A re-interview may solve this for a while, not always, but the issue can re-occur.

What did you expect to happen instead?
configured (default 0.5 degree) reports are reported in Home assistant

Steps to reproduce the behavior:

1. Include the CometZ in JSUI
2. The issue may already be present or take some time to occur.
3. Interview will sometimes correct this for a while
4. exclusion and re-inclusion isn't normally needed

Anything else we should know?
These TRVs are the 'new version' of the Eurotronic spirit. Similar issues with the spirits were reported here (I have nearly 20 spirits included and they operate perfectly):
https://community.home-assistant.io/t/eurotronic-spirit-z-wave-room-temperature-doesnt-refresh-with-z-wave-js/348981/3

I've seen this behavior on at least 6 CometZ's dispersed in a 60 node (mostly powered and repeater) well meshed network, and the same actions sometimes get them working again.
In the image attached is an example of how they behave with this issue before and after re-interview. You can clearly see the difference

With a manual refresh the temperature can change at least 5 degrees.

For completeness, I already reported some other strange behaviour with these exact devices and noted this problem here --> hassio-addons/addon-zwave-js-ui#620

Relating to the logfile, just after 18:00 - debug enabled
Shortly after nodes 146 and 145 were changed to setpoint 19.5 and the room heated (2 radiators in the same room)
Shortly before 19:10, #146 updated by itself, and Air temp jumped from 12-19 degrees!
Shortly after 19:11 i performed a manual sensor refresh on #145
Around 17:25 - re-interview #145
Around 19:51 - re-interview #146
Around 21:01 manual sensor refresh on #146
(also in network are non-problematic spirits #34,36,149,23,21 etc

Software versions

Driver (node-zwave-js): 12.4.1

Z-Wave JS UI: 9.7.1

Home Assistant (Yellow - but occurred the same on Pi)
Core 2024.1.5
Supervisor 2023.12.1
Operating System 11.4
Frontend 20240104.0

Aeotec Gen5+ controller

Device information

Manufacturer: Eurotronic
Model name: CometZ
Node ID: 146 & 145

Checklist

• I made sure to provide a driver log on level debug.

• The log includes a re-interview of the problematic device (if applicable).

• The log includes the problematic interaction with the device (if applicable).

• I provided the node ID of the problematic device (if applicable).

Upload Logfile

zwavejs_2024-01-23.log

[AlCalzone]

I think this is a combination of suboptimal connectivity with excessive reporting from energy meters and multisensors. There are stretches in that log where such reports are received every 100 ms for a few seconds straight. In some other instances, they are re-transmitted over and over, essentially flooding the network. Please give this a good read and try to apply it throughout.

Z-Wave really isn't a good fit for energy metering, especially when devices report changes of 0.03 W:

2024-01-23T19:26:32.386Z CNTRLR   [Node 082] [~] [Meter] value[66049]: 10.479 => 10.452             [Endpoint 1]

or no change at all:

2024-01-23T19:26:33.009Z CNTRLR   [Node 069] [~] [Meter] value[66049]: 0 => 0                       [Endpoint 0]

Then we can come back at trying to diagnose the TRV issue. As it stands, the controller drops down to 40 kbps from the get-go although the device supports 100 kbps, which indicates a suboptimal connection to the TRV. And later during the interview, even that stops working reliably, causing several queries to time out.

I think the devices are simply having trouble sending the reports to the controller. Lots of power meters "talking" over them doesn't help.

FWIW, the update at 9:07 is triggered by Z-Wave JS because it hasn't gotten one in 6 hours:

2024-01-23T19:07:03.118Z CNTRLR » [Node 146] Multilevel Sensor CC values may be stale, refreshing...
2024-01-23T19:07:03.119Z CNTRLR » [Node 146] querying Air temperature sensor reading...

[cadwizzard]

Thanks for looking into this. i've tried to be really careful with energy reporting, ensuring i use groups 1,2,3 wisely and only get data thats required. I make sure anything reporting watts i nee to monitor has automatic report set 60 seconds or more. I have some automations that need monitoring (node 82, aeotec dual nano which does appear noisy, even though i've disabled nearly everything as below). Thats in a bathroom with a main and a wall light connected to it. The wall light relay on the nano has to be always on as the pull cord is at the mirror. Automation (multisensor 7) turn the light on if its dark and motion detected. If i dont monitor the wattage on the wall light and count that in the rules, turning the wall/mirror light on will create enough light to turn off the main lights.
The only reports i have enabled (at 60s) are power.

Despite having thresholds set (blue outline) which would be ideal, i've found especially Aeotec devices just dont seem to reliably observe that.
I disabled the blue outlined parameters last night afternoon and the light was turned on in the evening and this morning, but there is no report (which breaks the automation and makes the main lights turn off when using the mirror light)

I really do get what you are saying though and have a few metering devices. I've tried to turn their reporting way down, but the metering isn't just to look at, its used in automations. Node 82 has been noisy in the logs and I wish I could just swap that to another device, but its a module in an electrical box in a loft under insulation and boarding.

I'm not sure why there are so many re-transmissions though, as i'm sure it didnt use to be like that, and the network hasnt been changed much since that didnt happen. The only notable changes are jsui updates etc and adding the CometZ's (although i excluded Spirits to replace them, so total nodes is still 60).

The thing is, its only these CometZ i'm seeing loss of updates from. I'd notice if any of the spirits werent responding, they have been in the mesh for years.

Really appreciate you taking a look as i'm at a loss with these TRVs (and actually why there are so many retransmissions recently), i installed 6 and have already taken 4 out and reincluded the spirits so that the heating works properly.

[cadwizzard]

Before the weekend I tried to reduce the devices reporting metering where I didn't need it, but saw no difference from the CometZ TRV. I was away for the weekend and made no changes since.
Now, since updating to the latest JSUI version (3.3.0) this afternoon, Both of the the CometZs are reporting again perfectly like the spirits always have - every 0.5 degree. I did power cycle the sprits to get them to re-adjust their valve detection around the same time (28/01/24) late afternoon.

At that point I didn't have debug enabled, but I enabled it so some of the working reporting has definitely been captured later on:

zwavejs_2024-01-28.log

It remains to be seen if they will continue to behave or revert back to not appearing to report.

[AlCalzone]

Did it stay this way?

[cadwizzard]

It seems so. I can't be 100% though as they were fine before and then suddenly started not showing the temps until things were changed (interview/jsui update/power cycle etc). At the moment all is well. Unsure if i captured anything in that latest log between not working and working again. Its definitely a system rather than TRV issue a they either are all recording properly or not.

Been stable more than a few days now though :)

[cadwizzard]

OK, Last night I noticed this again, two TRVs in the same room. One working perfectly still and the other back to the old ways:

[cadwizzard]

I've been monitoring this for the past weeks. I see the reporting stop, but can consistently get it working again for a period of time by removing the batteries and re-inserting and going through the mandatory valve adjustment process. Just doing that starts the reporting. Like last night...

At one point i had 6 of these TRVs installed and they all stopped reporting. I since removed 4 and have only 2 left, both in one room, and every time i notice the reporting stop (at least for the last 3 times), battery removal has restarted the reporting for a while. Also exclude/include does the same,

[AlCalzone]

So essentially you fix it by restarting the TRVs. Sounds like something in their firmware is hanging, which prevents the proper reports.
Has anyone reported this to the manufacturer yet?

[cadwizzard]

I haven't as of yet, but now there seems to be some reproducibility I will. Would be good to have feedback from others that have any/many of these in use.

[cadwizzard]

Brief update for anyone following. I emailed Eurotronic a couple of months ago. They haven't replied. I also emailed them previously with a question on parameters for the Spirit's - they didnt reply then either, despite me sending in English and German.