[Request device support] Develco EMI Norwegian HAN

[Jopinder]

Develco Norwegian HAN External Meter Interface

Real-time measurement and reporting of household power.

Product page: https://www.develcoproducts.com/products/meter-interfaces/emi-norwegian-han/

Technical manual with detailed cluster information: https://www.develcoproducts.com/media/3747/emizb-132-technical-manual-emi-norwegian-han.pdf

Node:

Node Info:

Basic Node 0000:

Simple Metering 0702:

Electrical Measurement 0B04:

[SwoopX]

Strange. Could you please enter sensor search in Phoscon and the in deconz GUI, whiche search is running, read the simple descriptors? Maybe that does the trick.

[gantonjo-tnm]

@SwoopX. Thanks again for your ideas, but still no luck in getting the sensors into the zll database.

[SwoopX]

I don't get it. However, I double checked one of your screenshots (https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2127#issuecomment-573355967) and there the develco specific device profile is missing.

I'd recommend either to re-pair (since you upgraded deconz in between) or reset the HAN and join it.

[gantonjo-tnm]

@SwoopX, thanks again. After deleting the node from VNC GUI, it came back when I reset the HAN. However, now I am not able to read any cluster infos from the HAN :-(

In the SQlite database two new sensors appeared:

         sid = 4
        name = EMIZB-132 (2)
        type = ZHAConsumption
     modelid = EMIZB-132

manufacturername = Develco Products A/S uniqueid = 00:15:bc:00:1b:02:4c:e0-02-0702 swversion = 2019-07-11 23:45 state = {"consumption":null,"lastupdated":null,"power":null} config = {"on":true,"reachable":true} fingerprint = {"d":83,"ep":2,"in":[1794],"p":260} deletedState = normal mode = 1

         sid = 5
        name = EMIZB-132 (2)
        type = ZHAPower
     modelid = EMIZB-132

manufacturername = Develco Products A/S uniqueid = 00:15:bc:00:1b:02:4c:e0-02-0b04 swversion = 2019-07-11 23:45 state = {"current":null,"lastupdated":null,"power":null,"voltage":null} config = {"on":true,"reachable":true} fingerprint = {"d":83,"ep":2,"in":[2820],"p":260} deletedState = normal mode = 1

And in HA the same sensors appeared with zero values.

[gantonjo-tnm]

@SwoopX : OK, now, after stopping deConz and starting it again, the node started to show readings, but now the values are extremely high:

And in HA it shows:

Corret value should be around 22886 kWh

[SwoopX]

Ah, finally some progress. You did exactly right with restarting deconz to be able to read the attributes and (not 100% sure) to have the sensors written to DB. Glad that it worked out.

Now, the consumption value is somehow unexpected and doesn't really fit. Maybe it takes some time for the value to become updated and therefore reasonable? I'd also be interested in the DB values you posted earlier as some of them require some unit tweaking. Also, is attribute 0x0302 of the simple metering cluster set for you all right?

Ah, and another thing: is 22886 kWh really reasonable? I'd require around 10 years to have that consumption ;)

[gantonjo-tnm]

@SwoopX, yes, 22886 kWh is reasonable;-) Here in Norway, the main source for heating and almost every thing that needs energy is electricty. So in winter time we easily consume 1500 kWh per month.

I will unplug my Develco HAN adapter, delete all traces of it from GUI and DB and try attaching it again without changing any values in the DB if I have time when I get home.

I will revert with results.

[gantonjo-tnm]

Hurray! Now I finally got readings from my Develco EMI adapter in my Home Assistant. Maybe I did not have to do SQLite deletion and rebinding, but well, I did the following:

1. Disconnected the Develco EMI adapter from my power meter.
2. Deleted the Develco Node in the VNC GUI
3. Stopped the deConz service (i.e. stopped the docker container running the service)
4. Deleted all traces of the adapter from the SQLite tables.
5. Started the deConz service again.
6. Searched for new sensor in the Phoscon GUI and monitored the VNC GUI. The Develco Node was successfully added, but could not read any Cluster Info.
7. After the Phoscon GUI showed new sensor was ready, I stopped the deConz service and started it again.
8. Now it was possible to read Cluster info and in HA I now had 2 new sensors added.

Still, some of the cluster values are not very well presented to HA, as you see in the pictures above. Below are the Cluster info from deConz:

