Deconz-rest-plugin: [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:

[ebaauw]

Did you read the attributes of the 0x0702 and 0x0b04 clusters? The 0x0b04 seems to show only default values. The 0x0702 suggests you’re currently consuming 8.3 kW. Can you relate this to what the meter is displaying? Life-time consumption is again the default value.

[Jopinder]

Yes, all values are after clicking "read" and the meter shows ~1-1.2kW atm. To open the HAN-port on Norwegian meters we have to ask the power company to do it, and it says on "My pages" that the port is open. So I'm not sure why it shows default values.

I will request a close and re-opening of the port to see if that helps with the values.

[gantonjo-tnm]

Thank you, @Jopinder, for requesting support for the Develco EMI Norwegian HAN. I have one myself, but have not been able to add it to my Conbee II USB adapter, hence I am not able to get any readings into my HomeAssistant server. I have asked my power provider (LOS) to open my HAN port, and they confirmed that they had enabled my HAN port. Even so, I am not able to see my Develco sensor in ConBee II. I tried using the PhosCon web interface as well as the VNC GUI.

Can you tell me (details) how you managed to bind your Develco HAN to your Deconz adapter?

Thanks in advance and Happy New Year.

[Jopinder]

My power company has confirmed the HAN port is opened after some mailing with their support. I'm going to contact the seller over new year (Wattle/Home Control AS) to ask if they have done anything to the firmware as they claim it only works with their gateway.

@gantonjo-tnm I tried to add it via the web-gui and Sensors -> Add new sensor and chose "Other", but it did not show up. I then reset the Develco and added it again via the web ui. It still didn't show up in the web ui, but this time in the VNC UI as connected (but unable to get any readings from the power meter). So nothing special I did I'm afraid.

Btw, I have Skagerak Energi and the Aidon meter, which meter does LOS use?

[gantonjo-tnm]

@Jopinder LOS uses Kamstrup meters.

[einarjh]

I have the same reader, but my Manufacturer Code comes up as 0x117c as opposed to 0x1015. Very strange, this seems to be the code for IKEA? The sensor is not talking directly to my hub, it's only within range of one of my IKEA bulbs.

My reader is bought from Elektroimportøren, and the web shop lists it as compatible with "Homely": https://www.elektroimportoren.no/emi-norsk-han/4514731/Product.html?Event=livesearch

My meter is also from Aidon. I've gotten a confirmation from my power company that my HAN port is enabled.

@gantonjo-tnm I had to upgrade to the latest deCONZ beta before I was able to get cluster information etc. from my HAN sensor. Got it from here: http://deconz.dresden-elektronik.de/raspbian/beta/

Here are my screenshots:

Node info:

0x000:

0x0702:

0x0b04:

[einarjh]

I just realized that the meter is already turning up in Home-Assistant, probably because I'm on the current deCONZ beta?

But alas, it's not showing anything useful yet (the second screenshot is particularly hilarious)

[gantonjo-tnm]

@einarjh: Very interesting. Thanks for the information, allthough I am not sure how to upgrade my Conbee II to the latest Beta version. I am running my Home Assistant in Docker on an old Apple Mac Mini 2.5 that is running Ubuntu 18.04.3 LTS. Deconz is running as Docker image "marthoc/deconz".

[einarjh]

Derp! I just started reading the documentation for EMIZB-132 a bit closer, and found this:

Seems there is an extra step needed to enable metering data from Aidon meters, which both @Jopinder and I have.

[ebaauw]

Best define these attributes in general.xml and set them thru the deCONZ GUI. You would need to know the type of each attribute.

[gantonjo-tnm]

@einarjh Ok, I managed to update my Docker image to latest "marthoc/deconz", but even so I am not able to find my Develco EMI Norwegian HAN adapter. I have tried to factory reset it and unplugging it after the reset. No luck binding it to my ConBee II :-(

(Since I used docker-compose, "docker-compose down && docker-compose pull && docker-compose up -d" gave me the latest version of the "marthoc/deconz" Docker image):

[einarjh]

I messed around with this some more tonight, but can't quite get it to work.

As far as I can tell from the manufacturer documentation, the manufacture specific attribute ID 0x0302 needs to be added within the 0x0702 cluster, with the manufacturer code set to 0x1015, so I tried adding it like this (with an educated guess for the type, since this is omitted from the documentation):

<attribute-set id="0x0300" description="Develco Specific" mfcode="0x1015">
  <attribute id="0x0302" name="Interface Mode" type="enum16" access="rw" default="0x0200" 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>

That didn't turn up at all, but when I used the IKEA mfcode, it showed up. Why is my Develco device cloning the manufacturer code for IKEA?

Next problem: the attribute id 0x0302 seems to be conflicting with the attribute id for divisor, when I double click on my new attribute, it brings up the widget for divisor, ref. screenshot:

If I give a fictional, unused attribute set ID, it shows the expected widget with a dropdown, but that won't let me read or write, of course. I get UNSUP_MANUF_GENERAL_COMMAND …

[einarjh]

@gantonjo-tnm Sorry, I can't help you with the connectivity issues. I have a feeling that the meter struggles with the range, though, so make sure your nearest node is close enough. I had to move some of my IKEA lights from the IKEA hub over to deCONZ in order to extend the range. Even now it drops out from time to time.

[Jopinder]

That didn't turn up at all, but when I used the IKEA mfcode, it showed up. Why is my Develco device cloning the manufacturer code for IKEA?

@einarjh That's very strange. My Develco is currently connected to ConBee via an IKEA Trådfri spot, and it keeps all the info, 0x1015 etc.

@gantonjo-tnm Yeah, the range on the Develco is kind of crappy, especially if it's mounted on the inside of the fuse box.

[ebaauw]

so I tried adding it like this

That looks good to me, but you might want to set required to o.

That didn't turn up at all, but when I used the IKEA mfcode, it showed up. Why is my Develco device cloning the manufacturer code for IKEA?

I’m afraid you’re running into a limitation of the GUI: it only shows manufacturer-specific clusters and attributes for the same manufacturer code as the device reports in the _Node Descriptor_. You see the attribute, but it won’t work, as the device expects a different manufacturer code in the read and write commands.

Why they use the IKEA code is beyond me, I’ve seen iCasa use the Philips code, so their lights are exposed natively to HomeKit by the Hue bridge.

the attribute id 0x0302 seems to be conflicting with the attribute id for divisor

That’s another limitation in the GUI: it doesn’t support manufacturer-specific attributes with the same ID as a standard attribute. Ran into this for the poweron colour settings of Hue lights. If you comment out the standard attribute, you should be able to interact with the manufacturer-specific attribute (if it weren’t for the previous issue).

You could try and access the attributes thru the deconz-cli-plugin, but that’s not for the faint-hearted.

[gantonjo-tnm]

Thanks @einarjh and @Jopinder fro your answers. The distance between my Develco and my ConBee II is not more than 20 cm, so I cannot believe distance is the reason for my problems. In addition I powered off all other Zigbee devices in my home to avoid interference.

[Jopinder]

@einarjh How are you able to edit general.xml? I'm using Hass.io/HassOS, and each time I copy the edited file back to the deCONZ container and restart it, the file goes back to default.

Is there some way of forcing a reload of general.xml without restarting the container?

I also tried creating a file with the values and adding it as a second source for the ZCLDB with no luck.

[einarjh]

@Jopinder I'm not using docker, I'm using the .deb file directly on a raspbian install.

[einarjh]

I tried resetting and re-adding the meter. It still came back with the wrong manu ID. Then I tried turning off every router and moving my raspberry pi within range of the reader. Same problem, it still came back with the IKEA ID.

Then I went for broke, reset _everything_, and started from scratch with a blank gateway and then adding it. I had to reset everything about ten times, because the device kept coming up with blank manu ID and no attributes. When I finally got it synced up and showing all the attributes again, the manufacture ID was set to 0x1135, which is the same as the raspBee hat has. It seems to clone the manufacturer ID of whatever router it talks to when it pairs up.

So I'm pretty much stuck. I can't get it to show up with the correct manufacturer ID, which means I can't get it to use the correct measuring mode for my power meter.

Is this a bug in deCONZ or do I have a faulty zigbee device?

[einarjh]

Why they use the IKEA code is beyond me, I’ve seen iCasa use the Philips code, so their lights are exposed natively to HomeKit by the Hue bridge.

Just to re-iterate. My testing indicates that DeConz is not seeing the correct manufacturer code, it's seeing the code from whatever router it is talking to. I have left it connected for a few days now, with no change.

[SwoopX]

@einarjh Ok, I managed to update my Docker image to latest "marthoc/deconz", but even so I am not able to find my Develco EMI Norwegian HAN adapter. I have tried to factory reset it and unplugging it after the reset. No luck binding it to my ConBee II :-(

@gantonjo-tnm not sure if I understand what you're missing. From the screenshot you posted, the EMI is visible (device 0x0CF2). EMI is supported since deconz version .72, so the update was necessary.

@einarjh The reason why you have previously seen a different manufacturer code is 99% a node descriptor issue I also had to fight with on the develco smoke sensors (#2154, #2052, #1653). Long story short: in deconz core, the node descriptor is NULL, although a valid node descriptor response was transmitted from the device. This is still not resolved however, my sensors work now with the changes comitted.

Regarding the metering cluster manufacturer specific attribute: I've seen that while amending general.xml for the EMI, but that one felt fishy. Like @ebaauw already mentioned, it might be hard to have it set. Maybe that's doable with ma-ca's deconz cli plugin. Anyhow, not haveing set this attribute appropriately might be the reason why the measurement values show defaults?

@einarjh happy to include your changes of general.xml in a pull request, if you want.

EDIT
@einarjh I might be able to help you with correcting node info data. Let me test that on my sensors first. If it works, it would also require some help from @Jopinder or @gantonjo-tnm.

[SwoopX]

@einarjh the trick works. You need to open daconz' database with sqlite3 and shut down deconz before. While open, issue the following query and make sure you amend the MAC address to yours:

UPDATE device_descriptors SET data = x'02408015105050000000500000' WHERE device_id = (SELECT id FROM devices WHERE mac = '00:15:bc:AA:BB:CC:DD:EE') AND endpoint = 0 AND type = 2;

I know that data set is not 100% accurate (as it should be DC powered instead of battery), but it will do.

[einarjh]

@SwoopX Perfect! I suspected that messing with some database or cache file would allow me to replace the manufacturer ID somehow, but I didn't know where to start. I am now able to read the value, but not able to write it. Hmmm.

[einarjh]

As to committing my suggested config change, that wouldn't make much sense since one needs to comment out/remove different parts of the file in order to get it to work. Assuming I can make it work.

[SwoopX]

Ah yeah, I see. Well, as @ebaauw suggested, you might wanna give the deconz cli plugin from ma-ca a go. If I recall correctly, it might be able to handle that. I may be able to assist.

[einarjh]

That thing looks daunting. I'll see if I'm able to set it up correctly first.

[einarjh]

OK, I have it set up now, seeing lots of traffic in the nc "shell". Awaiting further instructions :)

[gantonjo-tnm]

Thanks @SwoopX. Being new to this, I failed to see the Develco HAN actually being attached to the ConBee II. Now I can manually read the data from my adapter, but I still cannot see it inside my Home Assistant. I will follow this thread and see what comes out, as I understand I am not the only one trying to get this working for Docker installs (like the one I run on my Ubuntu server). So, thanks to all of you who do the hard work.

[einarjh]

@gantonjo-tnm Out of curiosity, since you don't have the troublesome Aidon meter, could you paste a screenshot of the 0x0702 cluster (Simple Metering) after pressing the read button (the one above the attributes)?

[gantonjo-tnm]

Of course: @einarjh :-) I will screenshot all possible cluster info parts so you all have it at hand:

[einarjh]

I'm kinda jealous now. Nice to see what I should expect to see once I get this working.

Are you sure you're not seeing it in Home-Assistant? Have you checked under Configuration -> Integrations -> deCONZ? A couple of sensors are showing up as the two eye icons as seen here:

[gantonjo-tnm]

@einarjh: No, unfortunately, I am not seeing any sensors in the integrations->deCONZ :-( And it is not visible in the Phoscon APP either.

[SwoopX]

@gantonjo-tnm your reading look reasonable, so those seem to be indeed dependant on the interface mode. We would require to find out how to expose them with correct formatting in deconz. Also, I feel some updates to the REST API would make sense for those devices since it is the first time we have them.

@einarjh I'd have said you should use one of those:

zclattrmanu 0x2931 02 0x0702 0x1015 03020202

The last values, that should be the payload. We need to find out how to correctly build it. Don't have time right now, maybe in the evening I can have another look and verify with a sniff.

[einarjh]

@SwoopX I was able to poll some basic data (manufacturer etc.) from it last night, but the tricky part would be figuring out what to send to it, yes. Thanks for all your help so far!

[einarjh]

If it's useful, this is what is spit out when I do a read of the 0x0302 attribute from the GUI:

<-APS attr 0xA2C7 2 0x0702 0x0302 0x31 00 02

(For future reference, my new shortaddr is 0xA2C7, I've done a few resets since the initial screenshot)

[SwoopX]

Give that one a try. I'm just not sure if that's the correct data type. Should write value "0202".

zclattrmanu 0xA2C7 02 0x0702 0x1015 020203210202

[einarjh]

I tried sending it a few times, mostly I get no response, but I'm getting this about 10% of the time:

<-APS-DATA.confirm FAILED status 0xE9, id = 0x5A, srcEp = 0x01, dstcEp = 0x02, dstAddr = 0xA2C7

[SwoopX]

Hm, tried the command just now and it appears that it should be correct. Just to have a better understanding what's send here:

zclattrmanu 0xA2C7 02 0x0702 0x1015 020203210202

  0xA2C7     02     0x0702 0x1015    02      0203     21     0202
shortaddr endpoint cluster mfcode writeattr attrid datatype value

Please take note that the attribute ID and value must be written in reverse byte order!

So it should have written value 0202 to manufacturer specific attribute 0302. Again, not exactly sure if that's the correct datatype, but it matches the one in your previous screenshot.

Do you still have your custom general.xml in action? Eventually, the datatype is not appropriately there. You used enum16 (which is 31), I used 21 in the command (which is uint16). Could also be 29, which is int16...

I'd rather start with this in the general.xml and then try different datatypes accordingly, if it doesn't work:

<attribute-set id="0x0300" description="Develco Specific" mfcode="0x1015">
  <attribute id="0x0302" name="Interface Mode" type="u16" access="rw" required="m" mfcode="0x1015">
  </attribute>
</attribute-set>

[einarjh]

At some point during my tests today, I was able to write to it, it's now it's set to 0x0202. Still getting no data, though, I'll try setting it to 0x0201.

I need to figure out which version of the command that worked, or whether it was because I pressed the physical button on the meter first.

[einarjh]

If I'm reading your latest question right, @SwoopX, then deconz-cli cares about what's set as the data type in the XML?

[einarjh]

I got it. Looking closer at your annotated explanation, I realized that the attrid was written in reverse byte order, so the proper command is:

zclattrmanu 0xA2C7 02 0x0702 0x1015 020203310202

No fiddling with the actual hardware is required.

And that answers my own question, deconz-cli doesn't seem to care what's set as the data type in the XML.

[einarjh]

I haven't seen any change in the data that is being reported, still getting only the default values. I've tested with both 0x0201 and 0x0202. Very strange.

[SwoopX]

I got it. Looking closer at your annotated explanation, I realized that the attrid was written in reverse byte order

Damn, thought of mentioning it, but actually forgot it. Sorry for that and glad you figured it out. I'll update it above for future reference.

deconz-cli cares about what's set as the data type in the XML?

As to my experience, it does. Played with it on the manufacturer specific attributes for basic cluster yesterday. However, it looks like this is only for value representation in deconz GUI. A read seems to provide the assiciated data type.

I haven't seen any change in the data that is being reported, still getting only the default values. I've tested with both 0x0201 and 0x0202. Very strange.

Sorry to read that, strange indeed. I'm afraid I cannot be of much help in that case. Do you have my node descriptor tweak applied and re-read the values?

@gantonjo-tnm To catch up on your earlier question regarding visibility of the device. Deconz should expose at leat two sensors, but only via REST API. They are not visible in Phoscon (closed source). As this is a yet unique device, some further amendments on the API will be required to provide further values of interest.

[gantonjo-tnm]

@SwoopX : Thanks for your catch up.Accessing the port where the Phoscon is exposed only shows me the Phoscon App. I guess I need a special URL to access the REST API. Are you able to tell me how to access the REST API?

[SwoopX]

Hope you're running on Linux without docker ;)

You can try this https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2121#issuecomment-564770517

However, a shortcut while having deconz DB open would be to run the following query

select * from sensors;

Then, look out for any ZHAconsumption and ZHApower sensors.

[gantonjo-tnm]

Thanks, @SwoopX. Well, I am running the marthoc/deconz container in Docker on my Ubuntu server ;-)
I actually found that the persistant storage for deconz on my server is at /opt/deconz/, so I could actually query the database on my server;-)

root@macubuntu:~/docker/dconz# cd /opt/deconz/ root@macubuntu:/opt/deconz# sqlite3 zll.db SQLite version 3.22.0 2018-01-22 18:45:57 Enter ".help" for usage hints. sqlite> select * from sensors; 2|TRÅDFRI remote control|ZHASwitch|TRADFRI remote control|IKEA of Sweden|00:0d:6f:ff:fe:5e:a7:3a-01-1000|1.2.223|{"buttonevent":2002,"lastupdated":"2019-12-06T19:08:26"}|{"alert":"none","battery":87,"group":"57270","on":true,"reachable":true}|{"d":2096,"ep":1,"in":[0,1,4096],"out":[5,6,8],"p":49246}|normal|3 3|Kjøkkenkontroll|ZHASwitch|TRADFRI remote control|IKEA of Sweden|d0:cf:5e:ff:fe:42:3f:c6-01-1000|1.2.214|{"buttonevent":3002,"lastupdated":"2020-01-13T18:57:11"}|{"alert":"none","battery":60,"group":"56285","on":true,"reachable":true}|{"d":2096,"ep":1,"in":[0,1,4096],"out":[5,6,8],"p":49246}|normal|3 1|Daylight|Daylight|PHDL00|Philips|00:21:2e:ff:ff:04:89:64-01|1.0|{"dark":true,"daylight":false,"lastupdated":"2020-01-14T19:33:22","status":230,"sunrise":"2020-01-14T08:04:47","sunset":"2020-01-14T15:05:00"}|{"configured":true,"lat":"58.4343","long":"8.7466","on":true,"sunriseoffset":30,"sunsetoffset":-30}||normal|1

As you can see, there are no ZHAxxx sensors in my DB :-( But in the VNC GUI, the Develco EMI is visible and updates with correct energy values when I order a read from the HAN.

I guess the absence of the ZHAxxx sensors in the database is the reason why they are not visible in Hass.io

[SwoopX]

@gantonjo-tnm Congratz, you promoted yourself to be my new lab rat ;)

Can you please try the following:

1. Shutdown deconz
2. Update the database as mentioned here: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2127#issuecomment-573210412
3. Start deconz again
4. Wait a moment, shut down deconz again and check the sensors

If that doesn't change anything, try reading the simple descriptors while deconz is running, wait a moment,shut down deconz again and check the sensors.

[gantonjo-tnm]

@SwoopX Done. No new sensors appearing in the zll.db :-(

Device_Descriptors for my device are as follows:
27,14,0,2,4,X'0204015300000600000300200002070407040b0303000a001900',1575475907
28,14,0,0,2,X'02408015105050000000500000',1575659017

[SwoopX]

Hmmm. Could you also please try to search for new sensors in Phoscon? No device reset, no pairing, just the search and cross fingers...

[gantonjo-tnm]

@SwoopX , search for new sensors in Phoscon did not reveal any new sensors, neither in HA nor in the zll.db :-(

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

[damtjern]

Could someone share a compiled deconz cli plugin? not all that familiar with how to, but would be nice to try the zclattr command and see if it wants to update then, probably over 200 tries later via attr. menu still failing

[damtjern]

If im adding the attribute after the divisor attribute, that is the one that shows up when opening it up in vnc, same the other way around, am i missing something?
Ordered another raspberry to try to build the ma-ca deconz-cli-plugin, but when trying to run qmake and make command i get an error message that deconz.h is missing

[SwoopX]

You're missing the deconz-dev package. sudo apt-get install deconz-dev if you added the DE repository. In doubt, check out http://www.phoscon.de

[damtjern]

Thanks, made it further! Now i get this error for wrong version deCONZ library, am i running a too new version (deconz latest beta)?
https://pastebin.com/wdk2ssxg

[SwoopX]

Have you made a make distclean before?

[damtjern]

Started over, with some more knowledge, and then it just worked, probably some error message i had not seen when installing something else!
Copied libdeconz_cli_plugin.so to my home assistant and to my windows deconz, but neither show the new plugin, is there another step?

[SwoopX]

Well, tbh, I have no clue as I don't know how HA/docker barricades itself.

Here is how it should work on a bare metal system: just use nc localhost 5001 and then you're connected. It's just a local TCP connection. I don't know if that's feasible in the environment you're running.

Maybe on the weekend, I could have a brief look if there's an easy way to extend the api to make that specific configuration.

[damtjern]

Thank you so much for your help, finally some progress! Ran it bare metal, that worked, but gives me send failed (commands attached and log if interested)

https://pastebin.com/PX8UQ6FY

[SwoopX]

If that is literally all what you've seen from the cli plugin, then it doesn't seem to work (unless this is your only device). Should be much chattier.

[SwoopX]

@damtjern Also did a mistake with the port. it's 5008 instead of 5001, stumbled upon that just now. Sorry for that.

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

[einarjh]

Not stale, just slow.

An update from me: as there has been speculation here that the firmware version is important in order for this device to work on Aidon meters, I went and bought a second device today. However, it has the exact same firmware as my old one, and the exact same problem; no data gets registered.

I also recently received the equipment I needed in order to test with zigbee2mqtt, but I had the same problem there. So I know for a fact that the firmware version "2019-07-11 23:45" does NOT work with Aidon meters.

I will try and send the new device back (actually kept the receipt this time), and see if they are able to get me one with a more recent firmware than 2019-07-11 ...

[SwoopX]

As I've already explained in the z2m threat, this is NOT the device firmware you're looking on, so that question remains open. The actual firmware version is to be found in attribute 0x8000 of the basic cluster. Unfortunately, deconz tries to display it as string, which makes it unreadable. Instead, the raw hex output represents the actual version.

[einarjh]

Ah, I see that now. How can I get to the raw hex output, do I need to break out the debug interface again? It would be helpful to know which versions are known to be bad (and crucially; which are confirmed to be working).

[SwoopX]

It would be helpful to know which versions are known to be bad (and crucially; which are confirmed to be working).

Indeed.

I get to the raw hex output, do I need to break out the debug interface again?

Well, that's the challenging part here. Right now, there's only 3 ways I see, all bringing "pain to the regular user":

• Use ma-ca's cli plugin and query the pertaining attribute
• Use a zigbee sniffer
• Compile and use a special version of the REST API plugin from me, which basically turns deconz into a sniffer

[oivindoh]

Here's the data from my functional device:

<-APS attr 0x3AD0 2 0x0000 0x0000 0x20 01 04 00 00 42 14 44 65 76 65 6C 63 6F 20 50 72 6F 64 75 63 74 73 20 41 2F 53
<-APS attr 0x3AD0 2 0x0000 0x0005 0x42 EMIZB-132
<-APS attr 0x3AD0 2 0x0000 0x0006 0x42 2019-07-11 21:41
<-ZCL attribute report 0x3AD0 0x0702 2 00 00 25 E7 FD B9 02 00 00 00 04 2A 5E 20 00 00 02 18 00
<-ZCL attribute report 0x3AD0 0x0B04 2 04 03 2B 5E 20 00 00 05 03 2B 6F 00 00 00 05 05 21 60 09 08 05 21 7D 4E 05 09 21 00 00 08 09 21 F0 4E 05 0A 21 5E 09 08 0A 21 9D 4C
<-APS attr 0x3AD0 2 0x0000 0x0007 0x30 04
<-APS attr 0x3AD0 2 0x0000 0x8000 0x10 80 86 20 80 86 0D FF 86
<-APS attr 0x3AD0 2 0x0000 0xFF22 0x23 FF 86 10 00 86
<-APS attr 0x3AD0 2 0x0000 0x0030 0x31 00 86 32 00 86 33 00 86

I couldnt' get either of these to work, so the above is just output that was generated when I pressed read in the GUI

zclattrmanu 0x3AD0 02 0x0000 0x1015 000008
zclattrmanu 0x3AD0 02 0x0000 0x1015 000007

[SwoopX]

Let me double check on my Develco device. The response above does not seem correct, you get 8 Bytes for a data type boolean...

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

[stale[bot]]

As there hasn't been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it isn't solved, request to get this opened again.

[Jopinder]

Yeah, gonna have to ask for this thread to be reopened again :)

[Mimiix]

@Jopinder I do expect activity in order for me to re-open. Bot warned after 21 days, no response and then closed it a week later.

What do we need to get this fixed?

[WTell]

@Mimiix To get this fixed, we need to get support for the MFG specific attributes described in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2127#issuecomment-571188206 . I tried adding this to the XML myself, but after fooling around for a good three hours, I have realised that I am not competent enough to implement this properly.