DDF for IKEA INSPELNING smart plug

[bluemoehre]

Solves #7948

Need verification / double check of Consumption calculation.
Phoscon shows value as wH, while comments and docs states value should be in kWh.

Anyway, I have already tested and confirmed that the raw value 0x0702 / 0x0000 in deCONZ GUI is in wH. Based on the divisor value from 0x0302, I added a x1000 division.

Maybe @ebaauw can help?

[github-actions]

Hey @bluemoehre, thanks for your pull request!

Tip

Modified bundles can be downloaded here.

DDB changes

Modified

• ikea/inspelning_smart_plug.json : INSPELNING smart plug ✔️

Validation

Tip

Everything is fine !

_{🕠 Updated for commit 88e3eeb}

[ebaauw]

The API should report consumption in Wh, see https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/generic/items/state_consumption_item.json.

If the device reports Current Summation Delivered in Wh, no conversion is needed. I don't use Phoscon, and have no clue how they report consumption.

The devices that I have don't use divisors/multipliers on Simple Metering, but instead use Summation Formatting. I never really figured out how that works, so I tend to use a known load (e.g. an old 60W Tungsten bulb), and see what the device reports to figure out it's scaling. Also check the Unit of Measure attribute. If that's kW and kWh binary (what I see in my cases), and 0x0000 reports in Wh, the divisor should be 1000, to transform Wh to the advertised kWh.

[SwoopX]

Actually, the logic here is quite simple:
The unit of measurement is kW/kWh. To get it, take the value and apply multiplier and divisor.

If, for the given device, attribute 0x0000 gives us the value of 4, the math is 4*1/1000 = 0,004. That means the device reports already in Wh and the DDF value calculation is incorrect.

Ideally, the multipliers and divisors are correct. However, we also had enough devices out there where that is just rubbish.

[bluemoehre]

I was testing 1h having a 6.5W bulb connected and total consumption (0x0702 / 0x0000) reported 6.

As far as I understand these data, there are only two approaches possible:

A

Formatting block just tells clients how to convert values to get to "kW & kWh binary" units, which is a default display to the user.

• raw values are in base units (plain Watts - no milli, no kilo etc.)
• raw values are provided to the API (no DDF conversion takes place)
• formatting info is provided in the API as well (clients can use it if they want to convert)

B

Formatting block tells devs how to convert values to meet standards.

• Values must be converted to meet standards (DDF conversion takes place)
• Standard is described in the formatting block (to meet "kW & kWh binary")
• Conversion needs to take place before providing data to the API (clients get user-ready data)

(C)

Formatting block / measured value is just bananas, and you have to find out yourself, as @SwoopX pointed out ;)

---

It's just a matter of what is the default/specs.
For both variants (A+B) the available data + formatting info generally is correct.

Based on your feedback @ebaauw, as well as what I see in the Phoscon UI, I think the first variant is the one to go.
So, I gonna remove the division.

[SwoopX]

Formatting block / measured value is just bananas

Not sure where I should have said that, but I warned taking things for granted. That's also why it was suggested to verify with a known load. The zigbee spec is quite clear in my view how to use the formatting attributes (as described above) and also that the summation formatting doesn't play a considerable role 🤷‍♂️

[bluemoehre]

I noticed this DDF is working fine up to 999 Watt:

/api/sensors

[
"119": {
        "config": {
            "on": true,
            "reachable": true
        },
        "etag": "fc5336ccc8a702bc7088ee0b430738b1",
        "lastannounced": null,
        "lastseen": "2024-10-12T12:54Z",
        "manufacturername": "IKEA of Sweden",
        "modelid": "INSPELNING Smart plug",
        "name": "Consumption 119",
        "state": {
            "consumption": 102,
            "lastupdated": "2024-10-12T12:27:59.387"
        },
        "swversion": "2.4.34",
        "type": "ZHAConsumption",
        "uniqueid": "xx:xx:xx:xx:xx:xx:xx:xx-01-0702"
    },
    "120": {
        "config": {
            "on": true,
            "reachable": true
        },
        "etag": "ac980bb68841173491ca2404464923b9",
        "lastannounced": null,
        "lastseen": "2024-10-12T12:54Z",
        "manufacturername": "IKEA of Sweden",
        "modelid": "INSPELNING Smart plug",
        "name": "Power 120",
        "state": {
            "current": 3,
            "lastupdated": "2024-10-12T12:54:56.327",
            "power": 2,
            "voltage": 237
        },
        "swversion": "2.4.34",
        "type": "ZHAPower",
        "uniqueid": "xx:xx:xx:xx:xx:xx:xx:xx-01-0b04"
    }
]

