Refactor Zaptec integration to improve polling and command handling#201
Conversation
- Introduced polling methods for charger and installation updates. - Replaced direct state updates with trigger_poll calls in various components. - Updated command handling in services and entities to use a unified command method. - Removed direct commands in favor of the command method
steinmn
left a comment
steinmn
left a comment
There was a problem hiding this comment.
Doesn't the Zaptec API cache values for 15 seconds or did I misunderstand the docs ( https://docs.zaptec.com/docs/api-fair-use-policy#2-api-usage-and-rate-limiting)? Would we really gain anything by polling multiple times within a 15 second span?
I am disucussing a lot with Zaptec about this. Notice what is said in #176 (comment) "There is no caching like mentioned #189 (comment), this is outdated info (fixed now). So, if value in states in still old one it only means that charger hasn't reported it back yet." |
Zaptec basically want us to significantly increase the poll intervals. Let's say we have a poll interval of 10 minutes during not charging. This means that if we don't poll after sending a command, it may take up to 10 minutes until the user sees the change in HA. I'm sure that won't be acceptable. The number of polls and timing between them are configurable. So we if find that the proposed scheme is pointless or that we need other timings, we can change it later. The second half of this post can be worth reading: #176 (comment) |
|
Ah, ok, then that objection was based on outdated info and can be safely ignored👌 |
|
For reference, I created #202 |
* Make TRIGGER_DELAYS as absolute, adding code for calculating the deltas * Fixup inconsisten log messages * Accept both snake_case and PascalCase commands
* Fix variable naming in _trigger_poll * Add type CommandType to help dev users to suggest what commands to use * Add docstrings to ZConst
2 participants
Note
This PR contains a known issue: It contains a new feature which issue a sequence of polls immediately after any HA imitated command or change. If HA makes very frequent changes (<20 secs), there might be many updates running in parallel for the same resource which is not good. This is planned to be fixed in a later PR.