I’ve done a bunch of searching but yet to really find anything addressing the need (ok, desire) to use an external editor for YAML files instead of the (functional, but very basic) one provided by HA.
While I understand I can of course just start an editor from the CLI and choose HA files to open and edit to my desire, that process is a bit klunky, particularly given that HA and my general O/S user are not the same user so I constantly have to mess around with permissions for editing files.
What I am looking for is for HA to launch my external editor of choice on a file chosen within HA to edit.
Dashboard editing is a perfect example. When I choose to edit a dashboard and then choose Raw configuration editor from the 3-dot menu on the top left, I’d like HA to open that file in my configured external editor, not in the basic editor provided by HA.
Is this possible in any way that my searches was just not finding?
I use Notepad++ on windows for dashboard editing. I just copy the yaml and paste it into Notepad++, use its power (you have to save the file as a .yaml otherwise tabs are used, but you can reuse that saved file) and when I’m done, paste it into HA. It would of course be better to have the functionality of both editors in one system but this works for me. My #1 issue is that I can’t read javascript well in my preferred theme, so have to change themes to edit, but then often want to change back to view, and Notepad++ helps get indenting right. Notepad++ is especially helpful when I am moving functionality between dashboards.
That’s not possible. The “raw configuration” is actually generated on-the-fly specifically for that editor. The actual content is JSON and hidden in .storage
Generally speaking (but not for, e.g., the use case above), you can use something like the samba addon to make the files under /config available to your user OS (windows, mac…), and then be able to open the files with your preferred editor.
Just because the configuration is generated doesn’t mean it’s not possible. HA could create a temporary file, write the generated content to it and then read it back when the external editor exits. This is a process flow that has been implemented many many times in other applications.
So, I guess as a hack/workaround something like that could work. Maybe. But it’s still pretty kludgy vs. having proper integrated support for an external editor. Having to add Samba as a dependency (that can break and need fixing) just increases the maintenance surface for something it should not really be necessary for.
Yes, of course that is a functioning work-around also.
But as I previously replied, I am hoping for something much more streamlined and supported as a first-class feature.
I’d suspect almost everyone would have a favourite editor they’d rather edit YAML in than the (very basic) built-in editor, so this would be a feature that would be much used in my estimation.
Ultimately, I suppose if this ability does not exist currently (it starting to seem like it does not) then this topic can probably be moved to the Feature Requests category.
When it becomes clear that nobody has any suggestions for how to get this to work without the workarounds, I will move it.
Web UI on whatever FE the user is operating on is configured to edit with an external editor (VS Code, GVim, Emacs, Notepad, etc.)
Action on said FE requests a file to be edited (i.e. editing a dashboard component for example)
HA server fetches or generates the content and gives the FE UI the file content to be edited.
FE UI receives the content (as it does now for UI editor editing) and (after saving it into a temporary file if required) opens the configured editor for editing.
FE UI waits for the editor to complete.
User edit and then saves the file and closes the editor.
When editor completes (i.e. the process closes) the FE reads the temporary file for the changes, deletes it and then submits the edited content back to the server.
I meant do you have a practical example.
I don’t remember seeing this feature in any other software.
I’m not sure a browser is allowed to download a file, launch a program, then upload the changed file without user intervention. Seems to be tricky security wise…
Which “External” editor do you have in mind ?, you do know that it somehow has to connect to HA ( Which basically is a linux-based webserver ), and there a “limited” ways allowed for this, such as add-ons like samba-share or SSH( with SFTP ) … this, you need to install first of all, for any external access, with samba-share you can use any editor i.e notepad++ Or you can use winscp, and connect over SSH(with SFTP) , and in winscp, you can in term configure External Editor
It’s as simple as this, you popup your favorite editor, which is already configured to access the files you want to edit.
As Chris explained cards/views etc are actually json, most config-files are plain yaml .
I agree that in specific the card-editor is horrible small , should open in full-view-size, i prefer raw editor is some cases, how ever i always save the views ctrl-a ctrl-c, paste in notepad++
In notepad++ i can make certain larger changes , then ctrl-a ctrl-c, and paste/overwrite cards/views
Other config files i access mainly through SMB/CIFS
As it’s a webview you are “phasing” cards(and mainview) etc are in this case mainly build upon.js class’es etc.
So someone could build a more comprehensive/advance file-editor( as an ADD-ON/Integration ) (i don’t need this to weight down my installation)(however yes card-editor in full-view, is desirable). Some card developers ad features to the UI editor, some has keep it “available” as file-editor options, and it will always be like this.
So if someone should build-in a click-option to an external editor, this has to include the ability to
copy the yaml-code
export it to some editor, on another node(IP) ( with user access to this “Windows Machine” ? )
receive this yaml-code, from this external-source/user-account
4 paste/overwrite it (preferable) in right place ( meaning keeping a connection to the specific card you are editing, in the webview ) Keep Dreaming
(or is it just specifically for raw editor mode, you find it unbearable to edit, and cumbersome to hit ctrl-a ctrl-c) ?
It doesn’t really matter. Any editor which can open a file, edit it and then save it.
The default/built-in YAML/configuration editor is just a “local” (i.e. to the web FE client) editor run in the browser.
You are thinking about this the wrong way around. The existing web UI editor does not use any kind of sharing or remote file access protocol to edit YAML/configuration files. The HA web UI client is given the content from the HA server which it edits and then sends back. The web UI is not given a remote file share (I.e. CIFS path, or ssh/sftp URL, et.) to load the file from.
It doesn’t matter what their source content is. Their source content (i.e. json) is not what the web UI editor is given to present the user with to edit. In my experience it’s always YAML. My point is that I don’t want to edit the source (i.e. json) files. I want to edit exactly the content that the web UI editor is given but I want to edit it in my own editor, not the web UI editor.
Frankly that’s the least of the issues. The fact is that the web UI is about as basic an editor as you can get. There are sooooo much better editors out there that will lint for you as you edit, have far better navigation, search and replace, etc.
Just the fact that everyone is super comfortable and efficient in their own editors
and should not have to devolve themselves down back into an editor from the 80s.
There you go. You have made my case for me.
That’s entirely and completely the wrong approach. The last thing we need is yet another editor. There are already tons of them and everyone has their favourite. We don’t need yet another one that doesn’t do everything everyone wants (whereas everyone’s existing favourite editor already fills that gap) anyway.
It’s all editing in HA. The bottom line is that the editor in HA is super basic, like a throw-back to the 80s. There are many many way better editors and we don’t need to invent a new one. We just need a way to leverage the existing massive pool editors where everyone has one they love and are super comfortable and efficient using.
I know how it works , and above “section” also , you on the other hand, doesn’t seems to know that it’s build that way, by the devs of core and frontend, to give people a basic choice, in the early days of HA im sure they edited in VI etc. OR, there favorite editor, maybe GUI based, and “pasted” or transferred through SSH
Correct, long live C/P … or the fact that by a few click you can install samba-share, or SSH(w. SFTP)
PS: I and probably most people like the fact that when you edit a card, you see the result(most of the times) before you even save it, so you can keep “correcting” adding until it looks like you want, How on earth do you want to accomplice this on an external Editor ? , You don’t !, so we are back to Raw editor mode only.
As you sounds like an “experienced” computer user, with ability to write code, i have hard to understand how a few keyboard touch, can be such a pita for you, it’s done in 2-3 seconds
Beside, after you save it the first time ( on the Unit you edit from ) it’s there !, you don’t have to open the View, before you are done and want to paste/overwrite the old, there you saved 1.5 seconds, you can edit it how many times you want, without disturbing you HA instance.
As a bonus you got your self an extra backup
I’m reading that it is JSON internally → I’d also wish to be able to work with YAML anyway.
The problem is a classic legacy issue here I guess:
I don’t think there are technical benefits of the conversion
I assume JSON was first internally, YAML was added layer for the UI
To fix it:
Let’s imagine SFTP/Samba as yet another UI Well, we shouldn’t imagine: CLI is a kind of UI. Anyway…maybe the YAML file could get (re)generated/parsed/synchronised with the JSON file → so that people can edit the YAML file, while keeping the backwards-compatible JSON layer.
Or better: just get rid of the JSON layer at all, just use YAML internally as well.
The why(s):
would allow to use an editor of choice for YAML
I want to git-version-control: I’m not tracking the internal JSON file (yet) → I’d wish to track the user-editable YAML file
Well, not quite. It’s javascript code that exchanges with HA through http.
Might be hard to grasp, but the “file” (which is itself already a YAML representation of a JSON content, as said above) is not actually local at all. It is its http/css representation that you see in the browser, and there is no way to “open” that content in a local editor.
If you don’t grasp the difference, I understand your request, but it’s technically much more different than “the webui is just another editor”.
The fact that you cannot find a real-life example of an implementation of your request might be a hint, here
Bottom-line: We discuss all day, but the only actual option you have in the foreseeable future is Samba or SSH/vscode for actual YAML files, and nothing for specifically the dashboards source code (besides copy/paste in a better editor, which is what I do).
Basically, there is no YAML-file for the View/cards, and the “website(View), and cards” is highly build upon .js , which makes the under-lying .json a perfect fast and more secure choice, as it also have to communicate with a bunch or various API’s
I can agree upon JSON was “first”, and therefore long ahead in both the ability to fast parsing heigher security, better support for various languages etc, and as mentioned, Most API’s HA is communicating with are using JSON, for the very same reason, compact, fast and secure parsing.
Rebuilding the Whole underlying system And the external communication, seems to me like starting over from scratch, even thou one doesn’t “get around” the fact, that you have to build for communication with external JSON API’s
Think Again
I would say, Yalm was only added because of it’s easy to read and write structure, for configuration files ( that basically wha it’s current good for ) You have to convert it ! , into i.e JSON, and the “stuff” eventually have to end up in a HTML/.js combined webside
So what you see in Raw Editor mode is basically just an .js editor, which convert the JSON into Yaml
Beside it’s more or less the only “file” ( you guys want to rebuild the whole system for )
You can access all other yaml-configuration files And.js files etc. through ssh/ftp/samba-share, That is The Way most/all system-administrators access their web-server, if not working locally in the serveroom ( read your comfy couch, or fav. chair )
More over there are a “fully featured” Add-Onn
" Fully featured Visual Studio Code (VSCode) experience integrated in the Home Assistant frontend " , beside the basic options mentioned above
Then UI configuration was added (basically, the .storage directory, where UI-backed dashboards actually reside) and JSON was choosen as its supporting format, for whatever reason.
I’d say, not a big issue. If you want to keep JSON at the backend, and want to present YAML for the user → you just convert JSON->YAML. And they do.
U’re saying they do that at the client side (js: in the user’s browser) → the solution would be to do it on the server side (python [?]: in the HA Core [?]; node js [?]; I haven’t read the internals yet; whatev). This way it could be available for both the Lovelace UI and anything else.
I’m starting to think you don’t know what you’re talking about. JSON and YAML are just data formats, serialization formats → there are no “security” differences between them.
Unless you know some security issue with YAML specific to HA’s parser implementation, then it would require an immediate fix, but in general there shouldn’t by any.
hey, it’s a big one. I’d guess about half of the “code” generated by the user is the Lovelace configuration (the other half being automations, etc). So you’re saying I’m only allowed to edit / version control only half of the stuff I want, not “just one file”.
BTW, same goes for example to Helpers created in the UI → they are also JSONs in the hidden storage. Same issue.
Yep, I’m mounting HA’s filesystem via SSHFS and edit configuration.yml etc using PyCharm.
Yep. But again: not for the lovelace/helpers/i_dont_know_how_much_more - as it is JSON and “internal .storage”.
And I’d have to open the web page with the addon every time I want to change something, which is slow to me. My PyCharm IDE is open 24/7
Well, we shouldn’t imagine: CLI is a kind of UI. Anyway…maybe the YAML file could get (re)generated/parsed/synchronised with the JSON file → so that people can edit the YAML file, while keeping the backwards-compatible JSON layer.