Vacuums rooms support

[glacial wolf]

A project to make vacuums suck less. Or more. Depends on how you look at it.

[hidden python]

Vacuums rooms support

[queen steeple]

Hi. We're talking about global support at the HA entity level, not at component level?

[glacial wolf]

Having this as an entity feature would be my current goal yes

[queen steeple]

We should probably also a add map support like Apple iOS does:

A map is a full or a partial representation of a home, known to the device. For example:

• a single level home MAY be represented using a single map
• a two level home MAY be represented using two maps, one for each level
• a single level home MAY be represented using two maps, each including a different set of rooms, such as "map of living room and kitchen" and "map of bedrooms and hallway"
• a single level home MAY be represented using one map for the indoor areas (living room, bedrooms etc.) and one for the outdoor areas (garden, swimming pool etc.)

Each map includes one or more areas

[glacial wolf]

You could currently already show an image entity for this

[queen steeple]

Have you been able to discuss architecture to identify which methods can be added to standardize the various integrations?

[hearty spade]

A starting point for discussion: https://github.com/home-assistant/core/pull/149315

[queen steeple]

What brand/model of vacuum cleaner are you testing?

[hearty spade]

I used my Roborock S7 to test it.

[queen steeple]

What do you think of Arthur's proposal?

[glacial wolf]

I will try to get back to this next week (or at least, not during beta)

[queen steeple]

Thanks

[queen steeple]

Hi,

I think we need to define a standard for implementing rooms/maps management for vacuum cleaners, because each integration implements it in its own way.

Roborock: get_maps
https://github.com/home-assistant/core/blob/dev/homeassistant/components/roborock/vacuum.py#L204

Miele RVC: get_rooms (draft PR)
https://github.com/home-assistant/core/pull/149728

Add clean_area action to vacuum #149315 (draft PR) https://github.com/home-assistant/core/pull/149315

Summary
Two actions seems required:

• Get rooms/maps to get mapIds and rooms
• Clean area() to trigger specific room(s) cleaning

[hearty spade]

There is no need for any get_rooms action. That is an internal detail and ideally should not be exposed directly to users.

[queen steeple]

So how do you allow the user to select the parts to be cleaned via the frontend web interface?

[queen steeple]

This is explained here for Roborock integration: https://www.home-assistant.io/integrations/roborock/#how-can-i-clean-a-specific-room

[hearty spade]

users should be able to select areas, the native home assistant ones, not some internal identifiers

[queen steeple]

Ideally, yes. But how do you match the API zones of a vacuum cleaner with those of HomeAssistant?

[hearty spade]

Users will make those selections.

Maybe it also makes sense to make some default choices, if the API makes some human readable names available, we can match those to area names.

[queen steeple]

At first, it seemed simpler to me to rely on the names and IDs of the provider APIs.
There seem to be a lot of dependencies with the frontend part in your proposal.

[hearty spade]

Yes, it would be simpler, but also a much worse user experience.

[queen steeple]

Sure, I agree.

[queen steeple]

Is that what you're trying to do with Xiaomi RVCs?

For my part, I would like to add the option to select areas for Matter integration:

• There are Matter attributes that contain the list of areas, maps and current area.
• There is a command that allows you to select areas.
  So I wanted to use this to enable selection.

[hearty spade]

That is how my PR works indeed, you select HA areas to clean in the clean_area action. To allow users to configure them first will require collaboration with the frontend team to settle on the exact UI for that.

[queen steeple]

Which version of HA are you planning to finalize? It seems there is a lot of work to do.

[hearty spade]

Yes, it's a long work ahead. It will require to:

• gather feedback from vacuum integrations maintainers
• prepare an architectural proposal and get it accepted
• adjust the base implementation and get it merged
• implement it in all the integrations

On the first point, since you seem to be knowledgeable in the matter integration:

• Are internal identifiers ints or strings?
• Do you have access to human readable area names?
• If you do, how are those set by users?

