Ecovacs Bumper lokal (Synology NAS) + Pi-Hole & Unbound - App umgeht lokales DNS

Integrationen
, , ,
1

Hallo zusammen,

ich wollte meinen Ecovacs Saugroboter und Mähroboter (Deebot Ozmo T8+ und Goat G1) komplett lokal über “Bumper” laufen lassen, habe das Projekt aber nach unzähligen Versuchen abgebrochen. Vielleicht sieht hier jemand den Fehler oder es hilft anderen, die vor dem gleichen Problem stehen. Ich habe am Ende alles wieder gelöscht und nutze leider nun weiter die Cloud.

Mein Setup:

  • NAS: Synology DS720+

  • Docker-Pfade: /volume2/docker_nvme/[Container-Name]/

  • DNS: Pi-hole + Unbound (als Docker-Container auf der NAS)

  • Router: FritzBox 7690

  • Reverse Proxy: Zuerst Nginx Proxy Manager (NPM), dann Synology nativer RP

  • Endgeräte: Galaxy S24 Ultra (App), Dual-Boot PC mit Windows 11 und CachyOS

  • Domain: saschahome.de (via Cloudflare)

  • Home Assistant: Container, Core 2026.8.1, Frontend 20260729.6

Genutzte Docker Compose Stacks:

Home Assistant:

YAML

services:
  homeassistant:
    image: homeassistant/home-assistant:latest
    container_name: Home-Assistant
    mem_limit: 8g
    cpu_shares: 768
    #security_opt:
    #  - no-new-privileges:true
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:8123/ || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
    restart: always
    network_mode: host
    volumes:
      - /volume2/docker_nvme/homeassistant:/config:rw
    environment:
      - TZ=Europe/Berlin

Bumper:

YAML

services:
  bumper:
    image: ghcr.io/mvladislav/bumper:develop
    container_name: Bumper
    restart: always
    ports:
      - "8007:8007"
      - "8883:8883"
      - "5223:5223"
      - "4443:443"
    volumes:
      - /volume2/docker_nvme/Bumper/data:/bumper/data:rw
      - /volume2/docker_nvme/Bumper/certs:/bumper/certs:rw
    environment:
      - TZ=Europe/Berlin
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:8007/ || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
    security_opt:
      - no-new-privileges:true

Was gemacht wurde und wo es scheiterte:

1. Zertifikate & Reverse Proxy (Port 443 Konflikt) Zuerst wollte ich alles über den Nginx Proxy Manager (NPM) leiten. Dort hatte ich zwei Proxy Hosts angelegt und die generierten Bumper-Zertifikate hinterlegt. NPM läuft bei mir aber auf den Ports 8341 und 8766. Die Ecovacs-App erzwingt jedoch gnadenlos Port 443. Das führte dazu, dass die Synology selbst den Traffic auf Port 443 abfing und an ihren DSM-Login-Port (5001) weiterleitete. In der App kam dann “Zertifikat ungültig / Sichere Verbindung fehlgeschlagen”. Also bin ich auf den systemeigenen Reverse Proxy der Synology umgestiegen, da dieser direkt auf 443 lauscht. Ich habe das Bumper-Zertifikat ins DSM importiert und 13 exakte Regeln (da die Synology-GUI keine Wildcards zulässt) nach dem Schema Quelle: HTTPS, [Domain], 443 -> Ziel: HTTPS, localhost, 4443 erstellt:

  • api.ecouser.net

  • mq.ecouser.net (WebSocket aktiviert)

  • gl-eu-api.ecouser.net

  • gl-eu-mq.ecouser.net (WebSocket aktiviert)

  • gl-eu-iot.ecouser.net

  • portal-eu.ecouser.net

  • portal-ww.ecouser.net

  • eco-ng-ngrp-ger.ecouser.net

  • msg-ger.ecouser.net

  • api-eu.ecovacs.com

  • ecovacs.com

  • ecovacs.net

  • ecouser.net

2. DNS-Umleitung mit Pi-hole (Wildcard-Problematik) Die Roboter-App nutzt etliche Subdomains. Die Pi-hole Weboberfläche unterstützt keine Wildcards. Deshalb habe ich per SSH direkt im gemounteten Verzeichnis eine Konfigurationsdatei für dnsmasq angelegt:

Bash

sudo sh -c "echo 'address=/ecouser.net/192.168.178.123' > /volume2/docker_nvme/pihole/dnsmasq.d/99-ecovacs.conf"
sudo sh -c "echo 'address=/ecovacs.com/192.168.178.123' >> /volume2/docker_nvme/pihole/dnsmasq.d/99-ecovacs.conf"
sudo sh -c "echo 'address=/ecovacs.net/192.168.178.123' >> /volume2/docker_nvme/pihole/dnsmasq.d/99-ecovacs.conf"
sudo sh -c "echo 'address=/ecovacs.cn/192.168.178.123' >> /volume2/docker_nvme/pihole/dnsmasq.d/99-ecovacs.conf"
sudo docker restart Pi-Hole

