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

[senilio]

Once the state.power / Instantaneous Demand value is properly displaying, I can start using that for calculating my consumption... so for my specific use case it's not critical that the API can handle those large numbers.

[SwoopX]

@senilio Can you please double check what your meter has as imp/kWh ratio? Going from the technical manual, there shouldn't be any adjustment necessary for the divisor or the instantaneous demand. Also, please read once again the simple metering cluster attributes (specifically the Develco attributes). Default for imp/kWh should be 1000, not sure if that fits your meter though.

From my perspective, you got an enormeous consumption within that short time frame ;)

[senilio]

Absolutely! It is speced at 10000 impulses/kWh. So that explains why I have to divide by 10 to get proper values... it will also mean that the values will be correct once I can configure the meter for 10k imp instead of 1k :) 👍
You are absolutely correct about the consumption... it's huge even after dividing by 10... but around 100kWh per 24h is unfortunately a fact this time of year 💸 🥶

Regarding reading the cluster attributes again, here's another screenshot:

I have a feeling that the colliding attribute ID's is a problem here...

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

For instance, the data type of "Unit of measure" is really enum8, and it does show enum8 shortly when i read the attributes. But about a second later it changes back to u16, which is really the data type of "Pulse Configuration". Same goes with the value of these two... after reading attributes, the value of "Unit of Measure" shortly shows as "kW & kWh binary", but the next second it shows as "1000", which AGAIN should be the value of "Pulse Configuration"... I can only assume this is due to the two values sharing the same id 🤷‍♂️

Perhaps the above is simply a cosmetic/display issue, but is messing up what I see in the Simple Metering cluster.

[SwoopX]

Alright, so the last commit should enable you to configure interface mode and pulse configuration via API. You might want to check it out.

[senilio]

Thanks! These 2 new attributes are now visible in the config section. I'm able to set both values:

> curl --header "Content-Type: application/json" --request PUT --data '{ "config": { "pulseconfiguration": 10000 } }' http://IP/api/KEY/sensors/42
[{"success":{"/sensors/42/config/pulseconfiguration":10000}}]

> curl --header "Content-Type: application/json" --request PUT --data '{ "config": { "interfacemode": 0 } }' http://IP/api/KEY/sensors/42
[{"success":{"/sensors/42/config/interfacemode":0}}]

 "config": {
    "interfacemode": 0,
    "on": true,
    "pulseconfiguration": 10000,
    "reachable": true

pulseconfiguration change from default 1000 to 10000 does not reflect on the instantaneous demand numbers, which I think is the only thing this variable is used for.
when it comes to interface mode, i tried setting to a few of the modes from the documentation, which all returned "success"... but it just kept on delivering the pulse counter like before :) 🤔

[SwoopX]

Alrighty, next try.

The pulse configuration had the wrong data type, so that's corrected now and therefore not surprising that it didn't change anything. Also the interface mode had some blemishes... Btw, allowed interface modes are from 1 (should be default, in order according to documentation, to 8).

The annoying thing is that I had to push before I could compile it, so the errors slipped through. Don't ask me why my local code threw different errors 🤷‍♂️

[senilio]

Got it 👍

setting interface mode to 1-8 all returns the below:

[{"error":{"address":"/sensors/42/config/interfacemode","description":"Could not set attribute","type":608}}]

unfortunately the same goes for setting pulseconfiguration... I tried with a number of integers, including 100, 1000, 10000:

[{"error":{"address":"/sensors/42/config/pulseconfiguration","description":"Could not set attribute","type":608}}]

[SwoopX]

Hm, eventually found a bug affecting other clusters as well here (or this could happen in future).

Regardless, now the API calls get through and a corresponding request is sent on zigbee level. Modified one of my Develco smart plugs this time to check it ;)

[senilio]

There we go! Both attributes now work as intended 👍👍👍

Bumping pulseconfiguration from 1000 to 10000 effectively put a divider of 10 on the consumption counter and "instantaneous demand", just as expected! The instantaneous demand attribute now displays correctly, probably because it never goes big enough to (according to my hunch) breach the boundary of an s16.