[queen steeple]

1. Are internal identifiers ints or strings? --> ints
2. Do you have access to human readable area names? --> There is an AreaInfoStruct Type for that in Matter specifications. The data from this structure indicates the name and/or semantic data describing an area. So human readable area names are not mandatory but most of the time, this is what is used because tags are not implemented at the moment.
3. If you do, how are those set by users? --> This is defined using the manufacturer's application.

[hearty spade]

Thanks a lot for all the answers. A couple of follow-ups:

• Ad 3. Is the manufacturer app using their own proprietary API for that or is that also done with matter?
• Is there a repeat parameter available so that each selected room is cleaned several times?
• Does the room order matter, can users define in what order are the rooms cleaned or is it decided internally by the vacuum?

[queen steeple]

• Ad 3. Is the manufacturer app using their own proprietary API for that or is that also done with matter? --> This is done outside the Matter ecosystem (via BLE or a cloud API).
• Is there a repeat parameter available so that each selected room is cleaned several times? --> There is no repeat parameter available in Matter specs
• Does the room order matter, can users define in what order are the rooms cleaned or is it decided internally by the vacuum? --> It's only a check list (list[uint32] in backend) so order doesn't matter.

[queen steeple]

The Matter specifications refer to “area” as internal IDs, but your POC PR refers to segments. Can you explain what these segments are?

[hearty spade]

That's just a vendor neutral name that corresponds to whatever the integration is using internally for that concept.

[queen steeple]

I think we need an intermediate step because we've been waiting almost 1 year for the addition of space management for Vacuum RVC:

1. define the name of the entity service and the data structure to be returned to manage areas
2. add a multiple selector in the frontend interface based on the entity data
3. add area management with synchronization between manufacturer areas and Home Assistant areas (in core and frontend)

[queen steeple]

We should also add a current_area attribute. This would indicate which room the vacuum cleaner is in. Matter has an attribute that provides this information.

[queen steeple]

Finally, there are also two useful attributes in the Matter specifications that could be included in the generic vacuum entity.

• EstimatedEndTime Attribute
  This attribute SHALL represent the estimated Epoch time for completing operating at the area indicated by the CurrentArea attribute, in seconds.
• Progress Attribute
  This attribute SHALL indicate the operating status at one or more areas. Each entry in this list SHALL have a unique value for the AreaID field.

[queen steeple]

For the frontend part, it should be possible to make a selection such as fan_speed_list but with multiple choices: https://github.com/home-assistant/frontend/blob/cdfd6431c3d3708a4c8a0dfc8922cfca8f3f3d9c/src/dialogs/more-info/controls/more-info-vacuum.ts#L172-L191

[queen steeple]

Hello. Let us know if you have any comments about the Vacuum PR 🙂

[glacial wolf]

Hah, beta is over and immediately 😂

[queen steeple]

When you have time available 😉

[glacial wolf]

Hehe

[tidal basin]

I got several comments but I think it should start in an arch discussion.

[queen steeple]

I agree completely. Have you done this before?

This goes in the same direction as Arthur's proposal.

[queen steeple]

@hearty spade Did you finish gathering feedback from vacuum integrations maintainers?

[hearty spade]

All communications happen in this thread. When people have time, they will respond here. Remember that it's summer, people are on vacations, etc. In fact I myself have a flight in just a couple hours 😄

[queen steeple]

I still don't see any response on this thread about other maintainers.

[glacial wolf]

Still need to check it, but I am mostly busy outside of HA atm 🙂

[queen steeple]

Hello. Do you know when you'll have time to look at this?

[hearty spade]

@queen steeple Do matter vacuums ever reset selected areas, like after cleaning is done, or are they set permanently?

[queen steeple]

From what I've seen, no, it doesn't reset at the end.

I'm waiting for the K11+ update to correct the bug and do a test.

[queen steeple]

That is why area selection must be implemented in the front-end interface.

[hearty spade]

