Zigbee plug *without* power monitoring

Hardware
1

A few days ago my dad and I installed Home Assistant in his house. He got very excited about the whole automation thing. He ordered a Sonoff Zigbee coordinator for his Zigbee shenanigans. We do have a little trouble finding Zigbee plugs without the unnecessary power monitoring.

We’re both using ZHA and from what I understand the power monitoring features can be quite heavy/chatty on the zigbee network. Browsing through Aliexpress almost all of the plugs come with power consumption monitoring, all which is completely unnecessary for just switching a few lamps on and off.

I couldn’t find enough information to see whether the monitoring could be turned off. I have a Silvercrest plug that does not have monitoring, but I am unable to find new ones that do not have such capability either.

Is is possible to disable the power monitoring features on those plugs, or how does it work in ZHA? Will disabling the sensor in Home Assistant be enough to calm down the data on the Zigbee network? Do you know where we can order Zigbee plugs without monitoring?

2

You should be able to just disable the sensor HA side when you don’t need it.

1 Like
3

Does that also mean that the plug will not pollute the zigbee network with unnecessary energy monitoring updates?

4

It should not be sharing out the data if its not being requested, only way is to test and see what results you get for your setup.

5

From my experience, sensors in zigbee devices are push not pull. So the data will be being sent from the power monitoring plug all the time, unless there is a configuration option on the specific power plug to disable the power monitoring.

To the OP’s @DeCodeerHeer concern, the amount of data being sent by zigbee sensors in general is very small compared to the bandwidth available. I have seen reports of some of the new radar based occupancy sensors are sending a lot of data, however I have not tested this personally as yet. However, for devices such as power plugs with monitoring, from my experience you should not be concerned about the amount of data being sent. Again, from my experience with several power monitoring plugs, they send reading a most 1 to 2 times per second, and often much less frequently. Most of my experience is based on Zigbee2MQTT, however when I was using ZHA extensively, I did not see any issues there either.

Good hunting and good success with your home automation adventure in 2024!

1 Like
6

I use a 1200W, i.e. older, version of these with Zigbee2MQTT and a Sonoff Zigbee dongle:
Innr Zigbee Smart Plug, Works with Philips Hue*, Alexa, Hey Google, SmartThings (Hub Required) 16A, Smart Outlet, 1800W Outlet, Plugs 1-Pack, SP 244: Amazon.com: Industrial & Scientific

7

IKEA and Hue plugs do not monitor power usage.

8

The old sonoff S26R2ZBTPG didnt monitor power and were good. Sadly they seem to be discontinued and are proving increasingly hard to find…

9

If you are worried about how chatty devices are, and you are using ZHA, you can use the zha-toolkit to modify the report configuration for attributes.

The best configuration for a device is indeed pushing the values to the coordinator (=reporting the values) while some users will pull values because they do not know/succeed/have confidence in the report configuration or because the attributes they want to monitor can not be configured to report values or because the device is faulty.

The report configuration defines when an attribute will be reported to all of the listeners. So another way to make the device quiet is to disable the listeners for the given cluster.
Listeners are defined using the bind operations. Using zha-toolkit you can get the bindings defined on a cluster.
And you can remove bindings - limited to an endpoint/cluster which you would generally restrict this command to.
When there are no bindings, there are no reports.
I’ld recommend setting up an automation that calls a script that executes these commands on a regular bases (once a week).

That’s because reconfiguring the device from the ZHA device interface would redefine certain bindings on the device which you would need to remove again later. Having a script that configures all of your devices makes it easier to reapply settings and also easier to update settings.

Personnaly, I find that by default the devices are not chatty enough with regards to power measurements, so I increase the reportability of the devices :slight_smile: .

Being able to measure power opens the door to other control possibilities and you might regret not having such devices later on. For instance, I get a notification when the washing machine finished it’s job - that saves me from having my spouse ask me to go and check if the “machine finished” - we now both know when it is through a notification.

Further, measuring consumption can help optimise a configuration, choose the better settings and even monitor if something is going wrong with the device.

