I personally don’t think the YAML in itself might be the biggest problem. The biggest problem is that it is un-intuitive, and on top of that it gives error-messages that make no sense to someone learning the syntax. On top of that it refuses to save your error-ed content and it will just delete lines you comment out.
At the moment the error-messages even go so far as to give an indentation-error when you actually had some ‘fault’ in the contents of one of the items before the item with the indentation.
As I suggested before improving on this could really prove beneficial. And perhaps there could even be a ‘fix my indentation’-button or a ‘highlight what is wrong and suggest what to change’-button, but perhaps this might be too far fetched…haha
(btw Studio Code Server seems to actually show the colors I was suggesting earlier in this thread, but I have only had a first look at that program).
The way I see it, the problem is there’s a risk of a biased agenda linked to the commercial operations that Nabu Casa now runs, controlling the development of HA.
It’s important to note: I have no problem with a commercial business like Nabu Casa leading the development of HA – quite the opposite.
But it would really be great if those in charge could step up and actually start acting like a business. HA is either a community-driven project or a commercial venture. Trying to play both sides like they are now is just pathetic and almost cowardly towards the people who are putting in free work on the platform.
I believe Nabu Casa should:
Get moving with an official roadmap about whether HA is going to stay a community project or if they’re serious about “transitioning to a mainstream consumer product.”
Define clear roles for future volunteer work.
Set up a communication strategy. Just posting excited updates during releases or occasional shoutouts here on the forum doesn’t count.
Fix the documentation so it actually works for a “mainstream consumer product.”
Make sure the responsible maintainers reply on GitHub.
A lot more, but I’ll get into that in a later post in a separate WTH thread.
Regarding ‘employees’, I think the term ‘staff’ fits better to include all types of compensation, including volunteer work.
That’s a very good way to end up with a fork. The vast majority of HA is based on volunteer effort, I very much appreciate the work Nabu Casa does, but HA will continue without Nabu Casa, it won’t without the volunteer developers. This is still a community driven project, Nabu Casa can lay out their vision for the future, work to generate excitement and even put their resources to pain points, and but they still have to sell that vision to the community, it’s not a dictatorship.
So, a volunteer with no affiliation to Nabu Casa isn’t allowed to share opinions? Seems like you just want to silence a group you disagree with. How is that fair
You’re basically asking for roughly 3000 people to not share opinions because they’ve made contributions to HA.
EDIT: As for comments in regards to this
Balloob, the creator of home assistant, transfered ownership to the Open Home Foundation and coined legal documents ensuring Home Assistant will remain an open source project and cannot be sold. This was announced earlier this year.
Promise, this is my last comment on who’s actually in control of developing a more user-friendly version of HA that doesn’t require a degree in rocket science. So, who’s really pulling the strings of HA? The community, Nabu Casa, or the Open Home Foundation? Only time will tell…
Most likely.
True, and that realtionship is the very the heart of the matter especially now since Nabu Casa tide most part of the major mainters to the business. I think it whould be decente gesture of Nabu Casa to all other volunteers to define that relationship and any offiically announs gratifications to for mainters working for Nabu Casa.
No, staff connected to Nabu Casa. I believe that the relationship with Nabu Casa should be clearly defined, and if any staff expresses an opinion, it should at least be clear whether that is the case.
It’s possible you’re mixing up the concept of open source (the code) with a commercial entity like Nabu Casa, which bases its business on this and, in reality, has control over the development. Nabu Casa could easily go public or be sold if it succeeds in its business (but only if they manage the transition to a mainstream consumer product, IMO).
As I mentioned before, I have no problem with a commercial business like Nabu Casa leading the development of HA – quite the opposite. But I still think they should get their affairs in order officially as a grand gesture to the volunteers, especially when so many of the key maintainers are signed up with them.
I have a feeling you’re trying to imply that moderators are staff, and you’re trying to imply that myself, Tom, and Tinkerer should not post our opinions. Let me be very clear: moderators are not staff. We are no different than moderators you’d find on reddit, or any other community.
But I can neither confirm nor deny if that is a good thing.
I agree that the documentation isn’t great.
I think tho that some of the recent documentation changes have been clouded by the move to configuring things via the UI. Again to make it more user friendly.
that results in an integration documentation page which is basically saying:
“click this button so that ‘My’ can take you to the HA integrations page and follow the prompts there”. And that’s it.
But what happens if the prompts are vague or not well specified?
I think I’ve had more problems trying to configure some integrations via the UI because I need to try to figure out what the integration config flow field is looking for than most of the yaml configured integrations that have structured documentation tables along with examples.
of course you also need to temper the “easy” expectations by understanding that you are still dealing with a pretty technical piece of software. So the user will always need to know what some technical terms mean. I don’t think there will ever be a way of getting away from that and still maintaining the power of HA.
EFP
I 100% agree.
Unless it’s a direct reference to a yaml syntax error then error messages in the log are more like reading tea leaves than a real tool to help find the problem.
these two are related.
when you do a config check (when it works to catch errors - which isn’t always the case - which is another probable WTH - that I should post about) it will tell you what the problem looks like it could be to the checker.
remember that the error checker can’t read the users mind but only find issues in syntax/structure.
So maybe not a button but the functionality is mostly there.
That’s the tool I was mentioning earlier.
EDIT TO ADD:
I just posted a WTH about the config checker here:
Out of curiosity, how many of these are straight YAML automations and how many of them and how many of them contain templates of any form?
The whole concept of “templates” to me has always seemed weird. For many reasons but mainly:
“Template” is not the correct term. It is more like a macro language with the familiar programming structures one would find in a scripting language. I can’t speak for others but when I initially heard the term “template” I kept thinking of something like Crystal Reports or Word templates. Where there is a structure defined to display elements, and those elements are replaced by underlying data. It made sense from a YAML “variable” context, but did not make sense to use this language/concept to develop automations. It’s one of those things that I can see new users being very confused by.
Having to define that I am about to do something with a “template”. I know this is going away, but there are so may “value_template” and similar where the user must specify in YAML to suddenly jump into a programming language which is in addition to defining things in straight YAML. It is very obvious that it was realized early on that YAML is not an appropriate way to create automations, so templating was added to provide “real programming” capability. Which begs the question…why have YAML automations and not just have every automation a Jinja “template”?
The brutal error messages which are displayed when making a YAML mistake are absolutely not helpful. Combine these with templates, where it is very easy to screw up spacing (don’t hit TAB!) when combining them with YAML resulting in very difficult to troubleshoot errors. At least Home Assistant usually doesn’t finish loading now if this is the case.
The UI is great and has jumped in usability leaps and bounds for creating automations since I started (2017). But fundamentally, it is still just a front end to a system of an inappropriate markup language hacked into a programming language. Simple automations are easy (ie. turn this light on at this time). But for anything more complex, the insane nature of using a combination of YAML and Jinja to create automations shows.
MQTT trigger is an easy example I run into. I use MQTT triggers in lots of automations (everything in my setup runs on MQTT…everything). In the UI I can define an MQTT trigger easily enough. But then must throw out the entire UI and jump to a “template” to determine if the message is what I want to act on:
One can see how this would be very confusing and counter intuitive for users. They simply wouldn’t find in the UI the option they need to determine if the MQTT value is between 1 and 900.
So they start to Google it (I just tried this) and find out what you need to use a “template”. Then hit the documentation for templates and there doesn’t seen to be an example of acting on an MQTT value which is clear and concise.
Once i wrapped my head around the fact that:
templates are not programs - they generate a thing.
They themselves can respond to triggers but if you’re not in a script forget making a service call.
So trying to trmplate something like a calendar entry that now requires a service call required precognition that I needed the calendar in the first place. So we work around it with a convoluted set of triggers somewhere else (usually on a time pattern) to preload a sensor or a synthetic text location made up of an attribute twisted into storage - as long as it doesnt exceed 16K LONG INHALE
I can understand the frustration. I really can. But i think the source of it all is YAML is really inappropriate for coding, As we try to make things easier we will invariably hide functionality in teh simplification - to prevent expert users from screaming thier bloody heads off YAML must still exist wiht the bonus or expert features. Lay-end users scream about not having XYZ - then someone steps in oh - its there you JUST have to… (YAML snippet)
THat cycle i see a permanent fixture of HA and will probably NEVER end.
I’d be happy with updating the error messages in teh editor to point out LINE AND COLUMN in plain english where to look for the error… (It’s absolutely there IF you know how to read the message and array loops it is telling you) That one simple point would probably do more for this entire situation than anything else I can think of. It seems like rocket surgery because normal humans dont speak array loop counters - base zero.
Thank you @ToonK! I have a similar background to yours and I share your sentiments, good and bad. My take-away from this and the aforementioned other discussion is that our perspective is not appreciated. eg. “I think home assistant is not for you.”, “The problem is that the documentation is not being read.” “hundreds of thousands of people before you get this (implied: it’s your problem, not HA’s)” “half million installs” (Please subtract my 10 or-so re-installs.)
GUI coding is fine … until something goes wrong. I start in the GUI with a primitive automation or script and then switch to YAML . Unfortunately I’m not yet seeing the patterns of YAML . The [YAML syntax] (YAML syntax - Home Assistant) and its referenced YAML Style Guide are full of examples with a lot of “good” and “bad” but no “why” these get this classification. Yet I’m still hopeful that YAML will eventually click with me.
I have had issues with timing. I’m pretty sure that this is related to the fact that Python is an interpreted language. I have a device that sends a message to an MQTT broker, which is picked up by HA, processed, then sent back to the broker to be picked up by another device. This takes 4-7 seconds. When I replace HA with a bash shell script (MQTT client, grep, awk, sed and their buddies) it is less than 1 second.
Here’s a bit of irony. A successful port of HA (or any port, for that matter) to a compiled language will require HA to be fully documented.
Be that as it may. HA has a lot of good things about it; documentation is not one of them.
Let me answer this question: NodeRed.
I know a lot of HA users use that. I know that a lot of them don’t, sticking to yaml automations.
NR is ingenious in it’s simplicity and easy to use at the same time.
And if you need something more than provided by NR nodes (ie do some math), you have JavaScript in hand. So it gives full-featured, popular, easy to learn, real programming language.
Moreover, NR gives access to a huge library of various functionalities, not available in HA. Some time ago I saw a node doing pretty complex stuff to control window blinds based on the Sun position, azimuth, time of a year etc.
You can build whole home automation based on NR alone , since it can even provide a basic gui.
I know there were similar discussions in the past. But I cannot understand till today, why it cannot be the main automation tool for HA.
Well you can use Node-RED in HA, the instalation is very simple and it was one of the first things I’ve installed to HA when I started. Initially I made most of my automations in Node-RED, but since then I’ve moved them to HA. The automations in HA became much easier to use over time and for me they are much easier to mantain now then by using Node-RED.
I still use Node-RED for my advanced climate controll which uses my AC units and gas boiler and has many conditions which are time and occupancy based. This has been working with little tweeks for two years and since it is complex and works I’m not moving it. I also use Node-RED for complex web scraping (like for train schedules).
So as Node-RED is a great tool, right now 99% of my over 100 automations in HA. The great thing about Home Assistant is that you can use external tools like Node-RED in it.
So as for this I do not want the HA automation system to be replaced by Node-RED, I would maybe like some more advanced visualsation of the automations but UI editing as is is fine for me. I do not have any programming experience, started some coding after using HA for over a year. I’ve actually had HA run on a VM in windows for some time before switching to a full install so I could learn and have some fun with it. I still have a second HA install on a another server to test things, because my main install is so advanced and a part of my house that I do not want to test things on it.
NodeRed is already available, so people are free to use it if they prefer it. I personally do not.
You can do a reasonable amount of maths using template sensors already, and sun azimuth/etc are available as attributes in HA already, so depending on the complexity of the automation it should be possible to create whatever was being done in NR.
Since NodeRed is already available, what should the core devs do? Removing all the functionality that already exists in Home Assistant and replacing it would be difficult and have massive backlash.
NR is available but is not encouraged to be used. the transition would take time.
But it would anyway in case of any alternative.
when I mentioned blind control node, the point was it was so complex as it would deserve separate integration in HA. for sure it cannot be mocked up with yaml and templates.
And with due respect, please do not even try to compare yaml/templates scripting abilities to NR. The latter is a different league.
Even basic math operations programmed in javascript look way simpler in javascript than yaml/jinja. Not speaking about more complex tasks.
It’s not that it’s not encouraged, but it’s not part of Home Assistant. You are still free to use it if it fits you better.
Again, you may prefer NR, but plenty of people do not. I have tried using it in the past and have found a lot more success with HA, what makes it a different league for you? I’m just curious if it really is a matter of the underlying paradigm being inherently better, or if it’s just more functionality.
You say it would take time, but I think you are massively underestimating the difficulty of changing the core of Home Assistant, to something which not everybody wants, and only to provide functionality which already exists if you just use NR.
What do you mean by NR is not encouraged to be used? There is no message that you should not use it or any other warning. Also check out who is responsible for the node red add on in HA and for the HA itself, you might be suprised.
The same goes for things like zigbee, you can use the build in ZHA integration or Zigbee2MQTT, what is your preference. But at the end of the day both give you entities in HA which you can work with. I actually use both, because I have two seperate zigbee networks in my house. Once again the power of HA is that there is no limit to what you can use, you like NR - use it, you like HA automations use them or like me use both. Now you want to limit the choice to use just NR and that is not the way to go.
So we work around it with a convoluted set of triggers somewhere else (usually on a time pattern) to preload a sensor or a synthetic text location made up of an attribute twisted into storage - as long as it doesnt exceed 16K LONG INHALE