Problem: Weder Windows 11 (ipconfig /flushdns) noch CachyOS (resolvectl flush-caches) haben bei Subdomains wie portal-ww.ecouser.net die lokale NAS-IP aufgelöst. Sie leiteten auf die öffentliche IP der Ecovacs-Cloud um (123.60.110.74 / 8.211.16.120). Die dnsmasq-Datei wurde vom Pi-hole scheinbar komplett ignoriert. Ich habe dann stattdessen manuell folgende 14 einzelne Domains in die GUI von Pi-hole (Local DNS Records) eingetragen und auf die IP 192.168.178.123 verwiesen:

  • ecouser.net

  • api.ecouser.net

  • mq.ecouser.net

  • gl-eu-api.ecouser.net

  • gl-eu-mq.ecouser.net

  • gl-eu-iot.ecouser.net

  • portal-eu.ecouser.net

  • portal-ww.ecouser.net

  • eco-ng-ngrp-ger.ecouser.net

  • msg-ger.ecouser.net

  • api-eu.ecovacs.com

  • ecovacs.com

  • ecovacs.net

  • ecovacs.cn

Dies hat die Namensauflösung am PC repariert.

3. IPv6 & Galaxy S24 Ultra Trotz korrekter IPv4-Auflösung umging das Smartphone den Pi-hole permanent. Die Ursache war die FritzBox, die über Router Advertisements und DHCPv6 eine IPv6-DNS an die Geräte verteilte. Ich habe in der FritzBox 7690 DHCPv6 komplett deaktiviert und die DNSv6-Bekanntgabe (RFC 5006) abgeschaltet. Am S24 Ultra wurde “Privates DNS” deaktiviert, die IP statisch eingestellt und der App-Speicher komplett gelöscht.

4. Das Resultat Obwohl alles auf die NAS zeigte, erschien in der Ecovacs-App nach der Eingabe fiktiver Zugangsdaten (die Bumper lokal akzeptieren sollte) die Meldung “Konto oder Passwort falsch” und die Aufforderung, mir einen Verifizierungscode senden zu lassen. Ein Blick in die Bumper-Logs auf der Synology zeigte:

Bash

sudo docker logs --tail 50 Bumper

Ausgabe:

Plaintext

[2026-08-11 21:34:26] - Starting Bumpers...
[2026-08-11 21:34:26] - Generating EC certificates in directories: /bumper/certs
[2026-08-11 21:34:26] - Creating CA certificate...
[2026-08-11 21:34:26] - Creating server certificate...
[2026-08-11 21:34:26] - Creating combined ca.pem...
[2026-08-11 21:34:26] - EC certificates created successfully
[2026-08-11 21:34:26] - Starting database migration :: 0.0.0 → 0.2.3
[2026-08-11 21:34:26] - Database backup created :: /bumper/data/bumper.db.bak.20260811-213426
[2026-08-11 21:34:26] - Database migration completed :: now at version 0.2.3
[2026-08-11 21:34:26] - Database version aligned with application :: 0.2.3 → 0.4.1
[2026-08-11 21:34:27] - Starting MQTT Server at 0.0.0.0:8883
[2026-08-11 21:34:27] - Starting MQTT Server at 0.0.0.0:1883
[2026-08-11 21:34:27] - Starting XMPP Server at 0.0.0.0:5223
[2026-08-11 21:34:27] - Bumper Authentication Success :: Helperbot :: ClientID: helperbot@bumper/helperbot
[2026-08-11 21:34:27] - Helper Bot connected successfully.
[2026-08-11 21:34:27] - Bumper started successfully
[2026-08-11 21:34:27] - Starting WebServer
[2026-08-11 21:34:27] - Starting WebServer Server at 0.0.0.0:443
[2026-08-11 21:34:27] - Starting WebServer Server at 0.0.0.0:8007
[2026-08-12 02:18:41] - Starting Bumpers...
[2026-08-12 02:18:42] - Starting MQTT Server at 0.0.0.0:8883
[2026-08-12 02:18:42] - Starting MQTT Server at 0.0.0.0:1883
[2026-08-12 02:18:42] - Starting XMPP Server at 0.0.0.0:5223
[2026-08-12 02:18:42] - Bumper Authentication Success :: Helperbot :: ClientID: helperbot@bumper/helperbot
[2026-08-12 02:18:42] - Helper Bot connected successfully.
[2026-08-12 02:18:42] - Bumper started successfully
[2026-08-12 02:18:42] - Starting WebServer
[2026-08-12 02:18:42] - Starting WebServer Server at 0.0.0.0:443
[2026-08-12 02:18:42] - Starting WebServer Server at 0.0.0.0:8007

Ergebnis: Der Server fuhr zwar fehlerfrei hoch, aber es gab keinen einzigen Verbindungsversuch von außen. Die App hat also den lokalen DNS und den Reverse Proxy immer noch irgendwie umgangen und direkt mit der echten Ecovacs-Cloud kommuniziert.

Hat jemand von euch Bumper in einer ähnlichen Konstellation (Synology, Docker Pi-hole, Android) erfolgreich ans Laufen bekommen? Wie habt ihr das Wildcard-Problem bei Pi-hole gelöst und wie verhindert man, dass die App ausbricht?

Lg