[BUG] Smart plug metering information only updated on HA restart

[lpwevers]

Describe the bug I got some Aubess EU power plugs with the capability of measuring electricity usage. They all work fine, except for one thing. Information for the sensor “smartenergy_metering_summation_delivered” is only updated on every restart of HA. All other sensors electrical_measurement, electrical_measurement_rms_voltage and electrical_measurement_rms_current are updated in real time as expected.

To Reproduce Add the device in HA and have a device plugged in to this socket use some energy. The sensor will not update. Restart HA and wait a couple of minutes then then the sensor does update once, until the next restart of HA

Expected behavior I expect the sensor to update in (near) real-time

Additional context Zigbee device signature:

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x010a",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0702",
        "0x0b04",
        "0xe000",
        "0xe001"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZ3000_gjnozsaz",
  "model": "TS011F",
  "class": "zhaquirks.tuya.ts011f_plug.Plug"
}

[JoryHogeveen]

Note to dev: This is a different device that the more common _TZ3000_typdpbpg devices which do works as expected and are also sold by Aubess. Other device signatures: https://zigbee.blakadder.com/Tuya_TS011F.html

[kokobadu]

Just came across exactly the same issue with more common _TZ3000_u5u4cakc from BlitzWolf BW-SHP15. https://zigbee.blakadder.com/BlitzWolf_BW-SHP15.html “smartenergy_metering_summation_delivered” is only updated after restart of HA.

[PonyOny]

I'm facing a similar issue #1370

[AlexMarent]

Hi, have the same issue with _TZ3000_gjnozsaz and _TZ3000_u5u4cakc! After a restart, all values are updated as intended.

[kokobadu]

My _TZ3000_u5u4cakc from BlitzWolf BW-SHP15 update “smartenergy_metering_summation_delivered” on comming back from unavailable. With other words switching it off and back on helps with updating just as restarting HA.

Just came across exactly the same issue with more common _TZ3000_u5u4cakc from BlitzWolf BW-SHP15. https://zigbee.blakadder.com/BlitzWolf_BW-SHP15.html “smartenergy_metering_summation_delivered” is only updated after restart of HA.

[lpwevers]

I tried restarting the _TZ3000_gjnozsaz plug, but alas. That did not update “smartenergy_metering_summation_delivered”. Only restarting HA seems to do the trick for this one.

[erkr]

Hi, have the same issue with _TZ3000_gjnozsaz and _TZ3000_u5u4cakc! After a restart, all values are updated as intended.

Same here (and _TZ3000_u5u4cakc). But I noticed another issue: When I manually operate the on/off button on the plug, the switch in HA doesn't change state. When operating the corresponding switch in HA, the plug reacts correctly.

[Marouanebouzoubaa]

i have the same issue with this plug _TZ3000_gjnozsaz. does it depend on the firmware installed ? this plug is very compact and nice, and it is becoming very popular, I highly appreciate if this plug can be supported fully by HA. I have bought 8 of them thinking that i can keep track of my energy comsumption for key eletrical devices on my home, but for now, they are useless as i don't need to do any automations on them !

I have another question, is it possible to update the firmware of these plugs directly from HA without the tuya gateway ?

[kokobadu]

Both plugs _TZ3000_gjnozsaz and _TZ3000_u5u4cakc when connected with zigbee2mqtt are reporting as TuYa TS011F_plug_3. Here is the description of the power measurement problem https://www.zigbee2mqtt.io/devices/TS011F_plug_3.html#tuya-ts011f_plug_3 In Z2M it is solved some time ago already.

Problem mentioned by @erkr that I can confirm with ZHA is solved by Z2M as well.

@Marouanebouzoubaa With 8 pieces perhaps it is worth trying Z2M. Plugs work as a charm.

Hopefully someone will tackle the problem within ZHA.

[lpwevers]

I have 5 of them, for exactly the same reasons as @Marouanebouzoubaa. And I was going to buy more if they were supported properly. Switching to Z2M is not an option for me as that meant I'd have to repair / reconfigure everything. And I really don't want to do that.

[Marouanebouzoubaa]

