HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
home-assistant
core
Python2014–2026
home-assistant / core

core

:house_with_garden: Open source home automation that puts local control and privacy first.

45Distinct people
55Mentions
0Explicit recommenders
92.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

:house_with_garden: Open source home automation that puts local control and privacy first.

GitHub

Where it is used

  • Marine Assistant — Marine Assistant uses Home Assistant as the core software platform powering its aquarium controller. It relies on Home Assistant to provide the automation and update capabilities for the product. Source
  • GrowRig — GrowRig uses Home Assistant as the foundation for its local-first grow monitoring and automation system. It builds its ecosystem on Home Assistant to power device integration and control. Source

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:03:30 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year55 dated mentions

Observed mentions: 2014-11-03 05:04:34 UTC to 2026-06-14 00:36:45 UTC.

02468102014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 7 mentions; 2 submissions, 5 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC110
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC817
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC725
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC211
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC1019
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC312
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC606
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC312
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC716
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC413

What Hacker News says

10 sources
> You're entitled to nothing when authors write FOSS. They provide it as-is. Take it or leave it. No one is obligated to take support harassment. the author of the lib literally pushed it to Home Assistant, so he gave it to a relatively famous project that is present in a lot of distro and Snapstore. Pushing to such project is a guarantee that your code will be repackaged. He could say it was a misunderstanding and require to be remove from HA, but to go to a project that uses the project that you PR your code into? eh. We have licensing for this reason and I am quite sure if frenck had choose the correct license/limitation from the beginning, it would have never been accepted into HA and this whole problem would have been avoided > Tons of FOSS projects do not support alternative distributions. In fact, implicitly, virtually no one doe
Read the rest
s. Most authors publish software with the expectation you'll use their distribution channels. I don't think this is true, and the fact that already author's libs had been already packaged in Gentoo, Fedora and possibly more distro (and he said he will request to remove them) show how quickly alternative and well used channel can and will pick them up if not specified in your license. Especially if the project you are contributing is ALREADY packaged in different disto. source: https://github.com/home-assistant/core/pull/51645
In “Please don't add any of my stuff to this project”
It looks like the bigger question here is this: Is it the official policy of the home-assistant project that their software should not be packaged by NixOS? frenck is the fourth most active contributor to home-assistant - and it uses quite a few libraries he has authored: https://github.com/home-assistant/core/graphs/contributors If frenck is saying NixOS can't package his libraries, he's actually enforcing that NixOS cannot package home-assistant. Is this direction agreed by the other maintainers of that project?
In “Please don't add any of my stuff to this project”
> It sounds like Home Assistant by default pulls the latest version of the package from PyPI at runtime and loads it dynamically. Package versions are recorded in component manifests so it will not default to the latest version, someone has to make a code change and PR on homeassistant to update the version. And they are collected in a requirements file for every HA release[0]. So it should not be hard to automate that if needed whenever the HA Nix package gets updated to ensure the latest used version of ambee package is included. [0] https://github.com/home-assistant/core/blob/dev/requirements...
In “Please don't add any of my stuff to this project”
What's worse is this frenk guy seems to be the reason his packages are being added to nixpkgs He added the dependency himself https://github.com/home-assistant/core/pull/51645 Nobody gives a shit about frenk or his code directly here - they want to use Home Assistant. But now that frenk added his code as a dependency, he has the right to transitively make Home Assistant un-packagable on NixOS? EDIT: On top of that, the way NixOS works is philosophically in-line with Home Assistant > Open source home automation that puts local control and privacy first Pinning every Python dependency instead of fetching HEAD is how you get local control and security!
In “Please don't add any of my stuff to this project”

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.