I’d be intereted to know how many of these installations are managed by experts who understand coding and how many are simple “out of the box” software setups. My problem is that i am likely to have to pass my church setup on to someone who does not know how to code and whose knowledge only extends to say how to update the OS on their phone. Much of the English language used here will be beyond them, let alone the coding.
Since the average number of automations is 12, then I would say a lot is not experts.
If you just configure it once with local control then there would be no need to change anything.
And that’s the problem. The person who wrote it in the logs knew right away that the other painter didn’t come to work. But instead of telling me that the painter didn’t come to work they just wrote it in a log. I’m a busy person and don’t have the time to constantly check how the painting is going (which is why I hired the logger to do it for me in the first place) but eventually I finally notice that the room isn’t getting painted on time so I then have to go look in the log to see why. Then when I finally realize the reason the job is behind schedule is because the third painter didn’t show up the person who logged it tells me that they put it in the log so it’s my fault I didn’t know the painter didn’t show up. Even tho it’s the responsibility of the logger to check that three painters actually showed up. Now I’m stuck with a two thirds painted room.
I agree that’s the way it currently works but just because that’s the way it works now it doesn’t mean it can’t be fixed.
If the logger knew the painter didn’t show up wouldn’t it be better to send me a text and tell me right then that there is a problem instead of waiting until I need to figure out that the job is not getting done?
IOW, a repair should be raised.
The logger does not know that the painter have not already call in sick or that you have assigned him for another task for the moment.
Maybe he was just late this morning.
All these cases are also possible in HA.
What is worse is that due to how wireless communication works then you do not really know when the painter have not arrived for work until something is not done.
The problem with your analogy is that the painter and the logger are never in the same room so they don’t hear each other when they both yell their problems. Sure, it could be fixed, but it’s a massive overhaul of the entire system and it would likely only work on HAOS. It comes back to needing the ability to load the objects in memory, which cannot be done without loading them into memory. It’s a chicken/egg scenario. I’m fairly sure I’ve explained this to you before. We would need an empty playground to load the objects into to see what errors arise in order to raise them to the UI at that time. Mind you, this empty playground would need to duplicate your entire HA system.
If we took the other approach you’re proposing (raising all errors), you’d be bombarded with API call failures and many other non-important issues. It would create a firestorm. Just look at the MQTT name change debacle that created a repair that was very similar to what you’re proposing.
3 Likes
Just make it smart and only tell you of important things 
It would be possible to make a smarter system for just errors encountered in scripts & automations. Not sure if that would satisfy finity’s gripes with the current system.
1 Like
Sorry, just seeing this. You answered a question I posed about how often automations are edited with an answer about how many automations each person has. They’re just… two different concepts.
(Also, “average is low so there must be lots of 0s” is not actually how math works. In the example you posed, the smallest number of automations can easily be 11.)
Re concepts: Maybe an example will help. Bob sets up 50 automations, is happy with them, and never needs to access the Automations screen again. Jim has 10 automations, but is constantly tinkering with them, and accesses the Automations screen 10 times a day for the rest of his life. Jim, therefore, makes much more use of the Automations menu item over time, even though Bob has five times as many automations.
I hope that clarifies the difference between the two concepts.
Re math: It’s just algebra. If you have 5 people with 200 automations each (the outliers), another 5 with 50 each, and another 5 with 15 each, here is the number of people with 11 automations you’d need to see an average of 12 automations per person across the entire population:
200(5) + 50(5) + 15(5) + 11x = 12(5 + 5+ 5 + x)
1325 + 11x = 180 + 12x
1145 = x
That’s certainly a high percentage people with 11 automations – but, as I said, the math itself doesn’t require any 0s (or any number of automations lower than 11 for that matter). More likely in practice you’re going to see some kind of negative exponential function with Number of Users on the x-axis and Automations on the y-axis.
In general: Your last reply was rude and personal, which indicates to me that you’re not really interested in clarifying or identifying your error. The good news is that I think that the above explanation will be very clear to everyone else who might visit this thread, so this is the final comment I’ll make on the subject.
Be well!
Uncalled for, please be more kind.
FYI that’s 15 people with 1325 automations, which is an average of 88 automations per person, unless you’re trying to simulate x as a random large number of users with exactly 11 and 12 automations.
1 Like
So you just need 99% of all installations to have 11 automations for your very very small example to work.
So all new installations are installed with at least 11 automations from start?
And everyone has 200, 50, 15 or just the standard of 11 automations.
Right… Completely feasible.
Do you really believe in this or are you just trying to… well… cause stirr?
The data exists so why do you bother fabricating numbers instead of just asking Nabu Casa for them?
You got your answer 3 moths ago, yes you can add links in the sidebar to the automations.
Why do you try and create false data to prove some point that is of no value?
My previous comment isn’t wrong if you need 99% to have 11 automation, all other values can be statistically removed since they are insignificant.
(Sorry, I stopped reading 10 minutes in, so I may have missed some things.)
Someone said that templating is needed because we only have those symbols from our keyboard. WTH? That hasn’t been true for 50 years.
Text editors have supported having objects in line with the text for ages. For example, fire up OpenOffice Writer, Then select Insert->Fields->Page Number. You get an object that show the current page number and behaves like a single character. Right-click it and select “Fields…” (bad menu open name, btw) and you get a configuration window where you can select how the page number should be shown (1,2,3 / I,II,III / etc.).
The same could be possible with wind directions in HA. Click an “add value” button, select the entity, and you get field. Right click (tap and hold) it to edit it’s properties “ as text, with unit, [4,8,16] directions, [0,1,2,3] decimals, Title Case”, the last four greying out depending on the first one.
Which brings me to the next point. Dynamically creating UI elements based on user selections seems to be a big taboo in HA. Why? Always showing all possible entry fields instead of showing only those that are relevant to the current selection doesn’t make a software easier to use.
For example:
I am a programmer. I have coded since the 80s, professionally since '93. Every time I see this screen, it takes me a couple of minutes to understand it. I can only imagine how a non-coder would feel.
Were I to redesign this, it would look like this initially:
Entity: [____V]
( ) Above
( ) Below
( ) In Range
( ) Outside Range
( ) Formula
“Attribute” would show up after selecting an entity and only if there’s more than one. Selecting above/below would show one entry field, the two range options would show two. Each entry field would have button “select entity” directly attached to the text field that would bring up an entity selection popup—and use the same everywhere, not just in this condition. When an entity is selected, the text field would force the whole content to be selected while it has the focus and revert into “direct entry” mode when something gets typed in.
This is the type of rocket science people talk about. Simple things should be easy. Hard things should be possible. Weird things require a yaml editor.
Sorry, I got into ranting. I just wanted to write 2 or three sentences…
PS: Also, “Formula” and “Template” should both be available. In many cases, a simple formula language that understands entity names and math operators is enough—and way more accessible than full templating. sensor.gas_currentgasflow + 9 * sensor.gw2000a_absolute_pressure > 9009.09 can easily converted programmatically into a template. Have the UI do that and then store the formula in a comment in the template and there’s not even a need to change anything on the backend side. Bonus points for an “insert entity” button.
Sorry again, I just seem to be unable to not go on a tangent with a random idea.
1 Like
So what if you want the value to be above one value and below another?
That checkbox style won’t work for that.
Edit
Just noticed in range.
By all means, please help get HA to this point by contributing to the software. Many of the things you’re listing are wanted but it’s a large body of work, we need all the volunteer developers we can get. We don’t need more project managers though.
Full disclosure, I accidentally checked one of these boxes when scrolling
That apparently edits your post. I revered the check but it still shows that I edited that post. FYI.
You fell into a well-known trap of iterative design.
People are familiar how an existing thing works, so they add onto it or improve it based on that. Often people also do that when evaluating suggested redesigns.
However, that’s a trap. One cannot make a bad thing better by adding stuff only. One can make a good thing worse by adding stuff.
Redesigning something after it has gone through a number of iterations and has spoiled requires to take a step back and question its core.
In this case, this means making a list of what a user may want to accomplish in the UI. What are the mindsets users may have—especially those that don’t fit the old design?
Next comes the decision to group or separate different use cases. Here, I went for a broad split, i.e. I give the user an early option to select which path to take. From there it branches, with only one minor additional choice that is then duplicated into each branch (entity value or fixed number).
Such an early branch isn’t always the right choice. Presenting a user with a menu of 409 different things they can do is not quite good design (even though HA basically does this with its actions and triggers). But merging the choices too much (as with the current numerical state condition) can make for a very complex and hard to understand form.
There’s a reason wizard interfaces got so popular. They are halfway between stating upfront what the user wants to do and giving one big screen with everything. At least when they are implemented well and are branching—most aren’t and are just a way of tricking the user into thinking an interface is simple by only showing them one entry field at a time.
1 Like
Interesting feature. I wonder what the intended use case for making those boxes toggleable was. Did someone want to use a forum as their personal TODO list?
But thanks for the head up.
I think that’s just a feature of Markdown. PRs on github use markdown and have the same features. If you make a box ([]) it should be toggable if you have edit rights. I can edit anything, so that’s why I was able to accidentally check it.
I’d love to, but not only does HA use a software stack I’m most unfamiliar with, but I also am not a UI programmer. Software architecture, backend programming and UX modelling are my professional specialities. Yes, UX and backend is a weird mix, but that’s what happens when you work 25 years at a company that does project staffing by “any available warm body”.
Want to route calls to an agent in a call centre? I can do that. Want to validate parts lists for weapon systems? Done that. Want to deploy statistics software on-the-fly to 300+ Linux boxes? Sure. Want to transcode videos for a TV station website and put them into the CMS? Yeah. But putting a button into a modern web app? Here’s the design document, got a UI coder?
Oh, unless you need a HA frontend for Minecraft. That I can do.
This! Even after ~2 years of using HA, whenever I accidentally come across this monstrosity, I immediately switch to template condition 
On topic: when I started using HA, I expected it to require learning a lot of new things, so I wasn’t surprised by some hardship. I got stuck a few times; some things could have been explained better (e.g. what does “parallel execution” actually mean in HA, as it’s very different from you might expect) but I don’t have any major complains.
What makes HA the most challenging for me is the overall complexity of the topics I would like Home Assistant to cover. For example, I wanted to buy and integrate several CCTV cameras, but I had no idea about neither CCTV nor streaming. And both topics turned out to be rather huge. Of course, I can hardly blame the creators of Home Assistant for this in any way.