Die öffentliche IP-Adresse als Sensor: MyIP.wtf für Home Assistant

Home Assistant kennt in meinem Netz so ziemlich jedes Gerät, jede Steckdose und jeden Fensterkontakt. Was es nicht weiß: unter welcher Adresse mein Anschluss gerade im Internet zu sehen ist. Für die meisten Automationen ist das egal. Für ein paar wenige ist es genau die Information, die fehlt – etwa wenn nach der nächtlichen Zwangstrennung ein DynDNS-Eintrag nachgezogen werden muss oder ich wissen will, ob der Datenverkehr wirklich noch durch das VPN läuft.

Bisher habe ich dafür einen REST-Sensor mit etwas Template-Bastelei benutzt. Das funktioniert, ist aber unhandlich, sobald IPv4 und IPv6 getrennt betrachtet werden sollen und man zusätzlich auf einen Wechsel reagieren möchte. Daraus ist myip-wtf-home-assistant geworden: eine kleine HACS-Integration, die den kostenlosen Dienst myip.wtf abfragt und die Antwort als ganz normale Entitäten bereitstellt.

Was man bekommt

Für jede aktivierte IP-Version legt die Integration ein eigenes Gerät an. Das klingt nach einer Kleinigkeit, verhindert aber, dass IPv4- und IPv6-Werte im Dashboard oder in einer Automation durcheinandergeraten. Pro Gerät gibt es acht Sensoren und zwei binäre Sensoren:

• die öffentliche Adresse selbst und den Reverse-DNS-Namen, den der Provider vergibt,
• den Provider bzw. Netzbetreiber hinter der Adresse,
• eine grobe Ortsangabe mit Stadt, Land und Ländercode,
• den Zeitpunkt des letzten Adresswechsels – der übersteht auch einen Neustart,
• ob die Adresse ein bekannter Tor-Exit-Node ist,
• und ob die letzte Abfrage für diese IP-Version überhaupt geklappt hat.

Ein API-Schlüssel oder ein Konto ist nicht nötig. Eingerichtet wird alles über die Oberfläche, YAML braucht es nicht.

Eine Anfrage pro Minute – für alles zusammen

myip.wtf wird kostenlos und ohne Werbung betrieben. Die Nutzungsregeln für Automatisierung bitten deshalb um höchstens eine Anfrage pro Minute und IP-Adresse. Die naheliegende Umsetzung wäre ein Limit pro Abfrage-Koordinator gewesen. Dann hätten IPv4 und IPv6 aber jeweils ihr eigenes Budget gehabt und wären in derselben Sekunde losgelaufen – formal zwei Clients, praktisch ein Regelverstoß.

Die Integration hat deshalb genau ein gemeinsames Anfragebudget. Jede Anfrage stellt sich dort an: der reguläre Abruf, ein manuelles homeassistant.update_entity aus einer Automation und auch die Prüfung beim Einrichten. Zwischen zwei Anfragen liegen immer mindestens 60 Sekunden. Antwortet der Dienst trotzdem mit HTTP 429, rückt die nächste erlaubte Anfrage weiter nach hinten, und Home Assistant zeigt einen Reparaturhinweis an.

Daraus folgt auch die Untergrenze für das Abfrageintervall: Mit beiden IP-Versionen kostet ein Durchlauf zwei Anfragen, also sind mindestens zwei Minuten nötig. Der Einrichtungsdialog lässt kürzere Werte gar nicht erst zu. Voreingestellt sind 15 Minuten, das ergibt acht Anfragen pro Stunde. Öffentliche Adressen ändern sich ohnehin selten, meist nach einem Router-Neustart oder der nächtlichen Zwangstrennung. Wer schneller reagieren will, stößt die Aktualisierung besser gezielt an, zum Beispiel wenn der Router eine neue Einwahl meldet.

Ein Detail, das mir beim Bauen aufgefallen ist: Beim Einrichten wird nur eine IP-Version testweise abgefragt. Eine zweite Probe müsste auf den nächsten freien Slot warten und würde den Dialog eine Minute lang hängen lassen. Die andere Version wird deshalb erst beim ersten regulären Abruf geprüft.

Wie IPv4 und IPv6 auseinandergehalten werden

Dafür braucht es keine Tricks auf Socket-Ebene. ipv4.myip.wtf hat nur einen A-Eintrag, ipv6.myip.wtf nur einen AAAA-Eintrag. Das Betriebssystem nimmt also automatisch das passende Protokoll. Die JSON-Antwort wird anschließend normalisiert: Leere oder Platzhalterwerte werden zu unknown, statt als leerer String im Verlauf zu landen.

Reagieren, wenn sich die Adresse ändert

Der eigentliche Nutzen liegt im Event myip_wtf_ip_changed. Es wird ausgelöst, sobald sich die Adresse gegenüber dem letzten Abruf unterscheidet, und bringt alte Adresse, neue Adresse, IP-Version und Provider mit. Eine Benachrichtigung aufs Handy sieht damit so aus:

automation:
  - alias: Öffentliche IP hat sich geändert
    triggers:
      - trigger: event
        event_type: myip_wtf_ip_changed
    actions:
      - action: notify.mobile_app_phone
        data:
          title: "Neue {{ trigger.event.data.ip_version | upper }}-Adresse"
          message: >-
            {{ trigger.event.data.old_ip }} → {{ trigger.event.data.new_ip }}
            ({{ trigger.event.data.isp }})

Mit event_data: { ip_version: ipv4 } im Trigger lässt sich die Automation auf eine Version beschränken, etwa für einen DynDNS-Dienst, der nur IPv4 kennt. Für die VPN-Kontrolle reicht ein Zustands-Trigger auf den Provider-Sensor: Taucht dort plötzlich der eigene Anschlussanbieter statt des VPN-Anbieters auf, ist der Tunnel weg.

Nachbesserung in 1.0.1

Mit 1.0.1 ist ein Fehler behoben, der mir im ersten Test durchgerutscht war: Wer in den Optionen eine IP-Version abschaltete, behielt deren Gerät samt zehn Entitäten – dauerhaft „nicht verfügbar“. Jetzt räumt die Integration beim Laden alle Geräte weg, deren IP-Version nicht mehr aktiv ist. Ein Gerät, das noch gebraucht wird, lässt sich dagegen nicht versehentlich löschen.

Installation

1. In HACS unter Integrationen das Menü öffnen, „Benutzerdefinierte Repositories“ wählen und https://github.com/sphings79/myip-wtf-home-assistant als Integration hinzufügen.
2. MyIP.wtf suchen, herunterladen und Home Assistant neu starten.
3. Unter Einstellungen → Geräte & Dienste die Integration hinzufügen und die gewünschten IP-Versionen auswählen.

Voraussetzung ist Home Assistant 2024.12 oder neuer und ausgehender HTTPS-Zugriff auf myip.wtf. Zusätzliche Python-Pakete braucht es nicht. Die Integration steht unter MIT-Lizenz, Oberfläche und Dokumentation gibt es auf Deutsch und Englisch.

Die Daten kommen von myip.wtf bzw. wtfismyip.com, betrieben von einem Dritten ohne Werbung und Tracker. Die Integration ist inoffiziell und steht in keiner Verbindung zu diesem Dienst.