[gantonjo-tnm]

Now, the next question. How can I get the Develco EMI to send readings more often to my HA? Or, maybe deConz is not able to read updated values from the Develco? It is stuck at the value 22973760, (Instantaneous Demand updates, not the other readings)

Contents from Database:

INSERT INTO devices VALUES(14,'00:15:bc:00:1b:02:4c:e0',1580235252,3347);
INSERT INTO device_descriptors VALUES(27,14,0,1,4,X'01c9c00100010303000500060000',1580235252);
INSERT INTO device_descriptors VALUES(28,14,0,2,4,X'0204015300000600000300200002070407040b0303000a001900',1580235258);
INSERT INTO device_descriptors VALUES(29,14,0,0,2,X'0240807c115252000000520000',1580236713);
INSERT INTO sensors VALUES('4','EMIZB-132','ZHAConsumption','EMIZB-132','Develco Products A/S','00:15:bc:00:1b:02:4c:e0-02-0702','2019-07-11 23:45','{"consumption":2.29738e+07,"lastupdated":"2020-01-28T19:01:04","power":688}','{"on":true,"reachable":true}','{"d":83,"ep":2,"in":[1794],"p":260}','normal','1');
INSERT INTO sensors VALUES('5','EMIZB-132','ZHAPower','EMIZB-132','Develco Products A/S','00:15:bc:00:1b:02:4c:e0-02-0b04','2019-07-11 23:45','{"current":17856,"lastupdated":"2020-01-28T19:00:27","power":null,"voltage":238}','{"on":true,"reachable":true}','{"d":83,"ep":2,"in":[2820],"p":260}','normal','1');

[SwoopX]

Hey, great news. So now we can go over to the tweaking part I mentioned earlier.

From what I see, we need to apply a divider on the current to have a more or less correct value represented. Power, consumption and voltage look ok.

How can I get the Develco EMI to send readings more often to my HA?

Also, it appears like the binding and attribute reporting has failed. From my experience, that was also the case while adding support for the Develco smoke sensors. I managed to have it working in the end. Root cause is that the device's node descriptor is either incorrect or not correctly picked up by deconz core (you don't wanna know). Good new is: we should be able to handle that.

So, I'd suggest 3 options and would like to ask you to go over them in that order:

1. Patch the device descriptor once again as mentioned here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2127#issuecomment-573210412 . Now that is has paired correctly and the sensors have been created as they should, there is a chance that it will work. Try shutting down deconz and power cycle the device (I hope it will stay paired. If not, sorry for that and move on with option 2)

2. Do a manual binding in deconz GUI. Ebaauw gave some good guidance here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/812#issuecomment-425660327 . Please make sure you create a binding with electrical measurement and simple metering cluster each. After that, check reporting configuration for the parameters of interest (also mentioned there) and amend where required.

3. I need to make a few code adjustments to circumvent the root cause mentioned in option 1. Those changes must be merged then and I'm not too sure if they will be included timely for the next official build .73

If you're willing to stay with me here, we can iron out a couple of issues here.

[gantonjo-tnm]

Good morning. After a night without touching the configuration, I now see new values being collected every full hour: it would be nice to have the posibility to tweak the parameters so that I get updated values more often, if possible. And it would be nice to get access to the other values that are present in deConz for this device as well.

[SwoopX]

it would be nice to have the posibility to tweak the parameters so that I get updated values more often, if possible.

It is, that's what my previous post was mainly all about. You can try to adjust that yourself by option 2 mentioned earlier. Binding and reporting is pretty much configuring a device to push values instead of pulling them. 2 Steps involved, binding first, then attribute reporting configuration. Not sure if any of the steps has been successful yet, but you can do both subsequently. Proposed values for attribute reporting are as follows:

• Min Interval: 1
• Max interval 300
• Reportable change: 1

