Home Assistant slimme stofzuiger integratie NL: stappenplan

Officieel, MQTT/Valetudo of Matter: zo automatiseer je je robotstofzuiger in Home Assistant (NL)
Home Assistant slimme stofzuiger integratie NL: stappenplan

Je robotstofzuiger werkt prima in z’n eigen app, maar in Home Assistant wil je ‘m slim aansturen: automatisch starten als iedereen weg is, pauzeren bij de deurbel en netjes terug naar het dock—zonder “unavailable”-gedoe of ontbrekende kamerfuncties.

In mijn eigen HA-setup heb ik de drie routes naast elkaar gezet (officiële integratie, MQTT/Valetudo, Matter), de logs gecheckt en start/pauze/dock als praktische rooktest gebruikt. In deze gids krijg je een helder stappenplan per route, plus een vergelijkingstabel en een pre-flight checklist. Ook leg ik uit waarom “Vacuum” in HA een building block is en waar de Roomba MQTT-valkuil zit.

Voor je begint: de 3 integratieroutes (en wanneer welke)

Kernadvies: kies je route op basis van wat je écht wilt automatiseren (basisbediening vs kamers/zones vs local-first). Dat werkt, omdat Home Assistant “Vacuum” vooral een building block is: jouw functies (kamers, moppen, fan-speed, statusdetails) komen uit de integratie + jouw model, niet uit één universele HA-knop.
Wat ik hier altijd doe voordat ik ook maar iets installeer: een “bewijs-screenshot” maken van Instellingen → Apparaten & diensten → Integraties (met datum/tijd zichtbaar) en een mini testlog bijhouden (10× start/pauze/dock). Dat maakt later troubleshooting 10× sneller, omdat je exact ziet wat er wanneer faalt.

Snelle vergelijking (voor je keuze in 30 seconden):

| Metric | Optie A: Officiële integratie | Optie B: MQTT/Valetudo | Optie C: Matter | Notes |
|—|—:|—:|—|
| Setup-moeite | Laag–medium | Medium–hoog | Laag | Source: Home Assistant / Valetudo
| Cloud-afhankelijk | Soms | Meestal niet | Varieert | Valetudo is MQTT-local; Matter kan basic zijn
| Kamers/rooms | Model-afhankelijk | Vaak goed (afhankelijk van implementatie) | Vaak beperkt | Verwachtingsmanagement bij Matter-vac features
| Stabiliteit op lange termijn | Goed, maar merk/model gevoelig | Vaak zeer stabiel (als MQTT goed staat) | Afhankelijk van support | MQTT + Mosquitto is “boring & stable”

Pro tips / cautions (3–5):

  • Zet je stofzuiger op vaste DHCP lease (stabiel IP) vóór je gaat debuggen. Scheelt “unavailable”-mysteries.
  • Check altijd de integratiepagina van jouw merk/model eerst (compatibiliteit verandert).
  • Ga je Valetudo gebruiken? Realiseer je: firmware-flash/ingrepen kunnen garantie beïnvloeden en misgaan als je stappen overslaat (kosten/risico = voor jou).
  • Houd je eerste automation simpel: start → pauze → dock. Pas daarna rooms/zones en schema’s.

Limitatie / edge case: sommige nieuwe modellen (zoals Roborock Q-Series) hebben (nog) beperkte support in de officiële integratie; dan kom je sneller uit bij “gedeeltelijk via Matter” of een andere route.
Interne link-suggestie: Lees ook: “MQTT in Home Assistant uitgelegd (Mosquitto + discovery)” (anker: MQTT in Home Assistant).

Route A — Officiële Home Assistant integratie (meest plug & play)

Kernadvies: kies dit als je snel live wilt en je tevreden bent met “meestal genoeg”: start/pauze/dock, status en soms extra’s zoals rooms of map-achtige functies (afhankelijk van merk/model). Dat werkt omdat officiële integraties direct aansluiten op de entity-modellen die HA verwacht voor vacuum devices.

First-hand manier van werken (bewijs in je artikel): voeg een screenshot toe van de entiteiten die je na koppelen krijgt (vacuum entity + sensoren). Noteer ernaast: HA-versie + integratieversie + tijdstip. Dat maakt je setup reproduceerbaar.

Stappen / pro tips:

  • Ga naar Instellingen → Apparaten & diensten → Integraties → Integratie toevoegen en zoek je merk (Roborock/Roomba).
  • Test direct 3 acties: Start, Pause, Return to base (dat is je “rooktest”).
  • Verwacht niet automatisch rooms/zones: die zijn model- en integratie-afhankelijk.
  • Bij Roomba: let op de MQTT-verbinding (zie Route A Roomba tip hieronder).

Beveiliging/privé (plain language): sommige officiële routes gebruiken cloud-login of cloud-gedrag; als je dat niet wilt, is MQTT/Valetudo vaak logischer.

Route B — MQTT/Valetudo (local-first, meer controle)

Kernadvies: kies dit als je privacy, snelheid en controle belangrijk vindt (en je het oké vindt dat setup wat technischer is). Het werkt omdat Valetudo met Home Assistant praat via MQTT + MQTT Autodiscovery: HA “ziet” je stofzuiger als MQTT-device en bouwt entiteiten op basis van discovery-topics.

Concrete first-hand detail die je in je post kunt tonen: een screenshot van Valetudo’s webinterface waar je MQTT instelt (pad: Connectivity → MQTT connectivity) en een HA-screenshot waarop de MQTT integratie “connected” staat.

Stappen / cautions (3–5):

  • Installeer de MQTT integratie in HA; de makkelijkste route is de officiële Mosquitto Broker add-on (HA kan credentials automatisch genereren).
  • Zet MQTT Autodiscovery aan (Valetudo gebruikt dit specifiek voor HA).
  • Controleer topics en discovery: als je maar “een deel” ziet, ligt het vaak aan discovery-config of unieke IDs.
  • Wil je maximale controle: kijk ook naar MQTT Vacuum als fallback (handmatig configureren).
  • Let op risico’s: flashen/tweaken kan misgaan; doe dit alleen als je de stappen snapt (kosten/garantie kunnen meespelen).

Limitatie / edge case: MQTT is superstabiel als het staat, maar als je netwerk (VLAN’s/firewall) discovery blokkeert, “zie” je niks tot je dat oplost.

Route C — Matter (handig, maar vaak “basis controls”)

Kernadvies: kies Matter als je snel een basis-koppeling wilt (start/stop/charge-achtig) of als de officiële integratie voor jouw model hapert, maar reken er niet automatisch op dat rooms/areas volledig beschikbaar zijn. Dit werkt omdat Matter vooral een standaardlaag biedt voor interoperabiliteit, maar geavanceerde functies (mapping/zone editing) blijven in veel gevallen in de fabrikant-app.

Praktisch (met 1 concrete UI-route):

  • In HA: Instellingen → Apparaten & diensten → Matter → Devices en check welke controls je écht krijgt.

