Vacuum vacuum.return_to_base not working with switch template

[jcastro]

The problem

I have a Xiaomi Vacuum S50. It has been working fine for more than a year with my switch template. I created this template because I wanted to expose it on HomeKit as well.

It used to work fine in the sense that turning the switch on would start the vacuum and turning it off will stop the vacuum and send it to the base. However now when I turn the switch off, the vacuum just pauses/stops instead of going back to the base as well. I have the latest firmware on the vacuum.

I’ve checked on the integrations page and this is the correct command for turning it off and send it to the base, however the expected result is not the same as it used to be.

Environment

Home Assistant 0.106.1 through Hassio
arch | x86_64
dev | false
docker | true
hassio | true
os_name | Linux
python_version | 3.7.6
timezone | Europe/Madrid
version | 0.106.1
virtualenv | false

• Home Assistant release with the issue: 0.106.1
• Last working Home Assistant release (if known): can't remember
• Operating environment (Hass.io/Docker/Windows/etc.): Hassio
• Integration causing this issue: Vacuum
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/vacuum

Problem-relevant configuration.yaml

- platform: template
    switches:
      limpiador_vacuum:
        friendly_name: Limpiador
        value_template: "{{ is_state('vacuum.limpiador', 'cleaning') }}"
        turn_on:
          service: vacuum.start
          entity_id: vacuum.limpiador
        turn_off:
          service: vacuum.return_to_base
          entity_id: vacuum.limpiador

[dshokouhi]

What happens when you use just a service call vacuum.return_to_base instead of the switch template? Do you get any errors in the logs when you call that?

[probot-home-assistant]

Hey there @rytilahti, @syssi, mind taking a look at this issue as its been labeled with a integration (xiaomi_miio) you are listed as a codeowner for? Thanks!

[jcastro]

What happens when you use just a service call vacuum.return_to_base instead of the switch template? Do you get any errors in the logs when you call that?

Thanks for your reply!. I've tried what you suggested and I called the service directly:
If the vacuum is running and I call the service the robot will "pause", same behaviour as from the switch. While the robot is paused, If then I call the service again it will go to the base.

I've tried enabling debug logs but I'm not getting anything there

[JurajNyiri]

Confirming the issue, this started happening after upgrading to FW 3.5.7_002008.

[rytilahti]

Calling return_to_base will execute the following method in the backend library: https://github.com/rytilahti/python-miio/blob/master/miio/vacuum.py#L92 . The previous behavior was (iirc) that returning did not work if there was no pause.

As for how to fix it, I'm not sure. Considering that calling the service second will make it return, maybe the new firmware requires a short pause between the commands?

[JurajNyiri]

I fixed this temporarily by this script:

dock_xiaomi:
  alias: Dock Xiaomi
  sequence:
  - data:
      entity_id: vacuum.xiaomi_vacuum_cleaner
    service: vacuum.stop
  - delay:
      seconds: 1
  - data:
      entity_id: vacuum.xiaomi_vacuum_cleaner
    service: vacuum.return_to_base

[melyux]

Also have this issue. Takes two hits of the return to base service call to actually return the vacuum to base.

[10bn]

me to, does somebody know how to implement this second action and the delay in to a template switch?

• platform: template
  switches:
  homekit_vacuum_downstairs:
  friendly_name: "Roomba Downstairs"
  value_template: '{{ is_state("vacuum.roomba_downstairs", "cleaning") }}'
  turn_on:
  - service: vacuum.start
  data:
  entity_id: vacuum.roomba_downstairs
  turn_off:
  - service: vacuum.return_to_base
  data:
  entity_id: vacuum.roomba_downstairs

[jcastro]

@JurajNyiri thanks for that, but I'm not entirely sure how to implement that?. Is your HA config up somewhere so I can take a look? thank you!

[melyux]

@jaddel This worked for me with a template switch:

    roomba_switch:
        friendly_name: "Roomba"
        value_template: '{{ is_state("vacuum.roomba", "on") }}'
        turn_on:
          service: vacuum.turn_on
          data:
            entity_id: vacuum.roomba
        turn_off:
        - service: vacuum.stop
          data:
            entity_id: vacuum.roomba
        - delay:
            seconds: 1
        - service: vacuum.return_to_base
          data:
            entity_id: vacuum.roomba

Ideally this sequence should be built into the integration for return to base.

[10bn]

tanks a lot!

[melyux]

The Roomba integration update fixed this for the Roomba (at least through the exposed HomeKit switch), but the Roborock vacuums remain affected. Any hope of adding the pause to the code @rytilahti?

[10bn]

Any News?

[drfra]

Had the same issue and solved it with inserting a delay.

[melyux]

The workaround didn’t work today, got this instead:

2020-10-25 16:44:18 ERROR (MainThread) [homeassistant.components.xiaomi_miio.vacuum] Unable to return home: {'code': -10003, 'message': 'action locked'}

Hey @rytilahti, @syssi, maybe some help with the main issue?

[rytilahti]

@melyux your most recent error sounds to be a completely separate problem, that json payload is coming directly from the device.

Regarding to the original issue, I'm not sure if anyone has tried to modify the code to use stop instead of pause to see if that helps? The code is here https://github.com/rytilahti/python-miio/blob/c4ab5e6f63df67e2b30cb0ec8160e85e1df8e63d/miio/vacuum.py#L136 - the change would be replacing the call to app_pause with app_stop. (another possibility could be adding a short delay of half a second or so there).

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[JurajNyiri]

This issue has not yet been resolved.

[rytilahti]

rytilahti/python-miio#918 is related issue, apparently no need to call pausing on some devices.

It would be great if those having problems could manually test if removing the pause helps (and note down what hardware they have) on that linked issue, we could create a workaround for them.

[rytilahti]

Confirming the issue, this started happening after upgrading to FW 3.5.7_002008.

Could you please comment your model to rytilahti/python-miio#933 so that we can add it to the blacklist for pausing?

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[melyux]

Nope, not yet fixed. I think. Just saw the comments. So there needs to be a blacklist on a per-vacuum basis. Though it seems like adding a delay is a panacea for all cases? Might be easier than keeping a blacklist.

[baccula]

This is happening to me using the return-to-base service called by Node Red. Vacuum is the Roborock S5 Max.

[rytilahti]

So pause is now being ignored by three vacuums: https://github.com/rytilahti/python-miio/blob/master/miio/vacuum.py#L154 . The need for a pause prior to app_charge could be only gen1 specific issue, so I think this could be converted to do special handling only on gen1. It is also possible that my firmware is just too old, but I just tested to verify that app_charge alone does not stop the cleaning and order the vacuum to return (even if the device returns 'ok').

If someone with a recent firmware running gen1 could try if miiocli vacuum --ip $IP --token $TOKEN raw_command app_charge works when the device is cleaning, it would be great! Otherwise, I think I'll simply convert the check from blacklist to whitelist (for gen1), I suppose most devices function well without stopping the cleaning first..

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[63Andre]

I have the same problem with mu new Zedar vacuum (vacuum.robot_vacuum_self_emptying)