feature request: Add support of smart metering functions for bitron smart plug 902010/25

[basty2]

Hi. I would like to suggest to add smart metering funkctions for bitron smart plug with smart metering. Is it possible and/or planned to add this feature? Regards Basty

[ebaauw]

Could you please post deCONZ GUI screenshots of the smart plug, showing and overview of the endpoints and clusters, and the attribute values of the Basic, the Metering and the Electrical Management clusters (if present). Do a Read in the Cluster Info panel to get the values. Also, we'd need to know what units the plug uses (e.g. W, 0.1W, or 0.01W).

[basty2]

Hi ebaauw, i got this information:

[ebaauw]

That looks promising, and in line with the technical documentation I found: http://media.bitronvideo.eu/bitronhome/Bitron_Home_ZigBee_Clusters_and_Attributes_-_en_0814.pdf. According to the documentation, the plug should support attribute reporting.

Is this a new plug? Current Summation Delivered (attribute 0x0000 in the Simple Metering (0x0702) cluster should report the total electricity delivered (probably since the last reset). Could you connect something and turn it on and see what value appears here? What version of deCONZ are you on? Until recently, there was a bug in the GUI that it wouldn't display the 48-bit value.

According to the documentation, there's another attribute on the Simple Metering cluster: Instantaneous Demand (0x0400), which would report the current power. However, deCONZ doesn't show it, because it's not defined in the ZCL definitions file, general.xml. If you're comfortable with this, could you edit /usr/share/deCONZ/zcl/general.xml and add the following line:

<attribute id="0400" name="Instantaneous Demand" type="s24" access="r" required="o"></attribute>

It should be at the attribute set 04 of the 0x0702 cluster:

            <attribute-set id="04" description="ESP Historical Consumption">
                <attribute id="0400" name="Instantaneous Demand" type="s24" access="r" required="o"></attribute>
            </attribute-set>

After that, and after restarting deCONZ, you should see the attribute in the Cluster Info panel. Again, we want to see what value it reports and guess what unit it might use.

[basty2]

Hi, I'm on deconz 2.05.12 and added the attribute. I connected the plug with a computer and a monitor. After restart of deconz:

After pushing the read button:

[ebaauw]

It might take a while (couple of minutes or longer) for the plug to update Current Summation Delivered. I find the Heiman smart plug only updates the value every 10 Wh or so, and when the plug is switched on or off.

The Instantaneous Demand won't show any value for me either. I double-checked by sniffing the ZigBee traffic that the plug does report a non-zero value. This seems to be the same value as for the Active Power attribute in the Electrical Measurement cluster (the Bitron doesn't support this cluster). Also for the ubisys dimmer. Probably a bug in deCONZ itself that it doesn't handle the s24 value correctly (like it didn't handle the u48 correctly). We need @manup to fix this.

[basty2]

the value Current Summation Delivered is displayed only in steps of thousands.

[ebaauw]

Is that 1000 Wh?

v2.5.14 should create a ZHAConsumption sensor for the Bitron plug. Not sure if state.power gets updated, but state.consumption should reflect Current Summation Delivered.

[ebaauw]

Hm, Instantaneous Demand is still missing from general.xml in v2.5.14. Even after I add it again, the value of state.power doesn't get updated. @manup, could you please have a look at this?

[basty2]

Hi. I think is WH, so the sensor is counting only in kwh = 1000 wh. I'm on v2.5.14. Unfortunately, I don't see the new ZHA sensor. But new unknown sensor was added: a new daylight sensor: "config": { "configured": true, "on": true, "sunriseoffset": 30, "sunsetoffset": -30 }, "etag": "20a761a60f9a9a3b71d711e337c44e28", "manufacturername": "Philips", "modelid": "PHDL00", "name": "Daylight", "state": { "daylight": true, "lastupdated": "2018-03-18T10:23:08", "status": 170 }, "swversion": "1.0", "type": "Daylight" }

[manup]

Hm, Instantaneous Demand is still missing from general.xml in v2.5.14. Even after I add it again, the value of state.power doesn't get updated. @manup, could you please have a look at this?

Sorry I missed that one, have added it now so it will arrive in 2.05.15.

(Note too myself again, make general.xml part of this git repository..)

[ebaauw]

