A custom version of Home Assistant's built-in Google Calendar (google) integration. It is based on the core integration at Home Assistant 2026.10.1 and overrides the built-in one when installed. It adds one virtual calendar entity per Google event colour, so dashboard calendar cards can colour events per person or purpose while you keep using a single shared Google calendar.

Status: version 0.1.1, for testing. Tested in a development Home Assistant 2026.10.1 against real Google calendars (splitting, creating and deleting events, the Repairs issue), plus automated tests, and running on one production Home Assistant 2026.10.1 with the Daylight Calendar Card. The design and the findings behind it are in plan.md.

Requirements:

• Home Assistant 2026.10.0 or later. This replaces the built-in integration with core's 2026.10.1 code plus the colour features. Core's Google integration is the same in 2026.10.0 to 2026.10.2, and the tests pass on all three. HACS won't install it on older versions, where it couldn't load (it needs calendar features added in 2026.10.0). Later Home Assistant releases may change core's Google integration; this project is re-based on them deliberately, and a weekly CI job flags when that's needed.
• The Google Calendar integration set up as usual (see Home Assistant's Google Calendar docs). Your existing config entry and entities are reused.
• To create events, the integration needs read/write access: Settings > Devices & services > Google Calendar > Configure.

Steps:

1. In HACS, add this repository as a custom repository (category: Integration).
2. Install Google Calendar (event colours) and restart Home Assistant.
3. Home Assistant will log a warning that a custom integration overrides the built-in google integration. This is expected.

To go back to the built-in integration, remove it in HACS and restart. Your Google Calendar config entry keeps working; delete the colour entities that are left behind (they show as unavailable).

Google Calendar lets you name each event colour per calendar, for example "Child1", "Medical" or "Everyone". The integration uses these names for its calendar entities, so Google Calendar is the one place where colours are managed.

To name a colour: in Google Calendar on the web, create or open an event on the calendar, open the colour menu, and select the pencil next to a colour. Names belong to each calendar, so name them on the calendar you want to split.

Naming the colours is optional but makes this integration more user friendly. Dad has more meaning than Banana.

The colour menu in Google Calendar's event editor (left), its named colours and the pencil (middle), and the Labels dialog the pencil opens (right).

In Home Assistant, go to Settings > Devices & services > Google Calendar > Configure and tick the calendars to split under Calendars to split by event colour.

If a calendar uses colours that have no name yet, you're asked whether to split now or wait (the default). Waiting is usually better: a colour without a name gets an entity named after the colour (such as calendar.family_radicchio), and while naming the colour later renames the entity, its entity ID stays the same.

Choosing a calendar to split (left), and the question when it uses colours without a name (right).

For a calendar called "Family", alongside the existing calendar.family:

Every event appears on exactly one colour entity. calendar.family is unchanged and still shows everything, so on a dashboard use either calendar.family or its colour entities, not both, or each event shows twice. Each colour entity starts with its Google colour as its entity colour, which Home Assistant's calendar page uses.

Home Assistant's calendar page with a test calendar split by colour: each entity in its Google colour.

Cards that colour events per entity can use the same split. Some cards pick their own colours per entity rather than using the Google colour; the Daylight Calendar Card is one, where you set the colours in the card's configuration. To match Google, copy each colour entity's color attribute (its Google colour, shown in Developer tools > States) into the card. For example:

type: custom:daylight-calendar-card
title: Family
default_view: month
entities:
  - calendar.family_parent1
  - calendar.family_parent2
colors:
  calendar.family_parent1: "#f6bf26"
  calendar.family_parent2: "#ad1457"
calendar_names:
  calendar.family_parent1: Parent1
  calendar.family_parent2: Parent2

calendar_names is optional: it sets shorter names for the card to show instead of the entity names (for example "Family Parent1").

Daylight Calendar Card with five of the colour entities, using the card's own colours.

When colours in use have no name, a Repairs issue (Settings > System > Repairs) lists them with example events, to help you find and name them. After naming colours or changing them in Google, reload the integration to update the entities.

Home Assistant's create-event dialog has no colour field, so choose the colour by choosing the calendar: pick "Family Child1" in the dialog's calendar list, and the event is created in the Family calendar in Google with Child1's colour. The same applies to the calendar.create_event and google.create_event actions and to dashboard cards that create events.

Home Assistant's Add event dialog: picking a colour entity in the Calendar list sets the event's colour in Google.

• Events created on calendar.family, or on the entity of the calendar's own colour, get no colour, so they follow the calendar's default colour.
• calendar.family_other can't create events when the calendar's own colour has a name (an uncoloured event would show on that colour's entity instead).
• Deleting an event from a colour entity deletes it from the Google calendar.

• An event has one colour, so it appears on one colour entity. For events involving several people, use a shared colour such as "Everyone".
• Events can be created and deleted, not edited (the same as core). To change an event's colour, change it in Google.
• The calendar's own colour is a per-account setting in Google. The integration uses the colour of the Google account Home Assistant is signed in with.
• A colour entity's state (its current or next event) only looks at the calendar's next 20 events, so a colour with no event among them shows as off. Calendar cards and the calendar page aren't affected.

custom_components/google/ was copied from home-assistant/core at tag 2026.10.1. Commit 6ce6cd2 holds that copy unchanged, so git diff 6ce6cd2 -- custom_components/google shows everything this project changes.

Every difference from core, and why it was made, is listed in DIFFERENCES_FROM_CORE.md, along with the steps for upgrading to a new core version.

• Hassfest passes, with one expected warning: "Domain collides with built-in core integration". Overriding google is deliberate, because it reuses the existing OAuth config entry.
• HACS validation ignores brands, since this repo has no brand images. It also checks GitHub repository settings: the repo needs a description and topics.
• Lint (ruff) and Test (pytest) run on every push and pull request.
• Latest Home Assistant runs weekly as an early warning that the integration needs re-basing before you upgrade. It fails if core's Google integration changed between the base version (the homeassistant pin in requirements_dev.txt) and the latest stable Home Assistant, with the diff in the run summary, and it runs the tests against the latest stable Home Assistant. It doesn't block anything.
• Renovate keeps dependencies up to date, except Home Assistant and the integration's own requirements (gcal-sync, ical, oauth2client, pytest-homeassistant-custom-component), which are pinned to core's versions and change only when re-basing.

Open the repo in the devcontainer and run scripts/develop to start a dev Home Assistant (2026.10.1) on port 8123. Run the tests with python3 -m pytest.

This repository was scaffolded from ludeeus/integration_blueprint.

Apache License 2.0 (see LICENSE), the same as Home Assistant core, which custom_components/google/ and tests/components/google/ are based on. The repository scaffolding comes from integration_blueprint under the MIT License; its notice is in NOTICE.