Sonoff TRVZB temperature synchronisation with external sensor

[photomoose]

Hey @Koenkk,

I've recently discovered that the Sonoff Bridge and eWeLink app make it possible to "connect" a Sonoff TRVZB with an external temperature sensor such that the internal temperature reported by the TRV matches that of the external device. This appears to be more accurate than any kind of temperature calibration setting, as the local temperature simply follows that of the external device.

From what I can tell, this synchronisation is orchestrated by the Sonoff Bridge: the external temperature sensor (SNZB-02D) advertises its temperature when it changes, which is received by the Bridge, and then the Bridge writes an attribute to the TRV with the temperature that was advertised by the external sensor, effectively updating the local temperature on the TRV.

I could quite easily expose two attributes on the TRV (there's one to enable/disable this behaviour and another to set the temperature). The question is where should the orchestration occur? It would be relatively simple to create an automation/blueprint in Home Assistant which is triggered by changes in temperature on an external device and then updates the TRV temperature. But I wonder whether this something that could also be achieved directly in Z2M? Or perhaps this "business logic" is something that falls outside the remit of Z2M and is better suited to an automation in Home Assistant?

I'd appreciate your thoughts on this.

Cheers!

[GTunney]

Hi photomoose,

I was hoping you'd pick up something like this and implement it as it will be a game changer for many I imagine.

Personally I think it should reside in Z2M, this means if I ever lose HA due to an outage the heating will remain unaffected by the outage because both temp sensor and TRV exist in Z2M.

[photomoose]

Hey @GTunney,

The more I think about it, the more I feel such logic is best suited outside of Z2M, as a HA automation perhaps. It would obviously be nice to cut out the middle man (HA) and let Z2M handle all this, but perhaps Z2M should just focus on converting Zigbee to MQTT and vice versa and not worry about application logic etc. I don't know how @Koenkk feels about this?

Furthermore, not every temperature sensor is zigbee. WiFi sensors and those hanging off ESP32s etc. may also want to set the TRV temperature. Z2M won't help here, so some sort of automation would be needed for these use cases anyway.

As it stands, I am currently running a crude automation which is effectively setting the TRV local temperature whenever the external sensor changes (within 0.5C, this depends on the reporting configuration of the external sensor). So far, so good. I will monitor it for the day and see how it goes.

[GTunney]

I suppose when it's put like that it does make sense but I thought the idea of this was to replicate what the ewelink app does and allow direct link between sonoff temp sensors and sonoff TRVs.

I use automations in HA to set the calibration offset at the moment, It's ok but does cause temp readings all over as it spikes up and down. Interested to see the difference with your automation and changing the local temp directly instead of via calibration offset.

[Koenkk]

But I wonder whether this something that could also be achieved directly in Z2M? Or perhaps this "business logic" is something that falls outside the remit of Z2M and is better suited to an automation in Home Assistant?

This logic should be done by e.g. HA indeed, exactly for the reasons you mentioned here:

Furthermore, not every temperature sensor is zigbee. WiFi sensors and those hanging off ESP32s etc. may also want to set the TRV temperature.

[EgerUS]

I was just looking to see if this option is already implemented, as the firmware already supports it for about two months ;)
I'm currently doing this by calculating the difference between the temperature measured at the valve and on the external sensor and then setting the calibration, but it still seems to be pretty unreliable.

As Koenkk writes, it would probably be better if there would be an entity to which the value could be written from HA.
The value doesn't always have to be taken from the zigbee sensor.

I hope this can be implemented as soon as possible.
Thanks for supporting these products.

[photomoose]

@EgerUS and @Koenkk: I have a working solution, I have exposed the "external sensor" entity in Z2M. I then have automations in HA which trigger on external sensor changes and then set the entity on the appropriate TRV(s). End result is that the temperature reported by the TRV remains in sync with the external sensor. I've been using it with Versatile Thermostat and it appears to be working well.

I’m currently away until Thursday but will raise a PR with the changes by the end of the week.

[srett]

Awesome, thanks for figuring this out!

[rasasak]

awesome ! I am waiting for it ! :D

and maybe ... can you publis blueprint of automations ? O:-)