Thank you @kokobadu for your valuable reply ! I spent the Last two days migrating to Z2M, I was hesitating to let down ZHA as for me, ZHA was the future and i was waiting waiting for this issue to be fixed. Let me tell you that i have repaired 50+ devices in Z2M without any issue and it was fun ... i have ikea, philips, xiaomi, tuya, sonoff devices. I like how devices are shown with images in Z2M dashboard. I had also to recreate the automations again and update my existing node-red flows and download new blueprints for the remotes and switchs...

Once all done, i noticed that some power plugs were identified as TS011F_plug_3 and others TS011F_plug_1 .Checked the ota and it suggested to update firmware of the all TS011F_plug_3 plugs. After update all the plugs, they became as TS011F_plug_1. They report correct values regularly.

OTA also updated my philips and ikea devices. I was not aware that i could do this. I ve read you can do OTA with ZHA, but i have not seen this option in my ZHA config.

I also like how zigbe2mqtt allows to configure each device without going to clusters which is not user friendly. For example, i have tuya covers and configuring the travel time was not easy, with z2m, all major configurations for each device are present in the use interface, i discovered interesting parameters for my devices, i found out also that my xiaomi flood sensors have also temperature sensors which were not reported as i remember when using ZHA.

@lpwevers , go ahead with Z2M, it is worth it, i think it is still as of now more mature.

Now that the plugs are working fine and reporting precise values, i will add more of the

Thank you for your help,

[erkr]

Problem mentioned by @erkr that I can confirm with ZHA is solved by Z2M as well.

Thx for confirming, I hope ZHA will follow solving this, not yet ready for moving to Z2M

[kokobadu]

Thank you all for replying. I was far from convincing anyone to step over to z2m. Main goal was of pinpointing the problem: z2m is addressing it as a need of polling the value of “smartenergy_metering_summation_delivered”.

Very interesting is what @Marouanebouzoubaa found: "Checked the ota and it suggested to update firmware of the all TS011F_plug_3 plugs. After update all the plugs, they became as TS011F_plug_1." As far as I read the main difference between plug_1 and plug_3 is the need of polling. It seems that plug_1 is one without need of doing that. It would be good to know if plugs after OTA update behave correctly when reconnected to ZHA. Perhaps it is workaround for our problem? Instead of new quirk, updating firmware and done. To me make no difference as long the plug works properly. Since I don't have the possibility of testing it, perhaps someone else do?

[lpwevers]

Hi,

Ok, I'd love to try it with the firmware upgrade, but I'm afraid I'm unable to do that. ZHA currently does not support this and if you want Tuya to take care of it, you need a Tuya zigbee hub, which I don't have.

Having said that, the frustrating thing is that I found that a fix for this issue actually exists since December 2021: Add support for Polled clusters and use it for ts011f plug Metering

Unfortunately this pull request still isn't merged, so we're stuck with the non working TS011F plugs. (Well for power metering that is). I wouldn't mind manually updateing the zigpy code but I can't seem to find where it resides.