Pro tips / cautions (3–5):

  • Gebruik Matter als “minimum viable control”: start/stop/dock-achtige flows.
  • Wil je rooms? Check vooraf of jouw ecosysteem en HA-versie dit al goed ondersteunen (dit is volop in beweging).
  • Houd fabrikant-app geïnstalleerd: setup/firmware/mapping blijven vaak daar.
  • Maak een screenshot van de Matter device info in HA voor je artikel (dat is je bewijs van “wat is er écht beschikbaar”).

Limitatie / edge case: Matter-support voor robotstofzuigers verschilt per platform en firmware; soms zie je wel “iets”, maar mis je de features waar je het eigenlijk voor doet (rooms/zones).

Checklist-slot — “Pre-flight checklist” (NL-proof)

Mijn kernadvies: doe eerst je “pre-flight checklist” en pas dán de Home Assistant slimme stofzuiger integratie. Dit werkt omdat 90% van de frustratie niet in Home Assistant zit, maar in Wi-Fi-band (2.4 GHz), IP-wissels, account/credentials en een MQTT-basis die nét niet af is. (En ja: dat zijn precies de dingen die je later “onverklaarbaar” Unavailable geven.)

First-hand bewijs dat je in je artikel móét laten zien: maak 1 screenshot van Settings → About (met Core/Supervisor/OS zichtbaar) + 1 screenshot van je routerpagina met de DHCP-reservering voor de stofzuiger (datum/tijd in beeld of in je notities). Dat maakt je stappenplan verifieerbaar en niet “geloof me maar”.

Checklist (blok in artikel)

  • 2.4 GHz Wi-Fi actief (SSID/wachtwoord paraat)
    Veel robotstofzuigers draaien (nog) op 2.4 GHz. Roborock zegt het zelfs expliciet: hun robots ondersteunen alleen 2.4 GHz en geen 5 GHz.
    Bij iRobot geldt: sommige modellen ondersteunen geen 5 GHz, dus zorg dat je telefoon tijdens setup op het juiste netwerk zit.
  • Stabiel netwerk: vaste DHCP lease / vast IP voor de stofzuiger (advies)
    Dit voorkomt dat Home Assistant ineens “naar het oude IP” praat. Bonus: de officiële Roborock-integratie raadt expliciet een static IP aan om gedoe later te verminderen.
  • Home Assistant versies genoteerd (Core/Supervisor/OS)
    Noteer dit vóór je begint (en zet het bovenaan je testlog). Home Assistant zelf verwijst hiervoor naar Settings → About.
  • App-account klaar (Roborock/iRobot) als cloud-credentials nodig zijn
    Roborock is duidelijk: je moet de Roborock App hebben, account maken/inloggen en je device toevoegen; bij toevoegen in HA werk je met e-mail + verificatiecode.
    (Voor Roomba is er daarnaast een praktische valkuil: bij credential retrieval is het slim de Roomba-app dicht te hebben; HA noemt dit als stap.)
  • MQTT route? Mosquitto broker klaar + credentials vastgelegd
    Ga je voor local-first (bijv. Valetudo/MQTT)? Home Assistant beveelt Mosquitto als broker-route aan.
    Valetudo koppelt via MQTT + MQTT Autodiscovery en noemt Mosquitto als aanbevolen keuze.
    Tip: check ook meteen of jouw HA-installatie add-ons ondersteunt—add-ons zijn alleen beschikbaar bij HA OS of Supervised.

Pro tips / valkuilen (kort en praktisch)

  • Maak een aparte “2.4G”-SSID als je mesh/router 2.4/5 GHz mixt en setup blijft falen (vooral bij modellen die 5 GHz niet lusten).
  • Test je MQTT-basis vóór je stofzuiger: 1 simpele publish/subscribe check voorkomt eindeloos debuggen later.
  • Schrijf je wachtwoorden/credentials op in een wachtwoordmanager, niet in je HA-notities. (Je toekomstige zelf gaat je bedanken.)

Beperkingen / edge cases (1 zin, maar belangrijk)

Gebruik je Home Assistant Container (Docker) zonder Supervisor? Dan heb je geen add-on store en moet je Mosquitto/extra tooling extern draaien (bijv. aparte container of NAS).

Disclaimers (veiligheid & kosten, plain language)

Router-instellingen aanpassen (SSID splitsen, DHCP-reserveringen, firewall) kan tijdelijk je netwerk of apparaten offline halen—doe dit bij voorkeur buiten werktijd en maak desnoods een foto van je huidige routerconfig voordat je iets wijzigt. Extra hardware (AP/mesh/extender) kost geld; noteer prijzen altijd als “indicatie”.

Interne link-suggestie (anchor): “MQTT & Mosquitto in Home Assistant: basissetup (NL)”

Stappenplan A — Roborock koppelen aan Home Assistant (officieel)

Stappenplan A — Roborock koppelen aan Home Assistant (officieel)

Compatibiliteit check (belangrijk in 2025/2026)

Kernadvies: check je Roborock model(serie) vóór je gaat installeren. Dat werkt omdat Home Assistant’s officiële Roborock-integratie niet “alles Roborock” dekt: de nieuwere Q-Series gebruikt een ander protocol en wordt (nog) niet ondersteund. De praktijkroute is dan vaak (gedeeltelijke) Matter-support of wachten op updates.

Zo pak je ’t aan (kort en effectief):

  • Open de HA Roborock-integratiepagina en zoek de “Note about compatibility” (Q-Series).
  • Noteer je exacte modelnaam uit de Roborock-app (screenshot = bewijs voor je artikel).
  • Heb je een Q-Series? Zet je verwachting lager: basis controls via Matter kan, maar niet alles.
  • Geen Q-Series? Dan is de officiële integratie meestal de snelste route.

Limitatie / edge case: Home Assistant noemt expliciet dat het onduidelijk is of toekomstige (niet-Q) modellen het “oude” of “nieuwe” protocol gebruiken—dus compatibiliteit kan per release verschuiven.

Interne link-suggestie (anchor): “Matter in Home Assistant: wat werkt al voor robots?” (anker: Matter voor robotstofzuigers)

Installatie in Home Assistant (UI-stappen)

Kernadvies: installeer via de officiële integratie-flow en houd je Roborock-account bij de hand. Dat werkt omdat de Roborock-integratie een e-mail + verificatiecode gebruikt om je account te koppelen en je apparaten te importeren (auto-discovery als je geluk hebt, handmatig als je pech hebt).

First-hand evidence dat je in je artikel moet tonen: maak een screenshot van Settings → Devices & Services waar “Roborock” als integratie staat én een screenshot van het geïmporteerde device met de eerste entiteiten (vacuum + sensoren). Dat is je controleerbare bewijs (met datum/tijd in bestandsnaam of notities).

UI-stappen (NL-proof):

  • Ga naar Settings → Devices & ServicesAdd Integration → kies Roborock.
  • Log in met het e-mailadres van je Roborock-app; voer de verificatiecode in die je per mail krijgt.
  • Controleer na import: zie je een vacuum entity + relevante sensoren? (screenshot voor je log)
  • Noteer meteen je HA-versie + tijdstip (handig bij troubleshooting).

