Deconz-rest-plugin: Question: Which powerplugs supported for Deconz and REST-api (for Home assistant)

I have smart plugs from Heiman and from OSRAM. I’m quite impressed by the Heiman smart plug. It even provides ZigBee attribute reporting on the power consumption. The OSRAM plugs work with deCONZ, but don’t report the actual power consumption, even though they support the corresponding ZigBee cluster.

I read that the Xiaomi smart plug als works, but you need an adapter as they have Australian pens. It reports power (in a typical Xiaomi way), but that isn’t yet exposed by deCONZ.

Note that we’re still figuring out the best way to expose power metering in deCONZ.

I read that the Xiaomi smart plug als works, but you need an adapter as they have Australian pens. It reports power (in a typical Xiaomi way), but that isn’t yet exposed by deCONZ.

Not looking for adapters in my sockets ;)

The OSRAM plugs work with deCONZ, but don’t report the actual power consumption, even though they support the corresponding ZigBee cluster.

This means they only report the energy consumption (kWh), not the actual used power (W)?

’m quite impressed by the Heiman smart plug. It even provides ZigBee attribute reporting on the power consumption.

So these plugs are the most "Plug and play" sensors you know of ?

Note that we’re still figuring out the best way to expose power metering in deCONZ.

There is currently no power consumption reported by the REST-api ?

I have yet to implement support for power metering in the hass component. @ebaauw is the details in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/423 complete?

Further there are power EU plugs from:

Busch Jeager
https://www.busch-jaeger.de/en/products/product-solutions/remote-control/zigbee-light-link/

Climax
http://www.climax.com.tw/psm29zb-zb.php

So the summary is:

• At this point the REST-api / HASS component but is Work in progress ?
• Looks like the Heiman plug is the most plug and play compatible, and most price efficient one

@geelenbert there is always new things to support :)

@Kane610 well i just would like to know if this is on the road map or not. If this is very far out, i might need to look at other options for power-metering of specific devices.

I would love to help in any way possible, but i'm just a simple python script hacker, not really a programmer ....

@geelenbert it is probably max an hour with testing to get this done. But I just need to know that all information is there. Would be nice to have a full json blob of a device with a reported power attribute.

I'm just a simple python hacker as well, I'm not a developer by profession. It is not hard at all adding support for new functionality from deconz to the hass component. Maybe you should try it out? ;)

@Kane610 Ok i'll order some of these plugs (the Heiman ones) and start messing around with it.
When the time is right, i'll open an issue on your project (https://github.com/Kane610/deconz) and well get it going.

I have yet to implement support for power metering in the hass component. @ebaauw is the details in #423 complete?

@Kane610, the details are complete, but not stable. Both the Heiman and the OSRAM serve the _Electrical Measurement_ cluster on the same endpoint as the _OnOff_ cluster, so it was easy to create state.power in the /lights resource. I’m afraid this approach might not work for devices that use a different endpoint, like the Xiaomi plug or the ubisys dimmer. Maybe I’ll need to create a ZHAPower sensor resource instead.

Here's the json of the Heiman plug:

{
  "etag": "97cbc3f6d2f0787875f12e6310477571",
  "hascolor": false,
  "manufacturername": "Heiman",
  "modelid": "SmartPlug",
  "name": "Plug",
  "state": {
    "alert": "none",
    "on": false,
    "power": 0,
    "reachable": true
  },
  "swversion": "",
  "type": "Smart plug",
  "uniqueid": "00:0d:6f:00:0b:xx:xx:xx-01"
}

And here of the OSRAM:

{
  "etag": "e188ff1ce6bee3935b31f43e7da3214e",
  "hascolor": false,
  "manufacturername": "OSRAM",
  "modelid": "Plug 01",
  "name": "Living Room Desk",
  "state": {
    "alert": "none",
    "on": false,
    "power": 0,
    "reachable": true
  },
  "swversion": "V1.05.09",
  "type": "On/Off plug-in unit",
  "uniqueid": "84:18:26:00:00:xx:xx:xx-03"
}

@geelenbert with the information from @ebaauw I will add the power state in good time for hass' 0.65 release. Then you can verify functionality when you get your plugs.

can anyone recommend some UK supported plugs?

@Kane610 Awsome! But i think that @ebaauw has a point for adding a different resource. I don't know wich one is more future proof?

@Martin-Gardner the Heiman plugs are also available in a UK version

@geelenbert - Thanks - Although buying them is going to be hard

Where do you guys buy your ZigBee stuff? - It seems there is not much ZigBee related products available in the UK except Philips and Ikea. There is the Samsung stuff but its very expensive - 50 euros for a smart plug.

The Xiaomi stuff at the Chinese webshops, gearbest.com or aliexpress.com, most of the EU stuff at amazon or my local webshops.

I haven't had luck finding the Heiman Plug (HS2SK-E-EU) at any of those places. Do you know where they can be bought? :-)

Well i also looking hard for some of the Heiman plugs, if i find anything i will let you know.

@ebaauw what is the difference between the Osram and the Heiman plug ? Does the Osram plug not report the current power (W), only the used energy (kWh)?

The OSRAM reports 28000 (deciWatt, I guess) when off and 400 when on. Regardless whether anything is drawing power or even connected. The Heiman reports the actual power drawn (so 0 when the plug is on, but the connected device is off). Also, the Heiman supports attribute reporting on _Active Power_, which means deCONZ is updated quickly when the power consumption changes. Otherwise the change won’t be visible until the next time the plug is polled.

Here's some screenshots of the Heiman. Note that is does _not_ support groups (deCONZ lets you add it to a group, but it won't respond to group commands). Also, it supports reporting Voltage and Current (Ampere) in the _Electrical Measurement_ cluster. So much to do...
I have no clue what, if anything, the _Simple Metering_ cluster does.

Here's the attribute reporting, also works for Voltage and Current:

And here when the connected fan is on:

Here's some screenshots from the OSRAM. Up to 8 groups, but no useful power measurement. I have no clue what the 0xFC0F cluster does. OSRAM lights enable setting the power-on defaults through a custom cluster, but I haven't found anything similar in the Lightify app for the plug.

This is when the plug is off:

And this when it's on, with nothing connected:

@ebaauw the simple metering looks like it will give you the used energy in kWh.

See it like this:
The power (Watt) is the amount of energy that a devices uses at one point in time.
The Energy is the (kWh) is how much energy was used in an hour. (kilo Watt's per Hour)

if a device uses 1000 Watt and is constantly turned on, this will result un a use of 1kWh after one hour, 2kWh after 2 hours etc...

This is actualy the most interesting part of the plugs. It is nice to know how what the active power of a device is, but it is much more interesting how much engery it used over the last hour (calculate what the electricity costs for that device where)

Here's some photos of the OSRAM, Heiman, and an Elgato Eve (from left to right). I might be challenging to place two Heimans above each other if you have multiple outlets stacked vertically.

I haven't had luck finding the Heiman Plug (HS2SK-E-EU) at any of those places. Do you know where they can be bought?

I got mine on loan from @Oggymator at led-trading.de. They don't yet sell them online, but they should become available in the next months.

This means they only report the energy consumption (kWh), not the actual used power (W)?
@ebaauw the simple metering looks like it will give you the used energy in kWh.

As far as I can tell the _Simple Metering_ cluster doesn't report anything. I might need to dive into the ZCL specs and add some attributes to general.xml. Also, I only added the attributes to the _Electrical Measurement_ cluster that my ubisys dimmer supports. As I said: so much to do...

This is actualy the most interesting part of the plugs. It is nice to know how what the active power of a device is, but it is much more interesting how much engery it used over the last hour (calculate what the electricity costs for that device where)

You mean something like this:

This is actually the homebridge-p1 plugin that I created today. It reads the smart electricity meter that the electricity network company installed in my home last week.

I'm doing the same for homebridge-hue, here's the Heiman, but still on my test network with plenty if restarts, so no data yet. Here I actually compute the consumption by multiplying the power by the duration.

The Energy is the (kWh) is how much energy was used in an hour. (kilo Watt's per Hour)

Actually kiloWatt hour (kW times hour), not kiloWatt _per_ hour.

Here I actually compute the consumption by multiplying the power by the duration.

@ebaauw that is not the correct way to do that. As the power changes over time, the calculation will be incorrect. The only reliable way to do this is by getting the (total) energy consumption from a plug.
Such a calculation may give an indication, but will never be realy accurate.
An energy meter measures the used power at around 400 Hz, and then calculates the used energy for that small time.

I do the calculation each time the power value changes, using the duration since the previous change. I’m pretty sure the plugs have a far lower update frequency than the electricity meter, though.

I’ll be more than happy to use the (total) consumption, as I do for the electricity meter, as soon as we’ve found if and how each plug reports this.

OK, looks like we have a bug in the deCONZ GUI, causing it not to display the value of the _Current Summation Delivered_ attribute (0x0000) of the _Metering_ cluster (0x0702). Maybe uint48 is too much for the GUI? @manup?

I setup attribute reporting manually and deCONZ receives the reports allright:

Feb 24 11:18:50 pi deCONZ[13192]: 11:18:38:251 ZCL attribute report 0x000D6F000B7A7837 for cluster 0x0702, ep 0x01

Wireshark confirms that the data is there when I read the attributes from the GUI:

I wonder if there is a way to reset the total? That would be particularly cool for my electricity meter, but, unfortunately, the end-consumer interface is read-only ;-)

Next, we need to figure out where to place the decimal point...

OK, looks like we have a bug in the deCONZ GUI, causing it not to display the value of the Current Summation Delivered attribute (0x0000) of the Metering cluster (0x0702). Maybe uint48 is too much for the GUI? @manup?

Yes it's likely missing, I'll check and add it for the next version.

It's defined in general.xml alright (or the attribute wouldn't even show in the GUI?). The value just remains blank in the GUI, see the screenshot above.

@ebaauw You can’t reset the total. In most metering options the counter keeps on counting. Wich is to be expected because you are looking at the total used enegergy of that plug. In the home automation system you would only be interested in the delta value between an hour, day, week etc.... It is way easyer just to record the values in a database and do the math from there.

I added state.consumption, state.current and state.voltage in my latest PR.
Note that I currently report the raw values (cf. state.temperature and state.humidity). Still need to check and scale the values so different plugs are comparable. The Heiman seems to report:

• consumption in Wh (0.001 kWh) [to be confirmed];
• current in dA (0.1 A);
• power in dW (0.1 W);
• voltage in cV (0.01 V).

They seem to work for the Heiman:

$ ph -H pi get /lights/3
{
  "etag": "852ff09aa39b1de608725833e24d8fa2",
  "hascolor": false,
  "manufacturername": "Heiman",
  "modelid": "SmartPlug",
  "name": "Plug",
  "state": {
    "alert": "none",
    "consumption": 2605,
    "current": 0,
    "on": false,
    "power": 0,
    "reachable": true,
    "voltage": 22831
  },
  "swversion": "",
  "type": "Smart plug",
  "uniqueid": "00:0d:6f:00:0b:xx:xx:xx-01"
}
$ ph -H pi put /lights/3/state '{"on": true}'
$ sleep 5
$ ph -H pi get /lights/3
{
  "etag": "a8797b4bad3e7715fe68b17473ca7326",
  "hascolor": false,
  "manufacturername": "Heiman",
  "modelid": "SmartPlug",
  "name": "Plug",
  "state": {
    "alert": "none",
    "consumption": 2605,
    "current": 14,
    "on": true,
    "power": 321,
    "reachable": true,
    "voltage": 22791
  },
  "swversion": "",
  "type": "Smart plug",
  "uniqueid": "00:0d:6f:00:0b:xx:xx:xx-01"
}

Also with websocket:

Feb 24 14:30:12 pi dc_eventlog[20886]: /lights/3/state: {"voltage":22858}
Feb 24 14:30:43 pi dc_eventlog[20886]: /lights/3/state: {"voltage":22838}
Feb 24 14:31:26 pi dc_eventlog[20886]: /lights/3/state: {"voltage":22846}
Feb 24 14:32:03 pi dc_eventlog[20886]: /lights/3/state: {"voltage":22831}
Feb 24 14:32:31 pi dc_eventlog[20886]: /lights/3/state: {"on":true}
Feb 24 14:32:31 pi dc_eventlog[20886]: /groups/1/state: {"any_on":true}
Feb 24 14:32:35 pi dc_eventlog[20886]: /lights/3/state: {"voltage":22791}
Feb 24 14:32:40 pi dc_eventlog[20886]: /lights/3/state: {"power":323}
Feb 24 14:32:49 pi dc_eventlog[20886]: /lights/3/state: {"current":14}
Feb 24 14:32:49 pi dc_eventlog[20886]: /lights/3/state: {"power":321}
Feb 24 14:32:56 pi dc_eventlog[20886]: /lights/3/state: {"power":319}
Feb 24 14:33:05 pi dc_eventlog[20886]: /lights/3/state: {"power":321}
Feb 24 14:33:22 pi dc_eventlog[20886]: /lights/3/state: {"current":13}
Feb 24 14:33:22 pi dc_eventlog[20886]: /lights/3/state: {"power":315}
Feb 24 14:33:46 pi dc_eventlog[20886]: /lights/3/state: {"power":313}
Feb 24 14:33:55 pi dc_eventlog[20886]: /lights/3/state: {"power":311}
Feb 24 14:34:11 pi dc_eventlog[20886]: /lights/3/state: {"power":309}

@ebaauw Sweet! So it looks like the Heiman plug is fully supported now.
How about the osram plugs. I try to figure out why they do not "work well". What is the missing functionality for the Osrams ?

The OSRAM reports in my Eve app:
Consumption: always 40W
Total consumption 0Wh when off and 6,7Wh (hour) when on (regardless whether anything is drawing power or not)

@geelenbert, @oleg77s, this is still work in progress, please bear with me...

I just pushed a new commit, which exposes the power measurement attributes under /sensors as a ZHAPower resource. I only have the Heiman on my test network, I'm about to push the new release to production to see if it works with the OSRAM plugs and with the ubisys D1. It should also work with the _Analog Input_ cluster on endpoint 0x03 of the Xiaomi plug, but I cannot test that myself. @manup if you could provide some info on the power measurement features of the Busch-Jaeger and Climax plugs, I could add support for these as well.

I've also changed homebridge-hue to base the _Total Consumption_ history on state.consumption (the _Current Summation Delivered_) instead of on state.power (_Active Power_) and the time since the previous change or history entry. I now use the heartbeat instead of the fakegato timer to schedule the entries and base the filenames to persisting the history on the device mac address instead of on the device name.
I still need to update homebridge-hue to use ZHAPower instead of the /lights attributes.

