* Add wake word to assist pipeline settings
* Update assist-pipeline-detail-wakeword.ts
* Add icon for wake word domain
* format state
* implement `wake_word/info` command
* Sortable options in input_select settings menu
* fix lint
* no ripple, default cursor
* Update src/panels/config/helpers/forms/ha-input_select-form.ts
Co-authored-by: Paul Bottein <paul.bottein@gmail.com>
* sortableStyles
* Use ha-list-item and mwc-list
---------
Co-authored-by: Paul Bottein <paul.bottein@gmail.com>
* start of lawn mower entity in the frontend
* added colours for states
* remove schedule states as no longer needed
* change mowing to teal
* remove docking as not included in architecture discussion and was missed
* Lock file maintenance
* Limit time period for lock file maintenance
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Steve Repsher <steverep@users.noreply.github.com>
* Added support for color temperature tile feature
* Update src/panels/lovelace/tile-features/hui-light-color-temp-tile-feature.ts
---------
Co-authored-by: Paul Bottein <paul.bottein@gmail.com>
* Add circular slider as temperature control
* Move climate icons and mode mapping
* Update icon
* Add mode icon
* Improve colors
* Add temperature control buttons
* Call service
* Remove climate control
* Some fixes
* Add current temp and humidity
* Fix default mode
* Swap state and current
* Some adjustments
* prettier
* Simplify color rules
* refactor cool mode
* Color button when dual climate
* Add current temp and humidity
* Fix opacity
* Hide current temp is below min or above max
* Adjust button size
* Add action label
* Better off and unavailable state
* Improve current color
* Add gallery
* Fix dark mode
* Add overflow
* Update src/dialogs/more-info/controls/more-info-climate.ts
Co-authored-by: Bram Kragten <mail@bramkragten.nl>
* Update src/panels/lovelace/cards/hui-thermostat-card.ts
Co-authored-by: Bram Kragten <mail@bramkragten.nl>
* Update src/dialogs/more-info/components/climate/ha-more-info-climate-temperature.ts
---------
Co-authored-by: Bram Kragten <mail@bramkragten.nl>
* Add crosshairs, destroy globals, and tweak updates for code editor
* Define update listener as arrow function
* Ensure editor is recreated on reconnection
* Don't create code mirror multiple times
* Remove creation in update
* Leverage lit lifecycle for editor creation and destruction
* Bump @codemirror packages
---------
Co-authored-by: Paul Bottein <paul.bottein@gmail.com>
* Fix missing submit button in options flow
* Fix missing header and finish button at end of options flow
* load config translations for options flow
* one more revert
@@ -63,7 +94,83 @@ gulp.task("check-all-files-exist", async function () {
awaitPromise.allSettled(writings);
});
constlokaliseProjects={
backend:"130246255a974bd3b5e8a1.51616605",
frontend:"3420425759f6d6d241f598.13594006",
};
gulp.task("fetch-lokalise",asyncfunction(){
letapiKey;
try{
apiKey=
process.env.LOKALISE_TOKEN||
(awaitfs.readFile(".lokalise_token",{encoding}));
}catch{
thrownewError(
"An Administrator Lokalise API token is required to download the latest set of translations. Place your token in a new file `.lokalise_token` in the repo root directory."
As a community, we are proud of our logo. Follow these guidelines to ensure it always looks its best. Our logo follows Google's material design spec and uses the blue interface color.
As a community, we are proud of our logo. Follow these guidelines to ensure it always represents the identity of the Home Assistant project and community the best way possible.
Please note that this logo is not released under the CC license. All rights reserved.
## Using the icon
# Design
Our icon is a shorter and most used version of our logo. The icon can exist without the wordmark, the wordmark should never exist without the icon.
At the core of the Home Assistant logomark is the Blue House with Antenna, the three most recognizable and distinct features of the previous logo throughout the past decade.

### Blue
## Using the right variant
Blue feels stable and essential. A bright sky blue is joyful, clear, and free of clouds.
The pretty blue logo with a background shadow, pictured top left, is our primary logo. It should only be used with black, white, and non-duotone photography.
### House
When needed you can use our logo without a shadow, as seen as the second variant.
Of all possible combinations of shapes, a home is best abstracted in the shape of a structure with a pitched roof. With the vast amount of logos based on this shape, the best we can do is to make it more iconic. The house is further simplified - there is no gable and there is no chimney - to an orthogonal shape with an elegant and deliberate proportion.
The outlined logo should only be used on packaging.
### Antenna
## Exclusion zone
Call it a tree, a set of nodes, a PCB, or an antenna. The antenna is the most recognizable and memorable part of the previous Home Assistant logo, and is an easily understandable symbol that conveys technologies that are smart, connected, and growing evergreen.
The logo needs some personal space. It's exclusion zone is equal to a quarter the height of the icon.
# Usage

The default variation is the static colored wordmark in horizontal layout and dark text on a light background.
The default layout is the wordmark in horizontal layout. It provides the clearest context to the brand identity of Home Assistant.
Use the logomark variant when the context is clear that the logo is about Home Assistant. For example, inside the Home Assistant app where users are already aware of where they are at, the logomark variant without the wordmark can be used. The logomark can exist without the wordmark, however, the wordmark should never exist without the icon.
Use the wordmark in vertical layout when the space available has an aspect ratio less than 4:3. For example, in a square space on a t-shirt where a logo is needed, since there is no established context of Home Assistant, the wordmark in vertical layout should be used.
Lastly, use the wordmark in vertical layout with small logomark when Home Assistant is displayed in context of other Home Assistant-related projects. For example, in a flowchart showing the voice pipeline, use this layout for Home Assistant and its other related projects.
## Color variations, backgrounds, and placement
The default color is the colored version on light background with dark text.
For backgrounds that are dark, for example, when it is used on a page in a dark theme, use the colored version on dark background with light text.
In printed materials where color is unavailable, use the monochrome color variations.
On background that are dark or photographic, use the light monochrome color on dark background variation.
On backgrounds that are light or photographic, use the colored version. Do not use the monochrome variations.
Do not enclose the logmark in a square or color or any confined backgrounds, except in specific situations enforced by another company's marketplace guidelines, for example, an iOS app icon.
Do not add drop shadow to the logomark or the wordmark. If legibility is compromised due to the background, change the background to provide more contrast, or in last resort, add a heavily blurred drop shadaow.
It should only be used with black, white, and non-duotone photography.
Unlike the previous version of our logo, no outlined variants are available. Use the monochrome variants in those spaces.
### Exclusion zone
The logo needs some personal space. Its exclusion zone is equal to a quarter the height of the icon.

## Animation
The default is the static variant.
Use the animated variant only for introductory purposes, for example, in the beginning of a video or on a loading screen.
Use the animated with sound variant only when sound is warranted in the user's context. For example, use it in the beginning of a video since sounds are expected in a video, but do not use it on a loading screen since sounds are not expected in a user interface.
Do not repeat the logo animation.
## Sizes and app icon variants
Special variants are created for specific contexts.
Use the tiny variants when the logomark is used in a very small space (16x16 dp), for example, the favicon of the Home Assistant website, a notification on Android, or the menubar of macOS.
When the component is dynamically displayed, the content is automatically announced by most screen readers. At this time, screen readers do not inform users of alerts that are present when the page loads.
@@ -78,6 +87,7 @@ Actions must have a tab index of 0 so that they can be reached by keyboard-only
## Implementation
### Example Usage
**Alert type**
<ha-alert alert-type="error">
@@ -96,17 +106,12 @@ Actions must have a tab index of 0 so that they can be reached by keyboard-only
This is an success alert — check it out!
</ha-alert>
```html
<ha-alert alert-type="error">
This is an error alert — check it out!
</ha-alert>
<ha-alert alert-type="error"> This is an error alert — check it out! </ha-alert>
<ha-alert alert-type="warning">
This is a warning alert — check it out!
</ha-alert>
<ha-alert alert-type="info">
This is an info alert — check it out!
</ha-alert>
<ha-alert alert-type="info"> This is an info alert — check it out! </ha-alert>
<ha-alert alert-type="success">
This is a success alert — check it out!
</ha-alert>
@@ -154,13 +159,14 @@ The `title ` option should not be used without a description.
@@ -5,28 +5,32 @@ subtitle: Dialogs provide important prompts in a user flow.
# Material Design 3
Our dialogs are based on the latest version of Material Design. Specs and guidelines can be found on its [website](https://m3.material.io/components/dialogs/overview).
Our dialogs are based on the latest version of Material Design. Specs and guidelines can be found on its [website](https://m3.material.io/components/dialogs/overview).
# Highlighted guidelines
## Content
* A best practice is to always use a title, even if it is optional by Material guidelines.
* People mainly read the title and a button. Put the most important information in those two.
* Try to avoid user generated content in the title, this could make the title unreadable long.
* If users become unsure, they read the description. Make sure this explains what will happen.
* Strive for minimalism.
- A best practice is to always use a title, even if it is optional by Material guidelines.
- People mainly read the title and a button. Put the most important information in those two.
- Try to avoid user generated content in the title, this could make the title unreadable long.
- If users become unsure, they read the description. Make sure this explains what will happen.
- Strive for minimalism.
## Buttons and X-icon
* Keep the labels short, for example `Save`, `Delete`, `Enable`.
* Dialog with actions must always have a discard button. On desktop a `Cancel` button and X-icon, on mobile only the X-icon.
* Destructive actions should be a red warning button.
* Alert or confirmation dialogs only have buttons and no X-icon.
* Try to avoid three buttons in one dialog. Especially when you leave the dialog task unfinished.
- Keep the labels short, for example `Save`, `Delete`, `Enable`.
- Dialog with actions must always have a discard button. On desktop a `Cancel` button and X-icon, on mobile only the X-icon.
- Destructive actions should be a red warning button.
- Alert or confirmation dialogs only have buttons and no X-icon.
- Try to avoid three buttons in one dialog. Especially when you leave the dialog task unfinished.
## Example
### Confirmation dialog
> **Delete dashboard?**
>
>
> Dashboard [dashboard name] will be permanently deleted from Home Assistant.
@@ -30,7 +30,7 @@ For the switch / toggle there are always two variables, one for the on / checked
The track element (background rounded rectangle that the round circular handle travels on) is set to being half transparent, so the final color will also be impacted by the color behind the track.
`switch-checked-color` / `switch-unchecked-color`
Set both the color of the round handle and the track behind it. If you want to control them separately, use the variables below instead.
Set both the color of the round handle and the track behind it. If you want to control them separately, use the variables below instead.
This portal aims to aid designers and developers on improving the Home Assistant interface. It consists of working code, resources and guidelines.
## Home Assistant interface
The Home Assistant frontend allows users to browse and control the state of their home, manage their automations and configure integrations. The frontend is designed as a mobile-first experience. It is a progressive web application and offers an app-like experience to our users. The Home Assistant frontend needs to be fast. But it also needs to work on a wide range of old devices.
### Material Design
The Home Assistant interface is based on Material Design. It's a design system created by Google to quickly build high-quality digital experiences. Components and guidelines that are custom made for Home Assistant are documented on this portal. For all other components check <a href="https://material.io" rel="noopener noreferrer" target="_blank">material.io</a>.
## Designers
We want to make it as easy for designers to contribute as it is for developers. There’s a lot a designer can contribute to:
- Meet us at <a href="https://discord.gg/BPBc8rZ9" rel="noopener noreferrer" target="_blank">devs_ux Discord</a>. Feel free to share your designs, user test or strategic ideas.
- Find the lates UX <a href="https://github.com/home-assistant/frontend/discussions?discussions_q=label%3Aux" rel="noopener noreferrer" target="_blank">discussions</a> and <a href="https://github.com/home-assistant/frontend/labels/ux" rel="noopener noreferrer" target="_blank">issues</a> on GitHub. Everyone can start a new issue or discussion!
- Find the latest UX <a href="https://github.com/home-assistant/frontend/discussions?discussions_q=label%3Aux" rel="noopener noreferrer" target="_blank">discussions</a> and <a href="https://github.com/home-assistant/frontend/labels/ux" rel="noopener noreferrer" target="_blank">issues</a> on GitHub. Everyone can start a new issue or discussion!
## Developers
Everything you need to get started developing can be found in our <a href="https://developers.home-assistant.io" rel="noopener noreferrer" target="_blank">Home Assistant Developer Docs</a>.
At the end of last year, we created one Configuration menu by merging Supervisor. In the next iteration, we want to organize our menu by creating logical grouping and combining duplicated features. We are conducting this test to see if we are on the right track.
* Anyone could join
* Respondents recruited on Twitter, Reddit and Home Assistant Forum
* This test is open for 10 days
* UsabilityHub for user test
* Figma for prototype
* 6 questions
* 3 tasks
* Due to some limitations by UsabilityHub, it only worked on desktop
- Anyone could join
- Respondents recruited on Twitter, Reddit and Home Assistant Forum
- This test is open for 10 days
- UsabilityHub for user test
- Figma for prototype
- 6 questions
- 3 tasks
- Due to some limitations by UsabilityHub, it only worked on desktop
# Results
915 respondents took part in this test and they gave 407 comments. In general there isn’t a significant difference between:
* How long a respondent has been using Home Assistant
* Installation method
* How many visits to its Home Assistant in the past 3 months
* Home Assistant expertise
- How long a respondent has been using Home Assistant
- Installation method
- How many visits to its Home Assistant in the past 3 months
- Home Assistant expertise
## Overall menu change
This prototype organized our menu by creating logical grouping and combining duplicated features. What do people think of this change?
### Stats
* 2% (21) Like extremely
* 30% (276) Like very much
* 53% (481) Neutral
* 12% (108) Dislike very much
* 3% (26) Dislike extremely
*3 respondents passed*
- 2% (21) Like extremely
- 30% (276) Like very much
- 53% (481) Neutral
- 12% (108) Dislike very much
- 3% (26) Dislike extremely
_3 respondents passed_
### Comments summary
**Like**
* Clean and decluttered
* Style looks better
* Faster to use
* Merging Supervisor into different pages
* Moving Developer tools to Settings
- Clean and decluttered
- Style looks better
- Faster to use
- Merging Supervisor into different pages
- Moving Developer tools to Settings
**Dislike**
* Moving Developer tools to Settings
* More clicks for scripts and helpers
* Too many changes at once causes a high learning curve
* Removing the word `Integrations` makes it harder to find them
* Difference between `Addons` and `Services` is a bit subtle
* No clear distinction between `Developer` and `System`
* Material Design got the Google image
- Moving Developer tools to Settings
- More clicks for scripts and helpers
- Too many changes at once causes a high learning curve
- Removing the word `Integrations` makes it harder to find them
- Difference between `Addons` and `Services` is a bit subtle
- No clear distinction between `Developer` and `System`
- Material Design got the Google image
**Suggestions**
* More top level menu items for example logs.
* What are settings and what not? Maybe better to name it `Configuration`
* Devices are a first-class citizen in the domain of Home Assistant, and so shouldn't be tucked away in "Settings"
* Rename Developer tools (or make it only for Home Assistant developers)
* Separate administration (for instance creating users / adding lights etc) from development activities (creating automations and scripts)
* Search Bar in Settings
* Feature to put menu items in sidebar
* Unification of add-ons and integrations
* Adding ‘New’ hints to show what changed
* Give `About` a less prominent size
* Accordion view option which puts every tab below
* Dev mode and a Prod Mode
* Always show config menu (on bigger screens)
- More top level menu items for example logs.
- What are settings and what not? Maybe better to name it `Configuration`
- Devices are a first-class citizen in the domain of Home Assistant, and so shouldn't be tucked away in "Settings"
- Rename Developer tools (or make it only for Home Assistant developers)
- Separate administration (for instance creating users / adding lights etc) from development activities (creating automations and scripts)
- Search Bar in Settings
- Feature to put menu items in sidebar
- Unification of add-ons and integrations
- Adding ‘New’ hints to show what changed
- Give `About` a less prominent size
- Accordion view option which puts every tab below
- Dev mode and a Prod Mode
- Always show config menu (on bigger screens)
### Conclusion
We should keep our focus on organizing our menu by creating logical grouping and combining duplicated features. With these changes we make more people happy:
* Reconsider putting `Logs` as a top-level menu item
* Add a search bar
* Use the word `Integrations` with `Devices & Services`
* Moving `Developer tools` to `Settings` is a good idea
* Rename `Developer tools` to for example `Tools`
* Add `New` explanation popups to what has changed
* We could rename `Configuration` to `Settings`
* Give `About` a less prominent size
- Reconsider putting `Logs` as a top-level menu item
- Add a search bar
- Use the word `Integrations` with `Devices & Services`
- Moving `Developer tools` to `Settings` is a good idea
- Rename `Developer tools` to for example `Tools`
- Add `New` explanation popups to what has changed
- We could rename `Configuration` to `Settings`
- Give `About` a less prominent size
## Helpers
In Home Assistant you can create toggles, text fields, number sliders, timers and counters. Also known as `Helpers`. Where should they be placed?
### Stats
* 78% (709) respondents are using helpers. They use it for:
* 92% (645) automations and scenes
* 62% (422) dashboards
* 43% (296) virtual devices
- 78% (709) respondents are using helpers. They use it for:
- 92% (645) automations and scenes
- 62% (422) dashboards
- 43% (296) virtual devices
### Comments summary
Some respondents commented that they think `Helpers` shouldn’t be listed under `Automations & Services`. Although almost all respondents use it for that specific purpose.
### Conclusion
Helpers is, in addition to `Automations & Services`, also partly seen as virtual devices and dashboard entities.
* We might consider promoting them in their own top-level menu item
* Rename `Helpers` to something with `controls`
Helpers is, in addition to `Automations & Services`, also partly seen as virtual devices and dashboard entities.
- We might consider promoting them in their own top-level menu item
- Rename `Helpers` to something with `controls`
## Add person
The first task in this user test was to add a person. Since this has not changed in the current menu structure, this should be an easy assignment. How do people experience the navigation to this feature?
### Stats
95% reached the goal screen and 98% marked the task as completed. There were 18 common paths.
After the task we asked how easy it was to add a person.
* 41% (378) Extremely easy
* 48% (440) Fairly easy
* 7% (67) Neutral
* 2% (19) Somewhat difficult
* 1% (11) Very difficult
- 41% (378) Extremely easy
- 48% (440) Fairly easy
- 7% (67) Neutral
- 2% (19) Somewhat difficult
- 1% (11) Very difficult
### Comments summary
*No mentionable comments *
_No mentionable comments _
### Conclusion
This test showed that the current navigation design works.
## YAML
In Home Assistant you can make configuration changes in YAML files. To make these changes take effect you have to reload your YAML in the UI or do a restart. How are people doing this and can they find it in this new design?
### Stats
83% reached the goal screen and 87% marked the task as completed. There were 59 common paths.
After the task we asked how easy it was to reload the YAML changes.
* 4% (40) Extremely easy
* 22% (204) Fairly easy
* 20% (179) Neutral
* 37% (336) Somewhat difficult
* 17% (156) Very difficult
- 4% (40) Extremely easy
- 22% (204) Fairly easy
- 20% (179) Neutral
- 37% (336) Somewhat difficult
- 17% (156) Very difficult
And we asked if they have seen that we've moved some functionality from current `Server Controls` to `Developer Tools`.
* 57% (517) Yes
* 43% (398) No
- 57% (517) Yes
- 43% (398) No
### Comments summary
**Like**
* YAML in Developer tools
- YAML in Developer tools
**Dislike**
* Hidden restart and reload
* YAML in Developer Tools
* Combining `Developer tools` with `Server management`
* Reload Home Assistant button isn't clear what it does
* Reload/restart Home Assistant in Developer Tools
- Hidden restart and reload
- YAML in Developer Tools
- Combining `Developer tools` with `Server management`
- Reload Home Assistant button isn't clear what it does
- Reload/restart Home Assistant in Developer Tools
**Suggestions**
* Reload all YAML button
* Dev mode and a Prod Mode
* Show restart/reload as buttons in System instead of overflow menu
* Explain that you can reload YAML when you want to restart your system
* YAML reloading under System
- Reload all YAML button
- Dev mode and a Prod Mode
- Show restart/reload as buttons in System instead of overflow menu
- Explain that you can reload YAML when you want to restart your system
- YAML reloading under System
### Conclusion
This test showed two different kinds of user groups: UI and YAML users.
* Moving `Developer tools` to `Settings` is a good idea
* YAML users want reload YAML and Home Assistant restart in `System`
* Move the restart and reload button to the `System` page from the overflow menu
* Add suggestion to reload YAML when a user wants to restart
* Add reload all YAML button
This test showed two different kinds of user groups: UI and YAML users.
- Moving `Developer tools` to `Settings` is a good idea
- YAML users want reload YAML and Home Assistant restart in `System`
- Move the restart and reload button to the `System` page from the overflow menu
- Add suggestion to reload YAML when a user wants to restart
- Add reload all YAML button
## Logs
### Stats
70% reached the goal screen and 77% marked the task as completed. There were 48 common paths.
After the task we asked to find out why your Elgato light isn't working.
* 6% (57) Extremely easy
* 28% (254) Fairly easy
* 21% (188) Neutral
* 21% (196) Somewhat difficult
* 24% (220) Very difficult
- 6% (57) Extremely easy
- 28% (254) Fairly easy
- 21% (188) Neutral
- 21% (196) Somewhat difficult
- 24% (220) Very difficult
### Comments summary
**Suggestions**
* Log errors on the integration page
* Problem solving center
- Log errors on the integration page
- Problem solving center
### Conclusion
Although this test shows that a large number of respondents manage to complete the task, they find it difficult to find out the light isn’t working.
* Add logs errors/warnings to the integration page
* Reconsider putting `Logs` as a top-level menu item
- Add logs errors/warnings to the integration page
- Reconsider putting `Logs` as a top-level menu item
## Learnings for next user test
* Explain that topic is closed for comments so that you can do this test without any influence
* Mobile test should work on mobile
* Testing on an iPad got some bugs
* People like doing these kind of test and we should do them more often
- Explain that topic is closed for comments so that you can do this test without any influence
- Mobile test should work on mobile
- Testing on an iPad got some bugs
- People like doing these kind of test and we should do them more often
We have defined three user types for Home Assistant. They are a lean segmentation of users that helps us make decisions throughout the product. User types differ from traditional personas in that the segmentation criteria aren’t demographic and don’t personify a group into a single character with a fictitious background story.
We have defined three user types for Home Assistant. They are a lean segmentation of users that helps us make decisions throughout the product. User types differ from traditional personas in that the segmentation criteria aren’t demographic and don’t personify a group into a single character with a fictitious background story.
@@ -31,8 +31,8 @@ export class HassioUploadBackup extends LitElement {
.icon=${mdiFolderUpload}
accept="application/x-tar"
label="Upload backup"
supports="Supports .TAR files"
@file-picked=${this._uploadFile}
auto-open-file-dialog
></ha-file-upload>
`;
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.