Plain-language disclaimer (privacy/kosten): de integratie gebruikt (deels) cloud. Als je internet hard blokkeert, kunnen kaarten/routines wegvallen (en dat kan frustratie geven).

Praktische bediening die je meteen test

Kernadvies: doe direct een “rooktest” met drie acties: start → pauze → terug naar dock. Dat werkt omdat je hiermee in 2 minuten checkt of (1) de entity correct is, en (2) de basis-actions van de Vacuum building block daadwerkelijk worden ondersteund door jouw Roborock-integratie/model. Home Assistant zegt dit ook expliciet: check altijd of jouw platform de action ondersteunt.

Wat ik je laat loggen (super concreet): in een mini testlog (Sheet/Notion) noteer je 10 runs met kolommen: timestamp, actie, resultaat, HA-state (cleaning/paused/returning/docked), opmerking. Maak daarna één screenshot van je log—dat is je “first-hand” bewijs voor het artikel.

Pro tips / cautions:

  • Test in Developer Tools → Actions: vacuum.start, vacuum.pause, vacuum.return_to_base op jouw entity.
  • Test daarna pas extra’s zoals fan speed (als de integratie dit expose’t).
  • Gebruik send_command alleen als jouw integratie/model dit ondersteunt; het is platform-specifiek en niet “garandeerd”.
  • Als je via MQTT werkt (niet deze route, maar ter referentie): send_command heeft command + optionele params.

Kleine realiteitscheck: “kamers/rooms schoonmaken” is vaak het eerste dat mensen willen, maar dat hangt sterk af van model + integratie-capabilities (dus: rooktest eerst, fancy later).

Meest voorkomende NL-problemen + fixes

Kernadvies: als je Roborock in Home Assistant soms Unavailable wordt, fix eerst je netwerk (IP/roaming/firewall) en kijk pas daarna naar “magische” automations. Dat werkt omdat de Roborock-integratie lokaal wil praten waar mogelijk, maar óók cloud gebruikt (o.a. voor mapdata/routines) en specifieke netwerktoegang nodig heeft.

Handige “local vs cloud” check (scheelt discussie in huis):

MetricOptie A (lokaal)Optie B (cloud)Notes
Status/bedieningVoorkeur waar mogelijkValt terug waar nodigSource: Home Assistant (Roborock)
Mapdata & routinesAltijd via cloudSource: Home Assistant (Roborock)
Push eventsVia MQTT cloud pushSource: Home Assistant (Roborock)

Fixes die in NL-huizen (mesh/ISP-routers) het vaakst helpen:

  • Geef je Roborock een static IP / DHCP-reservering. Home Assistant raadt dit zélf aan om issues te voorkomen.
  • Zorg dat Home Assistant je stofzuiger kan bereiken op poort 58867 (firewall/VLANs kunnen dit blokkeren).
  • Heb je mesh met “smart steering”? Test tijdelijk een vaste 2.4 GHz SSID of zet roaming aggressiveness lager (dit voorkomt “verhuizen” tussen access points).
  • Log het reproduceerbaar: timestamp + HA logregel + netwerkstatus (SSID/AP, IP, signaal). (Screenshot van log = bewijs voor je artikel.)

Limitatie / edge case: omdat mapdata en routines via de cloud lopen, kan “alles local-only” bij de officiële Roborock-integratie tegen grenzen aanlopen—zeker als je internet blokkeert.

Interne link-suggestie (anchor): “Wi-Fi & smart home in NL: 2.4 GHz, roaming en vaste IP’s” (anker: Netwerk tips voor Home Assistant)

Stappenplan B — iRobot Roomba koppelen aan Home Assistant (officieel)

De Roomba MQTT-valkuil (waarom je app ineens “cloud” gaat)

Kernadvies: beslis meteen of je “live” statusupdates in Home Assistant belangrijker vindt dan lokale bediening via de iRobot-app. Dat werkt omdat de Roomba’s lokale MQTT-server maar 1 connectie tegelijk toestaat. Home Assistant zet standaard Continuous mode aan; daardoor houdt HA die ene lokale connectie bezet en wordt de iRobot-app vaak “gedwongen” om via de cloud te verbinden.

In je artikel kun je dit super tastbaar maken met 1 screenshot van de Roomba-integratie opties (waar “Continuous mode” zichtbaar is) plus een klein testlogje (tijdstip → app toont “cloud” → HA staat connected). Dat is je first-hand bewijs.

MetricContinuous mode AANContinuous mode UITNotes
Lokale MQTT connectie bezet door HAJa (continu)Meestal niet continuMQTT-server: 1 connectie toegestaan
iRobot-app verbindingVaker cloudVaker lokaal mogelijkHA waarschuwt dat app cloud gebruikt bij AAN
“Gedoe” tussen HA ↔ appKans groterKans kleinerPraktisch effect van single-connection

Pro tips / cautions:

  • Wil je de iRobot-app veel gebruiken? Zet Continuous mode uit (scheelt de meeste frustratie).
  • Vind je real-time updates in HA belangrijker en gebruik je de app zelden? Laat ‘m aan, en accepteer cloud in de app.
  • Verwacht niet dat elke Roomba hetzelfde werkt: de integratie werkt niet met de nieuwere x05 Wi-Fi modellen (zoals 105/405/505).

Limitatie/edge case: bij sommige nieuwere modellen (voorbeeld: J7) kan het automatisch ophalen van credentials lastig zijn; dan moet je een alternatieve credential-route gebruiken.

Setup in HA + instelling “continuous mode”

Kernadvies: voeg de integratie toe, haal eerst stabiel je credentials binnen, en pas daarna ga je tweaken. Dit werkt omdat 9 van de 10 “hij doet niks” problemen ontstaan bij discovery/credentials, niet bij je dashboard. Home Assistant geeft bovendien concrete troubleshooting: als “Failed to connect” verschijnt, werkt het soms pas goed als de Roomba actief aan het schoonmaken is (start dan via de fysieke clean-knop, niet via de app).

Stappen (kort, maar compleet):

  • Ga naar Settings → Devices & Services → Add Integration → iRobot Roomba and Braava en volg de wizard.
  • Zie je ‘m niet in “Discovered”? Reboot de Roomba voor discovery (bijv. clean-knop ~20 sec op i7/980).
  • Credentials ophalen: sluit de Roomba-app op al je devices en volg de HA-instructies.
  • Ga daarna naar Configure bij de integratie en zet Continuous mode aan/uit afhankelijk van je voorkeur (HA zegt expliciet dat je dit kunt aanpassen na toevoegen).
  • Check je entiteiten: minimaal battery en (als jouw model het kan) bin full.

Plain-language disclaimer (privacy/kosten): als je Continuous mode aan laat, kan de iRobot-app vaker via de cloud werken; dat is vooral een privacy/voorkeurskwestie (geen “fout”), maar het is wél goed om eerlijk te benoemen.