Then again, in this threade someone actually provided a workaround that works for me. This workaround makes use of the "ZHA Toolkit" so you need to install that first. (It's in HACS). Having done that you can create automations to just do the pulling for you. Below is what I have for my 5 plugs:

- id: "1650531854533"
  alias: Lees energieverbruik apparaten
  description: ""
  trigger:
    - platform: time_pattern
      minutes: /1
  condition: []
  action:
    - service: zha_toolkit.attr_read
      data:
        ieee: sensor.pl_computer_smartenergy_metering_summation_delivered
        cluster: 1794
        attribute: 0
    - service: zha_toolkit.attr_read
      data:
        ieee: sensor.pl_magnetron_smartenergy_metering_summation_delivered
        cluster: 1794
        attribute: 0
    - service: zha_toolkit.attr_read
      data:
        ieee: sensor.pl_vaatwasser_smartenergy_metering_summation_delivered
        cluster: 1794
        attribute: 0
    - service: zha_toolkit.attr_read
      data:
        ieee: sensor.pl_wasdroger_smartenergy_metering_summation_delivered
        cluster: 1794
        attribute: 0
    - service: zha_toolkit.attr_read
      data:
        ieee: sensor.pl_wasmachine_smartenergy_metering_summation_delivered
        cluster: 1794
        attribute: 0
  mode: single

Just change the name of your sensors and you're good to go. Also, pulling every minute like I do in this examle may be a bit overkill, so maybe I'll change it to every 5 minutes or so. But for now It doesn't seem to have a negative impact on the network.

[kokobadu]

Thank you for sharing @lpwevers !

I can confirm that it works for me with _TZ3000_gjnozsaz as well. It doesn't for plug _TZ3000_u5u4cakc.

Perhaps it is worth mentioning for followers that after installing "ZHA Toolkit" line with 'zha_toolkit:' has to be added in configuration.yaml, and than restarting Home Assistant.

Bit awkward is that automation as above updates metering_summation_delivered when executed by hand always. When executed automatically by time_pattern every minute updates it only once in 6-7 attempts. I can't find anything worthful in the log about it. But well: it is workaround. Let’s hope it will be implemented in ZHA soon and work properly.

[erkr]

Hi I have several innr SP 120 plugs, the Current power, amp and Voltage reading work fine, but the total power consumption smartenergy_metering_summation_delivered doesn't update for these plugs either.

[lpwevers]

Seems that this is a more general issue with ZHA than just with my "exotic" plugs. @erkr , have you tried the workaround? It might solve your issue for now.

[dmulcahey]

Nope, it’s an issue with manufacturers not following specs. This is fully supported in ZHA. Some manufacturers don’t report changes which requires polling.

[erkr]

@erkr , have you tried the workaround?

I will give it a try 👍 Update: @lpwevers yes this works for my Innr plus 🙏

[kokobadu]

@erkr does it work for your plug _TZ3000_u5u4cakc ? On Apr 7 you wrote that you have issues with this model. It would be strange since by me this workaround work for _TZ3000_gjnozsaz and NOT for _TZ3000_u5u4cakc.

@dmulcahey Isn't the purpose of quirks or zha-device-handlers to adjust to manufacturers that are not following specs? Will any manufacturer report changes? They have their own agenda and basically don't care about ZHA.

[dmulcahey]

They practically all do. I have plugs from sengled, smart things, hell even Aqara ones and they all report just fine. Advice: don’t give your money to Tuya. It’s what allows them to do this 🤷🏻‍♂️

That said, we’ll eventually figure out a solution for this it just isn’t high up on the list atm.

[kokobadu]

They practically all do. I have plugs from sengled, smart things, hell even Aqara ones and they all report just fine. Advice: don’t give your money to Tuya. It’s what allows them to do this 🤷🏻‍♂️

Agree 100%. However it is easier said that done. Depend where you live. Some of the makes are not available in Europe at all. And Tuya is everywhere. It is not that easy to change the market.

That said, we’ll eventually figure out a solution for this it just isn’t high up on the list atm.

Let's hope sooner than later, before the impatient will step over to other systems once for good.

[dmulcahey]

They practically all do. I have plugs from sengled, smart things, hell even Aqara ones and they all report just fine. Advice: don’t give your money to Tuya. It’s what allows them to do this 🤷🏻‍♂️

Agree 100%. However it is easier said that done. Depend where you live. Some of the makes are not available in Europe at all. And Tuya is everywhere. It is not that easy to change the market.

That said, we’ll eventually figure out a solution for this it just isn’t high up on the list atm.

Let's hope sooner than later, before the impatient will step over to other systems once for good.

🤷🏻‍♂️ None of us get paid to do this. We do it because we enjoy it. If folks want to swap systems they are free to do so.

[dmulcahey]

https://github.com/home-assistant/core/pull/71527/files

someone who knows what they are doing can hack their container and try these changes... you will have to replace add-model-names-here with your model number for your device. Someone should work compiling a list of manufacturers / models that need this functionality

[lpwevers]

I'd be happy to try it, but I don't seem to have access to smartenergy.py. At least, I can't find it in the container itself and I don't know how to access the underlying OS. (I run the HAOS from the qcow2 image)

[erkr]

@erkr does it work for your plug _TZ3000_u5u4cakc ? On Apr 7 you wrote that you have issues with this model. It would be strange since by me this workaround work for _TZ3000_gjnozsaz and NOT for _TZ3000_u5u4cakc.

I don't know, I gave that plug to someone running Z2M instead of ZHA

[erkr]

https://github.com/home-assistant/core/pull/71527/files

someone who knows what they are doing can hack their container and try these changes... you will have to replace add-model-names-here with your model number for your device. Someone should work compiling a list of manufacturers / models that need this functionality

I would love to help out but I don't have the knowledge.

[erkr]

Hi With help of the ZHA Toolkit owner I learned that my SP 120 plugs don't require polling once I configure reporting for them. @dmulcahey: my question. Is that something the zhaquirks.innr.innr_sp120_plug.SP120 Quirk for these plugs can take care of?!

Background info of the SP 120 plus, signature and services of ZHA toolkit used:

Zigbee Signature:

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4454, maximum_buffer_size=127, maximum_incoming_transfer_size=80, server_mask=0, maximum_outgoing_transfer_size=80, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 49246,
      "device_type": "0x0010",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0008",
        "0x000a",
        "0x0702",
        "0x0b04"
      ],
      "out_clusters": [
        "0x0003",
        "0x000a",
        "0x0019"
      ]
    },
    "2": {
      "profile_id": 49246,
      "device_type": "0x1000",
      "in_clusters": [
        "0x1000"
      ],
      "out_clusters": []
    }
  },
  "manufacturer": "innr",
  "model": "SP 120",
  "class": "zhaquirks.innr.innr_sp120_plug.SP120"
}

