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