Launch external editor for YAML files

[boheme61]

@DvdNwk

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.

Yes that is what “they” do, in raw editor-mode

@DvdNwk

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.

Think what you want, but we are talking about “average” people editing editing, and doo to the flexibility of Yaml, it could be (actually does) causes i.e crashes of the system, people who can’t start their system, and even possible to create vulnerabilities, so it’s a wise thing to keeping it to JSON( beside the performance benefits ), in the back-end ( Having YAML in back/front-end( for other than simple config-files) is " not allowed commend here ! "

@DvdNwk

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”.

Right, i do have a “view” over 2000 rows ( so i do wish for a “search-box in header” of raw-editor-mode )( even thou i have all my views/cards externally(yaml) from my first HA(2021) until now ( however the “version control” is limited to “sort in order#created” )
My Version-control does not occur in my HA-system, it’s resides on external device ( Where do you have your “version-control” ? )

@DvdNwk

BTW, same goes for example to Helpers created in the UI → they are also JSONs in the hidden storage. Same issue.

True, this relative new feature, could need an “improvements” which i think eventually will come ( there has been some already, since it’s resent “birth” ) however as they mostly are “templates” it does fit better in JSON format, i.e do the better performance

@DvdNwk

But again: not for the lovelace/helpers/i_dont_know_how_much_more - as it is JSON and “internal .storage”.

Yes as above, and .storage can be a “dangerous” place to open(lock) files in external editors ( absolutely not recommended !) , it’s a little cumbersome to edit i.e device-registry etc. when / if that is needed, but again, keep in mind the system is intended for a wide “audience” , which files do you suggest should be easy accessible/editable for everyone ?, with the impact this can (Already) cause ?

@DvdNwk

And I’d have to open the web page with the addon every time I want to change something, which is slow to me

No you don’t you open/access your shared folders(samba), from/on your “working device”( where you have your external editor) 24/7
With i.e winscp(configured to use your "external"preferred editor), same, a double-click on your desktop 24/7, over secure SSH, from anywhere
( ps: i know you don’t keep your “version” control on your HA-Unit , meaning you are working on another device, where you have your preferred editor, if it doesn’t support converting YAML to JSON, use an online tool

Don’t feel pity, because you have to RAW-edit your view in a basic editor, on the HA, when you have multiple options, probably a majority of the user-base, avoid even raw-editor, because they don’t have the knowledge that many others have when it come to programming/editing

So as you self mentions, there are options(several), and as long as My system is function, i could care less, how it’s build, as long as the devs to some extend have it’s wide user-base, and security/stability in mind( which i have the feeling that they do their best to )

Yes, im still “confused”, you, or in specific brianj don’t want few “enhancements” in the “raw-editor” mode , however you do want to edit yaml , from/on an external Device and external Editor
How ever you “bend” it, there needs to be some kind of “communication” between the HA’s web-UI, HA’s Front-end, and Core, and a “Secure” such, which there are already several options for.
Yes you need “credentials” , verification, to access the HA resources, your personal linux/windows(external editor) account, don’t make it through, unless you have configured an i.e Integration/add-on. ( you even have to lock in(with your HA-admin-account), from your external browser, to be able to edit “locally” )
And please don’t suggest a builtin-option, where anyone, from their random “preferred” phone-app/windows editor, should be able to just click/touch( double-tap ) to access your (secure) homeautomation/web-server, with the , interference, lock of files and vulnerability, this in any ways will implies
Many people find the need, and there are some viable options, yet another integration/add-on could be yet another option … And that is actually what OP’s “request” is, " yet another option "

True, would be convenient ( skip basic-file-editor, skip-ssh/ftp/samba/VS-Code-Editor, skip-raw-editor-mode , because what people want is YAML-only( no matter the under-lying factors ), and just a button " Open External Editor ", i think most people can relate to that is a “simple/easy” solution

[DvdNwk]

@boheme61

Where do you have your “version-control” ?

cd /homeassistant && git init

@boheme61

better performance

I don’t think having to parse YAML vs having to parse JSON would be any kind of performance bottleneck.

And if it was a slight issue, there’s always caching for the rescue (and sometimes more problems ).

@boheme61

which files do you suggest should be easy accessible/editable for everyone ?

I don’t know about the files → I haven’t got into the internals that much yet.

For me personally: I’d love to have everything managed by configurable and git-trackable config files.
Most importantly, as I’ve already mentioned: the Lovelace config and Helpers.
But eventually anything else: installed integrations, General->Settings… anything that I change with my mouse on the Web UI, I’d like to see in my version control tracking.

The end goal being: if I want to configure a new machine hosting HA, I’d just git pull && reboot.
If I want to get back to any kind of historical state of HA, I’d just git checkout <revision> && reboot.

But that’s most likely if I were living in a dream world → as more and more is pushed towards Web UI → even things that used to be YAML–configurable, they are not anymore…

@boheme61

ps: i know you don’t keep your “version” control on your HA-Unit

I do: see above I back it up to github, but I edit the configs / git commit “directly” on the HA–Unit (“directly” in quotes, because – as I’ve mentioned before – it is actually via SSHFS lets say “tunneling”).

[boheme61]

@DvdNwk

For me personally: I’d love to have everything managed by configurable and git-trackable config files.
Most importantly, as I’ve already mentioned: the Lovelace config and Helpers.
But eventually anything else: installed integrations, General->Settings… anything that I change with my mouse on the Web UI, I’d like to see in my version control tracking.

I guess HA-OS is not your preferred install, sounds like you need Supervised, or Docker

And yes, i would also love to easily be able to poke around everywhere, but i “felled” back into HA-OS quite quick, do to stability/easiness

[DvdNwk]

I’m using HAOS. I may try Docker in the future. But that’s a sidetopic to a sidetopic

[boheme61]

Is it ?, both you and OP could use your preferred editor, with another HA install Type, and easily gain access to the whole “packet”, for editing and version control

[DvdNwk]

AFAIU, OP is wishing for a WebUI button that would launch edit YAML with a preferred editor on their (client) computer.

There are a few mixed issues here:

• editing YAML config files in a preferred editor – SSH/Samba access solves it → no need for changing HAOS to let’s say Docker
• Lovelace config being actually JSON translated to YAML “temporarily” in the Web UI – neither SSH/Samba nor Docker solves it
• what the OP wants → for me not exactly what I’d like to use, but a step forward, if I can’t get lovelace YAML via SSH would allow to edit with a preferred editor, but still lacking version-control tracking (unless i’d track internal JSON files)

[boheme61]

@DvdNwk

(unless i’d track internal JSON files)

Yes that is what you should do, and ofcause not only, i even edit some “plug-ins” like cards ( .js ), so what ever filetype you want version control on please do.

With HAOS, your can easily track everything under /config (/ homeassistant ) , that include all Custom-Component(integrations) and custom-cards, beside the .json in .storage.
Most add-ons config-files your need i.e Advance SSH Add-on to access, as they are in separate Docker-containers, you find your config-files for i.e add-ons under /supervisor.

Basically you installed a server build on python, using json, js and yaml (most likely for easy readability ) but that’s not for the functionality ( it’s just config-files )
You are asking for a rebuild of everything, every integrations you want to use yaml, and every add-on also, etc. , and easy access to everything , from external source/editor( Will never happen with HAOS !)

You and OP should consider optional install-type, supervised/docker, and get use to edit json ( and hope for a “costly” workaround for i.e dashboard etc to intermediate storage in yaml-file-format, as for i.e automation.yaml etc )

That is a “hard” one even to discuss, for people who don’t “create/contribute” to this open source platform, even more because it involves all components( you want file-versions on, and in yaml format ), native as well as custom

I don’t know why i even commends on this topic, as im sure even OP knows, he want external access to another OS/Server/front-end without any form but a click on a button, to launch his external file editor, And no “new inventions” … well beside you actually wants to access a secured server, Externally, with no flaws

[petro]

@DvdNwk

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

They do not. What you see in the frontend when you click edit in yaml is serialized objects. It’s not actually yaml. There is no conversion that’s done.

[koying (Chris B)]

@petro

What you see in the frontend when you click edit in yaml is serialized objects. It’s not actually yaml. There is no conversion that’s done.

Not sure what you mean. They might be serialized object, but they are definitely serialized to YAML (and serialization is a kind of conversion, code is used to generate that representation).

[boheme61]

I wouldn’t call it YAML, but it’s structured to present a YAML-alike-document, and it’s not an entire “yaml-file” you are editing, but trunks(a “window” as large as your view-height) picked from the JSON , every-line in it’s own numbered class
( So it seems to me )( but yes the editor “interpret it as yaml-language” , so the JSON is “converted” in the memory, while editing, the editor doesn’t “open a yaml-file” and doesn’t save anything in yaml-format

[petro]

@koying

Not sure what you mean. They might be serialized object, but they are definitely serialized to YAML (and serialization is a kind of conversion, code is used to generate that representation).

The difference is that it’s not using a json to yaml converter. The objects themselves have a serialization and there’s limitations to that serialization. If the object itself does not offer serialization, you’ll get [object Object] in the spot that the ‘yaml’ is. It’s an important distinction because it’s not actually yaml, it’s object serialization made to look like yaml.

There’s also limitations because each object itself is serialized instead of starting at the ‘total json object’ and traversing nested items.

So all these posts in this thread talking about json to yaml conversion are making the assumption that this is happening when it’s not happening.

[koying (Chris B)]

@boheme61

I wouldn’t call it YAML

Why not?
Copy the content of the text area an put it in a YAML validator. All OK…

[boheme61]

@koying

Why not?
Copy the content of the text area an put it in a YAML validator. All OK…

ehhh , right, and if i take a picture of a Porche, i see a Porche … That doesn’t mean there is a Porche engine below the hood, it could be pedals

[koying (Chris B)]

@petro

The difference is that it’s not using a json to yaml converter. The objects themselves have a serialization and there’s limitations to that serialization.

That’s semantic
Conceptually, serialization is “object 2 whatever” conversion. Whether the objects themselves do the conversion or some other functions is just implementation detail.
So, indeed, it’s not “json to yaml”, it is “object to yaml”, but in the context of the OP, it doesn’t matter.

@petro

It’s an important distinction because it’s not actually yaml, it’s object serialization made to look like yaml.

I don’t understand your point.
YAML is just a text format. If the serialization of an object passes a YAML linter, it is YAML. Same goes for JSON.

[koying (Chris B)]

@boheme61

That doesn’t mean there is a Porche engine below the hood, it could be pedals

What is YAML for you? YAML is just a file format, same as JSON.
You seem to put more meaning in “YAML” than I do

YAML

[petro]

It does not validate the yaml. There could be issues associated with it, hence the [object Object] which while it passes validation, will not pass HA yaml validation when put into effect. I understand you think this is semantics, but it’s not a conversion. It’s serialization. In the eyes of the user that doesn’t make a difference but in the eyes of the coder it means we now need to have serialization on all objects (even ones we can’t think of) which would completely break the frontend. There’s a reason the UI won’t work when you put in yaml that isn’t accounted for. It’s because these objects can’t be deserialized.

I’m just trying to clear up your miss conceptions. There’s very little chance that this request would ever happen because of this. The yaml editor field is specifically built to work directly with the objects HA uses. Replacing it with a normal text editor would not work without a significant overhaul.

[koying (Chris B)]

@petro

It’s because these objects can’t be deserialized.

That’s a real issue of course, but is not linked to the textual representation of the object (the serialization)

@petro

The yaml editor field is specifically built to work directly with the objects HA uses. Replacing it with a normal text editor would not work without a significant overhaul.

Sorry, but that’s just not true. The “raw configuration editor” of a dashboard is a plain text editor.
As mentioned above, what I personally do is the copy the content of that text area in another editor, do changes, then paste back.

Only when you press “save” is the YAML representation validated and de-serialized back in to a “dashboard” object.

[petro]

@koying

The “raw configuration editor” of a dashboard is a plain text editor.

It’s a custom text editor specifically built for frontend objects being treated as yaml

home-assistant/frontend/blob/d4d0fb2a034a9529a3a8ec0790085bc5ab2f7a1b/src/components/ha-yaml-editor.ts

[koying (Chris B)]

We’re definitely not talking of the same thing. The “raw configuration editor” is a plain ha-code-editor

home-assistant/frontend/blob/d4d0fb2a034a9529a3a8ec0790085bc5ab2f7a1b/src/components/ha-code-editor.ts

[petro]

That does the exact same thing with serialization of the objects…