Great to hear, thanks!
in english:
Hello,
I noticed that my port and window sensors display no contact, (see photo) when there is contact, (see photo in the sensor parameters) is it possible to correct the term?
Thank you
Yes I know, but my problem is the indication of state that does not correspond to truth,
Have you tried doing a Repair on the contact sensor? If that doesn’t work have you tried deleting the device and doing a factory reset, then re-adding it?
I have many of these contact sensors on most of my windows and doors and they work flawlessly. Do you have enough mains powered Zigbee router devices near by, to ensure the contact sensor has a good connection?
No, none of that, my sensors work very well, it’s just the state that’s not good
I’m sorry I must be missing something. It’s not that you want to invert the status. And you haven’t tried any steps to troubleshoot the sensor because it works very well. What exactly is the problem with it, because I don’t understand?
I think you might be confusing both notifications:
- The notification on the device tile (aucun contact / no contact) means that the contact sensor’s magnet is not making contact with the sensor. Or in other words: the door/window is open.
- The notification on the Capabilities tab in the device tile, indicates whether the contact alarm is going off. That is the case (as the door/window is open), hence it indicates Oui / Yes.
So both say the same, but due to the chosen wordings it might be confusing.
In a prior version of the Homey app, the notification on the device tile used similar wordings as in the Capabilities tab (‘contact alarm’), but Athom changed that.
Hello,
Yes I agree, the concern comes from the wording, that is my concern. I hope that a next update will correct CA.
Thank you both for answering
So far so good. Thank you so much for working on the FP300 wake state issues. I’m not sure if this is one of the issues or not (anymore, at least), but another Zigbee mode user reported to me that his issues occurred with the climate sensors, but with those features disabled, the sensors reported presence accurately (perhaps he has logs for that data).
For me, they’ve been working flawlessly since this update, so you have my thanks. I’m looking forward to more sensors being supported in future updates. Any plans for the FP2?
Hi @TedTolboom
I am experiencing a recurring communication problem with Aqara radiator thermostats E1 connected to Homey Pro 2019.
The thermostats work normally for some time, but after an unpredictable interval one or more of them becomes partially unresponsive. The most important detail is that communication becomes one-way:
- Changes made directly on the physical thermostat are received by Homey. The new temperature and state appear correctly in the Homey mobile app and web interface.
- Changes made from Homey do not reach the thermostat. The target temperature can be changed in the Homey interface, but the physical thermostat does not change.
- Homey eventually reports a timeout, typically 30 seconds in the app.
The issue has occurred with the kitchen, bedroom, and living-room thermostats. It is not limited to one specific device.
The most effective recovery method is physical interaction with the affected thermostat. I usually have to change the target temperature several times directly on the thermostat, often across a wider temperature range. I also change the thermostat mode from Manual to Away and then back to Manual. After several such changes, the thermostat usually starts accepting commands from Homey again and bidirectional communication is restored.
If this does not help, I open the device-pairing procedure in the Aqara/Homey app and put the affected thermostat into pairing mode without first removing it from the app. Homey then often reports that the device already exists in the household or recognizes it as the existing device. After this rejoin/reconnection, communication usually starts working again. In one case, however, the thermostat had to be completely removed and paired again, which resulted in a new Homey device ID.
Sometimes an Extended Interview also restores communication, although this is not consistent.
The following actions do not reliably resolve the problem:
- restarting the Aqara/Homey app;
- restarting HomeyScript;
- restarting Homey;
- changing the target temperature repeatedly from the Homey app;
- restarting the Wi-Fi network.
The thermostats remain powered, have sufficient battery level, and are not reporting an open window. The problem appears to be related to the communication/session state of the Aqara thermostat or the handling of sleepy/end devices, rather than to the thermostat settings themselves.
Environment:
- Homey Pro 2019
- Homey firmware 13.5.1
- Aqara/Homey app version 1.17
- dedicated 2.4 GHz IoT Wi-Fi network
- multiple Aqara radiator thermostats
I have also experienced Homey command timeouts during scheduled temperature changes. Sometimes one thermostat is updated successfully, then the next command times out and the remaining thermostats are not updated.
Diagnostic report ID: e7f02d30-bb50-4fcd-88e7-2ec9b25ecf4a
Could the youplease investigate whether the app correctly recovers the command channel after an Aqara thermostat enters a sleeping, stale, or partially rejoined state? In particular, please check the difference between receiving state updates from the thermostat and sending target-temperature or mode commands to it.
It would also be useful to know whether there is a recommended recovery procedure that does not require repeatedly changing settings physically or re-pairing the thermostat.
Thank you for any recommendation
Spoke too soon! The FP300 sensors are getting stuck in the “detection” state again. Everything updated to current software/firmware, paired directly to the Homey Pro (2026) via Zigbee.
The only fix is restarting your app and then restarting the sensors periodically.
Let me know if you need anything from me to diagnose.
I have an FP400 since a couple of days, and I was able to connect it through matter over thread (first with Aqara app to create the zones). While the zones are visible in the FP400 device in Homey (with different random names), I cannot create any separate flows from these zones. Is this a known problem, or is there any way I can start flows for specific zones?
As you add this sensor (which is not currently in the list of supported devices for this app) via Matter, it’s capabilities have no involvement with this app, it is the device itself and the Matter controller of Homey that negotiates what it can and can’t do.
The developer of this app won’t be able to change that (or at least until this sensor is added to apps Zigbee devices) You might want to try the Aqara forum for Matter and sensor functionality.
version 1.18.0 has been uploaded to the app store, pending Athom’s release
Changelog:
- Add support for the Floor Heating Thermostat W500 (UT-A01D) and the Smart Radiator Thermostat W600 (WT-A03D) in both Zigbee and Matter device protocols.
- Improve communication with the Thermostat radiator valve E1 ( @Petr_Petlach let me know if this resolves your issue)
- Improve handling of the scene button presses ( @Christopher1 let me know if this resolves your issue)
Note: setting an external temperature is implemented for the Aqara Thermostat Radiator valve W600. For the Aqara Floor Heating Thermostat W500 this feature is still disabled and will be implemented as soon as possible.
The thing is that the zones are being depicted, I just cannot start a flow from a specific zone. So Homey does not display separate flow triggers for the separate zones. Just an “overall” occupancy trigger for any zone without being able to distinguish between the zones.
I thought the idea of Matter was to have everything compatible regardless of the platform 
That’s the theory… not the practice.
In practice Matter is more just about making things compatible with other ecosystems… but manufacturers like to try and keep the best features to their own ecosystem to entice you to buy more of their ecosystem products.
If/when the FP400 makes its way in to this Homey Aqara app with the Zigbee protocol support, then you should be able to access all its features, including zone triggers.
It’s a bit of a pipe dream, but maybe one day in the distant future Matter will become the universal protocol it’s meant to be… but I wouldn’t hold one’s breath 
The W600 Radiator Thermostat device works a treat… thank you so very much for this, so pleased it’s working now. For now using it in Matter o/ Thread mode and then shared with my Aqara M3 hub. I will probably also try the Zigbee version when I get some more TRVs (which I will now this is working 
)
Greatly appreciated, thank you!
Standardized protocol were also the basis for the Z-wave and Zigbee protocols, as is now also the intention for the Matter protocol. Yet, specifically with the occupancy devices providing also position / area indication, you’re running into the limits of a standardized protocol…
The Homey app UI currently has a limitation to (graphically) show a floor plan / area plot to be able to use to depict specific areas for the FP400 to trigger local occupancy for… Athom is aware of this limitation and working on a solution.
To manage expectations, not all information/capabilities of the FP400 is available on all protocols, as described at their website.
Also to for the W600 Radiator Thermostat you see in practice the (limited) standardized implementation when using matter (thermostat_mode and thermostat_setpoint capabilities) in comparison with using the (extended manufacturer specific) Zigbee implementation (next to the standard thermostat capabilities also thermostat_presets (with corresponding setpoints) and setting an external temperature value are implemented.
