Valetudo: Useful blueprints for your vacuum robots

Ah yes, MQTT topics are case sensitive. I’ll post a screenshot of my dashboard later, basically I’m combining the Valetudo Map card with some Mushroom buttons (and the buttons call the command script with various parameters, e.g. individual rooms or the whole apartment).

1 Like

Thanks for your amazing scripts! My vacuums are voice controlled now :-).

What I didn’t understand is the notification: Is this only for phones or can I use it in my dashboard, too? I’d love to have the status displayed - especially, when and where Errors occured…is this what the lovelace URL is for?

Thanks in advance for some help,
pheidrias

The notifications are only tested with the HA companion app (but they use standard HA notification features, so theoretically other notification providers should work as well).

The dashboard URL is for your own vacuum dashboard (if you have one), the blueprints don’t include an example. (Please note that the URL does not work correctly on iOS due to a HA companion app bug)

Hi.
I’ve tried using your clean rooms script, and while it works for one vacuum, and it does execute the cleaning in a desired order, the other one doesn’t (it just uses whatever order it has decided to use from the mapping pass).

I have created a separate script for both:
The first vacuum is Roborock S5 Max"

alias: "Valetudo: Send Vacuum Command - RoborockS5Max"
use_blueprint:
  path: mundschenk-at/valetudo-send-vacuum-command.yaml
  input:
    robot: RoborockS5Max
description: ""
alias: "Valetudo: Clean Rooms - RoborockS5Max"
use_blueprint:
  path: mundschenk-at/valetudo-clean-rooms.yaml
  input:
    send_robot_command: script.valetudo_send_vacuum_command_roborocks5max
    robot_map_segments: sensor.valetudo_roborocks5max_map_segments
description: ""

the other one is Eureka J15 Pro Ultra:

alias: "Valetudo: Send Vacuum Command - EurekaJ15ProUltra"
use_blueprint:
  path: mundschenk-at/valetudo-send-vacuum-command.yaml
  input:
    robot: EurekaJ15ProUltra
description: ""
alias: "Valetudo: Clean Rooms - EurekaJ15ProUltra"
use_blueprint:
  path: mundschenk-at/valetudo-clean-rooms.yaml
  input:
    send_robot_command: script.valetudo_send_vacuum_command_eurekaj15proultra
    robot_map_segments: sensor.valetudo_eurekaj15proultra_map_segments
description: ""

the robot parameter is adjusted properly for both, using the one from MQTT configuration in Valetudo.

Running the script against Eureka:

action: script.valetudo_clean_rooms_eurekaj15proultra
data:
  mode: vacuum_and_mop
  iterations: 1
  custom_order: true
  segments: Kuchnia,Salon,Gościnny,Łazienka,Kotłownia,Wiatrołap

starts it and the payload looks valid, but the order is wrong, despite it having MapSegmentationCapability

params:
  domain: script
  service: valetudo_send_vacuum_command_eurekaj15proultra
  service_data:
    mqtt_topic: OperationModeControlCapability/preset/set
    mqtt_payload: vacuum_and_mop
  target: {}
running_script: true
child_id:
  domain: script
  item_id: valetudo_send_vacuum_command_eurekaj15proultra
  run_id: 2ff9f9622527081677f2e70a12752295
params:
  domain: script
  service: valetudo_send_vacuum_command_eurekaj15proultra
  service_data:
    mqtt_topic: MapSegmentationCapability/clean/set
    mqtt_payload: >-
      {"segment_ids":["1","4","3","2","6","7"],"iterations":1,"customOrder":true}
  target: {}
running_script: true
child_id:
  domain: script
  item_id: valetudo_send_vacuum_command_eurekaj15proultra
  run_id: 49d6753f334f4496eb622784e513747f

The room ordering is fine too, sensor.valetudo_eurekaj15proultra_map_segments looks like this:

1: Kuchnia
2: Łazienka
3: Gościnny
4: Salon
6: Kotłownia
7: Wiatrołap
icon: mdi:vector-selection
friendly_name: Eureka J15 Pro Ultra Map segments

Any idea why it is not applying th correct order?

Some vendor firmwares ignore the given order and apply their own. I don’t think there’s anything we can do in that case. (Theoretically, there might be a bug in the Valetudo implementation for a specific vendor, but that is unlikely.)

I’ve copied the generated MQTT command from Valetudo UI and adapted it. THat seems to work fine:


action: mqtt.publish
data:
  payload: |-
    {
      "action": "start_segment_action",
      "segment_ids": [
        "1",
        "4",
        "3",
        "2",
        "6",
        "7"
      ],
      "iterations": 1,
      "customOrder": true
    }
  topic: valetudo/EurekaJ15ProUltra/MapSegmentationCapability/clean/set
  retain: false
  evaluate_payload: false

Interesting. The only difference in the payload would seem to be “start_segment_action”. That parameter does not seem to be strictly necessary, but I’ll look into it.