zha-device-handlers
zha-device-handlers copied to clipboard
zigpy
Fix power measurement for Aqara MAEU01 plugs with newer firmware
Notes
This quirk will allow for the power outage memory to be enabled with a config entity in HA with:
- https://github.com/home-assistant/core/pull/80444
This quirk will probably only work if:
- ~~the MAEU01 plug has
app_version = 41(couldn't confirm with older firmware versions) AND~~ (should work with all firmware versions now) - the coordinator sends out Xiaomi manufacturer codes when pairing (might be fixed for
maeu01with older firmware?)
This quirk (as of right now) will break power measuring in other MAEU01 plugs if:
- ~~the plug is running older firmware OR~~
- the coordinator doesn't send out Xiaomi manufacturer codes when pairing (possibly fixed?)
If anyone needs the quirk right now, you can install this as a "custom quirk". See the instructions at the bottom.
Would fix https://github.com/zigpy/zha-device-handlers/issues/1655
As of right now, the newest firmware for the MAEU01 can be found here: https://github.com/Koenkk/zigbee-OTA/pull/140 (41) Older firmware is available here: https://github.com/Koenkk/zigbee-OTA/pull/159 (32) For downgrading your firmware, refer to the "Plugs randomly toggling on/off when using IKEA remotes" section of this post.
It's possible that this also fixes an issue with MAUS01 plugs (https://github.com/zigpy/zha-device-handlers/issues/1654) where sensors aren't created because there's no default value.
Changes
- add new signatures (yes, even if the plug isn't reporting an endpoint with an AnalogInput cluster, it's there)
- Improve custom Xiaomi ElectricalMeasurementCluster:
-
- add lumi.plug.maeu01
-
- put default values for sensors
-
- switch to report voltage on
rms_voltageinstead of wrongly usedinstantaneous_voltageattribute (sensor isn't created for instantaneous voltage (and it's wrong, as we deal with AC voltage here and the sensor always reports the "max" of the sin wave)
- switch to report voltage on
-
- set ac_power_divisor to 10 and multiple power_reported value to workaround a rounding error in ZHA (initial attribute report gets correctly rounded: 100.9 => 101 but during "polling" of the fake DataCluster, it only reads 100 which causes a weird jump in graphs. Another reason we want this: it also adds one decimal point. See: for the rounding issue, see: https://github.com/zigpy/zigpy/issues/1041)
- use the custom Xiaomi ElectricalMeasurementCluster for MAEU01 plugs (previously used for MMEU01 and MAUS01 plugs)
- renamed some things
- now set OppleMode to 1 (enabled), as this sends the custom Xiaomi attribute reports on plugs with older firmware when enabled. Newer firmware versions don't have this attribute and always have this "enabled" (will require re-pairing to change "automatically" for older plugs)
- add power outage memory
- ...
TODO
- make this work without breaking power measurement older plugs paired without Xiaomi manufacturer codes/older firmware (or force everyone to update firmware?) (how to determine in which state we are?)
- ~~provide custom quirk download links~~
- ~~also get the alternative signatures of the older MMEU01 plug~~
- search ZHA for where that rounding/cutoff issue happens (currently tracking in https://github.com/zigpy/zigpy/issues/1041))
- figure out if AnalogInput cluster on endpoint 31 is used for anything (at least US plugs use it, maybe EU too. Do the US plugs, like the EU plugs, also send total consumption in the special Xiaomi message?)
- ~~It's possible that
current_summ_deliveredneeds to be polled, as it doesn't seem to update (Reference: https://github.com/zigpy/zha-device-handlers/pull/1211)~~ - ~~check if we still need to write
OppleModeto0.1might be better? (default forMMEU01plugs with older firmware. For those, this quirk seems to work fine with both.OppleModeseems to be removed on newer firmware versions).~~ Edit: We wantOppleModeset to1if it exists, so special Xiaomi attribute reports are sent - ~~figure out if https://github.com/Koenkk/zigbee2mqtt/issues/13903 can be solved. (IKEA remotes routing through these plugs trigger toggle)~~ Edit: by downgrading firmware (refer to the "Plugs randomly toggling on/off when using IKEA remotes" section below)
- ...?
Testing
- Completely remove the device from HA
- Do the following:
In the configuration.yaml, add this:
zha:
custom_quirks_path: /config/zha_custom_quirks
In the /config directory, create a folder called zha_custom_quirks, put the tjj_custom_aqara_plugs folder from this ZIP file in it: zha_custom_quirks.zip
In the end, the folder structure should look like this:
/config/zha_custom_quirks/tjj_custom_aqara_plugs
The last folder should contain four files:
__init__.py, plug.py, plug_eu.py, plug_maus01.py
- Restart Home Assistant
- Re-pair the device and see if the power measurement sensor works (it's likely others (like power_factor get created which can be disabled, as they'll never work))
- Also see if "total power consumption" works now (only EU models atm).
- Even if the power measurement sensor works now, please restart Home Assistant and let me know if any additional useless sensors are created.
Plugs randomly toggling on/off when using IKEA remotes
There's an issue in the v41 firmware on the plug where IKEA remotes toggle the plug (because the plugs always listens to messages sent for group 0). This is somewhat fixed in current versions of zhaquirks and this custom quirk by making the plug explicitly leave group 0. However, the plug still reacts when messages from those remotes are routed through it.
See the following comment for further explanation and a link for how to downgrade your plug to a "non-broken version": https://github.com/zigpy/zha-device-handlers/pull/1656#issuecomment-1244750465
Codecov Report
Base: 80.06% // Head: 80.37% // Increases project coverage by +0.31% :tada:
Coverage data is based on head (
bac7e4a) compared to base (fceacf1). Patch coverage: 100.00% of modified lines in pull request are covered.
Additional details and impacted files
@@ Coverage Diff @@
## dev #1656 +/- ##
==========================================
+ Coverage 80.06% 80.37% +0.31%
==========================================
Files 240 240
Lines 7455 7482 +27
==========================================
+ Hits 5969 6014 +45
+ Misses 1486 1468 -18
| Impacted Files | Coverage Ξ | |
|---|---|---|
| zhaquirks/xiaomi/__init__.py | 83.79% <100.00%> (+3.38%) |
:arrow_up: |
| zhaquirks/xiaomi/aqara/plug_eu.py | 90.56% <100.00%> (ΓΈ) |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Pull Request Test Coverage Report for Build 3267161994
- 43 of 43 (100.0%) changed or added relevant lines in 2 files are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage increased (+0.4%) to 80.444%
| Totals | |
|---|---|
| Change from base Build 3259514820: | 0.4% |
| Covered Lines: | 6018 |
| Relevant Lines: | 7481 |
π - Coveralls
I've updated the custom quirk and total power consumption might work after some time now.
(EU models only atm: maeu01 should work. mmeu01 could potentially also work
Before testing anything, it's recommended to reset and re-pair the plug! Some values might be off otherwise.
Edit: Updated again. MAEU01 and MMEU01 total power consumption should work now (re-pair device!)
Note: When restarting or manually polling active_power or current_summ_delivered, the respective attribute might display a lower value than it previously was. This will also affect the HA sensor. It should resolve itself when the value updates again. (This seems to be because of another zigpy/zhaquirks/HA issue currently tracked here: https://github.com/zigpy/zigpy/issues/1041)
I've updated the quirks and let you know if the total power consumption is now working !
One quick question, the plug has the hability to resume power on power loss. This is not the default behaviour (does not resume power by default). With Z2M, we had access to this settings directly. It's also described on the device page : Power_outage_memory (binary)
Enable/disable the power outage memory, this recovers the on/off mode after power failure. Value can be found in the published state on the power_outage_memory property. To read (/get) the value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/get with payload {"power_outage_memory": ""}. To write (/set) a value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"power_outage_memory": NEW_VALUE}. If value equals true power_outage_memory is ON, if false OFF. # Voltage (numeric)
With ZHA, I cannot find it, nor using "Set Cluster" options. Do you have any idea how should I do that ?
Regards,
I updated the quirks. (No need to re-pair when coming from the previous version).
Under Manage Clusters -> OppleCluster, you'll now find power_outage_memory.
When writing the attribute, use 0 for default off or 1 for restore.
Thanks ! But it does not seems to do anything. Getting the value returns "Bool.false". If I set this to 1 and then try to get value, it returns "none". If I close/ reopen Manage Cluster and get the value, returns "Bool.false" again ?
Smartenergysummation has started to returns value !
Mhm, that's weird. It works on the plugs I tested it with. Reading the attribute before re-opening the window also shouldn't be able to get another value (None) at all. Can you turn on ZHA debug logs and see if there's anything in the logs when reading or writing the attribute?
Also, make sure you're not using the lower text field with "manufacturer code override". That should always stay empty.
So only use the upper one with writing 0 or 1. When reading the attribute, it will show in the same text field (but Bool.false/Bool.true).
Ok, now I feel dumb, i've never used custer attributes to write attributes so I was using the "Manufacturer code Override" because the "value" was filed with 'Bool.false'.
Works like a charm using the correct textfield !
Looking good here too on my 2 lumi.plug.maeu01. Only one useless sensor is created, but I think you already mentioned that (sensor.lumi_lumi_plug_maeu01_electricalmeasurementpowerfactor_2). The rest seems to work fine and update as well, many thanks!
@fmiermont It's not really a user-friendly way. If/when this quirk gets merged officially, an option could be added to HA itself, so the clusters menu doesn't even need to be used.
My two maeu01 plugs also works with "Electricalmeasurement", "Smartenergysummation" and the new "power_outage_memory" setting. Thanks! :)
@TheJulianJES yes I know this is not the user friendly way to set this parameter but this is also the basics of "advanced" zwave settings and I'm usually familiar with this (but i'm not using HA for a long time). Anyway that works flawlessly for me now, perfect !
Thanks a lot for your work! It's working for me as well π (MAEU01, app_version = 41)
FYI for anyone that is using IKEA remotes and firmware v41 on the MAEU01/SP-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 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)
I tested the latest quirk with 3x v41 plugs, all work great. Thanks for the quirk!
Hi
Just wanted to give my input on this, i have a total of 5 Aqara Smartplugs and i have mixed luck with this and the original quirk shipped in 2022.9.7 of Home assistant, in the original one the connection to my plugs with .41 firmware is stable, but no power readings what so ever, in this this one i get power readings but the plugs constantly goes unavailable but i get power readings from them.
i have 3 with .41 firmare and 2 with .32 and the old ones work with either quirks.
I have removed one of the plugs after i added this and reinstalled it, same problem.
Just wanted you to know that it does not work for every .41 plug sadly.
If there is something specific you want me to post about my plugs i will gladly do so.
Regards / Marcus
@muddenhed The quirk can't affect the connection stability. It only changes how the messages are parsed when coming from the plug. With these plugs, I haven't encountered any stability issues so far. What coordinator/stick are you using?
(Also FYI, you can upgrade or downgrade all plugs to whatever firmware version you want (32 or 41))
Hmm, intresting, wieard that it starts acting like that then. I'm using ConBee II on a Raspebby PI, I will try to downgrade one of them if i can.
Sorry for wasting your time on this, thought it containted some connection polling code in this, but know better now.
Thanks. /Marcus
Sorry for wasting your time on this, thought it containted some connection polling code in this, but know better now.
You didn't! Thanks for all the feedback.
I'm using ConBee II on a Raspebby PI
Mhm, I've heard of quite a few issues with ConBee sticks now. You could try to upgrade the firmware on the stick and see if that helps. Also make sure that the ConBee is on a USB extension and not near any USB 3 devices (like a USB-SSD plugged into the Pi, as that will cause massive interference in the 2,4 GHz range).
downgrade one of them if i can.
Process should basically be to download the modified firmware image, put the image in a zha_ota folder that's registered in the configuration.yaml, send a cluster command to notify the device of the OTA, wait until the device updates, delete the image from the zha_ota folder and restart HA (so the device doesn't "upgrade"(downgrade) again). Let me know if you need help with this.
Sorry for wasting your time on this, thought it containted some connection polling code in this, but know better now.
You didn't! Thanks for all the feedback.
I'm using ConBee II on a Raspebby PI
Mhm, I've heard of quite a few issues with ConBee sticks now. You could try to upgrade the firmware on the stick and see if that helps. Also make sure that the ConBee is on a USB extension and not near any USB 3 devices (like a USB-SSD plugged into the Pi, as that will cause massive interference in the 2,4 GHz range).
downgrade one of them if i can.
Process should basically be to download the modified firmware image, put the image in a zha_ota folder that's registered in the configuration.yaml, send a cluster command to notify the device of the OTA, wait until the device updates, delete the image from the zha_ota folder and restart HA (so the device doesn't "upgrade"(downgrade) again). Let me know if you need help with this.
Thanks for the tips, i will check it out, i acutally manage to do a workaround by creating a timed automation that triggers the indentify button on them every 2 minutes and they have been far more stable now, no dropouts since then(6h+).
But it is better to have them working without the automation. :-)
/Marcus
Just wanted to say, I have a few maeu01 (I think firmware 0.0.0_0032) connected to a Conbee II (firmware 0x26780700) and I would love to help test if necessary. Up to now the quirk seems to work fine. :+1:
The quirk is now included starting with Home Assistant Core 2022.10.5 (and later). It's recommended to uninstall the custom quirk before you upgrade to that version. If you've already installed 2022.10.5, then just delete the custom quirk, reboot HA, and the "official quirk" should be used by ZHA.
If you didn't install the custom quirk and have issues with your Aqara MAEU01 or MMEU01 plugs now, please remove the device from ZHA and re-pair it. If you still have issues then, create a new issue in this repo and tag me.
@TheJulianJES
I just got three of these plugs, first tried to install one of them this evening. It did not work so I got searching for why, and found this thread. Now I have updated to: Home Assistant 2022.10.5 Supervisor 2022.10.0 Operating System 9.3 Grensesnitt 20221010.0 β latest
But it still do not function, I have tried to install one of the other ones I got but the result is still the same. I got ZHA and the Raspbee II, where do I go wrong?
Best regards Freddy.
I'm facing the same problem. I have 2 switches of this type. One is recognized, the other is not recognized or already recognized but I don't get any values displayed. The other connector works with no problems. My HA is 2202.10.5, everything is up to date. Greetings, Maggi
This is actually really frustrating. Have spend hours searching and I do have to conclude that my knowledge isnt good enough. Hope this is posible to solve then.
@TheJulianJES any idea how I can solve this? Today I updated the firmware on my Raspbee II, but still none of my plugs reporting any measuring, only function is on off. Home Assistant 2022.11.1 Supervisor 2022.10.2 Operating System 9.3 Grensesnitt 20221102.1 β latest
If you didn't install the custom quirk and have issues with your Aqara MAEU01 or MMEU01 plugs now, please remove the device from ZHA and re-pair it. If you still have issues then, create a new issue in this repo and tag me.
@FSHelgeland So, you re-paired the plug after updating your Raspbee firmware and it still doesn't work? If so, then please create another issue: https://github.com/zigpy/zha-device-handlers/issues/new/choose Make sure to fill out the template and tag me (@TheJulianJES) there.
Hello @TheJulianJES , I have Home Assistant 2022.11.1 as well and only the switch is working. Then I tried installing the quirk but it does not work anyway...
So, you re-paired the plug after updating your Raspbee firmware and it still doesn't work? If so, then please create another issue: https://github.com/zigpy/zha-device-handlers/issues/new/choose Make sure to fill out the template and tag me (@TheJulianJES) there.
@sipy Did you do the above?
Also, remove any custom quirks for the plug. They're all in Home Assistant 2022.10.5 or later (so also in 2022.11.1). After having removed all custom quirks, remove the device from ZHA and then pair it again.
Yep @TheJulianJES , tried them all and still not working. I am now trying to downgrade the Aqara firmware from V41 to V32. I'll let you know if it works.