Regarding this (#4337 (comment)) ... what showed inside deCONZ at the time was correct, but the corresponding value in REST always stayed between negative 32768 through positive 32767 (I just verified this in my Prometheus history). So is REST really displaying state.power / Instantaneous Demand as int16 while it is in fact an int24?

[SwoopX]

Ah, finally, that took a while 💪

So is REST really displaying state.power / Instantaneous Demand as int16 while it is in fact an int24?

Well, gotta check that in more depth. I recall that one of the values gets a cast down, but that should only become an issue at large values (which typically do not occur).

[SwoopX]

Hm, so when the power value on the consumption resource gets high enough, it turns into a negative value. To check, I manipulated my power reading by *5000

The value is casted down to qint16 before "handed over to the API"...

[senilio]

Yeah then that's it... my unscientific tests using python ctypes says that it starts over from the negative end once you trespass the limit :)

>>> c_int16(32767)
c_short(32767)
>>> c_int16(32768)
c_short(-32768)

While you're at it manipulating values in your Develco adapter, try pumping "consumption" up to 7 or 8 digits and see it go exponential :)

Thanks alot for your effort on this!

[SwoopX]

Don't have anything in my production network that high yet, so I gotta bend stuff later.

[SwoopX]

While you're at it manipulating values in your Develco adapter, try pumping "consumption" up to 7 or 8 digits and see it go exponential :)

It does indeed.

[robinjoh90]

Is there any documentation how to add the sensor? It has joined my zigbee-network but i can't see the sensor in the api.

[lwsrbrts]

Is there any documentation how to add the sensor? It has joined my zigbee-network but i can't see the sensor in the api.

@robinjoh90
I just received my pulse meter (from: https://www.vesternet.com/collections/zigbee/products/zigbee-frient-electricity-meter-interface) and joined it to my Zigbee network (ConBee II on a dedicated RasPi).

The pulse meter isn't visible in the Phoscon app (GUI website) but it is available/visible/configurable in the API and is also exposed to, in my case, Home Assistant, without me having to do anything else except configure the pulseconfiguration: setting to suit my meter.

Are you actually checking the "API" or just the Phoscon app (GUI website) ?

[nukleuz80]

Hey all,
what can i do with the interfacemode?
Thanks.

[robinjoh90]

Is there any documentation how to add the sensor? It has joined my zigbee-network but i can't see the sensor in the api.

@robinjoh90 I just received my pulse meter (from: https://www.vesternet.com/collections/zigbee/products/zigbee-frient-electricity-meter-interface) and joined it to my Zigbee network (ConBee II on a dedicated RasPi).

The pulse meter isn't visible in the Phoscon app (GUI website) but it is available/visible/configurable in the API and is also exposed to, in my case, Home Assistant, without me having to do anything else except configure the pulseconfiguration: setting to suit my meter.

Are you actually checking the "API" or just the Phoscon app (GUI website) ?

Yes I was looking in the API with Postman, for me it does not appear. I can see it as a node in the Deconz, and it even blinks (receiving data) but I can't see it in the API. For now, I gave up and migrated it to Zigbee2mqtt.

[CookieThemes]

Is there any documentation how to add the sensor? It has joined my zigbee-network but i can't see the sensor in the api.

@robinjoh90 I just received my pulse meter (from: https://www.vesternet.com/collections/zigbee/products/zigbee-frient-electricity-meter-interface) and joined it to my Zigbee network (ConBee II on a dedicated RasPi).

The pulse meter isn't visible in the Phoscon app (GUI website) but it is available/visible/configurable in the API and is also exposed to, in my case, Home Assistant, without me having to do anything else except configure the pulseconfiguration: setting to suit my meter.

Are you actually checking the "API" or just the Phoscon app (GUI website) ?

Could you please share, how did you change the pulseconfiguration?

[lwsrbrts]

Is there any documentation how to add the sensor? It has joined my zigbee-network but i can't see the sensor in the api.

@robinjoh90 I just received my pulse meter (from: https://www.vesternet.com/collections/zigbee/products/zigbee-frient-electricity-meter-interface) and joined it to my Zigbee network (ConBee II on a dedicated RasPi).
The pulse meter isn't visible in the Phoscon app (GUI website) but it is available/visible/configurable in the API and is also exposed to, in my case, Home Assistant, without me having to do anything else except configure the pulseconfiguration: setting to suit my meter.
Are you actually checking the "API" or just the Phoscon app (GUI website) ?

Could you please share, how did you change the pulseconfiguration?

There's an example using CURL provided above: #4337 (comment)

You must send the command to the deConz API and must therefore know the device's "number" as well as have an API key that you include in your URL.

The URL will look something like this for example: http://192.168.1.53/api/FDB1E623B1/lights/10

10 being number associated with the device by the API, FDB1E623B1 being the API "key" - both of these will be different for you.