Unexpected behaviour BT controlling more than one TRV

[Hapi-D]

Prerequisites

I am not certain if this is actually a bug, or me misunderstanding the POPP or maybe BT parameters. Please advise?

I have several POPP Smart thermostat (701721) devices, all updated to last firmware release. All TRVs are connected via zigbee2mqtt and a SONOFF Zigbee 3.0 V2 USB Dongle.

I have two BT devices each one controlling two POPP TRVs.

Description

A single BT device controls two TRVs in my living room, one TRV fitted on a rather large radiator, the other on a much smaller one. The large radiator could heat the entire room. The tiny radiator tries its best.
When changing setpoints I would have expected both TRVs to react more or less the same. Well, they don't.

Above is the output of the BT device: a scheduled change of target temperature to 21C. The thermostat values follow but lack enthusiasm. The setpoint temperature of 21C is reached but not before noon.

The TRV on the small radiator follows. gets a target temperature of well over 25C and makes a daring dash towards it. However a small radiator in a large room, all alone .. doesn't really make it to the target.

The large radiator does react but doesn't get its target set higher than 21C. The TRV temperature rises up to 21C but the room temperature lags.

This leaves me with the following questions:

1. Why does one TRV receive a high target temperature, much higher than the room temperature setpoint, while the other gets only target temperature hardly higher than the room temperature setpoint both controlled by the same BT
2. Is there a description of the logic and the parameters of the POPP devices? Other than the one copied into the Z2M parameter list I mean. That one is cutting the corners a bit short so I'd think.
3. Is there a description of the logic of the BT calibration process and modes? I have been experimenting a bit, and the aggressive mode seemed to get best results in shortest time, but I will need to do some more experiments on that.

I noticed several POPP settings that could influence the control:

• Algorithm scale factor: set to 1 ("quick": found to have best results in large rooms) (Does this really filter setpoint values? not entirely unheard of but new to me).
• Load balancing enable: False (disabled): I am not sure if BT actually can handle this, presumably not. Tried it but found no effect.
• Load room mean: for load balancing purposes so Undefined

BT settings that could be useful:

• Sort of calibration to use: Target Temperature Based (only option available)
• Calibration Mode: aggressive

Steps to Reproduce

This can actually be reproduced, however the roles can be (randomly??) changed and if the large radiator rushes to target and the tiny radiator lags behind it is much harder to detect. Measured room temperature (external sensor) reaches setpoint well within an hour then.

Versions

Hardware is a Raspberry rpi4-64 with SSD
HA:

• Core 2024.12.5

• Supervisor 2024.12.0

• Operating System 14.1

• Frontend 20241127.8

• BT version 1.7.0-beta1

Additional Information

Zigbee connections are stable, I have not noticed LQI values lower than 120.

[folfy]

Regarding 1)
It looks like you set different calibration modes in BT for the different TRVs, but without actual logs or diagnostic data, it's not possible to prove or analyze anything.

You should enable debug logging for the integration, and then once the issue occurs again, upload those logs. Without any more logs, it's not possible to analyze the issue unfortunately.

Regarding 2) Is there a description of the logic and the parameters of the POPP devices?
Idk, you'd have to ask that at the vendor or somewhere related to those devices. This is an integration for controlling TRVs, you can try your luck with asking for such info in the discussions page maybe, but I don't think it makes sense. This is the first time I'm reading about "POPP" devices (here, or anywhere around).

Regarding 3) Is there a description of the logic of the BT calibration process and modes?
Unfortunately not rly besides the source code. I find most of them rly odd in what they're actually doing, and while I'd wanna document them, first I have to get the originators intention, because some modes/things rly don't make sense in my view. Plus I'm waiting for even basic fixes to be merged still, so not gonna pile up more work/PRs for now, till at least the existing backlog is reviewed pulled...

[Hapi-D]

Thanks for your message,
Re (1) definitely the same calibration modes and settings for both TRVs. I checked several times. Different parameters was my first thought as well.
Will try the logging.

Re(2) Popp devices are the same as Danfoss TRVs. I don't know which of the two is the original. They gave me an overview remarkably similar to the one in the Z@M exposed overview.

Re(3) <> and <> .. oh dear .. I get the message.. I hope the originator is still within reach. Would you mind if I had a peek in the code? Only promise I'll make is that I'll not change anything.

[folfy]

All the code is public here, you just have to search for it - https://github.com/KartoffelToby/better_thermostat/blob/master/custom_components/better_thermostat/calibration.py

In BT v1.7.0b2 the diagnostic data download is working again (but the offset calibration is broken, which you don't use anyway, so shouldn't be an issue for you) - Please provide this and debug logs for any further analysis, or we will have to close this issue.

diagnostic data
IMPORTANT:
Download and paste the diagnostic data from your Better Thermostat Entity(s) below.
https://www.home-assistant.io/docs/configuration/troubleshooting/#download-diagnostics

debug log
Depending on how complicated you issue is, it might be necessary to enable debug logging for BT,
reproduce the issue, and then upload this logfile here.
https://www.home-assistant.io/docs/configuration/troubleshooting/#enabling-debug-logging

[Hapi-D]

Working on this, reproducing it is more of a problem than I initially thought. Would leaving debug logging running for several days be a problem?

[folfy]

Not rly an issue, like at least BT shouldn't generate that many messages. It depends a lot on how many entities you got and how often they change. If you wanna be sure, you can turn it off and on after a while, and see how big the log is, but it rly should be fine.