Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IKEA INSPELNING Smart Plug with kWh meter #7948

Open
1 task done
NotSoScientific opened this issue Sep 28, 2024 · 21 comments · May be fixed by #7959
Open
1 task done

IKEA INSPELNING Smart Plug with kWh meter #7948

NotSoScientific opened this issue Sep 28, 2024 · 21 comments · May be fixed by #7959

Comments

@NotSoScientific
Copy link

Is there already an existing issue for this?

  • I have searched the existing issues and there is none for my device

Product name

INSPELNING

Manufacturer

IKEA

Model identifier

INSPELNING Smart plug

Device type to add

Switch

Node info

Screenshot 2024-09-28 at 12 37 38

Endpoints and clusters

Screenshot 2024-09-28 at 12 39 35

Basic

Screenshot 2024-09-28 at 12 47 21

Further relevant clusters

Power Configuration

On/Off

Screenshot 2024-09-28 at 12 42 46

Level Control

Screenshot 2024-09-28 at 12 43 02

Color Control

Thermostat

Simple Metering

Screenshot 2024-09-28 at 12 49 36

Electrical Measurement

image Screenshot 2024-09-28 at 12 44 39 Screenshot 2024-09-28 at 12 45 01 Screenshot 2024-09-28 at 12 45 40 Screenshot 2024-09-28 at 12 45 53

Any other cluster of relevance/interest

OTAU table row

Reports manufacturer 0x117C and image 0x9f3e
Screenshot 2024-09-28 at 12 48 11

The device currently exposes itself to the REST API as an outlet, which allows for the on/off control, however the kWh meter seems to not report yet.

This IKEA Zigbee outlet is currently rolling out globally. The IKEA subreddit has reported that an OTA Update may be needed to use all features, this device was not seen in the OTAU file folder. If you have further questions, feel free to reach out.

@bluemoehre
Copy link
Contributor

bluemoehre commented Oct 1, 2024

Interesting device! Especially after the new Firmware (v45) for Xiaomi / Aqara Plug seems to remove some features like Voltage, Current, Status after Powerloss.

Before integrating a DDF,

  • ensure Electrical Metering (0b04) multipliers 0x0604 & divisors 0x0605 are handled correctly
  • ensure Simple Metering (0702) multipliers 0x0301 & divisors 0x0302 are handled correctly

... which both currently is still an issue for other products and causes devices to report wrong values.

Additionally it's a real struggle to fix this locally by custom DDFs due to another problem in merging general definitions over custom ones.

Related issues
#6251

Related files:
/devices/generic/items/state_current_item.json
/devices/generic/items/state_power_item.json
/devices/generic/items/state_voltage_item.json

Requirement
Maybe we need some additional fields like config/power_divisor to hold the multiplier values, so we can use these in the value calculation?

Example:

{
  "name": "state/power",
  "parse": {
    "at": "0x0000",
    "cl": "0x0000",
    "ep": 0,
    "eval": "Item.val = Attr.val / R.item('config/power_divisor').val",
    "fn": "zcl:attr"
  },
  "default": 0
}

@ebaauw
Copy link
Collaborator

ebaauw commented Oct 1, 2024

That won’t work, for a number of reasons:

  • The API standardises on weird units (like 0.1A, if memory serves). This was needed in the time it couldn’t handle floating point values;
  • You would need to apply both the multiplier and divisor, but only when supported by the device (or default them to 1);
  • Historically, not all devices report correct multiplier and/or divisor values.

it’s probably easiest to hard- code the conversion per device model in the DDF. What problem merging general definitions are you referring to? I find this works without any issues - the DDF overwrites any generic item.

@bluemoehre
Copy link
Contributor

You would need to apply both the multiplier and divisor, but only when supported by the device (or default them to 1)

That's correct, I simply didn't add this to my example. But as far as I see the specs - the values default to 1!

The API standardises on weird units (like 0.1A, if memory serves). This was needed in the time it couldn’t handle floating point values

Historically, not all devices report correct multiplier and/or divisor values.

Okay, got that one. But doesn't it make more sense to make it better now, make it more generic & become more future proof, and just care about the legacy with custom rules for the old devices, rather than making weird moves for everything?

What problem merging general definitions are you referring to?

Gonna make a dedicated ticket soon, so we don't mix up things in this one.

@bluemoehre bluemoehre linked a pull request Oct 7, 2024 that will close this issue
@bluemoehre
Copy link
Contributor

FYI: IKEA also offers another smart plug and a bundle with a RODRET, both called TRETAKT. That plug is visually identical besides having a white front. TRETAKT does not support any metering, it's a simple on/off device.

@janip81
Copy link

janip81 commented Oct 8, 2024

I tried the DDF made by @bluemoehre and it works i get measurments but should it be so slow on updating? i get power updates like every 5minutes only, could this be configured to be more precise?

@Mimiix
Copy link
Collaborator

Mimiix commented Oct 8, 2024

I tried the DDF made by @bluemoehre and it works i get measurments but should it be so slow on updating? i get power updates like every 5minutes only, could this be configured to be more precise?

Yes, report intervall in deCONZ. But this is not the place to ask ;)

@Mimiix Mimiix linked a pull request Oct 8, 2024 that will close this issue
@bluemoehre
Copy link
Contributor

I tried the DDF made by @bluemoehre and it works i get measurments but should it be so slow on updating? i get power updates like every 5minutes only, could this be configured to be more precise?

If I understood the docs correctly, the DDF defines the polling interval only (template defaults to 300s aka 5min). The report interval is configured in the device itself - and possibly changeable in deCONZ.
(I already saw devices which have the options to set the min & max report time, also the amount of change which triggers an immediate report.)

Right now I have to admit I do not see any of these options in the INSPELNING. I tried to cause huge changes in power but the device did not actively report - so I get only 5min intervals, too.

Maybe we have to decrease the polling interval to 60s?
(Unfortunately I could not find any docs about how the bindings work, just some unexplained examples.)

@ebaauw
Copy link
Collaborator

ebaauw commented Oct 8, 2024

The attribute reporting configuration is standard Zigbee functionality. Double-click on the attribute in the GUI for a popup window. These can be set in the DDF as well, under the bindings section.

Note that this configures the reporting interval, not necessarily the interval at which the device takes a measurement.

Unfortunately I could not find any docs about how the bindings work, just some unexplained examples

Look in the GUI user guide under help.

@bluemoehre
Copy link
Contributor

bluemoehre commented Oct 8, 2024

These can be set in the DDF as well, under the bindings section.

This is the part I didn't understand yet - sorry. I found you can drag & drop attributes to the DDF editor's binding section, but fields I see for other devices, do not appear here. Also this doesn't add a reporting property to the DDF.
Changed settings in the modal (after double-clicking an attribute) are not reflected in the DDF as well, so I don't know how to get these settings copy pasted there.

Look in the GUI user guide under help.

Unfortunately it's not possible to use the GUI help since I switched to Conbee II using Docker. If you click it, nothing happens. But that's another issue. The docs I was checking are the official ones linked in the README:
https://dresden-elektronik.github.io/deconz-dev-doc/modules/ddf/
But these do not explain that specific part of the bindings/reporting (yet).

Anyhow, I guess it would make sense to setup some faster reporting settings by default.
Is there some default or recommended value for all plugs or similar?
And is there a copy of the help files outside of deCONZ GUI, so I can read it?

@ebaauw
Copy link
Collaborator

ebaauw commented Oct 8, 2024

I don't use the DDF editor that often, but under the Bindings tab, you can setup bindings and attribute reporting, by dragging the cluster into the left area Bindings and subsequently dragging the attribute into the right area Reporting Configuration, while the binding is selected.

If you click it, nothing happens

Same for me, so that's probably an omission in the latest version.

A quick Google search for "deCONZ User Manual" finds https://www.dresden-elektronik.com/wireless/software/deconz.html?file=files/dresden-elektronik/content/downloads/dokumente/funktechnik/deCONZ-BHB-en.pdf. See sections 7.2.3 and 8.1 for how to setup attribute reporting and bindings.

@bluemoehre
Copy link
Contributor

[...] and subsequently dragging the attribute into the right area Reporting Configuration, while the binding is selected.

🤯 I would have never guessed it works that way. That was the missing part for me!

See sections 7.2.3 and 8.1 for how to setup attribute reporting and bindings.

Actually I was on that, but is it up-to-date? It looks different than the current UI and I didn't find what you told me above ... or it's too unclear / confusing to me.
(In my opinion the linked docs in the README should enable every dev to do daily tasks, so we get a better / faster flow, involving less people / time. Especially adding new devices seems to be a very frequent job. But again - that's another topic)

Many thanks, @ebaauw ! I gonna try adjusting the DDF again and check if the device will report in a more meaningful way.

@bluemoehre
Copy link
Contributor

bluemoehre commented Oct 8, 2024

i get power updates like every 5minutes only, could this be configured to be more precise?

@janip81 please try the updated DDF. It now uses more meaningful report intervals:

  • on state: every 1s - 10min
  • electrical measurements: every 10sec - 5min
  • simple metering: every 1min - 1hour

@janip81
Copy link

janip81 commented Oct 9, 2024

@janip81 please try the updated DDF. It now uses more meaningful report intervals:

  • on state: every 1s - 10min
  • electrical measurements: every 10sec - 5min
  • simple metering: every 1min - 1hour

@bluemoehre I seems to get faster usage (Watt) reading now when power changes. so seems to work. Will do more testing

@ebaauw
Copy link
Collaborator

ebaauw commented Oct 9, 2024

Please make sure the refresh rate for reading an attribute is 60s longer than the periodic reporting rate for that attribute. We only want to fall back to polling the device, in case reports go missing.

@bluemoehre
Copy link
Contributor

bluemoehre commented Oct 9, 2024

Should it be exactly X + 60s, or just higher than the max reporting interval? Currently it is at the double or multiple.

Is there a best practice or standard for this?
If that's the case, I would really like to document it somewhere and have it tested by an automation whenever we add/edit a DDF file.

@NotSoScientific
Copy link
Author

#7959 allows the Consumption and Power to be reported throught REST. However, the other variables, such as Voltage, are not (yet) directly reported. Thanks everyone for your contributions!

@bluemoehre
Copy link
Contributor

@NotSoScientific here voltage is reported using that DDF. Can you re-check and maybe re-join the device?

image

@NotSoScientific
Copy link
Author

@bluemoehre

Yeah I have the same in the Phoscon app:
image

However, when accessing throught REST in Home Assistant, it shows the following entities:

image

This is after refreshing, I have not had the time yet to readopt the device, will update this weekend.

@bluemoehre
Copy link
Contributor

You can also try in HA to reload deCONZ device list first. So you won't have to re-add it to the network.
Goto http://\<homeassistant:port\>/config/integrations/integration/deconz and hit "reload".

Copy link
Contributor

github-actions bot commented Nov 1, 2024

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

@github-actions github-actions bot added the stale label Nov 1, 2024
@bluemoehre
Copy link
Contributor

Bump, this is waiting for PR(s)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants