You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please explain your feature request in a one or two sentences.
When new predefined areas are configured, a new characteristic/control is added so that one can request the robot to work on that predefined area. I see a couple of issues with that
This control is only visible using the Eve app. I understand you can create scenes but this is not ideal in my opinion.
You don't really have control to pick and choose any combination of areas unless you pre-configure them.
Ideally, a user would be able to select any area, or combination of areas and tell the robot to go clean them, without the need for another app to set it up and without the need to pre-configure all possible combinations (which is not feasible).
Example: Something happened and I need to send my robot to clean my hallway and guest bathroom. Right now, unless I have a predefined area configured for the this specific combination, I cannot use Home or even Eve to send my robot to do the job. I'd have to open up the Ecovacs app. With the suggested changes, I could open Home app, "turn on" Guest Bathroom and Hallway and then tell it to go clean.
Is your feature request related to a problem? Please describe.
This is an improvement suggestion rather than a problem.
Any particular ECOVACS devices that this relates to?
No
Anything else?
I ended up spending a few hours working on a fork that implements what I'm suggesting. Here's what it does:
It adds a new configuration setting that allows users to ask the plugin to expose all areas defined on the map as a switch
It exposes all configured pre-defined areas as switches as well
When an area switch is turned on, it does NOT tell the robot to go clean, rather, it keeps track of selected areas. One can select multiple areas and predefined areas as long as they are all SPOT areas. Custom coordinate areas can only be selected by itself (it turns off all other switches)
When the robot is asked to clean, the plugin will check if any area is selected, and if so, it will tell the robot to clean the selected areas. If you select multiple areas, it will build an array of all unique area ids and tell the robot to go clean those areas.
The work I've done is more of a proof of concept and is not really polished. Here's a link for a PR on my own fork. A few comments:
I could not figure out how to properly sort the switches. Clean is always first, but Go Charge gets lost somewhere in the middle and all other switches are somewhat random.
When new switches are added after the initial accessory is setup, the custom names are not set for some reason (example, turn off the option to create switches for zones, restart, turn it on and restart again. New switches will not have custom names).
For me, I have 13 areas, and it gets a bit messy with all these switches. Not sure what can be done about it, maybe a new device to group only the area selection switches?
The option to have switches vs an Eve control could be configurable
The text was updated successfully, but these errors were encountered:
When new predefined areas are configured, a new characteristic/control is added so that one can request the robot to work on that predefined area. I see a couple of issues with that
Ideally, a user would be able to select any area, or combination of areas and tell the robot to go clean them, without the need for another app to set it up and without the need to pre-configure all possible combinations (which is not feasible).
Example: Something happened and I need to send my robot to clean my hallway and guest bathroom. Right now, unless I have a predefined area configured for the this specific combination, I cannot use Home or even Eve to send my robot to do the job. I'd have to open up the Ecovacs app. With the suggested changes, I could open Home app, "turn on" Guest Bathroom and Hallway and then tell it to go clean.
This is an improvement suggestion rather than a problem.
No
I ended up spending a few hours working on a fork that implements what I'm suggesting. Here's what it does:
The work I've done is more of a proof of concept and is not really polished. Here's a link for a PR on my own fork. A few comments:
The text was updated successfully, but these errors were encountered: