Home Assistant, from user to contributor.

01 — 2018 · A user firstA product you live in

A smart home is an unusual kind of product. You're the engineer, the product manager and the main user all at once, and the feedback loop is your own daily routine. When something is off, you don't see it in a dashboard. You notice it at home.

What keeps me on Home Assistant is simple: it runs locally, it's open source, and I can read how it works. Privacy and security are long-standing interests of mine, and a home that needs someone else's cloud to switch on a light has never sat right with me.

I've also never tried to build the "finished" smart home in one go. Like my work setup, it has changed in small steps over the years: make one change, live with it, and keep what earns its place.

1. 2018
   A user first. I started running Home Assistant, and I've been improving my setup a little at a time ever since.
2. Sep 2025
   First pull request. I forked the frontend and proposed synchronised zoom across the charts in the history panel.
3. Oct 2025
   Shipped. The feature went out in Home Assistant 2025.10 and made the release notes.
4. Autumn 2025
   Follow-ups and fixes. A fix for my own feature's rough edges, a bug left behind by a component migration, and a clearer energy card.
5. Dec – Jan
   Login and automations. Forgiving whitespace in 2FA codes, and fractions of a second in automation timings.
6. Today
   Still a user first. My own setup keeps changing, and the frontend is where I go when something could be better for everyone.

02 — Sep 2025 · Getting mergedThe first pull request

What turned me from user into contributor was the possibility itself. Home Assistant is one of the biggest open-source projects around, and its frontend is open to anyone willing to learn a corner of it. Understand one part well enough and you can improve it for a huge number of people who'll never know your name. For someone who builds interfaces for a living, that's a rare kind of leverage.

My first real contribution was a feature for the history panel. When you have several charts there, zooming into one now zooms all of them to the same time range, so you can compare what different entities were doing at the same moment.

Writing it was the easy part. Getting it merged taught me five things:

1. The process is part of the product.My first attempt didn't last a minute. The project's bot flagged commits that weren't linked to a GitHub account, so the contributor licence agreement check couldn't pass. I closed it and opened a clean one with properly linked commits. Reading the contribution guide first is part of the work.
2. Someone else might be building the same thing.Another contributor pointed out an earlier pull request that looked similar. Rather than compete, I offered to coordinate with its author. They ended up testing mine and caught a regression: the hover tooltips on the graphs had disappeared. I fixed it and posted a recording.
3. Use the system's components, at the right layer.A maintainer's review reshaped the code. Instead of dispatching zoom events from the parent, add a public zoom method on the base chart component and let each chart pass calls through to it. Use the project's own floating action button rather than a generic icon button. Respect the device's safe-area insets. Remove the props nothing reads. None of that was about whether zoom worked. It was about whether the code fitted a UI built by a very large community.
4. Performance on real devices is part of "done".Before approving, a maintainer asked how it behaved with lots of charts on a phone. I tested it on my phone with all of my own entities loaded. It was slow with that many charts, but usable, and another maintainer confirmed the slowness wasn't coming from the zoom sync.
5. Evidence beats argument.At one point a reviewer saw three bugs I couldn't reproduce. Instead of debating it, I posted a screen recording of everything working. Their build turned out to be the problem, and the next review was an approval.

It was labelled Noteworthy and shipped in Home Assistant 2025.10, where the release notes put it simply:

“When you have multiple charts in the history panel, zooming in on one chart will now automatically zoom in on all other charts as well.”

03 — After the mergeShipping is the start

After it merged, rough edges showed up. Graph lines were drawn over the new reset button, a second scrollbar could appear, and when several history graphs shared a panel, the wrong reset button responded. Within a week of the merge I opened a follow-up fix, and it was merged the next day.

