Home Assistant
Nested Areas #172
Replies: 10 comments 17 replies
-
I. Prior ArtAs Jörg W pointed out on the 2020 Why the heck can’t areas be nested? , @balloob has weighed in on nesting Areas in 2018-19 home-assistant/architecture#94
Further discussion by the devs took place at 2023-24 Add the concept of floors #1021 Related from the HA community:
II. ArgumentIn light of the robust arguments by no less than the Founder and President of HA and key devs against Nested Areas made earlier, it made sense to keep the Areas simple for a time to see where the community takes it. Having assigned everything to its respective areas, I was able to massively reduce the number of redundant automations (same stuff, different room) by targeting "same area as the trigger was in": That lowly little template hints at the much bigger notion: Areas hold the key to make automations MUCH more portable & reusable among us! Which, for the most common use cases, can shift us users away from blank-slate, one-off tinkering, solving the same problem 1000 different ways 600 of which are legacy, and towards more collaboration opportunities, putting our heads together refining common blueprints. Imagine a new user spinning up their fresh new HA for the first time, and instead of a blank slate being asked "Is this for a House, an Apartment, an Office, a Restaurant - or start blank?". Based on selection, a template / super-blueprint is loaded with common automations already in place - just add your devices to the correct areas. Once you do, they just start doing the right thing, effortlessly, based on the best of the HA community experience encapsulated in those blueprints. The user can take it from there, not from a blank slate but "standing on the shoulders of ... a bunch of other guys and gals who've done this before & put their heads together". But why nested areas? Because it enables semantics and context and lay of the land - it enables a smart home to actually know itself. In a flat list implementation I can name my kitchen area We're talking having the lowest-level areas defined pretty granularly: down to parts of the livingroom, work stations in the kitchen, individually-lit sections of a walkway, or even steps on the stairway, with spatial relationships between them & their peers (what peer area is to my South - SW - West - NW - ... or up the stairs / down the stairs) - being one and the same with the motion radar detection areas. On top of those baseline mlost granular areas, have 3-4 levels of area hierarchy roll-ups to the top level "Everywhere" this HA instance manages. The higher Area levels would be semantically tagged - am I a complete room, a suite of rooms or a floor, a flight of stairs; am I indoor or outdoor; am I public-access or guest-access or family/team-access or restricted area, etc. YES, a "Floor" would be a type of area - that HA understands is a floor. Potentially, a Zone might also be folded into the hierarchical Area paradigm. Imagine your home inferring your intent-in-context based on past patterns, and lighting your way ahead of you even including areas that don't have motion detectors because it knows you'll likely pass there. The more granular the areas, the more fidelity those patterns will have - meaning, confidence on the detection side and finesse on the action side. But without the less granular roll-up / parent areas, it becomes tedious for the humans. I don't want to manually turn off the lights in all 15 sub-areas of the kitchen that are one and the same with the mw radar motion sensor areas, much less list them individually in an automation (goodbye, those blueprints). So we need to have it both ways (very granular areas AND room / suite or floor / house-level parent area roll-up). We're asking to have it both ways. I support this Nested Areas feature request by @wildekek . |
Beta Was this translation helpful? Give feedback.
-
|
This post https://www.reddit.com/r/homeassistant/comments/1hkkcv9/virtual_or_nested_areas/ highlights some of the reasons limiting the use of "flat" Areas as implemented in HA currently. Nested Areas can help the smart home to "know itself" if the areas are semantically tagged, including:
This metadata that lets HA actually understand the Area's intended use, can enable automations that create useful smart home behaviors purely based on Areas (whatever the sensors or lights or media players etc assigned to those areas, without hard-coding those devices' entities either in Triggers or Actions). That'll make those automations reusable between the rooms, and, more importantly, among the HA user community, whereby we can collectively refine the blueprints vs individually reinventing the bike for each room. Related: https://discord.com/channels/330944238910963714/1351529028112224359/1391476666978668737 |
Beta Was this translation helpful? Give feedback.
-
|
As a new user (in the first few days of using HA) this was the first thing that struck me. The lack of a Home wrapper into which Areas could be put. This was apparent to me as the first thing I did after launching and seeing the easy discoverable devices was start the Tuya integration as I have many Tuya compatible devices already deployed in 4 properties. I've read much of the debate and I see the complexity, but I can also see a clear need for a layer representing a Property or Home, underneath which are areas. While I understand the concept that each property might have a home assistant instance locally which might be accessible remotely, some of the integrations break this concept as soon as you do them. Tuya supports a concept of a Home and in the Tuya app these are separated. So if you have a HA instance with Tuya integration then the devices appear in a flat hierarchy. I tried using labels to separate them but it was not great so then I separated them by making an Area for each home and making that part of the device config. Then I used the Area dashboard to separate them. But it would have been more elegant if HA could have imported the Home label. A counter example is the MyDlink app where there is no such hierarchy. So the cameras for all the homes appear together. But the count is low compared to sensors and other items so it mostly works. For these I used the generic camera integration to import into the local instances of HA. HA can become the Master over many integrations, offering a clear added value to provide a 'one pane of glass' view which would be enhanced with some form of nesting. I agree with the concerns of many deep nestings, granularity and overlaps. But a Property or Home is a thing with a clear role in a hierarchy, placeable on a map. Just something to consider, so I support this feature request. And added my own request in the Tuya integration to allow for import of the Home tag. |
Beta Was this translation helpful? Give feedback.
-
|
Piggybacking into this idea, we should also be able to have floors act as a parent area of all the areas within that floor. Reason why is that sometimes we have devices or automations that are in, or target an entire floor, rather than a single area. For example, I can have a scene or automation that sets up night lights for upstairs, or downstairs. |
Beta Was this translation helpful? Give feedback.
-
I already have multiple situations where I misuse floors, for example:
|
Beta Was this translation helpful? Give feedback.
-
|
Again a new reason why we need this: Purpose-specific automation triggers & conditions. When selecting a purpose specific trigger, areas become first class citizens in your trigger now. Trigger example that was in the live stream for release 2026.4: Smoke detected > Area = House. The house area does not exist at the moment though and was just an area made for the demo, so in practice this does not work. The use case is excellent though. It would be great to have a root area based on the name in Settings > Home information > Home Name. EG "My house". Then all subsequent areas could fall under this root. |
Beta Was this translation helpful? Give feedback.
-
Would it not be more logical for the root to be ”My Property” since you can have several buildings on your property other than your main house? Should you then be able to have multiple root areas so if you have for example a detached garage then it can also have areas for example bike shed, storage room, and workshop. I am sure others have other types of detached buildings as well, like maybe a barn, a growhouse, a conservatory or winter-garden, a play-house, or different types of sheds or outhouses, etc. That is, you could have ”the main house” then other smaller standalone buildings on your property, and those are not ”floors” inside the main house. Then many people with houses have an outdoor garden, with can alao have subareas, which you do want to define as separate areas in order to automate automated watering of the lawn or direct the lawnmower robot or other type of garden robot. There are also snow-blower robots now so maybe you want your driveway as a separate area from your parking spots so you can direct a snowblower robot to clear the parkingspot when the car is away. |
Beta Was this translation helpful? Give feedback.
-
Absolutely agree re: multiple root areas. As far as the name, I believe we're onto something delicate here, in that it combines 3 separate notions: how we label the thing, the level of that thing in the overall area tree, and the semantic meaning of the thing - is it indoor or outdoor, a standalone structure or part of a building, and other relevant metadata tags mentioned in the earlier comment here. The label would be per the user's whim, and it's the level and specific semantic tags (from a well thought-out standardized set) that enable HA to understand the actual function of the area and its spatial relationship to all the others. Those two things would enable whole-property super-blueprints to be defined with a bunch of useful automations ready to be enabled - just define/semantically tag the areas and add devices to them. One more thing about the areas I'd like to see eventually (not necessarily day one) is zones rolled into the area hierarchy and with a twist of possibility of areas being shared among HA instances (either bidirectional sync or unidirectional / delegation / read-only). Besides multiple properties for things like AirBnB, this can be neighborhood community watch or common areas in a condominium or coop or public park / garden (that nonetheless needs watering, and where people from different units take turns taking care of it). So a soil humidity sensor and camera and other goings-on in that little garden can be cleanly shared among their HA instances. |
Beta Was this translation helpful? Give feedback.
-
|
I think another good use case nested areas would be to direct vacuum robot (or lawn robot) to a specific sub-areas within rooms (i.e. a sub-area inside a room). The would allow for example to give voice command for vacuum robot to ”clean in front of the cat litterbox” or ”clean the babys spot in the dining room”. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, spotted that @nielsrowinbik has now added a very relevant issue tracker to the Home Assistant roadmap about models for physical space: Note that references this feature request as well as this Discord thread that sparked from the 2026.4 release party chat: |
Beta Was this translation helpful? Give feedback.
-
|
The following things should be considered when changing areas: Beginners vs advanced usersWe all think differently, so what works for me might not work for someone else. Predefined dashboardsThe new default dashboards use the predefined context of areas and floors to provide a very decent dashboard layout. This is something which needs to be preserved. GroupingAreas are a common way of grouping and finding devices, entities and automations. Many users use areas beyond the originally intended concept of physical (parts of) rooms. AssumptionsHome Assistant appears to assume areas are always part of the house. If a user creates an outdoor area with weather data, radar image and lights, the devices will be included in the default climate, security and lights dashboards. Backwards compatibilityThe impact of an backwards incompatible change can be significant. Scenarios and edge cases:The following use cases can be considered: Connected roomsConnected rooms such as an open kitchen connected to a living room can be considered 1 area for some situations and 2 areas for others. It's currently not possible to group the rooms. Outside vs InsideThe garden, porch or balcony are areas which can have lights, motion and temperature entities which are relevant for the area but which are not part of the house. Non-house areasAreas such as a garage, shed or car are marked as such and not considered part of the house. They are shown separately on the default dashboards. Virtual areasIt's not uncommon to use virtual areas for grouping of concepts such as network devices, a homelab or utilities which affect the whole house. DoorsA door is commonly part of 2 rooms. This is currently not supported and requires workarounds to model correctly. Options0. Current Floors & AreasAreas are a way of grouping devices. 1. Outdoor FloorAdd a "floor" for outdoor. Areas such as porch, shed and garden can be related to this floor. 2. Context specific AreasAdd extra information to areas. Extra properties are added to areas to provide better context and allow for better decision making. 3. Add (Hue) ZonesPhilips hue allows zones to be defined as an more advanced way to organize devices. 4. Nested areasAs described above. Areas can contain devices and other areas. 5. Buildings / Floors / AreaIt is currently assumed that there is 1 build which all floors and areas are part of. By adding a building which areas can or cannot be part of would provide useful context. 6. Multiple areas per deviceAllow a device to be added to more than 1 area.
ConclusionLooking at which solution meets which scenarios, nested areas do not seem like the best way forward because it is probably not backwards compatible with the default dashboards. Adding more specific concepts such as "building" and allowing an area to be part of the building or not be part of the building would satisfy several use cases with minimal impact. Adding less specific concept such as the zones from Philips Hue could provide additional flexibility which the context specific areas do not provide. It could act like a group of devices. The benefits are however rather small. |
Beta Was this translation helpful? Give feedback.
-
|
I see how having extra context with certain constraints would allow many of the backwards compatibility issues to be fixed. It's just that it's a lot more work for both developers and users. Keeping the current flat area structure as it is guarantees backwards compatibility without the need to make assumptions about the context of an area. Allowing certain areas to be placed outside of the main structure would resolve many of the use cases. Nested areas are very nice and powerful, but also complex and overwhelming for new users. Most problems can be fixed using a simpler solution. One of the simplest additions is to add an "outdoor" floor. I'll add this to the options as well. Note that adding area context or an outdoor floor still allows nested areas to be added in the future. |
Beta Was this translation helpful? Give feedback.
-
|
Right. I see your concern. Well, in that case we can have any current AND new areas the user creates by default tagged as room-level, and any floors the user creates by default tagged as floor-level areas, keeping it looking and feeling 100% the same as now, for any user who wants to stick to the old paradigm. However I must say, a significant part of new-user HA overwhelm comes down to:
Nested and tagged areas can eventually address 1 via whole-house super-blueprints described above, and streamlining the zones / floors / areas / mmWave radar areas into levels of a hierarchy is frankly easier not to mention they can streamline many automations if scope / area-level escalation methods are available such as "triggered area's whole floor" or "areas between the triggered mmWave area and nearest bathroom" |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the table @AJediIAm I have the following thoughts.
Nesting Areas would be no longer required. To view these a tree-like structure could be used to open/close certain parts of the Property. |
Beta Was this translation helpful? Give feedback.
-
Zone is already taken and used for larger zones for geolocation like your home, work place, school, grocery stores, etc. https://www.home-assistant.io/integrations/zone/ So nested-areas or sub-arenas are still wanted for different sub-areas like a closet, dining area inside the kitchen, or kitchen-island. And much more for outdoor areas like font lawn, backside lawn, patio, etc.. (if you have a lawn mower robot then you know that you need to devide your yard and lawn in to different sub-areas. https://www.home-assistant.io/docs/organizing/ Also, as you see, there is no such thing as "property", and if there was then what about different houses/buildings and different outdoor areas on your property. For example you can have a large property with several buildings all controlled from a single instance of Home Assistant and on that property you can have a yard which in turn is also devided into different outdoor sub-areas. |
Beta Was this translation helpful? Give feedback.
-
This is of particular interest to me. In my home, the kitchen, dining room, and living room are one open space and while the kitchen has its own lighting circuit the dining room and living room share one which means I have a single smart switch that controls the lights for both rooms. That one light entity should be considered part of both rooms, but at the moment you need to use a group or other work around to create a duplicate entity that can be placed in another area. Also since this area is one open space, it would make sense for it to share things like climate sensors and devices. But at the same time, these are clearly three distinct spaces with clearly distinct purposes and making them just one "great room" would be a bit silly. The same issue comes up for door sensors and locks. Does the front door belong to the porch or to the foyer? Does the garage door belong to the garage or the hallway? In these cases you can arbitrarily choose and it's probably fine, but it can lead to confusion later if you don't remember how you organized it. This can also feed into those transitional areas like stairways. My house is a split level, and there is a short stairway between the kitchen and the den, and this stairway has its own light. This light provides significant illumination to both spaces, so if I want to turn off the den lights to watch TV I also want to turn off the stairs, and if I turn on the kitchen lights in the morning I expect that light to come on too. There are ways to automate this already, but it's inelegant. As another example, the "den" is a room that I've literally divided into two spaces with a large Ikea shelf so that one side is the "den" and the other is my office, but like the living room and dining room these spaces are sharing one circuit of ceiling lights and are equally impacted by any climate entities. But the TV is definitively in the "den" and my sit/stand desk belongs only to the "office" and these entities shouldn't be shared. |
Beta Was this translation helpful? Give feedback.
-
|
A remark I also made in Discord: Do we really need such a rigid structure where:
This concept has already be tried with labels, where you can "tag" as many label as you want to anything. The same concept could be pushed to floor / areas:
=> This would solve many nesting issues by allowing an entity to be in more than one area User could create "non physical" floors or area on purpose (many example and possibilities):
I personaly see very few drawback as this logic already exist for label and works well there:
Keeping only floor / area "type" would not break anything (especially overview dashboard) , but allowing tag instead of assign would allow many new opportunities. Floor and area names could be changed, but it is another debate. Many things can already be done with labels:
|
Beta Was this translation helpful? Give feedback.
-
|
To extend a little bit: To better reflect this flexibility, I suggest slightly evolving the terminology:
To be 100% clear I am NOT saying we should remove the 2 level architecture to replace it by labels ! I am just saying that with a membership logic, the 2 level logic could be already sufficient for many cases. And only some corner cases would require to deeply nest areas into sub areas into sub areas. Maybe those corner cases do not require to change all the UI and can be managed by 2 level floor/area (context / space) membership + labels. Some further UI modification will probably be needed afterward, especially for overview dashboard, to not duplicate to much area display when member of several floors, for example:
|
Beta Was this translation helpful? Give feedback.
-
|
Multiple areas per device makes such areas similar to tags that already exist. The entire point of areas is they represent the actual locations of an HA-managed property. And locations are hierarchical. A master suite is a part of a 2nd floor and contains a bathroom and a bedroom (rooms), and the bathroom has his and her sink area plus toilet plus shower, and a bedroom contains two closets. In addition to a hierarchy, spatial relationships exist between these places. A master bathroom can be North of the master bedroom and navigable from it (i.e. a door / passage exists directly connecting these places). A guest bathroom shares a wall with master bathroom, but is NOT navigable directly from it. The master suite can be semantically tagged that it's indoors, year-round, family access, non-work. Multiple areas per device as the alternative to true nested areas, solves one issue bur robs us of all these relationships between places and their meaning being knowable to HA for future smarts. |
Beta Was this translation helpful? Give feedback.
-
|
All location are not hierarchical. But many other exist: I have a air conditionning system that is shared through tubing between 3 rooms. Why can't it be assigned to those 3 rooms? Nesting more than 3 levels is in my view over engineering and I do not see the true advantage. If you are at this level that you need to separate a bathroom from main room, you can do it differently and do not need HA to do it for you. I guess you do not use overview anymore, thus do your custom dashboard with the nesting level you want... With nested areas into nested area, everybody will then complain that there is too much clic in their dashboard to access a bathroom switch. That seem to be so far away from most of the user cases. When proposing multiple area per entity, I never said that it should be exclusive to floors. I just said that with the existing 2 levels, it could already cover many cases. But if an entity cannot be assigned to more than one area, I think we are missing an important gate and create an outdated rigid folder structure again with patches on top to create "relationship" between areas... |
Beta Was this translation helpful? Give feedback.
-
This make sense for "sorting" entities. But not for "using" them. If to access a switch on a dashboard you need to navigate first to 2nd floor, then to master suite, then to bathroom to be able to clic on the light switch that is not good ! IMHO more than 2 levels is too much.
Multiple floor (rename it "context") per area as I propose above bring this back if needing to build relationship between areas, even more it allows to create as many membership as you need :
Then showing or not membership on dashboard is another question. But quite quickly we will need a notion of displayed floor and not displayed floor, just for dashboard. |
Beta Was this translation helpful? Give feedback.
-
I don't see how. A closet door is a door to access the closet from whatever larger/common area. The closet door hence goes with the closet not that other area. No ambiguity. A bedroom door, by the same token, belongs to its bedroom. Ditto a bathroom door. Ditto the house front door. It's whatever the more particular area the door opens to, that it belongs to. Granted, there can be edge cases such as doors connecting adjacent hotel rooms, but even these rooms are intended to connect the rooms into a larger suite - hence that suite makes perfect sense as a roll-up of the individual rooms, since when they're joined together, the guest may want to manage them together as opposed to / in addition to individually.
Because it would lead us and HA to believe these rooms are separate HVAC zones. So someone may be adjusting air conditioning in their room to be hotter / colder and unwittingly affecting folks in the other rooms. They get too hot or cold and go into a dashboard and see that someone has changed THEIR thermostat from under them, set it back. Unless there's some implementation kludge or manual label (which is even worse) making people aware that that HVAC area is shared across more than their own room, and changing it may affect other people that a user who say can only see their area, would not even see. By contrast, nested areas would represent the physical world more directly / naturally. If a thermostat zone or a CO2 sensor applies to a whole master suite or a floor, it should be manageable at a master suite or a floor level, respectively, and by whoever is permissioned to manage that level entity (relevant: #22 , #13 )
OK so we've floors and rooms and we've touched on a suite of rooms (like bedroom + bathroom + closet) as the use case in-between of those. That's three levels. Why not the whole property? Why not everything indoors and everything outdoors of that property? Why not my desk, where mmWave radar detects me and which has a light shining on it, on its own dimmer, and a table lamp? Why not individual steps on stairs or sections of a walkway in my backyard? |
Beta Was this translation helpful? Give feedback.
-
|
This is your way of thinking, allow other to think differently please ! A ceiling light shared between kitchen and dining space should be controlable both in a kitchen space and in a dining space. And yes when controling light in one place it will affect the other, that is how our houses are built. And it affects a lot of people. Doors are another example. A closet is a bad exemple, it is like a fridge door... Nobody really walk out the fridge... Considering all door with fridge door in mind would be crazy... Your vision is not the way I see a house. And while I do not say that nested might not be needed, I strongly need to have entities belonging to more than one area, and not only doors. But not only, we should open that to floor ( rename floor in context to better get my point): Nesting is one solution with some advantages.but does not solve all issues. How to define south facing room if you can not have this context span accross floors? You need new notions, new relationships. Please open your eyes and consider you are not the only user. And not everybody need a tree folder rigid structure with n level that alone does not solve many problems. Two levels ( context/spaces) with as many membership as needed is another one, that opens some possibilities that nesting can not without hacking. But it does not solve your n- level hierarchy issue. One level taging only is too limited. On this I fully agree! If the perfect solution exist, it would be implemented by all solution already... |
Beta Was this translation helpful? Give feedback.
-
By all means! Yours is a valuable perspective, to both enrich the nested area notion and make it more robust by virtue of having survived a good argument! :)
My small business is serving NYC's hospitality industry, and I've seen things go on in walk-in fridges that I can't unsee :-) Anyway, I think a closet / fridge door you brought up is a GREAT example of your point. You absolutely gotta be able to control those from either area they connect, seamlessly and easily. Which, I respectfully submit to you, ought to be a matter of implementing a clean hierarchy properly (i.e. a door connecting two spaces ought to be readily & conveniently navigable both in terms of user interface and programming automations. Your fridge door (love that example) being left open for longer than usual should be able to alert in the kitchen not in the fridge lol. But to the hierarchy point, if the kitchen "fridge door left open" alert doesn't get a response soon enough, wouldn't it make sense to then promote that alert to the kitchen's parent area?
I absolutely 100% agree with this. I myself wouldn't want nested areas if they're implemented so crudely / naively as to rule out the office door being able to be targeted from both sides in an automation. This is that "enrich the nested area notion" I said i the beginning. I now begin seeing it your way. Nested areas will be pretty shite UNLESS they also give us ability to target adjacent branches cleanly and natively. children(thisArea), siblings(thisArea), parent(thisArea)
I absolutely 100% agree with this too! Come think of it, nested areas will be a nightmare without this orthogonal way of organizing spaces and features, but in a way that works with areas. And definitely yes to it being North South East West (and southwest etc) aware. On a moving vessel may have to also support port / starboard / fore / aft way of doing it instead.
I have, with your help. We should be able to do lights(areaSearch(areaParent(thisArea, "floor"), "bath*|toilet")) to get all the lights between me and the nearest bathroom on my floor, to light them up. The same could be done with doors (unlock or highlight the right doors). ACtually this pseudocode doesn't really do the nearest bathroom, so there should indeed be a way to find the nearest area of a given type to the area in question. Nearest not naively geographically (we can't walk through walls) but being aware of which areas connect with each other in which direction (there's your North South East West) in a way that's navigable. And also return a list of entities of a given type on the way. This can be for fancy uses like lighting up on the way or unlock doors or have my music follow me as I walk!
Yes! And also for our purposes to work, tagging should be semantic (HA understands the meaning of these special - spatial and functional - tags. "North" shouldn't be merely a string to HA. It should know that it's in the opposite direction from South, etc. So it understands what areas are "neighbors" and whether they're connected in that direction in a way that's navigable without breaking walls or jumping floors :) The same should be true of other semantic tags that have specific meanings. Code shouldn't have to guess or pattern-match bathroom vs powder room vs toilet vs toilets vs loo vs lavatory vs other foreign languages. It should be a special multi-lingual tag that HA knows is a "bathroom" as a concept. The same should be for other such "special places" and common uses. Work, sleep, kitchen, etc. Semantic and understood by HA so it's not like a random string "kitchen" or "ktichen" or "pantry" We're asking for a lot here, so I for one am not surprised it's not yet been implemented. But given how HA is maturing and evolving by leaps and bounds lately with TONS of impressive new developments, I'm optimistic looking forward! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for disagreeing and the clear examples. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe your core improvement
I would like to nest Areas in Areas. This way we can make devices and entities easier to find and simplify naming. Let's get rid of names like 'Guesthouse Bedroom Walk-in Closet Light' but nest areas like so:
Area: Guesthouse > Bedroom > Walk-in Closet
Device name: Light
Current limitations
Currently, I can't group areas per building, nor can I add a specific place inside an area. For example, when I have an open plan living room with a kitchen, the architecture does not allow easy control. Hence, I have to:
When I turn off all lights in the living room, I want the kitchen to be included. Not possible in this way.
Technical benefits
Additional context
Looking at the new device pickers and the focus on areas for automated dashboards, this would be a logical next step imo.
Beta Was this translation helpful? Give feedback.
All reactions