@basty2., You need to open the network from the web app or Phoscon app and maybe read the basic cluster attributes from the deCONZ GUI.

@manup, thanks! Do you also need to add support for the s24 value in the deCONZ core? Even if I define the attribute in general.xml, I don't receive a value through ia->numericValue(). I tried all variations: .u32, .s32 and their 64, 16, and 8-bit versions.

[manup]

@manup, thanks! Do you also need to add support for the s24 value in the deCONZ core? Even if I define the attribute in general.xml, I don't receive a value through ia->numericValue(). I tried all variations: .u32, .s32 and their 64, 16, and 8-bit versions.

Just checked the code, s24 is missing I'll add it for the next release.

The other bit lengths will likely fail since the datatype in the packet doesn't match.

[basty2]

@ebaauw: ahh. yes, now i have the sensor... Thanks.

[ebaauw]

@manup, Current Summation Delivered is an u48 value, but ia->numericValue().u64 seems to work. Based on that observation, I would expect ia->numericValue().s32 to work for the s24 Instantaneous Demand. Or does the u64 for Current Summation Delivered work though a lucky coincidence?

I also noticed different behaviour in the deCONZ GUI: when looking at the attribute reporting, the u48 reportable change value shows, but the s24 value doesn't. Note that you cannot set the attribute reporting from the GUI, as the reportable change is the wrong type.

[manup]

No coincidence the s48/u48 are already implemented a while and store the value in the union which makes it available in the .u64.

For s24/u24 this need to be added, due the type.length() info from ZCLDB this should be enough to add the enum values to the switch statement.

[ebaauw]

@manup, in v2.5.15, I'm getting the value of Instantaneous Demand through ia->numericValue().s32. Thanks!

@basty2, you should see a value for state.power with v2.5.15.

[basty2]

@ebaauw with 2.05.15 the value Instantaneous Demand is shown. It seems, that the value isn't automatically updated (for one hour). I have to push everytime the read button in the gui. Is it possible to change the update interval?

[ebaauw]

Cool! What value does it report? W? 0.1W?

deCONZ should setup attribute reporting so that the plug reports every 5 minutes and when the value changes more that 10 (that was for the Heiman plug, which reports in 0.1W). Also, deCONZ should poll the values in case reporting isn’t supported. Apparantly that’s not working quite as I expected. It did seem to work in my test environment, with only the Heiman plug, but in my production environment, with three OSRAM plugs and a ubisys dimmer, the values aren’t updated either.