As far as I can tell, the OSRAM only reports _Active Power_ on the _Electrical Measurement_ cluster. No consumption. And it always reports _Active Power_ as 400 (40W?) when it's on (irrespective of whether something is drawing power or even connected) and 28000 (2800W?) when off.
The Eve app expects six history entries per hour with the current power (40W), yielding a consumption 40Wh per hour or ~6.67Wh per 10 minutes. I have no clue where the _Total Consumption_ comes from. Even at 2800W, it would take over 7.5 years to accumulate 187 MWh. That's longer than homebridge-hue exists.

I want to check deCONZ and homebridge-hue, and see if they work correctly when there's only an _Electrical Measurement_ and no _Metering_ cluster. After that, I think I'd better drop support for the OSRAM plugs, at least until they fix their firmware or some-one figures out the FC0F cluster. One of my E14 OSRAM bulbs did report power (more or less) correctly under an old firmware version, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/153#issuecomment-326122497.

Ok
And what can you say about power consumption of Xiaomi Zigbee plug ?

Analog input present value is 0,00 when plug is off or on (without any load)
Analog input present value is 0,63 when plug is on and connected Osram bulb is off
Analog input present value is 5,26 when plug is on and connected Osram bulb is on

@oleg77s I think this on endpoint 0x02? That seems to report power in W, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/153#issuecomment-326148369. Can you have a look at endpoint 0x03 as well. That should report lifetime consumption in kWh.

I would theorise that endpoint 0x64 would hold an _In Use_-like value: true when something is connected/drawing power and false otherwise. Does the plug send reports for this cluster as well?

Hi,

Don’t want to break the discussion or make sales promotion.
But if anybody has interest in Heiman products like smart plug, send me an email tobias.[email protected]

Back to topic :)

@ebaauw yes, this on endpoint 0x02
endpoint 0x03 report 0.04 after 1.5 hour 25w load, so it is 0.04kw
endpoint 0x64 report always false

I added support for the Xiaomi plug to my latest PR, but cannot test it. It should be exposed as a /lights resource with state.on and as a /sensors ZHAPower resource with state.consumption (based on endpoint 3). I don't know how to combine the two endpoints into one resource, so, for now, endpoint 2 is not exposed.

one note about Xiaomi plug:
as rtenklooster commented: only deCONZ is showing and able to control plug,
it isn't showing up in the REST API.
@manup commented: Ah I see, the reason it isn't showing up in the REST API is that other than the one from the above screenshot this doesn't have the 0x0051 device id but 0xffff which isn't recognized by deCONZ.

There are two version of Xiaomi plug: ZNCZ02LM (latest) and ZNCZ01LM (older)


The older version showing up in REST API as a Light
The latest version isn't showing up in the REST API
Attributes in basic plaster are exactly the same, but endpoints 1 are very different

The 0xffff should be showing up as a light as well, with my latest PR. I cannot test this myself, though. Out of interest: does the _Groups_ cluster of the old plug actually work? Does it react to group commands?

old plug reacts on group commands in Phoscon App

I added support for the Xiaomi plug to my latest PR, but cannot test it. It should be exposed as a /lights resource with state.on and as a /sensors ZHAPower resource with state.consumption (based on endpoint 3). I don't know how to combine the two endpoints into one resource, so, for now, endpoint 2 is not exposed.

I'm compiling your pull request atm. will see if my Xiaomi plugs are listed. Keep you posted and thanks for the effort!

@ebaauw After compiling your pull request and replacing the libde_rest_plugin.so my xiaomi plug isn't listed in the rest api, not under lights and sensors.

Bummer. You did open the network from the Web or Phoscon app? After that, you might try reading the 0x01 _Basic_ cluster attributes and the 0x03 _Analog Input_ cluster attributes.

Could you double-check that the plug has indeed:

• Device ID: 0xffff
• _OnOff_ server cluster on endpoint 0x01
• Manufacturer code: 0x1037 (on the _Node Info_ panel)
• Mac address starts with 0x00158d
• _Analog Input_ cluster on endpoint 0x03
• Model: lumi.plug

Oops, I see I listed the plug under _Multistate Input_ instead of _Analog Input_. That would explain why it doesn't show as a ZHAPower sensor. I added a commit with a fix to the PR.

Ok, something about a donkey and a stone...
After re-adding the plug from the PWA It's working 👍 👍 👍
"18": { "etag": "3c08f3ef7e983e0840ba4119dbc4d493", "hascolor": false, "manufacturername": "LUMI", "modelid": "lumi.plug", "name": "Light 18", "state": { "alert": "none", "on": false, "reachable": true }, "swversion": "", "type": "Smart plug", "uniqueid": "00:15:8d:00:01:3f:9c:a6-01" }

Lastest commit, (hopefully) due for 2.05.08 now divides the attributes over a ZHAConsumption sensor (endpoint 0x03 for the Xiaomi plug or the _Metering_ cluster for other plugs) vs ZHAPower (endpoint 0x02 or _Electrical Management_).

Please let me know if this works.

@geelenbert this is still moving, so I'll wait a few more days to let @ebaauw iron out how this should be. Still loads of time to get this in for 0.65 or I can await you receiving devices.

@Kane610 No worries!
@Oggymator I have send you an email for some of the Heiman plugs, and that i needed the EU version, but i'm not getting any response.
@ebaauw is there any other plug that needs some more investigation that i could buy for testing ?

@geelenbert
Very busy the last days, you get response today :)

For a long time, the only EU plugs available were the OSRAM plugs. Before Hue, Philips used to have plugs as well, but they have been discontinued for years. I don’t know if they can report power, at least not through the Hue bridge. I’m quite happy with the Heiman plug and haven’t looked for any others. Would be nice(r) to have groups support as well, though, but I guess you cannot have it all.

I’ll be happy to help investigating if you find one.

Short note on the Busch-Jaeger power plug, it doesn't provide electrical measurement. Also it isn't dimmable albeit containing a level control cluster.

http://www.busch-jaeger-catalogue.com/artikel.php?bereich=1013323&programm=1035820&gruppe=1043979&produkt=1035830

I can confirm that the ZNCZ02LM version of Xiaomi Power Plug is not shown in REST API

@tomfritz1, are you on v2.05.08? Does the plug show in the GUI? Did you open the network from the web app or Phoscon app and refresh the _Basic_ cluster attribtes?

@ebauww, I am on v2.05.08. The plug is shown in the GUI and the basic cluster attributes have been refresehd (lumi.plug, 11, 2, 18, Lumi, etc.). I tried open network both in web app and Phoscon but it is not found as new light. But funny enough my xiaomi cube is now shown in Phoscon :-)

@Kane610 if all goes well the plugs will arrive tomorrow. In the weekend I can get the devices tested. Do i need specific versions of deConz, Home assistant or the Rest api ?

@geelenbert for deconz, whichever version listed in this thread that supports your device, for hass I recommend you take the latest, you would get all data from deconz by enabling logger debug in hass then we can work on the power usage support

@tomfritz1 could you double-check the list from my post above, in particular the device type? Did the REST API create the the ZHAConsumption and ZHAPower /sensors resources?

@rtenklooster, is v2.05.08 working for you?

@ebaauw , I did delete the cluster (in GUI) and re-added in REST API. Now it works!!!! thanks a lot

@tomfritz1, good to know! Do you also see the sensors? Do they show the correct values: consumption in Wh (0.001 kWh) and power in W? Thanks.

removed the node from the gui and it reappeared shorty after, correctly as a smart plug, visible in the rest api. Yay!

i do how ever have a different manufacturer code:
0x115f

i do how ever have a different manufacturer code: 0x115f

@g3wd, Do you have an old plug, with a "Smart plug" device type (0x0051) on endpoint 0x01? This is exposed as a light, irrespective of the manufacturer code.

deCONZ will only expose the new plug (with device type 0xffff on endpoint 0x01) as a light, when the manufacturer code is 0x1037. Likewise, the ZHAConsumption and ZHAPower sensor resources for endpoints 0x03 and 0x02 (both new and old plugs) are only created when the manufacturer code is 0x1037.

@oleg77s, What are the manufacturer codes on your plugs, old and new?

device type FFD?

@ebaauw
not a 100% confident i understand the terminology of endpoints and device types. hope the screenshot sheds some light onto whats going on.

Thanks, @g3wd. This is indeed the old plug, with a device type of "Smart plug".

The "box" with the yellow bar to the left is a node, a device on the ZigBee network. Yellow indicates it's a router (part of forming the mesh network), grey indicates its an end-device, blue is for the coordinator - your RaspBee or ConBee. In the "drop down list", you see the endpoints, 01, 02, 03, 64 (all in hex).

Each endpoint has a profile, in this case ZHA (indicated by the HA symbol and the Home Automation text). For lights this might be ZLL (for Light Link). You might also see Green Power here. Under the profile you see the device type, hopefully a name, otherwise four hex digits (like 0053 for endpoint 03).

Each profile has one of more clusters (four hex digits). Blue clusters are server clusters; grey are client clusters. Server clusters typically have attributes, which you can read in the Cluster Info panel.

@ebaauw, all manufacturer codes on my plugs, both old and new, are 0x115f (in Node Info panel)

So apparently they use both? That would explain why some folks still don’t see the light resource but others do.

i don't see too :)

After re-adding the plug from the PWA It's working

Searching back, I cannot find any reference of manufacturer code 0x1037 being used for the plug. I just copied the code from the other Xiaomi devices. @rtenklooster, may I ask you to double check the manufacturer code and device type of your Xioami plug?

The Heiman seems to report:

• consumption in Wh (0.001 kWh) [to be confirmed];
• current in dA (0.1 A);
• power in dW (0.1 W);
• voltage in cV (0.01 V).

I think the consumption is in dWh (0.1 Wh, 0.0001 kWh). I get plenty of attribute reports, but the value only updates in intervals of ~100 raw value. Here's the log, with a halogen desk lamp connected, that burns at ~36W (reported by both the Heiman plug and an Eve Energy):

Mar 02 21:32:34 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2292,"lastupdated":"2018-03-02T20:32:34"}
Mar 02 21:37:35 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2292,"lastupdated":"2018-03-02T20:37:35"}
Mar 02 21:42:35 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2292,"lastupdated":"2018-03-02T20:42:35"}
Mar 02 21:47:36 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2292,"lastupdated":"2018-03-02T20:47:36"}
Mar 02 21:49:39 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2392,"lastupdated":"2018-03-02T20:49:39"}
Mar 02 21:54:40 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2392,"lastupdated":"2018-03-02T20:54:40"}
Mar 02 21:59:40 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2392,"lastupdated":"2018-03-02T20:59:40"}
Mar 02 22:04:41 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2392,"lastupdated":"2018-03-02T21:04:41"}
Mar 02 22:06:44 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2492,"lastupdated":"2018-03-02T21:06:44"}
Mar 02 22:11:45 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2492,"lastupdated":"2018-03-02T21:11:45"}
Mar 02 22:16:46 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2492,"lastupdated":"2018-03-02T21:16:46"}
Mar 02 22:21:46 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2492,"lastupdated":"2018-03-02T21:21:46"}
Mar 02 22:23:34 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2592,"lastupdated":"2018-03-02T21:23:34"}
Mar 02 22:28:35 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2592,"lastupdated":"2018-03-02T21:28:35"}
Mar 02 22:33:36 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2592,"lastupdated":"2018-03-02T21:33:36"}
Mar 02 22:38:37 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2592,"lastupdated":"2018-03-02T21:38:36"}
Mar 02 22:40:29 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2693,"lastupdated":"2018-03-02T21:40:29"}
Mar 02 22:45:30 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2693,"lastupdated":"2018-03-02T21:45:30"}
Mar 02 22:50:31 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2693,"lastupdated":"2018-03-02T21:50:31"}
Mar 02 22:55:32 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2693,"lastupdated":"2018-03-02T21:55:32"}
Mar 02 22:57:24 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2793,"lastupdated":"2018-03-02T21:57:24"}
Mar 02 23:02:25 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2793,"lastupdated":"2018-03-02T22:02:25"}
Mar 02 23:04:59 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2793,"lastupdated":"2018-03-02T22:04:59"}
Mar 02 23:05:02 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2834,"lastupdated":"2018-03-02T22:05:02"}
Mar 02 23:08:14 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2834,"lastupdated":"2018-03-02T22:08:14"}
Mar 02 23:08:17 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2849,"lastupdated":"2018-03-02T22:08:17"}
Mar 02 23:13:17 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2849,"lastupdated":"2018-03-02T22:13:17"}
Mar 02 23:18:18 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2849,"lastupdated":"2018-03-02T22:18:18"}
Mar 02 23:23:19 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2849,"lastupdated":"2018-03-02T22:23:19"}
Mar 02 23:25:22 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2949,"lastupdated":"2018-03-02T22:25:22"}
Mar 02 23:30:23 pi dc_eventlog[4701]: /sensors/13/state: {"consumption":2949,"lastupdated":"2018-03-02T22:30:23"}

I stacked the plugs for comparison. The Eve Energy consistently logs history entries for 6,09 Wh every 10 minutes (so ~36 Wh over an hour). With homebridge-hue v0.8.1, I see alternating log entries for ~100 Wh and 0.00 Wh, with occasionally two adjacent ~100 Wh entries. I'm happy that this averages out to ~360 Wh over an hour, so a factor 10 too large.

Building the history from the power x duration would be smoother than building it from the delta's in total consumption. The total consumption is reset when you factory-reset the plug.

After deleting Node Light 3 (Xiaomi old smart plug) from my test setup and adding it again in deconz 2.05.08, it looks in GUI like new one and not added to PWA.

After deleting Node Light 3 (Xiaomi old smart plug) from my test setup and adding it again in deconz 2.05.08, it looks in GUI like new one

As I said before: this plug is cursed. I don't know how the plug can change fingerprints without a firmware upgrade. I would suspect it is has different ways of reporting its fingerprint, and deCONZ randomly (?) uses one of these ways. Maybe there's an inconsistency between the information in the _Basic Descriptor_ and the _Node Descriptor_? @manup, any ideas?

not added to PWA.

