I would like to announce that I just published ESPHome Web App (ESPWA), a Progressive Web App (PWA) and it’s underlying library ESPHome Web JS.
The ESPHome Web App (ESPWA) is a Progressive Web App (PWA) designed to streamline the setup, configuration, and control of ESPHome-based microcontrollers independently, without requiring additional infrastructure like an ESPHome or Home Assistant instance.
Running directly in your browser, ESPHome Web App operates locally and can even function without an internet connection once cached. Its only requirement is an active ESPHome web_server component for communication with the ESPHome MCU.
While ESPHome and Home Assistant are indeed powerful tools for managing ESPHome-based microcontrollers, they often necessitate additional infrastructure like a Raspberry Pi or Home Assistant color hardware. ESPHome Web App fills the gap by enabling provisioning*, configuration, and control of ESPHome devices in locations where such infrastructure might not be readily available, such as caravans and trailers, corporate offices, coffeeshops or other remote settings.
Moreover, for Makers seeking to offer customizable and user-friendly UI for their products, ESPHome Web App provides an accessible and customizable solution. It allows users unfamiliar with Home Assistant or ESPHome to interact with devices seamlessly without additional resources having to be diverted to app or other development.
I dont really understand how this is different than just using the esphome web_server through a browser. It kind of sounds misleading too. You still need to setup web_server on the esp, they also need to program something on the esp or they’re just going to be interacting with a blank screen and a log output.
Did I miss reading somewhere that you can configure gpio’s and create esphome entities like lights(pwm) switches, etc from this app and actually dont need esphome? Unless i missed all that, it kind of sounds like that raspberry or other extra hardware is necessary after all.
Most people usually figure out within the first week of using esphome that its very capable of running solo and doesnt need a HA instance. Just add the web_server and go visit the board and toggle switches or turn on lights and read sensors. You can do that already.
I suppose if you flashed a board and made a project for someone, that person wouldnt need the hardware but, how is this different than just connecting to the esp via web_server over the browser thats already available.
Im not trying to be a dic* or anything, i couldnt build this. Its cool, i just cant figure out how its not the same as accessing it over a browser like you can now.
Yes, you are right. It requires web_server and uses it under the hood for communicating with the device. But for the end user it provides an improved user experience compared to the built-in UI and for makers it gives the possibility of easy self-hosting, customization, and branding. Which might not be particularly exciting for end users, but are really valuable for people building and distributing their own ESP based devices and products.
But even for end-users there are benefits over the built-in UI. Unlike with the user interface of the built-in web server you can have all of your devices in one place, connect and disconnect easily from them with just a tap, don’t need to remember IP addresses or host names every time you want to connect to them and the ESPHome Web UI has an expanded feature set over the built-in one. E.g. you cannot set light brightness or color from the built-in UI. Also upcoming are the ability flash a firmware binary (with serial even to an unflashed, virgin ESP) and the ability to provision WiFi using serial or bluetooth (also still work in progress). Neither of those are possible or even theoretically possible using the built-in web_server interface.
Just to be clear: the purpose here is not to replace Home Assistant or ESPHome installations. And in many cases the built-in UI of web_server is absolutely sufficient. But there are use-cases out there in which those are not readily available or meeting the requirements. The purpose is to provide an app-like experience for those scenarios which makes it easy even for non techy end-users to setup and interact with ESPHome based devices.
You may not have those use-cases or are in the target audience, but that is absolutely fine. Doesn’t make you a dic*. Fair questions. Thank you for asking them!
You make some good points. I didn’t play with it long and didn’t realize you can have all devices in there. Are they stored like a history whenever you connect to a device or do you manually create your list? Having a list of devices to choose from, that alone is a flipping awesome feature that webUI doesn’t. I guess you could create a folder in favorites, then put the devices in there but, I kind of like your way better for that.
Im kind of confused about what you mean about not setting light brightness, color, etc over the built-in one. I have brightness controls, can select effects and you are correct, it doesn’t have color select by default but, it wouldn’t take much to create an input_select to set colors.
The upcoming features really sound nice!
I do see now, the people/market with special needs or use cases and how this fills that void. That makes more sense because I was sitting here scratching my head and thinking, “it’s basically the same thing” lol
I actually do like it and I like it more after you explained it in a way that slow people like myself can understand.
I hope you don’t take my comments as negative or rude. I can be a little abrasive sometimes, i’ll admit that but, it was only me not understanding fully and some good old fashion constructive criticism.
It’s people like you that invest your time and skills to create and improve the things myself and others use and enjoy and you give it away to the community. I appreciate what you have done here, Thank you.
An improved web interface for ESPHome devices would be a great thing. But you imply there’s more to it than that. Multiple ESPHome devices on the same browser page? That’s going to require a back end. Who provides that? Or is it some peer-to-peer thing?
Also, didn’t I read somewhere that ESPHome devices reboot if they lose connectivity to HA? I assume there’s a way to turn that off. Or maybe I imagined the whole thing. I can see myself wanting “standalone” ESPHome devices for various projects which don’t really need HA, but I haven’t really looked into that yet.
It doesn’t really require a backend, at least not in the sense you’re probably thinking. The backend in this case is your browser. Modern browsers have a lot of technologies that makes it possible to persist data locally and across sessions. This is what I am using to store the list of hosts you add to the web app. No (remote) backend involved.
You are also correct that ESPHome reboots the device if it doesn’t receive a HA connection. This is something you can disable in the firmware if you desire. But also don’t expect that to cause a lot of real world problems. The web app will just transparently reconnect to the ESP upon a loss of connection.
If it turns out that ESPHome reboots are causing problems I would probably submit a patch to ESPHome to disable the reboot while a HTTP event stream persists. I believe the reboot is meant to remedy Wi-Fi connectivity problems and an existing HTTP event stream indicates that Wi-Fi connectivity is present and good, similarly to how an active HA connection does.
Its kind of bugging me since you brought up. I dont do a lot of colorful lighting and the little i do, i dont use the web_server to access the settings. I could see that being really annoying to someone that does and i cant figure out why they wouldnt have included a way to change colors. I woildnt expect something fancy like a pixel wheel but, it seems like thats a pretty big oversight to not have that option. Am i missing something here?
Yes, your are right that brightness can be changed in the existing UI. I got that wrong. I am not entirely sure why no UI for changing color or color temperature exists in the web_server UI. In software projects there are typically a couple of possible reasons why a feature doesn’t exist.
It’s an oversight by the developers.
It’s not economical (i.e. cost/benefit tradeoff is not good)
It’s not relevant to/demanded by users (which is really a version of 2)
It’s not useful to the developer themself
Point 4 only really exists in open source and maybe to a lesser degree in internally developed commercial tooling (i.e. the developers writing the software are also the ones using it), but especially in open source, where the existence of features often depends on someone putting in their free time to build out those features, features will only exist if one of the developers had a personal need for that feature.
It could be as simple as that the developer writing the web_server UI just didn’t have any colored lights and didn’t have a need for that UI. Or they didn’t think it would be useful for users. Or the effort for building a color selection UI was too high for the expected benefit. In the end though, you’d really need to ask the folks who wrote the web_server UI why this is not something they included.
This is excellent, thank you! I’ve looked for something like this many times so I’m glad to see someone has started building it.
My ESPHome IR controller doesn’t have its Climate actions exposed in ESPLink.
Any chance support for climate components could get added in?
A few extra big wishlist feature requests
Ability to rearrange devices list.
Grouping capability where I can turn on and off multiple ESPHome devices at once
Set and edit on/off timers (maybe not possible unless ESPHome device is configured in a certain way?)
A native Android app (similar to Tasmotrol)
Scan local network and auto-add in all ESPHome devices
Quick actions such as power toggle available directly in the title bar of the device. Thus you could power the device without expanding it to see all the options.
Remember if a device is expanded or collapses and save it to cache.
Display devices in a grid format on larger screens
climate entities are indeed not implemented. I’ll make sure to fix that with the next release.
Your list of suggestions is great. I will certainly make sure to add some of those as soon as possible. <3
In regards to a native Android app, you should be able to install the app as a Progressive Web App on Android and use it from your home screen as well as offline.
Auto discovery is something I would love to build but I’m afraid is not possible using web platform APIs.
Great project! I like it. If the intent is not to use HA for some devices, then do not add the api: section to the yaml. That’s what is causing the reboots since it keeps trying to reconnect to the HA instance. You can happily use mqtt or just the web_server api (which uses events). Note though that the web_sever api does not provide encryption like the default HA api: function. Please note also that there is a serious flaw in the espasyncwebserver back end used for the web_server. It will intermittently reboot due to heap corruption depending on traffic. This is a known flaw and no fix is available as far as I know.
Let me also add a use case. You want to install some esphome smart devices at your parents/inlaws/friends/etc place to control/monitor some things but don’t need a full blown HA setup. Just a couple devices and the web_server component and easy peasy. They can then control their own systems simply.
I also get the “something went wrong” most of the time. Sometimes I get an error because my ESPHome devices don’t support SSL, but switching to “unsecured” doesn’t work either. One time it worked for some reason. It looked great. Until I tried to add another device. I haven’t been able to replicate that using Chrome or Brave browsers in Windows. But no rush, I can wait until the bugs are worked out.
Oh no! Would you mind sharing what browser you are using (including version)? Also, please feel free to report any bugs you encounter in the Github issue tracker.
Thank you for reporting. What browser are you using?
If it did work once, it may not be a browser support issue. Sometimes (as some others have already pointed out in this thread), the web_server component can cause the ESP to crash. Especially if there are multiple event stream connections at the same time. I could try making sure your desktop browser is no longer connected before connecting with your mobile phone. That might work more reliable for you.
Let me know if that works better and I will add a note to the documentation explaining this.
This is really the main use-case I had on my mind. I’m thinking of it more as “device distribution” (i.e. the person building the device is not the user of the device and vice versa), but I do care strongly about both the commercial and the non-commercial use-cases (the latter being essentially what you are describing).
Edge 121.0.2277.105 here on OnePlus 8pro with Android 13.
Could my privacy settings (tracking, cookies, do not follow, advertising blocking,…) be too restricted?
I would love to use bonjour/zeroconf/mDNS to do device discovery, but the web platform does not provide any APIs to use them. There was a specification draft a few years back that was proposing exactly this, but it got axed in favor of the Second Screen Presentation and Remote Playback APIs. These are not really suited for our use-case.
I kinda hope that once Private Network Access Permission Dialog fully ships and becomes more widely utilized by projects like this, that some of the groups within W3C recognize that having some form of MDNS/bonjour/zeroconf for generic HTTP service/device discovery is something that would be complimentary to PNA Permission Dialog and possibly revisit the discovery API or something like it.
