Zwei vacuum.minisaugroboter_k10_pro-Entitäten im Setup sind praktisch – und im Alltag ein Ärgernis. Beide starten gleichzeitig, beide melden getrennt, beide brauchen ihre eigene Wartung, und in Home Assistant heissen sie standardmässig fast gleich. Wer die kleinen SwitchBot-Sauger auf zwei Etagen verteilt, will keine zwei Bedienoberflächen, sondern eine Logik: einer nach dem anderen, zur richtigen Zeit, mit einer einzigen Meldung am Ende.
Was die Integration liefert – und was nicht
Die K10+ Pro werden über die SwitchBot Cloud-Integration eingebunden. Sie legt für K10+, K10+ Pro, K10+ Pro Combo, K11+, K20+ Pro sowie S10 und S20 je eine vacuum-Entität an. Statusänderungen kommen nicht per Polling, sondern per Webhook aus der SwitchBot-Cloud. Das ist schnell, setzt aber voraus, dass die HA-Instanz von aussen erreichbar ist – mit Home Assistant Cloud entsteht der Cloudhook automatisch, sonst braucht es eine erreichbare externe URL.
Die lokale Bluetooth-Integration ist die schlechtere Wahl: Für K10+ und K10+ Pro liefert die Firmware nur cleaning und docked. Für Automationen mit Ende-Erkennung ist das zu wenig. Wer beide Integrationen parallel laufen lässt, sollte die Bluetooth-Variante deaktivieren, sonst konkurrieren zwei Zustandsquellen um dieselbe Wahrheit.
Erster Aufräumschritt: Vergeben Sie sprechende Entity-IDs. vacuum.sauger_eg und vacuum.sauger_og sind in jedem Template lesbarer als eine angehängte _2. Nehmen Sie sich die zwei Minuten, das gleich beim Einbinden zu erledigen – jede Automation, die später auf _2 referenziert, wird beim nächsten Gerätewechsel zur Fehlerquelle. Ergänzend lohnt sich ein Bereich pro Etage und ein Label wie reinigung, damit Skripte und Dashboards die beiden Geräte gemeinsam ansprechen können, ohne dass Sie IDs pflegen müssen.
Nacheinander statt gleichzeitig
Zwei Mini-Sauger gleichzeitig sind laut und blockieren sich an Türschwellen. Ein Skript, das seriell abarbeitet und auf das Andocken wartet, löst das sauber:
# scripts.yaml
sauger_tour:
alias: Sauger-Tour EG dann OG
sequence:
- action: vacuum.start
target:
entity_id: vacuum.sauger_eg
- wait_template: "{{ is_state('vacuum.sauger_eg', 'docked') }}"
timeout: "01:30:00"
continue_on_timeout: true
- delay: "00:02:00"
- action: vacuum.start
target:
entity_id: vacuum.sauger_og
- wait_template: "{{ is_state('vacuum.sauger_og', 'docked') }}"
timeout: "01:30:00"
continue_on_timeout: true
mode: single
mode: single verhindert, dass ein zweiter Aufruf die Tour parallel startet. Das Timeout ist Absicht: Bleibt ein Gerät hängen, läuft das Skript weiter statt ewig zu warten.
Nur saugen, wenn niemand stört
Die Tour soll laufen, wenn das Haus leer ist – aber nicht mitten in der Nacht und nicht, wenn schon gesaugt wurde:
# automations.yaml
- alias: Sauger-Tour bei Abwesenheit
triggers:
- trigger: state
entity_id: zone.home
to: "0"
for: "00:10:00"
conditions:
- condition: time
after: "09:00:00"
before: "17:00:00"
- condition: template
value_template: >
{{ as_timestamp(now()) -
as_timestamp(states('input_datetime.sauger_letzte_tour')) > 82800 }}
actions:
- action: script.turn_on
target:
entity_id: script.sauger_tour
- action: input_datetime.set_datetime
target:
entity_id: input_datetime.sauger_letzte_tour
data:
timestamp: "{{ as_timestamp(now()) }}"
Der input_datetime-Helfer ist die simpelste Form einer Sperrfrist: 82’800 Sekunden entsprechen 23 Stunden, damit rutscht die Tour nicht Tag für Tag später. Wer lieber ohne Helfer arbeitet, kann stattdessen mit einem Trigger-basierten Template-Sensor den letzten Start festhalten – das Prinzip ist dasselbe wie bei den Skripte in HA: wiederverwendbare Bausteine beschriebenen Bausteinen.
Eine Meldung statt zwei
Zum Schluss eine gemeinsame Rückmeldung, statt zweimal dieselbe Push-Nachricht:
# template.yaml
- sensor:
- name: Sauger Status gesamt
state: >
{% set s = [states('vacuum.sauger_eg'),
states('vacuum.sauger_og')] %}
{% if 'cleaning' in s %} laeuft
{% elif 'error' in s %} stoerung
{% else %} fertig {% endif %}
Auf diesen Sensor lässt sich eine einzige Benachrichtigung setzen – und wenn er auf stoerung steht, weiss man, dass einer der beiden Sauger Aufmerksamkeit braucht, ohne die App zu öffnen. Wer die Verbrauchsmaterialien ebenfalls im Blick behalten will, ergänzt die Bürsten- und Filter-Sensoren der Integration in derselben Vorlage.
Fazit
Zwei K10+ Pro sind kein doppeltes Gerät, sondern ein kleines Flottenproblem. Mit sprechenden Entity-IDs, einem seriellen Skript, einer Abwesenheits-Automation mit Sperrfrist und einem zusammengefassten Statussensor verschwindet der Verwaltungsaufwand fast vollständig. Der Rest ist Feinschliff: Ruhezeiten pro Etage, ein Button auf dem Dashboard für die Sofort-Tour – und die Gewissheit, dass beide Sauger dann fahren, wenn es niemanden stört.