Sonoff TRVZB: expose external temperature sensor attributes #8873
Conversation
|
@Koenkk please do not merge yet, just discovered some improvements. |
|
@Koenkk I think this is now good for review. |
|
Thanks! |
|
Is it possible to also actually bind TRVZB with e.g. SNZB-02P? |
well yes and no, you cant really bind them. You need to sync the sensor to the TRV outside Z2M. For example by a automation/trigger in HA. The external sensor is basicly and empty text box. You can fill in the temperature that it needs to be (aka external senor or device). Cant really bind devices with zigbee. The devices have no other idea what the other devices are doing. That is the task of the hub (or HA or whatever) |
|
do we know when this will be available in Z2M? |
My understanding is that when binding Zigbee devices, the bound devices can communicate with each other without the need of the coordinator. However, when configuring an external sensor in the eWeLink app, it explicitly states that both devices have to be in reach of the Sonoff Bridge (coordinator). Furthermore, my Wireshark traces in the eWeLink/Sonoff Bridge setup show that messages are broadcast from the external sensor to the Bridge, then the Bridge sends an appropriate message to the TRV to set the local temperature. So, I am under the impression that binding is not possible. On the plus side, this does mean you can use non Zigbee temperature sensors, but you will need something to provide the synchronisation, which I have an HA blueprint for (to be published later). |
Presumably at the start of March, going by previous release cadence. |
|
Seems like this is "mildly useless" then for those who can run Home Assistant? I run Versatile Thermostat with HA in direct valve control mode, but this also means that if I lose the HA box -- well, I hope my apartment won't freeze to the point of the pipes bursting while I'm away... (it would be awesome if TRVZB devs added the condition to set valve open degree to 100% and valve closing degree to 0% as soon as the temp hit something dangerous, like 7C, to prevent everything from freezing in the winter if your HA box went down -- basically safeguarding the freeze protection from the effects of valve open/close regulators) |
There is Frost protection temperature which is exactly this, except I never tested whether it also works when the TRVZB system mode is not off. Ideally, they would also implement a timeout, e.g. if external temperature sensor data is not received in the last X minutes, fallback to internal sensor. This would prevent both cold and hot runaway in case of empty sensor battery or any other error. |
Versatile Thermostat directly twiddles the open/close degree, so the thermostat needs to figure out that if there were no commands from the coordinator for a while, or if the temps are getting dangerously low, it would need to reset the open/close degree and continue on its own. And I'm not sure if TRVZB can do this currently. |
Depends on your use case. In my case, I don't have a need for direct valve control (UK based with boiler that fires on demand - i.e. there's no continuous hot water flowing in the system whereby I need to regulate the valve. The system is either on or off - so I have an automation that tells the boiler to fire whenever any TRV calls for heat). I also use Versatile Thermostat and have previously used Better Thermostat. In the case of a non valve control setup, I believe these integrations attempt to regulate the room temperature by calculating the difference between an external temperature sensor and a user controlled set point and then they either adjust the calibration setting on the TRV or adjust the TRV set point to a value that bears no resemblance to the real temperature, and there is a discrepancy between the temperature reported by the TRV vs the external sensor. (They are obviously a bit more complicated than that, but just simplifying it here). By using the attributes exposed in this PR, there's no real need for all that trickery - the TRV believes the room temperature is as per the external sensor. Yes, I believe there is a risk that whatever is synchronising the TRV temperature (e.g. Home Assistant) could go down and the TRV will believe the room temperature is the last known temperature for an indefinite time period.... so there might be a chance of overheating/freezing here.
I have tested this and when enabled, frost protection will call for heat regardless of whether the heating mode is set to heat or off. However, I am not sure what will happen if the TRV has been configured to use an external sensor and does not receive a temperature update for a while, during which time the house starts freezing.... |
Same here. I open or close the valves by setting them to 35 or 10˚C, leaving Local temperature calibration at 0 - so if everything stops working, you can still operate the valves manually as if they were not Zigbee connected. I am afraid this is not possible if they are controlled via open/close degree. However, I have a vague memory of a comment with some trick to reset these values using manual control. I cannot find it now.
Very good point, also for Sonoff developers. Considering the Frost protection temperature is meant as a security feature, it could always be compared to |
I don't even do that, I just set them to the required room temperature and let the TRV make the decision when to turn on/off based on the value provided to it by the external temperature sensor. The only real benefit I now get out of something like Versatile/Better Thermostat is the ability to control two TRVs in a single climate entity (e.g. a room with two radiators). Although thinking about it, I might be able to achieve that with a simple automation (i.e. sync one radiator's set point to that of another radiator) and then I can just simply use the vanilla Home Assistant climate card and remove all the complex setup. |
|
I've placed one of my TRVs in the garden with the external temperature sensor functionality enabled. I've now noticed that the Sonoff cluster is returning a value of 3 for the external temperature sensor selection. At present, I've only implemented support for the following values: 0: Use internal temperature sensor I have asked Sonoff for more information about this. Perhaps this value indicates some sort of protection? When I get time later, I will pair the TRV with my Sonoff Bridge/eWeLink app and repeat the experiment to see whether the app says anything. Once I have the information, I will provide an updated PR. |
|
OK, initial findings so far... It looks like the TRV falls back to internal temperature sensor when it hasn't received an update from the external temperature sensor after a while. As you can see in the attached screenshot, the local temperature is being reported as 9.9C and the running state is in "heat" despite the external temperature sensor being last set to 19.8C a few hours ago. The temperature sensor selection value ("internal"/"external") is incorrect here as the value being reported is unsupported. I am still trying to find out what this means. I will repeat this test and also do it with eWeLink/Sonoff Bridge to see whether that tells me any more information.
|
|
Thank you for testing! Does it also allow writing the value of 3, or is the write limited to 0 or 1 only? Perhaps @lcheng33775823 might offer any insight, considering they are also adding new TRVZB attributes 🙇 |
|
Fallback to internal sensor appears to occur after 2 hours of silence from the external sensor, but reverts to external sensor as soon as the next update is received.
|
so this means that, technically, if the temperature does not change for 2hr it will fallback as if the external sensor is dead. |
If using a Zigbee external temperature sensor, then I believe the reporting settings (e.g. min rep interval / max rep interval) will ensure that a message gets broadcast within that defined time period, regardless of whether the temperature value has changed. |
but the update should be done by an automation, isn't this what was discussed? so if the value does not change, unless you trigger it also at 2hr, it will not update the setting in the TRV. |
That's a very good point. My Home Assistant blueprint (yet to be published) fires on all state changes to the external temperature sensor entity (which includes changes to the state attributes), so the automation should run whenever the |
|
Just confirmed that the eWeLink app also notifies when the external temperature sensor has been inactive for 2 hours:
Just need to figure out how to handle this in Z2M. |
|
I'm now thinking this attribute is actually a bit field, with bit 0 indicating the sensor selection. Observed behaviour so far is as follows:
If these assumptions are correct, I have no idea what the difference is between values 0x01 and 0x03 and/or why value 0x03 is needed - which might suggest my assumptions here are incorrect. I'm still waiting to hear back from Sonoff. I wonder whether @sonofftaotaoliu or @lcheng33775823 can provide any more information? |
|
I've published a blueprint which synchronises the external temperature sensor with the TRV: https://community.home-assistant.io/t/sonoff-trvzb-external-temperature-sensor-calibration/856444 |
Exposes the following attributes on the Sonoff TRVZB to allow synchronisation of temperature to an external sensor:
When enabled, the local temperature of the TRV will be set to the value of the external temperature sensor attribute and heating decisions will be made based off this value. Note that Zigbee2MQTT only exposes the attributes, it does not provide a mechanism for the synchronisation - this can be provided with an automation in Home Assistant or similar.
Valid values of the external temperature sensor value attribute range from 0C to 99.9C. Values outside of this range are silently ignored by the TRV.
Discussion around this: Koenkk/zigbee2mqtt#26308