Comments (8)
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:
- 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).
- 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.
from zha-toolkit.
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
from zha-toolkit.
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.
from zha-toolkit.
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
from zha-toolkit.
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
from zha-toolkit.
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.
from zha-toolkit.
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
from zha-toolkit.
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)..
from zha-toolkit.
Related Issues (20)
- module 'custom_components.zha_toolkit.neighbours' has no attribute 'get_routes_and_neighbours' HOT 1
- [Errno 2] No such file or directory: '/config/scans/tmptphbmdk_' HOT 4
- The robovac custom integration is using deprecated vacuum feature HOT 5
- Fallback on on actual attribute read if `use_cache` is `True` but attribute not in cache for `attr_read`/`attr_write HOT 3
- set attribute on tuya device HOT 7
- Make use of zigpy's new "Manufacturer OTA Firmware Update Support" feature (also referred to as "*Generic OTA providers")? HOT 3
- Leave: Need 'ieee' and command_data HOT 1
- zdo_scan_now: Unable to serialize to JSON HOT 1
- ZHA toolkit not working for OTA updates HOT 3
- Setting a different report interval to my thermostat via ZHA toolkit didn’t work HOT 7
- ZHAData is not subscriptable after upgrade to 2023.10.0 HOT 9
- Zigbee throwing errors HOT 1
- Setting New reportable_change on Tuya TS0201 (Temp + Humidity - No Display) HOT 2
- 🧰 ZHA Toolkit: Get Binding Table not working HOT 3
- Fehler beim Aufrufen des Diensts zha_toolkit.scan_device. Unknown error HOT 5
- OTA notification spams with WARN and ERROR and floods with requests HOT 3
- Backup Coordinator Data fails (AttributeError: getKey not found in COMMANDS) HOT 3
- Can't get data from API call HOT 9
- Unknown error: OTA' object has no attribute '_listeners'' for service call HOT 3
- Add example on how to set last seen attribute HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zha-toolkit.