You would need my latest commit (PR #451) for that, which whitelists the 0x115f manufacturer code.

And why the appearance of endpoint 01 has changed?

on previous ver of deconz it looks as Consumption

on previous ver of deconz it looks as Consumption

The REST API used to update the node name when the ZHAConsumption resource was created. I did change that, so now only the name of the light resource will be used.

The interesting part: apparently deCONZ created a ZHAConsumption resource while still looking for manufacturer code 0x1037. Apparently, the cursed plug changes manufacturers as well? Can you double check what the codes are now?

0x115f

removed and added again both plugs in latest deconz:

PWA:

Short info: 2.05.09 will be online later today which will include latest PR https://github.com/dresden-elektronik/deconz-rest-plugin/pull/451 from @ebaauw :)

@ebaauw I do no see sensors for the Xiaomi plug. The other problem I have: in DECONZ Web App, I can turn it on/off without problems. In Alexa it is not shown as a light or switch but as a device - I can not turn it on with routines. And in Harmony I can only turn it off but not on -> there might be still some issues.

Starting fresh setup from scratch, it's ok now:

Consumption in Eve seems ok now, too:

[2018-3-3 23:29:59] [Hue] Test: gateway request 2: get /
[2018-3-3 23:29:59] [Hue] Test: gateway request 2: ok
[2018-3-3 23:29:59] [Hue] Test: gateway request 3: get /groups/0
[2018-3-3 23:29:59] [Hue] Test: gateway request 3: ok
[2018-3-3 23:29:59] [Hue] Test: 00212EFFFF0140AE-G0: LightGroup "All"
[2018-3-3 23:29:59] [Hue] Test: /groups/0: LightGroup "All"
[2018-3-3 23:29:59] [Hue] Test: 00212EFFFF0140AE-G1: LightGroup "Xiaomi Smart plugs"
[2018-3-3 23:29:59] [Hue] Test: /groups/1: LightGroup "Xiaomi Smart plugs"
[2018-3-3 23:29:59] [Hue] Test: 00158D0000F853BE: LUMI lumi.plug "Light 1"
[2018-3-3 23:29:59] [Hue] Test: /lights/1: Smart plug "Light 1"
[2018-3-3 23:29:59] [Hue] Test: /sensors/2: ZHAConsumption "Consumption 2"
[2018-3-3 23:29:59] [Hue] Test: /sensors/1: ZHAPower "Power 1"
[2018-3-3 23:29:59] [Hue] Test: 00158D0001DEC776: LUMI lumi.plug "Light 2"
[2018-3-3 23:29:59] [Hue] Test: /lights/2: Smart plug "Light 2"
[2018-3-3 23:29:59] [Hue] Test: /sensors/4: ZHAConsumption "Consumption 4"
[2018-3-3 23:29:59] [Hue] Test: /sensors/3: ZHAPower "Power 3"
[2018-3-3 23:29:59] [Hue] Test: 4 sensors
[2018-3-3 23:29:59] [Hue] Test: 2 lights
[2018-3-3 23:29:59] [Hue] Test: 0 schedules
[2018-3-3 23:29:59] [Hue] Test: 0 rules
[2018-3-3 23:29:59] [Hue] Test: 2 groups
[2018-3-3 23:29:59] [Hue] Test: 5 accessories

I do no see sensors for the Xiaomi plug.

@tomfritz1, You need deCONZ v2.05.09 for that.

in DECONZ Web App, I can turn it on/off without problems.

That means the REST API is working. I'm sorry, I have no experience with Alexa nor with the Harmony.

Consumption in Eve seems ok now, too:

Glad to see that. Thanks, @oleg77s.

Starting fresh setup from scratch, it's ok now:
@oleg77s @ebaauw

Is there an alternative to "start up from scratch" to have the plug consumption recognised by eve?

got them in the rest api alright i think.
But eve knows the plug from when it didn't have sensors maybe?

{
  "config": {
    "battery": 100,
    "on": true,
    "reachable": true,
    "temperature": 0
  },
  "ep": 2,
  "etag": "5913c8a3c8036b15b560a1d6d4cc7d93",
  "manufacturername": "LUMI",
  "modelid": "lumi.plug",
  "name": "Power 3",
  "state": {
    "lastupdated": "2018-03-04T16:37:58",
    "power": 17
  },
  "swversion": "02-28-2017",
  "type": "ZHAPower",
  "uniqueid": "00:15:8d:00:01:f9:ec:bf-02-000c"
}

{
  "config": {
    "battery": 100,
    "on": true,
    "reachable": true,
    "temperature": 0
  },
  "ep": 3,
  "etag": "e3ee07a3befd6e35dc410bab9aed2adf",
  "manufacturername": "LUMI",
  "modelid": "lumi.plug",
  "name": "Consumption 4",
  "state": {
    "consumption": 3581,
    "lastupdated": "2018-03-03T11:46:30"
  },
  "swversion": "02-28-2017",
  "type": "ZHAConsumption",
  "uniqueid": "00:15:8d:00:01:f9:ec:bf-03-000c"
}

Just restart homebridge, and homebridge-hue should recognise the ZHAPower and ZHAConsumption resources. Check the homebridge log if you see history entry log messages and ~homebridge/accessories for a persist__mac_.json file. Close and exit Eve - it should load the history on a clean start.

first: thank you @ebaauw for an amazing piece of software, and on top of that taking the time to answer my novice questions.
i updated homebridge-hue to latest and restarted homebridge, and everything works as it should now. yay! thanks again

@Kane610 I've got the setup running. Got 3 power sockets and the latest beta version of deconz (2.05.10). What do you need from me to get the power metering working?

innr will be releasing a new and very compact EU smart plug by the end of this month. It's not yet on their web site, but it's already mentioned here (in Dutch): https://www.beaumotica.nl/innr-1x-new-zll-smart-plug-hue-compatible-small-footprint-8718781551735. I don't know how smart it is, unfortunately their service department couldn't tell me if it supports metering.

@Kane610 I've got the setup running. Got 3 power sockets and the latest beta version of deconz (2.05.10). What do you need from me to get the power metering working?

@Kane610 I don't want to be pushing ... But is there any way i can help in this ?

@geelenbert if I could get the initial value for these devices and also some state updates over web sockets I think that would be a start.

Enable logger component and set level to debug then it is just to start browsing the logs on a restart

@Kane610 here is a little part of my log:

2018-03-12 20:25:41 DEBUG (MainThread) [pydeconz.websocket] Websocket data: b'\x81t{"e":"changed","id":"27","r":"sensors","state":{"lastupdated":"2018-03-12T19:25:41","temperature":2076},"t":"event"}' 2018-03-12 20:25:41 DEBUG (MainThread) [pydeconz.deconzdevice] Edit Room Multi Sensor: update lastupdated with 2018-03-12T19:25:41 2018-03-12 20:25:41 DEBUG (MainThread) [pydeconz.deconzdevice] Edit Room Multi Sensor: update temperature with 2076 2018-03-12 20:25:41 DEBUG (MainThread) [pydeconz.websocket] Websocket data: b'\x81q{"e":"changed","id":"28","r":"sensors","state":{"humidity":4609,"lastupdated":"2018-03-12T19:25:41"},"t":"event"}' 2018-03-12 20:25:41 DEBUG (MainThread) [pydeconz.deconzdevice] Edit Room Multi Sensor: update humidity with 4609 2018-03-12 20:25:41 DEBUG (MainThread) [pydeconz.deconzdevice] Edit Room Multi Sensor: update lastupdated with 2018-03-12T19:25:41 2018-03-12 20:25:41 DEBUG (MainThread) [pydeconz.websocket] Websocket data: b'\x81p{"e":"changed","id":"29","r":"sensors","state":{"lastupdated":"2018-03-12T19:25:41","pressure":987},"t":"event"}' 2018-03-12 20:25:41 DEBUG (MainThread) [pydeconz.deconzdevice] Edit Room Multi Sensor: update lastupdated with 2018-03-12T19:25:41 2018-03-12 20:25:41 DEBUG (MainThread) [pydeconz.deconzdevice] Edit Room Multi Sensor: update pressure with 987 2018-03-12 20:25:52 DEBUG (MainThread) [pydeconz.websocket] Websocket data: b'\x81~\x00\x87{"e":"changed","id":"16","r":"sensors","state":{"current":34,"lastupdated":"2018-03-12T19:25:52","power":64,"voltage":231},"t":"event"}' File "/usr/lib/python3.6/site-packages/pydeconz/websocket.py", line 98, in data_received File "/usr/lib/python3.6/site-packages/pydeconz/__init__.py", line 159, in async_event_handler File "/usr/lib/python3.6/site-packages/pydeconz/websocket.py", line 98, in data_received File "/usr/lib/python3.6/site-packages/pydeconz/__init__.py", line 159, in async_event_handler 2018-03-12 20:26:34 DEBUG (MainThread) [pydeconz.websocket] Websocket data: b'\x81~\x00\x87{"e":"changed","id":"16","r":"sensors","state":{"current":34,"lastupdated":"2018-03-12T19:26:34","power":65,"voltage":231},"t":"event"}' File "/usr/lib/python3.6/site-packages/pydeconz/websocket.py", line 98, in data_received File "/usr/lib/python3.6/site-packages/pydeconz/__init__.py", line 159, in async_event_handler File "/usr/lib/python3.6/site-packages/pydeconz/websocket.py", line 98, in data_received File "/usr/lib/python3.6/site-packages/pydeconz/__init__.py", line 159, in async_event_handler 2018-03-12 20:27:01 DEBUG (MainThread) [pydeconz.websocket] Websocket data: b'\x81u{"e":"changed","id":"15","r":"sensors","state":{"consumption":11352,"lastupdated":"2018-03-12T19:27:01"},"t":"event"}' File "/usr/lib/python3.6/site-packages/pydeconz/websocket.py", line 98, in data_received File "/usr/lib/python3.6/site-packages/pydeconz/__init__.py", line 159, in async_event_handler File "/usr/lib/python3.6/site-packages/pydeconz/websocket.py", line 98, in data_received File "/usr/lib/python3.6/site-packages/pydeconz/__init__.py", line 159, in async_event_handler

I think this is the part that you need right ?

Also look for lines that says name created as {xxxxxx} It is in the up start phase of hass

@Kane610 that would be this part:

2018-03-12 20:24:41 DEBUG (MainThread) [pydeconz.deconzdevice] Server created as {'_alert': 'none', '_bri': None, '_colormode': None, '_ct': None, '_effect': None, '_hue': None, '_on': True, '_reachable': True, '_sat': None, '_x': None, '_y': None, '_async_set_state_callback': <bound method DeconzSession.async_put_state of <pydeconz.DeconzSession object at 0x7f0215108dd8>>, '_deconz_id': '/lights/1', '_etag': '9e895d51d99bf47af592e3ed9f7af2d7', '_manufacturername': 'Heiman', '_modelid': 'SmartPlug', '_name': 'Server', '_swversion': '', '_type': 'Smart plug', '_uniqueid': '00:0d:6f:00:0b:7a:53:44-01', '_async_callback': []}
2018-03-12 20:24:41 DEBUG (MainThread) [pydeconz.deconzdevice] Media System created as {'_alert': 'none', '_bri': None, '_colormode': None, '_ct': None, '_effect': None, '_hue': None, '_on': True, '_reachable': True, '_sat': None, '_x': None, '_y': None, '_async_set_state_callback': <bound method DeconzSession.async_put_state of <pydeconz.DeconzSession object at 0x7f0215108dd8>>, '_deconz_id': '/lights/2', '_etag': '45d61e96b5d9f53abd9457fd3f33ca92', '_manufacturername': 'Heiman', '_modelid': 'SmartPlug', '_name': 'Media System', '_swversion': '', '_type': 'Smart plug', '_uniqueid': '00:0d:6f:00:0b:7a:64:29-01', '_async_callback': []}
2018-03-12 20:24:41 DEBUG (MainThread) [pydeconz.deconzdevice] Heatpump created as {'_alert': 'none', '_bri': None, '_colormode': None, '_ct': None, '_effect': None, '_hue': None, '_on': True, '_reachable': True, '_sat': None, '_x': None, '_y': None, '_async_set_state_callback': <bound method DeconzSession.async_put_state of <pydeconz.DeconzSession object at 0x7f0215108dd8>>, '_deconz_id': '/lights/3', '_etag': 'e8066dd6fbfd9bc082a48e6957dd0cf3', '_manufacturername': 'Heiman', '_modelid': 'SmartPlug', '_name': 'Heatpump', '_swversion': '', '_type': 'Smart plug', '_uniqueid': '00:0d:6f:00:0b:7a:75:d3-01', '_async_callback': []}
2018-03-12 20:24:41 WARNING (MainThread) [pydeconz.sensor] Unsupported sensor type ZHAConsumption (Consumption 15)
2018-03-12 20:24:41 WARNING (MainThread) [pydeconz.sensor] Unsupported sensor type ZHAPower (Power 16)
2018-03-12 20:24:41 WARNING (MainThread) [pydeconz.sensor] Unsupported sensor type ZHAConsumption (Consumption 17)
2018-03-12 20:24:41 WARNING (MainThread) [pydeconz.sensor] Unsupported sensor type ZHAPower (Power 18)
2018-03-12 20:24:41 WARNING (MainThread) [pydeconz.sensor] Unsupported sensor type ZHAConsumption (Consumption 19)
2018-03-12 20:24:41 WARNING (MainThread) [pydeconz.sensor] Unsupported sensor type ZHAPower (Power 20)

Sorry, I'm tired. I meant the part before that when retrieving the deConz config with all device data. I'll have a look at it tomorrow if you can get it.

@Kane610 the reason i'm not posing the complete log file is beacuse i have a shit load of zigbee devices connected ... ;)

2018-03-12 20:24:41 DEBUG (MainThread) [pydeconz.utils] HTTP request response: {'config': {'UTC': '2018-03-12T19:24:41', 'apiversion': '1.0.9', 'backup': {'errorcode': 0, 'status': 'idle'}, 'bridgeid': '00212EFFFF022DBE', 'datastoreversion': '60', 'devicename': 'ConBee', 'dhcp': True, 'factorynew': False, 'fwversion': '0x261e0500', 'gateway': '192.168.1.1', 'internetservices': {'remoteaccess': 'disconnected'}, 'ipaddress': '192.168.1.112', 'linkbutton': False, 'localtime': '2018-03-12T20:24:41', 'mac': '00:0c:29:85:f2:df', 'modelid': 'deCONZ', 'name': 'deconz', 'netmask': '255.255.255.0', 'networkopenduration': 60, 'panid': 44006, 'portalconnection': 'disconnected', 'portalservices': False, 'portalstate': {'communication': 'disconnected', 'incoming': False, 'outgoing': False, 'signedon': False}, 'proxyaddress': 'none', 'proxyport': 0, 'replacesbridgeid': None, 'rfconnected': True, 'starterkitid': '', 'swupdate': {'checkforupdate': False, 'devicetypes': {'bridge': False, 'lights': [], 'sensors': []}, 'notify': False, 'text': '', 'updatestate': 0, 'url': ''}, 'swupdate2': {'autoinstall': {'on': False, 'updatetime': ''}, 'bridge': {'lastinstall': '', 'state': 'noupdates'}, 'checkforupdate': False, 'install': False, 'lastchange': '', 'lastinstall': '', 'state': 'noupdates'}, 'swversion': '2.5.11', 'timeformat': '12h', 'timezone': 'Etc/GMT-1', 'uuid': '9186523c-f5b7-4221-b580-332c15ca4e2c', 'websocketnotifyall': True, 'websocketport': 443, 'whitelist': {'043E08157D': {'create date': '2018-02-27T19:03:30', 'last use date': '2018-02-27T19:17:18', 'name': 'deCONZ WebApp'}, '2DDB148972': {'create date': '2018-03-06T12:28:36', 'last use date': '2018-03-10T12:03:02', 'name': 'Phoscon#B1280x821'}, '71700133C0': {'create date': '2018-02-27T19:29:55', 'last use date': '2018-03-12T19:24:41', 'name': 'pydeconz'}, '7EC88F0BC6': {'create date': '2018-02-27T19:03:08', 'last use date': '2018-02-27T19:05:17', 'name': 'Phoscon#B1280x821'}, '7EE6CEEBA6': {'create date': '2018-02-27T19:18:14', 'last use date': '2018-03-10T18:42:36', 'name': 'deCONZ WebApp'}, '81D82EFBC1': {'create date': '2018-02-27T19:04:32', 'last use date': '2018-02-27T19:16:11', 'name': 'Phoscon#B1280x739'}, '89E19F0BD1': {'create date': '2018-03-03T13:35:09', 'last use date': '2018-03-06T12:29:58', 'name': 'deCONZ WebApp'}, '8B1B3E20BA': {'create date': '2018-03-10T10:22:30', 'last use date': '2018-03-11T09:53:50', 'name': 'Phoscon#B1280x739'}, '95AE29E5F2': {'create date': '2018-03-10T13:03:05', 'last use date': '2018-03-11T17:42:42', 'name': 'Phoscon#B2560x1379'}}, 'zigbeechannel': 15}, 'groups': {'1': {'action': {'bri': 127, 'colormode': 'hs', 'ct': 0, 'effect': 'none', 'hue': 0, 'on': False, 'sat': 127, 'xy': [0, 0]}, 'class': 'Other', 'devicemembership': [], 'etag': 'd4365c84d680422898682fb506bc38df', 'hidden': False, 'id': '1', 'lights': ['9', '8', '10'], 'lightsequence': [], 'multideviceids': [], 'name': 'Dining Table', 'scenes': [], 'state': {'all_on': True, 'any_on': True}, 'type': 'LightGroup'}, '15289': {'action': {'bri': 127, 'colormode': 'hs', 'ct': 0, 'effect': 'none', 'hue': 0, 'on': False, 'sat': 127, 'xy': [0, 0]}, 'class': 'Other', 'devicemembership': ['57'], 'etag': '40e429757ee84ee8cc71721fd8028ac0', 'hidden': False, 'id': '15289', 'lights': [], 'lightsequence': [], 'multideviceids': [], 'name': 'RWL021 9', 'scenes': [], 'state': {'all_on': False, 'any_on': False}, 'type': 'LightGroup'}, '1832': {'action': {'bri': 127, 'colormode': 'hs', 'ct': 0, 'effect': 'none', 'hue': 0, 'on': False, 'sat': 127, 'xy': [0, 0]}, 'class': 'Other', 'devicemembership': ['56'], 'etag': '40e429757ee84ee8cc71721fd8028ac0', 'hidden': False, 'id': '1832', 'lights': [], 'lightsequence': [], 'multideviceids': [], 'name': 'RWL021 8', 'scenes': [], 'state': {'all_on': False, 'any_on': False}, 'type': 'LightGroup'}, '2': {'action': {'bri': 127, 'colormode': 'hs', 'ct': 0, 'effect': 'none', 'hue': 0, 'on': False, 'sat': 127, 'xy': [0, 0]}, 'class': 'Other', 'devicemembership': [], 'etag': '1d7be8e6ff66d43646a7d15d6516d66e', 'hidden': False, 'id': '2', 'lights': ['6', '7'], 'lightsequence': [], 'multideviceids': [], 'name': 'Hall', 'scenes': [], 'state': {'all_on': False, 'any_on': False}, 'type': 'LightGroup'}, '3': {'action': {'bri': 127, 'colormode': 'hs', 'ct': 0, 'effect': 'none', 'hue': 0, 'on': False, 'sat': 127, 'xy': [0, 0]}, 'class': 'Other', 'devicemembership': [], 'etag': '40e429757ee84ee8cc71721fd8028ac0', 'hidden': False, 'id': '3', 'lights': ['17', '18', '4'], 'lightsequence': [], 'multideviceids': [], 'name': 'Edit Room', 'scenes': [], 'state': {'all_on': False, 'any_on': False}, 'type': 'LightGroup'}, '4': {'action': {'bri': 127, 'colormode': 'hs', 'ct': 0, 'effect': 'none', 'hue': 0, 'on': False, 'sat': 127, 'xy': [0, 0]}, 'class': 'Other', 'devicemembership': [], 'etag': '5f0ae5650d108fe0d351e30e49f975eb', 'hidden': False, 'id': '4', 'lights': ['11'], 'lightsequence': [], 'multideviceids': [], 'name': 'Bathroom', 'scenes': [], 'state': {'all_on': True, 'any_on': True}, 'type': 'LightGroup'}, '5': {'action': {'bri': 127, 'colormode': 'hs', 'ct': 0, 'effect': 'none', 'hue': 0, 'on': False, 'sat': 127, 'xy': [0, 0]}, 'class': 'Other', 'devicemembership': [], 'etag': 'f5ec9634d75570ea10068680b3fd0e0c', 'hidden': False, 'id': '5', 'lights': ['15', '14', '16'], 'lightsequence': [], 'multideviceids': [], 'name': 'Bedroom', 'scenes': [], 'state': {'all_on': False, 'any_on': False}, 'type': 'LightGroup'}}, 'lights': {'1': {'etag': '9e895d51d99bf47af592e3ed9f7af2d7', 'hascolor': False, 'manufacturername': 'Heiman', 'modelid': 'SmartPlug', 'name': 'Server', 'state': {'alert': 'none', 'on': True, 'reachable': True}, 'swversion': '', 'type': 'Smart plug', 'uniqueid': '00:0d:6f:00:0b:7a:53:44-01'}, '10': {'ctmax': 500, 'ctmin': 153, 'etag': '1079e879e8b1e5de80d29994e662c991', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT010', 'name': 'Dining Table 3', 'state': {'alert': 'none', 'bri': 112, 'colormode': 'hs', 'ct': 497, 'effect': 'none', 'hue': 7170, 'on': True, 'reachable': True, 'sat': 225, 'xy': [0.528654, 0.414927]}, 'swversion': '1.15.2_r19181', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:02:3c:95:af-0b'}, '11': {'etag': '5f0ae5650d108fe0d351e30e49f975eb', 'hascolor': False, 'manufacturername': 'Philips', 'modelid': 'LWB006', 'name': 'Bathroom', 'state': {'alert': 'none', 'bri': 254, 'on': True, 'reachable': True}, 'swversion': '5.38.2.19136', 'type': 'Dimmable light', 'uniqueid': '00:17:88:01:10:57:77:0d-0b'}, '12': {'etag': 'e79e6e89bf41dab6cd64b583fa4923e9', 'hascolor': False, 'manufacturername': 'Philips', 'modelid': 'LWB006', 'name': 'Storage Room', 'state': {'alert': 'none', 'bri': 254, 'on': False, 'reachable': True}, 'swversion': '5.38.2.19136', 'type': 'Dimmable light', 'uniqueid': '00:17:88:01:10:57:c9:d9-0b'}, '13': {'etag': '5b0edae350ce21c184d5eda328ce1d0c', 'hascolor': False, 'manufacturername': 'Philips', 'modelid': 'LWB004', 'name': 'Toilet', 'state': {'alert': 'none', 'bri': 0, 'on': False, 'reachable': True}, 'swversion': '5.38.2.19136', 'type': 'Dimmable light', 'uniqueid': '00:17:88:01:00:d7:d2:8c-0b'}, '14': {'ctmax': 500, 'ctmin': 153, 'etag': 'f5ec9634d75570ea10068680b3fd0e0c', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Bedroom 1', 'state': {'alert': 'none', 'bri': 254, 'colormode': 'ct', 'ct': 366, 'effect': 'none', 'hue': 14956, 'on': False, 'reachable': True, 'sat': 140, 'xy': [0.458892, 0.411327]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:f0:96:6d-0b'}, '15': {'ctmax': 500, 'ctmin': 153, 'etag': 'f5ec9634d75570ea10068680b3fd0e0c', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Bedroom 2', 'state': {'alert': 'none', 'bri': 0, 'colormode': 'ct', 'ct': 366, 'effect': 'none', 'hue': 14956, 'on': False, 'reachable': True, 'sat': 140, 'xy': [0.458892, 0.411327]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:f0:8f:cf-0b'}, '16': {'ctmax': 500, 'ctmin': 153, 'etag': 'f5ec9634d75570ea10068680b3fd0e0c', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Bedroom 3', 'state': {'alert': 'none', 'bri': 0, 'colormode': 'ct', 'ct': 366, 'effect': 'none', 'hue': 14956, 'on': False, 'reachable': True, 'sat': 140, 'xy': [0.458892, 0.411327]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:f0:93:f7-0b'}, '17': {'ctmax': 500, 'ctmin': 153, 'etag': '13ba20e780b7c0245ce5ab1d01a067d3', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Edit Room 2', 'state': {'alert': 'none', 'bri': 0, 'colormode': 'ct', 'ct': 366, 'effect': 'none', 'hue': 14956, 'on': False, 'reachable': True, 'sat': 140, 'xy': [0.458892, 0.411327]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:02:23:d7:99-0b'}, '18': {'ctmax': 500, 'ctmin': 153, 'etag': '13ba20e780b7c0245ce5ab1d01a067d3', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Edit Room 3', 'state': {'alert': 'none', 'bri': 0, 'colormode': 'ct', 'ct': 366, 'effect': 'none', 'hue': 14956, 'on': False, 'reachable': True, 'sat': 140, 'xy': [0.458892, 0.411327]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:02:b0:f9:33-0b'}, '19': {'ctmax': 500, 'ctmin': 153, 'etag': '1d7be8e6ff66d43646a7d15d6516d66e', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Hall 3', 'state': {'alert': 'none', 'bri': 254, 'colormode': 'ct', 'ct': 366, 'effect': 'none', 'hue': 14956, 'on': False, 'reachable': True, 'sat': 140, 'xy': [0.458892, 0.411327]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:d7:c1:f8-0b'}, '2': {'etag': '45d61e96b5d9f53abd9457fd3f33ca92', 'hascolor': False, 'manufacturername': 'Heiman', 'modelid': 'SmartPlug', 'name': 'Media System', 'state': {'alert': 'none', 'on': True, 'reachable': True}, 'swversion': '', 'type': 'Smart plug', 'uniqueid': '00:0d:6f:00:0b:7a:64:29-01'}, '20': {'ctmax': 500, 'ctmin': 153, 'etag': '1d7be8e6ff66d43646a7d15d6516d66e', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Hall 4', 'state': {'alert': 'none', 'bri': 254, 'colormode': 'ct', 'ct': 366, 'effect': 'none', 'hue': 14956, 'on': False, 'reachable': True, 'sat': 140, 'xy': [0.458892, 0.411327]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:f0:2e:fb-0b'}, '21': {'ctmax': 500, 'ctmin': 153, 'etag': 'd4365c84d680422898682fb506bc38df', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Living Room 1', 'state': {'alert': 'none', 'bri': 112, 'colormode': 'hs', 'ct': 497, 'effect': 'none', 'hue': 12510, 'on': True, 'reachable': True, 'sat': 226, 'xy': [0.528914, 0.414896]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:f1:3f:6a-0b'}, '22': {'ctmax': 500, 'ctmin': 153, 'etag': '8dcbf62729f731d9182ee505c42e0920', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Living Room 2', 'state': {'alert': 'none', 'bri': 112, 'colormode': 'hs', 'ct': 497, 'effect': 'none', 'hue': 12510, 'on': True, 'reachable': True, 'sat': 226, 'xy': [0.528914, 0.414896]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:d7:c3:dd-0b'}, '23': {'ctmax': 500, 'ctmin': 153, 'etag': '968ab63671c7ac62272b420af5ddbb58', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Living Room 3', 'state': {'alert': 'none', 'bri': 112, 'colormode': 'hs', 'ct': 497, 'effect': 'none', 'hue': 12510, 'on': True, 'reachable': True, 'sat': 226, 'xy': [0.528914, 0.414896]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:f1:46:ad-0b'}, '24': {'ctmax': 500, 'ctmin': 153, 'etag': '3af71d5a1a93e083fb3948b932748137', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Living Room 4', 'state': {'alert': 'none', 'bri': 112, 'colormode': 'hs', 'ct': 497, 'effect': 'none', 'hue': 12510, 'on': True, 'reachable': True, 'sat': 226, 'xy': [0.528914, 0.414896]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:f0:2e:83-0b'}, '25': {'ctmax': 500, 'ctmin': 153, 'etag': '3af71d5a1a93e083fb3948b932748137', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Living Room 5', 'state': {'alert': 'none', 'bri': 112, 'colormode': 'hs', 'ct': 497, 'effect': 'none', 'hue': 12510, 'on': True, 'reachable': True, 'sat': 226, 'xy': [0.528914, 0.414896]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:f0:24:03-0b'}, '26': {'ctmax': 500, 'ctmin': 153, 'etag': '17a94b82b2e3a71c996b57c7d730c600', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Kitchen 1', 'state': {'alert': 'none', 'bri': 128, 'colormode': 'ct', 'ct': 500, 'effect': 'none', 'hue': 12510, 'on': False, 'reachable': True, 'sat': 226, 'xy': [0.528914, 0.414896]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:02:5e:0b:a3-0b'}, '27': {'ctmax': 500, 'ctmin': 153, 'etag': '17a94b82b2e3a71c996b57c7d730c600', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Kitchen 2', 'state': {'alert': 'none', 'bri': 128, 'colormode': 'ct', 'ct': 500, 'effect': 'none', 'hue': 12510, 'on': False, 'reachable': True, 'sat': 226, 'xy': [0.528914, 0.414896]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:02:5e:97:ae-0b'}, '28': {'ctmax': 500, 'ctmin': 153, 'etag': '17a94b82b2e3a71c996b57c7d730c600', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Kitchen 3', 'state': {'alert': 'none', 'bri': 128, 'colormode': 'ct', 'ct': 500, 'effect': 'none', 'hue': 12510, 'on': False, 'reachable': True, 'sat': 226, 'xy': [0.528914, 0.414896]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:02:5e:52:0e-0b'}, '29': {'etag': '17a94b82b2e3a71c996b57c7d730c600', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LLC010', 'name': 'Kitchen Living Colors', 'state': {'alert': 'none', 'bri': 128, 'colormode': 'xy', 'effect': 'none', 'hue': 47404, 'on': False, 'reachable': True, 'sat': 254, 'xy': [0.14487, 0.082584]}, 'swversion': '5.23.1.13452', 'type': 'Color light', 'uniqueid': '00:17:88:01:00:12:4a:e9-0b'}, '3': {'etag': 'e8066dd6fbfd9bc082a48e6957dd0cf3', 'hascolor': False, 'manufacturername': 'Heiman', 'modelid': 'SmartPlug', 'name': 'Heatpump', 'state': {'alert': 'none', 'on': True, 'reachable': True}, 'swversion': '', 'type': 'Smart plug', 'uniqueid': '00:0d:6f:00:0b:7a:75:d3-01'}, '4': {'ctmax': 500, 'ctmin': 153, 'etag': '13ba20e780b7c0245ce5ab1d01a067d3', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Edit Room 1', 'state': {'alert': 'none', 'bri': 0, 'colormode': 'ct', 'ct': 366, 'effect': 'none', 'hue': 14956, 'on': False, 'reachable': True, 'sat': 140, 'xy': [0.458892, 0.411327]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:02:5f:11:eb-0b'}, '6': {'ctmax': 500, 'ctmin': 153, 'etag': '1d7be8e6ff66d43646a7d15d6516d66e', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Hall Front 2', 'state': {'alert': 'none', 'bri': 254, 'colormode': 'ct', 'ct': 366, 'effect': 'none', 'hue': 14956, 'on': False, 'reachable': True, 'sat': 140, 'xy': [0.458892, 0.411327]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:f1:3b:45-0b'}, '7': {'ctmax': 500, 'ctmin': 153, 'etag': '1d7be8e6ff66d43646a7d15d6516d66e', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT003', 'name': 'Hall Front 1', 'state': {'alert': 'none', 'bri': 254, 'colormode': 'ct', 'ct': 500, 'effect': 'none', 'hue': 12510, 'on': False, 'reachable': True, 'sat': 226, 'xy': [0.528914, 0.414896]}, 'swversion': '5.50.1.19085', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:00:f1:3b:da-0b'}, '8': {'ctmax': 500, 'ctmin': 153, 'etag': '3dea5ab0b43e2e0a929119c4398dc206', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT010', 'name': 'Dining Table 1', 'state': {'alert': 'none', 'bri': 112, 'colormode': 'hs', 'ct': 497, 'effect': 'none', 'hue': 7170, 'on': True, 'reachable': True, 'sat': 225, 'xy': [0.528654, 0.414927]}, 'swversion': '1.15.2_r19181', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:02:8e:13:7d-0b'}, '9': {'ctmax': 500, 'ctmin': 153, 'etag': '1079e879e8b1e5de80d29994e662c991', 'hascolor': True, 'manufacturername': 'Philips', 'modelid': 'LCT010', 'name': 'Dining Table 2', 'state': {'alert': 'none', 'bri': 112, 'colormode': 'hs', 'ct': 497, 'effect': 'none', 'hue': 7170, 'on': True, 'reachable': True, 'sat': 225, 'xy': [0.528654, 0.414927]}, 'swversion': '1.15.2_r19181', 'type': 'Extended color light', 'uniqueid': '00:17:88:01:02:f6:63:f8-0b'}}, 'resourcelinks': {}, 'rules': {}, 'schedules': {}, 'sensors': {'15': {'config': {'on': True, 'reachable': True}, 'ep': 1, 'etag': 'a99e5bc463d15c23af7e89946e784cca', 'manufacturername': 'Heiman', 'modelid': 'SmartPlug', 'name': 'Consumption 15', 'state': {'consumption': 11342, 'lastupdated': '2018-03-12T19:19:08'}, 'type': 'ZHAConsumption', 'uniqueid': '00:0d:6f:00:0b:7a:64:29-01-0702'}, '16': {'config': {'on': True, 'reachable': True}, 'ep': 1, 'etag': '96e71c7db4685b334d3d0decc3f11868', 'manufacturername': 'Heiman', 'modelid': 'SmartPlug', 'name': 'Power 16', 'state': {'current': 34, 'lastupdated': '2018-03-12T19:22:13', 'power': 64, 'voltage': 231}, 'type': 'ZHAPower', 'uniqueid': '00:0d:6f:00:0b:7a:64:29-01-0b04'}, '17': {'config': {'on': True, 'reachable': True}, 'ep': 1, 'etag': '8b785d01fe8fd0c454e95ae326569fe4', 'manufacturername': 'Heiman', 'modelid': 'SmartPlug', 'name': 'Consumption 17', 'state': {'consumption': 15399, 'lastupdated': '2018-03-12T19:22:42'}, 'type': 'ZHAConsumption', 'uniqueid': '00:0d:6f:00:0b:7a:75:d3-01-0702'}, '18': {'config': {'on': True, 'reachable': True}, 'ep': 1, 'etag': 'f26b7cf762cd79854ebc9ab5ce6b8342', 'manufacturername': 'Heiman', 'modelid': 'SmartPlug', 'name': 'Power 18', 'state': {'current': 33, 'lastupdated': '2018-03-12T19:22:58', 'power': 71, 'voltage': 230}, 'type': 'ZHAPower', 'uniqueid': '00:0d:6f:00:0b:7a:75:d3-01-0b04'}, '19': {'config': {'on': True, 'reachable': True}, 'ep': 1, 'etag': '9e895d51d99bf47af592e3ed9f7af2d7', 'manufacturername': 'Heiman', 'modelid': 'SmartPlug', 'name': 'Consumption 19', 'state': {'consumption': 0, 'lastupdated': '1969-12-31T23:00:00'}, 'type': 'ZHAConsumption', 'uniqueid': '00:0d:6f:00:0b:7a:53:44-01-0702'}, '20': {'config': {'on': True, 'reachable': True}, 'ep': 1, 'etag': '149dec5afe7181f462e8523a3ae5b93a', 'manufacturername': 'Heiman', 'modelid': 'SmartPlug', 'name': 'Power 20', 'state': {'current': 0, 'lastupdated': '2018-03-12T19:23:56', 'power': 0, 'voltage': 229}, 'type': 'ZHAPower', 'uniqueid': '00:0d:6f:00:0b:7a:53:44-01-0b04'}, '21': {'config': {'battery': 0, 'offset': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '2687d922a64aeccf382b6a98851a6079', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Bedroom Multi Sensor', 'state': {'lastupdated': '2018-03-12T18:43:58', 'temperature': 2000}, 'type': 'ZHATemperature', 'uniqueid': '00:15:8d:00:01:72:01:03-01-0402'}, '22': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '2687d922a64aeccf382b6a98851a6079', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Bedroom Multi Sensor', 'state': {'humidity': 5309, 'lastupdated': '2018-03-12T18:43:58'}, 'type': 'ZHAHumidity', 'uniqueid': '00:15:8d:00:01:72:01:03-01-0405'}, '23': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '2687d922a64aeccf382b6a98851a6079', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Bedroom Multi Sensor', 'state': {'lastupdated': '2018-03-12T18:43:58', 'pressure': 987}, 'type': 'ZHAPressure', 'uniqueid': '00:15:8d:00:01:72:01:03-01-0403'}, '24': {'config': {'battery': 0, 'offset': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '5f10bce750ff6829fe4e405e957e2d56', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Bathroom Multi Sensor', 'state': {'lastupdated': '2018-03-12T19:23:17', 'temperature': 1954}, 'type': 'ZHATemperature', 'uniqueid': '00:15:8d:00:01:a4:bb:0b-01-0402'}, '25': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '5f10bce750ff6829fe4e405e957e2d56', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Bathroom Multi Sensor', 'state': {'humidity': 5638, 'lastupdated': '2018-03-12T19:23:17'}, 'type': 'ZHAHumidity', 'uniqueid': '00:15:8d:00:01:a4:bb:0b-01-0405'}, '26': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '5f10bce750ff6829fe4e405e957e2d56', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Bathroom Multi Sensor', 'state': {'lastupdated': '2018-03-12T19:23:17', 'pressure': 987}, 'type': 'ZHAPressure', 'uniqueid': '00:15:8d:00:01:a4:bb:0b-01-0403'}, '27': {'config': {'battery': 0, 'offset': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '6569fde455b9a6e02f57e112a038fd93', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Edit Room Multi Sensor', 'state': {'lastupdated': '2018-03-12T18:40:11', 'temperature': 2078}, 'type': 'ZHATemperature', 'uniqueid': '00:15:8d:00:01:b7:e0:8a-01-0402'}, '28': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '6569fde455b9a6e02f57e112a038fd93', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Edit Room Multi Sensor', 'state': {'humidity': 4601, 'lastupdated': '2018-03-12T18:40:11'}, 'type': 'ZHAHumidity', 'uniqueid': '00:15:8d:00:01:b7:e0:8a-01-0405'}, '29': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '6569fde455b9a6e02f57e112a038fd93', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Edit Room Multi Sensor', 'state': {'lastupdated': '2018-03-12T18:40:11', 'pressure': 987}, 'type': 'ZHAPressure', 'uniqueid': '00:15:8d:00:01:b7:e0:8a-01-0403'}, '3': {'config': {'battery': 100, 'on': True, 'reachable': True, 'temperature': 0}, 'ep': 1, 'etag': '40e429757ee84ee8cc71721fd8028ac0', 'manufacturername': 'LUMI', 'mode': 1, 'modelid': 'lumi.sensor_switch', 'name': 'Switch 3', 'state': {'buttonevent': 1002, 'lastupdated': '2018-03-10T20:38:02'}, 'type': 'ZHASwitch', 'uniqueid': '00:15:8d:00:01:64:40:b5-01-0006'}, '30': {'config': {'battery': 0, 'offset': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '4a5c1afd2d25c9512ec4f86742d1b67f', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Storage Multi Sensor', 'state': {'lastupdated': '2018-03-12T18:47:51', 'temperature': 2222}, 'type': 'ZHATemperature', 'uniqueid': '00:15:8d:00:01:f5:20:4c-01-0402'}, '31': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '4a5c1afd2d25c9512ec4f86742d1b67f', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Storage Multi Sensor', 'state': {'humidity': 4438, 'lastupdated': '2018-03-12T18:47:51'}, 'type': 'ZHAHumidity', 'uniqueid': '00:15:8d:00:01:f5:20:4c-01-0405'}, '32': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '4a5c1afd2d25c9512ec4f86742d1b67f', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Storage Multi Sensor', 'state': {'lastupdated': '2018-03-12T18:47:51', 'pressure': 987}, 'type': 'ZHAPressure', 'uniqueid': '00:15:8d:00:01:f5:20:4c-01-0403'}, '33': {'config': {'battery': 0, 'offset': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': 'fcb71d42840a13abfba82f6836ca0b88', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Living Room Multi Sensor', 'state': {'lastupdated': '2018-03-12T18:44:09', 'temperature': 2145}, 'type': 'ZHATemperature', 'uniqueid': '00:15:8d:00:01:fa:98:3a-01-0402'}, '34': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': 'fcb71d42840a13abfba82f6836ca0b88', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Living Room Multi Sensor', 'state': {'humidity': 6224, 'lastupdated': '2018-03-12T18:44:09'}, 'type': 'ZHAHumidity', 'uniqueid': '00:15:8d:00:01:fa:98:3a-01-0405'}, '35': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': 'fcb71d42840a13abfba82f6836ca0b88', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Living Room Multi Sensor', 'state': {'lastupdated': '2018-03-12T18:44:09', 'pressure': 987}, 'type': 'ZHAPressure', 'uniqueid': '00:15:8d:00:01:fa:98:3a-01-0403'}, '36': {'config': {'battery': 0, 'offset': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '0c5f9e1dfb7ba636ac3b22b2ff152085', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Server Room Multi Sensor', 'state': {'lastupdated': '2018-03-12T18:44:07', 'temperature': 2598}, 'type': 'ZHATemperature', 'uniqueid': '00:15:8d:00:02:28:86:3f-01-0402'}, '37': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '4c4d07e9e2bd1cbfc375fec0fe2fc863', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Server Room Multi Sensor', 'state': {'humidity': 3514, 'lastupdated': '2018-03-12T18:44:08'}, 'type': 'ZHAHumidity', 'uniqueid': '00:15:8d:00:02:28:86:3f-01-0405'}, '38': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '4c4d07e9e2bd1cbfc375fec0fe2fc863', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Server Room Multi Sensor', 'state': {'lastupdated': '2018-03-12T18:44:08', 'pressure': 988}, 'type': 'ZHAPressure', 'uniqueid': '00:15:8d:00:02:28:86:3f-01-0403'}, '39': {'config': {'battery': 0, 'offset': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '0ea89e9d32899529777ea7ccc19874d1', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Living Room Multi Sensor 2', 'state': {'lastupdated': '2018-03-12T18:45:25', 'temperature': 2074}, 'type': 'ZHATemperature', 'uniqueid': '00:15:8d:00:02:01:89:ba-01-0402'}, '40': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '0ad5ca9875c7d0589117abb59f16f7a6', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Living Room Multi Sensor 2', 'state': {'humidity': 6702, 'lastupdated': '2018-03-12T18:45:26'}, 'type': 'ZHAHumidity', 'uniqueid': '00:15:8d:00:02:01:89:ba-01-0405'}, '41': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '0ad5ca9875c7d0589117abb59f16f7a6', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Living Room Multi Sensor 2', 'state': {'lastupdated': '2018-03-12T18:45:26', 'pressure': 988}, 'type': 'ZHAPressure', 'uniqueid': '00:15:8d:00:02:01:89:ba-01-0403'}, '42': {'config': {'battery': 0, 'offset': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': 'e5a0708e2309b81e2ba3c062eaefd624', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Fridge Multi Sensor', 'state': {'lastupdated': '2018-03-12T19:18:55', 'temperature': 846}, 'type': 'ZHATemperature', 'uniqueid': '00:15:8d:00:01:fa:5d:33-01-0402'}, '43': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': 'e5a0708e2309b81e2ba3c062eaefd624', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Fridge Multi Sensor', 'state': {'humidity': 3104, 'lastupdated': '2018-03-12T19:18:55'}, 'type': 'ZHAHumidity', 'uniqueid': '00:15:8d:00:01:fa:5d:33-01-0405'}, '44': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': 'e5a0708e2309b81e2ba3c062eaefd624', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Fridge Multi Sensor', 'state': {'lastupdated': '2018-03-12T19:18:55', 'pressure': 988}, 'type': 'ZHAPressure', 'uniqueid': '00:15:8d:00:01:fa:5d:33-01-0403'}, '45': {'config': {'battery': 0, 'offset': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '7f51f855edb04bddc28c8305d4fa050e', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Freezer Multi Sensor', 'state': {'lastupdated': '2018-03-12T19:18:45', 'temperature': -1378}, 'type': 'ZHATemperature', 'uniqueid': '00:15:8d:00:02:27:39:90-01-0402'}, '46': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '7f51f855edb04bddc28c8305d4fa050e', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Freezer Multi Sensor', 'state': {'humidity': 3380, 'lastupdated': '2018-03-12T19:18:45'}, 'type': 'ZHAHumidity', 'uniqueid': '00:15:8d:00:02:27:39:90-01-0405'}, '47': {'config': {'battery': 0, 'on': True, 'reachable': True}, 'ep': 1, 'etag': '7f51f855edb04bddc28c8305d4fa050e', 'manufacturername': 'LUMI', 'modelid': 'lumi.weather', 'name': 'Freezer Multi Sensor', 'state': {'lastupdated': '2018-03-12T19:18:45', 'pressure': 988}, 'type': 'ZHAPressure', 'uniqueid': '00:15:8d:00:02:27:39:90-01-0403'}, '48': {'config': {'battery': 0, 'duration': 60, 'on': True, 'reachable': True, 'temperature': 0}, 'ep': 1, 'etag': '3cfa1a262129de33be720877e22631d0', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_motion', 'name': 'Hall Motion Sensor', 'state': {'lastupdated': '2018-03-12T19:16:48', 'presence': False}, 'type': 'ZHAPresence', 'uniqueid': '00:15:8d:00:01:5d:bc:da-01-0406'}, '49': {'config': {'battery': 0, 'duration': 60, 'on': True, 'reachable': True, 'temperature': 0}, 'ep': 1, 'etag': '40e429757ee84ee8cc71721fd8028ac0', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_motion', 'name': 'Edit Room Motion Sensor', 'state': {'lastupdated': '2018-03-11T16:43:24', 'presence': False}, 'type': 'ZHAPresence', 'uniqueid': '00:15:8d:00:01:26:7a:ca-01-0406'}, '50': {'config': {'battery': 0, 'duration': 60, 'on': True, 'reachable': True, 'temperature': 0}, 'ep': 1, 'etag': '3cfa1a262129de33be720877e22631d0', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_motion', 'name': 'Storage Room Motion Sensor', 'state': {'lastupdated': '2018-03-12T19:16:49', 'presence': False}, 'type': 'ZHAPresence', 'uniqueid': '00:15:8d:00:01:b1:5a:57-01-0406'}, '51': {'config': {'battery': 0, 'duration': 60, 'on': True, 'reachable': True, 'temperature': 0}, 'ep': 1, 'etag': '8d7d613934dda628bca1ac2656847c15', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_motion', 'name': 'Bedroom Motion Sensor', 'state': {'lastupdated': '2018-03-12T19:17:52', 'presence': False}, 'type': 'ZHAPresence', 'uniqueid': '00:15:8d:00:01:a8:e3:b9-01-0406'}, '52': {'config': {'battery': 0, 'duration': 60, 'on': True, 'reachable': True, 'temperature': 0}, 'ep': 1, 'etag': '6c81043e6efe13e3967f352632cd32ff', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_motion', 'name': 'Kitchen Motion Sensor', 'state': {'lastupdated': '2018-03-12T18:56:38', 'presence': False}, 'type': 'ZHAPresence', 'uniqueid': '00:15:8d:00:01:b1:5a:73-01-0406'}, '53': {'config': {'battery': 0, 'duration': 60, 'on': True, 'reachable': True, 'temperature': 0}, 'ep': 1, 'etag': '29647304431ed0400bdd6c76affb263c', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_motion', 'name': 'Living Room Motion Sensor 2', 'state': {'lastupdated': '2018-03-12T19:16:42', 'presence': False}, 'type': 'ZHAPresence', 'uniqueid': '00:15:8d:00:01:dc:23:3c-01-0406'}, '54': {'config': {'battery': 0, 'duration': 60, 'on': True, 'reachable': True, 'temperature': 0}, 'ep': 1, 'etag': '92434baa2a93a98e50b3aff433e67bb2', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_motion', 'name': 'Living Room Motion Sensor 1', 'state': {'lastupdated': '2018-03-12T19:16:08', 'presence': False}, 'type': 'ZHAPresence', 'uniqueid': '00:15:8d:00:01:dc:03:19-01-0406'}, '55': {'config': {'battery': 0, 'duration': 60, 'on': True, 'reachable': True, 'temperature': 0}, 'ep': 1, 'etag': '13db2d4a1b965169a29b3187f0f3104f', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_motion', 'name': 'Toilet Motion Sensor', 'state': {'lastupdated': '2018-03-11T20:15:18', 'presence': False}, 'type': 'ZHAPresence', 'uniqueid': '00:15:8d:00:01:b1:5a:75-01-0406'}, '56': {'config': {'battery': 100, 'group': '1832', 'on': True, 'reachable': True}, 'ep': 2, 'etag': 'fbec62d1de77c7ca47729102de023a20', 'manufacturername': 'Philips', 'mode': 1, 'modelid': 'RWL021', 'name': 'Bedroom Dimmer Switch', 'state': {'buttonevent': 1002, 'lastupdated': '2018-03-11T06:02:38'}, 'swversion': '5.45.1.17846', 'type': 'ZHASwitch', 'uniqueid': '00:17:88:01:10:49:cc:26-02-fc00'}, '57': {'config': {'battery': 100, 'group': '15289', 'on': True, 'reachable': True}, 'ep': 2, 'etag': '98a384c8a48662a49320ac17b2cf9ddd', 'manufacturername': 'Philips', 'mode': 1, 'modelid': 'RWL021', 'name': 'Living Room Dimmer Switch', 'state': {'buttonevent': 1002, 'lastupdated': '2018-03-10T13:12:07'}, 'swversion': '5.45.1.17846', 'type': 'ZHASwitch', 'uniqueid': '00:17:88:01:02:0e:c6:85-02-fc00'}, '58': {'config': {'battery': 100, 'on': True, 'reachable': True, 'temperature': 2500}, 'ep': 1, 'etag': '1b34785535b14192115df92860951b57', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_magnet.aq2', 'name': 'Balcony Door Sensor', 'state': {'lastupdated': '2018-03-12T18:49:30', 'open': False}, 'type': 'ZHAOpenClose', 'uniqueid': '00:15:8d:00:01:de:5d:4b-01-0006'}, '7': {'config': {'battery': 0, 'duration': 60, 'on': True, 'reachable': True, 'temperature': 0}, 'ep': 1, 'etag': '6e4da475da2b865fe870ecdc658ecaa0', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_motion', 'name': 'Bathroom Motion Sensor', 'state': {'lastupdated': '2018-03-12T19:21:10', 'presence': False}, 'type': 'ZHAPresence', 'uniqueid': '00:15:8d:00:01:5d:bd:45-01-0406'}, '8': {'config': {'battery': 88, 'on': True, 'reachable': True, 'temperature': 2800}, 'ep': 1, 'etag': '2ed482aa2743d67fea353bf0a1803dae', 'manufacturername': 'LUMI', 'modelid': 'lumi.sensor_magnet.aq2', 'name': 'Front Door', 'state': {'lastupdated': '2018-03-12T18:42:02', 'open': False}, 'type': 'ZHAOpenClose', 'uniqueid': '00:15:8d:00:01:d3:ac:48-01-0006'}}}

@geelenbert you could have filtered it ;). But that should indeed help. I'll get back to you tonight. I will move this discussion over the issue in my repository referenced a few comments above. You can expect a ping ;)

Are the units for power and consumption standardised between different manufacturers?

If current, power and voltage are 0.x should I multiply them by 10?
What would be the proper value to expose consumption as?

@Kane610 i would say logical values would be:
Power: W (Watt)
Voltage: V(Volt)
Current: A(Ampere)
Energy (consumption): kWh (Kilo Watt Hour)

Looking at my debug lines, i think the Power and Voltage are in the correct unit and amplification. The current i'm not really sure what to make of it. The energy looks like it is in Wh, so this needs to be divided by 1000.

I think maybee @ebaauw would be able to tell if the numbers are the same for all the plugs he has seen so far ?

@geelenbert PR up for home-assistant https://github.com/home-assistant/home-assistant/pull/13218

@Kane610 Cool! This github thing is new for me, but i guess as soon as the pull request is passed by Home Assistant, it will end up in the next release 0.66 ?

@geelenbert yes 👍

I think maybee @ebaauw would be able to tell if the numbers are the same for all the plugs he has seen so far ?

Each plug reports different units, but the REST API should normalise these to:

• consumption: Wh (or 0.001 kWh)
• power: W
• voltage: V
• current: 0.1 A

As ZigBee doesn’t define a standard here (unlike e.g. for temperature, which is in 0.01 degree Celcius), I arbritarily used the resolution as displayed by Eve (my favourite HomeKit app). Happy to change that, but the plugs I’ve seen don’t report a higher resolution. Except maybe for voltage, but I find the precision is at best around +/- 1%, so changing to 0.1 or 0.01V wouldn’t add much value, at least when reporting mains power. We might want to change that if we’d want to report battery voltage.

@manup still struggling with Harmony. My Xiaomi smart plug is connected and works perfectly in DECONZ (turn ON/OFF). But I have two problems: In Harmony App I can turn the plug OFF but when I turn it ON with Harmony it is shown as ON in DECONZ (with 0%) and it is not powering on. In Amazon Alexa it is not show as a light or as a switch but as a Device. Any ideas on this?

Hi @ebaauw ,
based on your recommendation I ordered two of the heiman plugs.
I added them to the latest deconz beta (.20) with the latest firmware installed to the conbee 0x261f0500.

They came up inconsistent in Phoscon (one smartplug and one unknown - both appered under "Lights"):

Not sure whether this is bad or not..

Via REST I only see two new sensors - one is ZHAPower and one is ZHAConsumption, so I assume the corresponding ones of the second plug are missing, right? They are both invisible in Phoscon.

    "22": {
        "config": {
            "on": true,
            "reachable": true
        },
        "ep": 1,
        "etag": "ebf0583f9fd06308c15430107ae60cb7",
        "manufacturername": "Heiman",
        "modelid": "SmartPlug",
        "name": "SmartPlug",
        "state": {
            "consumption": 0,
            "lastupdated": "2018-04-12T16:25:03",
            "power": 0
        },
        "type": "ZHAConsumption",
        "uniqueid": "00:0d:6f:00:0b:7a:7f:d2-01-0702"
    },
    "23": {
        "config": {
            "on": true,
            "reachable": true
        },
        "ep": 1,
        "etag": "60ceb94523bfbfefa26867996c11e6d1",
        "manufacturername": "Heiman",
        "modelid": "SmartPlug",
        "name": "SmartPlug",
        "state": {
            "current": 0,
            "lastupdated": "2018-04-12T16:26:16",
            "power": 0,
            "voltage": 230
        },
        "type": "ZHAPower",
        "uniqueid": "00:0d:6f:00:0b:7a:7f:d2-01-0b04"
    }

Aisde from that, both plugs emit a very annoying high pitch noise which unfortunately renders them unusable in pretty much all inhabited rooms..

Do you have the same experience?

They came up inconsistent in Phoscon (one smartplug and one unknown - both appered under "Lights"):
Not sure whether this is bad or not..

Looks like the _Basic_ cluster of the second one hasn’t been read fully. The REST API need the _Model Identifier_ before it creates the /sensors resources. This is shown as _Product_ in the Phoscon app. You could try and read the _Basic_ cluster attributes from the deCONZ GUI while the network is open, or reset and re-pair the plug.

I assume the corresponding ones of the second plug are missing, right?

Yes, the resources are for the same plug (see the MAC address in the uniqueid).

Aisde from that, both plugs emit a very annoying high pitch noise which unfortunately renders them unusable in pretty much all inhabited rooms..

That sucks

Do you have the same experience?

No, I don’t.

I have the same high pitch noise. You just have to wait some years. The older you get the less noise you hear :stuck_out_tongue_closed_eyes:

Maybe my ears are just old enough. I’ll ask my kids...

The problem with the second switch was that I added it via "add new light" (neues licht verbinden) after the first plug appeared in that section. That probably messed it up.
I was not able to fix this using phoscon or rest, unfortunately because deleting the device did not actually delete it. After resetting the plug I started the pairing process again from phoscons sensor list but it ended without result. Instead, the "old" plug entry just reappeared in the lights section.

After digging around a little bit in previous issues, I learned that deconz is not deleting the devices from its internal DB. So I removed the corresponding entry (marked as status 'deleted') from there and after another pairing process the plug was added properly along with its corresponding sensors.

It feels that I hit several bugs in deconz here...
1) it should not matter from where I add a new device. it should discover what features the device brings with it. The plugs are lights and sensors at the same time, so it should not matter from which screen they are added
2) deleting and re-adding a device should do what it says, otherwise it is not possible to reinitialize a device because deconz is just re-using old data.

