Lumi Plug maeu01 - Wrong metering

[basty2]

Describe the bug

Since the update to 18.0, my aqara plug delivers the wrong active power. I am accessing the data via rest api in iobroker deconz adapter. The delivered value is 10x higher than in version 2.17 before.

Steps to reproduce the behavior

all values supplied are 10x too high.

Expected behavior

the delivered value should be 1/10 of it

Screenshots

see attached. the right value should be 129W. At rest api it delivers 1292.

Environment

Host system: (PC)

• Running method: Ubuntu

• Firmware version: 26720700

• deCONZ version: 2.18.00

• Device: ConBee II

• Do you use an USB extension cable: yes

• model: lumi.plug.maeu01

deCONZ Logs

not necessary

Additional context

up to v.2.17 it worked fine.

here ist the rest api

"ep": 1, "etag": "xxx", "lastannounced": "2022-08-08T07:53:35Z", "lastseen": "2022-08-09T07:18Z", "manufacturername": "LUMI", "modelid": "lumi.plug.maeu01", "name": "OpenClose 63", "state": { "current": 0, "lastupdated": "2022-08-09T07:19:00.345", "power": 1292, "voltage": 0 }, "swversion": "09-10-2019", "type": "ZHAPower", "uniqueid": "xxx"

[Mimiix]

@basty2 Can you please fill in the report as intended?

[basty2]

@Mimiix Is it ok in this way or do you need more information?

[Mimiix]

Is good :)

Thanks :)

[Smanar]

Hello, can you edit the file devices\xiaomi\xiaomi_sp-euc01_smart_plug.json

At this part

          "name": "state/power",
          "refresh.interval": 10,
          "read": {
            "at": "0x0055",
            "cl": "0x000C",
            "ep": 21,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0055",
            "cl": "0x000C",
            "ep": 21,
            "eval": "Item.val = Math.round(Attr.val);"
          }

try

"eval": "Item.val = Math.round(Attr.val / 10);"

[basty2]

@Smanar I changed the data, restarted deconz, but it is not working. Values are 10x too high.

[Smanar]

The bad value is state/power ? Can you check if you have something in logs with the flag "DDF" ?

Can you check in the file if the modification is "persistent" ?

[basty2]

Hi @Smanar,

the bad value is state/power. I have activated the debug mode, there are some entries at DDF, but none from the affected device. The modification should be persistent, if i open the file again, the modified entry still exists.

[Smanar]

there are some entries at DDF, but none from the affected device

Ha ? The DDF status is "Gold" so I don't see why the DDF is not used for this device ...

Edit : Ok I have found a "check line" in the DDF

  "comment": "DDF for device firmwares at least above 0.0.0_0022, paired with xBee I fw 0x26400500 / xBee II fw 0x266f0700 and above",
  "matchexpr": "R.endpoints.includes(0x15) && R.endpoints.includes(0x1F)",

I think your device don't have Endpoint 0x15 and 0x1F ?

You can remove the line "matchexpr" to remove the check, but idk what will happen an other plug with different firmware (but same model) on your network.

[basty2]

I used "//" before the line matchexpr. But it doesn't work. the ID of the active power is 0x050B as you can see in the screenshot.

[basty2]

maybe this helps.

[Smanar]

You can direclty remove the line to test. From the log I think it explain why the DDF is not used for you.

[basty2]

ok, now it is shown at ddf. But the value is still to high.

[Smanar]

