Howto avoid Timeout errors with attr_read -> 'tries' & 'conf_report' about zha-toolkit

[mdeweerd]

Well, this is likely not an issue with zha-toolkit, but zha-toolkit likely has one or two solutions for it ;-).

IHMO, your smart energy devices are not responding to the requests (or the command is not succesfully through zipy) and because the reply is not coming back there is a timeout.

Two possible solutions:

1. Add a "tries" parameter to the service call. That means that if it does not work the first time it will tries in total as many times as indicated (maximum).
2. Configure your devices to report by themselves every 10 minutes by setting up the Report Configuration and setting the max_interval to 600. If you want at most 1 report every 10 minutes, then set the min_interval to 600 as well. The reportable change allows you to have faster updates if you set the min_interval lower and the reportable change to a value lower than your maximum consumptions.

[erkr]

Your guess is most probably right. Thanks for pointing me out these great two options, I was not aware that the 'tries' option is applicable for the'attr_read' service. That could be a quick fix that I will give a try.
The second option is more intriguing solution to explore (I earlier understood these devices must be polled, as they don't report). New territory for me. Wil try that as well 👍

I will report back if solution 2 works as well. Nice for other users to know.

Thanks
Eric

[mdeweerd]

FYI - you can so a 'scan_device' . If your device has the functionnality, it will report which attributes are reportable.

Example:

                "0x0702": {
                    "cluster_id": "0x0702",
                    "title": "Metering",
                    "name": "smartenergy_metering",
                    "attributes": {
                        "0x0000": {
                            "attribute_id": "0x0000",
                            "attribute_name": "current_summ_delivered",
                            "value_type": [
                                "0x25",
                                "uint48_t",
                                "Analog"
                            ],
                            "access": "REPORT|READ",
                            "access_acl": 5,
                            "attribute_value": 2304
                        },

In Access you can see report, so it is reportable.

Then you can just do (values copied from the attribute characteristics (above)):

service: zha_toolkit.conf_report
data:
  ieee: <ADDRESS_OR_ENTITY_NAME>
  cluster: 0x702
  attribute: 0x0000
  min_interval: 60
  max_interval: 600
  reportable_change: 10
  tries: 3
  event_done: zha_done

As you know your devices are not responding very well, it's best to always add a number of tries. Not all zha_toolkit commands will use that, but quite a few do.

[erkr]

Hi
Thanks for all the help again!
Option 1, with just 3 tries works flawlessly for hours without any errors. So my initial issue is solved :-)
then I tried to figure out Option 2 with your instructions and scanned the device (note: generated many unsupported errors, see below), I retrieved this for the 0702 attribute data:

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

Looks like reporting is not implemented, right?! (or can that be the result of an incomplete quirk?)
Example of the errors:

This error originated from a custom integration.

Logger: custom_components.zha_toolkit.scan_device
Source: custom_components/zha_toolkit/scan_device.py:189
Integration: 🧰 ZHA Toolkit Service (documentation, issues)
First occurred: 23:06:26 (72 occurrences)
Last logged: 23:13:15

got Status.UNSUP_GENERAL_COMMAND status for discover_attribute starting 0x0006/0x0000
got Status.UNSUP_GENERAL_COMMAND status for discover_attribute starting 0x0005/0x0000
got Status.UNSUP_GENERAL_COMMAND status for discover_attribute starting 0x000a/0x0000
got Status.UNSUP_GENERAL_COMMAND status for discover_attribute starting 0x0003/0x0000
got Status.UNSUP_GENERAL_COMMAND status for discover_attribute starting 0x0019/0x0000

I also tried the conf_reporting service. No errors, so I will report back if these settings are effective

Best Eric

[erkr]

Update: although my power plugs don't return their attribute options with the scan, setting the report config had effect, they are now reporting themselves :-)
For my Innr SP120 plugs this works! Thanks for the clear instructions, Eric

[mdeweerd]

Looks like reporting is not implemented, right?! (or can that be the result of an incomplete quirk?)

From the top of my head, the reporting feature for the attribute in question is mandatory according to the zigbee specification.
Not all devices follow specifications, but most should.

Also, there are still quite a few devices not responding to the device_discovery commands, and your device seems to be one of them. It does not hurt to try though because you get some interesting information from that when they do respond.

The scan_device command still tries to get as much information as it can, and you see in the log "Status.UNSUP_GENERAL_COMMAND" which is the reply from the device indicating that it does not support the discovery command.

Happy to see that my suggestions were spot on - you can now stop polling your devices ;-).

If you want to be on the safe side, you could still send the reporting configuration from time to time to your devices - in case they loose this configuration because of a device reset or because they were reinitialized by Home Assistant.
It doesn't hurt to send the reporting configuration once a day or a week, with retries of course.
It's better to use reporting than polling because it reduces traffic on the network, and I think it reduces the communication issues as the device will try to reach out by itself and it does not have to wait for the read command.

[erkr]

Yes I decided for option 2 and implemented this during HA startup. I additionally added this info to a related ZHA device handler issue (zigpy/zha-device-handlers#1404). Maybe the quirk could take care of this as well.
Thanks again!
Eric

[mdeweerd]

Good thing to make a link there.

In principle the reporting configuration is set on initialisation by ZHA (configured at https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/core/channels/smartenergy.py#L59-L67 ) but I guess this is lost over time for startup reasons, etc.

The thing is that the quirk is a lower level than ZHA so it should not be deciding on the reporting frequency which is set in ZHA - unless it's a special case that's not handled by ZHA.

My guess is that that configuration is not always successful (very much like polling), and once the device is set up, those commands are not sent again. So you're either in luck or not. I see on the other thread that the other user are often complaining about read_attr working irregularly, thereby suggesting that the communication is not at its best which was probably also true on initial configuration.

The 'Reconfigure' button for ZHA devices will send all these configuration commands again, still subject to successful reception (and when successfull will also override certain configurations you sent using zha-toolkit)..