Blitzwolf BW-SHP13 (_TZ3000_amdymr7l) reports ZERO current consumption regularly

[bcutter]

I see a (major) issue with the new hardware revision (see Update frequency Blitzwolf BW-SHP13 (TZ3000_g5xawfcq) - #25 by bcutter for history) its current consumption falls to 0 W almost exactly every 5 minutes:

See my custom DDF here:

{
  "schema": "devcap1.schema.json",
  "manufacturername": [
    "_TZ3000_g5xawfcq",
    "_TZ3000_amdymr7l"
  ],
  "modelid": [
    "TS0121",
    "TS011F"
  ],
  "vendor": "Blitzwolf",
  "product": "BW-SHP13",
  "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"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/alert",
          "default": "none"
        },
        {
          "name": "state/on",
          "refresh.interval": 5
        },
        {
          "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"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/current",
          "refresh.interval": 10,
          "default": 0
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/power",
          "refresh.interval": 10,
          "default": 0
        },
        {
          "name": "state/voltage",
          "refresh.interval": 10,
          "default": 0
        }
      ]
    },
    {
      "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"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/consumption",
          "refresh.interval": 300,
          "read": {
            "at": "0x0000",
            "cl": "0x0702",
            "ep": 0,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0000",
            "cl": "0x0702",
            "ep": 0,
            "eval": "Item.val = Attr.val * 10"
          },
          "default": 0
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0006",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x10",
          "min": 1,
          "max": 300
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0702",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x25",
          "min": 1,
          "max": 300,
          "change": "0x0000000A"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0B04",
      "report": [
        {
          "at": "0x0505",
          "dt": "0x21",
          "min": 1,
          "max": 20,
          "change": "0x00000001"
        },
        {
          "at": "0x0508",
          "dt": "0x21",
          "min": 1,
          "max": 20,
          "change": "0x00000064"
        },
        {
          "at": "0x050B",
          "dt": "0x29",
          "min": 1,
          "max": 10,
          "change": "0x00000001"
        }
      ]
    }
  ]
}

---

@Smanar

You have tried to increase time beetween report ?

@Smanar No I have not - because as already mentioned the same DDF is relevant for both hardware revisions/models.

But looking at my DDF again, I think I could split those and set another frequency for the “_TZ3000_amdymr7l” which is having the zero current consumption issue, right?

[Smanar]

Yep, you can split DDF or create a new one in the “user” folder, as this one have priority on the one in the deconz folder. But will be not something easy on HA

For me the easier is removing your model on the existing one and make a new one for test for this manufacture name.

"manufacturername": ["_TZ3000_g5xawfcq", "_TZ3000_amdymr7l"],

But you have too _TZ3000_amdymr7l ?

The similar issue is here Aubess 20A smart plug Zigbee 3.0 · Issue #6423 · dresden-elektronik/deconz-rest-plugin · GitHub

[bcutter]

I removed the new hardware revision both from manufacturername and modelid, saved, performed a hot reload of the changed DDF.

Checked with deCONZ (right click: edit DDF):

• For the old ones my custom config was still referenced, for the new one the default config.
• I did neither reload the deCONZ integration in HA nor restart the deCONZ addon.

I powered up one of the newer plugs (_TZ3000_amdymr7l) and looked at the current consumption graph for a while (at least a few iterations of 5 minute slots which is the interval the “zero consumption bug” kicked in before):

As you can see, that changed really nothing so far.

1. Can I be sure the changed DDF has really been applied to the newer hardware?
2. Which setting in detail might cause this 5 minute-zero consumption-bug? I suspect this one (default DDF):
   
   (changed that to 10 seconds, saved, hot reloaded - no change in the graph in HA)
   …maybe also one of these:
   
   
3. Shall I open an issue for this on the deCONZ GitHub repository?

Not sure how to make any progress on this.

[Smanar]

The line “refresh.interval” is used when reporting is not working, so for you it’s never used, you can remove it from the DDF

Max is the maximum time without reporting.
Change is the difference value that can trigger a report

Can I be sure the changed DDF has really been applied to the newer hardware?

Can enable logging with flag “DDF”, and make a “hot reload” you will see usefull line in debug log.

Not sure how to make any progress on this.

For me need to check on zigbee side, if you enable both “APS” flags in logs you will see the raw value, (need to be enabled in same time than “DDF” to see the zero value to locate the good request.

If the 0 is from the device, it’s device firmware, can do nothing. Except use a hack if there is a way to detect the faulty request.

[bcutter]

So this still renders data unusable, which became a more important issue due to some statistics done with the consumption values:

@Smanar

1. Any new progress on this?
2. Or any other ideas?
3. How (content of DDF) would I ignore/suppress the values of 0 (zero) for current consumption so they are not reported at all? I’d at least give that a try just to see what it would look like in Home Assistant in the end and if it has any (not acceptable) side effects. I’d need a custom DDF based on the default one with a) just for the _TZ3000_amdymr7l and with the "name": "state/consumption", section modified in a way it ignores value of 0 (zero).

Similar to what we did with the battery value for another device here:

It's time to fix Aqara battery bug

