Customise auto-discovered devices? Multi-TRV/ call-to-heat automation

Configuration
1

Relatively new to HA, but not to home automation (i.e. happy to get my hands dirty with code etc).

I’m trying to figure out how to setup multi-zone/ TRV heating so that I can:

  • Use Zigbee TRVs to ‘call for heat’ based on an individual room’s need (vs one room representing an entire floor worth of demand)
  • Schedule/ perform automations to temperature changes on a per floor/ group, or an individual room basis (i.e. Top Floor bedrooms set low during the day and higher in the evening, Ground Floor set higher in the day and low at night, middle floor needs some per-room granularity due to working from home!)

I’ve been working through the following thread, which gets me some of the way there, but I feel like I’m creating a load of per-room virtual thermostat devices that I ‘already have’… bar one issue, the auto detected TRV climate entities/ detected thermostats don’t have a ‘heater’ configuration variable, so cannot be used to ‘call for heat’ as part of a group.

That said, I can see that a virtual thermostat will be useful or groups of TRVs where I want setpoint temperatures to be the same.

In terms of what I am working with, I have:

  • Three heating zones, each with a Beca Wi-Fi Thermostat (running fashberg/WThermostatBeca), that control heating demand on a per-floor basis.
  • Zigbee TRVs, connected to HA via zigbee2mqtt

All devices are in HA, using Auto-Discovery features of their respective firmware/ services.

I’ll add that I’m planning to put a Tasmotized Shelly1 in parallel to the thermostats to enable ‘call for heat’ as there is no relay override control available for the thermostats (only target vs actual based relay trigger). I guess I could MacGyver an automation to increase Setpoint, but that feels wrong!.

So I’m wondering, am I able to extend/ modify HA discovered devices from within HA? The ‘easiest’ solution I can think of is modifying the TRV entities to include a ‘heater’ configuration variable and call an MQTT switch which I use to drive the Shelly (or other automation). I could then track individual or groups of TRVs and use the group status to call for heat.

If anyone has gone about this another way, I’m all ears - thanks in advance.

2

I guess by “‘heater’ configuration variable” you mean state within the climate entity indicating that it’s demanding heat?

ZWave TRVs that I’m familiar with show ‘Idle’, ‘Heat’ or ‘Off’ in Lovelace, but annoyingly the underlying state value is (respectively) heat, heat, off. So you can’t determine if the TRV needs heat that way. Adding an idle state would be a useful improvement to climate entities and would give you what you need.

But for now, we have to do some maths. If you do it by comparing set point and temperature then you’re doing the same maths as a generic_thermostat so you may as well use that - it’s a wonderfully flexible entity.

Many TRVs also report valve position, so you could instead create (per TRV) a template binary_sensor which is ON iff the valve position is above, for example, 5%.

The usual caveat with valve position monitoring is that reports from devices with proper PID control would be more frequent than temperature reports during steady-state so battery life would suffer.

But however you get the ‘demand’ input, as you say, you still have to deal with the 3 zone thermostats. Do others in the household use the Beca thermostat UI? If so you’ve got the “smart-bulb/dumb-switch” problem to solve too.

I guess I could MacGyver an automation to increase Setpoint, but that feels wrong!.

It’s precisely what I did initially with one of our boiler (heater) thermostats. Unlike yours the link to the heater relay can be disabled so now it simply acts as temperature sensor for the room it happens to be mounted in (and was added to a min_max sensor group as I described in the other thread). It no longer directly controls the boiler.

Sticking an MQTT switch in parallel sounds like a straight-forward solution. Somehow disconnecting the Beca thermostats sounds even better though.

3

Thanks for your reply @markferry

But for now, we have to do some maths. If you do it by comparing set point and temperature then you’re doing the same maths as a generic_thermostat so you may as well use that - it’s a wonderfully flexible entity.

Yep, to be fair the virtual ‘generic thermostat’ working well for this purpose, I guess I’ll just have to abstract the complexities of virtual vs physical or ‘real’ thermostats away from the wife and kids via the UI!

But however you get the ‘demand’ input, as you say, you still have to deal with the 3 zone thermostats. Do others in the household use the Beca thermostat UI? If so you’ve got the “smart-bulb/dumb-switch” problem to solve too.

So the Beca devices are ‘smart’, running an MQTT capable custom firmware with HA auto discovery. For the luddites that visit (in-laws for example) I’m hoping to keep these working as a means to control the heating: using automations to take setpoint changes (that HA will see) and update the state on some/ all of the TRVs on the floor in question.

My issue I fear will be a potential automation loop where:

  1. Take state changes on the virtual thermostat and apply them to the physical thermostats/ TRVs
  2. Take state changes on the physical thermostats/ TRVs and apply them to the virtual thermostat
  3. (repeat as the automations will constantly be triggering each other!)

Time to look at whether/ how I can use if then else to stop the potential looping.

Sticking an MQTT switch in parallel sounds like a straight-forward solution. Somehow disconnecting the Beca thermostats sounds even better though.

Agreed, and if necessary this is really easy, per your suggestion I could also use the Beca devices as a sensor for ambient temperature in the relevant rooms. Ideally though I’d like to keep them in play, just to increase usability/ simplicity - albeit they are not an essential or even necessary part of the heating setup.

I could also use the Beca as the ‘switch’ input on a Shelly1 (it’s a 240v wall stat), that way there is a physical override/ relay control in the event of an issue with HA.

4

Ah that was the bit I was confused about.

It’s a pity the custom firmware for the Beca doesn’t provide a switch input (boost mode?).

So all three Beca stats control a single heater relay through simple parallel wiring?

And you have a choice of adding the Shelly in parallel (a “fourth input”) or in series between the heater and the Becas?