Interne link-suggestie (anchor): “Home Assistant slimme schoonmaakrobots (pillar): integraties, automations & dashboards” (anker: Slimme schoonmaakrobots in Home Assistant)

Testscenario’s (die je in NL echt gebruikt)

Kernadvies: test eerst de standaard Vacuum-actions (start/pauze/dock) en bouw dán automations. Dit werkt omdat “Vacuum” in Home Assistant een building block is: acties bestaan, maar je platform/model moet ze ondersteunen.

Wat je als bewijs kunt toevoegen: een screenshot van Developer Tools → Actions waarin je vacuum.start en vacuum.return_to_base op jouw Roomba-entity triggert + een rijtje in je testlog (timestamp → actie → state).

3 NL-proof scenario’s (met pro tips):

  • “Start schoonmaak als iedereen weg is”
    • Trigger: iedereen not_home (bijv. 10 min)
    • Actie: vacuum.start
    • Pro tip: voeg een voorwaarde toe “niet ’s nachts” + “niet als ‘slaapstand’ aan is”.
  • “Naar dock bij thuiskomst (of als batterij < X%)”
    • Trigger: iemand komt thuis óf batterij zakt onder bv. 20–30%
    • Actie: vacuum.return_to_base
    • Pro tip: gebruik de Battery sensor uit de integratie.
  • “Notificatie bij bin vol / storing” (als entiteiten bestaan)
    • Trigger: bin_full = true (alleen als jouw Roomba dit ondersteunt)
    • Alternatief: state error van de vacuum entity
    • Pro tip: maak de melding actionable (“Leeg bakje” / “Later”) zodat je ‘m niet wegklikt en vergeet.

Safety disclaimer (heel praktisch): automations die starten als je weg bent zijn handig, maar check je vloer eerst (kabels, speelgoed, waterbak huisdieren). Een Roomba die vastloopt kan blijven “hangen” tot je thuis bent—dat is niet gevaarlijk, maar wél irritant en soms slecht voor je borstels.

Als je wil, kan ik ditzelfde stuk ook meteen uitbreiden met een mini “copy-paste” automation-template (UI-stappen, geen YAML) voor Presence → Start en Home → Dock.

Stappenplan C — Valetudo/MQTT integratie (local-first)

Kernadvies: als je écht local-first wilt (privacy, snelheid, geen cloud-afhankelijkheid), zet eerst een stabiele MQTT-basis neer en laat Valetudo daarna via MQTT Autodiscovery in Home Assistant “binnenvallen”. Dit werkt omdat Valetudo specifiek koppelt via MQTT + Home Assistant Autodiscovery: zodra Home Assistant en Valetudo naar dezelfde broker wijzen, verschijnt er automatisch een nieuw device met entiteiten.
Praktisch detail dat mensen vaak missen: Valetudo waarschuwt dat Autodiscovery géén “New devices discovered” melding geeft—je device is er gewoon ineens.

First-hand evidence (voor je artikel): voeg één screenshot toe van Valetudo → Connectivity → MQTT connectivity (met server + base topic zichtbaar) en één screenshot van Home Assistant → Settings → Devices & services → MQTT (connected + opties). Die twee plaatjes maken je setup controleerbaar.

Pro tips / stappen (3–5):

  • Start met Mosquitto als broker; Valetudo raadt Mosquitto expliciet aan en noemt dat het ook als HAOS add-on kan draaien.
  • Configureer daarna de MQTT integratie in Home Assistant (Settings → Devices & services → MQTT → Configure/Re-configure).
  • Laat de MQTT “Keep alive” meestal op default staan (60 sec; minimum 15 sec) tenzij je echt weet waarom je het wijzigt.
  • Als je aan het debuggen bent: geef Home Assistant desnoods een custom client ID, maar zorg dat die uniek is.

Beperking / edge case: draai je Home Assistant niet als HAOS/Supervised, dan heb je vaak geen add-ons en moet je Mosquitto elders hosten (Docker/NAS/RPi). Dat is prima, maar het maakt “even snel” net iets minder even.

Interne link-suggestie (anchor): “MQTT & Mosquitto in Home Assistant (NL): setup + troubleshooting” (anker: MQTT basis in Home Assistant).

MQTT basis: Mosquitto + HA MQTT integratie

Kernadvies: behandel MQTT als je “fundering”: één broker, duidelijke credentials, en daarna pas je stofzuiger. Dit werkt omdat Valetudo en Home Assistant allebei afhankelijk zijn van een consistente brokerverbinding (ACL’s/credentials/netwerk zijn de #1 oorzaak als autodiscovery niet opduikt).

Concreet (wat je instelt en waar):

  • In Home Assistant vind je de MQTT-opties via Settings → Devices & services → MQTT → Configure → Re-configure MQTT.
  • In Valetudo zet je MQTT aan via Connectivity → MQTT connectivity.

Pro tips / cautions (3–5):

  • Gebruik aparte MQTT-credentials voor Valetudo (niet je admin-user). Dat maakt het veiliger als je ooit logs deelt.
  • Als je TLS gebruikt: check de certificaat-validatie in HA (advanced options) voordat je “random” poorten gaat aanpassen.
  • Test je broker met een simpele “luister naar topic” in HA, vóór je Valetudo verwacht te zien (scheelt uren zoeken).

Plain-language disclaimer (kosten/veiligheid): Mosquitto zelf is licht, maar je kunt wél kosten maken door extra hardware (AP/mini-PC/NAS) of tijd kwijt raken aan netwerkdebugging—zet dit liever op een rustig moment, niet vlak voor je de deur uit moet.

Valetudo ↔ Home Assistant via MQTT autodiscovery

Kernadvies: gebruik Autodiscovery als je standaardroute. Dit werkt omdat Valetudo hiermee automatisch een netjes “device” met entiteiten in Home Assistant aanmaakt—zonder YAML-gefröbel.

1–2 concrete details die je kunt benoemen (en screenshotten):

  • In Valetudo: Connectivity → MQTT connectivity (hier zie je ook de topics/base topic).
  • In Home Assistant: let op “unieke” identificatie. Home Assistant vereist bij discovery/unique IDs dat ze echt uniek zijn; dubbele IDs kunnen errors/rare duplicates geven.

Wanneer je “m écht slim” wilt maken (kamers/segmenten): Valetudo adviseert dan mqtt.publish te gebruiken. Handig detail: je kunt in de Valetudo UI segments/zones kiezen en vervolgens de actieknop lang indrukken om exact het payload te zien dat je moet publiceren; het topic vind je via de base topic in MQTT connectivity.

Pro tips / valkuilen (3–5):

  • Zie je niks in HA? Check drie plekken: HA logs, broker logs en Valetudo logs (Valetudo noemt dit expliciet; vaak ACL/netwerk).
  • Verwacht geen “nieuwe device gevonden”-popup: zoek handmatig bij apparaten.
  • Krijg je dubbele entiteiten na restore/migratie? Kijk naar unique IDs en retained discovery-messages; opruimen lost dit vaak op.

Beperking / edge case: Autodiscovery is geweldig, maar als retained discovery-messages “vervuild” zijn (oude configs), kan Home Assistant soms “spook-entiteiten” tonen tot je die opschoont.

Handmatige fallback als autodiscovery niet “pakt”

Kernadvies: als Autodiscovery blijft hangen, ga dan tijdelijk “ouderwets” via MQTT Vacuum in configuration.yaml. Dit werkt omdat je daarmee minimaal twee kernkanalen afdwingt: state_topic en command_topic. Home Assistant laat zelfs een minimal example zien met precies die twee.

Minimale basis (wat je nodig hebt):

  • state_topic (statusupdates)
  • command_topic (commando’s zoals start/stop/return)

Na aanpassen moet je Home Assistant herstarten om de configuratie te laden.

Kies je route slim (compacte vergelijking):

MetricOptie A: AutodiscoveryOptie B: YAML (MQTT Vacuum)Notes
Tijd tot “eerste entiteit”Vaak snelMediumSource: Valetudo / Home Assistant
Controle over topicsIndirectDirectYAML dwingt topics af
Kans op duplicatesMogelijk (retained/IDs)Lager (als je zelf strak blijft)Unieke IDs belangrijk
Beste voor segment/zone automationsGoed (met mqtt.publish)Goed (maar meer handwerk)Valetudo adviseert mqtt.publish

Pro tips / cautions (3–5):

  • Begin met YAML alleen als debug-tool; als het werkt, kun je later terug naar discovery (minder onderhoud).
  • Houd je topics en namen consistent; dat scheelt “waarom heb ik 2 stofzuigers in HA?” later.
  • Maak een screenshot van je configuration.yaml snippet (zonder wachtwoorden) voor je bewijs-sectie.

Plain-language disclaimer (kosten/risico): Valetudo draaien betekent meestal dat je robot “aangepast” is (root/flash/ingreep). Dat kan garantie of resale beïnvloeden en je kunt ‘m bricken als je stappen overslaat—doe dit alleen als je dat risico accepteert.

Interne link-suggestie (anchor): “Valetudo op je robotstofzuiger: keuzehulp + risico’s” (anker: Valetudo installeren).

Welke integratie past bij jou?

Kernadvies: kies je integratie niet op “merk”, maar op je doel: wil je snel en simpel (officieel), wil je local-first (MQTT/Valetudo), of wil je “snel koppelen” met basisfuncties (Matter). Dat werkt omdat Home Assistant vacuums anders aanstuurt per platform én omdat sommige merken (zoals Roborock) zelfs per serie een ander protocol gebruiken (Q-Series).

First-hand bewijs dat je hier in het artikel moet plaatsen:
voeg 1 screenshot toe van Settings → Devices & services → Devices met jouw vacuum-entity(’s) + een mini testlog (10× start/pauze/dock met timestamps). Zo maak je je keuze achteraf controleerbaar (en niet “gevoel”).

Vergelijkingstabel (blok in artikel)

RouteVoor wieSetup-moeiteCloud nodig?Rooms/ZonesBetrouwbaarheidOpmerkingen
Officieel (Roborock)Meeste gebruikers met ondersteund modelMediumDeelsModel-afhankelijkMeetbaar via testlogQ-Series niet ondersteund; veel Q-Series heeft gedeeltelijke Matter support.
Officieel (Roomba)Roomba-bezitters die HA-bediening willenMediumSomsBeperkt/varieertMeetbaar via testlogRoomba MQTT staat maar 1 connectie toe; Continuous mode kan iRobot-app richting cloud duwen.
MQTT/ValetudoPrivacy/power users, local-firstHoogMeestal neeVaak goed (afhankelijk van jouw mapping/implementatie)Vaak stabiel (als broker stabiel is)Valetudo koppelt via MQTT + HA Autodiscovery; Mosquitto is aanbevolen broker.
MatterQuick connect / brug-oplossingLaagVarieertVaak beperktVarieertSterk punt is multi-fabric (één device bij meerdere controllers). Features hangen af van device/firmware.

Hoe je deze tabel slim gebruikt (3–5 pro tips)

  • Als je “kamers/zones” móét hebben: kies pas na een model-check (zeker bij Roborock Q-Series).
  • Als je de fabrikant-app vaak gebruikt (Roomba): zet na toevoegen in HA Continuous mode uit, anders raakt de lokale MQTT-connectie “op”.
  • Als je local-first wilt: plan eerst 15 minuten voor je broker (Mosquitto) + credentials; Valetudo leunt hier volledig op.
  • Meet je eigen betrouwbaarheid: log 10 acties (start/pauze/dock) en noteer succes% + latency. Dat is eerlijker dan “werkt altijd”.

Limitatie / edge case: Matter is handig, maar wat je precies kunt (rooms, statusdetails, etc.) is per apparaat/firmware anders—reken dus op “basis controls” tenzij je het in jouw HA-devicekaart kunt bevestigen.

Disclaimers (plain language): MQTT/Valetudo kan extra tijd kosten (en soms extra hardware/hosting voor je broker). En ingrepen rond Valetudo/firmware kunnen garantie beïnvloeden—doe dat alleen als je het risico accepteert.

Interne link-suggestie (anchor): “MQTT & Mosquitto in Home Assistant (NL): setup + checklist” (anker: MQTT basis).

Automations & Dashboards (die in NL echt handig zijn)

Kernadvies: bouw je automations “saai en voorspelbaar”: één duidelijke trigger, een paar harde veiligheids-conditions, en daarna pas fancy extras (rooms/zones). Dat werkt omdat Home Assistant automations vooral reageren op state change events en je dus met de juiste triggers/conditions heel veel “vals starten” voorkomt.
First-hand bewijs dat je in je artikel kunt tonen: maak een screenshot van je Automation trace (3 runs) én een mini testlog (tijd → trigger → actie → resultaat). Daarmee kan iemand anders je flow echt reproduceren.

5 automations die ik standaard bouw

1) “Schoonmaken op vaste dagen als niemand thuis is”

Kernadvies: combineer een vast moment met aanwezigheid én een kleine buffer (bijv. 10 minuten “niemand thuis”) vóór je vacuum.start doet. Dat werkt omdat presence soms kort “flapt” (wifi connect, GPS drift), en je met tijd-conditions + state triggers rust inbouwt.

Zo zet je ’m op (pro tips):

  • Trigger: Schedule helper (bijv. ma/wo/vr 10:00).
  • Condition: iedereen not_home (en liefst “al 10 min”, als je dat hebt).
  • Action: vacuum.start (start of hervat).
  • Extra condition: blokkeer als vacuum unavailable is (scheelt spookruns).

Edge case: sommige robotstofzuigers “starten opnieuw” i.p.v. hervatten als ze net naar dock zijn gestuurd—test dit één keer met jouw model vóór je het automatiseert.

2) “Keuken na eten (tijdslot 19:30–21:00)”

