#GlassHome: An ESPHome visual editor (Concept)

1 messages · Page 1 of 1 (latest)

abstract path
#

I am new to esphome and I love the versatility of yaml. But I feel I am lost in the endless possibilities having to dig deep in the docs. That can be a bit confusing for a beginner. So I toyed with the idea of a visual editor and made this concept.
Let me know if it makes any sense and if you think I should pursue it any further. If so what feature do you really want to see?

PS: got inspired from this github issue https://github.com/esphome/dashboard/issues/16
PS2: This was originally posted on reddit https://www.reddit.com/r/Esphome/comments/1m49pti/a_visual_editor_for_esphome_concept/

Screenshot_2025-07-20_123123.png Screenshot_2025-07-20_123134.png
zenith monolith
#

look nice

#

how does the cards field are populated ?

#

from esphome source or you have to update all fields each release ?

abstract path
# zenith monolith how does the cards field are populated ?

@zenith monolith For now it's manual. Just for the concept. But it should tie to the actuall code. I am still going through and trying to understand where these "definitions" come from. If you have any pointers I would appreciate it. That way I can fetch the files and automate it. Or maybe add a pipeline to the esphome release that publishes the definitions as JSON Schema's on the website for 3rd party tools. Ideas are endless, but I need to find the code first.

zenith monolith
#

you can parse config schemas from component python code, but that would need to fetch each other component they extend

#

that would be a nice thing, can definetly comes out from concept to real software

#

i can try coding something that generate a big json from esphome source if it helps

#

i already have some feature requests x)

abstract path
#

That would be amazing. Python is not my strong suit, I am more of a typescript dev. I can consume JSON very easily.

zenith monolith
#

you would need also way to fetch and parse external components on the fly

#

how the backend is done? node?

#

or ists just front for now

zenith monolith
abstract path
# zenith monolith how the backend is done? node?

Yes. Well I have a Backend For Frontend (as I am using Nextjs to make my life easier). But fetching the json can be done on the frontend when the app is opened and as long as the structure is consistant it shouldn't break the UI

zenith monolith
#

you need a way to do it dynamically if you want to support external components

#

the backend would need to clone github repos

#

and running something that generate and cache the json files upon a component/components folder

abstract path
#

Oh external components is hard. because it's scattered. But the esphome builder already validates the components so it must fetch that from somewhere

zenith monolith
#

yes its using git

#

the tool generating the json config schemas must run using all local cached folders, both from esphome components one + git fetched external components. but its same principle

elder bolt
zenith monolith
#

since when ? x)

elder bolt
#

The vscode extension and the esphome builder editor uses files hosted here

#

there is one for every component and they are published on every release

zenith monolith
elder bolt
#

github actions

zenith monolith
#

perfect

#

we could use same action while fetching external component repo i guess

elder bolt
#

An external component would need to provide that json file somewhere for it to work

zenith monolith
#

we could checkout that repo to one with the action and run it locally?

elder bolt
#

Its just runs a script in the esphome repo
python esphome/script/build_language_schema.py --output-path=./schema

zenith monolith
elder bolt
#

I think dont focus on external component though to start, there is way more work that would need to be done first before trying to support anything external

abstract path
# elder bolt <https://schema.esphome.io/2025.7.0/switch.json>

Perfect! Exactly what we need. Now I have a versioned endpoint I can hit. Simple and elegant. Do we have a Schema somewhere that dictates the JSON structure? so I can parse it for my code making sure the UI dones't break. Important in the case of external components

elder bolt
#

Once one exists we can make sure we follow it and/or keep it updated

abstract path
#

That's alright. I can do that much. Would be a win for the ecosystem already

zenith monolith
#

one other thing i'm thinking about is cluttered config files + templating

#

do you plan to handle them ? and also config importing ?

#

(now with jinja2 configs are more and more complicated to parse)

elder bolt
#

@glmnet has done all of the work on the schema stuff and built the extension etc

zenith monolith
abstract path
#

Templating yes, and a million times yes. I want people to be able to search hundreds of templates and get inspired. Take them, expand and share again. Not sure what you mean with cluttered config?

zenith monolith
#

config using packages

#

(multiple config files)

elder bolt
#

Don't bombard the project with so much to start, let it get started properly first. Extra features come later

abstract path
elder bolt
#

Cool

#

So yeah as the commentor on Reddit were pointing out (quoting my actual messages on another post) we use Lit elements for the builder.
I'm not a frontend person myself, but it would be great to keep the same framework so it can integrate well and be maintained by the same people without learning something new

abstract path
#

If I figure the stuff with the JSON soon maybe I can share a beta next week. Maybe @robust bolt can chime in and let us know the best way to use the existing resources

zenith monolith
elder bolt
#

Ok, now I must try sleep...haha

abstract path
zenith monolith
#

i can help with lit. its a simple framework pretty easy to get if you come from vue or react world

#

you won't be lost

#

to get used to it you can look at esphome-webserver sources or builder one

#

its also using lit

abstract path
#