Well… as you can see here in the original DDF… …there is not such a part in this DDF. What I can see which looks interesting is this part: { "name": "config/battery", "awake": true, "parse": { "at": "0x00f7", "ep": 1, "fn": "xiaomi:special", "idx": "0x01", "script": "xiaomi_battery.js" } So this seems to be “outsourced” to the xiaomi_battery.js script: As I don’t want to change the…

[Smanar]

Yeah but for battery it’s easier, a 0 value is not possible so we can just ignore them, but the consumption can be 0, if you don’t use it. So IDK how to guess if the 0 value is “normal” or a device issue.

[bcutter]

As mentioned, I want to give it a try and see if this has any unwanted effects on regular usage of the device. How would the DDF need to look like? @Smanar

And what about 1 and 2…

@bcutter

1. Any new progress on this?
2. Or any other ideas?

…because it’s been 21 months now

[Smanar]

There is more reliables plugs.

[bcutter]

1. Yes there are. Could you please name a few? ZigBee with power metering, affordable.
   Back than I could not find a single one (without the need to flash it with some Tuya stuff).
   And: You want to buy 4 _TZ3000_amdymr7l’s? I can give you a good price my friend. Just kidding.
2. For sure it’s a shitty device firmware (confirmed to also affect

• ZHA users @ Sensors drop to zero with Zigbee plug Blitzwolf SHP-13 TS011F _TZ3000_amdymr7l · Issue #78155 · home-assistant/core · GitHub and
• ZigBee2MQTT users @ Tuya TS011F_plug_1 control via MQTT | Zigbee2MQTT,
  so no deCONZ blaiming here) - but I at least wanted to give it a try and just filter the 0 values, probably something deCONZ can do instead of ZHA and ZigBee2MQTT, so let’s give use that rare advantage and give it a try!

3. So you don’t want or can help? This seems to be the first time. Interesting.

[Smanar]

Tuya is realy random stuff, you can found users with problem and other without with same device, tuya is cheaper, and some stuff are realy good, but realy random, even if you buy all your devices in same time on the same brands.
I can help, …, if you have an idea how to ! I can make a special DDF but how to reconize bad zero values ? There is no logic, how reconize a “normal” zero value from one from the bugged firwmare. I can make a filter, but need to found a “rule”, if you have an idea ? I m sorry but nothing on my side.

[bcutter]

As mentioned at Blitzwolf BW-SHP13 (_TZ3000_amdymr7l) reports ZERO current consumption regularly - #5 by bcutter yesterday, I want to just filter ANY 0 (zero) values (see below)! Just to see what happens. I’m totally aware of the almost impossibility to recognize the “bad” ones… except, well, one idea.

1. First I need a DDF which simply ignores all 0 values.
2. Second - if possible - can we have some kind of “time” dimension in a DDF? Because looking at all the incidents, the “false” 0 values are only for 1 to 3, usually just exactly 2 seconds. So that’s a pattern to work with: if we could block/skip/ignore 0 values for let’s say 3 seconds, it should be completely safe to ignore these.

• full incident example
  
• start:
• end:

@bcutter

How (content of DDF) would I ignore/suppress the values of 0 (zero) for current consumption so they are not reported at all? I’d at least give that a try just to see what it would look like in Home Assistant in the end and if it has any (not acceptable) side effects. I’d need a custom DDF based on the default one with a) just for the _TZ3000_amdymr7l and with the "name": "state/consumption", section modified in a way it ignores value of 0 (zero).

[Smanar]

@bcutter

I want to just filter ANY 0 (zero) values

Can use that code

        {
          "name": "state/power",
          "read": {
            "at": "0x050b",
            "cl": "0x0b04",
            "ep": 1,
            "fn": "zcl:attr"
          },
          "parse": {
            "at": "0x050b",
            "cl": "0x0b04",
            "ep": 1,
            "eval": "if (Attr.val>0){Item.val = Attr.val;}"
          },
          "refresh.interval": 365
        },

It’s not consumption but power, and it will not work, if you have for exemple a power of 100W then turn of the device, you will stay with the 100W power all the time the device will be turned of.

Just a remark, on the DDF the refresh interval need to be > at the value used in bind/report. I don’t think it will change something, but i’s just better.

You never have two “0” values succesively ? if yes instead using a JS request, can use a script request, and a field state/consumption_2 (to store the previous value) and this kind of script.

if (Attr.val == 0)
{
    if (R.item("state/consumption_2") == 0)
    {
        R.item("state/consumption_2") = R.item("state/consumption")
        Item.val = Attr.val;
    }
    else
    {
        R.item("state/consumption_2") = Attr.val;
        Item.val = R.item("state/consumption_2");
    }
}
else
{
    R.item("state/consumption_2") = R.item("state/consumption")
    Item.val = Attr.val;
}

If the value is not 0, no change
If the value is 0 and the previous one 0, no change
If the value is 0 and the previous one not 0, ignore it.

[Swoop]

Reading this one here with interest. What I would like to understand is: why are the disliked values not filtered out in the home automation software? I mean, it is easy to steer what’s written to database and subsequently subject to visualization. In my personal view, that way you have all the flexibility and freedom you could possibly want.

Maybe this thought contributes to your 2nd question previously mentioned about having alternative ideas. As you mentioned above, it’s been 21 months, so maybe another reason to consider?

[bcutter]

I replaced the shitty BW-SHP13 (_TZ3000_amdymr7l) by SilverCrest HG08673 (_TZ3000_j1v25l17, Lidl SilverCrest Smart Plug EU HG08673-EU Zigbee compatibility).

I’ll probably keep the BW-SHP13 for use as simple on/off plugs and disable power metering related entities in Home Assistant. Not sure if it’s possible to “disable power metering” abilities of the device directly in deCONZ which would be the best option.

Thank you for your input.