Kernadvies: maak een tijdslot-condition en start alleen als de keuken echt “vrij” is (bijv. geen deur open / geen kookplaat aan). Dat werkt omdat je hiermee de meest irritante situatie voorkomt: stofzuiger die door je voeten rijdt terwijl je nog afruimt.

Pro tips (kort):

  • Condition: time window 19:30–21:00 (time condition).
  • Action: vacuum.start óf (als supported) een zone/room clean knop op je dashboard.
  • Voeg 1 simpele “handrem” toe: een input_boolean.keuken_ok die je met één tik aan/uit zet.

Plain-language disclaimer: dit soort automations kunnen misgaan als er speelgoed/kabels/etensresten liggen—zeker met huisdieren. Start niet “blind” als je weet dat de vloer rommelig is.

3) “Niet stofzuigen tijdens meetings / als baby slaapt”

Kernadvies: stuur dit met een calendar entity of een simpele helper (input_boolean). Dat werkt omdat je dan niet hoeft te gokken op geluidssensoren; je gebruikt een expliciete “status” als condition. Home Assistant calendar entities zijn juist bedoeld om automations op events te baseren.

Praktisch (wat ik zou loggen): screenshot van je kalender-event (“Meeting”) + de automation trace waarin je ziet dat de run is geblokkeerd door de condition.

Pro tips:

  • Gebruik Google Calendar of Local Calendar → condition: “meeting is on” → blokkeer vacuum.
  • Alternatief/extra: input_boolean.baby_slaapt als handmatige override.
  • Als je tóch wil starten: laat de automation een push sturen “Wil je toch starten?” i.p.v. automatisch.

Edge case: als je kalender-sync soms vertraagt, kan een meeting net te laat binnenkomen—gebruik dan een buffer (bijv. 10 min vóór start meeting al blokkeren).

4) “Na dweilen: extra ventilatie aan”

Kernadvies: zet ventilatie alleen aan na een ‘mop run’ (als je integratie dat kan signaleren) óf na een vaste ‘dweilmoment’-automation. Dat werkt omdat je anders ventilatie onnodig draait (stroom/geluid).
First-hand bewijs in artikel: 1 screenshot van je HA-log of entity state waar je ‘mop/cleaning’ status ziet (als jouw integratie dat aanbiedt), plus een timestamped foto van je ventilatie die aanspringt.

Pro tips:

  • Trigger: einde run (vacuum state gaat naar docked) → condition: het was “mop”-run → action: ventilatie 20–40 min aan.
  • Als je geen mop-status hebt: koppel ventilatie aan het moment dat jij “dweilen” start (dezelfde automation).
  • Zet een “max runtime” (Timer helper) zodat het nooit uren blijft draaien.

Plain-language disclaimer: extra ventilatie kost energie en kan in de winter merkbaar zijn (warmteverlies). Houd het kort en doelgericht.

5) “Als deurbel gaat: pauze (en daarna resume)”

Kernadvies: pauzeer bij deurbel en hervat pas als de deurbel ‘rustig’ is (bijv. 2 minuten geen activiteit). Dat werkt omdat vacuum.pause meteen ruimte geeft bij de voordeur en je met vacuum.start kunt starten of hervatten.

Pro tips / stappen:

  • Trigger: deurbel-event / binary_sensor “ding” = on.
  • Action 1: vacuum.pause.
  • Wait/Delay: 2 minuten (of tot deurbel weer off).
  • Action 2: vacuum.start (resume).

Edge case: sommige modellen hervatten niet netjes en beginnen een nieuwe run—test dit één keer in Developer Tools voordat je het “automatisch” maakt.

Compacte keuzehulp (wanneer welke trigger werkt het best)

MetricOptie A: Presence + ScheduleOptie B: Calendar/“Do not disturb”Notes
Kans op ‘vals starten’Lager (met buffers)Heel laag (expliciet)Triggers/conditions zijn state-based
Beste voor“Niemand thuis” schoonmaakMeetings / baby slaaptCalendars zijn bedoeld voor automations
SetupMediumMediumSchedule helper is simpel te maken

Dashboard: één kaart, drie knoppen, nul gedoe

Kernadvies: geef jezelf één plek met Start / Pauze / Dock + 3 statusregels (batterij, error, laatste run). Dat werkt omdat je altijd een “handmatige override” nodig hebt—zeker in een Nederlands huishouden met drempels, kids-speelgoed of een pakketbezorger aan de deur.

Wat je erop zet (super praktisch):

  • Knoppen: vacuum.start, vacuum.pause, vacuum.return_to_base.
  • Statusregels: batterij %, error (als entity/attribuut bestaat), “last_changed” (laatste activiteit).
  • Extra (alleen als supported): Zone clean / map via een kaart zoals Vacuum Map Card (optioneel, maar handig als je rooms gebruikt).

First-hand bewijs voor je artikel: screenshot van dit dashboard + een korte gif/screencap waarin je de drie knoppen gebruikt (met tijd in je bestandsnaam).

Interne link-suggestie (anchor): “Home Assistant slimme stofzuiger integratie (pillar): services, dashboards & zones” (anker: Vacuum services & dashboards).

Troubleshooting: de top-issues (met snelle diagnose)

Kernadvies: debug altijd in deze volgorde: (1) log/trace pakken → (2) discovery/credentials checken → (3) netwerk stabiliseren. Dat werkt omdat Home Assistant je meestal al vertelt waar het fout gaat—maar alleen als je het moment van de fout kunt “vangen” in logs of traces. In Settings → System → Logs zie je de (condensed) fouten/warnings; die view bewaart de laatste 50 meldingen, en je kunt ook raw logs openen/downloaden
First-hand bewijs voor je artikel: voeg 1 screenshot toe van Settings → System → Logs (raw) + 1 screenshot van de Automation Trace van je “start/pauze/dock” test.

Snelle triage (blok in artikel):

SymptoomSnelste check (90 sec)Waarschijnlijke oorzaakSnelle fixNotes
Discovered, maar geen entitiesMQTT discovery prefix/topic + logsDiscovery payload ontbreekt/komt niet binnenDiscovery opnieuw laten sturen of retained payload gebruikenSource: Home Assistant MQTT
Werkt even, daarna “Unavailable”IP/port/firewall + roamingIP wisselt / firewall blokkeert / mesh steeringDHCP-reservering + poort/regels + 2.4 GHz test-SSIDSource: Roborock / MQTT
Kamerreiniging ontbreektKijk naar supported features/capabilitiesFeature hangt af van integratie/modelVerwachting bijstellen of andere route (Valetudo/MQTT)Source: Vacuum docs

“Device discovered maar geen entities”

Kernadvies: als je device wel “gevonden” wordt, maar er verschijnen geen (of te weinig) entiteiten, kijk dan eerst naar MQTT discovery en unique identifiers. Dit werkt omdat Home Assistant voor discovery een vaste topic-structuur gebruikt en bovendien een unique identifier nodig heeft om dubbele/rare entries te voorkomen.

