raw_package/static/js/esphome.js is the legacy JavaScript file. Code in there needs to be refactored into Lit/TypeScript.

This issue is to track moving the LogModal class and all implementations that rely on it (install, logs, validate).

The configured nodes are currently rendered in index.html.template by the backend. They should be dynamically loaded via JavaScript.

1. icons not showing on the completions list, etc., 404 on codicons.ttf
2. hovers not showing at all, this includes docs and also errors
3. minimap not showing, not a big deal, most likely related to 2, seems like some parts of editor are not loaded

I've noticed that there is a WTH topic for dark theme: https://community.home-assistant.io/t/esphome-dark-theme/470927

I started working on this (I'm not a frontend dev) and I have something to start with:

My approach is to move most of the colors into variables and add prefers-color-scheme: dark override for those variables.
POC: Misiu@6c8b82a

Sadly, I lack design skills, so I'd like to ask @matthiasdebaat for creating a mock of the dashboard in a dark theme.
As @balloob suggested we need a mockup that shows how the dashboard should look and how a potential second view (list?) can look.

Operating environment/Installation (Hass.io/Docker/pip/etc.):

Hass.io
ESP (ESP32/ESP8266, Board/Sonoff):

ESP8266 (doesn't really matter)
ESPHome version (latest production, beta, dev branch)

1.19.2
Affected component:

Web GUI

Description of problem:
Since the new upload mode via Serial over the Browser, the Configuration isn't saved anymore when clicking on install which, for me, resultet in loosing my work I just made

Problem-relevant YAML-configuration entries:

PASTE YAML FILE HERE

Logs (if applicable):

PASTE DEBUG LOG HERE

Additional information and things you've tried:

The Install Choose dialog fetches the information about a configuration from the backend when it's opened so it can determine if the configuration is using ethernet or not. This information is only created when the configuration is compiled, and so it's not available for new configurations.

STR:

• Create new YAML file
• Open install dialog
• 500 error in logs

2022-10-19 12:08:05,607 ERROR Uncaught exception GET /info?configuration=picow.yaml (127.0.0.1)
HTTPServerRequest(protocol='http', host='localhost:6052', method='GET', uri='/info?configuration=picow.yaml', version='HTTP/1.1', remote_ip='127.0.0.1')
Traceback (most recent call last):
  File "/Users/paulus/dev/hass/esphome/venv/lib/python3.9/site-packages/tornado/web.py", line 1702, in _execute
    result = method(*self.path_args, **self.path_kwargs)
  File "/Users/paulus/dev/hass/esphome/esphome/dashboard/dashboard.py", line 136, in decorator
    return func(self, *args, **kwargs)
  File "/Users/paulus/dev/hass/esphome/esphome/dashboard/dashboard.py", line 161, in decorator
    return func(self, *args, **kwargs)
  File "/Users/paulus/dev/hass/esphome/esphome/dashboard/dashboard.py", line 779, in get
    self.write(DashboardEntry(yaml_path).storage.to_json())
AttributeError: 'NoneType' object has no attribute 'to_json'

Solution is to use the new json-config API from #338 to see if the ethernet component is configured.

Backend should also be updated to return a 404 and that should be handled.

Now that the dashboard has the ability to directly obtain serial logs, it would be awesome if it could also decode exceptions dumped to the logs.

This could be game changing to allow anyone to easily decode stack traces if they occur in their logs.

I can think of two methods this could be done:

1. Recreate this exception decoder in TS/JS and obtain the elf file from the ESPHome server to directly decode it.
2. Detect when an exception is dumped and pass it back to the esphome webserver for decoding.

Sometimes, it is helpful to have timestamps in the logs when diagnosing an issue.

When log output is shown, appending timestamps to the beginning of the line would be incredibly helpful. Perhaps a simple checkbox could also be added to enable/disable this feature.

After clicking on secrets editor, nothing happens

raw_package/static/js/esphome.js is the legacy JavaScript file. Code in there needs to be refactored into Lit/TypeScript.

This issue is to track moving the editor.

As title says: default tab length is now 4 spaces and thus many times unusable. Can it be reverted back to 2 ?

Hi *,

I have a K3s Cluster (v1.25.3+k3s1) with some RPi4b nodes and I want to run esphome dashboard on the cluster.

Deployment works fine, appliance discovery works fine, but when I try to compile via the dashboard to download it for USB upload, the wheel spins forever.
Here is my deployment yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: k3s-esphome-dashboard
  labels:
        app: esphome-dashboard
spec:
  replicas: 1
  selector:
    matchLabels:
      app: esphome-dashboard
  template:
    metadata:
      labels:
        app: esphome-dashboard
    spec:
      hostNetwork: true
      containers:
      - name: esphome-container
        image: esphome/esphome
        tty: true
        stdin: true
        resources:
          limits:
            memory: "2Gi"
            cpu: "3000m"
          requests:
            memory: "1Gi"
            cpu: "2000m"
        volumeMounts:
        - name: config
          mountPath: /config
        command: ["esphome"]
        # create secret!
        args: ["-v", "dashboard", "/config","--username","", "--password", ""]
      volumes:
        - name: config
          nfs:
            # URL for the NFS server
            server: 10.2.0.30
            path: /k3s_config/esphome

The pod produces the following output:

2023-03-08 19:56:42,565 INFO Running command 'esphome --dashboard compile /config/trv-lab.yaml'
2023-03-08 19:56:43,038 DEBUG > stdout: INFO Reading configuration /config/trv-lab.yaml...

2023-03-08 19:56:43,416 INFO 304 GET /ping (10.7.0.6) 2.86ms
2023-03-08 19:56:43,641 DEBUG > stdout: WARNING GPIO12 is a Strapping PIN and should be avoided.

2023-03-08 19:56:43,642 DEBUG > stdout: Attaching external pullup/down resistors to strapping pins can cause unexpected failures.

2023-03-08 19:56:43,643 DEBUG > stdout: See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins

2023-03-08 19:56:43,769 DEBUG > stdout: INFO Generating C++ source...

2023-03-08 19:56:44,925 DEBUG > stdout: INFO Compiling app...

2023-03-08 19:56:45,440 INFO 304 GET /devices (10.7.0.6) 24.82ms
2023-03-08 19:56:45,455 INFO 304 GET /ping (10.7.0.6) 1.80ms
2023-03-08 19:56:45,567 DEBUG > stdout: Processing \033[36m\033[1mtrv-lab\033[0m (board: esp32-poe-iso; framework: arduino; platform: platformio/espressif32 @ 5.2.0)

2023-03-08 19:56:45,568 DEBUG > stdout: \033[1m--------------------------------------------------------------------------------\033[0m

2023-03-08 19:56:45,577 DEBUG > stdout: Platform Manager: Installing \033[36mplatformio/espressif32 @ 5.2.0\033[0m

2023-03-08 19:56:45,579 DEBUG > stdout: INFO Installing platformio/espressif32 @ 5.2.0

2023-03-08 19:56:47,419 INFO 304 GET /ping (10.7.0.6) 2.08ms
2023-03-08 19:56:47,630 DEBUG > stdout: 
2023-03-08 19:56:47,631 DEBUG > stdout: \033[?25lDownloading  [------------------------------------]    0%
2023-03-08 19:56:47,633 DEBUG > stdout: \033[?25lDownloading  [------------------------------------]    2%
-----------------------------------------------8<-----------------------------------------------------------
2023-03-08 19:56:47,787 DEBUG > stdout: \033[?25lDownloading  [####################################]  100%\033[?25h

2023-03-08 19:56:48,026 DEBUG > stdout: 
2023-03-08 19:56:48,038 DEBUG > stdout: \033[?25lUnpacking  [------------------------------------]    0%
2023-03-08 19:56:48,049 DEBUG > stdout: \033[?25lUnpacking  [------------------------------------]    1%
2023-03-08 19:56:48,058 DEBUG > stdout: \033[?25lUnpacking  [------------------------------------]    2%
-----------------------------------------------8<-----------------------------------------------------------
2023-03-08 19:56:49,391 DEBUG > stdout: \033[?25lUnpacking  [####################################]  100%          \033[?25h

2023-03-08 19:56:49,419 INFO 304 GET /ping (10.7.0.6) 1.65ms
2023-03-08 19:56:50,100 DEBUG > stdout: Platform Manager: \033[[email protected] has been installed!\033[0m

2023-03-08 19:56:50,101 DEBUG > stdout: INFO [email protected] has been installed!

2023-03-08 19:56:50,126 DEBUG > stdout: Tool Manager: Installing \033[36mespressif/toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch3\033[0m

2023-03-08 19:56:50,128 DEBUG > stdout: INFO Installing espressif/toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch3

2023-03-08 19:56:50,429 INFO 304 GET /devices (10.7.0.6) 20.27ms
2023-03-08 19:56:51,421 INFO 304 GET /ping (10.7.0.6) 2.81ms
2023-03-08 19:56:53,421 INFO 304 GET /ping (10.7.0.6) 2.82ms
2023-03-08 19:56:53,592 DEBUG > stdout: 
2023-03-08 19:56:53,883 DEBUG > stdout: \033[?25lDownloading  [------------------------------------]    0%
2023-03-08 19:56:54,046 DEBUG > stdout: \033[?25lDownloading  [------------------------------------]    1%
-----------------------------------------------8<-----------------------------------------------------------
2023-03-08 19:57:52,779 DEBUG > stdout: \033[?25lDownloading  [####################################]  100%          \033[?25h

2023-03-08 19:57:53,436 INFO 304 GET /ping (10.7.0.6) 11.38ms
2023-03-08 19:57:55,431 INFO 304 GET /devices (10.7.0.6) 18.46ms
2023-03-08 19:57:55,445 INFO 304 GET /ping (10.7.0.6) 1.88ms
2023-03-08 19:57:57,438 INFO 304 GET /ping (10.7.0.6) 1.79ms
2023-03-08 19:57:59,256 DEBUG > stdout: 
2023-03-08 19:57:59,437 INFO 304 GET /ping (10.7.0.6) 1.74ms
2023-03-08 19:57:59,643 DEBUG > stdout: \033[?25lUnpacking  [------------------------------------]    0%
2023-03-08 19:57:59,899 DEBUG > stdout: \033[?25lUnpacking  [------------------------------------]    1%
-----------------------------------------------8<-----------------------------------------------------------
2023-03-08 19:58:11,760 DEBUG > stdout: \033[?25lUnpacking  [####################################]  100%          \033[?25h

2023-03-08 19:58:13,439 INFO 304 GET /ping (10.7.0.6) 1.93ms
2023-03-08 19:58:15,432 INFO 304 GET /devices (10.7.0.6) 20.62ms
2023-03-08 19:58:15,448 INFO 304 GET /ping (10.7.0.6) 1.59ms
2023-03-08 19:58:17,439 INFO 304 GET /ping (10.7.0.6) 1.82ms
2023-03-08 19:58:19,448 INFO 304 GET /ping (10.7.0.6) 1.84ms
2023-03-08 19:58:20,439 INFO 304 GET /devices (10.7.0.6) 21.37ms
2023-03-08 19:58:21,443 INFO 304 GET /ping (10.7.0.6) 1.67ms
2023-03-08 19:58:23,443 INFO 304 GET /ping (10.7.0.6) 1.80ms
2023-03-08 19:58:25,437 INFO 304 GET /devices (10.7.0.6) 20.44ms
2023-03-08 19:58:25,452 INFO 304 GET /ping (10.7.0.6) 1.65ms
2023-03-08 19:58:27,440 INFO 304 GET /ping (10.7.0.6) 1.56ms
2023-03-08 19:58:29,442 INFO 304 GET /ping (10.7.0.6) 1.66ms
2023-03-08 19:58:30,461 INFO 304 GET /devices (10.7.0.6) 17.93ms
2023-03-08 19:58:31,445 INFO 304 GET /ping (10.7.0.6) 1.64ms
2023-03-08 19:58:33,447 INFO 304 GET /ping (10.7.0.6) 1.55ms
2023-03-08 19:58:35,445 INFO 304 GET /devices (10.7.0.6) 26.74ms
2023-03-08 19:58:35,460 INFO 304 GET /ping (10.7.0.6) 2.66ms
2023-03-08 19:58:37,445 INFO 304 GET /ping (10.7.0.6) 1.76ms
2023-03-08 19:58:39,447 INFO 304 GET /ping (10.7.0.6) 1.57ms
2023-03-08 19:58:40,438 INFO 304 GET /devices (10.7.0.6) 21.62ms
2023-03-08 19:58:41,445 INFO 304 GET /ping (10.7.0.6) 1.49ms
2023-03-08 19:58:43,442 INFO 304 GET /ping (10.7.0.6) 1.67ms
2023-03-08 19:58:45,441 INFO 304 GET /devices (10.7.0.6) 21.23ms
2023-03-08 19:58:45,457 INFO 304 GET /ping (10.7.0.6) 1.67ms
2023-03-08 19:58:47,445 INFO 304 GET /ping (10.7.0.6) 1.54ms
2023-03-08 19:58:49,441 INFO 304 GET /ping (10.7.0.6) 1.73ms
2023-03-08 19:58:50,444 INFO 304 GET /devices (10.7.0.6) 23.04ms
2023-03-08 19:58:51,448 INFO 304 GET /ping (10.7.0.6) 2.22ms
2023-03-08 19:58:53,445 INFO 304 GET /ping (10.7.0.6) 1.76ms
2023-03-08 19:58:53,541 DEBUG > stdout: Tool Manager: \033[[email protected]+2021r2-patch3 has been installed!\033[0m

2023-03-08 19:58:53,542 DEBUG > stdout: INFO [email protected]+2021r2-patch3 has been installed!

2023-03-08 19:58:53,924 DEBUG > stdout: Tool Manager: Installing \033[36mplatformio/framework-arduinoespressif32 @ ~3.20005.0\033[0m

2023-03-08 19:58:53,925 DEBUG > stdout: INFO Installing platformio/framework-arduinoespressif32 @ ~3.20005.0

2023-03-08 19:58:55,435 INFO 304 GET /devices (10.7.0.6) 21.65ms
2023-03-08 19:58:55,451 INFO 304 GET /ping (10.7.0.6) 2.09ms
2023-03-08 19:58:56,055 DEBUG > stdout: 
2023-03-08 19:58:57,136 DEBUG > stdout: \033[?25lDownloading  [------------------------------------]    0%
2023-03-08 19:58:57,447 INFO 304 GET /ping (10.7.0.6) 2.04ms
2023-03-08 19:58:58,235 DEBUG > stdout: \033[?25lDownloading  [------------------------------------]    1%  00:01:42
-----------------------------------------------8<-----------------------------------------------------------
2023-03-08 20:01:30,736 DEBUG > stdout: \033[?25lDownloading  [####################################]  100%          \033[?25h

2023-03-08 20:01:31,471 INFO 304 GET /ping (10.7.0.6) 1.74ms
2023-03-08 20:01:33,476 INFO 304 GET /ping (10.7.0.6) 1.86ms
2023-03-08 20:01:35,454 INFO 304 GET /devices (10.7.0.6) 17.85ms
2023-03-08 20:01:35,485 INFO 304 GET /ping (10.7.0.6) 1.67ms
2023-03-08 20:01:37,485 INFO 304 GET /ping (10.7.0.6) 1.68ms
2023-03-08 20:01:39,485 INFO 304 GET /ping (10.7.0.6) 1.67ms
2023-03-08 20:01:40,456 INFO 304 GET /devices (10.7.0.6) 19.75ms
2023-03-08 20:01:41,486 INFO 304 GET /ping (10.7.0.6) 1.73ms
2023-03-08 20:01:43,488 INFO 304 GET /ping (10.7.0.6) 2.20ms
2023-03-08 20:01:45,477 INFO 304 GET /devices (10.7.0.6) 38.26ms
2023-03-08 20:01:45,494 INFO 304 GET /ping (10.7.0.6) 6.37ms
2023-03-08 20:01:46,957 DEBUG > stdout: 
2023-03-08 20:01:47,141 DEBUG > stdout: \033[?25lUnpacking  [------------------------------------]    0%
2023-03-08 20:01:47,313 DEBUG > stdout: \033[?25lUnpacking  [------------------------------------]    1%
-----------------------------------------------8<-----------------------------------------------------------
2023-03-08 20:02:43,312 DEBUG > stdout: \033[?25lUnpacking  [####################################]  100%          \033[?25h

2023-03-08 20:02:43,501 INFO 304 GET /ping (10.7.0.6) 1.97ms
2023-03-08 20:02:45,465 INFO 304 GET /devices (10.7.0.6) 22.58ms
2023-03-08 20:02:45,500 INFO 304 GET /ping (10.7.0.6) 1.85ms
2023-03-08 20:02:47,502 INFO 304 GET /ping (10.7.0.6) 2.23ms
2023-03-08 20:02:49,502 INFO 304 GET /ping (10.7.0.6) 2.24ms
2023-03-08 20:04:20,464 INFO 304 GET /devices (10.7.0.6) 19.60ms
2023-03-08 20:04:21,519 INFO 304 GET /ping (10.7.0.6) 2.48ms
2023-03-08 20:04:23,520 INFO 304 GET /ping (10.7.0.6) 2.95ms
2023-03-08 20:04:25,467 INFO 304 GET /devices (10.7.0.6) 24.73ms
2023-03-08 20:04:25,518 INFO 304 GET /ping (10.7.0.6) 1.85ms
2023-03-08 20:04:27,509 DEBUG > stdout: Tool Manager: \033[[email protected] has been installed!\033[0m

2023-03-08 20:04:27,510 DEBUG > stdout: INFO [email protected] has been installed!

2023-03-08 20:04:27,517 DEBUG > stdout: Tool Manager: Installing \033[36mplatformio/tool-esptoolpy @ ~1.40201.0\033[0m

2023-03-08 20:04:27,518 DEBUG > stdout: INFO Installing platformio/tool-esptoolpy @ ~1.40201.0

2023-03-08 20:04:27,522 INFO 304 GET /ping (10.7.0.6) 1.78ms
2023-03-08 20:04:29,522 INFO 304 GET /ping (10.7.0.6) 1.80ms
2023-03-08 20:04:29,919 DEBUG > stdout: 
2023-03-08 20:04:29,924 DEBUG > stdout: \033[?25lDownloading  [------------------------------------]    0%
2023-03-08 20:04:29,945 DEBUG > stdout: \033[?25lDownloading  [------------------------------------]    1%
-----------------------------------------------8<-----------------------------------------------------------
2023-03-08 20:04:30,292 DEBUG > stdout: \033[?25lDownloading  [####################################]  100%\033[?25h

2023-03-08 20:04:30,414 DEBUG > stdout: 
2023-03-08 20:04:30,420 DEBUG > stdout: \033[?25lUnpacking  [------------------------------------]    0%
2023-03-08 20:04:30,425 DEBUG > stdout: \033[?25lUnpacking  [------------------------------------]    1%
-----------------------------------------------8<-----------------------------------------------------------
2023-03-08 20:04:30,778 DEBUG > stdout: \033[?25lUnpacking  [####################################]  100%\033[?25h

2023-03-08 20:04:30,946 DEBUG > stdout: Tool Manager: \033[[email protected] has been installed!\033[0m

2023-03-08 20:04:30,947 DEBUG > stdout: INFO [email protected] has been installed!

Does anyone have a clue, what is missing?

Best,
Ck

Selecting "Show API Key" from this menu:

Displays this dialog:

I expected it to either fail with an error, or display a message that I have not yet set up an API key. Instead, it just looks like it hangs, because it never updates.

• Under api, I only have api: { password: "..." } in my config, and that successfully comes back from the json-config call.
• A javascript breakpoint shows this method executes, and (possibly?) results in undefined (based on the type signature)

  dashboard/src/api/configuration.ts

  Lines 82 to 87 in 8d0b3fe

  	export const getConfigurationApiKey = async (
  	configuration: string
  	): Promise<string | undefined> => {
  	const config = await getJsonConfig(configuration);
  	return config?.api?.encryption?.key;
  	};

• I don't know whether this._apiKey is updated or not

  dashboard/src/show-api-key/show-api-key-dialog.ts

  Lines 64 to 66 in 8d0b3fe

  	getConfigurationApiKey(this.configuration).then((key) => {
  	this._apiKey = key;
  	});

• if it is, and the value is undefined, this code looks like it would continue to render as 'Loading...'

  dashboard/src/show-api-key/show-api-key-dialog.ts

  Lines 26 to 27 in 8d0b3fe

  	${this._apiKey === undefined
  	? "Loading…"

I'm not set up for dashboard development (maybe I'll poke at it later), but I wanted to file the issue. I didn't see an existing Issue for this bug

Using latest Chrome / iOS / 2022.01-dev

If I edit the text of a config in the dashboard, I cant seem to zoom out / scroll down enough to get access to clicking the button.

This video is the only time I've been able to get to the buttons, and I'm not sure how it happened.
https://imgur.com/a/0RIkaXt

Please add the scroll ability to the config editor on mobile devices.
I understand that there is horizontal and vertical scrollbars, but using them is uncomfortable.

I think it would be awesome if, when a device is online AND an update is available, a single click upgrade button would be available.

This could be done by making the upgrade icon clickable or by any other indication that makes upgrading a single click away on my dashboard.

We are currently ignoring deprecation warnings so we could fix the build. We should address the issues instead.

Within each board group, the list of board should be sorted alphabetically.
The current implementation makes it extremely tedious to find boards that do not fall within the "norm" of traditional boards.
F.ex ESP-01s and the different Wemos boards.
Wemos boards are listed under Other ESP32s, where 2 of the boards are at the top, while you can also find others further down the same list.

Operating environment/Installation (Hass.io/Docker/pip/etc.):

esphome 19.2 and -dev

19.2 and -dev

Affected component:

Description of problem:
Clicking "install" does not save the current yaml in the same way that "upload" used to.

Problem-relevant YAML-configuration entries:

any yaml

Logs (if applicable):

logs not really relevant

Additional information and things you've tried:

There is a thread here https://community.home-assistant.io/t/esphome-addon-in-ha-not-autosaving-anymore/317278

Of course this may have been done with a reason, but needs a heads up for users who are used to the old behaviour, and may lose a lot of coding time.

Thanks for the addition of the new dashboard, the upload via local serial is amazing!
One small issue I found is that if OTA upload fails, it keeps the serial window up.
When I hit retry install, the pop-up for selection is hidden behind the console so I can't make a selection (I can see the background darken and it dismisses when I hit escape)
I need to close out of the console window and start install from the main dashboard because of this.
Thanks!

Dear Developers,

Would you mind changing the "Stop" button to "Dismiss" or something that is easier to understand for the user? Or maybe add some hover hint? Hitherto, I was unsure what happens when clicking it and was kindly informed at Discord that "Stop" will only stop the logging to the browser, while the ESPhome node will continue running.

Thanks for your consideration and my best wishes for you! 😃

Using the latest version of esphome (2022.9.2) and the latest version of Firefox (105.0.1) there is no Paste option on the context menu.
It's there on Chrome and Safari but missing on Firefox. I tried clearing browser cache but no luck.

Requires #7

ESPHome configuration files can offer dynamic node names using the name_add_mac_suffix option. These nodes should be shown in the dashboard (#7) and linked to the correct configuration.

Requires #6

We should have an option to show all discovered ESPHome nodes on the dashboard, even if we don't have a local configuration.

ESPHome devices have the board + platform in their mDNS data. This can be used to identify them to the user and allow creating a stub configuration.

This is an idea I've had for some time, but don't have the frontend experience for to implement.

Goal

Simplify config creation for beginners by replacing raw YAML with a GUI

Observations

• Big YAML files with indentation are daunting for beginners
• Simple Key-Value YAML without indentation is easy and beginner friendly
• More complex features like automations use very complex validation schemas internally - essentially impossible to dynamically generate HTML forms for all features
• ESPHome has good modularization, for example WiFi "config fragments" are independent of GPIO Switch fragments.

Idea

Create a GUI system with draggable config fragments where you can enter the per-component YAML.

Advantages

• Lots of YAML complexity gone - most config fragments will be easy key-value
• System would still allow 100% of more complex ESPHome uses with no extra effort. Like substitutions, automations etc
• Relatively simple implementation wise, frontend just needs to show editable cards, backend stores fragments on disk and "combines" them into a normal config datastructure. Mot backend parsing/validation logic can be kept.
• Incremental improvements possible, for example at a later stage simple config schemas could be converted to HTML forms (automatically generated where possible, but also custom HTML where necessary)

Disadvantages

• Internally, the UI state will have to be stored in some JSON file (like for each card, XY coords, editor text as string to keep comments); round-trip conversion of existing YAML files while preserving things like comments is hard -> no longer able to edit YAML files in text editor, only the dashboard YAML editor (but only if you use this feature)

Alternatives

Alternative ideas considered:

• Create Forms dynamically like HA config flows:

  • would require lots of backend changes for inference of schemas
  • very hard to get 100% feature coverage (especially more complex features like automations to dynamically generate forms for), without >80% feature coverage any "power" user wouldn't be able to use this system

• NodeRED like system: works well for automation flow, but not really useful for independent things like a GPIO switch; looks very complex to implement

This issue is to get the conversation going and see if there's interest in implementing the frontend side.

In conclusion, obviously a Config GUI would be a great addition. I believe this system is the easiest starting point with significant improvements right away while keeping all power users on board. Incremental progress towards more Form-like input is also possible.

The base layout relies on materialize.min.css for fonts and styling of header/footer. This should be moved to esphome-2.css.

Operating environment/Installation (Hass.io/Docker/pip/etc.):

installed via pip

ESPHome version (latest production, beta, dev branch)

v1.19.1

Affected component:

Description of problem:

If you click the INSTALL button, the dashboard will not autosave like it did in previos versions. Kinda annoying...

Originally posted by @Mariusthvdb in #320 (comment)

thought it best to post this as a separate issue, as it contains new info after initial succes

thx for the fix. Updated the Add-on to 2022.9.4 and refreshed the firmware on https://esphome.github.io/bluetooth-proxies/

I can see the devices being discovered:

so, I click on Adopt on the 277564, change the name to something nicer, bluetooth-proxy-centraal and that seems to fare well. I do notice it still compiles Wifi related lines, and an error scrolls by:

/data/cache/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-spi.c: In function 'spiTransferBytesNL':
/data/cache/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-spi.c:922:39: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
                 uint8_t * last_out8 = &result[c_longs-1];
                                       ^
/data/cache/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-spi.c:923:40: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
                 uint8_t * last_data8 = &last_data;
                                        ^

no matter that, there is success reported, and the board is online. hurray.

however, in the dashboard the discovered device is still showing after successful adoption:

reading the process for the M5stack board does in fact take away the 'discovered' device:

finally, this is repeated in the homeassistant.log:

Logger: homeassistant.components.esphome
Source: components/esphome/__init__.py:263 
Integration: ESPHome (documentation, issues) 
First occurred: 10:53:09 (20 occurrences) 
Last logged: 11:08:21

Name of device olimex-bluetooth-proxy-277564 changed to bluetooth-proxy-centraal, potentially due to IP reassignment

and

Logger: aioesphomeapi.reconnect_logic
Source: runner.py:119 
First occurred: 12:30:15 (1 occurrences) 
Last logged: 12:30:15

Can't connect to ESPHome API for olimex-bluetooth-proxy-277564 @ 192.168.1.221: Server sent a different name 'bluetooth-proxy-centraal'

which ofc isnt the fact and seems another bug?

The problem

after new update(new colored editor), while editing yaml file dashboard cursor freeze randomly and give no response to backspace key until i type random alphanumeric key. issue happening in android firefox and chrome browser.

Which version of ESPHome has the issue?

2022.12.x

What type of installation are you using?

Docker

Which version of Home Assistant has the issue?

2022.12

What platform are you using?

ESP8266

Board

d1_mini

Component causing the issue

backspace key

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

android version: 11
model: realme
keyboard: florishboard
browser: chrome and firefox

See Discord Messages

Be able to select with tickboxes or similar which devices to update. This means that a user doesn't need to waste time updating devices that are offline.

If needed, the tickboxes allow for a user to attempt to update devices that the Dashboard thinks is offline.

When copy pasting yaml into the editor, the validator somehow still uses validation for the old yaml as if it was never updated. While the in browser editor will show invalid for the yaml, simply closing and reopening the dialog will show the yaml as being valid.

To reproduce:

1. Paste this yaml into the editor.
2. Close and reopen the editor.
3. Paste this yaml into the editor.
4. Observe validation errors.
5. Close and reopen editor.
6. Observe validation errors disappear.

When trying to adopt device this is the error that I get. Using a nodemcu 1.0 (12-e) on the latest version of the website.

Operating environment/Installation (Hass.io/Docker/pip/etc.):

ESPHome in Docker behind SWAG (https://hub.docker.com/r/linuxserver/swag) reverse proxy.

docker-compose entry:

esphome:
    #image: esphome/esphome:1.18.0
    image: esphome/esphome:1.19.2
    container_name: esphome
    networks:
      - ha_network
    environment:
      - ESPHOME_DASHBOARD_USE_PING=true
    volumes:
        - /docker/esphome/config:/config
    ports:
      - 6052:6052
    restart: unless-stopped

ESP (ESP32/ESP8266, Board/Sonoff):

ESP32 / ESP8266
ESPHome version (latest production, beta, dev branch)

latest

Affected component:

Description of problem:

Upgraded Docker image from 1.18.0 to 1.19.0 then 1.19.1 and then 1.19.2. Each time I tried restarting the Docker container but the dashboard UI elements were unresponsive in Safari and Firefox but worked in Chrome.

I have tried restarting browsers, clearing caches etc but the dashboard remains unresponsive.

All elements are grey, none of the usual link elements respond when clicked.

Safari:

Chrome:

If I roll back to 1.18.0 everything works in Safari again:

Problem-relevant YAML-configuration entries:

PASTE YAML FILE HERE

Logs (if applicable):

PASTE DEBUG LOG HERE

Additional information and things you've tried:

Is it possible to have web flashed partitions.bin file generated by the project and not static one?

It's flashes project generated partition file when ESP connected to the host and old static partition file using web flasher.

I open the issue to have at least new partition file esphome/esp-web-tools#55

It would be great if the dashboard had native support for HTTPS. Currently this can be done but using a 2nd services like Nginx but Node already supports https, so to fun a second service for this would be unnecessary.

Describe the problem you have/What new integration you would like
Currently there's no confirmation when deleting a device in the GUI. It's pretty scary to use.

Please describe your use case for this integration and alternatives you've tried:
Would like to be asked for confirmation before proceeding to the deletion of the device.

Additional context
Fixing this would also prevent bugs like this one.

After a recent update a dialog with more options to connect to devices appeared in the dashboard.
With this change, connecting to your device to view logs requires choosing the method each time, even when the only option is to connect wirelessly.

I would like the logs to open right away without needing to click an additional time on this dialog:

If there is only one option available this is just an unneccesary step.

The problem

When setting up ESPHome, even if the user only ever uses something such as the M5Stack PoESP32, ESPHome still requires a WiFi network be entered on the first device.

While only a minor inconvenience of having to make up a non-existent WiFi network, there may still be a better way of handling this requirement. Perhaps some sort of "yeah naaaah this is LAN-only"?

The PoESP32 does not have any method of utilising the WiFi that is traditionally included in the ESP32.

Which version of ESPHome has the issue?

2023.5.5

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2023.5.4

What platform are you using?

ESP32

Board

M5Stack PoESP32

Component causing the issue

esphome

Example YAML snippet

esphome:
  name: m5stack-poesp32-25

esp32:
  board: m5stack-core-esp32
  framework:
    type: arduino

# Enable logging
logger:

# Keep this, coz you can't flash shit remotely without it
ota:

# Network interface for PoESP32
ethernet:
  type: IP101
  mdc_pin: GPIO23
  mdio_pin: GPIO18
  clk_mode: GPIO0_IN
  phy_addr: 1
  power_pin: GPIO5

# Enable Home Assistant API
api:
  encryption:
    key: "****"

Anything in the logs that might be useful for us?

N/A

Additional information

I adopted an olimex Bluetooth proxy and this is what came in via ACE

Since it expects all data fields to be JSON, this caused errors. Since it's in an event handler, it doesn't actually break the flow in ESPHome.

CC @glmnet

Delete action + undo toast should be moved out of legacy and no longer rely on the materialize toast.

Please, like it was once upon the time:

Plain, simple, useful 💚

In ESPHome 2021.10.0b4 the online state is hidden. Because of that, the height of the cards are different:

While I like the more compact view - it causes all cards to jump up/down when the status of one of the upper devices changes and also doesn't look clean.

Suggestion:
Use the icon of HA binary sensor device class connectivity to show if a device is offline (with tooltip & alt text "OFFLINE"):

The problem

because it is LAN connected, and not Wifi.

The device is recognized correctly in the Integration panel after having flashed the firmware successfully via https://esphome.github.io/bluetooth-proxies/

Note there is no option offered in that Next box to Include in Home Assistant, as is shown in the release party for the Wifi M% stack.

Ive had a long an intense discussion on Discord, and an active topic in the community, neither of which have yet solved the issue, hence I have to report here as true issue:

summary: can not adopt POE device because of Wifi only adapting in ESPHome dashboard.

TLDR:
upon opening ESPhome dashboard, the device is 'discovered'

clicking adopt wont work, because it wants wifi credentials. However, upon doing so a second instance is displayed:

directly followed by an offline of the same device:

we can Edit the yamlfiles, add the configuration as provided at https://github.com/esphome/bluetooth-proxies/blob/main/olimex-esp32-poe-iso.yaml which initially seems to succeed, a connection is made.

however, closing the log window reveals:

there seems to be no way to get out of this circle.

also tried it with static IP, but the result is the same. running in circles.

What version of Home Assistant Core has the issue?

2022.9.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

ESPhome

Link to integration documentation on our website

https://www.home-assistant.io/integrations/esphome/

Diagnostics information

No response

Example YAML snippet

substitutions:
  name: olimex-bluetooth-proxy

esphome:
  name: ${name}
  name_add_mac_suffix: true
  project:
    name: esphome.bluetooth-proxy-1
    version: "1.0"

esp32:
  board: esp32-poe-iso
  framework:
    type: arduino

ethernet:
  type: LAN8720
  mdc_pin: GPIO23
  mdio_pin: GPIO18
  clk_mode: GPIO17_OUT
  phy_addr: 0
  power_pin: GPIO12
  manual_ip:
    static_ip: 192.168.1.135
    gateway: 192.168.1.1
    subnet: 255.255.255.0

api:
logger:
ota:

dashboard_import:
  package_import_url: github://esphome/bluetooth-proxies/olimex-esp32-poe-iso.yaml@main

esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:

button:
- platform: safe_mode
  name: Safe Mode Boot
  entity_category: diagnostic

Anything in the logs that might be useful for us?

No response

Additional information

No response

if i want to create a new device, i have to put in wifi ssid + pw, but i use !secret.. in my yaml.
So i have to fill in something and have to change it after that.

it is possible to leave it blank at creating new yaml or maybe to choose out secret things.

Or it is possible to create a default config yaml, that will be used every time you create a new device?

Operating environment/Installation (Hass.io/Docker/pip/etc.):

Home Assistant supervised docker Add-on version 1.19.4
Browsing on Chrome 91.0.4472.114

ESP (ESP32/ESP8266, Board/Sonoff):

The issue is present on all boards I have, ESP8266 (nodeMCU), ESP-CAM, ESP32s (nodeMCU)

ESPHome version (latest production, beta, dev branch)

1.19.4

Affected component:

Docker webUI

Description of problem:
The windows opened after clicking on any device's validate, install, or logs buttons is oversized and falls below other web objects, making it difficult to see parts of those windows and click on some of the buttons, like "close".

Problem-relevant YAML-configuration entries:

Logs (if applicable):

Additional information and things you've tried:
Tried to resize the browser window but it makes no difference.

The problem

It is possible to change the color of the style in editor. The one in the original version 2022.8 suited me better.

Which version of ESPHome has the issue?

2022.9.1

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2022.9.6

What platform are you using?

ESP32

Board

No response

Component causing the issue

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

When installing via device connected to the server while no serial port is detected shows an empty list:

We should show a message when 0 entries found. It should also link to the drivers.

I hope this is not a duplicate, but searching for "logs" or any variation results in every issue matching. Sorry in advance.
This broke somewhere after 1.19.1.

I have the add-on set to use SSL. I also have the VS Code add-on installed, which might be relevant given the mention in the logs below. I was not able to get the VSCode integration working, probably due to my DNS setup (I do not use Home Assistant for DNS, I use Windows Server 2012R2 with a real domain name for everything, so *.local will not resolve anything).

Operating environment/Installation (Hass.io/Docker/pip/etc.):

Hass.io (Home Assistant OS 6.0, supervisor-2021.06.6, core-2021.6.4 running in a VM)
ESP (ESP32/ESP8266, Board/Sonoff):

ESP8266, probably all though
ESPHome version (latest production, beta, dev branch)

1.19.4 (latest as of now)
Affected component:

The web UI itself (here I guess)

Description of problem:

Problem-relevant YAML-configuration entries:
All devices have this issue, appears front-end related.

Logs (if applicable):

Browser console logs. The first 3 entries are just loading the page, the last entry is when I click on LOGS:

Uncaught (in promise) TypeError: t.filter is not a function
    at c.2472ed8e.js:1

ESPHome log:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 00-banner.sh: executing... 
-----------------------------------------------------------
 Add-on: ESPHome
 ESPHome add-on for intelligently managing all your ESP8266/ESP32 devices
-----------------------------------------------------------
 Add-on version: 1.19.4
 You are running the latest version of this add-on.
 System: Home Assistant OS 6.0  (amd64 / qemux86-64)
 Home Assistant Core: 2021.6.4
 Home Assistant Supervisor: 2021.06.6
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
[cont-init.d] 00-banner.sh: exited 0.
[cont-init.d] 01-log-level.sh: executing... 
[cont-init.d] 01-log-level.sh: exited 0.
[cont-init.d] 10-requirements.sh: executing... 
[cont-init.d] 10-requirements.sh: exited 0.
[cont-init.d] 20-nginx.sh: executing... 
[cont-init.d] 20-nginx.sh: exited 0.
[cont-init.d] 30-esphome.sh: executing... 
[cont-init.d] 30-esphome.sh: exited 0.
[cont-init.d] 40-migrate.sh: executing... 
[cont-init.d] 40-migrate.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[17:15:02] INFO: Waiting for dashboard to come up...
[services.d] done.
[17:15:02] INFO: Starting ESPHome dashboard...
INFO Starting dashboard web server on unix socket /var/run/esphome.sock and configuration dir /config/esphome...
[17:15:03] INFO: Starting NGINX...
INFO 200 GET / (0.0.0.0) 7.86ms
INFO 101 GET /ace (0.0.0.0) 0.47ms
INFO Running command 'esphome --dashboard -q vscode /config/esphome --ace'

Additional information and things you've tried:

ESPHome add-on configuration:

status_use_ping: true
ssl: true
certfile: real.FQDN.net-chain-2020.crt
keyfile: real.FQDN.net-key-2020.pem
relative_url: ''
leave_front_door_open: false

I have status_use_ping: true because mDNS does not work to/from the VLAN I keep my IOT devices in. But ping does, and this setup has been flawless until 1.19.4.

Reverting to a snapshot of 1.19.1 got things working again. I tried to restore my snapshot of 1.19.2 but that failed. Edit: removed logs of snapshot restore, that snapshot was bad for whatever reason.