How to prevent Aqara Smart Plug power on when "On" is pressed on a Hue Remote?

LeCaNo · January 14, 2023, 6:24pm

Hey there,

since 2023.1 I have the following issue with my Aqara Smart Plug (SP-EUC01) and my Philips Hue Dimmer Switch (RWL021)

When the Aqara Smart Plug is off and I press the “On” button on the Hue Dimmer, the Smart Plug turns on, which I don’t want.

In the past 11 months since I’m using the Aqara Smart Plug (I have Hue dimmer round about two years longer), this issue occurred at the beginning, but I had fixed it by installing newer Firmware (ZHA says Firmware: 0x00000029, which is afaik the latest. I also triggered OTA update, but no newer firmware was found or installed).

Is there a way to prevent this issue?

Thanks in advance

A few words about my system:

HAOS (9.4) VM on Proxmox
HA 2023.1.4
SONOFF Zigbee 3.0 USB Dongle Plus with Z-Stack-firmware 20220219

PineappleNectarine · January 25, 2023, 3:33pm

Had a similar problem with my aquara plugs and sonoff buttons, turns out to be a firmware problem described here which can be solved by downgrading the firmware (check bottom of first post)

github.com/zigpy/zha-device-handlers

Comment by TheJulianJES - Fix power measurement for Aqara MAEU01 plugs with newer firmware

zigpy:dev ← TheJulianJES:tjj/xiaomi_plug_fixes