Nice work man!
But the problem are the nodes and graph structure. In react thankfully there are so many libraries and documentation. I can also make the UI very pretty quite easily. It's the most used framework afterall. But the simplicity of Lit makes something this complex a bit too complicated. I am not looking into developing a node graph ui library from scratch honestly. That alone would take months to cover all edge cases and features. I found one library that does that but sadly it's poorly maintained and doesn't have the features I need.
If I use technologies I know I can actually publish this next week. But with another tech stack especially with lit which is very barebones. It will take months. Sadly this is a complex use case not like the ones ESPHome had to deal with so far.

zenith monolith
#

yes i was struggling about component libraries too

#

i did use shoelace but i wasn't able to make everything i wanted with

#

but dependencies in web dev is hell

#

less librarie you use, less broken stuff you have to deal with ^^

abstract path
#

It would work but sadly the simplicity catches up to you as soon as the apps get complicated. I do this for a living and used many frameworks on an enterprise level. My spider sense is telling me Lit is sadly not the right choice from what I have seen so far.

zenith monolith
#

but i understrand its better to use already existing stuff for quick releasing a poc

#

well lit is just html components

abstract path
zenith monolith
#

its like the jsx part of react or .vue files

abstract path
zenith monolith
#

it doesnt replace backend stuff

#

but just rendering stuff

#

you can use lit components with next (and any other framework)

#

(if you wanna try someday)

zenith monolith
#

from static html project to next/react/vue and so on

abstract path
#

Yup I see. It's really cool stuff! Will see what I can come up with

zenith monolith
#

(yes dont focus on that for now. was just explaining lit ^^)

robust bolt
#

Hey there

This is going to happen sometime yeah. For the gui myself would love to have something that is continuously on sync yaml an gui as the visual editors of the ha dashboards are, or how the automation editor works.

But connecting lines are also cool. However i only once used nodered and found the generated json unreadable. Mostly maybe because of it needing to store arrow positions etc. it’d be interesting to see how that would work.

In the other hand the schema project is quite old but I guess unpopular. Just recently Jesse help to make it realase on actions

For schema on the schema there is none but should be doable a json schema as it is generated with a tool not manually

It is generated first from the esphome code base and then
The schema also contains documentation which is pulled from the docs website

The vscode extension repo has some types that use it. (Typescript) There are functions that will tell you all properties of a component (by iterating its parents too) is quite ugly code there and not performant but works.

May be we can come with a base lib to share here between the vscode and some gui The objectives are quite similar

#

Ohh also be cautious on the tooling. If you’re not picking lit or anything the foundation wants be sure to have their blessing first or you’ll hit a wall later

abstract path
abstract path
# robust bolt Ohh also be cautious on the tooling. If you’re not picking lit or anything the f...

Absolutely, I am playing around with lit. It's amazing and I see why it has been chosen. Just at first glance I am not finding the tooling or ecosystem I need to build the complex graph UI. Once I wrap my head around it I can make an actual recommendation or proposal and whether I am capable of solving this use case with lit.
For now I will invest effort in component schemas as we all agree on that and then have a chat with the fine folks at esphome and the foundation to actually plan this out in a meaningful way.
Hope we can coordinate this into something awesome! 😄

And thank you @robust bolt for taking the time to pitch in!

elder bolt
#

The entire home assistant UI/frontend is built with lit, so you must be missing finding something

trim jewel
elder bolt
#

There are some simple interactive graphs for things like the bluetooth / zigbee / zwave maps

#

I dont know how they are written though

trim jewel
#

Ok. I haven't used those parts.

elder bolt
#

Might be using this

#

I dont know that that helps with this prohect though

#

haha

#

Like, there is nothing wrong with using other libraries inside it to produce parts, just saying that if as much as possible is done with lit, it makes integration and maintenance easier

zenith monolith
#

to represent hierachical stuff from component to other

#

not easy to make those components ^^

elder bolt
zenith monolith
#

theirs graphs are not dynamic

elder bolt
#

Im only providing what I found from the HA frontend, I am not a frontend dev so no clue about its capabilities

cerulean silo
abstract path
#

Hey @elder bolt, as@zenith monolith pointed out I meant node-based graphs and not statistical graphs (charts). I attached a functional demo. That behaviour of having a canvas, connections points and so on is quite complex. I am using a library for that https://reactflow.dev/. It makes such a complex use case quite possible. I searched last night for a counter part in lit which would enable this. I stumbled upon an example from 4 years ago https://github.com/rodydavis/lit-node-editor. It might be a good starting point but I would rather use a library. Before promising the community to build it in lit, I need to be sure that it is possible (with my skill level). So I am still looking.

if we can't find a viable way to build this in lit. We can at least try to finish it in React. That way I can guarantee finishing and maintaining it + writing documentation and everything in between.

cerulean silo
#

i have been thinking of doing something similar based on blocky (scratch).

elder bolt
cerulean silo
#

yeah, i could not see how it should be used with EspHome.yet. It could be suitable for HA's automations maybe. replacing the need of Jinja as well.

astral shuttle
#

Impressive first preview result

#

can we expect also to work with "packages" ? (and associated vars)

abstract path
#

If you mean external components then yes. I want to support them no idea how though, Will come later on. But I am not exactly sure what you mean, as I am still fairly new to esphome

pearl cedarBOT