adds code

l

Quick answer: Valetudo replaces the cloud layer on supported robot vacuums, publishing robot state — docked, cleaning, error, returning — as retained MQTT messages. Node-RED subscribes to that status topic, turns state changes into automations (a cleaning vacuum as a proxy occupancy signal, maintenance thresholds as notifications), and sends commands back the same way. No vendor app, no cloud account, no subscription.

What Valetudo actually does

Valetudo is not a custom firmware. It runs alongside the vendor's firmware on supported robots — mostly Xiaomi, Roborock, Dreame, and Viomi models — and replaces the cloud dependency with a local web interface and an MQTT integration. The project's own description calls it a "brain parasite" for the vendor firmware: you keep the vendor's navigation and motor control R&D, but lose the account requirement, the telemetry, and the app ads. It is Apache-2.0 licensed, maintained primarily by Sören Beye, and relies on security research by Dennis Giese to root each supported model.

The important nuance: only robots on the supported list work. The list is exhaustive, and each model was personally tested. A robot not on that list is not unsupported — it is explicitly not supported, because rooting requires specific security vulnerabilities that do not transfer across models.

The MQTT data: state, events, and consumables

Configure MQTT in Valetudo's web interface (Connectivity → MQTT connectivity), set your broker address and topic prefix, and the robot starts publishing. Valetudo follows the Homie convention for topic structure, which means any Homie-compatible home automation software can auto-discover it. For custom Node-RED integrations, the raw topics are well documented.

Robot state — the presence signal

The status topic — <TOPIC PREFIX>/<IDENTIFIER>/StatusStateAttribute/status — publishes one of eight retained enum values: error, docked, idle, returning, cleaning, paused, manual_control, moving. A separate error topic publishes a JSON object with severity, subsystem, and message fields when something goes wrong.

For Node-RED, an mqtt in node on that status topic is your single input. A switch node routes on the payload value: cleaning → the robot is roaming, which in a single-occupant home is a reasonable proxy for "someone is home and the robot has not been hijacked"; docked → cleaning cycle finished; error → notify. The status topic is retained, so Node-RED knows the robot's state on startup without waiting for the next change.

Maintenance: brush and filter life

Valetudo's ConsumableMonitoringCapability publishes each tracked consumable as a separate MQTT topic under <TOPIC PREFIX>/<IDENTIFIER>/ConsumableMonitoringCapability/, reporting either remaining seconds (integer) or remaining percentage, depending on your robot's firmware. Side brush, main brush, filter, and sensor are the common consumables tracked. Node-RED can watch these values, compare against thresholds, and push a notification when the filter hits 10% or the brush crosses 50 hours. No more guessing when to order replacements. If you are new to MQTT broker setup, the Shelly and Tasmota MQTT walkthrough (German) covers the broker installation end to end.

Presence automations in Node-RED

A robot vacuum's state is not a presence sensor, but it overlaps usefully:

  • Vacation deterrent. Schedule a cleaning cycle at randomized times while you are away. The robot's cleaning state, visible through any MQTT dashboard, signals activity to anyone watching the windows. Combined with smart lights on a similar random schedule, it is a reasonable simulation of someone being home.
  • Occupancy proxy. In a home where the vacuum only runs when someone triggers it, cleaning → "someone is probably home" and docked → ambiguous. This is a weak signal — the robot could be on a schedule — but layered with other inputs (Wi-Fi device tracking, door sensors) it adds confidence. The local smart home build guide shows how this fits into a broader MQTT architecture.
  • Cleaning-complete actions. docked after cleaning → turn off the music you only play while vacuuming runs, or log the session duration from Valetudo's current-statistics topics (area cleaned, time elapsed).

Choosing a vacuum for local control

Suction numbers on the box — "25,000 Pa" or "5,100 Pa" — tell you almost nothing about whether a vacuum will work with Valetudo or any local-control setup. What matters is whether the specific model is on Valetudo's supported-robots list and whether its firmware exposes the capabilities you need. Valetudo's buying guide recommends checking the supported-robots page before purchasing, because the list is tied to specific hardware revisions and rooting exploits that do not carry forward to newer models.

When you are shopping for a vacuum that will actually cooperate with local control, suction numbers on the box are less useful than knowing which models expose MQTT or a local API — CompareSmartDevice's robot vacuums on verified suction, runtime, and navigation specs lists each model with sourced specification values rather than marketing copy, so you can check local-control compatibility against real data.

If you buy through links on the sites we recommend, we may earn a small commission.

Honest limits

  • Feature parity with vendor apps is explicitly a non-goal. Valetudo's docs state it is "not $VENDOR but without the cloud." Some vendor-app features will not be replicated. Accept this before you start.
  • Capabilities vary per robot. Valetudo's capability system means your robot gets a subset of available features. Virtual walls and restricted zones exist as a capability (CombinedVirtualRestrictionsCapability) but only on robots whose firmware exposes the necessary interfaces — on others, the vendor app remains the only option for setting no-go zones. Carpet detection (CarpetModeControlCapability, CarpetSensorModeControlCapability) follows the same model: present on some robots, absent on others.
  • Reverting to stock firmware is not possible. The rooting process modifies the vendor firmware permanently. This is documented on Valetudo's "Why not Valetudo?" page.
  • Only supported robots are supported. The list is exhaustive. Newer models may not be supported because the required security vulnerabilities have not been found or have been patched by the vendor.

Frequently asked questions

Does Valetudo work with Home Assistant?

Yes. Valetudo documents a dedicated Home Assistant integration using MQTT autodiscovery. The same MQTT topics that feed Node-RED also feed Home Assistant entities — you can use both simultaneously.

Can I still use the vendor app after installing Valetudo?

No. Valetudo replaces the cloud connection that the vendor app depends on. Control moves to Valetudo's local web interface, MQTT, or Home Assistant.

What if my robot is not on the supported list?

It will not work with Valetudo. The project does not accept feature requests for unsupported models. Your options are: buy a supported model, or use Roborock Local Server (a separate, less opinionated project) if your robot is a Roborock.

Sources

Tags
Previous Post Next Post