2 Likes
10

Wow, I commend your knowledge of these deep inner working of Zigbee and ZHA (I learned some things, thx!) But really? :sunglasses:

11

Thank you all for your response, insights and knowledge.

I find myself falling deeper and deeper into this research to find what is really actually happening between the device, coordinator and zha.

As @somates they discontinued the old chip, and added one with power monitoring. I would believe that whilst designing the new plugs, they wouldn’t have thought of network pollution. Wouldn’t they?

This led me to believe they have built in a way to actually “disable” such features when they are not necessary.

When reading this article https://smarthomescene.com/reviews/tuya-zigbee-16a-smart-plug-review/ I noticed that Tuya has disabled automatic pushing of such measure reports in favor of polling. Which commands I am also able to find within the “manage zigbee device” menu. It so feels like that ZHA is requesting the data from the device, instead of the device pulling it.

Furthermore, I fiddled around with the plugs I have and use which have the new chip. When disabling one of the monitoring entities, the plug seemed to have “restarted” as it became unavailable for a little time, which might indicate it did something to disable the monitoring feature.

But all that is pure speculation. I dove into the zigbee and tuya specification to learn if I could find which method the devices use, but so far I only found a few posts and articles complaining about the firmware update that caused the automatic reporting to stop and the polling to kick in. Which gives me hope.

Just when I was about to post this @le_top replied, and got me investigating a little more. As I already installed ZHA toolkit, I’ve taken a look and was happy with the result, but also incredibly happy with your answer. Thank you for that! Even though it’s a little more work, I am pleased to know that the “just lights plugs” will do their job nice and quiet. And will not force their electrical findings upon the routers and coordinator :rofl:

I’ll give my dad a go with ordering the new types of plugs while I’ll wrap my head around this subject a bit more.

Many thanks all!

12

That’s actually just the surface for me :nerd_face: . I do not know what you mean by “But really”, but I guess my answer is : yes.

Discontinuing the use of a Zigbee communications chip does not imply adding power monitoring which requires extra hardware on top of the Zigbee chip.

The “Manage zigbee device” menu offers the user the opportunity to read and send data and commands to the device - it’s not telling how ZHA works with the device.
However if you reconfigure the device and check the details then you get a table where you can get an idea of the binding and reporting configuration that is being sent (it’s a high level summary, so you can’f find the hard details there).

Requesting the data implies more traffic on the network: there is the extra request packet (and it repeats if needed when it’s not confirmed).

My guess is that it’s a firmware update that simply does not add default reporting configurations while still allowing them. I think that ZHA is configuring reporting anyway, but I did not check that.

Thanks, good to know that ;-).

13

I’ve fiddled around with ZHA toolkit, and disabled the reporting for the available power metrics attributes. I wasn’t able to remove the bindings. Toolkit dropped an “Unknown error” on me. Looking in the logs I saw the following message:

AttributeError: 'ControllerApplication' object has no attribute 'ieee'

Either way. Even though I disabled the reporting (and did not see reporting coming in). Something is still requesting or giving an update, even after I disabled the metric sensors. As shown in the ZHA logs

