Findings while trying to add a Sunricher 2-wire dimmer (retrofit)

[Preto]

First off, thanks for the new release and the new up-to-date Wiki documentation!

I've bought some 2-wire built-in dimmer modules, quite similar to #1124 (comment). They're whitelabel Sunricher modules under different names like iCasa, Iluminize, yphix, Lubeez, Relicus etc. If I'm not mistaken the one that @ebaauw got is a Sunricher SR-ZG9101SAC-HP.

Mine is labeled ROB_200-011-0 and is a Sunricher SR-ZG9040A Built-in Micro Smart Dimmer in disguise. It's supported out of the box in deCONZ, but the Simple Metering and Electrical Measurement cluster aren't exposed in the API.

I've added the following line to the whitelist in de_web_plugin.cpp to expose the metering:

    { VENDOR_SUNRICHER, "ROB_200-011-0", silabs3MacPrefix }, // Sunricher SR-ZG9040A built-in dimmer, whitelabeled by Robbshop

After compilation you will get:

• Power measurement (Active Power & Current from the Electrical Measurement cluster) under /sensors (ZHAPower)
• Consumption (Current Summation Delivered from the Simple Metering cluster) under /sensors (ZHAConsumption)

I'm not yet sure what state.current does within ZHAPower. It looks like some mA conversion from RMSCurrent (0x0508) within the Electrical Measurement Cluster (0B04), but the numbers don't completely add up.

3:
  config:
    on: true
    reachable: true
  ep: 1
  etag: "33a64df551425fcc55e4d42a148795d9"
  manufacturername: "ROBB smarrt"
  modelid: "ROB_200-011-0"
  name: "Power"
  state:
    current: 43464
    lastupdated: "2020-05-26T20:28:29"
    power: 121
    voltage: 1352
  swversion: "2.5.3_r47"
  type: "ZHAPower"

Looking at the AC Power Divisor (0x0605) of 10, the Active Power seems to be in deciWatt.

---

To whitelist or not to whitelist
After the above source modification, recompilation and Add new sensor via Phoscon, the API finds the new Sensors. When I put back the default API (libde_rest_plugin.so: v1.16.0) from the debian-sources, these new parameters (ZHAConsumption & ZHAPower) are still there and keep updating. Makes me wonder why whitelisting via source-code is needed in the first place. You will also get now the swversion in the API for these two new parameters. So that's different too. Lets take it a step further.

Removing the actual device from the network does not remove the two new parameters in /sensors. The result from deCONZ and Phoscon regarding removal doesn't change this fact. The only way to remove these seems to be deleting the rows in the zll.db sensors table from the SQLite file.

I've reset the whole network and started from scratch with the shipped API and added the Micro Dimmer in this clean network.

Then I shut down deCONZ and opened a SQLite editor. Subsequently added the following two rows in the zll.db database:

INSERT INTO `sensors` (name,type,modelid,manufacturername,uniqueid,swversion,fingerprint,deletedState,mode) VALUES
	('Power','ZHAPower','ROB_200-011-0','ROBB smarrt','ec:1b:bd:ff:fe:7f:38:be-01-0b04','2.5.3_r47','{"d":257,"ep":1,"in":[2820],"p":260}','normal','1'),
	('Consumption','ZHAConsumption','ROB_200-011-0','ROBB smarrt','ec:1b:bd:ff:fe:7f:38:be-01-0702','2.5.3_r47','{"d":257,"ep":1,"in":[1794],"p":260}','normal','1');

After that the dimmer gets the /sensor endpoints and all works well. They also keep updating. This makes me even more wondering why there is a whitelist :-)

I couldn't figure out what the fingerprint column represents, but besides that this means you can add these "power" sensors on-the-fly. Curious what others think.

So, anyone that completely understands the codebase, please feel free to add this awesome module the right way, and maybe get the conversion of state.current correctly!

---

While I'm at it (as feedback via e-mail has no success):

1. The two new sensor parameters do not show up in Phoscon. I know its closed-source, but seems like a small trick to add just like other sensors also show in the overview.
2. Running deCONZ with --dbg-info=1 increases fonts and colors of the GUI.
3. I noticed that the Supported Devices list hasn't got all supported devices.
   • For instance the LUPUS 12134 (temperature sensor) is supported, but not in the list. Looking at the API source-code, it seems to be a Tuyatec RH3052 (OEM), which is indeed supported. But you won't know that until you buy one and read the modelnumber.
   • The same with the Aqara MCCGQ11LM (Door and Window Sensor). It is supported looking through the issue-list but doesn't show up on the Supported Devices list. It seems to show up as a lumi.sensor_magnet device which works, but again you only know that after you buy it.
   • To avoid duplicate questions and make it easier to buy a (supported) product, I would opt for a way to use additional naming in the Supported Devices list.
4. The deCONZ Manual (PDF) mentions Attribute Reporting (7.2.3) and Bindings (8), but doesn't tell you that you need to create a binding to get a continues flow of attributes to your gateway (0x0000). This makes sense when you understand things completely, but in my case I got that from one of the awesome explanations of Mr. Baauw laying around in a issue here on Github. The Manual mostly explains what things are but not what things actually do. The Wiki does a better job.
5. Does /usr/bin/deCONZ-WIFI2.sh needs to be active on a RPI with Conbee II?

[ebaauw]

Removing the actual device from the network does not remove the two new parameters in /sensors. The result from deCONZ and Phoscon regarding removal doesn't change this fact. The only way to remove these seems to be deleting the rows in the zll.db sensors table from the SQLite file.

You need to remove the resources through the API (using DELETE /sensors/xx). Note that if you don't reset the sensor, it will re-appear in the GUI. Even if you do, it might re-appear as long as it's still in the neighbour table of one of the routers.

When I put back the default API (libde_rest_plugin.so: v1.16.0) from the debian-sources, these new parameters (ZHAConsumption & ZHAPower) are still there and keep updating.

/sensors resources get restored from the database, but some attributes are only re-created when the device is whitelisted in database.cpp.

Makes me wonder why whitelisting via source-code is needed in the first place.

To create the /sensors resource on pairing. Note that there's probably half a dozen places in the code where devices are whitelisted, not just for creation of the resource, but also to create the associated group for wireless switches, create the bindings, setup attribute reporting, and handle device-specific stiff (like the scaling of state.current and the likes).

They also keep updating.

Probably because you haven't reset the dimmer, and it has retained the bindings and attribute reporting. Could also be that they're whitelisted on cluster, mac address, and/or manufacturer code, and the model id isn't used for that.

I couldn't figure out what the fingerprint column represents

It's the info from the basic descriptor: device type, endpoint, server clusters, client clusters and profile.

[Preto]

Thanks for your answer and time. I will give deleting through the API a try. I was hoping upon a cascade delete of (sub)devices when the actual device is removed. Doesn't seem logical to leave them around imho. :-)

In regards of the whitelisting, I get it. For my dimmer it probably also needs some more code changes/whitelists, as I understand from you. For instance: I needed to do the pairing twice, or pair only via Sensors and get the /light resource automagically. This way I get the light and the sensors to appear.

Probably because you haven't reset the dimmer

That's correct, I didn't reset the dimmer.

Can you, or someone else, make the correct code-changes for this dimmer module? So that the Sensors appear, bindings are done and the right conversion for the values returned from the Metering and Measurement cluster? I'll try to supply as much additional information as possible below.

There are 3x Ikea Ledare LED GU10 lights of 7,5W each behind this dimmer. The values from the screenshot's are:

• Simple Metering cluster:
  • Current Summation Delivered = 2943239
    • API: state.consumption in ZHAConsumption
    • This should be in kWh? Both the API and deCONZ agree on this number, so no calculation is done yet? While looking at the earlier provided screenshots, shouldn't the calculation be: Current Summation Delivered * Multiplier / Divisor = 2943239*1/3600000 = 0,817566388 kWh?
• Electrical Measurement cluster:
  • RMS Voltage = 1352
    • API: state.voltage in ZHAPower
    • A calculation should be done here I guess. This would then be 135,2 Volts if I'm correct.
  • RMS Current = 109
    • API: maybe state.current in ZHAPower?
    • The screenshot shows a RMS Current of 109, yet the state.current shows a lot bigger number. So probably some calculation is done here. If I do a fresh reading on deCONZ right now it shows 108 and the API shows a state.current of 42464. Shouldn't this calculation be RMS Current * AC Current Multiplier / AC Current Divisor = 108*1/1000 = 0,108A?
  • Active Power = 126
    • API: state.power in ZHAPower
    • Really in Watts? When the Current Level (of Level Control) is set to 254, the Active Power is fluctuating between 196 and 201. Looking at comment Updating Peanut Plug firmware with deCONZ #419 (comment) the calculation would be Active Power * AC Power Multiplier / AC Power Divisor = 201*1/10 = 20.1 Watt? This looks more in the right direction...

Are you or anyone else willing to make the right updates in the code in the right places?

[Preto]

@SwoopX thanks for adding!
I've tested your changes for the ROB_200 dimmer and it seems to work! In the meantime I've got the non-whitelabel version as well. There sensors are also not supported, so I've added it based on your code as well. Unfortunately I've noticed that I made a boo-boo on the MAC address! Kinda strange that it even worked with the wrong mac-address prefix :-/ I've corrected the original post to avoid confusion.

The correct ones are as follow for both identical built-in-dimmers:

const quint64 silabs3MacPrefix    = 0xec1bbd0000000000ULL;

Manufacturer Name:	ROBB smarrt
Model Identifier:	ROB_200-011-0
SW Build ID:		2.5.3_r47

const quint64 silabs5MacPrefix    = 0x588e810000000000ULL;

Manufacturer Name:	Sunricher
Model Identifier:	Micro Smart Dimmer
SW Build ID:		2.5.3_r49

There both from Silicon Laboratories. Triple checked them this time, sorry for the inconvenience.

