Vtherm and Shelly TRV BLU valve opening values not always consistent

[JBecker32]

I sometimes see that the calculated valve opening values of Vtherm and the real valve opening of the Shelly TRV ('new' BLU variant) are different (see below from ~14:00 until I manually opened and closed the valve at ~22.00).
This is especially the case if Vtherm value is 0% (but not only then, as you can see at around 9:00). In this case the Shell TRV often (every few days) stays open and the room consequently overheats more and more.
Seems that the 'command' to the Shelly valve is only sent when the Vtherm value changes (which is not a bad idea!) and the Shelly TRV 'misses' some of these changes.
Is there anything I can do to change this?
I am atm thinking of checking (in NodeRed) if the two values are different for a certain period of time (5-10 minutes?) and then set the Shelly TRV valve value to the Vtherm value. Not sure if this would work (but why not?).

[Linus86529]

Hello @JBecker32,
I have also observed the behavior you describe with my seven ZigBee Bosch Thermostats II [+M]. I took a close look at the history of “sensor.vhkt_office_valve_open_percent” and “number.hkt_office_pi_heating_demand” over several hours. The Versatile Thermostat specifies the value for the valve opening, e.g., in “sensor.vhkt_office_valve_open_percent.” The Bosch radiator thermostat adopts the same value in “number.hkt_office_pi_heating_demand.”

When the Versatile Thermostat specifies a major change (> 20%) for the valve opening, the PI demand value usually follows the specified value immediately. After a few seconds, however, the PI demand value begins to drift away on its own. In most cases, the PI demand value returns to 0%. In some cases, however, the PI demand value remains “stuck” at the last value if the “valve open percent” value changes only very slightly (±10%). I have not yet figured out why this is the case.

Perhaps this is due to the settings I have made for my thermostats.

• Direct valve control
• Control threshold = 2°
• Opening angle entity IDs = ‘number.hkt_office_pi_heating_demand’
• Closing angle entity IDs = --- (Do not enter anything! Tip from forum posts if there are problems with 100% opening.)
• Opening threshold value = 10
• Minimum opening degree = 10
• Maximum opening degree = ---
• Maximum closing degree = 100

I thought about what I could do to counteract the “Pi demand drift” and created a simple automation. This reacts to changes in the valve values on the seven Bosch thermostats.

Using the example of the two sensors for the thermostat in the office:

As soon as the value of “sensor.vhkt_office_valve_open_percent” or “number.hkt_office_pi_heating_demand” changes for a period of 30 seconds, I overwrite the value of “number.hkt_office_pi_heating_demand” with the value of “sensor.vhkt_office_valve_open_percent”.

I only added the 30 seconds later, as I didn't want to force the servomotor in the opposite direction immediately after it had moved in one direction. It was important to me that the movement was completed before the servomotor had to move back again.

As expected, the result is positive. The valve closes at a room temperature of T_room + 0 °C (20 °C) and reopens at a room temperature of T_room - 0.1 °C (19.9 °C).

As long as there is no other option for this behavior, I will continue to run my automation.
Perhaps this is also an option in your case to keep the valve values synchronized.

Since the entire automation is quite long due to the many thermostats, I will only copy the relevant sections for the office here.

`trigger: state
entity_id:

• sensor.vhkt_office_valve_open_percent
• number.hkt_office_pi_heating_demand
  id: Office_Ventil_Werte
  for:
  hours: 0
  minutes: 0
  seconds: 30

...
...

choose:

• conditions:
  • condition: trigger
    id:
    • Office_Ventil_Werte
  • condition: state
    entity_id: switch.schedule_ht_dachzimmer_heizplan
    state:
    • "on"
      sequence:
  • alias: >-
    WENN 'pi_heating_demand' != 'valve_open_percent', DANN setze
    'pi_heating_demand' = 'valve_open_percent'
    if:
    • alias: "'valve_open_percent' != 'pi_heating_demand'"
      condition: template
      value_template: >
      {{ states('sensor.vhkt_office_valve_open_percent') | int(0) !=
      states('number.hkt_office_pi_heating_demand') | int(0) }}
      then:
    • action: number.set_value
      target:
      entity_id: number.hkt_office_pi_heating_demand
      data:
      value: "{{ states('sensor.vhkt_office_valve_open_percent') | float }}"

Here come the next thermostat ...

• conditions:
  • condition: trigger
    id:
    • Hobby_Ventil_Werte
      ...
      ...
      `
      Each red block represents a difference in valve opening values. After the automation has corrected this, an “OK” appears after each red block:

[JBecker32]

Thank you for your input.
I have to check how to do this. This is the 'script' of a HA automation, right?
If messages get lost on their way to the TRV (as it seems to be true in my case), it would be better to check the difference in fixed intervals ( and not only on changes) and correct these differences whenever they exist.
I will try this when I find some time.

PS: I can see these differences on all my Shelly TRVs. Losing messages seems to be a 'feature' of the Shelly gateway which has to be used to translate between Wifi and the TRVs special bluetooth.

PPS: at least I managed to build an automation that does what I want to do. First I defined a new sensor which holds the absolute difference of Vtherm and TRV valve position. If this value is >0 for more than 10 seconds I set the TRV valve position to Vtherm valve position. It is working and now I am curious if it solves the issue longterm.

[altruizine]

@Linus86529,

I have five of these Bosch TRVs as well, and I'm curious:

I haven't yet observed this particular quirk (unwanted pi_demand change after a few seconds). However, I did observe a similar behavior where Bosch's internal algorithm takes over 15 minutes after last receiving an update, and I use a preventive automation (force update every 10 minutes); see #1468.

Are you sure the unwanted demand updates comes just seconds after an intended regulation?

Are you publishing a remote temperature to the TRVs using VT's temp-synchronization feature? There's a related quirk that Bosch's internal sensor/algorithm may take over when the TRV receives no temperature update for 30 minutes.

Are you using Z2M or Z2A?

[Linus86529]

Hi @JBecker32,
yes, this is an automation I created in HA. I apologize that the Shellies are a bit more difficult to handle via BT. I think it will work as you expect. Keep enjoying it and good luck!