I’ve been making several changes to my scenes lately, it would be nice to have a “Reload Scene” button on the scene page so that I don’t have to get out of scenes and into Server Controls to reload the scene. In addition, if a reload is necessary, why can’t the reload be part of the Save button, so that after saving, it reloads automatically.
This Reload function could be also placed in other sections such as Automation, Scripts etc. etc.
Not a bad idea, but you could just have a second browser page open on the reload page.
EDIT: Or better yet, when you save it just reloads… If config checking is a problem for this, enforce a passing config check in order for the save button to be enabled.
Having 2 browsers open, besides it’s really lame approach:
requires to open 2 browsers/tabs, steer to correct page. it unnecessarily costs time therefore it is not comfortable for users
brings risk of overwriting the code by editing file in other window. Unfortunatelly HA editor doesn’t recognize that opened file has been changed in the meantime.
TBH I’m shocked that people can advice/suggest so unproffesional workarounds so often
Not a bad idea, but you could just have a second browser page open on the reload page.
This is what I do today, but that’s the cause of my annoyance, rather than a solution to it. Seems minor but, as @maxym said, lots of small context-switching adds up to a lot of wasted time and an uncomfortable user flow.
Or better yet, when you save it just reloads
I like that idea better, but would that only work with in-browser file editing? Or would it be some kind of OS-level listening daemon, listening for edits, calling the appropriate reload service when detected.
In general, I would prefer to be in control of when the reload occurs. I constantly hit save out of habit, and I don’t want any currently-open editors to refresh, losing whatever progress I have there, or doing funky auto-formatting on-save.
Yeah, that’s the one thing that gives me pause with this “WTH” – it seems like everything’s moving toward being editable entirely in-app, without external editors. Once that happens, the issue would (I assume) be moot since all in-app saves would refresh automatically.
That said, I still very much consider this a “WTH” in the sense that it’s a relatively minor annoyance with a relatively simple solution.
While it seems to be super comfortable it’s not optimal in real life. You may want to save file (or even several files) multiple times before you really want to apply changes. aplying them in the middle of work will rise unnecessary errors.
Actually mission critical systems never apply changes automatically. Explicit command is required for that.
Offering current working solutions is not unprofessional. I’ve done my share of support over the past 10 years and there’s 1 thing you learn from that: People want answers and solutions now, not later.
When offering help is always welcome, wth is not for looking for help aka workarounds (tgere are other sections of this forum for that). in fact everybody knows it’s possible to use second browser instance.p more: both windows can be open next to each other. But in context of this thread it just seemed to me like excuse to not improve user experience because the workaround already exists.
This is how I received it. If it was not your intention then I apologize.
I agree with @petro here
Have a discussion, invite critisism, rebuff critisism where you can.
If you can’t your idea is worthless
Rebuffing it with reason makes your argument stronger.
petro / @Mariusthvdb / @donkawechico , your ideas here are very similar to @123 where he proposed a more seamless approach , where any file save (be it from the GUI or external editor) trigger an event which would determine if a config check was necessary, if it was, then one was performed.
It would then notify you “if it failed”
Subsequent to a sucessfull config check it would imediately reload the edited file into the system (maybe wouldn’t need a full reload that way).
Dunno.
Taras explains it a lot better than I and I can’t remember the thread
Yes, but I must misunderstand your question WTH then. Because I would only expect changes like this to work in the UI.
Not that it matters, but I’m just a passerby who agrees with the OP’s WTH.
So, I was trying to figure out whether the implementation you had in mind was UI-based or independent of UI.
Examples of non-UI solutions:
An OS-level daemon that monitors yaml files and reacts to any modifications. This would be entirely independent of how you’re editing your files, whether it be the UI, through external VSCode, nano, or even $ echo 'blah' << scripts.yaml.
The desktop version of VSCode has the “Home Assistant” extension, which comes with built-in tasks you can execute for reloading config sections. One could write an “on save” hook that runs that task from within the VSCode IDE.
I just want to say that I am very much fan of the “commit” approach. Eg. that changes have to be explicitly loaded. It can very well be easier to do it, with a more visible button or something, but automatically enabling all changes immediately can very easily lead to unexpected results.
I often change both sensors, automations, notifications and other sections with inter dependencies, and reloading the sensors before the automations are fixed (or the other way around) can really be problematic.
Wow, didn’t mean to trigger all this commotion, but in all good discussion all around.
Yes, my original post was for the UI based changes. I do the majority of my editing directly in the yaml files but decided a while back that I would give a try to use the GUI for Scenes. For that purpose, I enjoy the UI as I can create a quick scene from the existing state of my bulbs.
The suggestion came after editing several scenes and even after saving, my new (edited) scenes didn’t work until I went to the Sever Configuration page and reloaded them. I thought a button directly on the page would make sense.
For other functions, that may not work as well, but I like the suggestion of triggering a config validation first and then a commit when clicking reload.