You could try and setup attribute reporting manually (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/340#issuecomment-353648984), but the deCONZ GUI doesn’t support the reportable change values for u48 and s24.

[basty2]

it's very cool. :) the reported value was about 397, this sould be about 39.7W. "create the binding manually" seems not so easy. I will test it tommorow. Here is the screenshot

Honestly, I don't know what to do...

[basty2]

Hi @ebaauw,

do you found a solution for the updating problem?

[ebaauw]

Not yet. Created some additional logging and running that in my production environment at home. The polling of sensors is far less frequently than the polling of lights. Also, sometimes some of the sensors are skipped, but they are included after restarting deCONZ. Not sure why...

[basty2]

Hi. with the new version 16 it works. Sometimes there a big gaps. Between 16:22 and 19:35 there was the gap. before and after, every change is reported. I use FHEM for logging: 18-03-25_16:22:09 207 2018-03-25_16:22:13 186 2018-03-25_16:22:26 180 2018-03-25_16:22:34 184 2018-03-25_16:22:38 184 2018-03-25_16:22:41 184 2018-03-25_16:22:43 179 2018-03-25_16:22:45 179 2018-03-25_16:22:47 179 2018-03-25_16:22:52 169 2018-03-25_16:22:54 169 2018-03-25_19:35:44 159 2018-03-25_19:36:08 189 2018-03-25_19:36:24 196 2018-03-25_19:37:00 166 2018-03-25_19:37:04 166 2018-03-25_19:37:09 169 2018-03-25_19:37:11 169 2018-03-25_19:37:14 169 2018-03-25_19:37:16 158 2018-03-25_19:37:18 158 2018-03-25_19:37:20 158 2018-03-25_19:37:22 158 2018-03-25_19:37:24 166 2018-03-25_19:37:27 166 2018-03-25_19:37:29 166 2018-03-25_19:37:31 162 2018-03-25_19:37:34 162 2018-03-25_19:37:36 162 2018-03-25_19:37:43 162 2018-03-25_19:38:50 155 2018-03-25_19:39:01 183 2018-03-25_19:39:03 183 2018-03-25_19:39:33 184 2018-03-25_19:39:35 184 2018-03-25_19:39:42 184 2018-03-25_19:40:21 162 2018-03-25_19:40:26 162 2018-03-25_19:40:28 160 2018-03-25_19:40:30 160

[basty2]

Hi,

unfortunately, after the last update I have to update the plugs manually to get new values. @ebaauw Have you found a solution for an automatically update?

[ebaauw]

No, unfortunately. I still haven’t been able to find the cause

[basty2]

Is it possible to send a console command for updating manually?

[ebaauw]

No, the polling of ZigBee devices is not exposed through the REST API.

[basty2]

@manup: Since last versions there is no automatic update anymore. Is it possible to force the update with a command without the gui?

[stale[bot]]

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.

[manup]

Is this working with recent versions?

[ebaauw]

Not in v2.05.48. if I write the Reportable Change for Current Summation Delivered (an u64) for an innr SP 120 and read it back, it shows a different (random) value. For Instantaneous Demand (an s24) writing results in writing config failed for the Heiman plug and in _failed INVALIDVALUE for the ubisys D1. The innr plug doesn't support Instantaneous Demand.

[tseroo]

I've just started using a deCONZ (2.05.20) starting with a Bitron 902010/25. I can see the Instantaneous Demand in deCONZ and also get reasonable values (376 for 37.6W) after pressing the READ button, but no automatic update happens.
What I do not get are any Sensors! My understanding was that since 2.5.14 I should see a ZHAConsumption sensor for the Bitron plug. Any ideas what's going wrong?

[ma-ca]

It works in 2.05.54 (current version today) and has already been there for a while.

{
    "config": {
        "on": true,
        "reachable": true
    },
    "ep": 1,
    "etag": "ef09427d300f005657940fe11f8bde54",
    "manufacturername": "Bitron Home",
    "modelid": "902010/25",
    "name": "Consumption 36",
    "state": {
        "consumption": 2730000.0,
        "lastupdated": "2019-01-05T20:13:49",
        "power": 158
    },
    "swversion": "20150629",
    "type": "ZHAConsumption",
    "uniqueid": "00:12:4b:00:08:8b:7e:49-01-0702"
}

[tseroo]

OK, and where can I find 2.05.54? On the Dresden Homepage only the 2.05.20 is available for download. I thought that's the latest one...

[tseroo]

Never mind ... found it here. Thanks for the hint!

[tseroo]

No change with 2.05.54 ... I've deleted the node and re-joined but I still get the same result:

That's all I can see via the REST API:

No idea where the daylight sensor is coming from ...

What am I doing wrong ???

[manup]

In order to create new resources the sensor search must be running, while it is running please power-cycle the device (full reset shouldn't be needed).

[ebaauw]

@ma-ca what values does the Simple Metering cluster report? I doubt the lifetime consumption of the plug is 2.7 million kWh.

[ma-ca]

@ebaauw the Divisor attribute has the value 10000, which converts the Current Summation Delivered value 2742000 to 274,2 kWh.

{
    "config": {
        "on": true,
        "reachable": true
    },
    "ep": 1,
    "etag": "2b72e61f319157aeea6ad923a4d846eb",
    "manufacturername": "Bitron Home",
    "modelid": "902010/25",
    "name": "Consumption 36",
    "state": {
        "consumption": 2742000.0,
        "lastupdated": "2019-01-06T15:49:12",
        "power": 16
    },
    "swversion": "20150629",
    "type": "ZHAConsumption",
    "uniqueid": "00:12:4b:00:08:8b:7e:49-01-0702"
}

[ebaauw]

deCONZ doesn't read the divisor and multiplier attributes (as not all plugs/switches report these correctly). The scaling is hard-coded per model. https://github.com/dresden-elektronik/deconz-rest-plugin/blob/cad9e39ab975b1f5633e67ac57a47411b205eddc/de_web_plugin.cpp#L5745-L5771

[tseroo]

After doing a Sensor search I've got all resources available via the REST API. Thanks!

[tseroo]

Regarding scaling of the values I have a totally different behavior. I have a lamp connected to the switch - at brightness low about 37W. The consumption counter goes up about 360 per hour! Next I switched the lamp to brightness level high - 53W. And now the consumption goes up about 360 per hour again !!!

At 37W - time between meassurements 22min - consumption difference=132.
Per min: 132/22=6 Per hour: 6*60=360:

At 53W - time between meassurements 41min - consumption difference=246.
Per min: 246/41=6 Per hour: 6*60=360:

In other words, no idea what is measured here ...

[ebaauw]

state.lastupdated is the time the resource was updated, not the time of measurement. The plugs I’ve seen only update consumption every 10Wh or so. If deCONZ polls the sensor, state.lastupdated has nothing to do with the sensor updating consumption. Even if the sensor pushes changes, the resource could be updated because of a change in power.

You’ll need to measure for a way longer period of time to average out the errors because of the above.

[tseroo]

Sounds good, but if the update would occur only every 10Wh, why does the consumption counter then change between each single measurement, e.g. within 10 seconds?

To get better numbers I did a measurement over night for 12 hours with 37W connected. In this setup I clearly step over a possible ~10Wh threshold several times since the real consumption is about 3712=444Wh. In my opinion we should see a change of (scaling factor)444

Observed values: 5641-1321=4320 Divided by 12 we get the hourly change: 4320/12=360, and that's exactly the same change rate seen so far.

Long running test with 53W for 3 hours - expected (scaling factor)159 Observed values: 6786-5699=1087 / 181 = 6 60 =360 change rate per hour

No matter how many Watts are consumed by the attached device, the consumption always changes by 360 per hour!

[ebaauw]

Sounds good, but if the update would occur only every 10Wh, why does the consumption counter then change between each single measurement

I said: "the plugs I've seen". Different types of plugs (or even firmware versions) handle this differently.

No matter how many Watts are consumed by the attached device, the consumption always changes by 360 per hour!

It would seem the plug doesn't report consumption correctly. We've seen something similar for the for the OSRAM plugs, which reports power, but unrelated to the actual power.

[tseroo]

Previously you wrote

state.lastupdated is the time the resource was updated, not the time of measurement.

Does that mean, it's the timestamp when last receiving data from the device?

What I'm still struggling to understand is, how is a failure of a device detected? Via REST API I can see in the config section the fields 'on' and 'reachable'. But who is setting them and when? Meaning, device is broken - not sending data anymore. How can I know it is broken and how fast will I detect it? Does deCONZ query devices regularly, or has this to be implemented in the next layer e.g. OpenHAB?

Any clarification is highly appreciated. Thanks

[ebaauw]

config.on is used to enable/disable handling of the sensor by the gateway. It’s set through the API. It’s not forwarded to nor read from the sensor. When you set config.on to false, the Hue bridge actually disables updates to the state attributes; deCONZ only disables firing rules with conditions for the state attributes.

config.reachable (or state.reachable for lights) is maintained by the gateway. Some devices periodically push notifications to the gateway, other devices are polled by the gateway. The gateway should set reachable false when it hasn’t received a couple of push notification or answers from the device in a row. How long this takes depends on the device: Xioami devices push a notification only once per hour, so it will take a couple of hours. Note that sleepy battery powered deviced cannot be polled. reachable is set to true as soon as a new message arrives.

Note there’s no way to distinguish between a faulty device, a powered down device (mains power off or depleted battery), or a network failure (e.g. interference). More sophisticated devices (mostly intruder alert system (IAS) devices) should report alarms on detecting tampering or low battery, but I find even devices that expose the corresponding Zigbee attributes don’t always use them.

I’m not sure if deCONZ currently handles config.reachable for Zigbee end devices. I actually check state.lastupdated manually to see if my sensors and deCONZ are still communicating. This doesn’t work for wireless switches - some of them do send periodic push notifications for the battery state, but that doesn’t update state.lastupdated as battery is exposed as config.battery. You do see the web socket notifications for config, though.

[tseroo]

Thanks for the detailed explanation!

[stale[bot]]

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.