Hi all,
I am running the RaspberryMatic in my HA installation and currently I have got 5 HMIP-eTRV-2 thermostates installed in 4 rooms.
In addition I have got Xiaomi Zigbee temperature/humidity sensors in those rooms.
In general I have set up a nice multi room heating system which turns on the boiler (a TOON thermostate) as soon as any of those rooms becomes too cold. Right now the condition that needs to be met is that the (Xiaomi) temperature needs to be lower than the (HMIP) set temperature. This works well - in theory.
However, this will definitely fail in the long run because the TRVs will heat up and will have quite an offset to the Xiaomi measurements, closing the valves while still keeping the boild and pump running. The measured temperature difference between the Xiaomis and the TRVs is not constant so even setting an offset temperature (of max 3.5°C) will not work, I think.
So I had the idea to somehow use the Xiaomi measured temperature instead of the one that is measured in the TRV - just as a HMIP wall thermostate would do.
I don’t know if I started going down the correct route and would like to ask for your ideas/ input.
So far I have created a system variable in RaspberryMatic and an automation in HA which sends the Xiaomi measured temperature into this variable.
This is the code:
- id: '1650988768441'
alias: Set Office Homematic Current Temperature from Xiaomi
description: ''
trigger:
- platform: state
entity_id: sensor.office_temperature
condition: []
action:
- service: homematicip_local.set_variable_value
data_template:
entity_id: homematicip_local.homematic_ip_local
name: OfficeCurrentTemp
value: "{{states('sensor.office_temperature')|float}}"
mode: single
I read something about setting up virtual devices using CUxD. Would that be the right way?
In this case, I would aim at setting up a virtual wall thermostate, get the current value from the system variable (rather than the temperature that is measured at the TRV) and then create a group that contains the TRV and the virtual thermostat.
Or is there a more elegant way to achieve all this? Or does it just not work?
I have now created a virtual device with CUxD, following a Youtube video from “verdrahtet” where the author of the video tries to do something very similar, but with IOBROKER instead of HA.
The generic thermostat will toggle a switch or boolean.
This boolean can be used to trigger on/off your TRV (some TRVs can actually be switched on/off with a switch entity).
My TRVs can’t be switched like that so I built an automation to trigger the TRV thermostats based on what the generic thermostat is set to.
It has worked flawlessly for about a month or two now.
But they will still use their internal temperature sensors to decide when to open/ close the valve.
I am living in the Netherlands and unfortunately here it is quite common to build wodden frames around the radiators. So there will be quite some heat building up and while the room is still cold, the TRV will think it is hot enough and shut the valve.
I want to avoid this by using the external Xiaomi thermometers which are placed in the room, not close to the ratiator.
But in order to use them I need to be able to override the temperature in the TRV. Homematic also sells wall thermostats which do exactly that, but they come at 50Euros per piece. So before sinking another 200 euros I would like to try to get to a solution with my existing Xiaomi thermometers.
I have already managed to let RaspberryMatic know the temperature. Now all I need to do it somehow tell the TRV to use this, rather than their internal temperature.
Hi Hellis81,
so this is not going to work.
The issue is that the TRVs have some internal temperature measurement which controls when they open and close. And this value cannot be set with the generic thermostat. This is the problem I am trying to solve.
Within RaspberryMatic wall thermostats can do this job because they can be coupled with the TRV and then it listens to their measured and set temperatures.
The logic I have set up to turn on/off the heating based on the SET temperature at the valves and the MEASURED temperatures at the Xiaomi thermometers works. But the valve itself will just close much earlier than it should because the room temperature (measured by the external Xiaomis) is not reached yet. So the heating will still be running, trying to pump against closed valves.
Hope this explains the issue.
Maybe you can share your automation and I can then see if this can be applied to my TRVs. I am not sure if these TRVs can just be turned “on / off” with a switch. Will try to find out.
Just like every single TRV model out there.
Your’s are not in any way different.
I can’t set the temperature sensor in the TRVs either, but I can create a generic thermostat which will be the thermostat for the TRV and thus control the TRV with an external temperature sensor.
You got some nice code in the second post so just replace the entities.
Create a helper that will be the heater and add your external temperature sensor as the target sensor and try it out.
What you will get is the boolean switching on and off depending on the set temperature.
Just stop arguing and do it, this is really ridiculous.
This is not the finished product but if it’s quite apparent that you need to take baby steps.
@Hellis81 let me just understand the functionality, so generic thermostat combined with the automation switches the TRV off, if the externally measured temperature goes above the set temperature, and then on again when the temperature drops below that point? That is not really a good solution, as a valve allows to use different opening levels (1-100%), that can more granularly adjust the heating to reach the target temperature.
This is how I went about it, with the help from others, with the Danfoss Ally eTRV:
Depends completely on how you set it up.
If you want a gradual solution then use the generic thermostats target temperature + or - something and pass that to the TRVs target temp.
But for me completely on/off is the most efficient solution since I live in an apartment with central heating.
And regarding your solution.
How’s the batteries
Don’t use time pattern automations. Just don’t.
They are horrible and drain the batteries for no good reason.
If the temperature is the same this automation is just spamming the TRV with useless data.
And even if the temperature is slightly more or less that is still not a reason to send a new update to the TRV.
All that above, is what a thermostat deals with.
If there is no reason to send data, then it wont. If there is a reason to do it then it will.
As simple as that.
With a generic thermostat doing the work and just sending the commands that is necessary you will probably get about the same temperature in the room, but also don’t have to replace the batteries month.
So far each pair of AA battery has lasted 2 years, and I am expecting they will last one more year.
And they are rechargeable, so I am not really concerned in that regard. I will probably switch to floor heating before they die out on me.
What I expect, is a lot more power usage, if the motor has to go from 0 to 100% valve opening, or back down to 0%, instead of small incremental adjustments. I also expect your temperature has a higher variance rate, whereas my temperature will be more stable due to the small adjustments to valve position.
I also live at an apartment with central heating, I don’t see why that favours the more rudimental approach. As it still the gatekeeper that controls how much hot water is permitted into the radiators.
But I do agree that using timing is a weakness, and a condition could be set to only send the message if there is a change larger than perhaps 0.2 Celsius. That is good input!
My temperature has always stayed within the parameters set by the generic thermostat (that is the basic idea of it).
At one point I noticed it had dropped 0.1 degree Celsius below what it should be, but it went up again within 10 minutes.
The generic thermostat is set to keep the temperature between 21 and 21.5. So when the temperature reach 21, it opens the radiators.
Since it’s too warm for my thermostats to be on at all now I don’t have any data to display.
But the sensors on the radiators send their data to a cloud where I can compare it with my neighbours data.
Mind you that in this house there are 8 apartments of the largest size (which is what we have). The majority of apartments are either half or one third the size of our.
The bars is our usage, and the line is the average in the house.
It’s quite clear when our TRV’s was installed?
Not sure if it does that. I doubt it.
It’s not a real time system as far as I know. Right now the latest data I can access is three days old.
The reason is that we pay for the usage.
The sensors are (as far as I understand it) cumulative temperature sensors mounted on the radiators, so each time I let hot water in to the radiator it starts ticking up.
During the real winter the radiators will be on most of the time I assume (given how we had the manual radiators valves set before) so that won’t change much.
What will change is that when we leave home all will be off, and when we get sunlight to heat up a room that room will turn off.