2024-01-08 02:35:52.733 DEBUG (MainThread) [zigpy.zcl] [0x7258:1:0x0b04] Received ZCL frame: b'\x18\xb2\x07\x00\x00\x08\x05'
2024-01-08 02:35:52.736 DEBUG (MainThread) [zigpy.zcl] [0x7258:1:0x0b04] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True), tsn=178, command_id=7, *direction=<Direction.Client_to_Server: 1>)
2024-01-08 02:35:52.738 DEBUG (MainThread) [zigpy.zcl] [0x7258:1:0x0b04] Decoded ZCL frame: TuyaZBElectricalMeasurement:Configure_Reporting_rsp(status_records=[ConfigureReportingResponseRecord(status=<Status.SUCCESS: 0>)])
2024-01-08 02:35:52.741 DEBUG (Thread-3358) [aiosqlite] executing functools.partial(<built-in method execute of sqlite3.Connection object at 0x7f77929300>, 'UPDATE devices_v12\n                    SET last_seen=:ts\n                    WHERE ieee=:ieee AND :ts - last_seen > :min_update_delta', {'ts': 1704677752.731597, 'ieee': a4:c1:38:5f:ac:e4:7a:4b, 'min_update_delta': 30.0})
2024-01-08 02:35:52.743 DEBUG (Thread-3358) [aiosqlite] operation functools.partial(<built-in method execute of sqlite3.Connection object at 0x7f77929300>, 'UPDATE devices_v12\n                    SET last_seen=:ts\n                    WHERE ieee=:ieee AND :ts - last_seen > :min_update_delta', {'ts': 1704677752.731597, 'ieee': a4:c1:38:5f:ac:e4:7a:4b, 'min_update_delta': 30.0}) completed
2024-01-08 02:35:52.744 DEBUG (Thread-3358) [aiosqlite] executing functools.partial(<built-in method commit of sqlite3.Connection object at 0x7f77929300>)
2024-01-08 02:35:52.744 DEBUG (Thread-3358) [aiosqlite] operation functools.partial(<built-in method commit of sqlite3.Connection object at 0x7f77929300>) completed
2024-01-08 02:35:53.770 DEBUG (MainThread) [zigpy.zcl] [0x7258:1:0x0b04] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True), tsn=179, command_id=<GeneralCommand.Configure_Reporting: 6>, *direction=<Direction.Server_to_Client: 0>)
2024-01-08 02:35:53.770 DEBUG (MainThread) [zigpy.zcl] [0x7258:1:0x0b04] Sending request: Configure_Reporting(config_records=[AttributeReportingConfig(direction=0, attrid=0x050B, datatype=41, min_interval=0, max_interval=65535, reportable_change=0)])

And another

2024-01-08 02:39:36.293 DEBUG (MainThread) [zigpy.zcl] [0xBDFB:1:0x0b04] Received ZCL frame: b'\x08i\n\x05\x05!\xe9\x00\x08\x05!\x00\x00\x0b\x05)\x00\x00'
2024-01-08 02:39:36.295 DEBUG (MainThread) [zigpy.zcl] [0xBDFB:1:0x0b04] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True), tsn=105, command_id=10, *direction=<Direction.Client_to_Server: 1>)
2024-01-08 02:39:36.297 DEBUG (MainThread) [zigpy.zcl] [0xBDFB:1:0x0b04] Decoded ZCL frame: TuyaZBElectricalMeasurement:Report_Attributes(attribute_reports=[Attribute(attrid=0x0505, value=TypeValue(type=uint16_t, value=233)), Attribute(attrid=0x0508, value=TypeValue(type=uint16_t, value=0)), Attribute(attrid=0x050B, value=TypeValue(type=int16s, value=0))])
2024-01-08 02:39:36.298 DEBUG (MainThread) [zigpy.zcl] [0xBDFB:1:0x0b04] Received command 0x0A (TSN 105): Report_Attributes(attribute_reports=[Attribute(attrid=0x0505, value=TypeValue(type=uint16_t, value=233)), Attribute(attrid=0x0508, value=TypeValue(type=uint16_t, value=0)), Attribute(attrid=0x050B, value=TypeValue(type=int16s, value=0))])
2024-01-08 02:39:36.299 DEBUG (MainThread) [zigpy.zcl] [0xBDFB:1:0x0b04] Attribute report received: rms_voltage=233, rms_current=0, active_power=0
2024-01-08 02:39:36.301 DEBUG (MainThread) [zigpy.zcl] [0xBDFB:1:0x0b04] Sending reply header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True), tsn=105, command_id=<GeneralCommand.Default_Response: 11>, *direction=<Direction.Client_to_Server: 1>)
2024-01-08 02:39:36.302 DEBUG (MainThread) [zigpy.zcl] [0xBDFB:1:0x0b04] Sending reply: Default_Response(command_id=10, status=<Status.SUCCESS: 0>)

