Add Support Aqara Outlet EU version lumi.plug.maeu01

[aleksandrdobrynin]

Please add support for lumi.plug.maeu01.

[aleksandrdobrynin]

The socket is added to homekit via homebridge and a low battery warning is displayed there.

[SwoopX]

Can you also please provide a screenshot of the node info panel? Also, please for the simple metering and electrical measurement cluster (after the attributes have been read).

Nice to see that it is running on Zigbee 3. How much was it?

[aleksandrdobrynin]

[aleksandrdobrynin]

[SwoopX]

Hey, is the device working now with the latest deconz version? Would be glad if you could also provide a screenshot of the simple metering cluster while the attributes have been read. Thanks!

[aleksandrdobrynin]

Yes, the device on the latest firmware works fine. But when forwarding through Homebridge to HomeKit, a low battery level is displayed.

[SwoopX]

I see, thanks for highlighting. Found some code inconsistencies which are addressed by a new pull request.

[ghost]

Hello there,

I've been trying to keep up with the integration of this plug since I recently purchased one, but I don't seem to find a definitive answer.

Was this implemented in 2.05.75 or it's just now making it though the pipeline?

I can read the temperature, power and voltage from the deconz gui, but it doesn't seem to send that info anywhere (ie. my home assistant).

[SwoopX]

I see integration done as I haven't heard differently. All included in .75 release. Which version do you run?

[aleksandrdobrynin]

I migrate to z2m )

[ghost]

Very weird. Home assistant and domoticz both see it as a switch. So it's not them. I can turn it on and off and that's it.
I am on latest everything

The API sent from deconz is not sending any info.

[SwoopX]

That's normal, what are you missing? Consumption and power is under sensors in the API.

[ghost]

Missing both consumption and power. I re-installed and re-added and debugged for the last 2 days.
Nothing under sensors.

Lights for proof it's still there

[SwoopX]

Try the following with the sensor:

• Start sensor seach in Phoscon
• Read the basic cluster from deconz GUI

If that shouldn't change anything, you could try:

• Start sensor seach in Phoscon
• After like 10 secs, go to deconz GUI and set permit join to 0 (EDIT -> Permit Join)
• Now read the simple descriptors

[ghost]

Thnaks for taking the time to help me out, but none of these worked. I also tried them before, but did it again just to make sure. I also added an Aquara button that I knew worked, just to make sure that I didn't mess anything up.

Lo an behold, the aquara switch sensor is there, but the plug is still nowhere to be found. I'm really considering moving to ZHA at this point.

[Smanar]

Realy strange.
The device is on witelist, there is the cluster 0B04 and no ZHApowr device ....

Do you know how to obtain deconz log ? I think logs during pairing will be usefull.

[ghost]

Sure, how noisy do you want the logs to be?
dbg_info: 1
dbg_aps: 1
dbg_otau: 1
dbg_zcl: 1
dbg_zdp: 1

is this too much?

[Smanar]

I think dbg_info=2 is the more usefull, dbg_zcl=1 can be usefull to situate code execution.

[SwoopX]

Totally gone now?

Are you sure you've properly reset the plug? Just wanna close out all options.

[ghost]

Log I managed to capture.
https://pastebin.com/rq3P8y5X

I'm pretty sure I am resetting it correctly since I am removing the plug from deconz and then I add it again :)
Is there another way to reset the plug besides holding the power button until the blue light starts blinking?

I managed to somehow make it show the sensors now, but they
1. won't get picked up by HA They get picked up in Home Assistant
2. won't update.

[Smanar]

Ok, so now it's not the same problem
You have a ZHAconsumption and it is working
You have a ZHA power but not sure it is working, have you something connected to it ? (voltage and current are not supported by this device)

[ghost]

not the same problem means progress, so I've heard :)
I have an AC plugged in, which should draw enough for me to notice, but even with it powered on I get the same values in the API

322.24 reading on the plug but 0 in the API.

By the way this was the initial problem, before I was unable to get the sensors to work again. I have reached peak Ouroboros

[Smanar]

??? what happen, it 's the same device ?
The cluster 0b04 have disapear ? And now you are using the 000C.

And the created sensor is looking for 0b04 too, so it can't work in actual situation.

[ghost]

Same device. (you can see the uniqueID is the same)
I have removed and re-added it several times until sensors showed up. Could that be the cause?