The same thread was a lesson in scope. When I asked the contributor who'd reported the issues to test the fix, they asked for more: syncing charts on dashboards too, and moving the reset button into the toolbar. They were good ideas, but my pull request was a bug fix. Syncing dashboards would mean wiring the logic into every page, which deserved its own feature request rather than a PR too big to review and test. I checked the button on a small iPhone screen to answer the size concern. The double scrollbar turned out to be an existing issue in the virtualised list, not something I'd introduced, so I said so and left it for its own issue.

04 — The smaller onesSmall fixes, sharp lessons

After that I kept an eye out for small things. Not all of them merged, and the ones that didn't taught me just as much.

• Merged
  Sort installed add-ons by name on the logs page Add-ons in the logs picker now appear alphabetically, after the built-in log sources. A list in no particular order makes you read every item.
• Merged
  Fix the target picker's buttons after the tooltip migration A migration of the tooltip component had prefixed element IDs, so the target picker's remove and expand buttons received the wrong ID. I fixed it and asked a maintainer to check for the same pattern elsewhere. In a big component library, a migration's bugs rarely come alone.
• Merged
  Add total consumption to the energy usage graph card The solar and gas cards already showed a total, but this one didn't. A maintainer explained why: this chart also shows grid return and battery charging, so a bare number would be ambiguous. We made it read as energy used, and kept the card's layout in line with its siblings. A number without a label is a question.
• Merged
  Trim whitespace from 2FA input before validation A correct 2FA code with a stray space was being rejected. My first version trimmed input too broadly. Review pointed out it would affect far more than the 2FA field, so I moved it into the login functions. Keep the fix as small as the bug.
• Merged
  Accept decimal seconds in time inputs Automation triggers and conditions can now use fractions of a second. The discussion was all about details: whether to show a separate milliseconds field, and how to pad a value like 0.2. I proposed keeping the existing formatting for consistency, and a maintainer decided to skip padding when there are decimals. Bring options, and let the people who own the design make the call.
• Closed
  A friendlier error for duplicate dashboard URLs Another contributor had fixed the same thing in parallel while I was on holiday without my laptop, so I closed mine in favour of theirs. The review thread also found the real fix a layer down: the backend should return error codes the frontend can translate, not raw messages. Sometimes the right fix lives one layer below yours.
• Closed
  Back-button protection for unsaved changes Review showed my approach left an extra entry in the browser history, so leaving a page would take two presses of the back button. The pull request was closed. A closed PR can teach more than a merged one.

05 — LessonsWhat a big frontend teaches

Home Assistant's frontend is one of the largest open-source user interfaces I know of, maintained in public by people who don't know you. Contributing to it sharpened habits I now rely on every day:

1. Write pull requests for strangers.Reviewers don't know you, your context or your intentions. Before-and-after screenshots, a screen recording and a clear "why" do the persuading.
2. Consistency is a thousand small agreements.Use the project's own components, keep sibling cards in sync, respect safe areas. No single rule makes a UI feel coherent; following all of them does. It's the same work I now do with the Experience Team at InSpace, building components and patterns that scale across NOVA.
3. Fix things at the right layer.A public method on the base component, error codes from the backend: the best review comments moved my fix to where it belonged.
4. Scope is a kindness.Small, reviewable changes get merged. Bigger ideas become their own issues.
5. Maintainers make the call.Bring evidence and options, then accept the decision. It's their product, and their time is the project's scarcest resource.
6. Closed isn't failed.Two of my pull requests were closed without merging, not counting the one the bot caught, and both left me knowing something I didn't before.

06 — Still a userLocal-first, slowly

Contributing hasn't changed why I use Home Assistant. It still runs locally, I still improve my setup in small steps, and I still care more about it being dependable than clever.

It also connects to my day job more than I expected. At InSpace I lead the Experience Team, building the interface NOVA's clients use every day. Home Assistant shows what that looks like at the scale of a huge community: the details are the product, and the best interfaces are the ones nobody has to think about.

If you want to see the work, my pull requests are public. And if you're tinkering with a smart home of your own, I'm always up for swapping notes.