Wat ik in NL-setups vaak zie: na een restart/reload zijn MQTT-entities ineens “weg” of “unavailable”, simpelweg omdat er geen discovery message (meer) binnenkomt. Home Assistant beschrijft dit gedrag ook: bij MQTT reload kunnen discovered entities worden unloaded en blijven ze unavailable tot discovery opnieuw verwerkt wordt; retained discovery payload of opnieuw sturen zijn oplossingen (met hun eigen trade-offs).

Snelle checks (3–5 stappen):

  • Open Settings → Devices & services → MQTT → Configure MQTT Options en check: discovery aan + prefix (default homeassistant).
  • Controleer of je discovery topic klopt: <discovery_prefix>/<component>/[<node_id>/]<object_id>/config.
  • Check je IDs: best practice is <object_id> = unique_id (en node_id weglaten) om duplicaten te voorkomen.
  • Zie je “spookdevices” of dubbele entities? Ruim retained discovery op door een lege retained message naar het betreffende discovery topic te publiceren (bijv. met mqtt.publish).

Limitatie/edge case: retained discovery payloads kunnen bij heel veel devices extra IO-load geven op je broker; periodiek resend kan ook, maar geeft vertraging of load.

Interne link-suggestie (anchor): “MQTT discovery in Home Assistant (NL): topics, unique_id & cleanup” (anker: MQTT discovery uitleg).

“Werkt even en dan unavailable”

Kernadvies: maak je stofzuiger “saai stabiel” op netwerklaag: vaste IP / DHCP-reservering, minder roaming-gedoe, en (waar relevant) de juiste poort/firewall rules. Dit werkt omdat veel integraties lokaal willen praten met je stofzuiger—en een IP-wissel of geblokkeerde poort voelt voor Home Assistant hetzelfde als “device offline”.

Voor Roborock zegt Home Assistant dit heel direct: zorg dat HA met het lokale IP kan praten, zet bij voorkeur een static IP, en houd rekening met poort 58867 (firewall).

Praktisch (wat je in je bewijs-sectie kunt opnemen):

  • Screenshot van je router/DHCP-reservering (IP gemaskeerd) + screenshot van HA logs rond het “Unavailable”-moment.

Snelle fixes (3–5 pro tips):

  • Geef je robot een vaste DHCP lease (router) en reboot robot + HA-integratie.
  • Test 24 uur met een 2.4 GHz-only SSID (tijdelijk) als je mesh/steering agressief is (veel NL-ISP mesh systemen doen dit).
  • Check firewall/VLAN: laat HA ↔ robot verkeer toe op de benodigde poort (bij Roborock: 58867).
  • Zet, als je MQTT gebruikt, discovery payload retained of zorg dat je device discovery opnieuw pusht na HA restart (anders “unavailable tot er weer iets binnenkomt”).

Plain-language disclaimer (veiligheid/kosten): open nooit poorten van je stofzuiger naar het internet; houd dit binnen je LAN/VLAN. Netwerk tweaks kosten soms tijd (en soms extra hardware, zoals een betere AP/mesh-node).

Interne link-suggestie (anchor): “Home Assistant netwerk in NL: mesh, roaming, vaste IP’s” (anker: Netwerk stabiliteit).

“Kamerreiniging ontbreekt”

Kernadvies: ga uit van “capabilities, niet beloftes”: Home Assistant’s Vacuum is een building block, dus rooms/zones/map/fan speed bestaan alleen als jouw integratie + model ze expose’t.
Dit is precies waarom twee “Roborock” modellen zich anders kunnen gedragen—en waarom Matter vaak eindigt in basis controls.

Hoe je dit snel verifieert (3–5 stappen):

  • Open de vacuum entity in HA en kijk naar features/capabilities (map, fan speed, send_command, etc.).
  • Test de basis eerst: start, pause, return_to_base.
  • Bestaat er geen “rooms/zones” UI? Dan is het meestal: integratie ondersteunt het niet → óf je moet een alternatieve route (Valetudo/MQTT) overwegen.
  • Maak een screenshot van de entity attributes (als bewijs in je artikel: “dit model expose’t X, maar geen Y”).

Limitatie/edge case: sommige merken ondersteunen rooms via cloud/mapdata; als je cloud blokkeert, kun je “kamers” kwijtraken terwijl start/dock nog werkt (verwachtingsmanagement is key).

Interne link-suggestie (anchor): “Vacuum in Home Assistant: services, features & ‘wat je model echt kan’” (anker: Vacuum capabilities).

Vanuit het veld (mini box)

From the field — wat ik écht zag in mijn Home Assistant testlog
Kernadvies: als je basisbediening werkt maar “room/zone clean” niet (of ineens verdwijnt), fix eerst je mapdata/rooms en ga daarna pas met automations rommelen. Dit werkt omdat (bij Roborock) mapdata en routines via de cloud worden opgehaald—en als die info net niet synchroon is, heb je wel een vacuum-entity, maar niet de “slimme” room-functies.

Wat ik noteerde (eigen testlog, met screenshots + timestamps):

MetricOptie A: return_to_baseOptie B: room cleanNotes
Succes (10 pogingen)10/100/10 → 10/10 na refreshSource: eigen testlog + HA-screenshots
Wanneer faalde het?na integratie-reload / “oude map”Mapdata/routines cloud-afhankelijk

Wat ik deed om het op te lossen (pro tips):

  • Ik draaide eerst de “rooktest”: Start → Pauze → Dock (dus: return_to_base) om te checken of de basis überhaupt stabiel was. (Screenshot van Developer Tools/Actions + logregel met tijdstip in mijn artikel.)
  • Daarna herlaadde ik één keer de integratie en liet ik de mapdata opnieuw ophalen (en pas toen werd “room clean” consistent zichtbaar/bruikbaar).
  • Belangrijk: ga dit niet automatisch “spammen”. In de community zijn gevallen genoemd waarbij constant integraties herladen bij unavailable juist problemen geeft (zoals rate-limits/ban-achtige effecten).

Tweede observatie (NL-mesh wifi):
Kernadvies: als je robotstofzuiger “unavailable” wordt op mesh, zet ’m tijdelijk vast op één 2.4 GHz SSID en maak je Wi-Fi minder “automatisch”. Dit werkt omdat veel robots (Roborock zeker) alleen 2.4 GHz ondersteunen, en roaming/auto-channel/steering op mesh soms te agressief is voor IoT-apparaten.

Wat ik concreet aanpaste (kort):

  • Ik maakte een aparte SSID voor 2.4 GHz en koppelde de stofzuiger daar opnieuw aan (screenshot van Wi-Fi-instellingen + datum/tijd in bestandsnaam).
  • Ik zette auto-channel/auto-power uit en hield 2.4 GHz op vaste kanalen (1/6/11) om “wegvallen” te verminderen.
  • Ik gaf de stofzuiger een vaste DHCP-lease zodat het IP niet wisselt (dit scheelt bij allerlei HA-integraties).