The original polling using a zha toolkit service as proposed by lpwevers:

  - service: zha_toolkit.attr_read
    data:
      ieee: sensor.innr_sp_120_38ea6103_smartenergy_metering_summation_delivered
      cluster: 1794
      attribute: 0
      tries: 3

And the one time (after powering the plug I guess) a report config solution, using the zha-toolkit (working in Core 2022.6.5):

  - service: zha_toolkit.conf_report
    data:
      ieee: sensor.innr_sp_120_38ea6103_smartenergy_metering_summation_delivered
      cluster: 1794
      attribute: 0
      min_interval: 60
      max_interval: 600
      reportable_change: 1
      event_done: zha_done
      tries: 3

@lpwevers: After this configuration, my plugs report themselves without the need to poll them. @dmulcahey : these innr SP 120 plugs don't seem to provide information that reporting can be configured (but if I do they work). This is the output for that cluster when performing a scan device:

                "0x0702": {
                    "cluster_id": "0x0702",
                    "title": "MeteringCluster",
                    "name": "smartenergy_metering",
                    "attributes": {},
                    "commands_received": {},
                    "commands_generated": {}
                },

[lpwevers]

Thanks @erkr for the suggestion. It seems that it doesn't work for my plugs. I still had one that I never used before, so I put it HA and then created this automation:

- id: "1650531854534"
  alias: Init power plugs stroommeting
  description: ""
  trigger:
    - platform: homeassistant
      event: start
  action:
    - service: zha_toolkit.conf_report
      data:
        ieee: sensor.pl_eettafel_pcs_smartenergy_metering_summation_delivered
        cluster: 1794
        attribute: 0
        min_interval: 60
        max_interval: 600
        reportable_change: 1
        event_done: zha_done
        tries: 3

Ran that manually to init the plug, made sure it actually did use some electricity but alas. No go. Just to verify I put it in the polling automation I created earlier and it started working immediately.

So knowing that the plug works, I removed it from the automatic polling and ran the automation again. Waited some time, but no more updates. Looks like this plug is more annoying than yours for this part. I hope that someone finally decides to merge the pull request I mentioned earlier with a fix for this issue.

[erkr]

Pitty it fails for your plug. My innr plugs apparently did support report settings, without defining then as such in the signature.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[lpwevers]

Hmmm, ok, checked again; several updates later. I've disabled my automation for automatically pulling the values from the plugs, and noticed that metering information is still being updated. Guess something must have been fixed in some release along the way. I'm closing this issue.