Should I open issues for this or is this "works as designed"?

Ad 1. I don’t use Phoscon and haven’t really looked into it, but I do think add new light and add new sensor actually make the same REST API call to open the network. In the REST API plugin, discovery of /lights resources differs from discovery of /sensors resources. Lights are recognised by device type, by being mains powered, and by (server) clusters. Sensors are recognised by MAC address prefix, by manufacturer code, by model, and by clusters. This means sensor resources are created later than light resources, after the basic cluster had been read (for the model). Xiaomi devices are particularly tricky, as they don’t always advertise their clusters, requiring a first report before the plugin “sees” the cluster.

Ad 2. Valid point. I don’t think the current behaviour should be changed, but I would welcome an additional “hard delete” REST API call. Could simply be an optional body {“harddelete”: true} to the existing DELETE calls. On the other hand, I would only really use this during beta, while we’re still figuring out how best to support all the functionally cool, but technically horrible, devices.

Maybe my ears are just old enough. I’ll ask my kids...

There's an almost inaudible hum when you place your ear next to the plug while it's on, but no high pitch noise. You really need to be within 10cm of the plug to hear the hum.

Hmm, my two plugs are audible to mid-30 yo people from several meters distance. The high pitch noises even alternate between different frequencies.
It is also irrelevant whether it is switched on or off, so I guess it has something to do with the voltage transformation for the zigbee transmitter.