[Smanar]

Nope.
But this device have something strange.

The cluster 0b04 exist, because the API have see it, and make a sensor according to it. And you have made a capture with this cluster present.

But if we compare the 2 capture, it's like 2 different device.

[Smanar]

Ok I m stupid.
There is 2 version of this device, the 2 capture show the same model id but not the same device.

Edit:
But BTW why you have a sensor "-0b04" ?
The 2 Sensors created doesn't correspond to cluster you have in deconz.

[ghost]

From what I understand it's the same device with two different sensors, the consumption sensor and the power one.
I only have one lumi.plug.mmeu01 type device

But BTW why you have a sensor "-0b04" ?

Not quite familiar what that means.

The 2 Sensors created doesn't correspond to cluster you have in deconz.

Figured as much, but nothing I can do about that. I need deconz to figure that out

[Smanar]

I have understand, It's normal, there is a "hack" in the code

                    else if (modelId.startsWith(QLatin1String("lumi.plug")) || modelId.startsWith(QLatin1String("lumi.ctrl_ln1")))
                    {
                        if (i->endpoint() == 0x02 || i->endpoint() == 0x15)
                        {
                            fpPowerSensor.inClusters.push_back(ci->id());
                        }
                        else if (i->endpoint() == 0x03 || i->endpoint() == 0x16)
                        {
                            fpConsumptionSensor.inClusters.push_back(ci->id());
                        }
                    }

But now need to use the good cluster.

[ghost]

Any idea how to remove those sensors from the api/unpair the plug completely and try again?

I can try putting raspbian & deconz only on the pi and removing everything again.
The thing is, I've been doing this in the past 3 days now and I don't think this will make any difference.

[Smanar]

Why do you want to remove them ?
You can using the API with command line.

BTW @SwoopX how are working binding for this cluster ?
I don't see problem on code, perhaps a reporting problem, but I don't find how the api configure it for the cluster 000c.

[SwoopX]

Folks, we're mixing up the plugs... This issue is for the lumi.plug.maeu01, but you got the lumi.plug.mmeu01.

If seen that strange behaviour (the plug shows 0x0702 and 0x0b04) only twince during my testing and that changed always after 30 seconds back to the analog clusters. I'd suspect a firmware issue. Regardless, I've added some code now that 0x0702 and 0x0b04 get discarded/disregarded. That is included in .76 that is now released.

#2583 is the issue to switch over. Btw, only .76 provides support for the device!

[Smanar]

Lol, I haven't take care enought to name.

[SwoopX]

@Smanar Me neither in the first place ;)

[ghost]

yikes guys sorry that's my fault I didn't read the whole name. I will go ahead and comment on the correct thread if I get around to trying this again.

Thanks for the help here.

[Smanar]

Lol, I think no one have take care correctly at name ^^

[Mimiix]

This looks closed :)

[silcotm]

Hello,

I received this plug today 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.

[Mimiix]

@silecotim Can you share some logs (if you are able to reproduce this)?

Option 1: To get debug logs in a GUI installation, open deCONZ and click Help. After that, click Debug View. The following debug levels need to be enabled for proper logging: INFO, INFO_L2, ERROR, ERROR_L2, APS, APS_L2.
Please note that in the HA Addon and Docker webVNC you can't copy paste. You need to use a Native VNC Client. HA Addon How-To, Docker Environment Vars.

Option 2: To get debug logs in a headless installation / ssh session, use the following commands:
sudo systemctl stop deconz-gui
sudo systemctl stop deconz
/usr/bin/deCONZ -platform minimal --dbg-aps=2 --dbg-info=2 --dbg-error=2 | tee debug.txt

When done, exit the process with CTRL+C. You can now start the systemctl service again. Your logs will be printed in the console, as well as saved to a file named debug.txt in the current directory. Be sure to capture at least a few minutes worth of logs. When sharing these logs, DO NOT attempt to paste them into a channel. Instead use a pastebin service such as this or this.

Afterwards, don't forget to disable logging. This is especially important when running off an SD card, as the debug logging will cause unnessecary writes, and might shorten the life of your media.

[silcotm]

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

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

[SwoopX]

Reachable must be wrong as the sensor got an update just 1 min ago

To continue on this, please raise a new issue, as this would be something generic. Thanks!