Add SUPPORT_OPTION feature and set_option service to the vacuum component

[shenxn]

Context

This is related to backend PR #34569. Many vacuum robots support options other than fan speed. For example, my Braava Jet supports wet mop behavior and spray amount and my Neato vacuum supports extra care navigation and double pass. However, they are currently not supported by the vacuum component.

Proposal

I would like to add SUPPORT_OPTION feature and set_option service to the vacuum component. I've tried to do some changes to the code in #34569.

Consequences

Each integration will be able to support its own set of options. To me, there seems to be no obvious risk introduced by this change.

[bdraco]

This architecture issue affects integrations you are list as code owner for.

@etheralm as the code owner for dyson @OverloadUT as the code owner for ecovacs @dshokouhi @Santobert as the code owner for neato @pschmitt @cyr-ius @shenxn as the code owner for roomba @rytilahti @syssi as the code owner for xiaomi_miio

[dshokouhi]

@shenxn what Neato botvac do you have? My D7 does not support "double pass" there is either extra care navigation or regular navigation. The D7 also offers deep cleaning navigation via API only. All botvacs support eco mode and turbo mode, these 2 modes are more associate with fan speed.

We also have a custom cleaning service call that allows the user to change these values because they are unique to neato and must be set when the start cleaning service is called. Users can't set it without initiating cleaning which is very much how the fan speed service call works on the vacuum platform.

I don't think any of the vacuums follow any form of standard so it might be best to let them do separate things?

Here is what neato supports: https://developers.neatorobotics.com/api/robot-remote-protocol/housecleaning

[balloob]

When features are not supported by an integration there are two approaches:

• We add the specific feature to the base vacuum abstraction. Example: "Go to Dock". For features to be added, there needs to be multiple integrations that offer a specific feature and we should be able to reasonably abstract it
• If the feature is unique to a single or very few integrations, the desired approach is that you register services under the domain of your integration to offer this functionality. This should be done with platform.async_register_entity_service(…) (example) to make sure entity selectors work appropriately.

[OverloadUT]

My suggestion for how to proceed with getting features added to the base vacuum component is to start a table with functionality that each vacuum/platform supports. Then others that are more familiar with other vacuums can add to the table, and we can identify if there are any features that span multiple integrations.

For example, here's what I know about Ecovacs:

Capability	Ecovacs
Accessory Lifespan (brushes, etc)	✔
Cleaning Method (random, planned, etc)	✔

[frenck]

Aren't those not just sensors? Things like brushes and current cleaning method? Changing/resetting them can be provided via services.

[pvizeli]

I would suppose to add a generic device option function with elements from config flow to render a UI on the device info page. All kinds of device have flat options like motion sensors with sensitivity or media players with things like an equalizer.

EDIT: Things they affect on runtime should be service other a device options

[OverloadUT]

Aren't those not just sensors? Things like brushes and current cleaning method? Changing/resetting them can be provided via services.

Yes, they can be provided by services and should right now. But if we determine that many vacuum manufacturers share a capability, it becomes a candidate for being added to the base vacuum component. This is exactly what balloob said above; I was just providing a structure for finding common features among manufacturers.

As for the component lifespans, yeah perhaps those just deserve to be sensors. Again, I'm just listing capabilities to find alignment.

[pvizeli]

Things they affect on runtime should be service other a device options

I means, stuff they need to be automated should be a service other a device options

[shenxn]

I'll explain in details on what I've done in the backend PR.

• SUPPORT_OPTION is added to the supported_features
• A new property option_list is added to the vacuum base class which should returns a list of options that can be set.
• A new service set_option that takes entity_id, option, and value that can be used to set a single option.
• In a specific integration, for each option (e.g. nav_mode), there will be properties nav_mode and nav_mode_list that do exactly same things as the fan_speed and fan_speed_list.

The main reason that I want to add something to the vacuum component instead of entirely relying on each integration is that it'll be much easier for the frontend to support this in its more info dialog. I've proposed the changes in #5596.

[shenxn]

@balloob @frenck @pvizeli Is there a better way to set things like navigation behaviors in UI? If we completely rely on custom services, it seems impossible without extra setup using scripts or helpers. What about let each integration register custom services that follows some rule and expose a list of options to the frontend?

[Acrobot]

I want to follow up on this issue, Xiaomi Robot Vacuum Pro (Viomi v8) has a mopping functionality, however currently there is no way to first of all set whether the robot should just vacuum, vacuum and mop or just mop. Additionally, the mop has three different modes for the water level (low/normal/high). When implementing the functionality, we have to currently switch the mode based on the type of the box in the robot (water only, dust only, 2 in 1) and whether the mopping attachment is attached to the robot.

First: do you think that the mop functionality should be standardised for vacuums? Perhaps additional entity, like Vacuum, but for the Mop? (Is it even possible to have an entity that is both Vacuum and a Mop?)

[shred86]

Also interested in this. There are various robot vacuums that support both vacuum and mop features. For example, the Roborock S7 has options to set the mop mode (standard and deep) and scrub intensity (close, mild, moderate, intense). I'd be curious to hear how other robot vacuum mop settings are specified.

[arthur-morgan-1]

Also interested in Mopping control for Roborock S7. We can only control the vacuum speeds right now. Mopping control should be 2 modes - Standard / Deep + Speeds (including 'disabled' - no mopping).

[shred86]

What is the process of getting this architectural change approved for the vacuum component? There are multiple robot vacuums (Roborock, Ecovac, iRobot, etc.) that have some variation of being able to control:

• Mop mode: controls the routing for more thorough cleaning (i.e. overlap)
• Mop intensity: controls the scrub intensity of the mop
• Water flow: amount of water used while mopping
• Empty bin: start or stop the auto-emptying station when the robot vacuum is docked

I think these should be added as additional supported functions since they are not specific to a device or vendor. It looks like the actual modes/settings (e.g. standard, deep, etc.) are defined by the integration's library. python-miio already supports changing the mop mode, intensity and water flow.

Per this guidance, I've created a new post in Discussions.

[frenck]

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck