In deconz right click on the node. Edit DDF. Change the status from silver to gold.
Save and then remove and repair the device. It’s supported, just not tested.
Hi Mimiix
Can i do a similar thing for my device?
mine is only draft.
Your device is different.
I recommend opening a device request.
1 Like
Hi Mimiix
The Device has the same id as another device in your device list.
https://dresden-elektronik.github.io/deconz-rest-doc/devices/tuya/_TZ3000_typdpbpg_smart_plug_eu/
but the manufacture name has changed a bit, i guess its because this device is sold by many companies with there own name on it.
should i still open a new device case or how should i proceed?
Hi,
As the manufacturer name is different, we can not know for sure its the same device. Thats why you need to open a new device request.
So yes, you need to open an new device request.
Oh dear. Running from one issue (shitty hardware/Blitzwolf BW-SHP13 (_TZ3000_amdymr7l) reports ZERO current consumption regularly - #14 by bcutter) to to the other - the _TZ3000_j1v25l17 is not showing any kWh measurements.
I checked the DDF and it is set to Gold already (running deCONZ 2.25.3).
What can I do to make this device show kWh measurements?!?
This for sure is a special deCONZ only thing… 
same like
Looks like there was a typo in the DDF that got resolved.
Ah interesting. But I don’t think that’s the issue here.
- The referenced bug seems to have been introduced later. As mentioned, I’m running latest available (HA deCONZ addon user) deCONZ v2.25.3.
- 2.25.3 shipped DDF looks like this:
So the search goes on. Interestingly the 0702 contains this value which slowly increases. No idea why it does not update in HA.
Maybe it’s not a deCONZ but a HA deCONZ integration issue looking at the HA log:
15 raw should translate to 0.15 kWh, shouldn’t it?
When you clicked read, did it update in ha?
No. I’m restarting HA now to see if the “deconz does not generate unique IDs” errors disappear - and hopefully the entities’ value updates.
What does the API show?
lights:
{
"capabilities": {
"alerts": [
"none",
"select",
"lselect"
]
},
"config": {
"groups": []
},
"etag": "XXXXXXXXXXXXXXXXXX",
"hascolor": false,
"lastannounced": "2024-08-23T12:36:23Z",
"lastseen": "2024-08-23T14:10Z",
"manufacturername": "_TZ3000_j1v25l17",
"modelid": "TS011F",
"name": "XXXXXXXXXXX",
"state": {
"alert": "none",
"on": true,
"reachable": true
},
"swversion": "1.0.4",
"type": "Smart plug",
"uniqueid": "XXXXXXXXXXXXXXXXX-01"
}
sensors (power):
{
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"etag": "XXXXXXXXXXXXXXXXX",
"lastannounced": "2024-08-23T12:36:23Z",
"lastseen": "2024-08-23T14:33Z",
"manufacturername": "_TZ3000_j1v25l17",
"modelid": "TS011F",
"name": "Power 115",
"state": {
"current": 598,
"lastupdated": "2024-08-23T14:33:52.733",
"power": 98,
"voltage": 241
},
"swversion": "1.0.4",
"type": "ZHAPower",
"uniqueid": "XXXXXXXXXXXXXXXX"
}
Anything suspicious here @Mimiix ?
Ah, here we go:
sensors/consumption:
{
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"etag": "XXXXXXXXXXX",
"lastannounced": "2024-08-23T12:36:23Z",
"lastseen": "2024-08-23T14:38Z",
"manufacturername": "_TZ3000_j1v25l17",
"modelid": "TS011F",
"name": "Consumption 116",
"state": {
"consumption": 0,
"lastupdated": "none"
},
"swversion": "1.0.4",
"type": "ZHAConsumption",
"uniqueid": "XXXXXXXXXXXXXX-0702"
}
So why does the API report "consumption": 0, when the attribute has (currently) 29 stored?
What transforms the raw data to the API - the DDF?
Here’s the full DDF currently used (stock / default as of deCONZ v2.25.3):
{
"schema": "devcap1.schema.json",
"manufacturername": ["_TZ3000_nkcobies","_TZ3000_j1v25l17","_TZ3000_ynmowqk2"],
"modelid": ["TS011F","TS011F","TS011F"],
"product": "HG08673 LIDL SilverCrest smart plug with monitoring (DK, EU, FR)",
"sleeper": false,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_SMART_PLUG",
"restapi": "/lights",
"uuid": [
"$address.ext",
"0x01"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"parse": {"fn": "zcl:attr", "ep": 1, "cl": "0x0000", "at": "0x0001", "script": "../tuya/tuya_swversion.js"},
"read": {"fn": "zcl:attr", "ep": 1, "cl": "0x0000", "at": "0x0001"}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "state/alert",
"default": "none"
},
{
"name": "state/on"
},
{
"name": "state/reachable"
}
]
},
{
"type": "$TYPE_POWER_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0b04"
],
"fingerprint": {
"profile": "0x0104",
"device": "0x0051",
"endpoint": "0x01",
"in": [
"0x0000",
"0x0B04"
]
},
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"parse": {"fn": "zcl:attr", "ep": 1, "cl": "0x0000", "at": "0x0001", "script": "../tuya/tuya_swversion.js"}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/current"
},
{
"name": "state/lastupdated"
},
{
"name": "state/power"
},
{
"name": "state/voltage"
}
]
},
{
"type": "$TYPE_CONSUMPTION_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0702"
],
"fingerprint": {
"profile": "0x0104",
"device": "0x0051",
"endpoint": "0x01",
"in": [
"0x0000",
"0x0702"
]
},
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"parse": {"fn": "zcl:attr", "ep": 1, "cl": "0x0000", "at": "0x0001", "script": "../tuya/tuya_swversion.js"}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/consumption",
"refresh.interval": 420,
"parse": {
"at": "0x0000",
"cl": "0x0702",
"ep": 1,
"eval": "item.val = 10 * Attr.val"
}
},
{
"name": "state/lastupdated"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0006",
"report": [
{
"at": "0x0000",
"dt": "0x10",
"min": 1,
"max": 360
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0702",
"report": [
{
"at": "0x0000",
"dt": "0x25",
"min": 1,
"max": 360,
"change": "0x0000000A"
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0B04",
"report": [
{
"at": "0x0505",
"dt": "0x21",
"min": 1,
"max": 360,
"change": "0x00000001"
},
{
"at": "0x0508",
"dt": "0x21",
"min": 1,
"max": 360,
"change": "0x00000064"
},
{
"at": "0x050B",
"dt": "0x29",
"min": 1,
"max": 360,
"change": "0x00000001"
}
]
}
]
}
The only difference compared to the current deconz-rest-plugin/devices/lidl/hg08673.json at master · dresden-elektronik/deconz-rest-plugin · GitHub I could spot is:
2.25.3:
"eval": "item.val = 10 * Attr.val"
latest on GitHub:
"eval": "Item.val = Attr.val * 10"
That’s not relevant at all and a wrong trail, isn’t it? Or is it the small “i” of “item.val”?
I’m starting to get a bit lost here after fiddling around with one device for 3 hours. 
I’m afraid we might need a device request as your device has a different firmware version.
Looking at this screenshots HG08673 LIDL SilverCrest smart plug with monitoring (EU, FR) - #7 by qwik
It looks like the SWversion is different opposed to yours. The screenshot shows 68, yours is 1.0.4
That’s why it’s different. The device simply is different.
@smanar or @de_employees how do we handle these again?
Oh no… really? 
It’s labeled with “version 01/22” so it’s sold for 2,5 years now. The HG08673 has support in deCONZ since May 2023. Is every new software version (device firmware) a new thing for deCONZ?
Looking at how fast things run currently (HA deCONZ addon, you know what I’m talking about - stuck at 2.25.3) I fear being able to fully use this device - WITH consumption reported correctly to the API - might take another 1.5 years. Otherwise I’m running out of proper devices for my use-case which work with deCONZ. I checked prior buying a bunch of those twice if deCONZ supports it - and everything was greenlighted.
I hope a custom DDF is sufficient for this? That’d be something I could comfortably live with (like I do for other workarounds too already).
Not necessarily, but you can imagine that if a device reported in it’s firmware in units of kWh and now new firmware reports in wh it needs a adjustment of *10 if you want to maintain the same output in the api.
Then you get a issue where people with devices running old firmwares need to keep the old DDF and people with new firmwares need a new DDF. That’s where the issue start.
This would be solved if you could simply update your firmware, which is possible if you have the actual update.
This is why I dislike tuya, you can’t trust what you buy as it changes.
Yes, but that’s where I’m useless 
Edit: fixed it myself. I copied the 2.25.3 DDF and changed this to that according to the latest GitHub content:
Copied it to the HA deCONZ addon persistent user DDF storage, a bit of DDF hot reload party and - et voila:
{
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"etag": "XXXXXXXXXX",
"lastannounced": "2024-08-23T12:36:23Z",
"lastseen": "2024-08-23T15:14Z",
"manufacturername": "_TZ3000_j1v25l17",
"modelid": "TS011F",
"name": "Consumption 116",
"state": {
"consumption": 340,
"lastupdated": "2024-08-23T15:11:36.828"
},
"swversion": "1.0.4",
"type": "ZHAConsumption",
"uniqueid": "XXXXXXXXXXXXX-0702"
}
So I assume there’s no need to add another device request. It more seems like the “GOLD” status of the DDF shipped with deCONZ v2.25.3 was anything but GOLD - which is stated as “Safe to use for production networks.”. Nah, that was a good one.
So FOR NOW I’m good. But I’m honestly not sure if that “everything working now after 3 hours!” persists e. g. once deCONZ gets updated in the next months and if it’s therefore safe to remove my custom DDF one day.
1 Like
Is the DDF in the repository the correct one? If not feel free to do a PR.
Nvm misread.
When it comes to this single line:
As mentioned I only changed the 2.25.3 line to the latest GitHub file line, and it is working now. It’s just that I don’t know since when this is working so I can’t be sure which deCONZ update is guaranteed to fully support this SilverCrest device. …which is why I’m likely keeping my custom DDF like forever. Hopefully the miss of the “new” uuid won’t be an issue as currently all my custom DDF don’t have one. Will it?
HA, a bit of GitHub research: this is exactly the fix I came up with too (I knew this line is highly suspicious!):
Unfortunately my GitHub skills are not advanced enough to track down which stable deCONZ release shipped this DDF with this fix.
As a personal summary, this really outlines the need for faster updates when it comes to the HA deCONZ addon. Unfortunately it ultimately is a “perfect” example why it’s so bad running damn old deCONZ versions. I really can’t stress this topic enough. After now spending 3,5 hours (!!!) for integrating just one “new” device (known to deCONZ for 15 months, for many months with DDF GOLD status), I had to act as Sherlock Holmes to in the end apply a patch which has been fixed on 2024-02-25 already and shipped with deCONZ 2.26.1-beta, available as 2.26.3 stable release (Release v2.26.3 · dresden-elektronik/deconz-rest-plugin · GitHub) for exactly 5 months.
Instead of a “5 minutes, stress-free device integration” (yes, this is possible with ConBee hardware and deCONZ!) I spent 3,5 hours and also wasted the time of you here which equals at minimum 4 hours in total.
As a HA deCONZ addon user I’m still stuck at deCONZ v2.25.3. So freaking §&§$%§% finally sort out this situation between Dresden and Home Assistant! @manup seems to do the best possible - looking e. g. at latest discussion Upgrade deConz to v2.27.6 by jannickfahlbusch · Pull Request #3708 · home-assistant/addons · GitHub, but again:
all those unnecessary issues and wasted hours can be avoided.
Speed up addon releases so people don’t need to run 6 months old deCONZ versions (2.25.3 got released at 2024-02-07).
Find a solution with HA team, e. g. by taking over repository control of the HA deCONZ addon or supplying testing resources. Whatever helps.
Solved by updating deCONZ to latest v2.28.1 (which contained two relevant fixes, one targeting exactly this issue) with