Home Assistant: ČHMÚ-Wetterdaten einbinden und Fehler beheben

Wetterdaten des Český hydrometeorologický ústav (ČHMÚ/CHMI) sind für Automatisierungen in Tschechien besonders interessant. Im ursprünglichen Gemini-Verlauf ging es zunächst um die Einbindung von CHMI-Warnungen und später darum, Jalousien bei Sturm- oder Hagelwarnungen automatisch zu schützen.

Der alte Chat enthält viel nützliches Praxiswissen, aber auch einige Details, die inzwischen korrigiert werden müssen. Deshalb habe ich die Anleitung mit dem aktuellen GitHub-Projekt CHMI Alerts for Home Assistant abgeglichen.

Welche Integration wird verwendet?

Für Wetterwarnungen gibt es die Community-Integration CHMI Alerts von nijel. Sie ruft Warnungen des tschechischen Wetterdienstes ab und stellt sie in Home Assistant bereit.

Nach aktuellem Stand bietet die Integration unter anderem:

  • Wetterwarnungen des CHMI/ČHMÚ
  • automatische Aktualisierung
  • Filterung nach Region
  • mehrere Instanzen für unterschiedliche Regionen
  • Kompatibilität mit MeteoalarmCard
  • einen Binary Sensor für aktive Warnungen

Installation über HACS

Das Projekt empfiehlt HACS als Installationsweg. Da es sich um eine Community-Integration handelt, kann es nötig sein, das GitHub-Repository zunächst als Custom Repository in HACS hinzuzufügen.

Der Ablauf:

  1. HACS öffnen.
  2. Das Repository nijel/hass-chmi-alerts als benutzerdefiniertes Integrations-Repository hinzufügen, falls es nicht direkt gefunden wird.
  3. Nach CHMI Alerts suchen.
  4. Integration installieren.
  5. Home Assistant neu starten.

Der Neustart ist wichtig, weil Home Assistant die neu installierte Custom Component erst danach registriert.

CHMI Alerts in Home Assistant einrichten

Nach dem Neustart gehst du zu:

Einstellungen → Geräte & Dienste → Integration hinzufügen

Suche dort nach CHMI Alerts. Anschließend kannst du eine Region auswählen. Das Projekt unterstützt auch All locations, wenn keine regionale Filterung gewünscht ist.

Wenn du mehrere Gebiete beobachten möchtest, können mehrere Instanzen der Integration angelegt werden.

Welche Entität wird erstellt?

Die aktuelle Projektdokumentation nennt als zentrale Entität:

binary_sensor.chmi_alerts_alert

Der Sensor steht auf:

  • on, wenn aktive Warnungen vorhanden sind
  • off, wenn keine Warnung aktiv ist

Die tatsächliche Entity-ID kann sich ändern, wenn Home Assistant bei mehreren Instanzen eine Nummer anhängt oder du die Entität umbenennst. Deshalb sollte die ID immer in deinem eigenen System kontrolliert werden.

Wichtige Attribute

Hier lag im alten Gemini-Chat ein wesentlicher Fehler. Dort wurde mit einem Attribut current_alerts gearbeitet. Die aktuelle CHMI-Alerts-Dokumentation nennt stattdessen:

  • awareness_level
  • awareness_type
  • alerts

alerts enthält eine Liste aktiver Warnungen mit Informationen wie Überschrift, Beschreibung, Schweregrad, Dringlichkeit, Ereignistyp, betroffenem Gebiet und Gültigkeitszeit.

Automatisierungen aus älteren Beispielen sollten deshalb nicht blind übernommen werden.

Attribute zuerst in Entwicklerwerkzeugen ansehen

Bevor du eine Automation schreibst, öffne in Home Assistant die Entwicklerwerkzeuge beziehungsweise die Entitätsinformationen des Sensors. Prüfe dort die tatsächlich vorhandenen Attribute.

Das ist besonders wichtig, weil Warnungen natürlich nicht ständig aktiv sind. Wenn gerade keine Warnung vorliegt, können manche Attribute leer sein oder andere Werte zeigen.

Einfache Automation: bei jeder Warnung benachrichtigen

Ein robuster Einstieg ist eine reine Benachrichtigung. Die Automation reagiert darauf, dass der Binary Sensor auf on wechselt.

alias: CHMI Warnung aktiv
triggers:
  - trigger: state
    entity_id: binary_sensor.chmi_alerts_alert
    to: "on"
actions:
  - action: notify.notify
    data:
      message: "Eine CHMI-Wetterwarnung ist aktiv."
mode: single

Diese Variante ist bewusst einfach. Sie hängt nicht von einem bestimmten Textattribut ab und eignet sich deshalb gut zum Testen der Integration.

Nur stärkere Warnstufen berücksichtigen

Das aktuelle Projekt verwendet für MeteoAlarm-kompatible Warnstufen das Attribut awareness_level. In der Projektdokumentation wird beispielsweise auf Werte geprüft, die mit 3; oder 4; beginnen.

Eine Bedingung kann sinngemäß so aussehen:

conditions:
  - condition: template
    value_template: >-
      {% set level = state_attr('binary_sensor.chmi_alerts_alert', 'awareness_level') %}
      {{ level and (level.startswith('3;') or level.startswith('4;')) }}

Damit reagiert die Automation nicht auf jede beliebige Warnstufe.

Warnungsdetails aus dem alerts-Attribut verwenden