Consuming >= 1000 Watt, the device changes the divisors / multipliers, which leads to wrong values when using hardcoded factors. That behavior was already reported here: Koenkk/zigbee2mqtt#23961 (comment)

So my idea #7948 (comment) became a real requirement sooner as expected.

I need to know how to access the other attributes (cluster 0x0b04, address block 0x0600) within the parse/ eval property for a correct calculation.

Result should be similar to:
"eval": "Item.val = Attr.val * R.item('config/power_multiplier').val / R.item('config/power_divisor').val",

Can anyone help?

[ebaauw]

Now there's an interesting use case. I think the multiplier and divisor items should be (read-only) state items, rather than (read-write) config items. I always thought of them as (constant) capabilities items, but since they might change value (other than through firmware upgrade), they clearly aren't. I also think we should not expose the multiplier nor divisor item over the API, since we don't want API clients to implement the logic to handle these.

Does the device do something similar for current?

So we would need to create two non-public items and change the eval to consider these, while taking care of the Wh vs kWh logic. Since the new items aren't exposed over the API, I think no change to the C++ code is needed for them.

Note to self: need to get one of these plugs.

[bluemoehre]

Feel free to add another commit vs my branch, if you know a solution, @ebaauw .

Does the device do something similar for current?

Didn't see that yet. Still haven't the update to the latest version, due it's still unavailable in DE, or still at beta stage. (People reported a completely different URL to get that from - I guess its a pre-prod host)

I want to point out another thought:

Since I already tested a lot what is a meaningful "report interval" + "minimal change to report", it makes sense to use the factor for the "minimal change to report" value. Connecting a Raspberry, you may be interested in reporting changes of 0,1 Watts, but having a toaster you are more interested in 10 Watt steps. When the factor changes the report config could be changed as well. What do you think?

---

For anyone just stumbling into this topic, here are some docs:
Zigbee Alliance - Cluster Library Specification (Rev 8 / 2021)

[ebaauw]

it makes sense to use the factor for the "minimal change to report" value.

I don't think it does, actually. The reporting change is on the raw value, as reported by the attribute, not on the derived value after considering the multiplier/divisor. So if you set a change of 1, it will report changes from 1W between 0 and 1000W and changes from 10W above 1000W (not sure I got the scale right, but I hope you get the idea). This is probably exactly what you want.

The idea is intriguing, though. I've never seen attribute reporting configuration being changed dynamically. Not sure if that's even doable from DDF. You could send the correct Zigbee message using zcl:cmd with the right fc (making sure to send a generic rather than a cluster-specific command), but I'm not sure how to trigger it. I'd probably create a dummy item with a write to send the report config, make the multiplier/divisor visible on the API, and create a rule to update the dummy item when the multiplier/divisor changes. I would be an interesting proof of concept, but I sure wouldn't recommend this for production setups.

[bluemoehre]

This is probably exactly what you want.

You are right! Actually it will result exactly in that behavior I wish. What a great Idea by IKEA to use the attributes that way.

So we only need to use the factors in the evaluation of the value to get this working.

[bluemoehre]

I think the multiplier and divisor items should be (read-only) state items

@ebaauw can you add a commit to my branch or briefly tell me how I can add that part?

[ebaauw]

I don’t I see your branch, it’s probably only available on your fork?

Basically, you need create two new item files in devices/generic/items for state/power_multiplier and state/power_divisor. I don’t think they need to be exposed by the API (for now), so this wouldn’t require any C++ changes. Not sure if the devices actually uses both.

I did pick up an INSPELNING at IKEA, but have yet to put it to the test. I want to install it for my washing machine, but better double check the supported load first.

[bluemoehre]

I don’t I see your branch, it’s probably only available on your fork?

Yes, it's on my fork. Most of the time you can't create branches on remote repos, so I'm used to that workflow. (Re-Checked: right now it's still disabled =)

[bluemoehre]

Basically, you need create two new item files in devices/generic/items for state/power_multiplier and state/power_divisor. I don’t think they need to be exposed by the API (for now), so this wouldn’t require any C++ changes. Not sure if the devices actually uses both.

I drafted another PR #7978 for this.