Have you had the chance to test it?

[queen steeple]

Yes, well, there was the corrective update at the end of last week.

[queen steeple]

The reset does not appear to occur immediately after cleaning is complete, but probably several hours later.

So if you want to start cleaning several rooms individually and in sequence, you need to be able to reset the value or an area selector.

How can we move forward with the frontend now that we have services that work?

[hearty spade]

I don't think this PR should have been merged like that, I will talk internally about reverting it

[queen steeple]

I can revert if needed

[tidal basin]

Which PR?

[queen steeple]

https://github.com/home-assistant/core/pull/151467

[tidal basin]

Personally I think clean_area service should be provided by the vacuum component and not by the individual integrations

[civic stratus]

Should this be an architecture proposal? There has been a lot of discussion here, and it is a bit hard to re-read it all now, so it makes it hard to give feedback

I do agree that a clean_area service should be part of the vacuum component, as that is common nowadays.
I am not sure about forcing those to be HA Areas (I think I've read that suggestion). It would be very hard to map HA areas to vacuum areas. Also, there may be vacuum areas that I don't want to have as HA areas (users may split a room in 2 parts if one of those parts needs more frequent vacuuming for example. I am not fully against it, but I am not sure if it would be too complicated (implementation and UX-wise) to be worth doing.

[queen steeple]

@hearty spade wanted to start a discussion, but I haven't seen any response yet. I don't know if it worked out.

[hearty spade]

We want to merge Matter vacuum support first and after that think about making it a generic HA service.

[tidal basin]

That seems weird to make a service which then needs to be deprecated?

Or you mean without that service?

[hard bloom]

Just detailing another difficult implementation. In my roborock I have two different floors which are actually the same floor in my house. One is for mopping and the other is for vacuuming. The mopping floor has carpeted and rug areas set as no-go zones.
So, in essence, each room exists twice...

[tidal basin]

I don't think we should try to have floors and areas to link into the floors/areas of HA. they can be same but I do think in many occasions they are not and I don't see any benefits of trying to have them as such either.

[hearty spade]

I disagree. There's obvious value in Home Assistant having a semantically good understanding of such things. It allows us to offer better UI and UX in terms of both frontend and voice features.

[tidal basin]

If it was a 1:1 I would agree, but it's not and therefore I just see it as something very complicated with very little benefits.

Anyway, maybe there's something that could work so I'm open for seeing how this could work out

[glacial wolf]

I think it can help with things like cards or voice commands. The fact that you can tell HA that you want to vacuum area X, and that the vacuum knows where to go

Yes, in theory that's just a name, id map from the vacuum itself, but why not link them to HA areas when we can to make it even a little bit easier

[urban scaffold]

Kind of curious how you were thinking the frontend for this service would work. There is no selector that can dynamically show the vacuum areas. So you'd be limited to a free textfield and you have to type the area ids.

There's the area selector for HA areas, which could maybe be useful if you mapped HA areas to vacuum areas, though that would also offer nonsense like vacuuming the garden or the attic.

[glacial wolf]

We can always make a new selector or extend an existing one

but at this point I also think we have very specific selectors and then I want to raise the question if that is a good idea long term

[urban scaffold]

We don't really have any domain-specific selectors at the moment, which I guess is what this would be.

State selector almost get you there, but someone put a comment in to explicitly pre-ban this usage 😂

            # The attribute to filter on, is currently deliberately not
            # configurable/exposed. We are considering separating state
            # selectors into two types: one for state and one for attribute.
            # Limiting the public use, prevents breaking changes in the future.
            # vol.Optional("attribute"): str,

[glacial wolf]

we do!

asssist pipeline selector, backup location selector

color temperature selector

conversation agent selector

[hearty spade]

I don't think it would cause any practical problems if we were to just use a standard area selector

[glacial wolf]

the thing is that we don't support nested areas, so not all robot areas are mapped to a HA area

[hearty spade]

Do any vacuums actually support nested areas themselves?

[glacial wolf]

I don't think vacuums themselves care about if their area is nested or not

its more that you have presets, and they align with an area

[hearty spade]

Are you talking about any particular manufacturer now? Every vacuum that I have seen just maps the whole house and splits into non-overlapping areas.

[glacial wolf]

From what I understand you can create separate rooms in certain integrations

as in, I know marcel has one program that just moves the robot to a certain spot

[tidal basin]

I don't think you can have overlaps but you could have more than one map and thereby have overlaps

[hearty spade]

We will not support multiple maps, certainly not at first.

[glacial wolf]

I am not sure what a map has to do with this

[tidal basin]

What if my kitchen is split into two areas in my cleaner?

[tidal basin]

Everything is based off the map

[hearty spade]

Then you will map a HA kitchen area as corresponding to those two areas in vacuum

[glacial wolf]

yes, but In some integrations I checked, I would assume that we just have a name -> id value for areas, and that's it

[hearty spade]

We should not try to find weird workarounds around the fact that HA does not have nested area support

[glacial wolf]

I am not

[glacial wolf]

but even in this case, would we send 2 areas at the same time to the robot? Can it support it?

[hearty spade]

yes and yes

[glacial wolf]

Are we sure that that is the case with all integrations?

[hearty spade]

I don't think there is a vacuum on the market that you can schedule to clean only one area at a time

[glacial wolf]

I think my cheap ass roomba would have that limitation

I couldn't even map rooms

[hearty spade]

then it doesnt have a clean area support in the first place, so it doesnt count

[glacial wolf]

I need to check the smartthings capabilities, but I don't expect to pass in a list

[glacial wolf]

is this the switchbot or do you also happen to have a ST vacuum

[queen steeple]

For Smartthing there are checkboxes

[queen steeple]

Any Matter RVC

I don't have any ST vacuum

[glacial wolf]

I would be interested in your diagnostic data from the smartthings integration

[queen steeple]

I don't own this myself (SmartThings hub). Someone send it to me 🙂

[glacial wolf]

oh

[queen steeple]

We were testing Matterbridge RVC

[civic stratus]

that is a good point. why are we moving forward with one specific for matter if we want to have a generic one?

[civic stratus]

what if you want to clean only one of the sub-areas? one of the reasons that people may have for splitting a room is due to wanting to clean it at a different frequency (because one side has things that need to be manually moved before cleaning, has carpets, etc)

[civic stratus]

there have been discussions to make some selectors get context from the entities, such as showing a list of options dynamically from a select entity, for example.
it would not be impossible to make a select selector pick from an attribute on the vacuum entity. something like:

select:
  options_attribute: rooms

[urban scaffold]

That would be useful for some of the other services with presets (fan, hvac) as well.

[hearty spade]

That would be a limitation, at least until Home Assistant gets a proper nested area support.

[civic stratus]

While mapping vacuum rooms to HA areas is nice, it introduces extra manual work for the users. Instead of simply being able to select the area from a list, they would have the extra step of first mapping all the areas. If the vaccuum areas change (which is not rare), they would have to map them again. If the area ids change, the mappings would be lost.
Having the selector just show the list of areas from the vacuum makes it straightforward without any setup.

Considering all the downsides, can you elaborate on the advantages of mapping to HA areas @hearty spade ?

[hearty spade]

Vacuum areas should not change in a normal use case. I'd assume a typical scenario is that you first map the house and then just use the vacuum, so everything is stable.

The benefits are that instead of some internal name, we will know what native HA area it actually corresponds to.
This deeper semantical understanding will allow us to offer better user experience, for example in area dashboards and other frontend features or in the future with possible native HA floor map entity.
The immediate impact will be for the voice functionality as we will be able to fully support it with a nice intent, that provides all the voice functionality, including features like aliases and support for languages with more complex grammar, that we are currently working on.

[glacial wolf]

I think a good benefit would be having some kind of quick action. Currently you assign your vacuum to where your dock is. But that doesn't explain what the vacuum can do. So if HA knows that it can vacuum the kitchen. It can show something on the kitchen area card or dashboard to vacuum the kitchen without the vacuum being in the kitchen

Nvm that's what Artur just explained

[civic stratus]

thanks to both for the inputs!
yeah, I can see how voice would benefit a lot from that. For dashboards it is not so straightforward IMO. On one side it makes it easier to provide some automatic dashboard features, but on the other side introduces some extra setup.

to be clear: I am not saying we should not do it! just trying to weight both the pros and cons. It is no good if we have nice dashboards but then users don't setup the vaccuum areas because it is cumbersome or they are not stable. but I do agree that if we can sort that out, its a good approach!

Vacuum areas should not change in a normal use case. I'd assume a typical scenario is that you first map the house and then just use the vacuum, so everything is stable.

I've seen it happen recently with an Ecovacs. For some reason a misplaced chair made it split the dinning room in 2 🙃
I've also saw it happen with an old roborock (but not frequently)

But we could eventually also account for that and somehow let the user know that the vacuum areas changed.

[tidal basin]

Roborock resaves the map on each run. Normally that isn't changing anything and the id's remain.

[glacial wolf]

cc @tender vine @night turtle @wary thunder Let's involve the codeowners of roborock and Miele as well

[night turtle]

Hey! I’ve slightly explored this a couple years ago but there are a lot of quirks. I have skimmed previous conversations in here, but I likely missed a lot of conversation.
There’s a potential many to many relationship between “rooms” and “areas” in HA. one area could have multiple vacuum rooms, and one room could theoretically contain multiple HA areas. No matter what, I can think of an edge case that makes the system “wrong”. If one room contains two areas, and I tell home assistant to clean a given area, the vacuum would end up cleaning two areas because their room contains both of those areas.
Or if the vacuum is in a specific room, but that room covers two areas: which area does it show up in on HA, both?
Either a system has to handle all the edge cases, or it needs to potentially limit the users implementation
As far as Roborock’s map updating goes, it will infrequently change. Perhaps on any significant change(i .e. New room) a repair should be created so the user knows they need to fix their mapping. But some users add the vacuum to HA before they do the first scan, so that also needs to be handled

As well, has there been any thought into making the idea of a room more generic? Are their other domains that may benefit from the idea of mapping rooms to areas outside of vacuums(sound systems or security systems?)

[night turtle]

Also some users will bring their vac up and down stairs and change the map, so rooms need to be completely dynamic, i.e. what rooms i can currently access

Ideally, rooms should also be able to support coordinates in the future. The obvious next step after room support is automatic floor plan support. If the vacuum is able to provide bounding coordinates of an area, we can automatically make a floor plan that the user can use to see which their vac is and clean specific areas

I’m sure this is all stuff you all have already talked about but figured I’d mention anyways

[tender vine]

https://github.com/home-assistant/architecture/discussions/913 and https://github.com/home-assistant/architecture/discussions/950 capture discussions

would be great to solve this as well as enabling a map card in a more general way (e.g. unifying w/ what ecovac does)

[queen steeple]

Have you managed to agree on which selector to use for the areas?

[hearty spade]

When it comes to Matter support, the first thing is to align the behaviour in the code with that of other integrations.

[queen steeple]

To my knowledge, each vacuum integration has its own behavior, which seems difficult to me to apply

[hearty spade]

The plan is to make a generic clean_area service for vacuums, in order for Matter to be included it has to behave the same as other integrations. I outlined that in the PR already before.

[civic stratus]

I was also concerned about the multi-map support. But I think that can be abstracted by the integration by encoding the map in the segment id like segment_id=f"{map_id}-{room_id}. The integration may also have to store/persist them, so that when the users switches maps they are not dropped.
So the current proposal still works fine for multi-map

[night turtle]

I think it makes sense for HA to store/persist them rather than each integration having to build their own storage. But maybe that's too much complexity.

[queen steeple]

Have you been able to make any progress in the discussions regarding the multiple selector for areas?

[queen steeple]

How can we move forward on this issue?

[astral dagger]

Let me fill the silence with thanks. I really appreciate that this is planned to come to HA. I had high hopes when matter 1.4 brought the room feature lately and it's great to see this is discussed here.

I'll now go back to silent/reading/watch mode.

[civic stratus]

Hey! So, this is not stuck nor forgotten! 😄
Since this is a change that depends a lot of having a good UX for mapping areas in Home Assistant, the UX colleagues are also taking a look at it.
It takes a bit more time, but this way we make sure that the core architecture actually allows for a good user experience!

But I think we should have something very soon 🤞

[tidal basin]

Soon ™

[civic stratus]

So, is 2 months Soon™ enough? 😆
The proposal for the new vacuum.clean_area action is now approved and @hearty spade is already implementing it: https://github.com/home-assistant/core/pull/149315

He also has a custom component implementing the new stuff: https://github.com/arturpragacz/hass-cc-dreame-vacuum/tree/clean_area

So, if anyone wants to start adapting integrations to it, please do 🙂

[remote lotus]

And if you are interested. Designs have been finalized before the holidays. We have 4 flows:

• New robo vacuum integration flow
• Second robo vacuum flow with multiple maps
• Repair flow
• Edit flow

When a user adds a vacuum that includes rooms, we trigger a dialog to map those rooms to Home Assistant areas.

For integrations with multiple vacuums and/or maps, we display the mapping across multiple steps.

If Home Assistant doesn't recognize a vacuum's map (for instance, when you've added a second vacuum or modified an existing map) we show a repair notification to prompt remapping.

Users can edit their room-to-area mappings anytime through the entity settings dialog.

[queen steeple]

Thank you for sharing this.

[queen steeple]

When can we expect this frontend part to be implemented?

[remote lotus]

Artur knows more about this. He will be back next week.

[tender vine]

would love to integrate this in roborock

[hearty spade]

@random crystal is working on the frontend. Ideally we would like to make it for the next release.

[hearty spade]

The backend is unlikely to change much at this point (although depends on reviewers obviously), so you could try giving it a go already.

[night turtle]

@hearty spade can you ping myself or Allen when the PR slows down a bit more and seems mainly stable? Happy to implement for Roborock but want to make sure we don’t have to make any big changes

[astral dagger]

@queen steeple are you planning on resuming your previous work on area-based vacuum cleaning for Matter?

https://github.com/home-assistant/core/pull/152410

[queen steeple]

Yes, once the generic implementation via the entity is complete.
At the moment, I'm busy working on Matter Thermostats.
Did you want to open a new PR to revive the topic?

[astral dagger]

No, I wouldn't be able to code this. Just a consumer with regards to this particular feature hoping to finally make better use of my K11+.

Glad to see, this new feature is considered already for Matter. Thank you

[queen steeple]

The frontend must also be implemented for this to work simply without going through service calls.

[tight wren]

hey, just sticking my head in to ask some noob questions.

The Dreame vacuum integration was the first HA integration I set up, and from what I recall, it wasn't the most stellar experience. Where does this initiative slot in? What pressure does it take off of the individual integrations?

[astral dagger]

True but being able to create automations is a great first step away from static cleaning schedules in the switchbot app.

[queen steeple]

Have there been any recent developments on this?
Has the vacuum entity been finalized for the core part?

[astral dagger]

The backend PR seems kinda complete with not being in draft anymore and all comments resolved. Just needs some final reviews. The frontend PR currently says it's waiting for the backend PR to be completed.

Interestingly the backend PR also has the "waiting for frontend" label....

[queen steeple]

It appears that the documentation is missing for the code section.
https://github.com/home-assistant/core/pull/149315

[astral dagger]

I hope this gets traction. So close and only 2,5 weeks til next beta.

[hearty spade]

@night turtle @tender vine @queen steeple
Core PR has been approved.

[queen steeple]

Great news

[queen steeple]

Back to draft

[hearty spade]

It's waiting for frontend and docs.

[hearty spade]

And it's merged.

[queen steeple]

I did a quick test and it seems to work. Here is a draft PR:
Adding CLEAN_AREA feature to Matter vacuum entity
#163570

[queen steeple]

The mapping appears in the vacuum cleaner entity settings:

[queen steeple]

Has a maintainer of another integration started integrating this new feature?

[night turtle]

Started but not quite far enough yet. On my plans for this weekend

[night turtle]

Added for Roborock here: https://github.com/home-assistant/core/pull/163760

Wasn't quite sure how to do some of the tests... so if anyone has any ideas let me know!

[astral dagger]

@hearty spade Since you're also involved in Voice, do you know when rooms support will be available as Assist intent? @broken edge and me were both watching this thread and since we're 50% of the DE language leaders, we're eager to provide the DE sentences for that.

[hearty spade]

Possibly next release, we will see.

[willow garnet]

Seems working in voice assist; device cards do not have options for areas

[astral dagger]

Yeah, with AI-based assist it does - but that was to be expected

[tender vine]

I wonder if the current repair issues should explain a little more about what's going on?

What is the purpose of the repair issue, what is a vacuum segment, etc (i won't be able to send a PR, but just a suggestion)

[hearty spade]

The repair issue with mapping not configured is gone btw.

[tender vine]

Ok perfect that helps a lot

[glacial wolf]

So talking to the friend of my sister last weekend, I got that Google Home also supports vacuum room mapping, which means we can now also expose this feature to Google Home: https://github.com/home-assistant/core/pull/164617, still WIP

[queen steeple]

What integration are we talking about?

[glacial wolf]

I didn't mean it as anything specific

But I think it would be cool if we in a way could

1. Expose rooms that are currently being vacuumed (google can handle this data, I am not sure if all our integrations expose it)
2. Expose the current room

[queen steeple]

Expose it in the vacuum entity?

[glacial wolf]

Maybe, as we could do the vacuum id -> area mapping

[queen steeple]

It's up to you to decide how to proceed in terms of architecture.

For Matter integration, the previous discussion:
https://github.com/home-assistant/core/pull/152410#discussion_r2351041996

#1392801038876282921 message

[glacial wolf]

I mean anyone can pick it up, I'm just thinking out loud

[charred furnace]

Do you know anything about Alexa support? I currently have a helper for every room and say „Alexa, clean kitchen on“

[glacial wolf]

I haven't looked at that one

[charred furnace]

working on reworking some automations with my vacuum now. Is there any way to get the saved room mapping (area -> id) in an automation/action?

[tender vine]

@hearty spade the thing we were discussing on the roborock pr about map validation is this: https://github.com/home-assistant/core/issues/165223#issuecomment-4026734147

Maybe we can discuss some alternative options on this for explicitly signalling. I get the context now for the original design decision but also I think this is a problem form the user perspective that it silently drops the users request.

I'm curious @hidden python if you see similar scenarios for ecovac for handling multiple maps

[hearty spade]

The user writes there that he must select the right map in the Roborock application. I was assuming that there is a select entity for doing that in the Roborock integration in HA. Is that not the case?

[tender vine]

Yes that is right

The feedback is roughly "this is confusing" (silent failure)... not "there is no workaround"

[hearty spade]

you need to select the desired floor/map in the Roborock application
Maybe this is not a bug. but simply a missing function
Maybe the user simply doesn't know that there is a map select already in HA?

[hearty spade]

I thought about some ways how we can improve it, but I'm not sure if we can get it fully correct without bringing the concept of a map all the way to the base vacuum entity.

[tender vine]

One idea could be a notion or currently available segments without respect to a map specifically

And the platform can query all currently available segments

[hidden python]

I wanted that the action is at least raising an error when nothing can be cleaned due "invalid" segments but that was declined as HA is skipping also in other actions invalid ones

[hearty spade]

I have a branch locally that tries to implement it in a somewhat sensible way, the issue is what do you do if only some of targeted areas can be cleaned. We don't really have a good way to handle partial success/failure like that currently.

I'm watching for user complaints on this btw, but so far the one linked above is the first one I've seen, and I think in that one the user may just not know about the functionality that is there. So far the most negative feedback is on the fact that it's hard to find the configure dialog and then not possible to start area clean from the UI, only through action call.

[charred furnace]

Are there any plans for supporting repeat in the new action vacuum.clean_area? I wasn't able to find anything on Github but wanted to be sure before opening an issue.
(Some/all?/at least Roborck) supports sending a parameter called repeat (not repeats) to be able to clean the area(s) one, two or three times. It'd love to see that implemented so we don't have to to something like this any more

action: vacuum.send_command
data:
  command: app_segment_clean
  params:
    - segments:
        - 24
        - 23
        - 22
    - repeat: 2
target:
  entity_id: vacuum.roborock_s7_maxv

If someone points me out into the right direction I'd be open to open a PR for this (if there is no support for this yet)

[hearty spade]

That was part of the initial proposal, but wasn't accepted at the time. We would likely need to have another architecture proposal to add this.

@hidden python, you had some thoughts on this from what I remember.

[charred furnace]

Looking forward to the thoughts

[hidden python]

the propblem is that different manufacturer support different types of repeat. Like on Ecovacs I could specify with one command to repeat 3 times the living room then do twice the bedroom and just once the bathroom. For that reasonI don't like the approach as we would just support the repeat of some models and also its not flexable. I think it would be better to allow specifying multiple times the same area. So the user can decide how he want to repeat it

Also @random crystal said adding support for specifying areas multiple times is easy. Just a small frontend change. @hearty spade any concern if the list would contain the same segment multiple times?

[charred furnace]

I think it would be better to allow specifying multiple times the same area.
So you mean something like [1,1,2] to clean area 1 twice and area 2 once?
any concern if the list would contain the same segment multiple times?
That would be my thought too. At least for roborck I dont know whether this would be accepted by the vacuum.

---

Do I understand your idea of the imkplementation right? I am not so sure about that

[hearty spade]

• Many vacuums don't support this, but only a single repeat attribute. The only way to support both that I can see would be to add two separate features to the vacuum entity, something like CLEAN_AREA_REPEAT_BASIC, CLEAN_AREA_REPEAT_ADVANCED
• As for segments being present multiple times, currently they would be deduplicated, so it wouldn't work, but that could be changed.
• There are some possible problems I can envision however, consider if your area_1 is mapped to two segments [s1, s2], then if you call clean_area with:

cleaning_area_id:
  - area_1
  - area_1

You would get in your vacuum a call with segments: [s1, s2, s1, s2], which I'm not sure is what was intended or if it is even supported by the vacuum. We could however likely detect it and change it to more sensible [s1, s1, s2, s2].

• But that doesn't solve the problem completely, because even with an area mapped to a single segment, a user could still call:

cleaning_area_id:
  - area_1
  - area_2
  - area_1

So that's another thing to handle.

• And what about repeating some area for example 5 times? I think there typically is a limit of max 3 times, right?
• So given the above challenges for this use case I would explore making a new selector, where you can select areas (each area just once) and next to each you also have a selection for number of repeats, limited to available ones, so likely [1, 2, 3].
• But all of the above is separate from the vacuums that support only a single repeat parameter. Those are much simpler to add, as they don't have any of the above challenges. So I think we should proceed with them first.

[charred furnace]

So I guess an option would be to implement support for a basic repeat option that repeats all provided areas 1-3 times and then afterwards implement the advanced repeat, right?