-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
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
Add Google Drive integration for backup #134576
base: dev
Are you sure you want to change the base?
Conversation
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.
Works as expected and LGTM. Missing test coverage should be a priority on follow-up PR.
LGTM - as this uses the folder ID, I'm assuming there could be a chance that someone might "accidentally" delete the folder? Does this impact integration startup / backup service? Could a backup upload "silently" fail for example? Very minor in the grand scheme of things, but I know Google's storage manager likes to recommend things to delete. |
Done. If the folder is deleted the setup fails with: |
Later this could be changed to use repair instead of reconfigure flow. |
That's a good idea. Thanks! For now I changed the quality scale to |
Lovely! Would it make sense to name the folder |
A plugin already uses the "Home Assistant Backups" folder in Google Drive. Will not using the same folder cause issues? |
I don't think so. Google Drive allows the use of the same name. |
@rokam But do you want backups created by two different plugins in the same folder? Moreover, if the file names will also be identical what will happen if they try reading each others files? |
It can be renamed after it's been created to whatever you like Potentially having 2 folders called "Home Assistant Backup" in the root of your Google Drive could be confusing if they are also using the addon. That being said, perhaps it could be named "Home Assistant Auto Backups" or similar by default? |
Ah, I was unaware as I don't use add-ons myself (running container). If there are too many potential overlaps/issues, I'd just stick with the current naming. |
This code uses id to reference the folder, not name: And also the addon: |
So that means that Google Drive will see the difference, it just might be confusing for the end user when logging into their own Google Drive and seeing 2 folders with the same name - IF (and only IF) one is using the Google Drive add-on already |
Maybe just use "Home Assistant/Backups"? |
The name is intentionally just Home Assistant. In the future this integration could expose an action to upload any file to Google Drive, e.g. to upload a camera snapshot or recording, similar to the service in the Google Photos integration. |
resp = await async_get_clientsession(self._hass).get( | ||
DRIVE_API_FILES, | ||
params={ | ||
"q": f"'{self._folder_id}' in parents and trashed=false", | ||
"fields": "files(properties)", | ||
}, | ||
headers=headers, |
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.
normally REST calls directly from HA (without being wrapped in a library) is not permitted in core
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.
Wrapping the REST calls in a library won't provide any value. In fact in an earlier version I was using aiogoogle and moved away from it in 4d3674c due to:
- non OSI license of one of its dependencies
- inject-websession and strict-typing (requirements for the platinum quality scale) wouldn't be possible with aiogoogle
- aiogoogle was slow because it was making unnecessary REST calls for discovery
- aiogoogle's support for streaming downloads wasn't compatible with HA. From my first commit I was bypassing aiogoogle and I was making a regular REST call for downloads
If you notice the diff of that commit, it's not like the code became longer after I stopped using the library. backup.py changed from 272 to 273 lines. So I don't see what would the benefits be.
I could wrap the REST calls in my own library. I've done it for other integrations I own for which this made sense, e.g. Opower, Android TV Remote, Google Assistant SDK. In fact for Google Assistant SDK I previously got feedback that the library doesn't need to exist and its code could just live in Home Assistant since it just wraps a simple grpc.
Wrapping the REST calls here is pointless. I'd just have a few library functions that just have 2 lines each calling the REST endpoints.
I tried this in my prod instance yesterday and it didn't work. The addons property was hitting the 124 bytes per property limit imposed by Google Drive. I just changed the code to use a backups.json file in Google Drive that is updated with a lock from this integration when a new backup is uploaded or an existing one is deleted. |
Proposed change
Add Google Drive integration. Currently it only provides a backup agent that works with the Home Assistant backup solution introduced in Home Assistant 2025.1.
Type of change
Additional information
Checklist
ruff format homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
.To help with the load of incoming pull requests: