HG08673 LIDL SilverCrest smart plug with monitoring (EU, FR)

Phoscon App General Support
21

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?

grafik
grafik814×128 30.9 KB

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. :disappointed:

22

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?

23

Oh no… really? :frowning:

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

24

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.

25

Yes, but that’s where I’m useless :sweat_smile:

26

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"
}

grafik

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
27

Is the DDF in the repository the correct one? If not feel free to do a PR.

Nvm misread.

28

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.

29

Solved by updating deCONZ to latest v2.28.1 (which contained two relevant fixes, one targeting exactly this issue) with