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.
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
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.
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.
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â
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?
