Develco External Meter Interface

[senilio]

Device

• Product name: External Meter Interface
• Manufacturer: Develco
• Model identifier: ZHEMI101
• Device type:
  • Sensor

I bought one of these, which is a rebranded Develco unit. Technical information of the sensor can be found here

Screenshots

[SwoopX]

I can take care of that, but it will require you to compile and test.

[senilio]

Thanks! No problem, I'll be happy to compile and test 👍

[SwoopX]

Ok, you might give it a first go:

git clone --branch=develco https://github.com/SwoopX/deconz-rest-plugin.git develco

I'd particularly interested in the manufacturer specific attribute set 0x0300 for the simple metering cluster. Does it show up and is it usable/configurable?

[senilio]

The 0x0300 attributes are visible and all of them are read only:

We do have a new ZHAConsumption sensor available via REST.

{
  "config": {
    "on": true,
    "reachable": true
  },
  "ep": 2,
  "etag": "3f4164cf56615e0d89c50134a9eeccb7",
  "lastseen": "2021-02-08T07:43Z",
  "manufacturername": "Develco Products A/S",
  "modelid": "ZHEMI101",
  "name": "ZHEMI101",
  "state": {
    "consumption": 29431,
    "lastupdated": "2021-02-08T07:43:48.984",
    "power": -25859
  },
  "type": "ZHAConsumption",
  "uniqueid": "00:15:bc:00:1b:02:39:c5-02-0702"
}

state.consumption counter is already usable, and looks to correctly represent the number of blinks detected 👍
state.power... not sure what this negative value corresponds to. I would expect this to contain the Instantaneous Demand value below....

In deCONZ GUI, the 0x0400 Instantaneous Demand attribute is correctly reporting usage after I apply a divisor of 10.... ie value of 40000 = 4000W = 4kW.

[SwoopX]

Thanks for checking. Is there no 2nd 0x0300 attribute set specific for Develco at the bottom? You probably have to manually copy general.xml file from the cloned folder. It must be in /usr/share/deCONZ/zcl/ iirc

[senilio]

You are correct! After applying general.xml, the new attribues does show.

They do show as "rw" in the table, so I assume they are writable :) Although, when clicking one of them to bring up the Attribute editor, the other 300 attributes pop up, seemingly because the id's are the same:

0x0300 Pulse Configuration --> 0x0300 Unit of Measure
0x0301 Current Summation --> 0x0301 Multiplier
0x0302 Interface Mode --> 0x0302 Divisor

[SwoopX]

Ah great, so half way there 😄

Regarding the pop up windows for the attributes, I need to pass that over since I can't do anything there. However, I guess it is currently more important that they're readable.

As I see it, it's more important that we get the interface mode configurable via API. Will also see that I include the amendments for the power readings.

Meanwhile, you might look around to see if anything of importance might be missing.

[senilio]

I've noted one tiny issue that started happening after the counter passed over to 7 digits.

Example... when the "Current Summation Delivered" counter displays 1022934 in the deCONZ GUI, the corresponding state.consumption value when retrieved via REST displays 1022930... the value is rounded to the nearest 10. While this doesn't mean any huge issues when measuring the counter velocity, there shouldn't be a reason for this rounding to happen. I'm thinking this issue might become worse over time... like rounding to nearest 100 when we reach 8 digits, nearest 1000 for 9 digits, 10000/10 and so on :)

[Mimiix]

@senilio What is the type for that Current Summation Delivered?

[senilio]

It is the id 0x0000 that can be seen here #4337 (comment)

u48, so up to 281474976710655 :)

[Mimiix]

It is the id 0x0000 that can be seen here #4337 (comment)

u48, so up to 281474976710655 :)

There goes my hunch 😄

[SwoopX]

Example... when the "Current Summation Delivered" counter displays 1022934 in the deCONZ GUI, the corresponding state.consumption value when retrieved via REST displays 1022930... the value is rounded to the nearest 10. While this doesn't mean any huge issues when measuring the counter velocity, there shouldn't be a reason for this rounding to happen. I'm thinking this issue might become worse over time... like rounding to nearest 100 when we reach 8 digits, nearest 1000 for 9 digits, 10000/10 and so on :)

Erm, thanks for highlighting this bit the fun part is that there's no rounding applied as codewise, the raw value is taken 🤔

[senilio]

When omitting the curl pipe to jq, I get the value in "exponential format" (which is also doing the rounding)... 🤷

curl -s http://deconz/api/KEY/sensors/42

{"config":{"on":true,"reachable":true},"ep":2,"etag":"b31245fffd8a13e8066065bfa8133bef","lastseen":"2021-02-10T15:00Z","manufacturername":"Develco","modelid":"ZHEMI101","name":"ZHEMI101","state":{"consumption":1.14375e+06,"lastupdated":"2021-02-10T15:00:43.410","power":-23184},"type":"ZHAConsumption","uniqueid":"00:15:bc:00:1b:02:39:c5-02-0702"}

[SwoopX]

I got the bad feeling that anything interprets those larger numbers as longs...