Nice. Edit the line (like here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6251#issuecomment-1212208880)

"eval": "Item.val = Math.round(Attr.val / 10);"

And you will see difference on the same debug line. If it work can you show all the device endpoints ? It's the number on the node title (can have more than one part)

To make a better "matchexpr", ATM this one work only if you have the endpoint 0x15 and 0x1F

[basty2]

Hi @Smanar , it is still not working. here ist my data

Is this the node title?

a screenshot of Cluster info is shown in the 1st post.

[Smanar]

Ok so you have the endpoint 0x01 and 0xF2 on yours. If you take a look in your log

Edit: Ok so I have look better your log, and we can see "eval": "if (Attr.val != -32768 && Attr.val != 32768) { Item.val = Attr.val; }", but in the DDF we have "Item.val = Math.round(Attr.val);" it mean the device is using another DDF

The only DDF where I can see "eval": "if (Attr.val != -32768 && Attr.val != 32768) { Item.val = Attr.val; }", is a Sinope device https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/sinope/th1124zb.json

You are sure there isn't a mistake somewhere ? with comparing the mac adress.

[basty2]

@Smanar I renamed the devices folder and copied a completly new downloaded devices folder from the github. But also this doesnt work. What kind of mistake could it be? I renamed the th1124zb.json to th1124zb.json.old but also this doesn't work. I dont have a sinope device. How could I campare the Mac adress? the mac adress ends with 46-58.

[Smanar]

If I m right with the flag "DDF" on debug you will see files used by devices, but as this one have a "matchexpr" field idk how it will react.

You can too on the GUI select the device (the node title) and choose "edit DDF" you will see the file used by deconz for the device.

Can be too a generic DDF (it's the defaut value), but how you have created it .... You haven't tried to edit the DDF using the editor and save the file ? https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/generic/items/state_power_item.json

[basty2]

Hi @Smanar . I tried edit ddf. it should be correct.

Here are all entries of ddf debug: 17:52:18:574 04:cf:8c:df:3c:76:46:58-01/attr/manufacturername expression: Item.val = Attr.val --> LUMI 17:52:18:575 04:cf:8c:df:3c:76:46:58-01-0b04/attr/manufacturername expression: Item.val = Attr.val --> LUMI 17:52:18:576 04:cf:8c:df:3c:76:46:58-15-000c/attr/manufacturername expression: Item.val = Attr.val --> LUMI 17:52:18:576 04:cf:8c:df:3c:76:46:58-01-0702/attr/manufacturername expression: Item.val = Attr.val --> LUMI 17:52:18:577 04:cf:8c:df:3c:76:46:58-1f-000c/attr/manufacturername expression: Item.val = Attr.val --> LUMI 17:52:18:578 04:cf:8c:df:3c:76:46:58/attr/manufacturername expression: Item.val = Attr.val --> LUMI 17:52:18:608 04:cf:8c:df:3c:76:46:58-01/attr/modelid expression: Item.val = Attr.val --> lumi.plug.maeu01 17:52:18:608 04:cf:8c:df:3c:76:46:58-01-0b04/attr/modelid expression: Item.val = Attr.val --> lumi.plug.maeu01 17:52:18:609 04:cf:8c:df:3c:76:46:58-15-000c/attr/modelid expression: Item.val = Attr.val --> lumi.plug.maeu01 17:52:18:609 04:cf:8c:df:3c:76:46:58-01-0702/attr/modelid expression: Item.val = Attr.val --> lumi.plug.maeu01 17:52:18:609 04:cf:8c:df:3c:76:46:58-1f-000c/attr/modelid expression: Item.val = Attr.val --> lumi.plug.maeu01 17:52:18:609 04:cf:8c:df:3c:76:46:58/attr/modelid expression: Item.val = Attr.val --> lumi.plug.maeu01 17:52:21:264 04:cf:8c:df:3c:76:46:58-01/state/on expression: Item.val = Attr.val --> true 17:52:21:563 04:cf:8c:df:3c:76:46:58-01-0b04/state/power expression: if (Attr.val != -32768 && Attr.val != 32768) { Item.val = Attr.val; } --> 1467 17:52:44:402 04:cf:8c:df:3c:76:46:58-01-0702/state/consumption expression: Item.val = Attr.val --> 1448266

[basty2]

there is also no change, if i change to (Attr.val / 100). Is this a problem only for me or is it a problem for several people?

[Smanar]

Ok, so there is something strange. I will ask for tips to others devs.

If you make a "hot reload" with same log enabled "DDF" (or perhaps "info" "info_l2"), you will see the file used used by deconz for this device, not possible it use the same ....

[SwoopX]

Please delete any modified DDF, restart deconz and re-pair the device. The device exposes incorrect clusters when a response is not properly received during pairing.

[basty2]

Hi @SwoopX. I deleted and reinstalled the complete devices folder. I tried to repair the device more than 20 times. I have now a new problem. The power value is not shown in electric metering, but In a new area.

7 Watt should be the right Power Value at Analog Input Cluster:

[SwoopX]

The "problem" is a works as designed. Regardless, the device still doesn't look right and my gut feeling says it runs on a rather old firmware. It should look like this:

Please activate the OTA update plugin under plugins (in the menu bar), select the device and then select OTA update pane (bottom left). Then press the query button until you get some result.

[SwoopX]

Firmware can be found here and must be placed in the otau folder to update https://github.com/Koenkk/zigbee-OTA/raw/master/images/Xiaomi/20211209165104_OTA_lumi.plug.maeu01_0.0.0_0041_20211206_0C22EC.ota

[basty2]

@SwoopX Very strange. Because everythings worked until 2.17. But this was the solution. I got all the values. Thanks.

[softwerker64]

Looks like I'm vacing the same problem :-( I updated the "lumi.plug.maeu01" with the new firmware referenced above and the device reports "09-10-2019" as SW-Version in Hue-Essentials. However, the value "state.power" still seems to be ten times too high. In Hue-Essentials and via REST.

Any ideas? Thanks in advance!

[softwerker64]

Update deconz on my Raspberry... "apt" reports this package: "deconz/unknown,now 2.19.03-raspbian-buster-stable armhf" Still no luck, REST still reports these values (where power is ten times too high): current: 0 power: 17 voltage: 0

JSON-String was: {"config":{"on":true,"reachable":true,"temperature":0},"ep":1,"etag":"a443133272e7ae501509b1c4ccbdb08e","lastannounced":"2022-10-25T08:55:40Z","lastseen":"2022-12-04T10:04Z","manufacturername":"LUMI","modelid":"lumi.plug.maeu01","name":"Zwischenstecker","state":{"current":0,"lastupdated":"2022-12-04T10:01:30.067","power":17,"voltage":0},"type":"ZHAPower","uniqueid":"04:cf:8c:df:3c:78:8a:57-01-0b04"}

[grimmaldus]

I have been experiencing the same issue for several years and have been stuck using version 2.17.1 since then. Could someone please explain what has changed in the newer versions? Is there any specific reason for this issue? Are there any known solutions or workarounds available?

Any help would be greatly appreciated. Thank you!

[Smanar]

Hello, are you using the new firmware ? (for the device, not for the Gateway)

[grimmaldus]

I’m using the file OTA_lumi.plug.maeu01_V32_20200922_C11F8A.20200924102946.ota in deCONZ, but it shows as 0x00000020. I couldn’t find a newer version. When I want to use the latest version, 2.28.1 deCONZ, the only way to get the correct values is by changing the DDF.

[Smanar]

Have checked the OTA file and yes this version is the 0x20. Do you have access to the GUI to compare how look your device in deconz ?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Xiaomi-smart-plugs-not-working-correctly

Perhaps need to delete it and re-include it.

[grimmaldus]

Have checked the OTA file and yes this version is the 0x20. Do you have access to the GUI to compare how look your device in deconz ?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Xiaomi-smart-plugs-not-working-correctly

Oh nice I'm gonna try this file I couldn't get to it before. And let you know.

Perhaps need to delete it and re-include it.

Yea I did it before after I updated.

[Smanar]

Nope, you need to compare the clusters, the first image on the wiki page. And from that I have checked you have the last one, the 0x20.

You have "DDF" written on the node corner ?

[grimmaldus]

Nope, you need to compare the clusters, the first image on the wiki page. And from that I have checked you have the last one, the 0x20.

Thanks for your response. I’ve checked the clusters, and unfortunately, they don’t match. Regarding the DDF, I’m not entirely sure where I should be looking for it in the GUI since I couldn’t find any reference to it in the wiki. If by any chance you are referring to the "Edit DDF" option in the right-click node menu, then yes, I do have that, and that’s actually how I managed to edit the DDF and fix the initial issue.

You have "DDF" written on the node corner ?

Additionally, I noticed that the file that led me to the 0x00000020 cluster has a different hash compared to the one on the wiki page. I wasn’t able to locate it earlier due to the broken link (source of my cheer), but I will now try updating the firmware for the lumi.plug.maeu01 following the wiki page's firmware guide.

[Smanar]

On this picture you can see Endpoint 01/15/1F/F2 and on the Endpoint 0x15 and 0x1F, you can see the cluster 0x000C You need them, for the DDF can work.

"matchexpr": "(R.endpoints.indexOf(0x15) !== -1) && (R.endpoints.indexOf(0x1F) !== -1);",

Else can you show how look your device ?

[grimmaldus]

Else can you show how look your device ?

[Smanar]

So yes I can confirm, the DDF will never work, you have an old version. But how you can have a version = 0x20 ? Or there is a OTA version above, but I don't see it on the github.

DDF for device firmwares at least above 0.0.0_0022, paired with xBee I fw 0x26400500 / xBee II fw 0x266f0700 and above

Can you check the swbuild on the cluster 0x0000 'basic" ?

And BTW why you have "DDF" writted on the node corner ? Can you make "edit DDF" to see wich one DDF is used by the editor ? (It's written on the titlebar")

[grimmaldus]

Can you check the swbuild on the cluster 0x0000 'basic" ?

And BTW why you have "DDF" writted on the node corner ? Can you make "edit DDF" to see wich one DDF is used by the editor ? (It's written on the titlebar")

I'm not very familiar with the deCONZ GUI, to be honest, so I'm not sure why it shows up there, but I have edited the DDF for these devices.

I plan to migrate the entire HA instance, where deCONZ is running, to new hardware this weekend. I will also rebuild deCONZ from scratch. I’ll keep you updated on whether the issue gets resolved.