It pretty much means that, if consumption increases by 1W every (let's say) 5 secs, you get new data every 5 secs but it doesn't go faster than every second. If consumption stalls for (let's say) 1h, you get new data every 300 secs. Note that the above values are the default values, but generally adjustable to your preference. I hope, that made it a bit clearer.

For a consistency check regarding measurement intervals of the above screenshot, please go to simple metering cluster, double click on the numeric value of attribute 0x0000 (Current Summation Delivered), press "read config" and share the screenshot. From the behaviour you experienced, I'd expect values of 3600 there somewhere. Regardless, I've already proposed corresponding changes for integration.

And it would be nice to get access to the other values that are present in deConz for this device as well.

Namely? From my perspective, all the important values are available

[gantonjo-tnm]

@SwoopX Thanks for your answers. First of all Current Summation Delivered have the following config:

Then, to the last question. Only 2 "sensors" are possible to graph, as far as I can tell. The Total Consumpsion is graphed, but not current momentary consumption:

And for the other sensor, there is one graph showin 0 all the time, while current and voltage are not being graphed:

Just to be sure I don't bind the wrong entities, does this look correct?

and

[SwoopX]

Yep, bindings look correct. Please write the attribute reporting config after binding, just to be sure. The attribute reporting values look also ok.

And for the other sensor, there is one graph showin 0 all the time, while current and voltage are not being graphed

Noticed that as well, might be resolved after binding. Anyway, set the values for electrical measurement cluster, attribute 0x0304 as well.

Btw, since you mentioned some values are not graphed, that's a topic for the community of your middleware I'm afraid. From a deconz sensor perspective, everything's as it should be (except for the reporting intervals of course).

[gantonjo-tnm]

Good morning, @SwoopX. Thanks for all your help in this case. I have now bound the 0x0702, Simple Metering, and 0x0B04, Electrical Measurement, clusters. I addition I checked the reporting config, but still I only get Current Summation values every hour from the meter. Strange, because I know I got updates from the meter everytime I read from the cluster (in VPN GUI) before I upgraded deConz.

[SwoopX]

While checking the attribute configuration, you also pressed "write config"? Did it return a success message?

We need to know if the values keep on changing in the REST API to be sure what is going on. It is also possible that the middleware you use might be the limiting factor here and on that end, I'm not able to help.

[oivindoh]

I'm a bit at a loss here. I have the Develco device (branded Wattle), and it seems to show up fine in the deconz gui with all the expected clusters. I'm running the latest deb release (within a docker container) of deconz-rest-plugin, with the plugin itself compiled from master as of a few minutes ago.

However, data is seemingly showing default values for everything:

0x702 cluster after hitting read and getting a gui update:

0xb04 cluster after updating via read:

Sensor is showing up nicely in the database:

sqlite> select * from sensors;
3|EMIZB-132|ZHAPower|EMIZB-132|Develco Products A/S|00:15:bc:00:1b:02:44:1a-02-0b04|2017-11-01 11:53|{"current":null,"lastupdated":null,"power":null,"voltage":null}|{"on":true,"reachable":true}|{"d":83,"ep":2,"in":[2820],"p":260}|normal|1
1|Daylight|Daylight|PHDL00|Philips|00:21:2e:ff:ff:05:23:fb-01|1.0|{"dark":true,"daylight":false,"lastupdated":"2020-02-01T21:27:37","status":230,"sunrise":"2020-02-01T07:57:22","sunset":"2020-02-01T15:09:31"}|{"configured":true,"lat":"63.420956","long":"10.321571","on":true,"sunriseoffset":30,"sunsetoffset":-30}||normal|1
2|EMIZB-132|ZHAConsumption|EMIZB-132|Develco Products A/S|00:15:bc:00:1b:02:44:1a-02-0702|2017-11-01 11:53|{"consumption":2.81475e+14,"lastupdated":"2020-02-01T21:27:41","power":0}|{"on":true,"reachable":true}|{"d":83,"ep":2,"in":[1794],"p":260}|normal|1

I've run the update statement from https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2127#issuecomment-573210412 using the correct MAC address of my adapter.

stopped deconz here

sqlite> SELECT * from device_descriptors where device_id = (SELECT id FROM devices WHERE mac = '00:15:bc:00:1b:02:44:1a') AND endpoint = 0 AND type = 2;
32|13|0|0|2|@�PP|1580583109
sqlite> UPDATE device_descriptors SET data = x'02408015105050000000500000' WHERE device_id = (SELECT id FROM devices WHERE mac = '00:15:bc:00:1b:02:44:1a') AND endpoint = 0 AND type = 2;
sqlite> SELECT * from device_descriptors where device_id = (SELECT id FROM devices WHERE mac = '00:15:bc:00:1b:02:44:1a') AND endpoint = 0 AND type = 2;
32|13|0|0|2|@�PP|1580583109

started deconz here

I've also set all the attribute reporting configurations to 1/300/1, as well as successfully bound simple metering and electrical measurement to my controller:

Might this simply be a case of my power company not actually enabling the HAN port after telling me they've enabled my HAN port?

[SwoopX]

@oivindoh welcome to the party. If I read your comments correctly, you just compiled deconz rest plugin yourself a couple of minutes ago. As my changes regarding binding and attribute reporting have been merged yesterday, so the last step described was some kind of double work for you :)

Regardless, what you're experiencing my very well be connected to your last line. In that sense, you should clarify with your provided if the port is enabled. Also, you need to know which metering is appropriate (refer to https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2127#issuecomment-571188206). If that attribute needs to be changed, you need to manually change general.xml and use deconz-rest-cli to change it. All required info in this regard is available here.

Hope, that helps (at least a bit).

[oivindoh]

I have the Kaifa meter, so I need to set the manufacturer-specific attriubute to 0x0203

I created a new docker container that plugs in current master of both rest plugin and cli plugin, into which I mount a modified general.xml with this under the simple metering cluster:

        <cluster id="0702" name="Simple Metering">
            <description>The Simple Metering Cluster provides a mechanism to retrieve usage information from Electric, Gas, Water, and potentially Thermal metering devices. These
devices can operate on either battery or mains power, and can have a wide variety of sophistication.</description>
            <server>
            <!-- for develco specific code -->
            <attribute-set id="0x0300" description="Develco Specific" mfcode="0x1015">
            <attribute id="0x0302" name="Interface Mode" type="u16" access="rw" showas="hex" required="m" mfcode="0x1015">
            <!--
                <value value="0x0200" name="Norwegian HAN"></value>
                <value value="0x0201" name="Norwegian HAN - Enable extra load. This is need to enable Adion meter communication"></value>
                <value value="0x0202" name="Norwegian HAN - Aidon Meter supporting Norwegian HAN HW interface"></value>
                <value value="0x0203" name="Norwegian HAN - Kaifa meter and Kamstrup meters running old firmware"></value>
            -->
            </attribute>
            </attribute-set>

I fire this up and connect via nc, and can successfully e.g. get attributes of the simple metering cluster:

zclattr 0x3E9D 02 0x0702 0C00000D
 --> send OK
<-ZCL discover attr 0x3E9D for cluster 0x0702 discoveryComplete = Yes
 <-ZCL discover attr 0x3E9D 0x0702 0x0000 0x25 48BitUint
 <-ZCL discover attr 0x3E9D 0x0702 0x0001 0x25 48BitUint
 <-ZCL discover attr 0x3E9D 0x0702 0x0200 0x18 8BitBitMap
 <-ZCL discover attr 0x3E9D 0x0702 0x0300 0x30 8BitEnum
 <-ZCL discover attr 0x3E9D 0x0702 0x0301 0x22 24BitUint
 <-ZCL discover attr 0x3E9D 0x0702 0x0302 0x22 24BitUint
 <-ZCL discover attr 0x3E9D 0x0702 0x0303 0x18 8BitBitMap
 <-ZCL discover attr 0x3E9D 0x0702 0x0306 0x18 8BitBitMap
 <-ZCL discover attr 0x3E9D 0x0702 0x0308 0x41 OctedString
 <-ZCL discover attr 0x3E9D 0x0702 0x0400 0x2A 24BitInt

Thanks to your excellent comments hidde by github further up, I then try to set the manufacturer attribute via zclattrmanu 0x3E9D 02 0x0702 0x1015 020203210302. I used the initial datatype you started with here. Perhaps trying data type 31 would be worthwhile? I don't quite understand how to read the current manufacturer specific value/type.

Still getting default (?) values after a fresh start and read. Wish I had another meter.

Going to try the rest of the types to see whether <-APS attr 0x3E9D 2 0x0702 0x0200 0x18 01 (01 on meter status) changes.

[SwoopX]

Thanks for the flowers. Glad That is helped people so far.

I used the initial datatype you started with here. Perhaps trying data type 31 would be worthwhile? I don't quite understand how to read the current manufacturer specific value/type.

Now, for your comments/questions: Reading manufacturer specific attributes is actually pretty simple once you know how it works: Try this:

zclattrmanu 0x3E9D 02 0x0702 0x1015 000203
              |    |    |      |    | |
              |    |    |      |    | +---------- Attribute ID (reverse byte order)
              |    |    |      |    +------------ Command (00 = Read)
              |    |    |      +----------------- Manufacturer code (Develco)
              |    |    +------------------------ Cluster ID (Simple Metering)
              |    +----------------------------- Endpoint
              +---------------------------------- Device

I'd expect that to work even without any modification of general.xml. The response should give you the correct data type to apply. Btw, I'm curious to see if the discovery command would also work if you pass a manufacturer. Will give it a try later on.

Going to try the rest of the types to see whether <-APS attr 0x3E9D 2 0x0702 0x0200 0x18 01 (01 on meter status) changes.

Might be worth a try. Any indication might be of help (meaning any value not being 0x00).

Btw, if I got that correctly, deleting and re-joining the device seemed worked out somehow for @gantonjo-tnm . Wouldn't be thefirst time this solving issues. And compliments to your work here ;)

[oivindoh]

Thanks for sticking with me!

I added the device from scratch and meter status is now reported as 0x00.

Edited general.xml to set interface mode type to enum16 since that is what is reported:

zclattrmanu 0x46F2 02 0x0702 0x1015 000203
--> send OK
<-APS attr 0x46F2 2 0x0702 0x0302 0x31 00 02

Trying to set value 0203 (no feedback other than send OK, as far as I can tell):

zclattrmanu 0x46F2 02 0x0702 0x1015 020203310302
 --> send OK

Reading the value back however, it seems to be stuck as 0200:

zclattrmanu 0x46F2 02 0x0702 0x1015 000203
 --> send OK
<-APS attr 0x46F2 2 0x0702 0x0302 0x31 00 02

GUI doesn't want to play either, but I suppose that's expected

I'll try another rejoin, this time with sqlite purge.

Discover command:

zclattrmanu 0x46F2 02 0x0702 0x1015 0C00000D
 --> send OK
<-ZCL discover attr 0x46F2 for cluster 0x0702 discoveryComplete = Yes
<-ZCL discover attr 0x46F2 0x0702 0x0302 0x31 16BitEnum

[SwoopX]

Hm, it seems to work according to https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2127#issuecomment-573762930 but may require sending it more than once... Have you tried other values just for fun?

[oivindoh]

Interesting...:

Setting to 2001 seems to take. Same goes for 2002. If I try to set 2002 after successfully setting 2002, the value stays at 2002 even after 10 attempts.

zclattrmanu 0x46F2 02 0x0702 0x1015 000203zclattrmanu 0x46F2 02 0x0702 0x1015 020203310102 --> send OK <-LQI 0x6157 012 0 2 0x00212EFFFF0523FB 0x0000 0 1 0 01 00 FC

zclattrmanu 0x46F2 02 0x0702 0x1015 000203 --> send OK <-APS attr 0x46F2 2 0x0702 0x0302 0x31 01 02

I can see the values updating in the VNC gui in the backgrorund while performing the changes, but it'll be damned if it'll accept the operating mode I need 🗡

Just noticed the guys above have a far more recent date code in the basic cluster, whereas I have 2017-11-01. Perhaps this adapter is just too damn old.

[SwoopX]

Could be indeed the case :(

Another thing I was wondering the last days: The complex metering cluster has at least two commands (according to technical manual). Those are not available. Also, I have no clue at all how to get the required values for them. I checked zigbee documentation and it feels that some of them need to be known upfront. Not sure if it has anything to do with it.

Just noticed by the way, that your first write attempt was with a wrong value (twisted numbers).

[Jopinder]

@oivindoh You have the same Date Code as me, and I also bought the adapter from Wattle. I contacted Develco about firmware-updates but they referred me to Wattle as they only provide white label products for other companies.

I haven't been in touch with Wattle, but it might be worth a shot to at least see if there's been any updates.

[oivindoh]

I got the same reply. Since I'm not hopeful about getting any help from Wattle, and the shop I had bought it from has a fairly generous return policy, I jsut returned it.

Planning to try again with the "original" and more expensive version of the exact same device - hoping to pick one up fairly soon.

[SwoopX]

@Jopinder at least you received a response. I haven't back in the days regarding the smoke sensors. Have you had the impression, they'd share the FW update? Would love to have it for my sensors.

Wattle was quite talkative. However, they haven't given me the FW though (If I recall correctly and it wasn't Cozify).

[Jopinder]

@SwoopX No, I don't believe they will share any FW with us directly. The response I got was short but precise:

Hi

Please contact your solution provider of the gateway and system.

Best regards, Develco Team

I did however look over the changelog for the Wattle Gateway and sent Wattle an email asking about the update for the Aidon meters. Unfortunately, that's for an older model (EMIZB-130) and apparently only an update for the gateway, not the device. I'm assuming it's for the same I and @einarjh struggles with, getting the Aidon to start sending data when the HAN-port is opened.

[SwoopX]

That's not much. I'm always thinking about requesting access to their support forum to be able to provide better integration for people, who've decided against their gateway. Maybe also ironing out a few potential FW bugs or at least discuss some behaviour observed as well as resolving some inaccurate documentation in the various papers ;)

[oivindoh]

So to follow up from my end, the firmware version seems important for Kaifa.

I went out and got one of these, and it had 2019-07-11 21:41 in its Date Code. Plugged it in, restarted deconz since apparently one of my ansible-playbook runs had set me up with a cli-less and general.xml-less docker image running.

Connected through nc and ran:

# Get attribute type
zclattrmanu 0x3AD0 02 0x0702 0x1015 0C00000D
    <-ZCL discover attr 0x3AD0 for cluster 0x0702 discoveryComplete = Yes
    <-ZCL discover attr 0x3AD0 0x0702 0x0302 0x31 16BitEnum

# Set Kaifa mode enum16 (31)
zclattrmanu 0x3AD0 02 0x0702 0x1015 020203310302

# Read to see if this took effect
zclattrmanu 0x3AD0 02 0x0702 0x1015 000203
    <-APS attr 0x3AD0 2 0x0702 0x0302 0x31 03 02

Restarted the container again as if I'm running an old windows computer, and lo and behold!

Real data!

Dividing current and voltage by 10 as specified in AC formatting gives us values that look pretty much spot on, though I'm a bit dismayed my base load without anything but lights, heat and ventilation is around 3.5kW. Exactly why I bought the meter though!

[ebaauw]

The Voltage Divisor reports 10, so Voltage reports the value in dV.

[oivindoh]

Seems we crossed comments. I noticed my glaring inability to read 👍

Spot the moment the EV charger was connected...

So in summary the changes made on my end to make this device work ended up being really simple:

1. Add Develco-specific attribute to general.xml - data type is enum16

       <cluster id="0702" name="Simple Metering">
           <description>The Simple Metering Cluster provides a mechanism to retrieve usage information from Electric, Gas, Water, and potentially Thermal metering devices. These
   devices can operate on either battery or mains power, and can have a wide variety of sophistication.</description>
           <server>
           <attribute-set id="0x0300" description="Develco Specific" mfcode="0x1015">
               <attribute id="0x0302" name="Interface Mode" type="enum16" access="rw" showas="hex" required="m" mfcode="0x1015">
                   <value value="0x0200" name="Norwegian HAN"></value>
                   <value value="0x0201" name="Norwegian HAN - Enable extra load. This is need to enable Adion meter communication"></value>
                   <value value="0x0202" name="Norwegian HAN - Aidon Meter supporting Norwegian HAN HW interface"></value>
                   <value value="0x0203" name="Norwegian HAN - Kaifa meter and Kamstrup meters running old firmware"></value>
               </attribute>
           </attribute-set>

Set attribute to "Kaifa mode" via nc, since I have a strange device in my fuse box:

zclattrmanu 0x3AD0 02 0x0702 0x1015 020203310302

[SwoopX]

Great that you have a working solution now. So, recap is, a relatively up-to-date device or firmware is required for it to go smoothly!?

[gforschi]

Just bought this sensor and as I can see it is not officially/properly supported yet? I have a Kaifa meter and I have successfully paired the sensor in Phoscon and I can confirm it is included in the network in deCONZ via VNC. Is there a reason to believe this will be supported "out of the box", and what would the timeframe for that be?

[SwoopX]

Well, the device is supported out-of-the-box. The "problem" is that Develco uses general attributes as manufacturer specific as well, so an unfortunate combination.

Additionally, Develco interprets a blurry definition in zigbee standard differently than others which makes things more complicated. As of now, the only reliable (and workable) way to configure the device is by compiling the deconz-cli-plugin and set the interface mode accordingly.

[gforschi]

Yeah, I understand that there are probably something along what you are describing. Unfortunately I'm not at that level where I know exactly how/where to begin trying to fix it. And in the first place, I want to make sure there isn't any issue with the pairing or something I could have done differently.

[einarjh]

I have been away from this issue for a few months due to moving to a new apartment. Sadly, the new appartment has a meter from Aidon as well, and I'm still unable to coax any data from it. It would seem this reader is a no-go with deConz, but as far as I can tell, somebody got it to work with zigbee2mqtt over on https://github.com/Koenkk/zigbee-herdsman-converters/issues/974 ?

[SwoopX]

@einarjh I'll read the issue from z2m in detail later to see if there's any new information that can help us. However, briefly skipping through it, I've seen that an old firmware was mentioned as root cause. We have that here as well.

EDIT: Like I said, firmware issue on the device https://github.com/Koenkk/zigbee-herdsman-converters/issues/974#issuecomment-590450035

[SwoopX]

All, I wrote some code which should take care of the invalid node descriptor of the devices. As consequence, the manufacturer code should show up correctly (if that was no already the case), so that all Develco specific attributes are visible and available. That makes the previously mentioned patch of the database superfluous, as it is now done automatically. It is available with the next release.

Eventually, that could also bring some progress in having the meter mode visible. Would be great if somebody could test that then by just adding the manufacturer specific part to general.xml, while leaving the non specific attributes untouched.

[damtjern]

Eventually, that could also bring some progress in having the meter mode visible. Would be great if somebody could test that then by just adding the manufacturer specific part to general.xml, while leaving the non specific attributes untouched.

Think i did this right, changed all occurences where Develco were set to 100b (Philips as mfac), to 1015.. Running in Hassos, only difference was the descriptions i changed as a test.. Which section should i change to get the correct manufacturer under node info?

[SwoopX]

What you see in here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2127#issuecomment-587694816 is the only thing which needs to be changed.

[damtjern]

Does my formatting seem right? The changes i do appears ( i changed description for the cluster to mkkechanism), but nothing else changes

[SwoopX]

Looks ok to me. Just to double check: you're running on .76 already? Can you also please share a screenshot of the node info panel?

[damtjern]

Yes, just updated Homeassistant and the Deconz core yesterday.. Here's an image of node info, wierdly now suddenly the correct mf shows in node info! The attribute also showed up after updating general.xml once more, but after a Deconz restart the general.xml was overwritten with defaults. Before that i got writing failed trying to change to Aidon meter

[SwoopX]

Here's an image of node info, wierdly now suddenly the correct mf shows in node info!

Yeah, that's my magic kickin' in. You could do me a great favor and run deconz with additional --dbg-info=2 > EMI to pipe the debug output to a file and read the node descriptor again, wait a moment and then paste the file here. The rest of the node descriptor does not look too right and I want to check what data is really coming in.

Now, regarding the attribute write, it would be interesting to see as well what the debug output yould tell us. Regarding the overwrite, the root cause could be the container if you use one. Normally, the file resides in /usr/share/deCONZ/zcl/.

[damtjern]

Perfect! Not really sure how to output to log when runnning in Hass.OS? The addon logs shows the following, ran a couple times but not sure i get what youre after :/ Attached the contents of /usr/share/deCONZ/zcl/, not running docker but guess its a seperate container in HassOS? Not the most familiar with HA yet general - Copy.txt

Debug log.txt

[SwoopX]

Appreciate it. So the node descriptor update does fine. I still wonder why the device is reporting battery powered and RFD, but ok.

The additions you previously made seemed to be ok, However, that must somehow survive a deconz restart to be/stay available. If that's achieved, you could run with teh debug enabled again and we hopefully see, what's been send (or what the response is).

[ebaauw]

I still wonder why the device is reporting battery powered and RFD

RFD: Because it is an end device. Note also the Poll Control cluster.

battery-powered: Seems consistent with the Power Descriptor that claims a rechargeable power source. The web page claims it's powered by the HAN interface, so definitely not mains powered.

[damtjern]

Was able to get some screenshots of the attributes failing to write, but even adding a general2.xml in the ZCLDB preferences this file gets deleted on reboot.. Is this something i could write once if i connected the deCONZ stick to my windows computer, or added to the default general.xml?

[SwoopX]

You can add it to general.xml of course. I don't know why it fails, but recall somebody here had to try multiple times...