🔥 Advanced Heating Control

Blueprints Exchange
, ,
82

Hmm your trace shows the following:

"last_step": "action/0/else/0/else/0"

    "action/0/else/0/else/0": [
        {
          "path": "action/0/else/0/else/0",
          "timestamp": "2023-04-28T19:00:00.049615+00:00",
          "result": {
            "params": {
              "domain": "climate",
              "service": "set_temperature",
              "service_data": {
                "entity_id": [
                  "climate.ensuite_radiator_thermostat"
                ],
                "temperature": 21,
                "hvac_mode": "heat"
              },
              "target": {}
            },
            "running_script": false,
            "limit": 10
          }
        }
      ]

So in my eyes everything is fine. The climate call for setting temperature works. Do you have errors in your logs related to your climate or climate service calls?

83

I don’t have any errors in my logs.
While messing around in developer tools I’ve noticed that if I call the climate set temperature service and input both a target temperature and HVAC mode (to Heat) although I get a green check confirming the service is called, nothing happens to the set temperature on my TRV. However, if I only input a target temperature and call the same service it does update the set temperature on my TRV!

84

Interesting. I will provide you a version with seperated service calls. The differences between the individual thermostats are very confusing.

85

I split the service calls into setting hvac mode and setting temperature. Feel free to test it out and give feedback. Here is a new version.

86

I still seem to be having the same issue as before with this new version.
I’ve been playing around with calling the service via a script and it seems there needs to be a delay of a few seconds between the set_hvac_mode and set_temperature service calls for the set temperature to actually execute. Without this delay the set temperature does not execute correctly. Could this be relevant?

alias: New Script
sequence:
  - service: climate.set_hvac_mode
    data:
      hvac_mode: heat
    target:
      entity_id: climate.main_bedroom_radiator_thermostat
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: climate.set_temperature
    data:
      temperature: 20
    target:
      entity_id: climate.main_bedroom_radiator_thermostat
mode: single
87

Try this out. Could you tell me which valves and integration do you use?

88

I’m using the Siterwell _TZE200_zivfvd7h that shows up in Blakadder as houseiq Głowica termostatyczna ST GTZ02 Zigbee compatibility via ZHA. I’m testing this blueprint on two TRVs. With this latest version one of the TRVs worked as expected, the other TRV set the target temp to the comfort temp as expected but then did not set it back to the min temp later in the day as expected.
For this second TRV I can see this in the Trace:

Executed: May 2, 2023 at 4:30:06 PM
Result:
params:
  domain: climate
  service: set_temperature
  service_data:
    entity_id:
      - climate.ensuite_radiator_thermostat
    temperature: 16
  target: {}
running_script: false
limit: 10

So it looks like the automation called the TRV. The only thing that makes sense to me is that a potentially longer interval is required between the set_hvac_mode and set_temperature service calls for my TRVs. Perhaps the interval could itself be an input_number so that users can experiment and set an appropriate value for their TRV device. What do you think?

(These were the steps in the Trace before the above step)

Executed: May 2, 2023 at 4:30:00 PM
Result:
params:
  domain: climate
  service: set_hvac_mode
  service_data:
    hvac_mode: heat
    entity_id:
      - climate.ensuite_radiator_thermostat
  target:
    entity_id:
      - climate.ensuite_radiator_thermostat
running_script: false
limit: 10

Executed: May 2, 2023 at 4:30:04 PM
Result:

delay: 2 done: true
89

Yes, I could provide a version. But maybe it’s a deeper problem related to your zigbee mesh.

I had similar issues a few weeks ago. And in an earlier version I had it split into two service calls with a delay between. Sometimes the service calls didn’t had impact and sometimes I got errors like this in the log:

[0xd873:1:0x0001]: async_initialize: all attempts have failed: [DeliveryError('Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102>')

The first number was the address off device that should get the zigbee command.
So I had a look into the zigbee mesh where you can filter for the adress and every trv which did not respond correctly was connected to the same wall plug.

So I first disconnected it and switch to a plug of another brand and now the errors are gone.

Maybe you first check your log for zha delivery errors and have a look into your mesh. Maybe trvs that not respond sometimes have similar issues with the connected router.

Check your coordinator as well. Which one do you use? Maybe there is a firmware update or a recommended firmware especially for zha like for my sonoff dongle-e.

90

Thanks! Where would I look to see these logs? I’ve looked in the Home Assistant Core logs under System settings but I don’t see any errors there related to either of these TRVs.
Both of these two TRVs are connected to two different routers in my mesh, although the signal strength of both is not great.
I could run an experiment and try disconnecting both TRVs from the network and repairing to two different routers to see if that helps, what do you think?
(I’m running Home Assistant Yellow and using the built in Silicon Labs EZSP coordinator on the device.)

91

Yes, in the default home assistant log. You can filter for zha. The errors are not related to a specific device at first glance. They are very cryptic.

You can try to connect them to other routers but if they arent stupid like aqara devices, they will connect to the router that hast the strongest signal. That don’t has to be the best choice.

I would disconnect a TRV from the radiator and place it right next to the coordinator in order to connect it directly. Then test the service calls. Also disconnect the routers from power for testing. Maybe you need another repeater/router for your TRVs.

Also the 2.4Ghz wifi or bluetooth signal can interfere with the zigbee signal. If necessary, increase the distance between the router and the coordinator.
Also, wifi signals that are on the same band as your zigbee signal can cause interference. For this there are many guides to optimize Zigbee networks on the Internet

92

Sorry, I’m still new to HA and am not a developer, how exactly do I filter for ZHA, could you please explain step-by-step? All I can see is the below options:

Screenshot 2023-05-03 061810
Screenshot 2023-05-03 061810319×769 26.4 KB

I will try connecting the two TRVs to other routers and also directly to the coordinator and experiment.

To be honest, I’m not convinced signal interference is the issue. I have 96 devices connected via ZHA of which 37 devices are routers, in my 1,500 square foot home. In contrast I have only 8 wifi devices on the 2.4 ghz spectrum (I shifted most of my internet connected devices to 5 ghz spectrum only), and a similar number of BLE devices.

93

Hey, Great automation - Thanks for this. Managed to get it setup and working perfectly immediately.
It would be great if you could add an option to automatically turn off the heating based on the weather today. For example, if the weather forecast for today is Sunny and 24C then I wouldn’t want the heating to turn on in the morning while it’s still 18C as it’s going to be a nice warm day.

While writing this I figured in the interim I can just add another automation which turns off this automation based on weather, but it would be awesome to have it baked in to the same setup so everything is together.

1 Like
94

You can use the winter mode for that reason. If its on heating is activated. If its off TRVs turned off to save battery. Just create a template sensor like this:

platform: template
sensors:
  winter_mode:
    value_template: "{{ state_attr('weather.your_weather_entity','temperature') < 18  }}"

or use a helper and create a binary threshold like this. you need a sensor for your outdoor temperature for this. maybe your weather integration provide this or you can enable the entity in the entity section in your setting.

Bildschirmfoto 2023-05-03 um 09.06.41

1 Like
95

Thanks @panhans - Appreciate the quick response and a detailed one at that.

I created the template sensor as you suggested, however it turns off my heating immediately when I add it, even though it’s 8C outside at the minute. I noticed the automation itself suggests it must be a binary sensor or binary input?

Apologies, I’m still very new to HA and don’t fully understand how to change the YAML stuff yet to match those requirements above.

96

you can test the expression in the developer tools. Did you change the weather entity to yours?
On the left side you can see the result. If its below 18°C it has to be true.

image
image816×349 26.4 KB

You can also check the state of your template sensor in the developer tools. Just search for it:

image
image816×349 26.4 KB

97

Yeah the sensor itself is registering as True correctly. However the automation just turns off the heating when I add it in.

image

98

please trigger your automation. open up the trace, download it an and post it here?

99

Is this what you were after: https://controlc.com/dd9f51ea

100

Your winter mode sensor is not correct.

"winter_mode": "sensor.winter_mode"

Just binary_sensors or input_booleans are allowed.

101

I thought that may be the case, which I mentioned above. I’m not sure how to change it though as I used the code you provided earlier;

#Is It Warm Outside?
      winter_mode:
          value_template: "{{ state_attr('weather.forecast_home','temperature') < 18  }}"