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"}