About having both per-room and per-floor setpoints, I guess you’d have:

  • a one-way setpoint sync from each Beca to a “group of virtual thermostats” on that floor.
  • a per-floor demand group providing input to the Shelly
  • a per-room switch in Lovelace which “locks” that room’s virtual thermostat from per-floor updates (simple condition in the automation)

I don’t think HA will resend a setpoint command for the same value. I’ve never seen a setpoint update loop between my real and virtual thermostats - though that may well be down to the operation of the zwave integration.

l have seen the ones with local control get out of sync (virtual thermostat no longer reflects what the real thermostat setpoint changed to) - but it’s rare for local and remote control to be happening at the same time.

5

It’s a pity the custom firmware for the Beca doesn’t provide a switch input (boost mode?).

Agreed - this would make this much easier/ would avoid the need for an additional Wi-Fi relay. At this point in time there is no boost mode/ relay control in the firmware - I have a feature request in, but think it may be a limitation of the device itself (need for a hardware mod) vs a firmware limitation.

So all three Beca stats control a single heater relay through simple parallel wiring?

Each thermostat controls a different motorized valve, which in turn calls for heat/ isolates the flow of hot water to the specific floor (or zone): each floor can call for heat without sending hot water to the other floors (unless they too are requesting it).

And you have a choice of adding the Shelly in parallel (a “fourth input”) or in series between the heater and the Becas?

I can put a Shelly1 behind each Thermostat, either:

  • With the Thermostat as the ‘Switch’ input on the Shelly1, with only the Shelly1 being able to send the call for heat/ activate the motorized valve. This is better, or perhaps more resilient (imo!) than wiring truly in-series, in that the relay activation/ trigger is built-in to the firmware, not something I have to build in to /rely on HA for.
  • Or, with the Thermostat in parallel to the Shelly, with either the thermostat or Shelly being able to send the call for heat/ activate the motorized valve.

About having both per-room and per-floor setpoints, I guess you’d have:

  • a one-way setpoint sync from each Beca to a “group of virtual thermostats” on that floor.
  • a per-floor demand group providing input to the Shelly
  • a per-room switch in Lovelace which “locks” that room’s virtual thermostat from per-floor updates (simple condition in the automation)

:+1: I can see that would work, and enable the freedom to isolate specific rooms. I’ll look to build this out for one of the floors and test.

I don’t think HA will resend a setpoint command for the same value. I’ve never seen a setpoint update loop between my real and virtual thermostats - though that may well be down to the operation of the zwave integration.

Sounds promising - I’m going to give it a go later tonight and will update my findings here!

What I really want to avoid is the Beca being set higher than its local TRV, effectively calling for heat indefinitely as the TRV in the room with the wall thermostat will prohibit the ambient temperature reaching setpoint/ target !

6

So I definitely end up in a ‘loop’ scenario with the following automations -

  1. Syncs TRV setpoint with changes to virtual thermostat
  2. Syncs virtual thermostat with changes to TRV
- id: "Girls Bedroom vThermostat Sync with TRV"
  alias: "Girls Bedroom vThermostat Sync with TRV"
  trigger:
    - platform: state
      entity_id: climate.girlsbedroom_vthermostat
  action:
    - service: climate.set_temperature
      data_template:
        entity_id: climate.moes_hy368_2_climate
        temperature: '{{ trigger.to_state.attributes.temperature }}'

- id: "Girls Bedroom TRV Sync with vThermostat"
  alias: "Girls Bedroom TRV Sync with vThermostat"
  trigger:
    - platform: state
      entity_id: climate.moes_hy368_2_climate
  action:
    - service: climate.set_temperature
      data_template:
        entity_id: climate.girlsbedroom_vthermostat
        temperature: '{{ trigger.to_state.attributes.temperature }}'

My HA logs then fill up with:

2020-10-20 22:13:00 WARNING (MainThread) [homeassistant.components.automation.girls_bedroom_trv_sync_with_vthermostat] Girls Bedroom TRV Sync with vThermostat: Already running
2020-10-20 22:13:00 WARNING (MainThread) [homeassistant.components.automation.girls_bedroom_trv_sync_with_vthermostat] Girls Bedroom TRV Sync with vThermostat: Already running
2020-10-20 22:13:00 WARNING (MainThread) [homeassistant.components.automation.girls_bedroom_trv_sync_with_vthermostat] Girls Bedroom TRV Sync with vThermostat: Already running
2020-10-20 22:13:01 WARNING (MainThread) [homeassistant.components.automation.girls_bedroom_trv_sync_with_vthermostat] Girls Bedroom TRV Sync with vThermostat: Already running
2020-10-20 22:13:01 WARNING (MainThread) [homeassistant.components.automation.girls_bedroom_trv_sync_with_vthermostat] Girls Bedroom TRV Sync with vThermostat: Already running
2020-10-20 22:13:06 WARNING (MainThread) [homeassistant.components.automation.girls_bedroom_trv_sync_with_vthermostat] Girls Bedroom TRV Sync with vThermostat: Already running
2020-10-20 22:13:12 WARNING (MainThread) [homeassistant.components.automation.girls_bedroom_trv_sync_with_vthermostat] Girls Bedroom TRV Sync with vThermostat: Already running
2020-10-20 22:13:18 WARNING (MainThread) [homeassistant.components.automation.girls_bedroom_trv_sync_with_vthermostat] Girls Bedroom TRV Sync with vThermostat: Already running
2020-10-20 22:13:18 WARNING (MainThread) [homeassistant.components.automation.girls_bedroom_trv_sync_with_vthermostat] Girls Bedroom TRV Sync with vThermostat: Already running
7

Old thread, but I’m only starting my automation now. Any particular smart TRV that you would suggest? Preferably wifi or zigbee. Thanks.