[photomoose]

PR here: Koenkk/zigbee-herdsman-converters#8873

[bojanpotocnik]

I just noticed your PR, great improvement 👍

as the firmware already supports it for about two months ;)

This tells that the feature was present in the FW 1.2.1 already, and yesterday the TRVs got an update to 1.3.0, for which I cannot find the changelog. Did anyone notice any change in behavior with 1.3.0 in regards to this topic?

[photomoose]

I just noticed your PR, great improvement 👍

as the firmware already supports it for about two months ;)

This tells that the feature was present in the FW 1.2.1 already, and yesterday the TRVs got an update to 1.3.0, for which I cannot find the changelog. Did anyone notice any change in behavior with 1.3.0 in regards to this topic?

I can confirm that the external temperature sensor functionality works with firmware version 1.2.1 (half of my TRVs are still on this version).

With respect to what's new in 1.3.0, I've noticed @lcheng33775823 created this PR which looks like it introduces support for controlling the hysteresis in the TRV. At present, the TRV turns on when the temperature is 1C lower than the set point, it looks like this PR allows you to adjust that value. @lcheng33775823 was also the same guy who uploaded the 1.3.0 firmware, so I think they are related.

[bojanpotocnik]

Great to see the hysteresis being implemented! 🥳 They promised the implementation in Q1, but I got concerned yesterday after seeing this comment https://forum.ewelink.cc/t/trvzb-hysteresis/72122/38

[photomoose]

I have a working HA blueprint to control the synchronisation. I will post this to the HA forum later and provide the link here.

[photomoose]

I think it’s there in the firmware, just probably not present in the eWeLink app yet.

…

On Mon, 24 Feb 2025 at 11:19, Bojan Potočnik ***@***.***> wrote: Great to see the hysteresis being implemented! 🥳 They promised the implementation in Q1, but I got concerned yesterday after seeing this comment https://forum.ewelink.cc/t/trvzb-hysteresis/72122/38 — Reply to this email directly, view it on GitHub <#26308 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPEJFV4OX7MVBWKDG3P6Q32RL52HAVCNFSM6AAAAABW3YARWCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRZHE2TCMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kvanbiesen]

question, what happens if HA goes down? The external temperture sensor wont talk balk to the trv? What prevents the TRV for like overheating or not kicking in when freezing?

Now i am using the internal offset setting to correct the senor all the time. If HA goes down, its still more or less in order since the interal tem psensor working (with offset, better than no temp sensor at all)

[orzechszek]

question, what happens if HA goes down? The external temperture sensor wont talk balk to the trv? What prevents the TRV for like overheating or not kicking in when freezing?

I'm thinking about the same. Did you you consider implementation: when external temperature sensor data is not updated in the last X minutes, it fallbacks to internal sensor, or it's already there?

[photomoose]

question, what happens if HA goes down? The external temperture sensor wont talk balk to the trv? What prevents the TRV for like overheating or not kicking in when freezing?

Presumably, exactly the same behaviour as what would happen if the Sonoff Bridge went down. What that behaviour is, I don't know, but I could probably run some tests to see whether the TRV will revert to the internal temperature sensor.

Did you you consider implementation: when external temperature sensor data is not updated in the last X minutes, it fallbacks to internal sensor, or it's already there?

This implementation does not belong in Zigbee2MQTT - the TRV firmware is where this should live. I do not know whether such behaviour exists, however.

The same problem/concern exists when the external temperature sensor battery goes flat. I'm hoping Sonoff have thought about this.

[srett]

question, what happens if HA goes down? The external temperture sensor wont talk balk to the trv?

Hah, would be good if there is at least a hard-coded timeout, e.g. no update to the temp for 2 hours means the TRV will revert to the internal sensor. Even better if it were configurable.

[photomoose]

See my comments here regarding fall back to internal sensor when external sensor is unavailable.

[srett]

Ah thanks for the pointer. Good to know they seem to have thought of this failure mode. I assume if you start updating the external temp again, it will use that value over the interal probe again, so that's why it won't switch the sensor probe setting back to internal.

[photomoose]

@srett I've just this second posted a graph on the PR showing that your assumption holds true.