LWN: Comments on "Home Assistant, the Python IoT hub "

Home Assistant, the Python IoT Hub

coogle — Thu, 02 Jul 2020 19:11:56 +0000

I'm not sure I agree with you portrayal of the project, at least when it comes to an F-Droid alternative client. Specifically you say the developer was intimidated, but it sounds much more like they just didn't have the time to work on it anymore when I looked briefly for information on this:

https://github.com/home-assistant/android/issues/42#issue...

I can appreciate the desire to be free of Google services, but I also don't think it's necessarily the responsibility of a project to agree. It doesn't make it less open source if the project leads aren't interested in maintaining an entirely different code branch of the mobile application (IMO). Since the Android app is open source, (https://github.com/home-assistant/android) there's little to nothing preventing someone else from maintaining a fork that doesn't require Google Play. I don't agree with the harsh criticisms of the project based on this, because I think fundamentally it boils down to an expectation they do work for free they don't want to do. That's never an obligation in an open source project and they aren't preventing others from doing it if they want to take that on (although obviously it would be an "unofficial" application).

Home Assistant, the Python IoT Hub

donbarry — Thu, 18 Jun 2020 00:52:33 +0000

This is a problematic space, with each of the "big three", Domoticz, Homeassistant, and openHAB having much to praise -- and criticize.

Of these three, the use of a scripting language immediately makes Homeassistant more modular, but there are some... peculiar.. architectural choices at work, with the oddities of the YAML configuration system and squeezing codepoints into "templates" (which are available for some entries and not for others) requiring some rather abstruse workarounds for things you wouldn't think are particularly odd corner cases. There is the Appdaemon extension that gives you real programming capabilities, but that there isn't such an interface "under the hood" and that the extension is maintained externally and independently is reason to pause.

Also, the team developing this is pushing online GUI configuration to the degree that some contributors have gotten scared away. I'm not sure I agree with their conclusion that configuration files are planned to be obsolete, but the core community can be clannish and opaque.

But what really disturbs me is the complete hypocrisy they show towards the spirit of free software. On their lead page is the motto "Open source home automation that puts local control and privacy first." Yet their extensions make no distinction or warning regarding the use of cloud-based APIs that leak private information and control, in the goal of advertising something that "just works" for whatever proprietary component you might have -- and still worse is their attitude towards community members who have tried to develop important Android clients that respect freedom and privacy.

An F-Droid client developer was intimidated into stopping development, and the Homeassistant cabal has decreed that their offering, under development, will use the Google messaging system for push notifications, and that they will not accept patches to make this optional to respect privacy and freedom, and to enable an F-Droid-hostable instance built only on free software.

So "puts local control and privacy first" is clearly just empty advertising, bereft of content.

Don't get me wrong, as a tool available under a permissive license that can be configured to be privacy respecting (minus the remote app), it's a good social contribution. But these are people very much in the "open source" camp of pragmatism, with the freedoms and virtues of free software something they seem to have never heard of.

Home Assistant, the Python IoT Hub

jccleaver — Mon, 15 Jun 2020 15:00:36 +0000

I really, really wanted HA to work for me, but I found the support just a little too lacking for the infrastructure I was building, but it's definitely made significant progress and I'm eager to see how it proceeds going forward. It's definitely in a better position than OpenHAB is as the go-to extensible open project, and that bodes well for it since there's always going to be a market for true local automation. (And I'm also glad I put together the small near-embedded PC to run it.)

Home Assistant, the Python IoT Hub

djs_tx — Sun, 14 Jun 2020 22:27:22 +0000

I know it is an expensive hardware solution to a software problem but I migrated to HA starting on the Micasaverde (now EzLo) platform. And I left the Vera in charge of all of my Z-wave. And it appears to be a stable solution. I've thought about "cleaning up" my setup and moving to USB stick but the cost is sunk to me and is quite stable. I guess a little energy inefficient though.

Home Assistant, the Python IoT Hub

beagnach — Sun, 14 Jun 2020 12:14:12 +0000

Your overall intent may be good but the critical language and somewhat condescending attitude will just undermine any good you try to do. I'm not sure I'd accept patches from someone who introduced themselves in that manner.

In the end we're all human. We've all had that project where we learned some new language and made all the beginner mistakes. Some of us were lucky enough to do it in private, or with good mentors. Others had to do it in public and have their beginner mistakes visible to the world.

There's not need to be so harsh. There's probably code still living somewhere that you're probably not too proud of.

also
> I might not have enough energy to fix all other issues...

If you don't have the energy then why would you expect the maintainer to? Again, we're all only human, with limited time and energy.

So if you want to make a positive contribution, don't just snipe from the sidelines and make some drive-by pull request.
Loose the superior attitude and approach this as one fallible human being making a contribution to a project run by another fallible human being.

Home Assistant, the Python IoT Hub

gerdesj — Sun, 14 Jun 2020 00:51:18 +0000

HA is now doing its best to get your current work into as many hands as possible. As end users we are getting daily updates now as point releases. Obviously' that is unsustainable long term but as integration bugs are squished why not release often.

I'm not qualified to comment on code quality but current end results for HA users look quite good to me and improving quite literally daily. I do know that Mr Ax can be quite forthright with his language and approach but he generally seems to know what he's on about.

To summarise: HA is making a serious attempt to do Zwave right and make the best of your work.

Please don't give up on us lot. Your work as upstream is very much appreciated.

Home Assistant, the Python IoT Hub

meerdan — Sat, 13 Jun 2020 14:54:26 +0000

I don't use the OpenZWave library myself but I wanted to thank you for all your hard work!

There is a lot of work that goes into creating and maintaining such a library. And it must be hard to see that as long as everything works, nobody says anything, but if something doesn't work, people come at you with pitchforks.

I appreciate that you still take the time to show your viewpoint as a maintainer. This helps to remind people that maintainers are also just human and actually want the best for their projects.

Home Assistant, the Python IoT Hub

Cyberax — Fri, 12 Jun 2020 17:51:42 +0000

Sorry, but your library needs refactoring. This is the truth.

A well-behaved library just shouldn't do behind-the-scenes DNS lookups and unsecured HTTP downloads to update files in the filesystem. Neither should it manage its own volatile state using flat files.

I'll send patches to at least correct the config storage problems so customizable backends (like an SQLite database) could be used. I might not have enough energy to fix all other issues (like raw C++ pointers everywhere for no reason).

And if you feel that commercial products unfairly use your library then change its license to GPLv3 and offer alternative commercial licenses. It will help a lot.

Home Assistant, the Python IoT Hub

Fishwaldo — Fri, 12 Jun 2020 12:05:03 +0000

As the maintainer of OpenZWave It’s this type of “typical” comments from the home automation community that makes me want to delete the repo and walk away never looking back.

I’m a single developer on OZW, used in dozens of commercial and OSS home automation projects not to mention everyone’s pet Home Automation project. At last count in 2019 OZW was deployed in close to 100,000 installations. I’m spending most of my time debugging crappy $10 Chinese implementations that don’t adhere to specifications than I am working on features or refactoring legacy crap. I simply do not have the time!

And all people can do is complain. If you don’t like it, instead of being negative (is it really necessary to call it Crap?) why don’t you start putting up some PR’s and improve the situation? - in fact on second thought, dont. Not sure I want to work with someone with your kind of attitude.

And your cache corruption - that was back in OZW 1.4 - at least 4 years ago and fixed a long time ago. I can’t control if HA doesn’t have the will or manpower to stay current with OZW releases till now.

Home Assistant, the Python IoT Hub

Cyberax — Thu, 11 Jun 2020 21:28:30 +0000

I prefer my libraries, you know, NOT to hang at random moments. And OpenZWave is also not very well designed in itself. I'm now working on fixing it - removing all the !@#&*@^# singletons and adding a proper storage abstraction.

Home Assistant, the Python IoT Hub

dw — Thu, 11 Jun 2020 19:19:14 +0000

Somewhat odd to comment on code quality while simultaneously lamenting the absence of threading. You'd prefer it randomly hang once per day, and always while you are in the bath?

Home Assistant, the Python IoT Hub

Cyberax — Thu, 11 Jun 2020 18:03:25 +0000

> the new OpenZwave is the best and has recently (yesterday) had more device types added.
Unfortunately, it's built on top of crap (OpenZWave library). And adding more abstraction layers on top of crap doesn't make it any better.

I guess it's a bit better now because crap is isolated in a separate process and won't crash/lock the main daemon.

OK, that does it. I'm going in and fixing OpenZWave the way I like it: no more singletons and an abstraction for the node cache.

Home Assistant, the Python IoT Hub

gerdesj — Thu, 11 Jun 2020 15:11:23 +0000

The Docker install linked to in the article is a bit involved. For a quick spin try the RPi option or if you have an old laptop lying around then why not try this:

Install Ubuntu minimal: http://archive.ubuntu.com/ubuntu/dists/bionic/main/instal...

Update it to the new LTS - 20.04 with # do-release-upgrade -d

# apt install docker.io apparmor-utils apt-transport-https avahi-daemon ca-certificates curl dbus jq socat software-properties-common

# curl -sL "https://raw.githubusercontent.com/home-assistant/supervis..." | bash -s

... wait, a fair bit is happening ...

Point browser at the system on port 8123 and watch journalctl -f at the commandline

That recipe gets you a "Home Assistant Supervised" which is the full toy box but with proper hardware. Go to the Supervisor menu and get some add ons. I suggest File Editor, Lets Encrypt, Mosquitto broker, NGINX SSL proxy, Node-RED, OpenZwave and Terminal & SSH

There are currently three ways to do Zwave. The built in one will be deprecated eventually and is based on Openzwave 1.4 which is a bit sad. Zwave2MQTT is pretty decent but for my money the new OpenZwave is the best and has recently (yesterday) had more device types added.

The pace of development is amazing on this project. You get proper changelogs nowadays and it all looks a lot more grown up than it used to.

Home Assistant, the Python IoT Hub

LtWorf — Thu, 11 Jun 2020 13:04:40 +0000

And here I am writing a C++ daemon to detect devices on the LAN, wiring relais to rpis, making my own async py daemon to drive them, making the central one to set which profile to use, using relational algebra, then making a shell client for that, then also a Qt client to show on the screen of the rpi, then adding all sort of things to that graphical client such as shutting down the screen backlight or the power to the speakers when they are not in use. :D

Home Assistant, the Python IoT Hub

pj — Thu, 11 Jun 2020 04:00:16 +0000

I gave up on HA for awhile, but checked it out again recently, and it's made some progress. Might be worth checking out once every year or two to see if it becomes bearable for you - it does seem to be under constant development.

Home Assistant, the Python IoT Hub

Cyberax — Thu, 11 Jun 2020 00:22:09 +0000

I'm on a personal never-ending quest for perfect home automation. I've tried HA but ended up very disappointed.

My major issues were with barely functional ZWave and ZigBee support. In particular, HA uses OpenZWave library that just _loves_ to corrupt its device database (kept in a flat file). It also can't use a database for it.

I looked at its internal code structure and got scared away by its internals, the most problematic part was its use of await/async to simulate threads.