[Device Support Request] BlitzWolf BW-SHP13 smart plug (aka Tuya TS0121)

[mallorca2288]

Is your feature request related to a problem? Please describe. BlitzWolf BW-SHP13 smart plug 16A EU version, same device as TuYa TS0121 smart plug.

Device joins zigbee network and it's recognized by home-assistant.

Entities are created for:

• On/Off switch: It works
• Electrical power measurement (W): Values updated correctly.
• Energy metering (kWh): Entity is created but values are never updated.

This entities are missing:

• Current (A).
• Voltage (V).

Describe the solution you'd like Please consider adding support for the missing values and fixing the electrical power measurement value.

Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.

{
  "node_descriptor": "NodeDescriptor(byte1=1, byte2=64, mac_capability_flags=142, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=0)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0051",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0702",
        "0x0b04"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZ3000_3ooaz3ng",
  "model": "TS0121",
  "class": "zigpy.device.Device"
}

Additional context This device doesn't support reporting of electrical measurement values, so it needs to be polled. It's supported on zigbee2mqtt, they fixed this by polling the values every 10 seconds.

Voltage value is correctly reported if I manually get the attribute value:

[CharlieBailly]

Hi, yes it would be great if it was fully supported as you describ it. I also have the same device, but with a slightly different signature : (the manufacturer part differ)

 {
  "node_descriptor": "NodeDescriptor(byte1=1, byte2=64, mac_capability_flags=142, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=0)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0051",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0702",
        "0x0b04"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZ3000_g5xawfcq",
  "model": "TS0121",
  "class": "zigpy.device.Device"
}

[TheJulianJES]

Z2M polls them every 60 seconds: https://github.com/Koenkk/zigbee-herdsman-converters/blob/c9ed6bb75a9682cf60b41e4e7647c653480f9a6c/devices.js#L1490-L1503 because they don't support attribute reports apparently (or at least don't do it properly). It doesn't look like that zha-quirks has something similar yet. So I'm not sure how something like this would even be implemented correctly.

[dmulcahey]

ZHA already polls the electrical measurement cluster. Is this not an EM cluster?

[TheJulianJES]

It should be. Perhaps it's missing these constant attributes (https://github.com/Koenkk/zigbee-herdsman-converters/blob/c9ed6bb75a9682cf60b41e4e7647c653480f9a6c/devices.js#L1479-L1483) (or the binding above that)? (Just guessing at this point though). The Xiaomi quirk does something similar: https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/xiaomi/__init__.py#L410-L415 (Although the Xiaomi Smart Plug (EU) with power reporting also worked before doing that for me)

[TheJulianJES]

I just re-read the issue. It looks like the electrical power measurement (W) is working correctly, right? Only voltage and current do not have entities created for them. The total "smart" (?) energy meter isn't updated. That looks like the same "issue" basically all power measuring plugs have (at least the Xiaomi Plugs) (?)

[dmulcahey]

Yes, if that’s the case. We currently only support 1 sensor per cluster. This is currently a limitation in ZHA.

[TheJulianJES]

Got my Blitzwolf plugs today. They seem to work well so far. (On/off + current consumption). With Z2M you can also set the initial power on state: https://www.zigbee2mqtt.io/devices/TS0121_plug.html#power_outage_memory-enum I guess that's something ZHA could also implement. Since that shouldn't be hard, I'll see if I get around to it in the next couple of days.

Edit: This would be addressed by https://github.com/zigpy/zha-device-handlers/pull/742 For all other issues (voltage, current not displaying), ZHA would need to be "changed".

[Hedda]

Yes, if that’s the case. We currently only support 1 sensor per cluster. This is currently a limitation in ZHA.

Any plans to extend ZHA to support more than one sensor per cluster?

BlitzWolf BW-SHP13 smart plug 16A EU version, same device as TuYa TS0121 smart plug.

Device joins zigbee network and it's recognized by home-assistant.

Entities are created for:

