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

[geelenbert]

I'm ditching all my Zwave gear and switching to deCONZ.

For some equipment i want to do some power metering (heating, freezer, Server etc..). But before buying 5 of these plugs.... Which EU powerplugs work with deCONZ and the REST-api ?

Can't really find any good example of one that works.... Please help

[ebaauw]

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.

[geelenbert]

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 ?

[Kane610]

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?

[manup]

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

[geelenbert]

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

[Kane610]

@geelenbert there is always new things to support :)

[geelenbert]

@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 ....

[Kane610]

@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? ;)

[geelenbert]

@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.

[ebaauw]

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

[Kane610]

@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.

[Martin-Gardner]

can anyone recommend some UK supported plugs?

[geelenbert]

@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

[Martin-Gardner]

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

[Martin-Gardner]

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.

[ebaauw]

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

[tleegaard]

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? :-)

[geelenbert]

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)?

[ebaauw]

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.

[ebaauw]

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:

[ebaauw]

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:

[geelenbert]

@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)

[ebaauw]

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]

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.

[ebaauw]

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.

[ebaauw]

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.

[geelenbert]

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.

[ebaauw]

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.

[ebaauw]

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...

[manup]

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.

[ebaauw]

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.

[geelenbert]

@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.

[ebaauw]

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}

[geelenbert]

@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 ?

[oleg77s]

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)

[ebaauw]

@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.

[oleg77s]

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

[ebaauw]

@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?

[Oggymator]

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.ebert@led-trading.de

Back to topic :)

[oleg77s]

@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

[ebaauw]

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.

[oleg77s]

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.

[oleg77s]

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

[ebaauw]

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?

[oleg77s]

old plug reacts on group commands in Phoscon App

[rtenklooster]

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!

[rtenklooster]

@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.

[ebaauw]

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.

[rtenklooster]

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

[ebaauw]

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.