Bosch Radiator Thermostat II [+M] seems to revert to internal algorithm after 15 minutes

[altruizine]

Hi,

I'm trying to control Bosch smart radiator thermostats II [+M] (aka Bosch TRV2M) in Zigbee mode (with Zigbee2MQTT) as an over_climate-type thermostat using direct valve control. These thermostats have a heating-demand entity that I'm using for VT valve control, and a local-temperature-calibration entity I've configured as VT's offset-calibration entity. (There's also an external-temperature entity that I'm not using.)

Overall, this seems to work fine. (I have some minor trouble finding the correct TPI and valve settings as my valves [apparently, Danfoss RA-type valves] seem to have only a small range in which they are not either completely closed or completely open—but that's a different discussion.)

I'm writing because I have observed strange changes to the TRV valve positions (reported via Zigbee) that do not seem to be induced by VT. The following graph shows one TRV's valve position over about 40 hours:

I have configured the max closing degree as 85 %, so the line at 15 % is the one VT establishes when it closes the valve. Observed values at, or closer to, 0 %, or at 100 %, surely aren't set by VT.

I'm guessing that Bosch's internal algorithm takes over when it doesn't receive a new setting for some time. In the graph, the rogue settings never occur within in 15 minutes after a valid value has been set, and sometimes almost exactly after 15 minutes. (This is consistent with reports that the Bosch TRVs need continuous updates even when supplying an external temperature reading to their internal algorithm, although in that case the timeout seems to be 30 minutes before the TRV falls back to its internal temperature sensor.)

If my theory is correct, I need a way to regularly update the TRV even when parameters do not change to prevent it from reverting to its internal algorithm. Does VT have a way to do that, or is there a workaround you can recommend?

Thanks!

[jmcollin78]

Hello, please give us the entitites of your Bosch TRV. Is it not a common TRV.

Fro your concrete question there is a keep-alive feature in VTherm over_switch but not for over_climate. So I've got no solution out of the box. You will have to do a automation or look the documentation if there is an option. This behavior is really strange.

[altruizine]

Hello, please give us the entitites of your Bosch TRV. Is it not a common TRV.

Sure. Is there a preferred way to generate a list? I'm attaching a dump from Zigbee2MQTT: BOSCH-TRV2M.json.

For your concrete question there is a keep-alive feature in VTherm over_switch but not for over_climate. So I've got no solution out of the box. You will have to do a automation or look the documentation if there is an option. This behavior is really strange.

Is there a good way to attach an automation to VT so that I'm sending the underlying thermostat the correct values?

[altruizine]

I'm now using {{ state_attr("climate.foo", "vtherm_over_climate_valve").underlying_valves["number.thermostat_foo_pi_heating_demand"].last_sent_opening_value }} to set
number.thermostat_foo_pi_heating_demand every ten minutes. Is this a safe VT entity to use?

Now I worry that HA doesn't send an update to the thermostat if the value is unchanged. Is there a way to force an update to be sent?

[jmcollin78]

When the send value ({{ state_attr("climate.foo", "vtherm_over_climate_valve").underlying_valves["number.thermostat_foo_pi_heating_demand"].last_sent_opening_value }}) change, store it into a input_number and send it periodically with a timer. This seems the best way to do that (don't do loops into a automation but use timer instead).

In the Bosch mqtt entity there is some Bosch specific attributes Bosch-specific operating mode. Have you understand what is the purpose of this entity (and the others as well) ? If you are on 'schedule' maybe the TRV itself change the value.

[altruizine]

I'm now using an automation such as the following for each of the Bosch TRVs:

alias: Versatile_Thermostat_Update_Bosch_TRV_Foo
description: ""
triggers:
  - trigger: time_pattern
    minutes: /10
conditions:
  - condition: state
    entity_id: climate.versatile_thermostat_foo
    state:
      - heat
      - sleep
    attribute: hvac_mode
actions:
  - action: number.set_value
    metadata: {}
    target:
      entity_id: number.foo_pi_heating_demand
    data:
      value: >
        {{state_attr("climate.foo",
        "vtherm_over_climate_valve").underlying_valves["number.foo_pi_heating_demand"].last_sent_opening_value
        }}
mode: single

This now seems to work fine; I haven't observed any rogue settings since introducing these automations. Looks like my worry about unchanged values not getting propagated to the TRV was unfounded …?

Is there any reason to use your approach of storing changed values into an input_number helper instead of using the value directly in the automation?

In the Bosch mqtt entity there is some Bosch specific attributes Bosch-specific operating mode. Have you understand what is the purpose of this entity (and the others as well) ? If you are on 'schedule' maybe the TRV itself change the value.

My TRVs all were in manual mode. I'm not sure what changing this value would do beyond changing an indicator light on the TRV, as there is no known way to program a schedule directly on the TRV.

I do have some intuition for each of the other configurables. Is there any specific one you were wondering about?

One last question: Why are we setting the local-temperature-calibration entity despite controlling the valve directly?

Thank you for all your responses!

[altruizine]

In the Bosch mqtt entity there is some Bosch specific attributes Bosch-specific operating mode. Have you understand what is the purpose of this entity (and the others as well) ? If you are on 'schedule' maybe the TRV itself change the value.

In the meantime, I've found an incomplete Zigbee spec that Bosch has published (source). It indicates that the TRV can store a schedule on device, but does not document how exactly that would work. Zigbee2MQTT does not implement it.