You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The install dialogs on web.esphome.io now carry the same collapsible "Show details" log the Device Builder's install dialog has: every flash engine's step lines, so a failed flash shows the step it died in rather than one error line.
The dashboard's log toggle, download and ansi-log panel moved out of the install dialog's renderer into a shared <esphome-install-details-log> element that both the dashboard and the site use. The site slots it under the shared progress card (into the process-terminal card's status-extra, as the dashboard does) and its download saves esphome-web-install.txt; the dashboard keeps driving the expanded state (it opens the log on failure) and its own flushed download through the element's expanded-changed and cancelable download-log events.
The ESP flow already collected esptool's lines in the flow controller but never showed them; the shared progress card now passes them through, so the adoptable and upload dialogs get the log for free.
The nRF52 dialog feeds the 1200 baud touch's lines and the DFU engine's onLog into it; the Pico dialog does the same for the touch and the PICOBOOT engine. Both clear the log when the dialog closes.
No new copy: the toggle and download reuse the dashboard's firmware.show_details, firmware.hide_details and dashboard.logs_download strings.
Cleanup pass: the log is now one shared <esphome-install-details-log> under src/components/, used by the dashboard's install dialog (its renderer and styles lost their copy; it drives expanded and takes over the download through the element's events so its flush-before-download stays) and by the site's progress card. The nRF test file is named after the element and uses the shared mount; the empty-lines guard lives only at the render sites.
Addressed the two open suggestions and the Copilot thread:
Each run starts with a fresh log: the nRF dialog clears it at Install, the Pico dialog at Reset Device and at an Install that does not follow the reset step (so touch, wait and flash stay one log). Tests cover a retry without closing the dialog and the reset-then-install continuity.
The site opens the log on failure like the dashboard: the progress card passes expanded for the error state, and the element keeps the user's own toggle afterwards. New install-progress test.
The details-log element imports the icon component it renders.
Parent rerenders reset the site log's expanded state
src/web/install/install-progress.ts:80
The site callers do not own the log's expanded state, but this binding overwrites the child on every parent render. After a user opens "Show details" while flashing, the next progress/log update rerenders the card and sets expanded back to false (and a success transition also closes it), so the site log cannot stay open during the operation. Keep the expanded value in the site dialog/flow state and update it from expanded-changed, while still forcing it open on error.
On Copilot's latest overview note (the site's .expanded binding resetting a log the user opened): it does not. Lit commits a property binding only when its value differs from the last committed one, and while the flash runs that value stays false, so the child's own expanded (set by the toggle) is left alone across progress and log re-renders; the success transition binds false again and is likewise skipped. Only the error transition (true) is ever committed, which is the intended open-on-failure. Pinned in test/web/install-progress.test.ts ("keeps a log the user opened open across progress re-renders"), so nothing to move into the dialogs' state.
PR Review — Show the flash engines' step lines in the web.esphome.io install dialogs
Ready to merge. The last open suggestion is fixed and I found no new issues.
What's resolved and working:
Accessibility of the toggle: the Show details button now sets aria-expanded with a string value, so it renders on both states. It also sets aria-controls="log" while the panel is open. The #log id is in the same shadow root as the button, so the reference works. The element test checks both states.
One shared element:<esphome-install-details-log> removes the duplicated markup and CSS from the dashboard renderer and styles. The dashboard still flushes its log before downloading: it cancels the download-log event, and the batching test checks that.
ESP flow:InstallFlowController.logLines already existed and is cleared on each run. The progress card now passes those lines through, so the adoptable and upload dialogs show the log with no extra wiring.
Per-run log reset: the nRF dialog clears the log at Install. The Pico dialog clears it at Reset and at an Install that doesn't follow the reset, so a reset followed by an install stays one log. Tests cover both, including a retry without closing the dialog.
Open on failure (site):.expanded=${card.state === "error"} only takes effect when the value changes. A log the user opened stays open across progress re-renders, as the author explained in their reply and test/web/install-progress.test.ts checks.
No remaining findings.
✅ Resolved since last review (1)
Previously-flagged issues verified fixed
src/components/install-details-log.ts:61 The Show details toggle doesn't tell screen readers whether it is open
Checklist
No hardcoded secrets
Log state resets at the start of each install attempt
PR description goals delivered
Accessibility of the toggle control (aria-expanded/aria-controls)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
esphbot
left a comment
What does this implement/fix?
The install dialogs on web.esphome.io now carry the same collapsible "Show details" log the Device Builder's install dialog has: every flash engine's step lines, so a failed flash shows the step it died in rather than one error line.
ansi-logpanel moved out of the install dialog's renderer into a shared<esphome-install-details-log>element that both the dashboard and the site use. The site slots it under the shared progress card (into theprocess-terminalcard'sstatus-extra, as the dashboard does) and its download savesesphome-web-install.txt; the dashboard keeps driving the expanded state (it opens the log on failure) and its own flushed download through the element'sexpanded-changedand cancelabledownload-logevents.onLoginto it; the Pico dialog does the same for the touch and the PICOBOOT engine. Both clear the log when the dialog closes.No new copy: the toggle and download reuse the dashboard's
firmware.show_details,firmware.hide_detailsanddashboard.logs_downloadstrings.Related issue or feature (if applicable):
Screenshots
Same visual as the Device Builder's install log, under the site's progress card.
Types of changes
bugfixnew-featureenhancementbreaking-changerefactordocsmaintenancecidependenciesChecklist
pnpm run lintpasses.pnpm run testpasses.