FYI for anyone that is using IKEA remotes and firmware v41 on the ``MAEU01``/``S…P-EUC01`` plug: There's an issue in the v41 firmware version where the plug toggles on/off when IKEA remotes are used with their messages routed through the plug. Before https://github.com/zigpy/zha-device-handlers/pull/1706 (changes are also included in this modified quirk), the plug on v41 always toggled if an IKEA remote was used **anywhere** on the network. With those changes and v41 plugs, it'll now only happen if the messages are routed through that plug. (Again, an issue in Aqara's v41 firmware). The plug includes a rudimentary downgrade check that can be bypassed. I've successfully downgraded one of the plugs I'm testing with from v41 to v32. Be aware that you could brick your plug! Instructions for downgrading are here: https://github.com/Koenkk/zigbee2mqtt/issues/13903#issuecomment-1244720072 I'd only recommend trying the downgrade if you're running into this issue. (v32 doesn't seem to have the same issue as v41) The [quirk is now also updated](https://github.com/zigpy/zha-device-handlers/files/9552533/zha_custom_quirks.zip) to support ``maeu01`` plugs with older v32 firmware. This is done by explicitly enabling "OppleMode" now. Newer firmware versions don't have this attribute anymore and it's basically always enabled. So, the plugs send special Xiaomi attribute reports. Since this modified quirk properly works with those now, we want to enable "OppleMode" if that attribute exists. (Note: re-pairing and/or updating the custom quirk might be required in some cases when the sensors don't update)

Since I also use ZHA I then used this guide to apply the modified firmware

I had to use step 4 in the guide and I recommend using the logging configuration to be able to see the progress of the ota transfer (it took quite a while for me).
After waiting a while the plugs just kept flashing red so I repaired them and now they work great!

Mine have reported Firmware: 0x00000029 from the beginning and are still reporting the same after the modified firmware ota update, I think you have to look at “Manager zigbee device” > Clusters > Ota > current_file_version > Read attribute. 41 is the bugged one.

As to why this stopped happening for you and then came back after your update I have no clue but afaik the problem only occurs if the button is routed through the smart plug (which you can see on the network visualization) so maybe it wasn’t routed through your plug before.

LeCaNo · January 26, 2023, 6:28pm

Thank you for you reply

I have unfortunately installed FW version 41. Please excuse the stupid question, but how do I downgrade to FW version 32 within HA?

Sorry if I oversee this. There is a lot of linking to other issues. I think a simple how-to would be helpful here on the forum for many perhaps

PineappleNectarine · February 1, 2023, 1:47am

No worries, I’ll try to give a step by step rundown of how I did it for ZHA using the resources I linked above.

Make sure you really are running the SP-EUC01 (lumi.plug.maeu01) (not the square US version) and keep in mind that although mine came out fine, applying this modified firmware can brick your plug! Do this at your own risk!
Download or build the modified firmware version 32 zip from this comment https://github.com/Koenkk/zigbee2mqtt/issues/13903#issuecomment-1244720072 , the download and build instructions are collapsed (little icon).
Reason: Downgrades are normally not accepted by the plug so this modification tricks the plug into thinking this is a newer version (Just header information, if successful it will report version 32, meaning you can still “upgrade” it back to 41)
Unzip the download and upload it to a new directory inside HA, I placed my .ota file inside of the /config/zigpy_ota directory I created
Modify your configuration.yaml file to include the following:

Required: (change the otau_directory if you chose a different directory)

zha:
  zigpy_config:
    ota:
      otau_directory: /config/zigpy_ota

Optional but recommended:

logger:
  default: info
  logs:
    homeassistant.components.zha: debug
    zigpy: debug

Restart home assistant
If logging has been configured:

If you have a terminal via ssh or UI addon use cat /config/home-assistant.log | egrep 'zigpy.ota|zigpy.util|zigpy.*OTA' to check previous progress or tail -f /config/home-assistant.log | egrep 'zigpy.ota|zigpy.util|zigpy.*OTA' to tail new messages which might be related to the ota update.
If you don’t have a terminal you can check the full logs in Settings > System > Logs > Load full logs and search for “OTA” or “zigpy” but there might be a lot of unrelated messages.

If you see many lines ending in some increasing progress value the update started by itself. Skip step 7.
If the update didn’t start by itself (and mine didn’t either) see step 7.

Manually start the update for each plug: (You can keep the logs open)
7.1 Navigate to the plug and inside the Zigbee info copy the IEEE number
7.2 Issue the following command in Developer Tools > Services: (replace the ieee)

service: zha.issue_zigbee_cluster_command
data:
  ieee: 12:34:56:78:12:34:56:78
  endpoint_id: 1
  cluster_type: out
  command_type: client
  cluster_id: 25
  command: 0
  args:
    - 0
    - 100

Check the logs again, the ota update should now slowly transfer to the plug. If you didn’t enable logs wait half an hour, the transfer is pretty slow.

After the update mine started to flash red and I had to repair them again (the same way one initially pairs them) but home assistant will recognize them as your existing plugs so your automations shouldn’t be impacted.
Cleanup: Remove or comment out (#) the logging configuration if you don’t want your logs to be spammed by zha and zigpy messages. Remove or move the .ota file so HA doesn’t try to automatically update your plugs in the future since technically the .ota firmware version will always be greater than the reported firmware version.

That’s it! On the plug’s device page you can check “Manager zigbee device” > Clusters > Ota > current_file_version > Read attribute and it should now report 32

Hopefully Aqara will fix this issue in the future via some official firmware update but until then I hope my guide helps!

LeCaNo · February 2, 2023, 6:35pm

Thank you for your reply. idk what I’m doing wrong. Here my steps

Open a terminal on Linux machine (notebook with Arch Linux, if relevant)
wget https://github.com/Koenkk/zigbee2mqtt/files/9552415/OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946_modded_to_v42.ota.zip
unzip OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946_modded_to_v42.ota.zip
rm OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946_modded_to_v42.ota.zip
wget https://github.com/Koenkk/zigbee-OTA/raw/master/images/Xiaomi/OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946.ota
python3
- import pathlib
- from zigpy.ota.image import parse_ota_image
- data = pathlib.Path('OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946.ota').read_bytes() image, remaining = parse_ota_image(data)
- assert not remaining
- image.header.file_version = 42
- pathlib.Path('OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946_modded_to_v42.ota').write_bytes(image.serialize())
- exit()
Timestamp of OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946_modded_to_v42.ota changed to current time
uploaded the OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946_modded_to_v42.ota with changed timestamp via File Editor and triggerd the update

I’ve got this message via terminal

What I’m doing wrong? Thanks and sorry

PineappleNectarine · February 8, 2023, 7:00pm

Seems like your header is still version 32.

But I think you misunderstood my second instruction, you can either
A) Download the modified firmware file provided in the comment by TheJulianJES, provided you trust him
OR
B) Modify the original v32 ota file yourself.
you don’t have to do both!

Or are you trying to compare the files?
In that case I both downloaded the modded version and used the build script and both files ended up being exactly the same.

sha256sum OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946_modded_to_v42.ota 
67078519a1336af083ec3e2be050743c459e04a9b0ed72e41c58feb7d58068a9  OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946_modded_to_v42.ota

That being said your build instructions should still have produced a v42 image, was there any Python error?
If your ota file does not produce this very same sha256 hash you likely uploaded the unmodified v32 image to your ota directory

ccoreilly · October 5, 2024, 8:40pm

Just in case someone stumbled upon this (very useful) thread and faces the same issues:

I tried in vain to downgrade the firmware but kept seeing in the logs that there was no update available. I assumed the directory with the OTA was not being loaded and was right.

With HomeAssistant 2024.6.1 and thus zigpy 0.64.0, the config should look like this

zha:
  zigpy_config:
   ota:
     advanced_ota_dir: /config/zigpy_ota
     allow_advanced_ota_dir: I understand I can *destroy* my devices by enabling OTA updates from files. Some OTA updates can be mistakenly applied to the wrong device, breaking it. I am consciously using this at my own risk.

This configuration field has apparently already been deprecated in the latest zigpy version and advanced ota providers need to be configured.