This is an excellent point. It’s not just USB boot. The GPIO pins can’t be reliably read for input. There’s a two-year-old problem documenting this, along with a proposed workaround. There’s been no activity on it for a couple of months, last time I checked.
Not to diminish all the great work that’s being done on all kinds of higher-level stuff, but frankly, the core hardware functionality needs some focus here.
There would be far fewer posts here, and less time wasted helping beginners, if they had a place to go to learn it themselves, step-by-step, with links to the more advanced material.
Good point… as a direct example of this- last weekend I was introduced to the new Almond automation builder… and all I can say is the cool factor was diminished once I saw it was only going to work with devices home assistant identified as traditional lights ie: of no use for the two lights that I actually have automated- a plant grow and my bedside lamp, both of which are plugged into devices HA identifies as ‘switches’… or wall outlets as logical people know them as. (forgive my snideness- this was the subject of a prior thread I started where certain people were more interested in arguing the logic than exploring the thought potential there-in)
Sometimes I’m amazed at the ease, conciseness and neutrality with which other people are able to state my exact thoughts.
What are you referring to when making this statement - Hass.io, or HassOS? Either way, both are perfectly stable, or what I would consider stable enough for beta software, which HA has always been, and still is.
It isn’t needed, but it does help. If it was an essential part of the installation, it would be part of the installation documents.
That is entirely the point of the forums, to educate yourself and have others to help educate you.
So don’t use it, do a VENV install and stop complaining about how bullshit you think Docker is. Almost everything that can be installed as a plugin for Hass.io can be pulled from Github and run in venv.
You are not being forced to use Docker, there is multiple installation pathways.
Do you mean like this page on the Website? Links to advanced configuration, documents, example configurations from other in the HA community, how to use scripts, scenes, templates ,etc…
There is a very large proportion of posts that are made in the forums because users have not taken the time to properly read the documentation, followed installation guidelines, formatted their configuration correctly as per the docs, etc - and then, instead of taking the time to try and learn how to fix the issue themselves, instantly turn and ask for help posting “My HA is broken” with no logs, no real information on their set up, integrations used, example config, and so on.
It’s a symptom of society in general these days, people are used to having what they want, when they want it and are too lazy to investigate and fix the issue themselves and want things to work with little effort.
I’m not denying that HA has a steep learning curve, but if you take some time to read through the docs and search the forums, you will almost always find what you need.
HA is not paid software, it’s community based, so any documentation and guides is done by people in their own time. Sometimes it’s maybe not as user friendly as it could be, and if you find something like that, you can do as I have done a number of times and submit a change to the documentation on Github to make it easier for other users.
Or maybe users couldn’t be bothered spending hours going through breaking changes every time there’s an update. Community concept is great but where’s the end game.
If you want to use free, open source software, that’s what you sign up for. If you want a flawless piece of software that is updates silently, has no issue, requires no thought from you, then go pay for it.
It always blows my mind that people complain about using free, Beta software that isn’t up to their incredibly high expectations.
If you don’t like it how HA is currently, the vision the devs have, where they are taking it and the changes and effort that it takes to get there, then bugger off.
With that attitude are you surprised people are walking away from HA. Maybe people like you should bugger off and leave people who actually understand HA to it. Your contribution is hardly enlightening.
I’m very happy with HA, and understand it reasonably well, but certainly no expert. I’m happily staying with it, and have no desire to move the OpenHAB, as you have noted you may want to do.
I’m happy to face some issues with breaking changes, and things not being perfect. I’ve been using HA for over 2 years, it was far more difficult to work with and had far more issues 2 years ago than it does today. Using it today is a breeze and gets better and better with each update.
Like I mentioned, most people face issue due to not reading the docs.
also skipping 10-20 versions doesn’t help when there is an update you really want (and you don’t read the breaking changes). HA is just in very active development and some orignal decisions were bad regarding the architecture and how things work. These are being corrected moving towards v 1.0 and unfortunately do involve breaking some stuff sometimes to us users for seemingly no reason… so I just roll with it and keep up-to-date so it causes little pain.
If anyone thinks openhab is the answer, they should try it and see. HA isn’t for everyone.
Yes. I mean that one. It is very helpful. And I accept that there’s a steep learning curve. I’m very willing to do that.
But I keep hitting roadblocks. Important steps are left out. Details are glossed over. Conflicting terms and shorthand are common. Obsolete, and sometimes flat-out wrong, information is still being included.
Example: I was able to use a combination of the official documentation, these forums, Github, and searches of non-related Raspberry Pi sites to figure out how to read GPIO pins. I learned a lot and, although it wasn’t all laid out for me in one HA document, I’m OK with that.
When I got finished, and found that it simply didn’t work, I assumed I’d done something wrong. I spent weeks buying and tweaking hardware, running all kinds of tests and re-configuring the system over and over.
The documentation failed to mention that there is a known bug with HA. It simply can’t reliably perform the edge detection that the whole GPIO interface depends on. This bug has been known for at least two years. There’s a known fix that’s languishing now, with no apparent interest in fixing it anytime soon. https://github.com/home-assistant/home-assistant/issues/10498.
Agreed. Those posts can be ignored, or better yet, given a polite response along the lines of “here’s how to go find that yourself” or “here’s the information you need to include so we can help you.”
My whole point in my previous post was that spending a little time writing and updating good documentation, with enough information to allow new users to learn, pays off in the long run by avoiding the need to either answer or ignore those posts.
Then, if someone still doesn’t want to learn, that’s their problem.
I’m not sure what that means. It is difficult for a new users to find, much less understand, breaking changes. That’s part of the learning curve. I suffered the consequences of skipping that step that just once. It won’t happen again!
Could breaking changes be communicated better? Probably. Could the initial set-up documentation do a better job of steering new users there? Sure. But the information IS there, so that’s a pretty low priority, compared to core hardware functionality which simply doesn’t work, or beginner documentation that’s incomplete or incorrect.
Again, I’m not sure who this is directed at. I fully expect a lot of people who look at HA to ultimately walk away, because it’s just not for them. Others will try to wade in, and get over their heads very quickly. They’ll have a choice; walk away or learn.
I would humbly suggest that they should be encouraged to learn, not told they have a bad attitude or to bugger off.
I’m not trying to enlighten anyone. But I do want HA to succeed and grow. That won’t happen if it’s just an exclusive club with their own secret handshakes that they refuse to share. Being welcoming and supportive of newcomers should be a source of pride, not a chore.
I think the one ‘secret’ that ought to be shared with newcomers is that they are about to become Home Assistant beta testers.
Being an open-source project, relying on the efforts of volunteers, one will encounter gaps and rough edges. Overcoming these deficiencies often requires a considerable investment of one’s time (for research and experimentation). Anyone who has used this software, for an appreciable amount of time, knows it is far from being a consumer-level experience (the installation process alone is like nothing the average consumers attempts).
Although it is very possible to configure a stable, reliable system (I know mine works well), it’s only a matter of time before a new version changes something (usually for the better) that requires you to re-visit your configuration.
If one doesn’t know they are, effectively, beta testing Home Assistant, all of its gaps, rough edges, and breaking changes can be perceived to be a monumental pain in the azz. On the other hand, knowing you have a hand in the birth (and rapid evolution) of a product, prepares you mentally for its challenges … and there will be challenges.
If you think they could be better now then you should go back before about 6 or 8 months ago and see how much better they are now. There has been a huge improvement in that respect.
Not that I don’t agree with the other stuff you wrote (I generally do) but that particular thing caught my eye since I tended to be a super outspoken critic of the breaking changes documentation before it was changed.
Only if you want it to ONLY run HA. If you want to use HassIO add-ons such as MotionEye to record IP cameras, a RPi is NOT going to cut it. It will be ok for a couple of low res cams, but nothing decent
CaptTom and I are in disagreement about the validity of that example within the context that brought it up… the underlying examples (from my perspective) that led to that were throttling the database and usb-boot and neither of those are mentioned, best I can tell, in or linked to from that page. The database page… I’m not even sure it mentions entities, much less what can/can’t, should/shouldn’t be restricted.
That page does contain a lot of useful info, but it’s an info dump that 99% isn’t relevant to intermediate configuration… the vast majority is advanced, niche info that you’d have to already have a pretty good idea of your direction before finding what you need to get over the hump to where you’re trying to get to… it’s kinda like going from ‘hey, bottle rockets are pretty neat’, ‘you think so? …well, here’s everything you need to know to build your own space program.’ As a further example- the config examples are great but slightly less so when it’s link after link and it turns into a needle-in-a-haystack to find an example that does what you’re trying to do… keeping in mind- most of those are so advanced and utilize their own hack-fixes that likely aren’t a good way to go considering past and future config changes.
Sure… blame it on the users. Makes total sense. Blame the cold on the runny nose. I mean… if you wanna, we can tangent off into how poorly categorized the forums are. ie: very little, if any, distinction between all the different flavors of HA… (HASS, HASS.IO, HassOS, Hassbian…), the lack of simple things like troubleshooting templates… and really? …that you just brought that whole ‘symptom of society’… that is such a lame cop out. Like really. How `bout I complain about a community that would rather police posts for formatting and how the information isn’t presented in the standard format (ie: screenshots instead of code box… but how do you put something from the web-UI into a code-box?).
Disagree. Paid or Not… it’s not an excuse to meet a lesser standard or to justify disregard. All I’m saying is that it’s a two-way street. As far as community contributions- oh… just you wait an see… I get to the point that I know HA well enough to go through all the troubles… I’ll grammar and spelling nazi the shit out of the docs.
Questions being if it’s still relevant given past changes and if it will stay relevant given future changes and for how long considering changes are constantly happening all over the place with no indication of what or when (exacerbated by the lack of developer interaction on the forums, (did I mention that yet? …the divide between forums and discord?)
For the sake of clarity… when you say ‘end game’ are you speaking of a development roadmap?
This. This is what I was mostly replying to in my previous response bulleted as point 2 up above. OSS IS NOT justification for a cop-out like that and I DO know what I’m talking about here. In a past-life I had signifigant experience as a Dev for a very successful project. Very successful. Too successful. Just sayin… probably not a point that you want to step up to.
Ditto. Full-Stop.
You can blame it on something as vague as ‘active development’ but there are ways to do both… have active development AND not have so many unexpected breaking updates. You mention bad decisions being corrected and I think many of us feel there are things being worked on that need to be reassessed as far as priority goes. Seems like there’s a lot of effort being put into J, K and L to make M, N and O work when things would probably be all around better if B, E and G were a little more solid.
Right. Which is why I started this thread. To compile a list to look in to in case there were options that I was less aware of. Not to defend the flaws that I’ve experienced… hey- great… you haven’t had SD issues with your install. Neither had I, with any of my Pi projects, until (and this is just my forensic best guess) my database picked up a small corruption at some point. Over time… that corruption caused other corruptions that continued to grow until it started to affect more important parts. In time snapshots picked up the corruption and eventually my install lost the ability to update itself, then it got so bad that potential uptime went from <12 hours to <6 hours to 'lets reboot and see how long it take for my console to start infini-scrolling…
Discord.
I approach every OSS project with that in mind.
I’ll throw my agreement on what you said about the improvement that’s been made, but consider if… for instance- there were a revised versioning approach? Currently HASS is using a three-tier version format, second set has broken into the triple-digits… so… tell me… where is the rollover from 0.xxx.x to 1.xxx.x? If the rollover point wasn’t base-10 or base-100? …are we waiting for 0.999.x? …or is it an arbitrary rollover? 0.227.0, 0.227.1, 0.227.2, 1.0.0 (woohoo, bells and whistles) …has there been any kind of roadmap documented?
point is… there’s still room for improvement but people need to stop being so damn critical and antagonistic of what they see as dissent because it’s those kinds of questions that lead to thoughts like 'what if it was four-tier versioning and breaking changes were reserved for tier-two changes? ie:
tier-four- hotfixes (current tier-three)
tier-three- weeklies (current tier-two)
tier-two- breaking/major changes
tier-one- major version (current tier-one)
…updates to actually pay attention to could be fewer and further between and usually it’s the more advanced and technical installs that need the changes that break things… users that are prime candidates to pull and deploy an advanced dev branch of the code.
Correct. But for my purposes and preferences and in your example, for cams- I’d likely look into standalone IP camera DVR hardware… something rackmountable with space for multiple WesternDigital purples with HA serving as a viewport. But your point applies to other applicable intents of mine- the Grocy addon, for instance. But at that point I could add another Pi with a traditional serverOS.
I’m completely OK dedicating a Pi to HA. Completely OK. … … … I mean… the Pi4 in my UPS/Pi/m.2 stack… it’s a 1gig Pi4… completely intend to upgrade that to a 2gig Pi4 once I can justify it with a working hardware stack (microcenter had a sale on 512MB and 1G Pi4’s but not the 2G Pi4’s when I was last there).
Previously you mentioned power consumption as an issue yet now you are happy to keep adding more RPi’s. A NUC doesn’t use much power and a bunch of dedicated RPi’s is soon going to overtake the single NUC’s power consumption. I’m a fan of RPi’s too, but having the NUC capable of running ALL my add-ons without issue is nicer than having to run multiple devices to achieve the same end result.
I appreciate the point that you’re making… but for what my install is now and will be for the foreseeable future… all aspects considered (ie: my current ‘home’ isn’t someplace long-term so that limits what I’m willing to do at this time) and a Pi makes an ideal platform (ie: I’m not running cat6 for cameras… not here… and I have a strict 'no Wi-Fi automation devices policy… (hell- bluetooth for my plant sensor took a come-to-jesus discussion with myself).).
Point is- my intention is to keep it Pi based for as long as I can… if for no other reason than keeping ‘experimental’ things segregated until I’m less questioning of the stability (for external (HA-development quirks) as well as internal (my tendency of burning it to the ground before rebuilding when something goes wrong… I’d rather rebuild HA then plug things in than to rebuild the entire thing (ie: let the house burn… but the garage is fine)
edit: …and my intent wouldn’t be a bunch of Pis with dedicated purposes. I have no issue letting Pis serve multiple, even if unrelated, functions- for example… my OSMC Pi also serves as a CUPS server to put my non-networked usb DeskJet printer on my network as a network printer. In essence- I don’t expect my HASSpi to ever do more than act as a zWave/ZigBee controller slash automation scheduler… something I envision much more as an automation appliance than an automation server?
There’s dissent and then there’s just complaining.
If you’ve identified deficiencies either report them in GitHub or fix them. If you do neither then it’s perceived as complaining. No big surprise that people are ‘damn critical and antagonistic’ about incessant complaining.
Over the year I’ve participated in this project, I’ve witnessed many corrections and improvements. A problem was identified, possibly discussed and corroborated by others here, then posted as an issue and/or a PR. The result is progress (without drama).