[Z2M] Aqara TRV E1 link external temperature sensor

Use this blueprint the set an external temperature sensor to your Aqara E1 (SRTS-A01) TRV,

Features

  • Configures the Aqara E1 TRV to use an external temperature.
  • Every time the external temperature value changes it is send to the TRV using mqtt

Important
This Blueprint only works with the Zigbee2Mqtt integration not ZHA.

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

Screenshot

Changes

  • 01.02.2024 - updated blueprint to work with z2m version 1.35.2
  • 28.01.2024 - added optional configuration parameters to set the z2m instance name and the z2m external topic name
  • 02.11.2023 - fixed a bug after updating to the newest z2m where the wrong selector entry was chosen

Source:

5 Likes

@pavax Thank you for this work!

I installed my first Aqara E1 TRV today in Zigbee2MQTT and set it external sensor. When I browsed through forums about external sensor binding I found some remarks saying that if the TRV doesn’t receive any temperature update from external MQTT payload for longer time it revert to the internal sensor. But I also saw another remark from someone who said the TRV would just stick with the last temperature provided if no new MQTT payload is sent.

Are you familiar with this (potential) issue? If the TRV would actually do go back to the internal sensor (either because of no temperature update or other reasons of inconsistency like after e.g. a battery change) I’m wondering if additional stabilization measures should be considered in the automation like update intervals every x minutes instead of temperature change trigger. Also maybe the internal/external sensor state should be checked regularly.

Last but not least I also read through some (few) discussions about binding in Zigbee2MQTT itself instead of going the Home Assistant way which would be interesting to have continuity even when HA stops working. I eventually found this project: Anonym-tsk/zigbee2mqtt-extensions: https://www.zigbee2mqtt.io/advanced/more/user_extensions.html (github.com) . For now though I think i will go the HA way and maybe look into the native Z2M solution again at a later point in time.

As I already mentioned, I’m just asking based on third party remarks, not my own experience (yet), so my concerns might be without any substance.

Hello @Helge_K, I wouldn’t have noticed that behavior so far. But first, I’m not using the Aqara TRV for too long. And second, my external temperature sensor (a group of sensors) keeps changing quite frequently (like every 5min or so).

I did notice that when the batteries are changed, the TRV falls back to the internal value. But my blueprint takes care of that. Every time the external temperature value is changed, the blueprint also checks if the TRV is still configured to receive an external value and if not, it configures it (again) before sending the changed temperature.

I have no experience with that Z2M extension you mentioned and don’t see any benefit using that solution if you already have HA running. I’d only see a benefit if there was a way to natively bind a ZigBee temperature sensor to the trv by using the ZigBee protocol so that it also works without a coordinator.

1 Like

First of all: Thanks for a great blueprint

Can you make a version, where it is possible to add more than one TRV. i our living room we want a single Temp Sensor to send the temperature to all 3 TRVs. so instead of adding 3 blueprints for the one room, i would like to have a single one to controll the TRVs

Hi @pavax ,

thank you for your remarks.

Because the heating season hadn’t started yet in the past weeks I left my only installed E1 TRV untouched (no interactions with the device except retrieving it’s entity values) and only checked if any entity values would change from what I had set.

I observed that the device jumped back from ‘external’ to ‘internal’ after some days and I think also the ‘away preset temperature’ jumped back to 5°C automatically after some days although I had set it to a higher value.

So my observation seems to confirm the need to not only send the external temperature sensor to the device but to also to every time check if the device is still set to ‘external’. Therefore it’s great that you already reflected this in your automation.

Regarding the Z2M extension I now consider using it earlier than planned after a painful episode last week when my cable router suddenly stopped running and I had to switch to a network router device which I luckily had kept in my electronics storage. Because this router seemed to not support network name resolution well I had issues with Z2M and HA not communicating with each other and I had to switch to manual IP settings instead to restore the communication between both instances. If the temperature sensor could update the TRV temperature value within Z2M this would avoid this weak spot. I don’t plan to move all automations to Z2M but heating is one aspect where a more robust setup is important to me to avoid any unpleasant surprises. If the TRV would immediately jump back to ‘internal’ if doesn’t receive an external value e.g. for two hours or so I could live with such a predictable action. But based on my observations described in the beginning I simply don’t have the feeling that the TRV’s behaviour in this respect can be really predicted. Consequently I have the impression it’s better to put the TRV on a short leash to ensure its operations remains consistent.

Hello, I’ve a probleme with the Blue Print,

Befor it work well but since 1 week it don’t work :

The detail off the variable

Since today i have exactly the same problem.
What i noticed also is that since this morning i am running an updated Zigbee2MQTT version which now exposes one additional entity being Calibrate.

If i publish a message to mqtt setting the temperature by hand it works great.

ah thin, what message must we send manually to send the value?

Can you think is it possible to create manual automation while the problem is resolved?

Thank U

back to HA 2023.10.3 and it work

I’m trying to make a very basic automation standard HA. No luck so far.

using developer tools this is the zigbee2MQTT message to publish an external temperature reading.

service: mqtt.publish
  data:
  qos: 0
  retain: false
  topic: zigbee2mqtt/Aqara Radiator/set/sensor_temp
  payload: "22.1"

Hi there - there was a small bug in my blueprint where the wrong selector entity was selected.

More Details: This was caused due to the recent z2m version where a second selector entry (calibrate) has been introduced. The updated blueprint should now select the correct entity based on the existing of the option “external”

How to update:

  • Copy the raw content of my blueprint: z2m_aqara_trv_external_temperature.yaml · GitHub
  • search the blueprint file on your homeassistant (/config/blueprints/pavax/z2m_aqara_trv_external_temperature)
  • replace the content with the updated blueprint
  • reload automations (Hint: hit 'c' on your keyboard and search for reload automations)
2 Likes

updated to the newest version and indeed it works as before… :slightly_smiling_face:

Much appreciated.

perfect , thank you! :+1:

Thank U it work perfect !!

Thanks for the fast fix.

I knew something was up. The temperatures weren’t correctly updated and two of my Aqara went absolut mayhem, heating the room up.

Thanks for the fix, I was mildly worried when I saw my bedroom temperatures drop, but figured it might have been some update. :wink:

There really should be a more convenient way to upgrade blueprints…

Hi,

Thanks for the blueprint it works very well, but I do have a somewhat related question.

Recently I went on this kind of panic spree making sure all of my smart integrations have a proper dumb fallback and the TRVs are the last to pass this test.

Have you tested what happens if a TRV set to use external sensor loses connection to the network? I have already messaged Aqara about this, alas they did not respond yet.

I am probably gonna test this myself tonight (disconnect TRV from network > set TRV manually to higher setpoint > heat it up using hairdryer) hoping it fallbacks to internal sensor and closes the valve, but I was curious if you tested this.

This is pretty important especially in our case, because we have our own boiler controlled by esphome with opentherm shield that normally mirrors the TRV that has highest delta (setpoint - current_temp) and fallbacks to using default setpoint (17°C) and its own temp sensor. If the TRVs became “stuck” it could potentialy put a lot of strain on the system when boiler fires up and starts pumping even when we have one “overflow” radiator (towel one) that has dumb valve and is always open.

FIY somehow Aqara support has managed to fall short even of my very modest expectations.

Original support request message:

Hello,
I have recently installed a set of Aqara E1 TRVs on my radiators, connected them to external temperature sensors for better accuracy and was wondering about one thing. In case the Zigbee coordinator goes down, or any other issue occurs that causes the TRV to lose connection to the rest of the network what kind of fallback behavior can I expect from the TRVs?
Personally I would expect the TRV that loses connection to the rest of the network to fall back to operating using internal temperature sensor and last temperature setpoint allowing to change the setpoint manually by turning the controller knob. Perhaps it could also fall back to operating on the preset schedule.
Kind regards
PS: As it is not an option in following dropdowns I am using the TRVs connected to Home Assistant via zigbee2mqtt. But this is not very relevant to my question anyway since I am asking about offline behavior which is not gonna be dependant to the underlying home automation platform used.

Reply:

Hi Vojtech,
Thank you for contacting us.
I’m sorry to hear that you are having this problem. Actually, the Aqara TRV is only compatible with the Aqara hubs. It is not supported to use it in the Home Assistant.
Sincerely,
Cecilia
Aqara Technical Support

I wonder if they have some autofilter that sends generic reply whenever you mention “Home Assistant” in support request, but then why does it tak 3 days to send this “Ackchyually” garbage?