Which repeats every minute.

If I were able to bash these out, I think I’m on the right track. Didn’t imagine it would be so much work to just disable a feature…

EDIT:
For now I have created a custom quirk whose do not import the measurement cluster. This seems to have disabled the reporting altogether. For the few plugs we do want monitoring to be available on we’ll get another brand, hopefully that will resort to another quirk.

14

the “lite” version of sonoff S31 / S40 do not do power monitoring either.

… but which one (make/model) do you have that reports power monitoring? is yours an US plug?

15

Mine is the TuYa TS011F. EU version. Similar my dad is buying.

16

Hello, any chance you could share that quirk?
Made the mistake of buying far too many of these energy reporting devices before i realized my mistake.
Would be very helpful, in the meantime i will study what you have discussed here in more detail.
Kind Regards

17

I think I have it figured out, but any feedback is welcome/posting this for anyone who like me was tearing their hair out after nuking their zigbee network with one (or twenty) too many of these plugs.

I installed this as a custom quirk: zha-device-handlers/zhaquirks/tuya/ts011f_plug.py at 728ee427263d89a9c9186eacefc90e4994d81b82 · zigpy/zha-device-handlers · GitHub

Then under

class plug_v2(EnchantedDevice):
......
    replacement = {
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Identify.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaZBOnOffAttributeCluster,
                    TuyaZBMeteringClusterWithUnit,
                    TuyaZBElectricalMeasurement,
                    TuyaZBExternalSwitchTypeCluster,

I deleted the following lines:
TuyaZBMeteringClusterWithUnit,
TuyaZBElectricalMeasurement,

That seems to have solved the issue but I will be diving into the logs after work. So far devices are snappy, but there are a few I still need to re-add; and will need to verify the logs are no longer being spammed with energy statistics for um 41 smart plugs all at once

Edit:
That does indeed seem to have done the trick. All my devices are back online and seem to be stable and responsive; the error logs don’t show any zigbee related errors that I could see. Says a lot that a 10 second snippet of debug logging was ~15mb when I had all the energy reporting swamping my network, now it’s more like 1mb.

I also have a lot of thirdreality smart plugs on my net so in places where I needed the energy monitoring from the aliexpress tuya plugs I just swapped the thirdreality and the tuya plugs (there were only 2 so not too big a deal to redo the entities). I’ve never had any slowdowns with the thirdreality plugs and my understanding is that their energy reporting is much more sane (minutes rather than multiple times a second) so in case anyone needs a recommendation that is mine.

For anyone dealing with this issue like me who had zero experience with the more technical aspects of zigbee:

  1. Create a custom quirk as in this guide. Zigbee Guide: How-to add/setup local custom ZHA Device Handlers (also known as ”quirks”) in the ZHA integration
  2. Use the custom quirk file as linked at the top of this post (if doing this for the particular tuya plug in question, otherwise use the corresponding quirk.py file); I ssh’d into the machine with my HA docker container and pasted the contents of the link into nano editor. Give it a memorable/unique name to make the next step easier on yourself.
  3. When you restart HA to get it to load the custom quirk, then go to the device page of the plug in question, on the left under “device info” click the dropdown arrow to the right of “zigbee info” and verify that the “quirk” at the bottom is the custom one you created.
    If it’s not, it may be a mapping issue for the directory you created in 1), or as I found out, I was editing the wrong model in the quirk file I downloaded. I found the right one with a control + f search for my exact model number, or, whatever the default quirk is in the “zigbee info” row of the device page (screenshot below), search for that.
  4. Once you verify that your custom quirk is being detected and used, edit the quirk file as I describe at the top of this post, basically removing the energy monitoring clusters in the “replacement” section.
  5. Reboot HA, pull up an example of that plug, and the energy monitoring entities should all be unavailable or no longer being provided by the integration while the switch still works fine. I then went into ZHA “entities” and used filters to isolate the energy monitoring entities for my switch type and could “select all” and “delete”.

That’s all I can think of that would be helpful in case anyone else comes across this issue.
screen