• On/Off switch: It works
• Electrical power measurement (W): Values updated correctly.
• Energy metering (kWh): Entity is created but values are never updated.

This entities are missing:

• Current (A).
• Voltage (V).

Hope to see full support for these Tuya smart plugs as there are few inexpensive Zigbee plugs featuring power/energy-metering.

Lonsonho also has Tuya model TS0121 branded variant which also features support. for power-metering and energy-metering:

https://zigbee.blakadder.com/Lonsonho_TS0121.html

https://www.aliexpress.com/item/4001118546894.html

Really like that and BlitzWolf BW-SHP13 because power/energy-metering and fact that they are both inexpensive and very small.

Here are some pictures of Lonsonho TS0121 version:

[Hedda]

And this one from "Rehentele" looks to be yet another Tuya TS0121 variant with power-metering and energy-metering support:

https://www.aliexpress.com/item/4000449939329.html

Note that Rehentele seem to sell a TS0121 version with power-metering as well as a TS0111 version without that looks the same.

[vpomax]

It shows consumption in kWh (energy metering) as "unknow"... any solution about?

[sakara]

Please, add the missing entities so i can move from z2m to ZHA.

[McLP11]

same request from my side, this plug is perfect as size and power capability, so having the chance to see the consumption in ZHA will be the perfect match. I really hope this feature can be implemented, thanks.

[Gamester17]

That looks like the same "issue" basically all power measuring plugs have (at least the Xiaomi Plugs) (?)

For all other issues (voltage, current not displaying), ZHA would need to be "changed".

What exactly needs to be "changed" in the ZHA integration to overcome the limit of 1 sensor per cluster?

How many sensors per cluster does other Zigbee implementations like example Zigbee2MQTT support?

[manouallou]

It would be nice to know if there is a roadmap for this "fix" (more than 1 sensor per cluster) or else we should make a decision to steer away from Zigbee power plugs.

[rklomp]

+1. Bought a Tuya TS0121 from aliexpress to measure consumption of different devices.

On/Off switch works and Electrical power measurement (W) updated correctly.

I can retrieve the total usage from the device in the Metering cluster (0x0702) using the current_summ_delivered attribute ( 0x0000), but unfortunately there is no sensor for this.

manufacturer: _TZ3000_rdtixbnu model: TS0121

[flabbamann]

I did some research with my BW-SHP13 in Home Assistant via ZHA:

The current_summ_delivered attribute @rklomp mentioned gets written to zigbee.db. You could use a sql sensor to read the value from there.

You have to multiply that value by 10 to get Wh or by 0.01 to get kWh.

- platform: sql
  db_url: sqlite:////config/zigbee.db
  scan_interval: 30
  queries:
  - name: plug_metering
    query: "SELECT value * 0.01 as value FROM attributes WHERE ieee = 'YOUR_DEVICEID' AND cluster = 1794 AND attrid = 0"
    column: "value" 
    unit_of_measurement: kWh

So, the data is there. What needs to be done to show that via the device sensor?

Sidenote: I cross checked my Blitzwolf with an old dumb metering plug a have and the Blitzwolf always shows about 50% higher values. The Blitzwolf shows 120W while my other plug shows 80W (power measurement). So in that case I would multiply by 0.0066 instead of 0.01 to get a more accurate value, but I'm unsure which device I should trust more. In the end both are very cheap and no high-precision metering devices 😉 . If I take that into account both devices metering (kWh) values match.

[Hedda]

I just re-read the issue. It looks like the electrical power measurement (W) is working correctly, right? Only voltage and current do not have entities created for them. The total "smart" (?) energy meter isn't updated. That looks like the same "issue" basically all power measuring plugs have (at least the Xiaomi Plugs) (?)

Yes, if that’s the case. We currently only support 1 sensor per cluster. This is currently a limitation in ZHA.

FYI, there is a developers/development discussion about this "issue" in this related PR by @stattin42 -> https://github.com/home-assistant/core/pull/50471

There are also two problem discussion about the root cause in HA, see https://github.com/home-assistant/core/issues/44539 and https://github.com/home-assistant/core/issues/34090

Users tested/confirmed issue on BlitzWolf BW-SHP13, Innr SP 120 / SP120, Schwaiger ZHS15, Lonsonho 16A Energy Monitoring Plug

[juhanjuku]

I did some research with my BW-SHP13 in Home Assistant via ZHA:

The current_summ_delivered attribute @rklomp mentioned gets written to zigbee.db. You could use a sql sensor to read the value from there.

You have to multiply that value by 10 to get Wh or by 0.01 to get kWh.

- platform: sql
  db_url: sqlite:////config/zigbee.db
  scan_interval: 30
  queries:
  - name: plug_metering
    query: "SELECT value * 0.01 as value FROM attributes WHERE ieee = 'YOUR_DEVICEID' AND cluster = 1794 AND attrid = 0"
    column: "value" 
    unit_of_measurement: kWh

So, the data is there. What needs to be done to show that via the device sensor?

Sidenote: I cross checked my Blitzwolf with an old dumb metering plug a have and the Blitzwolf always shows about 50% higher values. The Blitzwolf shows 120W while my other plug shows 80W (power measurement). So in that case I would multiply by 0.0066 instead of 0.01 to get a more accurate value, but I'm unsure which device I should trust more. In the end both are very cheap and no high-precision metering devices 😉 . If I take that into account both devices metering (kWh) values match.

You are correct, current_summ_delivered in in zigbee db, BUT it updates there very rarely ( once per day) I have several different plugs and only one plug, BlitzWolf TS0121, updates correctly, every minute.

SQL query may be used if we could somehow force db value update.

[stattin42]

While sql sensors or events for attribute changes could be a way to handle multiple attributes per cluster, I am still struggling a little with the rationale behind selecting an optional attribute as the base entity/sensor for a cluster or channel. Wouldn't it be more useful to use a mandatory attribute for the sensor?

Now that things are what they are, I have some sympathy for not breaking things by changing existing behaviour. I cannot help thinking, though, that there is a sense of urgency finding a solution. Hopefully a solution which does not require templating for commonly used mandatory attributes. Support is currently broken for many compliant devices unless they support a certain optional attribute.

[flonair]

You are correct, current_summ_delivered in in zigbee db, BUT it updates there very rarely ( once per day) I have several different plugs and only one plug, BlitzWolf TS0121, updates correctly, every minute.

Same for me. Two plugs update regular, but four other plugs update only sporadically (sometimes after 5 minutes, sometimes after 30 minutes).

[pipiche38]

my understanding is that then current_summ_delivered is sent by the device when it reach a certain level of current delivered. So I would suggest to put something consuming more current to see if you see the update arriving more often.

[flonair]

my understanding is that then current_summ_delivered is sent by the device when it reach a certain level of current delivered. So I would suggest to put something consuming more current to see if you see the update arriving more often.

For current_summ I think this makes sense. But I also have the update problem with current_power. And there something like that would be absolutely pointless. For example, I want to be notified when the washing machine is ready and not 30 or even 60 minutes later.

[pipiche38]

For instant power, my understanding is that there is no reporting for as the Blitzwolf TS0121 are concerned, and you must poll the information by doing a read attribute as per the time cycle you want

[juhanjuku]

For instant power, my understanding is that there is no reporting for as the Blitzwolf TS0121 are concerned, and you must poll the information by doing a read attribute as per the time cycle you want

How do you read attribute with code? I can do this only from Manage Clusters dialog manually.

[flonair]

For instant power, my understanding is that there is no reporting for as the Blitzwolf TS0121 are concerned, and you must poll the information by doing a read attribute as per the time cycle you want

Maybe, but actually ZHA/Z2M polls independently. Otherwise no values would arrive, because I have not set this anywhere. Or am I misunderstanding this? If I use the node "poll state" in nodered, then I get only the state that HA knows. That means: if the plug polls 100W and then 30 minutes no more (although the consumer is off), then the node polls always the 100W.

