Hello. Actually, I initially tried a similar solution. However, I noticed some issues when I didn’t disable the internal sensor on the Sonoff TRV itself. For example, the temperature readings were highly unstable. Let’s say the room was 23°C, the sensor would show 23.4°C at one moment, then drop to 22.8°C, and later record something like 23.3°C. In short, the readings weren’t consistent. How can you manually assign a stable value to an external sensor when the readings fluctuate like this? For instance, the offset value can go from -2.3 to +2 in a short period of time. In my opinion, at least for me, the most reliable method is to disable this reporting and use automation instead.
I have a problem with sonoff trv (zigbeetoMQTT) using better thermostat, if the temperature drops with 0.1 degrees the trv starts heating until the set temperature is reached meaning for 0.1 degrees, how can i change the tolerance to 0.5, the tolerance setting in better thermostat seems not to work. thanks
The reason for this is that the values created by the Better Thermostat do not affect the actual main valve, which is the MQTT valve. In other words, you set the tolerance value in Better, but it does not impact the actual valve in MQTT. Honestly, I don’t know if there is a way to address this. Maybe it can be achieved with a complex automation as well.
Thanks for the answer, that is really not so god news for me. But anyone has the same problem? O jut i see it as a problem? Also i am not able to disable all the reporting
How to disable these too?
Thanks for this overview, very helpful. I took a different approach using automations. I set up two for each TRV, one for high temp and one for low temp using an external zigbee thermometer as the trigger. I set the hvac mode to on/off (high/low). This worked fine. I then tried to manually set (within zigbee2mqtt) the degree open/close % for some finer control (i.e. i did not want the valves to total close, only 50% for example). but I could not seem to get this to work. Has anyone else manage to get the degree close % for the valves to work? Any suggestions for how to test them, I tried to manually set the values but nothing seems to change with the valves. I would expect (for example) if the valve is closed, and degree is set to 100. If I then change the degree closed to say 50% the valve would then open to half way, but all my tests nothing seems to happen when I play with this attribute. I have the latest firmware so this should not be an issues. I was thinking/hoping to adjusting that value (degree open/close) directly but I think I could live with on/off with the % on/off being fixed if I could get it to work.
Thanks,
Pete.
Ok. so I am going to reply to my own post as I have had a bit of a break through. Here are my observations.
If the local temperature (i.e. TRV temp) is 20c, occupied heating setpoint is set to 30c with heating mode set to “heat”. I can then adjust the valve open degree and hear the valve changing. If the set point is below the local temperature changing the open degree has no effect.
If the local temperature (i.e. TRV temp) is 20c, occupied heating setpoint is set to 15c with heating mode set to “off”. I can then adjust the valve close degree and hear the valve changing. If the set point is above the local temperature changing the close degree has no effect.
It appears there is some interrelationship between the temperature set point, local temperature and the ability to change/adjust the open/close degree. I’m guessing this make sense is you are using the local/temperature and set point.
So, it appears if I want to have this fine control in my automations I will need to change the set point temperature on close/open to be above or below temperature as appropriate then i can adjust the close/open degree.
As mentioned above. Being able to exchange the local provided temperature for an external temperature (i.e. provided by a zigbee thermometer) would be great additional functionality.
Yet another reply to my own post. It appears the “temperature” entity is not the set point temperature but the calibration temperature. Very odd to have this exposed and an entity but not the set point temperature. I will look into updating the zigbee2mqtt description file to fix this as it is available via mqtt just not as an entity with HA. in the mean time a work around is to send an mqtt message to change the set point in my automations.
.
Hello. First of all, you can set the valves to open and close at specific percentages. This can be done easily with an automation since the valves appear as entities. However, instead of dealing with complex automations, I have a simpler suggestion for you.
For instance, in the example automation I shared, I divided the day into two parts. From 8:00 AM to 6:00 PM, I set different degrees, and from 6:00 PM to 11:30 PM, I set another degree. You could create an automation that, for example, adjusts the valve’s closing position to a specific percentage (like 50%) after 6:00 PM. Then, at 11:30 PM, the automation could turn itself off.
This way, in the evenings, when the setpoint is reached, the valves won’t close completely, preventing the room from cooling down quickly again.
The temperature part, as you mentioned, is the section where calibration is performed. Setpoints, on the other hand, are directly controlled via thermostat cards or service calls. These are entirely different things.
As I also mentioned in my text, unfortunately, the temperature value for Sonoff TRVs is extremely unstable. It does not remain at a constant value, which causes incorrect readings when manual calibration is performed.
You can change the set temperature values via MQTT messages, and you can also create actions. I preferred the action part.
Thanks for the feedback. Yep, I went with the mqtt approach for low and high temp. I leave the mode to heat. When my room thermostat goes over a certain value I reduce the setpoint temp low (10c) and when room thermostat drops below a certain temperature increase the setpoint (30c). When the automation runs I see the setpoint value change and the state change idle/heat. I’ll play around with the valve degree values for further fine tuning over the next few days.
mqtt action…
Topic:
zigbee2mqtt/TRV Bathroom/set
payload:
{“occupied_heating_setpoint”: 10}
It’s odd that the calibration temperature is exposed as an entity but the setpoint temperature is not, not sure if that is an oversight or if there is a technical reason for this situation.
Getting
z2m: Request 'zigbee2mqtt/bridge/request/device/configure_reporting' failed with error: 'Bind 0x0ceff6fffe6799d4/1 msTemperatureMeasurement from '0x00124b001ccdfe83/1' failed (AREQ - ZDO - bindRsp after 10000ms)'
when I try to modify any reporting intervals for my SNZB-02Ds.
Update: Fixed by re-connecting the sensors.
Update. My method for using an external thermometer with TRVZB seems to be working well so far.
Recap:
set mode to heat
Create automation triggered by max temperature required in room
action mqtt:
Topic:
zigbee2mqtt/TRV Bathroom/set
payload:
{“occupied_heating_setpoint”: 10}
Similar for the low temp. But set heating temp to something like 30c
I have also adjusted the open/close degree for finer control.
I see on the official Sonoff website for these devices it says
You can select a SONOFF Zigbee temp. sensor as the external sensor
Anyone know if this capability will be added to HA/zigbee2mqtt?
There may be certain reasons why the reporting feature of your device cannot be disabled. Below are potential causes and solutions based on my experience:
- USB Dongle Issue:
The problem might be related to the USB dongle you are using. I managed to disable this reporting feature successfully with a Sonoff Dongle Plus. - Firmware Updates:
Ensure that all your devices are running the latest firmware. Outdated firmware can cause unexpected issues. - Device-Specific Issues:
There might be a problem specific to the device itself, affecting its behavior. - Coordinator Limitations:
Check if the Zigbee coordinator you are using is nearing its capacity limit. Overloading the coordinator can lead to performance issues.
Maybe in a future update but not for now.
Hi Berkan,
Great work! I am trying to replicate this for my sonoff TRV and aquara room sensors. I am having difficulty with your automation for updating the TRV offset. and wondered if you could possibly review my code please?
First time for me writing such automations with MQTT
I get the error
Error: ValueError: Template error: float got invalid input 'unknown' when rendering template '{{ states('number.0x08ddebfffea87a36_local_temperature_calibration') | float }}' but no default was specified
Here is my code (slightly different format to yours as enforced by my HA)
alias: TRV UPdate Master Bed
description: ""
trigger:
- platform: state
entity_id:
- climate.master_bedroom_bed_trv
attribute: current_temperature
- platform: state
entity_id:
- sensor.master_bedroom_aquara_temperature
condition:
- condition: template
value_template: >
{{ state_attr('climate.master_bedroom_bed_trv', 'current_temperature') |
float != states('sensor.master_bedroom_aquara_temperature') | float }}
action:
- variables:
trvtemp: >-
{{ state_attr('climate.master_bedroom_bed_trv', 'current_temperature') |
float }}
trvcalib: >-
{{ states('number.0x08ddebfffea87a36_local_temperature_calibration') |
float }}
roomtemp: "{{ states('sensor.master_bedroom_aquara_temperature') | float }}"
calibration: "{{ (trvcalib - (trvtemp - roomtemp)) | round(2) }}"
vpayload: |
{
"local_temperature_calibration": {{ calibration }}
}
- service: mqtt.publish
metadata: {}
data:
qos: 0
retain: false
topic: zigbee2mqtt/0x08ddebfffea87a36/set
payload: "{{ vpayload }}"
mode: single
I’ve pasted the same question to AI, and got this reply:
actions:
- variables:
trvtemp: "{{ state_attr('climate.stiralnia_trv', 'current_temperature') | float(0) }}"
trvcalib: >-
{{ states('number.0x08ddebfffea9946c_local_temperature_calibration') | float(0) }}
roomtemp: "{{ states('sensor.stiralnia_sensor_temperature') | float(0) }}"
calibration: "{{ (trvcalib - (trvtemp - roomtemp)) | round(2) }}"
By adding | float(0) to each template, you ensure that if the value is ‘unknown’, it will default to 0 instead of causing an error
This is awesome! Thank you so much.
I now have this largely working, although the temperature reporting from the TRV seems to fluctuate. If i view the sensor value on my dashboard it flicks between 23.5 (which is the temp the TRV will be reading) and 20 (which is the temp my external sensor is writing back. I can see this too under Z2M for the TRV under the exposes tab. The offset keps moving and changing.
Is this expected behaviour? I have turned off local temperature reporting under the reporting tab of Z2M for the TRV.
Many Thanks
Mike
Room temperatures do not fluctuate sharply between values like 20 and 23 degrees. It’s likely that your TRV is still trying to read from its built-in thermometer. Are you sure you’ve completely disabled it in the reporting section? To test this, first disable it in the reporting section and avoid running the automation immediately. Instead, observe the calibration value on the expose page for a while. Once you’re certain that the value remains stable, then you can run the automation.
intresting reading!
@berkans: as i am running a heatpump i am seeking just a possibility to open or close the valve on my sonoff trv - no need for anything in between ON and OFF. i am going with the climate-entity to set it to OFF and HEAT … is this correct or can i set the valve-opening directly?
Hi,
I’m looking for the best way to regulate the temperature using this valve.
Currently, I use the valve in “Heating” mode. Node-RED sends the desired value with this parameter “occupied_heating_setpoint”, but the valve operates in a fully open or fully closed state, which is not very efficient.
Has anyone tested or explored the possibility of regulating the progressive opening of the valve using the valve_closing_degree parameter?
With an external regulator and either the TRVZB probe or an external probe, could this parameter be used to progressively open the valve to achieve the desired setpoint temperature?