Comments (18)
Backend groups will still be around, just no longer necessary for the frontend to show groups. Once decoupled from the frontend, we can better judge their future.
from architecture.
I wouldn't want to use a config entry but instead use a standalone YAML/JSON file. That will allow easier sharing and also means we don't have to start adding a UI before being able to launch this.
For configuration I was thinking of something like this:
# which view to add newly discovered entities to
new_entities_view: living_room
# views that can be defined
views:
- title: Living Room # Title of the view, shown as tab name unless icon set
id: living_room
# Number of columns in the view. Right now use "auto" but we might allow changing this
# Can be set to "auto", a number or maybe also "auto(2, 4)" to specify range of min/max ?
column_count: auto
cards:
- type: entities
# Used in future UI but can also be used as caption for card etc
name: Kitchen
config:
entities:
- light.kitchen_left
- light.kitchen_right
- switch.coffee_maker
- type: "custom:crazy-camera" # the name after "custom:" part will be used as web component
name: Camera backyard
# to be passed to the card
config:
rotate: 180
refresh: 5
from architecture.
- So the backend groups are unnecessary with this?
- Has this a concept for frontend only (custom) UI's like floorplan or weblinks?
- Should all frontend related attributes, like friendly name and icon moved to this?
- We have some input_xxx components with min/max for numbers or we have supportedFeatures so we still need to send some static 'attributes' to the frontend. Maybe this is also the time for home-assistant/core#10732
from architecture.
Backend groups will not be used anymore.
Thinks like friendly names are still used in entities for things like Alexa or Google Home. That's not a frontend only concern. I would also keep icons and entity picture s backwards compatibility
from architecture.
💯for this. I have one tiny detail question though: How would cross-domain groups be done if "Backend groups will not be used anymore"? I mean by expanding #13 to all domains, we'd solve the issue of groups inside one domain. But what if we want to control switches, covers, ... (inter-domain) at the same time? I think we'd still need to have at least some way of doing that, maybe not through the group:
domain, but through something else.
from architecture.
Does it makes sense to keep backend groups around, but strip out the frontend concerns? They're pretty widely used in automations.
from architecture.
Late to the party, but could this be as easy* as
Groups = backend (group of device trackers, group of lights, group of lights and switches in a room), for the purpose of having a 'state' for x number of devices.
Card = frontend card, containing devices or backend groups as listed.
View = frontend view (tab) as it is now, containing cards as listed, and entities (as badges/whatever).
(*) (from an end user perspective, not a dev perspective, I know there's nothing easy about coding all this!)
from architecture.
Can't we migrate the frontend component to a config_entry? And use that as an API to set, save and get configuration. (we could then also leverage migrations if ever implemented/needed as we would not want breaking changes on UI configuration.)
But we could of course also make a seperate API endpoint for frontend configuration.
My main requirement would be that this all should be very easy to get and set in the frontend. Setting this all in yaml would be a PITA.
As noted above groups should be groups for state/backend purposes (can be viewed/used in frontend of course, but are not the way to group items for display purposes)
A very simple schema with some basic attributes could be:
- entities (customization):
icon | icon_color | show_history | show_last_update | custom_ui
- cards:
title | type(could be custom_ui) | entities
- badges:
type | title | entities(sortable list)
- views:
title | icon | badges(sortable list) | cards(sortable list)
default_view
: references viewshow_new_entities_on_view
: references view
Of course a single entity could act as a card too (like the media-player)
We could add other configuration too, for example the history_graph_card could have additional settings like what type of chart, the size of the chart.
When defining the schema technically, we should make sure it is extendable. So a sortable list would be able to have additional attributes for each list-item. (so we can eventually show/hide/customize stuff based on location in UI and not only based on the entity customization)
from architecture.
another approach could be to not customize entities, but define additional state-cards...
Of course each entity would always have a default state-card. But you can define extra state-cards (custom_ui) for that same entity to show it in a different way.
We could provide our own simple customizable state-card (change icon, color, control type, show one additional attribute) that could act as a basic example for other custom_ui.
from architecture.
That makes sense. Although I would prefer to (be able to) define cards separately and reference them by id in the view. That makes it easier to manually edit ordering, moving it to another view or showing the same card on multiple views. Same with state-cards/entities.
I do realize that will turn into a relational database rather than a single config object.
from architecture.
Although I can see the use cases, I also think that it will make it just more complicated for beginners to get started and understand the system. I think that if we allow people to duplicate cards and then move cards to other views, we can cover most of those use cases.
from architecture.
Hmm... both approaches are not mutually exclusive. So we could of course do the 'in-place' config first, and later add the ability to reference a card (elsewhere configured) by id.
I envision some sort of 'UI library' with our default UI 'building blocks', but also custom UI the user added and/or defined. Then it's a matter of adding (drag and drop?) those building blocks into a view.
You could also just store some Card/custom ui for later use.
from architecture.
I just realize I’m getting a bit ahead of ourselves and we should just start building something really basic (but extendable) and see how it goes.
I’m not very familiar with doing big rafactoring/architectural stuff like this, so bear with me ;-) I’m just trying to get things going (and learning from it in the process)
For the backend we need a new ‘frontend’ component that:
- exposes its config to the frontend.
- migrates the current group-based views to a new config schema. (This can be removed later)
- and of course provide some sensible default config (where needed)
- and (later) takes config changes set in the frontend and save it.
This can be developed completely seperate from everything.
For the frontend it’s a bit harder. We could keep things backward compatible (fallback to groups based views) and do all this on the master branch. But if fear a lot of contidional code and the ‘old way’ holding back progress.
As this is a pretty big change for the frontend maybe we should just create project and a seperate branch to develop this on.
from architecture.
Maybe the migration logic from group-based views to a seperate frontend config should be done in the frontend too.
The logic to determine the views based on the groups is already in place there.
from architecture.
So we already have a frontend component, so that's easy 😉
We can make it opt-in, have a new key under frontend config that includes a new file.
Frontend will check if config enabled, if so use that, otherwise fall back to old render logic.
The only thing we need to change is that we need some code to use our config instead of our current auto sorting algorithm
from architecture.
There should be a config object (under ‘hass’ object?) that has the view config.
Our group-based view algorithm should be used to initialize that object (with the new scheme) if no other config is present.
That way we can start changing the frontend to use that object/schema without any need to change the backend. And that way it’ll be opt-in and fully backwards compatible. (The only thing is that new features won’t be added to our groups based view/sorting algo)
from architecture.
You are correct if you are talking about the hass object in the frontend 👍
from architecture.
We can have it live under the config object in hass. I am planning on making the websocket API extensible, so we can send it over the websocket connection.
from architecture.
Related Issues (20)
- Splitting tests files in smaller files in components/modules tests HOT 1
- Feature Request HOT 1
- Add favorite position to Cover entity HOT 10
- Add feature light distribution control to LightEntity
- Add new CURRENT_HVAC constants HOT 1
- Add Home Appliance entity
- Officially allow enities to set their entity ID not based on their names HOT 2
- Custom Device Class for Binary Sensors HOT 9
- Installed homeassistant supervised on my Linux machine; can't get it to run. HOT 1
- Expand enqueue options media player HOT 2
- Extend Rest API - unique_id HOT 3
- Add "status" as an attribute to CalendarEvents HOT 5
- Add list of (upcoming) calendar events to templating HOT 1
- Creating automations on the fly HOT 1
- Optional health check HOT 2
- Open letter for improving Home Assistant's Authentication system HOT 7
- Add device_class Heater HOT 2
- Area Units HOT 3
- New Device class for Reactive Energy (varh) HOT 1
- "Lost" device HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from architecture.