What about the code is not consistent? That’s the whole idea of using standard formats?
Here’s your road map end of year post… From said persons.
2 Likes
It seems my WTH is being hijacked and I don’t like where it is going…
7 Likes
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.
Everyone who is on the staff at Nabu Casa is listed here.
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.
Blurb from Open Home Foundation website
Between these 2 websites, you should be able to determine Nabu Casa’s role in Home Assistant.
6 Likes
Well…yeah…
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.
1 Like
Truth.
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.
1 Like
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.
OSD
2 Likes
What would the alternative be? What would you propose as a better solution to define and store user-configured automations and logic?
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.
1 Like
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.
3 Likes
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.
1 Like
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.
1 Like
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.
2 Likes
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.
1 Like
The fact is that Node Red is a viable (and in some cases superior) alternative to HA automation. There is no need to choose one over the other, or for HA to change to be more NR-alike?
1 Like
And the data field?
Isn’t that JSON you need to type in that field?
Is that really better than yaml?
I would say if you can’t write a template then JSON is not better
But that takes programming skills, and syntaxes.
Something that has already been deemed outrageous.
5 Likes
Which is different from being discouraged, to make it very clear. This is an HA forum, yet it’s welcoming towards other technologies, such as NR. There’s even a forum label for it. The only thing I’ve seen people say is that HA automations has improved to an extent (in terms of capabilities) that you often don’t need NR. The NR UI is another matter and I get that many likes that. I’ve personally never used it. I’ve had some difficult automations to build, but it was difficult because of the logic I needed — not because it wasn’t possible.
You guys missing the point. likely reading the most recent response without context (how usual).
One of the issues in this thread was related to to complexity of automaticing with use of yaml and jinja, which is kind of frankenstain in world of scripting/programming.
You asked for an alternative. I gave you one, I believe it’s easier to learn, is more consistent, the code (if must be used) uses full-featured, popular, easy to learn and easy to read programming language.
It has been stated that yaml/jinja have no such properties. It’s not even programing nor scripting language at the end. And because of that (and together with the fact it lacks programming language abilities) is inefficient.
In both cases newcomer has to learn something. I believe, making your first automation using blocks in NR is easier than then writing it in yaml. And for more complex things one has to learn more, in bot cases. NR with JS still offers more, than yaml/jinja. It’s even not subjective. It’s a fact.
@Hellis81 not sure what data you are about. In all my automation are rarely need to create data. And yes, json is more clear, and less error-prone syntax-wise then yaml.
@parautenbach, the question was about ways and options for newcomers, how to to smoothly propose alternatives to yaml to newcomers. Encouraging using NR instead of yaml would be the way. Not discouraging means doing nothing to give them an option, thus most of them is forced to learn yaml. It’s quite logical.
Thats all. Take it or leave it.
2 Likes