Wenn du den Text einer Warnung in eine Benachrichtigung übernehmen möchtest, greifst du auf alerts zu. Dabei sollte immer geprüft werden, ob die Liste überhaupt vorhanden und gefüllt ist.

Die Projekt-Dokumentation zeigt dazu sinngemäß:

{% set alerts = state_attr('binary_sensor.chmi_alerts_alert', 'alerts') %}
{% if alerts %}
  {{ alerts[0].headline }}
{% endif %}

Damit vermeidest du einen Template-Fehler, wenn gerade keine Meldung vorhanden ist.

Sturm oder Hagel gezielt filtern

Im ursprünglichen Chat sollte eine Jalousiengruppe nur bei Wind, Sturm, Gewitter oder Hagel reagieren. Die alte Lösung suchte tschechische Wörter in current_alerts. Dieser konkrete Code ist heute nicht mehr passend.

Stattdessen solltest du zuerst die Inhalte von alerts und awareness_type bei einer echten Warnung ansehen. Danach kann genau auf die dort gelieferten Ereignistypen gefiltert werden.

Das ist zuverlässiger als fest angenommene Textbegriffe, deren Schreibweise sich ändern kann.

Jalousiengruppe in Home Assistant anlegen

Im Gemini-Verlauf entstand anschließend die Frage, wie alle Jalousien unter einer gemeinsamen Entität zusammengefasst werden können. Dafür ist eine Cover-Gruppe beziehungsweise ein passender Helfer sinnvoll.

Der genaue Dialog kann sich je nach Home-Assistant-Version ändern. Grundsätzlich gehst du zu Einstellungen → Geräte & Dienste → Helfer und legst eine Gruppe für deine Cover/Jalousien an.

Danach kann eine Automation statt vieler einzelner Entitäten nur noch die Gruppenentität ansprechen.

Bei Wetterwarnung Jalousien hochfahren

Nachdem im ursprünglichen Verlauf ausdrücklich kein Tilt gewünscht war, reicht als Aktion grundsätzlich das Öffnen der Jalousiengruppe:

actions:
  - action: cover.open_cover
    target:
      entity_id: cover.jalousiengruppe

Die konkrete Entity-ID musst du natürlich aus deinem eigenen System übernehmen.

Wetterwarnung nicht als einzigen Sicherheitssensor verwenden

Eine amtliche Wetterwarnung ist ein gutes zusätzliches Signal, aber sie ersetzt keinen lokalen Windsensor, wenn es um den physischen Schutz von Außenjalousien geht. Warngebiete sind groß und Windböen können lokal früher oder stärker auftreten.

Für eine belastbare Schutzautomation ist eine Kombination sinnvoll:

  • amtliche CHMI-Warnung
  • lokaler Windsensor
  • definierter Wind-Grenzwert
  • klarer Sicherheitszustand der Jalousien

MeteoalarmCard nutzen

CHMI Alerts ist laut Projekt kompatibel mit der MeteoalarmCard. Dadurch können aktive Warnungen auf dem Dashboard sichtbar gemacht werden.

Die aktuelle README nennt beispielsweise:

type: custom:meteoalarm-card
integration: meteoalarm
entities: binary_sensor.chmi_alerts_alert

Auch hier gilt: Wenn deine Entität anders heißt, muss der Wert angepasst werden.

CHMI Alerts erscheint nach HACS-Installation nicht

Prüfe in dieser Reihenfolge:

  1. Wurde die Integration in HACS wirklich installiert?
  2. Wurde Home Assistant danach neu gestartet?
  3. Ist das Repository als Integration und nicht als Frontend-Komponente hinzugefügt?
  4. Ist unter Geräte & Dienste → Integration hinzufügen nach dem Neustart „CHMI Alerts“ auffindbar?
  5. Zeigen die Home-Assistant-Protokolle einen Fehler beim Laden von chmi_alerts?

HACS und Home-Assistant-Apps nicht verwechseln

HACS-Integrationen sind nicht dasselbe wie Home-Assistant-Apps. CHMI Alerts wird als Custom Integration installiert und danach unter Geräte & Dienste eingerichtet. Es taucht nicht als eigenständige Home-Assistant-App wie beispielsweise ein MQTT-Broker oder File Editor auf.

Alter YAML-Code mit trigger/action-Syntax

Auch die Home-Assistant-YAML-Syntax hat sich weiterentwickelt. Aktuelle offizielle Beispiele verwenden für Automationen oben die Bereiche triggers, conditions und actions. Darin steht bei einem einzelnen Trigger beispielsweise trigger: state und bei einem einzelnen Befehl action: cover.open_cover.

Ältere Beispiele mit trigger:, platform: oder anderen historischen Schreibweisen können teilweise noch funktionieren oder aus älteren Konfigurationen stammen, sollten aber nicht blind mit aktueller UI-generierter YAML gemischt werden.

Fazit

CHMI Alerts ist eine praktische Community-Integration, um amtliche ČHMÚ-Wetterwarnungen in Home Assistant zu verwenden. Die Installation erfolgt über HACS, die Konfiguration anschließend unter Geräte & Dienste. Wichtig bei älteren Anleitungen: Der aktuelle Warnungsinhalt liegt im Attribut alerts, nicht in current_alerts. Für Automatisierungen sollte zuerst die tatsächliche Entität und Attributstruktur im eigenen System geprüft werden – insbesondere bevor damit Jalousien oder andere sicherheitsrelevante Geräte gesteuert werden.