They got back to me today. They believe the issue is on the app side. Please see relevant text in discussion:
Smart plug (US) lumi.plug.maus01 (ZNCZ12LM) fails to pair on Homey Pro (2026), firmware 13.5.2, Aqara & Xiaomi app 1.19.1. The plug joins and the interview completes, but pairing then fails with “Unable to connect”. Homey’s log shows the bind to endpoint 1 succeeding for clusters 0, 6, 1794 and 2820, then cluster 64704 (0xFCC0) fails with “Binding table full (status: TABLE_FULL)”, followed by “create_bindings_failed”. This happened in 11 of 11 attempts on two different plugs. It looks like the plug only accepts 4 bindings while the driver requests 5. Could the driver bind fewer clusters, or treat the 0xFCC0 bind as non-fatal?
Can someone at the forum who owns Aqara w600 reproduce the issues I have with one valve without too much inconvenience?
Should simply be to have w600 connected directly to Homey through zigbee (no Aqara Hub), use internal sensor, set to a temperature (directly at valve or in Homey) and see if it heats two degrees beyond the set temp. If you are able to reproduce I will take it further with Aqara.
Thanks for coming back with this feedback.
Strange as I tested this plug without these binding issues to occur. I will check with Athom what changed in the Zigbee core to prevent this issue moving forward.
In parallel, I will provide a solution for the smart plug (US) within the next update.
Follow-up on the E1 radiator thermostat (lumi.airrtc.agl001, firmware 0.0.0_1030 – reported as 0.0.0_0030), Homey Pro (Early 2023), Homey 13.5.2, Aqara app 1.19.1.
Symptom with the app Setpoints sent from Homey (Flow or device tile) are often not applied: the display keeps the old value and the room doesn’t heat. Changes made on the device show up in Homey immediately. Since 1.19 Homey keeps showing the commanded value and no longer syncs back to the real setpoint (with 1.18.1 it reverted at the next device report, so failures were at least visible).
What I found with a small diagnostic driver To see what happens on the wire, I paired one E1 to a minimal test driver that logs every raw ZCL frame in both directions:
Late answers. Homey’s sendFrame() often rejects after ~9 s (“device not reachable”), although the E1 picks the frame up later and answers 1–20 s after that. zigbee-clusters then has no transaction handler for the answer and replies to it with a Default Response FAILURE; the E1 retransmits its answer. A driver that relies on await writeAttributes() sees an error although the write arrived.
No status check.Cluster.writeAttributes() returns the Write Attributes Response without checking the per-attribute status records; only a Default Response with an error status throws.
How to tell that a setpoint was applied. The E1 answers SUCCESS to every write of occupiedHeatingSetpoint (0x0201/0x0012), but often does not take it: the display keeps the old value. When it does take it, it sends an attribute report of 0x0012 within ~1 s – that report is the only reliable confirmation. Reading 0x0012 back and the heartbeat (0xFCC0/0x00F7, tag 103) both return the stored value, even when the display shows the old one. What helped in my tests: when no report comes, write a slightly different value first (±0.5 °C) and then the wanted one – both were taken and reported immediately.
Time requests. The E1 reads Time cluster attributes (0x000A: 0x0002, 0x0000) about once a minute and gets FAILURE. Answering them, as Zigbee2MQTT does, stops the polling.
Reading Aqara attributes. A read of several 0xFCC0 attributes in one frame returns zeros only; single-attribute reads return the real values.
Child lock. Writing 0xFCC0/0x0277 = 1 is accepted and reads back as 1, but the device is not locked (no lock icon, knob still works). The long press on the device itself works.
The communication and processing between Homey and E1 seems to be a little buggy:
The E1 contradicts itself. It answers “accepted”, stores the new value, returns it when read back and in its status report – and still regulates to the old setpoint, which is also what the display shows. Neither Homey nor the Zigbee network can create this gap between the stored and the actually used setpoint; it happens inside the thermostat.
The child lock behaves the same way: stored, yes – effective, no.
“Nudging” works: write a different value first and then the wanted one, and the E1 takes both immediately. So it can process the command, but some internal logic decides when it actually applies it. That looks like a firmware bug, not like a lost radio command.
At the moment the E1s are running via the diagnostic app to process the heating changes. It re-sends values more often to get things done on the E1.
Thanks, for sharing. I will look into the details provided.
Do note that 1.19.2 already contains quite some changes impacting the communication for the E1 thermostat, please use that as reference.
Follow-up on the E1 radiator thermostats, and most likely the cause of the problems I reported. With thanks to @makleso6 (Maxim), who found it and agreed that I share it here.
Root cause: reused ZCL transaction sequence numbers (TSN)
The E1 – and apparently other Aqara devices – remembers roughly the last 10 TSNs. A frame with a TSN it has seen shortly before is answered with SUCCESS, but not executed (duplicate suppression). zigbee-clusters numbers frames per cluster instance and starts at 1 again after every app start. Since Homey reboots every night, the first commands of the day reuse TSNs the device has just seen – and get lost while Homey shows them as successful.
My own captures match this exactly: right after pairing, all setpoint writes were reported back immediately; after driver restarts, writes reusing TSNs 2, 6, 8, 10, 12 and 14 got SUCCESS but no setpoint report, and the display kept the old value; this morning after the nightly reboot TSN 1 and 2 failed, while TSN 3 and 4 a few minutes later worked within a second.
Fix that works for us
One outgoing TSN counter per physical device, across all its endpoints and clusters, stored before each transmission and restored after an app restart. Since then, setpoints are applied again in my diagnostic driver; I’ll report back after a few days with all four E1s.
Related points (from the same captures)
Treat a setpoint as applied only when the E1 reports 0x0201/0x0012 back. A read-back and heartbeat tag 103 both show the stored value, even when the display keeps the old one.
Homey’s sendFrame() often rejects after ~9 s although the E1 picks the frame up later and answers; zigbee-clusters then answers that late response with a Default Response FAILURE. Check the Write Attributes Response status records and don’t answer expired responses.
The E1 asks for Time cluster attributes 0x0002/0x0000 about once a minute; answering them stops that.
Child lock: writing 0xFCC0/0x0277 is accepted and reads back as 1, but only the long press on the device actually locks it.
Thanks @Jan_Z and @makleso6, very helpful. I checked it with captures of three E1s (firmware 0825, 0925, 1030) on Homey and one on an Aqara M3 hub, and could confirm the main issues:
After an app restart, the E1 answers “success” to a setpoint with a reused sequence number, but ignores it.
The E1 often answers after Homey has given up, so Homey shows “device not responding” while the change was applied.
Combined 0xFCC0 reads returned correct values here, not zeros. And remains the preferred approach as it saves communication bandwidth.
I’ll contribute to the Github issue / in contact with Athom development as well.
The next update fixes this for the E1 (and the same timeout for the W600): sequence numbers continue across restarts, there are no parallel requests or retries, and the E1’s own report confirms each change. It also adds firmware 0.0.0_1030 as an OTA update.
Child lock: I was not able to reproduce (both with or without these changes applied). Changing it from the UI, locked the devices.
Thanks @Jan_Z and @makleso6 for your contribution to spot the communication issue, below update has a containment in place, while a formal update of the Zigbee core is pending by Athom.
@SMoritz should resolve your issue. @Christopher1 looking forward to hear your experience on the H2 triggers based on this release
Aqara v1.20.0 (TEST version)
Requires Homey v13.2.0 or newer.
Check your flows
Smoke detector: the non-functional tamper and battery alarms are removed (the detector never reported them). Flows that use them need updating; for the battery, use the battery level instead (e.g. battery level drops below 20 %).
New device
Multi-State Sensor P100 (Zigbee and Matter)
Firmware updates from Homey
The latest Aqara firmware can now be installed from the device settings in Homey for:
Presence sensor FP1, FP1E and FP300
Smart radiator thermostat E1 and W600
Climate sensor W100
Smart plug EU
Note: the firmware update might end with an Update failed (Update aborted by device) error message, which is caused by the Aqara device reporting the completion with a different code which Homey is interpreting as an error. Athom is looking into this issue. Check in the device settings if the new firmware version is visible, if so you can ignore this error message, the device should be fully operational.
Fixes and improvements
LED strip T1 and Ceiling light T1M: the light scenes and effects are back, with new dimming and power-on settings.
Presence sensor FP300: more reliable communication. Active check added when the device is awake and did not cancel the presence alarm for more than 15 minutes.
Smoke detector: muting works during an alarm, smoke density in dB/m, new alarm grouping setting.
Smart plug EU: the on/off state stays in sync and new settings are added.
Smart plug US and Wall switches US: pairing no longer fails.
Thermostats E1, W500, W600 and climate sensor W100: more reliable communication and settings that follow the device.
Water leak, door and window and temperature and humidity sensors: correct state right after pairing and settings applied immediately.
Buttons and remotes: more reliable button presses, also after a remote rejoins the network.
All devices: fewer Zigbee bindings when pairing (only for newly paired devices).
Next updates will add firmware updates to more devices. Current updates are verified on test devices to not introduce breaking changes.
Thank you @TedTolboom for all your hard work and due diligence on this, it is greatly appreciated. Particularly pleased to hear the improvements with the FP300. And adding OTA firmware updates is outstanding. Many thanks
My WXKG17LM dual button E1 won’t pair anywhere in the house even though it has paired (as a useless generic Zigbee device) before. I have plenty of routers (lights, sockets, dimmers, LED drivers etc).
On 1.19.2, I got Apparaat wordt toegevoegd >> Kan geen verbinding maken. Er ging iets fout tijdens het toevoegen van het apparaat. When I changed to the test version 1.20.0 I was able to add it successfully
Hi, I seem to be having issues with my Homey discovering several of my Wireless Mini Switches (WXKG11LM), and I’m not sure if it’s issues with the app or the device. I am able to connect them with via my Hub M3 over Matter, though I would prefer to be able to connect my devices directly.
Does this mean that Aqara finally has started to share their firmware across different devices (e.g. also for water leak, door/window etc.)? That is a massive new positive development if that is the case.
Check your flows