Just received the new innr SP 120 (https://shop.innrlighting.com/en/shop/113/smart-plug). It's cute, even smaller than the EU Elgato Eve Energy. And it seems to provide everything one could wish for in a smart plug:

Yes, support for power measurement, groups, scenes, and even OTA firmware updates! The _Level_ cluster seems functional, but the plug seems to provide full power at any level >= 1. The _Electrical Measurement_ cluster reports Voltage, Current, and Power. It supports attribute reporting for all of these, as well as for the _OnOff_ attribute of the _OnOff_ cluster (and even for _Level_). It has a control light that's blue when the plug is on, and red when the plug is off. It blinks on _Identify_.

I don't know why deCONZ shows the 0x0702 cluster as unknown. I double-checked that this cluster shows as _Simple Metering_ for other devices. @manup, any idea? Maybe a mandatory attribute is missing?

Good news! How is the noise level on these?

I don't hear anything when the attached fan is switched off (and the plug is on). Also, I only hear the fan when it's switched on. I need to see if I can find a quiet load...

I don't know why deCONZ shows the 0x0702 cluster as unknown. I double-checked that this cluster shows as Simple Metering for other devices. @manup, any idea? Maybe a mandatory attribute is missing?

Likely either the server or client cluster definition is missing in the ZCLDB, it can be empty but the client/server XML elements must be defined otherwise unknown will be shown.

I cannot find any error in the ZCLDB (it's the general.xml as distributed by deCONZ). The 0702 cluster is shown correctly for other nodes. I edited general.xml with an almost empty cluster definition (just the description and the server and client tags, but no attributes nor commands), but it still shows as unknown.

I whitelisted the plug, and deCONZ creates the ZAHConsumption and ZHAPower sensor resources as expected. The ZHAPower's state is updated; the ZHAConsumption's state isn't.

$ ph get /sensors/8
{
  "config": {
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "6864ab2df3540444365bc2645233dbef",
  "manufacturername": "innr",
  "modelid": "SP 120",
  "name": "Consumption 8",
  "state": {
    "consumption": null,
    "lastupdated": "none",
    "power": null
  },
  "swversion": "2.0",
  "type": "ZHAConsumption",
  "uniqueid": "00:15:8d:00:02:17:ad:31-01-0702"
}
$ ph get /sensors/9
{
  "config": {
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "9e34e2c8dbeadf47604fa9044cfb7b80",
  "manufacturername": "innr",
  "modelid": "SP 120",
  "name": "Power 9",
  "state": {
    "current": 13,
    "lastupdated": "2018-06-08T08:08:16",
    "power": 31,
    "voltage": 236
  },
  "swversion": "2.0",
  "type": "ZHAPower",
  "uniqueid": "00:15:8d:00:02:17:ad:31-01-0b04"
}

Time for some sniffing. deCONZ is polling the 0702 cluster (as expected, since I couldn't setup attribute reporting through the GUI). The plug reports that it doesn't support _Instantaneous Demand_ (state.power) and returns 0 for _Current Summation Delivered_ (state.consumption). I'll keep it running for a while, with a simple fan hooked up, to see if will collect total consumption. EDIT it does!

Checking the deCONZ log:

Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:164 poll node 00:15:8d:00:02:17:ad:31-01-0702
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:164 >>>> Poll ZHAConsumption sensor node Consumption 8
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:164 Idle timer triggered
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:164 Force binding of attribute reporting for node Light 3
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:164 Force read attributes for SensorNode Consumption 8
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:164 don't create binding for attribute reporting of sensor Consumption 8
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:164 Force binding of attribute reporting for node Consumption 8
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:261 read attributes of 0x00158D000217AD31 cluster: 0x0702: [ 10:01:37:262 0x0000 10:01:37:262 0x0400 10:01:37:262 ]
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:262 add task 4183 type 19 to 0x00158D000217AD31 cluster 0x0702 req.id 193
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:262 Poll APS request 193 to 0x00158D000217AD31 cluster: 0x0702
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:362 APS-DATA.request id: 193, addrmode: 0x03, addr: 0x00158d000217ad31, profile: 0x0104, cluster: 0x0702, ep: 0x01 queue: 0 len: 7
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:412 Poll APS confirm 193 status: 0x00
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:412 Erase task req-id: 193, type: 19 zcl seqno: 214 send time 0, profileId: 0x0104, clusterId: 0x0702
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:412 APS-DATA.confirm id: 193, status: 0x00 SUCCESS
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:412 APS-DATA.confirm request id: 193 -> erase from queue
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:436 APS-DATA.indication srcAddr: 0x00158d000217ad31, dstAddrMode: 2, profile: 0x0104, cluster: 0x0702, lqi: 255, rssi: -47
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:437 APS-DATA.request id: 193 erase from queue
Jun 08 10:01:39 pi1 deCONZ[29461]: 10:01:37:437 Node data 0x00158d000217ad31 profileId: 0x0104, clusterId: 0x0702

deCONZ sees the _Read Attributes_ response, but doesn't update the resource. Presumably because it hasn't recognised the cluster through the ZCLDB.

Unlike the other smart plugs, the innr SP 120 uses the ZLL profile. The _Smart Energy_ domain reference is missing from the ZCL profile in the ZCLDB. After copying the line from the ZHA profile to the ZLL profile (line 2130), the 0702 cluster is listed correctly, and state.consumption is updated.

   2125         <profile id="0xc05e" name="Light Link" description="This profile defines device descriptions and standard practices for ZigBee Light Link." version="1.0" rev="15" icon="zll.png">^M
   2126                 <domain-ref name="General" low_bound="0000" />^M
   2127                 <domain-ref name="Light Link" low_bound="1000" />^M
   2128                 <domain-ref name="Lighting" low_bound="0300" />^M
   2129                 <domain-ref name="Measurement and Sensing" low_bound="0400" />^M
   2130                 <domain-ref name="Smart Energy" low_bound="0x0700" />^M
   2131                 <domain-ref name="Manufacturer Specific" low_bound="0xfc00" />^M
   2132                 <device id="0x0000" name="On/off light" description="" icon="dev-on-off-light.png"></device>^M
   2133                 <device id="0x0010" name="On/off plug-in unit" description=""></device>^M
   2134                 <device id="0x0100" name="Dimmable light" description="" icon="dev-on-off-light.png"></device>^M
   2135                 <device id="0x0110" name="Dimmable plug-in unit" description="" icon="dev-on-off-light.png"></device> -->^M
   2136                 <device id="0x0200" name="Color light" description="" icon="dev-on-off-light.png"></device>^M
   2137                 <device id="0x0210" name="Extended color light" description="" icon="dev-on-off-light.png"></device>^M
   2138                 <device id="0x0220" name="Color temperature light" description="" icon="dev-on-off-light.png"></device>^M
   2139                 <device id="0x0800" name="Color controller" description=""></device>^M
   2140                 <device id="0x0810" name="Color scene controller" description=""></device>^M
   2141                 <device id="0x0820" name="Non color controller" description=""></device>^M
   2142                 <device id="0x0830" name="Non color scene controller" description=""></device>^M
   2143                 <device id="0x0840" name="Control bridge" description=""></device>^M
   2144                 <device id="0x0850" name="On/off sensor" description=""></device>^M
   2145         </profile>^M

Cool, good find

With my latest PR, the SP 120 should be supported:

$ ph get /lights/1
{
  "etag": "006dd70d4d4ef8e0a78f82bb1c029c72",
  "hascolor": false,
  "manufacturername": "innr",
  "modelid": "SP 120",
  "name": "Light 1",
  "state": {
    "alert": "none",
    "bri": 254,
    "on": true,
    "reachable": true
  },
  "swversion": "2.0",
  "type": "On/Off plug-in unit",
  "uniqueid": "00:15:8d:00:02:17:ad:31-01"
}
$ ph get /sensors/4
{
  "config": {
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "5e4df71d9243fe7334953cdd2e2fae81",
  "manufacturername": "innr",
  "modelid": "SP 120",
  "name": "Consumption 4",
  "state": {
    "consumption": 1,
    "lastupdated": "2018-06-08T13:41:55"
  },
  "swversion": "2.0",
  "type": "ZHAConsumption",
  "uniqueid": "00:15:8d:00:02:17:ad:31-01-0702"
}
$ ph get /sensors/5
{
  "config": {
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "e8c21749b620bc3a03988b2b5e072d4b",
  "manufacturername": "innr",
  "modelid": "SP 120",
  "name": "Power 5",
  "state": {
    "current": 1,
    "lastupdated": "2018-06-08T13:41:36",
    "power": 31,
    "voltage": 235
  },
  "swversion": "2.0",
  "type": "ZHAPower",
  "uniqueid": "00:15:8d:00:02:17:ad:31-01-0b04"
}

Awesome! Next investment is settled then ;)

Just got one of the new innr plugs. Seems to be working fine with power meter :)

Maybe I am doing something wrong, but I cannot get the Innr SP120 to be recognized properly. I've managed to get it connected using Phoscon as a light and it is showing in the lights list as a power socket in Phoscon. But no power usage is available, only the on / off status, same seems to hold true for the REST API?

Are the changes build by @ebaauw only working for the GUI version of deCONZ and not the Phoscon app?

Same goes for me @gjong. Which version are you on?

My changes only apply to the REST API and homebridge-hue. Not sure if Phoscon supports this.

@ebaauw Im using REST as well:

```
curl light:
{
"1": {
"etag": "3c75a277ca51098adc8c2e947aedb759",
"hascolor": false,
"manufacturername": "OSRAM",
"modelid": "Plug 01",
"name": "Light 1",
"state": {
"alert": "none",
"on": true,
"reachable": true
},
"swversion": "V1.04.12",
"type": "On/Off plug-in unit",
"uniqueid": "84:18:26:00:00:0d:23:6a-03"
},
"2": {
"etag": "c3323d22e772be74aa95ad2c80cd11b0",
"hascolor": false,
"manufacturername": "innr",
"modelid": "SP 120",
"name": "Light 2",
"state": {
"alert": "none",
"bri": 254,
"on": false,
"reachable": true
},
"swversion": "2.0",
"type": "On/Off plug-in unit",
"uniqueid": "00:15:8d:00:02:17:be:cf-01"

curl sensors:
{
"1": {
"config": {
"configured": true,
"on": true,
"sunriseoffset": 30,
"sunsetoffset": -30
},
"etag": "787e4abfda66ed69338b27be395c5cf6",
"manufacturername": "Philips",
"modelid": "PHDL00",
"name": "Daylight",
"state": {
"dark": false,
"daylight": true,
"lastupdated": "2018-07-02T17:16:29",
"status": 170
},
"swversion": "1.0",
"type": "Daylight",
"uniqueid": "00:21:2e:ff:ff:02:2c:f8-01"
},
"2": {
"config": {
"on": true,
"reachable": true
},
"ep": 3,
"etag": "de919d896c8011769a693b9aae2dc8af",
"manufacturername": "OSRAM",
"modelid": "Plug 01",
"name": "Power 2",
"state": {
"lastupdated": "2018-07-02T17:19:12",
"power": 40
},
"swversion": "V1.04.12",
"type": "ZHAPower",
"uniqueid": "84:18:26:00:00:0d:23:6a-03-0b04"
}
}

Odd, looks like the REST API plugin didn’t create the /sensors resources. Could you try and open the network (from Phoscon or from the old web app) and manually read the _Basic_ cluster attributes from the deCONZ GUI?

If that fails, could you verify your deCONZ version is 2.05.31? If it is, could you post a screenshot of the node and of the _Node info_ panel?

I dont have a gui at the moment for this installation:
pwa reports:

Vendor dresden elektronik
Product ConBee
Version 2.05.31 / 6/22/2018
Firmware 260B0500

That’s ancient firmware. Not sure if related to your issue, though.

Could you try and unplug (power off) the plug, open the network, and re-insert (power on) the plug? If lucky, that should trigger the device setup as well.

I have the same issue. The light is available but nothing under sensors. I'm currently on the following versions:

Product RaspBee
Version 2.05.31 / 6/22/2018
Firmware 26210500

I've tried to unplug the device and plug it back in with an open network, but this did not add the sensors.

Note that I did have some issues getting it detected in the first place, took resetting of the plug.

same as @gjong . But it connected directly without problems.

I have tried to delete it and readd it, without success. In regards of fw im having issues upgrading my stick atm with docker.

@gjong @alainlecluse are you on Docker as well?

In regards of fw im having issues upgrading my stick atm with docker.

Did you try running sudo GCFFlasher_internal while deCONZ is not running? See https://github.com/dresden-elektronik/deconz-rest-plugin/issues/566#issuecomment-400635822. If that fails, try to download GCFFlasher from here and run it on a physical host.

Firmware 26210500

Firmware 26210500 has issues, best use 261f0500.

Note that I did have some issues getting it detected in the first place, took resetting of the plug.
I have tried to delete it and readd it, without success.

That sounds like the usual connection blues, but these are quite uncommon for a mains-powered device. Hard to debug without the deCONZ GUI. You could try:

• Use a USB extension cable to move the ConBee away from the server for less interference;
• Power down all ZigBee routers and move the plug in range of the ConBee, to force a direct connection rather than a connection over the mesh;
• Reset the plug, delete the light resource, delete the node, quit deCONZ, physically delete the deleted record from the database;
• Reset the ConBee by removing/re-inserting it or the RaspBee by power-cycling (not rebooting) the Raspberry, or running sudo GCFFlasher_internal -r;
• Re-pair the sensor: Open the network from the old web app (under Menu|Settings), reset the plug (again).

I am running deCONZ in a docker container, but to upgrade the firmware I make sure the container is not running and then perform a manual upgrade running the GCFlasher_internal tool. I've not had any issues doing this. I'm currently using the Raspbee unit and to connect the power plug I move it to a outlet socket about 15cm away from the Raspbee.

To verify it is not an issue with the firmware version 26210500 I downgraded to 261f0500 and attempted the same steps as before:

Remove device using phoscon, reset the plug using the reset instructions included and rescan using phoscon (also attempted to use open network in the old interface)

All attempts have the same result. The light is added in the /lights API, but no sensors get created under the /sensors API.

I am considering to buy several OSRAM Smart+ smartplugs but after reading this threat I am not sure if the actual power consumption of these plugs is available in HASS when using Raspbee with Deconz?

No

any possibility of getting the UK Smartthings/Centralite Outlet usage working

Basic Cluster:

Electrical Measurement Cluster:

It should already be exposed as a light resource. We need to whitelist the plug to also expose the ZHAPower sensor resource. By the looks of it, that should be fairly straightforward. Could you please:

• Post a screenshot of the _Node info_ panel;
• Check whether the plug supports attribute reporting for the _OnOff_ attribute of the _On/Off_ cluster and for the _RMS Voltage_, _RMS Current_, and _Active Power_ attributes of the _Electrical Measurement_ cluster;
• Double check that the values reported are indeed in V, mA, and 0.1 W, as the divisor attributes suggest.

I have tried to delete it and readd it, without success. In regards of fw im having issues upgrading my stick atm with docker.

I'm also stuck with the light resource and no sensors for my newly arrived innr plugs, did any of you (with docker installs) get it to work? I'm on docker as well, 2.05.31, and have tried delete and readding countless times now.

I'm also stuck with the light resource and no sensors for my newly arrived innr plugs, did any of you (with docker installs) get it to work? I'm on docker as well, 2.05.31, and have tried delete and readding countless times now.

Just for the reference. I still had my old deconz SD image laying around, so I popped it in, updated it, copied the config files, readded my innr plugs, read the basic cluster manually and the sensors turned up. Copied back the config files to docker and everything reads fine now.

@manup Could we have some kind of button to manually read the basic cluster in the web UI? Maybe as an advanced setting? Seems that every problem I have had for the last six months (after switching to docker) falls back to this, not being able to read the basic cluster. (innr plugs, xiaomi/honeywell smoke sensors, more xiaomi sensors).

Are you running docker in host or alternative host and privileged mode? Maybe that will help? Just a suggestion.

It should already be exposed as a light resource. We need to whitelist the plug to also expose the ZHAPower sensor resource. By the looks of it, that should be fairly straightforward. Could you please:

• Post a screenshot of the _Node info_ panel;
• Check whether the plug supports attribute reporting for the _OnOff_ attribute of the _On/Off_ cluster and for the _RMS Voltage_, _RMS Current_, and _Active Power_ attributes of the _Electrical Measurement_ cluster;
• Double check that the values reported are indeed in V, mA, and 0.1 W, as the divisor attributes suggest.

Node info panel screen shot:

On/off reporting: turned true after I switched the fan on

RMS voltage, RMS current & active power when the fan is on running low

so RMS voltage is definitely in V, RMS current would seem to be in mA, and power in 0.1 W.

@ebaauw What else would you like to have? Also keen to get this plug to work... :-)

Here's some photos of the OSRAM, Heiman, and an Elgato Eve (from left to right). I might be challenging to place two Heimans above each other if you have multiple outlets stacked vertically.

@ebaauw

hey, that heiman, looks indeed interesting, but your picture is showing that this one is for the NL market
the other 2 are for BE market,
is there also a heiman model for BE market? like those other 2 ? i need one with a hole :)

or is that EVE also now supported for deconz? i dont see it listed in the wiki ..

I'd recommend the innr SP 120. It's even smaller than the Eve energy, works with deCONZ and the Hue bridge, and has a hole for the ground pin in BE outlets.

The Eve Energy cannot be supported by deCONZ. It talks Bluetooth, not ZigBee.

thnx, alreade now ordered the osram, it was only 18€ , seems the inr is more expenive
i dont need to know the power consumption
also, for me its more as repeater function, not gonna actually use the smart plug :)

thnx for the feedback though

There is too the Salus plug, not yet implemented https://github.com/dresden-elektronik/deconz-rest-plugin/issues/812
But works without problem with power metring on another Zigbee project.

I have smart plugs from Heiman and from OSRAM

Just got an Osram SMART + , it is added in deCONZ but not in phoscon app. I see is not supported, how did you add it?

i have it added in phoscon, working with HA, its exposed a light
my osram smart is working perfect

Same here, works perfectly, (as router too but without power meter) exposed in light section but the icon is a plug. Nothing special to add it, I have made with phoscon.

How do you add it in phoscon? Click ADD NEW SWITCH and then click OTHER?

mine was discovered automaticly as a light

Ohh, yes, now I see it as light. I was trying to add it as a switch, but it was already there as a light

Is there already a fix for Osram to read power usage?

Nope, it looks very much like the OSRAM plug doesn't support this feature in a usable way.

ok, thnx for confirming, too bad though

Nope, it looks very much like the OSRAM plug doesn't support this feature in a usable way.

That's why I commented out the whitelisting of the OSRAM plugs from the list of supported sensors in #1013, as discussed in #1010. Currently, there's no more ZHAPower resource for the OSRAM plugs.

I have a problem with OSRAM Smart Plug. In phoscon App it works perfectly. But the REST API don’t show actual state. State.on is always false.

Anyone with same problems ?

Regards,
Bobby

i have Osram smart plug, using Home Assistant, no issues with state here

I'd recommend the innr SP 120. It's even smaller than the Eve energy, works with deCONZ and the Hue bridge, and has a hole for the ground pin in BE outlets.

I am using the innr 120 in homebridge with the deConz module and homebridge-hue but dont seem to be able to use the power consumption statistics feature. All I get is the on/off switch.

How do I go about exposing this feature so I can use power consumtion statistics in EVE?

Many thanks

Are you exposing sensors in config.json?

Simple solution to a stupid omission. Thanks

This may be the wrong threat, but one more question on the innr SP 120:

This plug has a status light (blue/red). Is there a possibility to have an option to switch this off? I have one plug near my bed and the light is a bit disturbing. Thanks

I asked INNR technical support, but it can not be switched off.

Op wo 29 mei 2019 om 11:18 schreef bubffm notifications@github.com

This may be the wrong threat, but one more question on the innr SP 120:

This plug has a status light (blue/red). Is there a possibility to have an
option to switch this off? I have one plug near my bed and the light is a
bit disturbing. Thanks

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/432?email_source=notifications&email_token=ABNGEKHEQV4OC3VGLWKNTI3PXZC6ZA5CNFSM4ESCFCJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWOWYQI#issuecomment-496856129,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABNGEKD5POETEBD4SFQLCCTPXZC6ZANCNFSM4ESCFCJQ
.

Thanks for checking. I'll put some tape over it or find a better location. Maybe they can address this in a later firmware upgrade.

Already suggested, but most unlikely because of physical design. They will
take it into account when releasing a new plug but that won’t be in the
near future (not this calendar year). First some more Zigbee 3.0
(rgbw)bulbs.

Op wo 29 mei 2019 om 11:53 schreef bubffm notifications@github.com

Thanks for checking. I'll put some tape over it or find a better location.
Maybe they can address this in a later firmware upgrade.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/432?email_source=notifications&email_token=ABNGEKCF3KLZFXNYSOFPDODPXZHBJA5CNFSM4ESCFCJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWOZZDA#issuecomment-496868492,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABNGEKGDYN6ZVJ3SEGYKRWLPXZHBJANCNFSM4ESCFCJQ
.

Just bought a Bitron plug for power monitoring, but noticed that it only creates a ZHAConsumption sensor, not ZHAPower. Because of this it's not possible to monitor the power usage in Home Assistant, while it is available as an attribute on the ZHAConsumption state.

Do you know more about this @ebaauw? I saw your responses on an issue about this plug.

Just bought a Bitron plug for power monitoring, but noticed that it only creates a ZHAConsumption sensor, not ZHAPower.

Yes, see the Wiki. The ZHAConsumption resource is linked to the _Simple Metering_ cluster; the ZHAPower to _Electrical Measurement_.

Yeah, I found that, so this is a problem in Home Assistant?

Should power metering via the ZHAConsumption resource be supported in home assistant @Kane610? I only see a consumption sensor in home assistant, the power sensor is missing.

Hello, I have an Osram plug, I connected that to deconz SW, infact I see that plug in that way:

after I search it in Postman (with this command: "DECONZ-IP:PORT/api/token/lights") and I see that:

Now the problem is in Home Assistant where I see this plug only as sensor:

In that Way I can only see if the plug is ON or OFF but I'm not able to change the state.

Any suggestion or Idea on how to integrate that plug in Home Assistant as Light or Switch?

thanks

All seem normal on deconz, I think the problem is more from Home assistant.

One aspect to double-check when evaluating smart plugs is the power rating. The innr plugs are rated for 10A (which should amount to ~2300W at 230V). My washing machine is rated 10A and 2200W, but the innr plug would turn off spontaneously. My dryer is rated 16A and 2350W, and actually broke a couple of innr plugs (before checking the rating...). The Heiman plug is rated 16A and 3000W and has been working flawlessly with my washing machine for well over a year.

I ordered a second Heiman plug for my dryer from AliExpress, which arrived yesterday. It has newer firmware than my old plug. It now exposes a _Date Code_ ("2018.1.11") and _Groups_ and _OTAU_ clusters. Not sure were we would get the firmware updates from...

Hi @ebaauw, can you share that AliExpress link?

I'm not sure; they constantly change the site, but it looks like this one: https://nl.aliexpress.com/item/32839165490.html?spm=a2g1y.12024536.productList_11977830.pic_3

Ok, thx in advance, gonna try these ones out, at the moment I have Osram, they work good, but not reliable for as router with my xiaomi pir sensors...
Do you have xiaomi pir sensors?

No, I use Hue motion sensors. Had some issues in the past when deCONZ was losing the route to them, but they’ve been rock solid since v2.05.60 and 0x26320500. See #849.

Ok, interesting, do the hue motion also provide lux?

I wouldn't use those Heiman plugs any more. You can find multiple instances of it catching fire if you Google for it. For example: https://community.smartthings.com/t/heiman-hs2sk-z-smart-plug-fire-hazard/118358

I actually purchased one of these plugs and found that something was loose inside the plug (you could hear something rattling around). So I opened it and found a loose screw. So no more heiman for me 😅

So what do you use as router? Seems heiman was not suitable for me anyway, I need EU version, the one in above link was for Netherlands

For example: https://community.smartthings.com/t/heiman-hs2sk-z-smart-plug-fire-hazard/118358

That's a Z-Wave plug, not ZigBee, and the thread suggests it's not an original Heiman.
I only have two Heiman ZigBee plugs (EU version), and (knock on wood) they're not causing any issues for me. There's not that many ZigBee plugs out there that can handle 3000W and report consumption.

Ok, interesting, do the hue motion also provide lux?

Yes, and temperature (although the temperature is not very accurate). It's one of the few motion sensors that actually report no motion, with a delay that's configurable on the sensor. No config.duration timer needed. The motion sensitivity can be configured at three levels. It runs on two AAA batteries that last well over a year. And they're firmware upgradable (but we haven't yet found a way to download the firmware for deCONZ, so you need the Hue bridge for this).

Here's the REST API resources:

{
  "config": {
    "alert": "select",
    "battery": 100,
    "delay": 0,
    "ledindication": false,
    "on": true,
    "pending": [],
    "reachable": true,
    "sensitivity": 2,
    "sensitivitymax": 2,
    "usertest": false
  },
  "ep": 2,
  "etag": "9714d2a3aaf6e01eeb341aaed12918d6",
  "manufacturername": "Philips",
  "modelid": "SML001",
  "name": "Hallway Motion",
  "state": {
    "lastupdated": "2019-09-09T17:26:59",
    "presence": false
  },
  "swversion": "6.1.0.18912",
  "type": "ZHAPresence",
  "uniqueid": "00:17:88:01:02:00:ac:85-02-0406"
}

{
  "config": {
    "alert": "none",
    "battery": 100,
    "ledindication": false,
    "on": true,
    "pending": [],
    "reachable": true,
    "tholddark": 12000,
    "tholdoffset": 4000,
    "usertest": false
  },
  "ep": 2,
  "etag": "9714d2a3aaf6e01eeb341aaed12918d6",
  "manufacturername": "Philips",
  "modelid": "SML001",
  "name": "Hallway Light Level",
  "state": {
    "dark": true,
    "daylight": false,
    "lastupdated": "2019-09-09T17:26:59",
    "lightlevel": 6444,
    "lux": 4
  },
  "swversion": "6.1.0.18912",
  "type": "ZHALightLevel",
  "uniqueid": "00:17:88:01:02:00:ac:85-02-0400"
}



md5-fc7b89b8e8c62e1e3fca03cda41771cc



{
  "config": {
    "alert": "select",
    "battery": 100,
    "ledindication": false,
    "offset": 0,
    "on": true,
    "pending": [],
    "reachable": true,
    "usertest": false
  },
  "ep": 2,
  "etag": "a5d387a97fda48c44d05763b3063dd8f",
  "manufacturername": "Philips",
  "modelid": "SML001",
  "name": "Hallway Temperature",
  "state": {
    "lastupdated": "2019-09-09T17:25:07",
    "temperature": 2073
  },
  "swversion": "6.1.0.18912",
  "type": "ZHATemperature",
  "uniqueid": "00:17:88:01:02:00:ac:85-02-0402"
}

Thnx for the detailed info... Gonna use the Philips sensor as a backup...
I am also quite happy withy xiaomi sensors, they work verry good and instant, long battery, and verry small and cheap...
The only issue I have is that they sometimes just don't react, and 5 minutes later , they are working again... I thibk it's because of the routing with my osrams... Heiman is not possible for me, I need BE plugs, heiman are NL ... So gonna try first Ikea smart plugs, then as a last resort the Philips motion

Be advised that IKEA plugs don't do power measurement.

yes i know, but actually i just need routers
my conbee is on second floor, on first floor i have a osram router, and 3 xiaomi, all xiaomi are verry good
on ground floor another osram, and 1 xiaomi, that one is giving me headaches, probably because its using 2 osrams to reach the conbee
20% of the time its not reliable

i dont have bulbs , dont need them, so i am left with smart plug :)

Or the Trådfri repeater?

yes, but then i need to give up the switch in my wall, still want to use it
and i dont need usb chargers anyway :)

Quick Summary from my side:
Osram Smart+ Pro: Works well, cheap / Cons: No consumption monitoring, big design
innr sp120: works well, power consumption monitoring / Cons: only 2300W, overload switch-off, when dish washer turns ons
heimann: not bought yet, seems to be a chinese xiaomi style product from shenzhen with doubtful reliabilty?

anyone has any suggestions for a reliable, cheap plug with consumption monitoring to min. 2600W ?

Does anybody know, how to reset the consumption counter of the "innr SP120" - did not find a writeable register in deconz to clear?

Any hints?

Factory reset the plug (and re-pair afterwards).

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

It seems this issue is resolved or otherwise inactive. If it is not, please re-open!