Aqara Smart Plug - power sensor becomes unreachable

[silcotm]

Describe the bug

Hello,

I received this plug today (lumi.plug.maeu01 / SP-EUC01) and paired it with deCONZ:

Then I went into Home Assistant and there it was showing with a lot of weird entities like Motion and Battery:

Then I went back into deCONZ and went to Sensors > Add new > Other and pressed the button on the plug. It said sensor added successfully (but no sensor actually appeared in the list of sensors).

Going back to Home Assistant, the device now fixed itself and displayed energy metering etc:

However, the problem is that the power consumption sensor becomes unavailable a few minutes after satrting deCONZ. In those few minutes, the value of the power consumption updates like it should when the power draw changes, but then the sensor becomes unavailable and stays that way.

Steps to reproduce the behavior

Expected behavior

Screenshots

Environment

• Host system: Ubuntu VM
• Running method: Marthoc Docker container
• Firmware version: 26720700
• deCONZ version: 2.13.01
• Device: ConBee II
• Do you use an USB extension cable: yes
• Is there any other USB or serial devices connected to the host system? no

deCONZ Logs

5 minutes of logs: https://pastebin.com/Ex4xHhPh

During those 5 minutes, the sensor came and went 2-3 times.

Additional context

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[silcotm]

Anyone?

[Mimiix]

@SwoopX Perhaps you have some time to check?

[SwoopX]

I'm afraid there is nothing to be checked. I don't have even the slightest clue how such a condition can happen.

[mortelil]

Hello! I have the same plug (SP-EUC01) and I have a somewhat different problem. The plug reports both power (W) and consumption (kWh), but the values only update every ~7 minutes. The value is reported only for a few seconds, then the values are reported as 0 (see screenshot).

The way I would like it to work would be that it reported power usage much more often, every 30 seconds would be nice. And also it should keep its value, not "reset" to zero.

Hope someone could look into this, I bought several of this plug to monitor the energy usage of different devices in my home, and they are all pretty much useless to me now.

[mike9011]

Same issue here since a couple of weeks.

[torkel]

I have more or less the same issue. Have three smart-plugs bought at the same time and they all behave differently.

One working ok. The other two are loosing connection in some way and showing strange sensors.

[Zetro]

I also have the same issue with the sensor being unavailable. And I also didn't have any consumption sensor. My lumi.plug.maeu01 with firmware 09-22-2020 is using endpoint 1F (dec 31) for that. Current code only check 0x03 and 0x16.

I did some quick debugging where checkSensorNodeReachable in de_web_plugin.cpp sets config/reachable to false.

A newly reset and added plug has [12] in both sd.inClusters() and sensor fingerprint. Sensor works fine and is available.

After power cycling the plug, the fingerprint now contains [12, 0]. Sensor receive updates every 5-10min but immediately become unavailable. The basic cluster was added and is not found, which mark the sensor as unreachable/unavailable.

Tested a hack fix in DeRestPluginPrivate::addSensorNode that doesn't add the basic cluster for maeu01 and it stayed available for a full day until I physically disconnected the plug, and became available after plugging it in again.

But I hope someone else knows what a proper fix is. Since I know neither the code nor the zigbee protocol.

[Zetro]

Looks like the change I did partially revert commit 36b9fc11adf512d4cf388b38c1b2a61b3455d312.

[SwoopX]

Can somebody please check if this has been resolved with version 2.14.0 beta?

[Zetro]

Tried the beta (unmodified) and the issue remains, for me at least.

