-
-
Notifications
You must be signed in to change notification settings - Fork 28.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate Aurora_ABB_Powerone to DataUpdateCoordinator #72363
Merged
emontnemery
merged 25 commits into
home-assistant:dev
from
davet2001:aurora_dataupdatecoordinator
Nov 22, 2023
Merged
Changes from 19 commits
Commits
Show all changes
25 commits
Select commit
Hold shift + click to select a range
e6a21ce
Refactor to DataUpdateCoordinator
davet2001 eccb76d
Fix tests for sunset/sunrise
davet2001 516a0df
Correct time offsets in tests
davet2001 a0d04c8
Fix time intervals (attempt 2)
davet2001 d4ea67b
Merge dev
davet2001 7921d67
Fix tests after rebase
davet2001 dab0e02
Fix isort
davet2001 2546087
Address review comments: const and increase cov
davet2001 3ae8ce2
Fix merge problems
davet2001 8a3ceef
Refactor, removing unnecessary file
davet2001 f08a1b8
Perform blocking serial IO in the executor
davet2001 f8b3c8b
Replace deprecated async_setup_platforms
davet2001 586f50a
Merge branch 'dev' into aurora_dataupdatecoordinator
davet2001 916aeed
Merge branch 'dev' into aurora_dataupdatecoordinator
davet2001 8e093b5
Merge dev into aurora_dataupdatecoordinator
davet2001 5b06c3d
Update based on review comments
davet2001 6eae5b3
Fix tests
davet2001 893e254
Merge remote-tracking branch 'upstream/dev' into aurora_dataupdatecoo…
davet2001 7760e68
Update based on review comments.
davet2001 2732e94
Update homeassistant/components/aurora_abb_powerone/sensor.py
davet2001 b3ce850
Merge branch 'dev' into aurora_dataupdatecoordinator
davet2001 f084896
Merge branch 'dev' into aurora_dataupdatecoordinator
davet2001 f92c6cf
Merge branch 'dev' into aurora_dataupdatecoordinator
davet2001 c36f1f5
Use freezer for time deltas.
davet2001 e1dae93
Address review comments
davet2001 File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
57 changes: 0 additions & 57 deletions
57
homeassistant/components/aurora_abb_powerone/aurora_device.py
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you migrate to using
CoordinatorEntity
as a base class you don't need to worry aboutavailable
anymore.raise UpdateFailed
if something goes wrong and everything will automatically go unavailableThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have done some experiments with this, and I'm not happy with the result when raising
UpdateFailed
.The problem is that
UpdateFailed
logs an error every time, but going offline during the night is not an error. I don't want to fill the user's logs with errors that are impossible to prevent. By explicitly detecting online/offline I can manage what generates an error and also only show log messages when the device comes back online, even though it is trying 100s of times in the night.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it changed in all those months, but I just checked the code of the DataUpdateCoordinator and there is a mechanism for this:
Which is doing exactly what you're doing right now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get what you are saying, but I'm trying to do something very specific, which is to catch the case of a timeout error, then display a single warning message on the first instance.
I think the automatic route only gives me the possibility to suppress all failure logging which isn't what I want.
In addition, this particular device is sometimes unreliable particularly in low light, so I'm planning a follow up PR that does some auto-retrying, see davet2001@f745523 and #82983
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not talking about the
log_failures
but about the last_update_success. If you trigger an UpdateFailed, it will log an error, and then it will setlast_update_success
to False, which is checked before logging.So in practice, if UpdateFailed is raised 5 times, 1 error is written. It won't log it again, until it actually does an update without a raised error (so it succeeded).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, they are doing very similar things. I did a quick experiment, changing the code to raise
UpdateFailed
on timeout. It works as you describe. But here is the log output:Existing code:
Using UpdateFailed to manage offline/online messages:
They are almost identical, but the key point: going offline due to sunset is not an error. So I want a way of this occurring without raising anything red in the logs (only info/warning). I can't see any other way of doing this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay you got my point, now I know we're on the same wavelength.
Is there a way in the code you can differentiate on if it's because of a failure or if it's because of sunset?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately none that I know of, unplugging the cable behaves the same as sunset (both cause a timeout).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I still think this is a difficult situation. imo, posting something in the logs doesn't have to be seen as something bad, just an FYI. I think we can just use the normal way like every integration does, but just have to teach the user a bit more about how it works via the documentation or the error raised. You could edit the raised error like, "Lost connection to inverter, could it be dark?". We have way more integrations that just log every time the service is responds with a 500 while the next call just succeeds.
I think it would be good to have a third opinion on this matter. Like I get where you come from, but I am just wondering what's the right solution here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joostlek I don't agree. If there are warning or error prints users will create issues and complain about it. In this case, what could be considered is to log with info level since debug prints are usually very spammy.
I think the PR is good to go as is though, adjusting to info level can be done in a follow-up.