So I would have to set a poll interval directly in ZHA or what do you mean?

[pipiche38]

I'm sorry but I don't know how zigpy and zha works. But the way we are doing on other plugins not zigpy related) is to poll every 30s or every 60s , so you can catch if there is something consuming power or not. Then as mentioned for the current_summation this is a based on some trigger on the device itself.

Blitzwolf is a Tuya based device, and you get what you pay for. If you want a full working plug with instant and summation you can go for Salus SP600 which works very well, with reporting and they are also other brands like Legrand, but the price is somehow more expensive :-(

[KentuckyMC]

Hey all, since the new energy dashboard, is this also the topic to see the opportunities to integrate this plug inside that? I'm now trying to do something with a template sensor to get things inside the energy dashboard.

[Gamester17]

Hey all, since the new energy dashboard, is this also the topic to see the opportunities to integrate this plug inside that?

With Home Assistant's devs current focus on energy management, I too have questions regarding HA's new energy dashboard, etc..

Do you think that if and when ZHA has enabled support for multiple sensors per zigbee cluster, could power metering features via ZHA be achieved by supporting the new energy device class in consumption sensor, as in similar to what deCONZ implemented in https://github.com/home-assistant/core/pull/53731 and https://github.com/home-assistant/core/pull/53866 ?

That is assuming wanted ZHA features are related to new energy management that is now being added to Home Assistant? As per:

https://www.home-assistant.io/blog/2021/08/04/home-energy-management/

https://www.home-assistant.io/blog/2021/08/04/release-20218/#home-energy-management

https://www.home-assistant.io/blog/2021/08/04/release-20218/#long-term-statistics

https://www.youtube.com/watch?v=VLiqDkam33k&ab_channel=HomeAssistant

[Gamester17]

Maybe this could utilize the new sensor state class "total_increasing" after long term statistics has been unlocked for all sensors?

https://www.home-assistant.io/blog/2021/09/01/release-20219/#long-term-statistics-unlocked-for-all-sensors

2021.9.0 news mentions checking out Home Assistant's developer blog regarding the new sensor state class: total_increasing

https://developers.home-assistant.io/blog/2021/08/16/state_class_total/

That is mentioned in the Home Assistant 2021.9.0 Beta release notes under "Home Energy Management updates"

https://www.home-assistant.io/blog/2021/09/01/release-20219/#added-support-for-many-more-integrations

https://www.home-assistant.io/blog/2021/09/01/release-20219/#home-energy-management-updates

https://www.home-assistant.io/blog/2021/09/01/release-20219/#view-energy-usage-over-a-period-of-time

[Hedda]

FYI, it looks like support for more Zigbee clusters attributes is now being worked on for ZHA integration in Home Assistant core, see:

https://github.com/home-assistant/core/pull/56909

and

https://github.com/home-assistant/core/pull/56666

So maybe now you could try to get this working with the latest Home Assistant beta or wait for the next upcoming release:

https://www.home-assistant.io/faq/release/

[MattWestb]

For all users of TS0121 device is ZHA adding the device to summation_delivered channel but no TS0121 user have testing is it working with there devices.

One user have doing it with TS011F and the device is sending values with wrong multiplier and hi is fixing it on the device quirk that is ready for merging in the dev.

If like getting the TS0121 working OK its need testing and feedback from the user for getting it working OK and perhaps updating the quirk for the devices.

[Hedda]

Also note the last comment from Adminiuga in https://github.com/home-assistant/core/pull/56909

"Support for other attributes could be extended later, as I couldn't find too many devices other than Sinopé RM3250ZB Electrical Load Controller – 50A – Zigbee https://www.amazon.com/dp/B07CGJ6XH2/ reporting anything interesting on the electrical measurement cluster."

[flabbamann]

For all users of TS0121 device is ZHA adding the device to summation_delivered channel but no TS0121 user have testing is it working with there devices.

One user have doing it with TS011F and the device is sending values with wrong multiplier and hi is fixing it on the device quirk that is ready for merging in the dev.

If like getting the TS0121 working OK its need testing and feedback from the user for getting it working OK and perhaps updating the quirk for the devices.

Hi @MattWestb as expected the multiplier and divisor for TS0121 are wrong. I opened #1062 to fix that. It's working with my Blitzwolf BW-SHP13, but maybe someone else can confirm with their devices?

[MattWestb]

I dont have the device but other users may having it and can testing if its working OK.

And typical tuya they have not doing the same fault as in the TS011F for making it easy and making one more version of the "undocumented future" (= bug).

Great work done !!

PS: I have renaming the quirk and making only using the MODEL so not need adding all versions of the device and its one more PR waiting for being merged with moving the power on state to tuya quirk INI then more device need the same function in the future (TS011F shall using it then its being merged).

[Celer21]

Hi, I have 4 of BW-SHP13 and after new HA version, they get new sensor and it shows data. But it show kWH unit, but it number is actually in Wh.

[Hedda]

I have 4 of BW-SHP13 and after new HA version, they get new sensor and it shows data. But it show kWH unit, but it number is actually in Wh.

OK so as 1 kWh == 1 Wh ZHA will need to have a quirk which fix multiplier and divisor for that model too that multiply by 10 and divide by 1000 in order to get correct current_summ_delivered values reported to ZHA in Home Assistant? See this PR -> https://github.com/zigpy/zha-device-handlers/pull/1062

[flabbamann]

Hi, I have 4 of BW-SHP13 and after new HA version, they get new sensor and it shows data. But it show kWH unit, but it number is actually in Wh.

Are you sure the value is Wh and not "10Wh"? On my devices it's "10Wh" so we must divide by 100 and not by 1000. Can you confirm that?

[Celer21]

Hi, I have 4 of BW-SHP13 and after new HA version, they get new sensor and it shows data. But it show kWH unit, but it number is actually in Wh.

Are you sure the value is Wh and not "10Wh"? On my devices it's "10Wh" so we must divide by 100 and not by 1000. Can you confirm that?

Hi, maybee it is in 10Wh. I am only shure, it is not in kWh. Because it is connectect to whashing mashine and showing 16 323,0 kWh. And that is too much after 1/2 year of using it...

[juhanjuku]

I have plugs from Schwaiger, Innr SP 120, BlitzWolf, Lonsonho and Salus. Now they all show smartenergy_metering_summation_delivered, but values are not updating in Lovelace. electrical measurement utdates frequently but summation_delivery shows reading after restart. Only Lonsonho plug updates also summation_delivery. I have made restarts, nothing helps.

.

[MattWestb]

I think (= not knowing) that the summation_delivery is only updated ones in the hour or 2. Let all plugs running some hours with power load and looking if you have getting historical measurements from them.

Edit: Sorry i was not seen that you have last reported for 16 hours so my statement is false :-((

[stattin42]

I have plugs from Schwaiger, Innr SP 120, BlitzWolf, Lonsonho and Salus. Now they all show smartenergy_metering_summation_delivered, but values are not updating in Lovelace. electrical measurement utdates frequently but summation_delivery shows reading after restart. Only Lonsonho plug updates also summation_delivery. I have made restarts, nothing helps.

Odd. I have Innr SP 120 and Develco SPLZB-131 devices and they all update. I need divisor/multiplier quirk for the Innr SP 120 though.

Just one thought, don't know if it is related to the problem you are seeing, but I note that in the log I get warnings seemingly related to configuration of reporting: WARNING (MainThread) [homeassistant.components.zha.core.channels.base] [0x1201:1:0x0702]: 'async_configure' stage failed: 'ConfigureReportingResponse' object has no attribute 'status' Could it be a reporting configuration issue?

[stattin42]

Drilling a bit deeper into the WARNING above, it appears that in configure_reporting_multiple in zigpy/zcl/__init__.py it is expected that the return value from _configure_reporting_multiple may be a list.

However, in the case of the WARNINGs I see, _configure_reporting_multiple returns a one element nested list with [[ConfigureReportingResponseRecord(status=0)]] which does not go very well with the condition:

if (
            isinstance(res, list)
            and not (res[0].status == foundation.Status.SUCCESS and len(res) == 1)
            and len(res) >= 0
        ):

@Adminiuga, is this an issue only with certain devices or a general issue? Should a separate issue be opened for this?

[Adminiuga]

Can you enable debug logging and post the raw payload received by the radio. Zigpy should handle a single element list instance

[stattin42]

@Adminiuga, there appears to be a couple of different (potential) issues here ...

1) configure_reporting_multiple returns a list of lists of ConfigureReportingResponseRecord, but the test in the caller expects only a simple list of ConfigureReportingResponseRecord (see above). This seems to be happen the same for Innr SP 120, Datek PoP and Develco SPLZB-131.

2) ZHA tries to configure reporting for attributes InstantaneousDemand, CurrentSummationDelivered and Status whether or not the device supports it. E.g., Innr SP 120 does not support the (optional) attribute InstantaneousDemand which seems to result in that other reporting configurations included in the same reporting configuration command get messed up. It may be because the device fails to parse the reporting configuration for unsupported attributes. Maybe because the device does not understand the configuration (e.g., data type) for an unsupported attribute and gets the length of the configuration wrong?

For instance, zha tries to configure attribute reporting for InstantaneousDemand (0x0400), CurrentSummationDelievered (0x0000) and Status (0x0200) as follows:

2021-10-11 13:40:34 DEBUG (MainThread) [zigpy_deconz.uart] Send: 0x1292003a0033007a0002011201040102070124000079060000042a05008403010000000000251e00840301000000000000000218010084030200 The device, in this case an Innr SP 120, responds: 2021-10-11 13:40:34 DEBUG (MainThread) [zigpy_deconz.uart] Frame received: 0x1796002d002600260200000102011201040102070f0018790786000004860084038d00000000afffRRRRRRRRd0 indicating status 0x86 (UNSUPPORTED_ATTRIBUTE) for attribute 0x0400 (InstantaneousDemand) 0x86 (UNSUPPORTED_ATTRIBUTE) for attribute 0x0384 (???) 0x8d (INVALID_DATA_TYPE) for attribute 0x0000 (CurrentSummationDelivered)

Attribute 0x0384 was never configured (don't know if such an attribute even exists), but 0x0384 (900) was the value for max reporting interval for all attributes in the configuration command. Also the data type is misunderstood for CurrentSummationDelievered.

If the configuration for InstantaneousDemand is put last in the configuration command, attribute numbers and the data type for CurrentSummationDelivered seem to be correctly understood by the device. --> Should probably not try to configure reporting for unsupported attributes. At least not combine with reporting configurations for other attributes in same reporting configuration command. The device may not understand the data type indicated for an unsupported device.

As a side note, the Innr SP 120 seems to support the Status attribute, but not periodic reporting of it. The device responds with status 0x8c that periodic reports cannot be issued for this attribute. This condition however seems to be handled gracefully, unlike the issue with the unsupported attribute InstantaneousDemand. Presumably the device knows the data type of the Status attribute and can parse the remaining configuration command.

EDIT: Masked the values of some reserved octets in the raw payload received from the deconz firmware (RRRRRR above).

[Adminiuga]

Do you have same log, but as instead of zigpy_deconz.uart include logging for zigpy_deconz.zigbee.application and zigpy_deconz.api

[stattin42]

Do you have same log, but as instead of zigpy_deconz.uart include logging for zigpy_deconz.zigbee.application and zigpy_deconz.api

Had to re-join the device so nwk address is different, but same device (and same behaviour) as above.

Configure Reporting: 2021-10-12 10:01:30 DEBUG (MainThread) [zigpy_deconz.api] Command Command.aps_data_request (51, 48, 0, <DeconzAddressEndpoint address_mode=2 address=0xECDF endpoint=1>, 260, 1794, 1, b'\x00/\x06\x00\x00\x04*\x05\x00\x84\x03\x01\x00\x00\x00\x00\x00%\x1e\x00\x84\x03\x01\x00\x00\x00\x00\x00\x00\x00\x02\x18\x01\x00\x84\x03', 2, 0)

2021-10-12 10:01:30 DEBUG (MainThread) [zigpy_deconz.uart] Send: 0x125c003a003300300002dfec0104010207012400002f060000042a05008403010000000000251e00840301000000000000000218010084030200

2021-10-12 10:01:30 DEBUG (MainThread) [zigpy_deconz.uart] Frame received: 0x125c00090002002a30

2021-10-12 10:01:30 DEBUG (MainThread) [zigpy_deconz.api] APS data request response: [2, <DeviceState.APSDE_DATA_REQUEST_SLOTS_AVAILABLE|APSDE_DATA_INDICATION|2: 42>, 48]

Configure Reporting Response: 2021-10-12 10:01:30 DEBUG (MainThread) [zigpy_deconz.uart] Frame received: 0x175e0035002e00260200000104dfecYYYYYYYYYYYYYYYY01040102070f00182f0786000004860084038d00000000afffRRRRRRRRdd

2021-10-12 10:01:30 DEBUG (MainThread) [zigpy_deconz.api] APS data indication response: [46, <DeviceState.APSDE_DATA_REQUEST_SLOTS_AVAILABLE|APSDE_DATA_CONFIRM|2: 38>, <DeconzAddress address_mode=ADDRESS_MODE.NWK address=0x0000>, 1, <DeconzAddress address_mode=ADDRESS_MODE.NWK_AND_IEEE address=0xecdf>, 1, 260, 1794, b'\x18/\x07\x86\x00\x00\x04\x86\x00\x84\x03\x8d\x00\x00\x00', 0, 175, 255, 166, 0, 1, 2, -35]

2021-10-12 10:01:30 DEBUG (MainThread) [zigpy.zcl] [0xecdf:1:0x0702] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=47 command_id=Command.Configure_Reporting_rsp>

2021-10-12 10:01:30 DEBUG (MainThread) [zigpy_deconz.api] 'aps_data_indication' response from <DeconzAddress address_mode=ADDRESS_MODE.NWK_AND_IEEE address=0xecdf>, ep: 1, profile: 0x0104, cluster_id: 0x0702, data: b'182f0786000004860084038d000000'

[stattin42]

Created new ZHA issue for 2) here: home-assistant/core#58339

[stattin42]

Really don't understand why https://github.com/home-assistant/core/issues/58339 was closed with comment:

... other devices support these attributes. Works as designed.

Clearly it has been reported numerous times that the attribute InstantaneousDemand is not supported by several devices. This attribute is optional according to the standard so should be allowed to not support.

[Adminiuga]

It's not supported and it's fine. Asking to not configure it is dumb, and was explained why.

[stattin42]

It's not supported and it's fine. Asking to not configure it is dumb, and was explained why.

The issue seems not so much about trying to configure unsupported attribute, but error handling and side effects of such attempts. If attempt to configure reporting for unsupported attribute has side effects, some handling may be needed. Not trying to configure unsupported attribute is one solution. There are perhaps better ones, e.g., retrying configuration of reporting for supported attributes. Or issue separate reporting configuration commands for attributes for which support is unknown. Or reorder attribute reporting configuration records with records for mandatory attributes before optional attributes (not bullet proof for optional attributes, but better than failing for mandatory attributes). Any working solution is fine, but currently this issue does not seem to be handled gracefully.

Also I would really appreciate a more constructive discussion than calling names.