Still creates a dotted history graph in HA while unavailable (like the one in torkel's image).

[kljakobsen]

Any news on this front? Anyone created a working DDF template?

some data randomly gets to HA…

12:16:28:394 0x54EF4410003145CC extract Xiaomi special attribute 0x00F7 12:16:28:395 64 on/off 1 12:16:28:395 03 Device temperature 25 °C 12:16:28:395 98 power 229.992004 (230) 12:16:28:395 95 consumption 0.601922 (602) 12:16:28:396 96 voltage 2470.000000 (247) 12:16:28:396 97 current 931.141724 (931) 12:16:28:396 05 RSSI dB (?) 3 (0x0003) 12:16:28:396 9a unknown 0 (0x00) 12:16:28:397 08 unknown 288 (0x0120) 12:16:28:397 09 unknown 5376 (0x1500) 12:16:28:397 0b unknown 0 (0x00) 12:16:28:397 9b Consumer connected (yes/no) 1 12:16:28:398 0f unknown 3414753280 (0xCB890000)

however isnt working well for moment …

Running latest deconz and 2.14.01 firmware

[nhulsch]

same over here... after re-learning the devices multiple times it worked well, i had "electrical measurement" descriptors etc and the reporting worked fine. after 2 weeks without changing anything i had the same issues again. values were reported every 6-7 minutes followed by 0. restarted deconz and the device has lost its "electrical measurement" descriptors. Now I've changed the reporting interval in the lumi specific values to 30 and the reporting works every 30 seconds without any 0 after the correct value. Still the sensor is being showed as not reachable and switches to true/false with every value received.

so it looks to me, that the new plugs don't use the "electrical measurement" descriptors anymore as these are always 0, but with the xiaomi specific values the real power value is being read. problem is, that older plugs with possible the same device firmware are using "electrical measurement" with the correct values

I'm on: Version: 2.14.01 / 6.2.2022 Firmware: 26720700

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[iamspido]

Any news? I have the same Problem. I have 2 Smart Plugs in use. One works perfectly, but the other has the same problem with the same firmware version (Version 09-06-2019) of the Smart Plug.

Deconz: Version: 2.14.01 / 6.2.2022 Firmware: 26720700

Working device:

Not working device:

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[github-actions[bot]]

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.

[rwijnhov]

Is there an update on this issue?

[Drumdevil]

I have the same plugs with a similar problem. The device becomes temporarily unavailable in Home Assistant every time the power consumption changes more than the value set in: FCC0 Lumi specific -> 0x0204 (min. power change for report(W))

It also happens when I manually read the value from 000C Analog Input -> 0X0055 Present value.

As a workaround I could fabricate a template sensor that updates only when the value changes to a numeric value. It would clean up the sensor data nicely, but it's undesirable

[Drumdevil]

Used another workaround for Home Assistant: I used the deCONZ API instead. I set the reporting interval (0X00F6) to 3 seconds (I'll see how that goes), and configured a REST sensor that checks the sensor value. The resulting data is picked up by a template sensor.

The API GET method:

http://XX.XX.XX.XX:40850/api/YOUR_API_TOKEN/sensors/YOUR_SENSOR_ID

REST Sensor configuration

  - platform: rest
    name: lumi_power_1
    resource: http://XX.XX.XX.XX:40850/api/YOUR_API_TOKEN/sensors/YOUR_SENSOR_ID
    scan_interval: 3
    json_attributes_path: '$.state'
    json_attributes:
      - power
    value_template: 'OK'

Template sensor configuration

  - platform: template
    sensors:
      lumi_power_1_wattage:
        value_template: '{{ state_attr("sensor.lumi_power_1", "power") }}'
        device_class: power
        unit_of_measurement: 'W'

The only downside I found so far is that when the plug is removed from the wall socket without switching it off first, the last known value is retained in the sensor. If you shut it down first, it will be 0.

[Egglestron]

@silcotm Do you mind re-opening the issue please? It's still not fixed.

[nhulsch]

One problem is, that there are different firmware versions for that smartplug that cannot be identified with deconz yet. I've posted a feature request for more identifications for DDF files on the forums.

You might want to comment there as its about the smartplug issue.

https://forum.phoscon.de/t/feature-request-ddf-optional-basic-cluster-identifications/2092

I have 2 Aqara smart plugs with different firmware versions and can only use one at a time due to that issue

[Mimiix]

REopening as it probably isn't solved. @SwoopX can you check along?

[phlexss]

I have a similar problem. I’m using CONBEE II v2.17.01 and when I add an AQARA SMART PLUGIN I don’t get power sensors anymore.

I have an exact same device that was connected some time ago (with older deconz sw version) which works fine.

When looking at the devices using VNC the one that works shows the following cluster info:

0702 Simple Metering 0B05 Electrical Measurement

The newly added device doesn’t show these two clusters, but it shows:

FCC0 Lumi speficic

It seems deconz doesn’t identify the measurement capabilities…can this be a problem with the latest software?

Any help is appreciated!

[Mimiix]

@phlexss Can you share screens of the basic cluster for both devices?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/How-to-read-Clusters

[phlexss]

Here they are...

[Mimiix]

@phlexss I think you need to re-pair the faulty one a few times. They are the same devices but probably haven't paired fully.

[phlexss]

This is a bit embarassing....I have deleted/paired this device at least 5 times and it never showed the measurement capabilities......and now I delete/pair again and it works!

So no more issue for me....I'll keep this "trick" in mind!

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[Egglestron]

@silcotm Do you mind re-opening the issue please? Issue still not fixed.

[SwoopX]

Should be settled with #6216

[Zetro]

I pulled in the latest commit (0e2f15ea) earlier today and tried the new DDF with lumi.plug.maeu01, conbee II fw 26720700.

Can confirm that both power and consumption sensors are working without becoming unreachable.

[bjoernh]

After upgrading today to latest docker release, I didn't get the power and consumtion measurments from Aqara Smart Plugs. But not from all devices i used, only for these with firmware "manufacturername": "LUMI","modelid": "lumi.plug.mmeu01", "swversion": "09-06-2019". The only one I owned that works after upgrading is these with "manufacturername": "LUMI", "modelid": "lumi.plug.mmeu01","swversion": "0.0.0_0022

[nhulsch]

you have to re-pair the devices that are not working anymore. due to changes on the conbee firmware the stick emulates a xiaomi base and the device will recognize that on pairing. after that different endpoints are being sent to conbee.

[nhulsch]

@SwoopX can you tell me why you read the power via zcl and not via xiaomi:special directly? via zcl i see random drops to 0W while not with xiaomi:special. of course i have to lower the reporting interval of the device to get more fresher data.

[SwoopX]

@nhulsch please keep the discussion on topic. I haven't observed anything like you describe within 1h runtime, confirmed by deconz logs and the sniffer. If you still feel there's something wrong, you can raise a seperate issue with supporting debug log data.