3 ms·

> I have a strong aversion to Python I have had a great experience with HA (unlike with OpenHAB which is a Java-based monstrosity with a data schema that is ne

> I have a strong aversion to Python I have had a great experience with HA (unlike with OpenHAB which is a Java-based monstrosity with a data schema that is near impossible to figure out). It's unfortunate that he went and rewrote an entire home management stack just because he dislikes Python. Even worse, the justification for disliking Python, namely: > It’s a nice language, but for things like home automation, having build/dependencies problems is the absolute last thing I need. is absolutely not a problem if you run HA on a tiny dedicated box, because all of that stuff is completely handled (and hidden) by the HA update system. > The biggest problem with HomeAssistant, however, is its really over-engineered setup for running on mini computers like the Raspberry Pi, which was my goal. It may feel over-engineered if you look under HA's skirts (the fleet of docker containers thing), but turns out you almost never need to go deep into HA to get it to do things, and when you actually do, HA is actually pretty open and easy to work with. (just ssh to port 22222 if you really need access to the bare metal system). I would agree that the HA setup is a bit unusual for someone used to just ssh into a linux server: I had the same initial reaction. But turns out it's actually never much of a problem. It's just different. Also, it may look heavy, but it runs absolutely fine on a small raspi-like computer. > Is the best solution we can come up with a bunch of Docker containers running on a custom Linux distro? Why not? It may "feel" big and complicated, but in practice: - it's very well packaged - it's very well maintained - it has support for a *ton* of home automation devices - it runs out of the box on a tiny and cheap SBC (a raspi) without overloading it All you have to do is dedicate a raspi to the problem and be done with it, not really a big problem. And if you really want to run it on a Linux server that is used for other things, and the HA architecture irks you the wrong way: just wrap HA in a native qemu VM and run it on your server along your other stuff.

deepspace 3y ago
The author's attitude reminds me of one of the best software articles ever, "Cash Cow in the Tar Pit" (https://www.computer.org/csdl/magazine/so/1996/03/s3041/13rRUxly9bK https://www.computer.org/csdl/magazine/so/1996/03/s3041/13rR...). The reason a "legacy" system seems so clunky and over-engineered and hard to modify and has so much corner case handling is: real-world experience and bug-fixes. When you throw that old cow in the tar pit and start developing your shiny new application, you throw all those years of hard-earned experience away with it. By the time your application works as well as the old one, it will be just as ugly. FWIW, I have been running HA in a qemu VM on a NUC for years, and it is one of the most stable pieces of software I use. It supports every device I can throw at it, and the automations, while clunky, are easy to manage, as long as you keep KISS in mind.
waterCalendar 3y ago
I love what author did and I'd probably do the same, I guess I'll replicate author path. It all depends on requirements, but I also dislike python, I want to do something in python (and I've started something but a bit against main trends), but packages and recent step to get rid of signatures is a big no from my side. Too many news here and there about "enriched" versions of packages regarding python - and I know other tech stacks have it too, but looks like they have it less. I would not see it as problem if HA had dependencies statically linked, which in python terms would mean just copied fixed versions into HA repo. Anyway what is wrong with HA/OpenHAB? It's too "enterprise" or rather too rich and therefore seems heavy to run - VM with at least 2GB of RAM? No, thanks. What requirements I have for smart home: - made for tinkering people - preferable approach as in open-hardware initiatives where one electric motor can be used either for water pump engine or spinning table saw, so you can use it with things you already have and you have some indications about how to connect it all together in various cases - something designed for the cheapest hardware (nowadays rpi comes quite cheap though but it is not truly open and there are availability issues) - something doing only what is necessary and not cloud-first - option for build time removal of unused features - no need for hot loaded plugins - build based on tools with long term compatibility in mind (again, sorry custom extensions for each new language in the world) - real time system or at least good separation of control vs deployment/etc - designed as optional extension to existing world with switch-off mechanism - no need for vast ecosystem as long as it is based on freely available standards - nice to have feature is to provide scripting scenarios, can be deployed independently from main control board - should be cross-platform on native level, so in the end going to C, no heavy vms or interpreters, nice to have runnable on bare metal - things like reports presentation should be done not in the hardware which has actuators, data should be kept in another piece of hardware e.g. PC
- jdiez17 3y ago
  You don’t need a real-time OS.

deepspace 3y ago

The author's attitude reminds me of one of the best software articles ever, "Cash Cow in the Tar Pit" (https://www.computer.org/csdl/magazine/so/1996/03/s3041/13rRUxly9bK https://www.computer.org/csdl/magazine/so/1996/03/s3041/13rR...). The reason a "legacy" system seems so clunky and over-engineered and hard to modify and has so much corner case handling is: real-world experience and bug-fixes. When you throw that old cow in the tar pit and start developing your shiny new application, you throw all those years of hard-earned experience away with it. By the time your application works as well as the old one, it will be just as ugly. FWIW, I have been running HA in a qemu VM on a NUC for years, and it is one of the most stable pieces of software I use. It supports every device I can throw at it, and the automations, while clunky, are easy to manage, as long as you keep KISS in mind.

waterCalendar 3y ago

I love what author did and I'd probably do the same, I guess I'll replicate author path. It all depends on requirements, but I also dislike python, I want to do something in python (and I've started something but a bit against main trends), but packages and recent step to get rid of signatures is a big no from my side. Too many news here and there about "enriched" versions of packages regarding python - and I know other tech stacks have it too, but looks like they have it less. I would not see it as problem if HA had dependencies statically linked, which in python terms would mean just copied fixed versions into HA repo. Anyway what is wrong with HA/OpenHAB? It's too "enterprise" or rather too rich and therefore seems heavy to run - VM with at least 2GB of RAM? No, thanks. What requirements I have for smart home: - made for tinkering people - preferable approach as in open-hardware initiatives where one electric motor can be used either for water pump engine or spinning table saw, so you can use it with things you already have and you have some indications about how to connect it all together in various cases - something designed for the cheapest hardware (nowadays rpi comes quite cheap though but it is not truly open and there are availability issues) - something doing only what is necessary and not cloud-first - option for build time removal of unused features - no need for hot loaded plugins - build based on tools with long term compatibility in mind (again, sorry custom extensions for each new language in the world) - real time system or at least good separation of control vs deployment/etc - designed as optional extension to existing world with switch-off mechanism - no need for vast ecosystem as long as it is based on freely available standards - nice to have feature is to provide scripting scenarios, can be deployed independently from main control board - should be cross-platform on native level, so in the end going to C, no heavy vms or interpreters, nice to have runnable on bare metal - things like reports presentation should be done not in the hardware which has actuators, data should be kept in another piece of hardware e.g. PC

jdiez17 3y ago
You don’t need a real-time OS.