I saw that you made the calculations as well. They do seem to defer on what I thought was right, shown just above this post. If I use the changes that you propose, the following can be read in both the API and deCONZ:

ZHAConsumption

• state.consumption 895 (deCONZ Current Summation Delivered: 3224661)

ZHAPower

• state.current 62464 (deCONZ RMS Current : 128)
• state.power 20 (deCONZ Active Power: 200)
• state.voltage 187 (deCONZ RMS Voltage : 1878)

It seems that I'm now missing the precision due to the rounding. I see that in a couple of more comments on other issues as well. Still can't make sense of the numbers though, in particular the current.

Thanks for helping!

[SwoopX]

There both from Silicon Laboratories. Triple checked them this time, sorry for the inconvenience.

Haven't noticed that one so no worries ;)

There sensors are also not supported, so I've added it based on your code as well. Unfortunately I've noticed that I made a boo-boo on the MAC address! Kinda strange that it even worked with the wrong mac-address prefix

Without explaining the mechanism behind it, that's kinda normal in that particular case. What most likely will not work out of the box is the attribute reporting and eventually calculation of values without any code changes.

For the values you mentioned, I'm not sure if I can follow you here. Yes, you loose precision rounding as internally, integers are used instead of floats. Although it sounds comparable easy, a change is far from it so I'm afraid that's currently one death to live with. For the adequacy of the reported values from the devices, that's just what they are. However, please take note of the units the REST API reports upon.

Consumption is in Wh, power in Wh, current in mA and voltage in V.

[Preto]

Thanks, yeah you put effort in adding support for the devices I noticed, but I provided the wrong MacPrefix at first. Tried to be as complete as possible though, hehe. You got the right ones now!

For the values you mentioned, I'm not sure if I can follow you here

I'll explain it with some live readings. I'm looking at the original dimmer (ROB_200-011-0) within the deCONZ GUI. Under the 0B04 Electrical Measurement Cluster I read at 0x0508 RMS Current a value of 111. Looking at the same module through the API, I read a value of 45464 in state.current (under type ZHAPower), assuming this was the RMS Current.

If I understand you right, this is 45464 mA. That would be 45,464 Ampère!

Lets do another reading, this time under the 0702 Simple Metering Cluster I read at 0x0000 Current Summation Delivered a value of 3476044 in the deCONZ GUI. Looking at the API again, I read a value of 965 in state.consumption (under type ZHAConsumption), again assuming this is the same.

This would be 965 Wh according to your info above. Looks also a bit much to me, as behind this dimming module there is a lamp wit 3 GUI10 LED lights of 7.5W, 600 lm each :)

I'm getting nuts from these numbers...

Yes, you loose precision rounding as internally, integers are used instead of floats.

The precision part I understand now. I see that this is the case with the state.voltage and state.power in your branch. The API first exposed 126 and that's now 13 (state.power) with your changes.

A possible solution would be to provide the (full) integer value as deCONZ does, in my case, and also expose the divider/multiplier through the API so clients consuming the API can do there own calculation(s) or not. Although this would be a breaking change I guess?

[SwoopX]

Sorry, totally forgot to come back on this.

If I understand you right, this is 45464 mA. That would be 45,464 Ampère!

That's indeed rubbish. The value got multiplied by 1000 instead of kept as is. I'll have it covered by a new commit.

For the other remarks on the values, I'm afraid I cannot really follow you. There's indeed some math to be done with the values presented in deconz GUI, but your calculations seemed to be pretty much correct up here #2829 (comment). However, for the power calculation, your device does only offer the values displayed + I don't get where the 200 came from.
Also the consumption looks somehow reasonable to me. You have 22,5W as load to apply, consumption was 965 resulting in ~43h of operation in total. Of course, I don't know for how long you got the device installed but again, the calculation is based on the values displayed.

Please do not forget that most devices have a measurement accuracy of +-5% or so, so stuff never adds up perfectly.

Does that make it a bit clearer?

[Preto]

Excuse the delay here also. Thank you for explaining. I've updated to the latest (dev) release and it looks better now.

Unfortunately our MAC-prefix mistake is still present in this release. The prefix silabs2MacPrefix should have been silabs3MacPrefix as the MAC prefix of ROB_200-011-0 is EC1BBDF*

Secondly, can you also add the non-whitelabel version? It seems not yet in the code. It's MAC address is different and not yet defined in the source-code, but is also from the same MAC vendor, Silicon Laboratories. All info below for both identical dimmers for your convenience:

Whitelabel built-in dimmer (now supported)	Non-whitelabel built-in dimmer
Node Info IEEE 0xec1bbdf* id name value 0x0004 Manufacturer Name ROBB smarrt 0x0005 Model Identifier ROB_200-011-0 0x4000 SW Build ID 2.5.3_r47	Node Info IEEE 0x588e81f* id name value 0x0004 Manufacturer Name Sunricher 0x0005 Model Identifier Micro Smart Dimmer 0x4000 SW Build ID 2.5.3_r49

See also my previous comment: #2829 (comment) 😁

Thanks!

[SwoopX]

Closing this as device is now supported with .79 beta.