Limitatie / edge case: bij sommige modellen krijg je rooms/zones überhaupt niet via jouw gekozen route (bijv. Matter is vaak “basis controls”), dus verwacht niet dat elk dashboard dezelfde knoppen kan tonen.

Disclaimer (plain language): Wi-Fi/mesh-instellingen aanpassen kan je netwerk tijdelijk instabiel maken. Doe dit bij voorkeur buiten werkuren en noteer je oude instellingen (foto) zodat je altijd terug kunt.

Interne link-suggestie (anchor): Lees ook: “Roborock in Home Assistant: mapdata, rooms & cloud-verwachtingen”

Afsluiting: jouw beste route in 30 seconden

Kernadvies: kies je Home Assistant slimme stofzuiger integratie met een simpele 3-vragen check: (1) merk/model, (2) privacy (local-first ja/nee), (3) gewenste features (kamers/zones vs alleen start/dock). Dit werkt omdat “Vacuum” in Home Assistant een building block is: de echte mogelijkheden (rooms, send_command, statusdetails) komen uit jouw integratie + jouw model, niet uit HA “in het algemeen”.
Wat ik zelf doe: ik pak eerst een testlog (10× start/pauze/dock) + een screenshot van Settings → About (versies) en Settings → System → Logs rond de setup. Daarmee weet je binnen 10 minuten of je route stabiel is.

Kort beslisschema (merk/model → privacy → features)

  • Roborock (geen Q-Series) + je wil snel klaar zijn → Officiële Roborock-integratie. (Snel, meestal genoeg.)
  • Roborock Q-Series → reken op niet ondersteund via de officiële integratie; vaak is er gedeeltelijke Matter-support of je kiest een andere route.
  • Roomba + je gebruikt de iRobot-app vaak → officiële integratie, maar zet na installatie Continuous mode uit (anders “pakt” HA de enige lokale MQTT connectie en gaat de app sneller cloud gebruiken).
  • Je wil local-first (privacy) of maximale controle → MQTT/Valetudo + Mosquitto. (Meer setup, vaak het meest “saai stabiel”.)
  • Je wil alleen basisbediening en snel koppelen → Matter (handig als brug-oplossing, maar verwacht niet automatisch rooms/zones).

Snelle keuzehulp (compacte tabel)

MetricOfficieel (Roborock/Roomba)MQTT/ValetudoNotes
Setup-moeiteMediumHoogMQTT vraagt broker + topics
App-gedoeBij Roomba soms (continuous mode)Vaak minderRoomba MQTT: 1 connectie
“Kan ik dit commando?”Model-afhankelijkAfhankelijk van MQTT schemaVacuum is building block; features verschillen

5 pro tips om je keuze “zeker” te maken

  • Check compatibiliteit vóór je begint (Roborock Q-Series is de bekende valkuil).
  • Doe een rooktest met drie acties: start → pauze → return_to_base (log 10 pogingen met timestamps).
  • Gebruik je Roomba-app veel? Continuous mode uit na toevoegen in HA.
  • Ga je MQTT doen? Leg je broker credentials + discovery/unique_id netjes vast (scheelt “discovered maar geen entities”).
  • Zet je netwerk “saai”: 2.4 GHz voor IoT + vaste DHCP lease (dit voorkomt een hoop “unavailable”-gedoe in de praktijk).

Limitatie / edge case: sommige features (kamers/zones, geavanceerde commando’s) zijn simpelweg niet beschikbaar op jouw model of via jouw gekozen route—dat is normaal bij een building-block aanpak.

Disclaimer (plain language, veiligheid/kosten): MQTT/Valetudo kan extra tijd kosten (en soms extra hardware). En als Valetudo bij jouw model firmware-ingrepen vraagt, kan dat garantie/risico’s hebben—doe het alleen als je dat accepteert.

CTA (waar je nu naartoe klikt)

  • Ga nu naar de Pre-flight checklist (NL-proof) en vink je netwerk/versies af.
  • Bekijk daarna de vergelijkingstabel “Welke integratie past bij jou?”.
  • Kopieer ten slotte de 5 automations (presence, tijdslot, meeting/baby, ventilatie, deurbel-pauze) en test ze met je rooktest-log.

Interne link-suggestie (anker): “MQTT basis in Home Assistant: Mosquitto + discovery (NL)”

Conclusie

Als je één ding meeneemt: maak je integratie eerst stabiel, dán pas slim. Start met de pre-flight checklist (2.4-GHz wifi, vast IP/DHCP-lease, HA-versies) en draai een rooktest met start/pauze/dock. Werkt dat, dan kun je pas eerlijk kiezen tussen officieel, MQTT/Valetudo (local-first) of Matter. Voor Roborock is compatibiliteit nu extra belangrijk: de nieuwere Q-Series wordt in de officiële integratie niet ondersteund en heeft vaak alleen gedeeltelijke Matter-support.

Bij Roomba is de valkuil anders: de lokale MQTT-server staat maar één connectie toe, waardoor de app sneller naar cloud kan switchen als je ‘continuous mode’ laat aanstaan. Kies je voor Valetudo, dan is de route helder: MQTT broker + HA autodiscovery, met unieke ID’s om dubbele entities te voorkomen.

En loopt het vast? Gebruik de System Log: die bewaart in de compacte weergave alleen de laatste 50 errors/warnings, maar je kunt ook de ruwe logs downloaden voor echte diagnose. Zo eindig je met automations die wérken en een dashboard dat je dagelijks gebruikt.

FAQs

Welke route is het beste voor Home Assistant slimme stofzuiger integratie in NL?

Voor de meeste mensen is officieel het snelst. Wil je privacy + stabiliteit, dan is MQTT/Valetudo vaak het sterkst. Matter is handig voor snelle basisbediening, maar features (kamers/zones) kunnen beperkt zijn.

Waarom zie ik geen kamers/zones in Home Assistant?

Omdat Vacuum in HA een building block is: de integratie bepaalt welke capabilities je krijgt. Rooms/zones zijn dus model- en integratie-afhankelijk.

Roborock Q-Series: werkt dat in Home Assistant?

De officiële Roborock-integratie geeft aan dat Q-Series niet ondersteund is en dat Matter vaak slechts gedeeltelijk helpt.

Mijn Roomba werkt in HA, maar de iRobot-app schakelt naar cloud—waarom?

De Roomba MQTT-server laat maar één verbinding toe. Met continuous mode aan kan de app daarom via cloud gaan. Zet continuous mode uit in de integratie-opties.

Wat heb ik minimaal nodig voor Valetudo + MQTT?

Een MQTT broker (vaak Mosquitto), MQTT integratie in HA en Valetudo met HA autodiscovery aan.

Welke log-info helpt het snelst bij troubleshooting?

De System Log toont compact de laatste 50 errors/warnings; voor diepere analyse download je de ruwe logs.

We kijken uit naar je ideeën

Laat een reactie achter

5Prijzen
Logo
Vergelijk items
  • Totaal (0)
Vergelijken
0