A vacuum robot with a camera: what the Ecovacs X12 sends home

I bought a robot vacuum on 11 October 2026. An Ecovacs DEEBOT X12 OmniCyclone for 720 euro, delivery in the coming days. This is not a review, the box has not arrived yet. It is the other half of the work, the part that does not need the device: what does this thing actually cost, and which addresses does it need in order to function. Both are answerable from public material, and the interesting answers are not the ones on the product page.

The price: 720 euro was solid, not the floor

The vendor lists the X12 OmniCyclone in its own shop at 999.00 euro, with a struck-through RRP of 1,399.00 euro. The Austrian price comparison at Geizhals showed a best price of 698.82 euro on the evening of the same day, from 20 offers, with a price change of minus 22 percent marked over the last thirty days. The spread that evening ran from 698.82 euro to 1,604.99 euro at neckermann.de, with cyberport.at at 709 euro and heynoor.at at 716.74 euro in between.

So 720 euro sits just above the cheapest verifiable Austrian offer of the day and far below the RRP listing. Anyone comparing against 1,399 euro would get a wrong picture. The model confusion is worth a line, because it shows up in the price: the X12S is a different product and starts at 1,299 euro in Austria. Ecovacs announced the X12 at CES in January 2026 and German retail had it from mid April. Buying one in October means buying an autumn discount, not a launch product with launch prices.

Four hostnames the device needs

The interesting question for connected consumer hardware is not suction power. It is the network question, and it can be answered without any measurement setup, because the reference library for exactly these robots is open source. I cloned DeebotUniverse/client.py on 11 October and read the address building directly. For an account in Austria the code produces four destinations.

Purpose	Address	Where in the code
Portal, also serves the robot photos	portal-eu.ecouser.net	authentication.py, line 83
Login	gl-at-api.ecovacs.com	authentication.py, line 86
Auth code	gl-at-openapi.ecovacs.com	authentication.py, line 87
MQTT channel, the constant heartbeat	mq-eu.ecouser.net	mqtt_client.py, line 91

Three details in the same files matter for anyone who wants to look at their own logs. The country mapping assigns Austria the code eu, Germany gets the same, only the United Kingdom is turned into UK. The constant that names the login domain is ecouser.net rather than ecovacs.com, so a filter on the vendor name misses most of the traffic. And the library presents itself as a phone, with the user agent string Dalvik/2.1.0 (Linux; U; Android 5.1.1; A5010 Build/LMY48Z). The reason is compatibility: the endpoint was built for a mobile app. In the DNS log you will therefore find a robot that claims to be a telephone.

The test data of the same library also contains image paths of the form https://portal-eu.ecouser.net/api/lg/image/…, which are the photos from the cleaning log. That is a finding from test fixtures. It says nothing about a robot that is actually running. Anyone who wants it from their own device will find it in the resolver log.

What the privacy policy itself states

Here the vendor deserves fair treatment, because it writes down the awkward parts instead of hiding them. The privacy policy of the ECOVACS HOME app carries an effective date of 2025.11.24. Under the account data it states, word for word, that besides the IP address, the system version and the identifiers of the mobile device it also collects the SSID of the Wi-Fi network and the password of that network, continuously, so that the pairing stays intact. Processing then covers the working environment map the device produces, with Article 6(1)(f) as the legal basis.

The camera section is the one with the most need for conversation, and it is tied to a condition. Only if object recognition is switched on and the customer has joined the product improvement programme does the device take a photo of an unrecognised object, send it to the vendor and store it in the People's Republic of China for further processing. Areas showing a person are blurred automatically beforehand. If the model cannot identify the object, staff at a subsidiary in China may review the image by hand, and the same text says plainly that the image is then stored in the database in order to train the artificial intelligence.

Two further passages belong to the same file. For the voice assistant the recording goes to an Ecovacs cloud hosted in the European Union, from there on to Microsoft Azure for automatic speech recognition, while some models use Google Dialogflow for understanding and speech output, operated by Google Asia Pacific in Singapore with data centres inside the EU. The transcripts stay in the Ecovacs cloud. And on the website policy two sentences sit in one document that should be read together: personal data rests on servers inside the European Union, yet processing locations may include China, where the head office is and where data can be accessed for problem solving and analysis. Mail to the data protection address goes to China, because the mail infrastructure is there. The document itself places the operator's seat with the sentence that China has not been recognised as offering an adequate level of data protection, and points to the standard contractual clauses.

The CVE file: sixteen entries, none naming the X12

Operators who treat IoT devices strictly in the company network like to point at missing vulnerabilities. The NVD query for this vendor returns sixteen entries, retrieved on 11 October 2026, and the list has substance.

CVE-2024-52327, published 23 January 2025: through the cloud service of the robot mower and vacuum family, authenticated attackers bypass the PIN for the live video feed.
CVE-2024-52331, same date: a deterministic symmetric key decrypts firmware updates.
CVE-2024-42911, 14 January 2025: Wi-Fi remote code execution on the Deebot T20 OMNI and T20e OMNI before firmware 1.24.0.
CVE-2025-44251, 10 July 2025: the Deebot T10 transmits Wi-Fi credentials in clear text during pairing.
CVE-2025-30198 and CVE-2025-30199, 5 September 2025: a deterministic WPA2-PSK between robot and dock, and dock stations that do not validate firmware updates.
CVE-2025-2394, 23 May 2025: embedded access keys in the ECOVACS HOME app for Android and iOS up to version 3.3.0.

Not one of these texts names the X12, which I measured with a full text pass over the result list. Many formulations speak of the family, meaning mowers and vacuums together, others name older models explicitly. What that means for the device standing in your hallway stays open in both directions. Turning the file into an all clear means reading it worse than the vendor wrote it.

Cloud dependency is also an availability question

The second failure mode arrives earlier in daily operation than any vulnerability: a server change at the supplier. In July 2026 the community reported an error code 1013 with the text Please update to the latest version to continue, first among users of the official Home Assistant integration, later across several regional endpoints. The vendor had demanded a new device verification procedure on the server side. On GitHub the issue #176484 in home-assistant/core carries the title 1013 Error, Change within EcovacsAPI?. An IoT device without a local control path can move into a stand-only mode this way, without anyone touching the hardware.

The exit door is a niche, but it exists

The comfortable route for robot vacuums is rooting and switching the cloud off; for Roborock and Xiaomi the tool is Valetudo. On the supported devices page of Valetudo the word Ecovacs does not appear at all, counted on 11 October 2026 with a hit counter of 0. Ecovacs has no equivalent of that convenience.

The alternative path is younger. The project bumper describes itself as a standalone and self-hosted implementation of the central server that Ecovacs vacuum robots use. The official Home Assistant integration ships the matching switch, with an instance type of cloud or self_hosted and own fields for the REST URL and the MQTT URL. That puts robot and app on a server you own. What falls away are the services the vendor does not hand over: YIKO voice control, the automatic firmware updates and the comfort features of the vendor app. The project warns that its main and development branches are under active development and can be rough. Using this door means operating a service, not a device.

What you can measure at home in twenty minutes

Since the home network here is not reachable from the working machines, the measurement at home runs over the household's own means, and that is the honest recommendation anyway. The four addresses from the table are no secret, so a DNS log that keeps its queries is enough to start. Anyone running Pi-hole or AdGuard Home puts those four names on a watch list and sees within a day when the robot calls in and how often. Our own guide to running DNS blocking in house covers the logging side.

Three further steps need no permanent router surgery. First, map the DHCP leases to MAC vendors, because dock and robot often announce themselves separately. Second, sinkhole the four domains and observe what exactly breaks: app commands and voice control die, a cleaning plan stored on the device keeps running. That matrix is the most honest answer to the question how much cloud the device really needs. Third, let the byte counters per port run for a while on a managed switch or in the router overview. The MQTT channel produces a pattern of small regular packets, a telemetry burst looks different. For more detail, mirror the port temporarily and read SNI targets, ports and packet sizes, without opening the TLS payload.

The rest is a decision each household makes for itself. I paid 720 euro for the device and I know before delivery that it needs four addresses in two domains, that its password and its map are named in the vendor's paperwork, and that no adequacy decision exists for the operator's seat in China. Those sentences come word for word from the seller's own documentation. The hands-on report follows once the robot has driven around for a few weeks.