ach, bei Stärke 3.0 kann man sich freuen - das merkt man “gerade so” wenn man ruhig auf dem Sofa liegt.
Also da sehe ich dann z. B.:
2026-04-17 10:11:39.113 DEBUG (MainThread)
[custom_components.earthquake_monitor.sensor]
[letztes Erdbeben | 01KPBKHW7J0NE9GPYDNV2SM2Z7]
Skipping event outside criteria: unid=20260417_0000088 action=update mag=1.3 within_radius=False min_mag=2.5 total_max_mag=8.0 region=WESTERN TURKEY time=2026-04-17T06:13:00.79Z lastupdate=2026-04-17T08:11:36.023662Z
Ich habe jetzt mehrfach Sensoren angelegt und manchmal kam ein Wert und manchmal nicht.
Ist echt etwas merkwürdig.
jetzt sehe ich im Log gerade das hier:
2026-04-17 11:23:05.528 DEBUG (MainThread) [custom_components.earthquake_monitor.sensor] [leztes Erdbeben | 01KPD8NKNRK4M5Z69W5N7DEYWS] Skipping event outside criteria: unid=20260416_0000401 action=update mag=1.1 within_radius=False min_mag=0.1 total_max_mag=10.0 region=SWITZERLAND time=2026-04-16T22:00:57.48Z lastupdate=2026-04-17T09:23:02.157571Z
2026-04-17 11:23:05.528 DEBUG (MainThread) [custom_components.earthquake_monitor.sensor] Received WebSocket message: {"action":"update","data":{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [
7.8850,
47.4270,
-7.0
]
},
"id": "20260416_0000401",
"properties": {
"source_id": "1979947",
"source_catalog": "EMSC-RTS",
"lastupdate": "2026-04-17T09:23:02.157571Z",
"time": "2026-04-16T22:00:57.48Z",
"flynn_region": "SWITZERLAND",
"lat": 47.4270,
"lon": 7.8850,
"depth": 7.0,
"evtype": "ke",
"auth": "EMSC",
"mag": 1.1,
"magtype": "ml",
"unid": "20260416_0000401"
}
}}
2026-04-17 11:23:05.528 INFO (MainThread) [custom_components.earthquake_monitor.sensor] [Latest Earthquake | 01KPBKHW7J0NE9GPYDNV2SM2Z7] Ignored update for older earthquake: current_unid=20260417_0000126 incoming_unid=20260416_0000401 current_time=2026-04-17 09:07:39+00:00 incoming_time=2026-04-16 22:00:57.480000+00:00 action=update mag=1.1 region=SWITZERLAND lastupdate=2026-04-17T09:23:02.157571Z
Er zeigt mir da aber auch noch sensoren an, die es nicht mehr gibt (habe ich schon wieder gelöscht)
2026-04-17 11:23:05.320 DEBUG (MainThread) [custom_components.earthquake_monitor.sensor] Received WebSocket message: {"action":"update","data":{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [
7.8850,
47.4270,
-7.0
]
},
"id": "20260416_0000401",
"properties": {
"source_id": "1979947",
"source_catalog": "EMSC-RTS",
"lastupdate": "2026-04-17T09:23:02.157571Z",
"time": "2026-04-16T22:00:57.48Z",
"flynn_region": "SWITZERLAND",
"lat": 47.4270,
"lon": 7.8850,
"depth": 7.0,
"evtype": "ke",
"auth": "EMSC",
"mag": 1.1,
"magtype": "ml",
"unid": "20260416_0000401"
}
}}
2026-04-17 11:23:05.320 INFO (MainThread) [custom_components.earthquake_monitor.sensor] [letztes Erdbeben | 01KPD8F31Q9726KX2TZYKDP877] Ignored update for older earthquake: current_unid=20260417_0000126 incoming_unid=20260416_0000401 current_time=2026-04-17 09:07:39+00:00 incoming_time=2026-04-16 22:00:57.480000+00:00 action=update mag=1.1 region=SWITZERLAND lastupdate=2026-04-17T09:23:02.157571Z
Aber was wirklich noch gut wäre, dass der Sensor wenn Zeit X verstrichen ist und kein neues Erdbeben bekommen ist auf unbekannt zurückspringt.
by HarryP: Zitat richtig formatiert
War nur 'n Scherz, aber bissl makaber isses ja schon… 
Was mir aufgefallen ist.
Wenn ein lokales Ereignis anliegt und ein globales aufläuft, wird das lokale Ereignis gelöscht. Das ist ein bischen doof, weil ja das lokale Ereignis das wichtigere für mich ist.
Der “Franzose” meint dazu:
Feature-Request an den Entwickler
Das grundlegende Problem, das HA allein nicht lösen kann:
▎ Das letzte lokale Ereignis wird überschrieben, sobald ein globales Event eintrifft. Wenn danach wieder ein lokales kommt, ist das globale weg. Die Integration speichert immer nur ein
▎ Ereignis pro Sensor.
Gewünschte Funktion:
- Dual-State-Tracking — Der Sensor soll intern zwei unabhängige Ereignisse verwalten:
- last_local_* — letztes Ereignis innerhalb des Radius (min_mag-Schwelle)
- last_global_* — letztes Ereignis außerhalb des Radius (total_max_mag-Schwelle)
Als Attribute z.B.: last_local_mag, last_local_region, last_local_time, last_global_mag, last_global_region, last_global_time
-
Alternativ: Separater globaler Sensor — Pro Config-Entry ein zweites optionales Sensor-Entity (z.B. sensor.athen_global), das ausschließlich Events mit within_radius == False aufzeichnet.
Die aktuelle Sensor-Entität würde dann nur noch lokale Events annehmen. -
event_type-Attribut — Explizit “local” oder “global” (statt nur dem Boolean within_radius) — das wäre auch für Automatisierungen nützlich.
Und von mir dazu nur nochmal:
Aber schon mal echt cooles Ding, was du da entwickelst!
Ich habe das Problem dadurch gelöst, dass ich zwei Sensoren angelegt habe, einen “lokal” und einen “global”, damit wird nichts überschrieben.
Allerdings hatte ich das Problem, dass mein Magnituden-Filter nicht zuverlässig funktioniert hat, d.h. es wurden auch Beben unterhalb meiner festgelegten Magnitude gemeldet.
Habe jetzt in Node-Red, da bereite ich mir auch die teegram-Meldung auf, einfach für beide Sensoren einen “Magnituden-Filter” eingebaut und seither kommen nur noch die gewünschten Ergebnisse.
BTW: Beim “globalen”-Sensor kommt manchmal keine nächste größere Stadt mit, auch wenn das Beben an Land war - kann ich aber verkraften!
ja, das ist ein Bug der im Code schon behoben ist (die gelöschten Entitäten wurden erst bei einem HA-Neustart entfernt, was natürlich nicht Sinn der Sache ist). Das Bugfix-Update kommt heute abend oder morgen, ist gerade im internen beta-Test! Das “Auto-Zurückspringen” haben wir weiter oben schon diskutiert, das ist einfach zu implementieren und kommt definitiv auch bald.
Was das “manchmal kam ein Wert und manchmal nicht” angeht, liegt das daran wie die Daten vom Feed reinkommen. Da die Infos von vielen Erdbebenwarten auf der Welt im Feed zusammenlaufen, kommen manchmal Erdbeben (meist vom A… der Welt) verspätet in den Feed, wenn die entsprechende Warte langsam ist. Die haben dann zwar den Zeitstempel von dann, wann das Erdbeben tatsächlich war, kommen aber nach neueren Erdbeben an, die wirklich in Echtzeit gemeldet wurden.
Die Logik zur Auswahl des “letzten Erdbebens”, das in der Entität angezeigt wird, nimmt updates von einem alten Erdbeben nur an, solange es noch das letzte Erdbeben in der Entität ist (und danach nicht mehr). Die verspätet gemeldeten Erdbeben kommen zwar möglicherweise als neu herein, haben aber einen Zeitstempel der älter ist als das letzte akzeptierte Erdbeben. Dann wird es verworfen, weil es ja nicht das letzte Erdbeben ist. Wie gesagt, das ist ein Problem mit den Rohdaten, da kann die Integration leider nichts dran ändern. Sonst müsste man das tatsächlich letzte Erdbeben mit Daten eines älteren (verspätet gemeldeten) Erdbeben überschreiben. Das wäre ein inkonsistentes Chaos. Der Log-Text (“Ignored update for older earthquake“) ist dahingehend etwas unklar - wird behoben!
Das Problem tritt aber fast ausschließlich bei globalen Erdbeben auf, die von verschiedenen Warten kommen, nicht bei lokalen Erdbeben die (fast immer) von der selben lokalen/nationalen Stelle kommen und damit alle entweder in Echtzeit oder verzögert (aber nicht mal so, mal so) sind.
1 „Gefällt mir“
Im Prinzip hat natürlich jeder Punkt auf der Erde eine “nächstgelegene Stadt”, aber ich habe derzeit einen internen Filter drin, der die “nächste Stadt” nur bis 200 km Entfernung anzeigt. Sprich, wenn das Beben irgendwo im Nirvana ist, kann die nächste Stadt “none” sein. Sind die 200 km zu eng gefasst? Es wäre ein winziger “Fix”.
Das hat mich am Anfang auch gestört - das war der Grund warum ich in der neueren Version implementiert habe, mehrere Entitäten mit jeweils eigenen Auswahlkriterien zuzulassen. Dann wird nichts überschrieben, und alles sauber zugeordnet.
Das kommt m.M.n. auf die Magnitude an. Bei allem was kleiner als 5 ist, sind 200 km völlig ausreichend.
Genauso habe ich es gemacht - funktioniert gut.
@fof
Das mit den unterschiedlichen Zeiten und ggf. “alten” Beben sollte, falls noch nicht geschehen, in die Beschreibung (Schande über mich, habe ich immer noch nicht gelesen 
)
Das ist natürlich wahr, vor allem wenn man daran interessiert ist ob man das Beben in dieser nächstgelegenen Stadt spüren konnte (oder ob dort Schäden zu erwarten sind). Mir ging es erstmal hauptsächlich um “wo zum Geier ist das???”, weil mir Koordinaten weniger sagen als “nächste Stadt: Neapel” oder so.
Aber deine Antwort hat mir eine Idee gegeben: Man könnte (als zusätzliche Möglichkeit zu einem festen lokalen Radius) auch einen automatischen/dynamischen Radius ermöglichen, der ein Beben je nach Stärke näher oder weiter entfernt vom Referenzpunkt akzeptiert. Im Readme hab ich in der Tabelle über Erdbebenstärken ja sowieso schon “Daumenregeln” für die Entfernungen, wie weit man ein Erdbeben spürt. Solche Werte könnte man einfach hernehmen um zB ein Beben der Stärke 3 nur bis zu einer Entfernung von 30 km, ein Beben der Stärke 6 aber bis zu einer Entfernung von 500 km in die Entität zu packen.
1 „Gefällt mir“
Also Daten kommen rein, dass ist schonmal das wichtigste. Mit dem Dashboard kämpfe ich noch… Das nutzt weniger Platz als da wäre
Das Bugfix-Update 1.4.1 ist raus. Es behebt den Fehler daß gelöschte Entitäten weiterhin den Webfeed abgehört und auswertet haben, bis HA neu gestartet wurde.
Das Update auf 1.5 ist im internen Beta. Damit kann man dann die gewünschte Lebensdauer des letzten Ereignisses festlegen, also zB daß sich der Sensor nach 48 Stunden auf “kein Erdbeben” zurück stellt. Die Tests brauchen noch etwas, und die Übersetzungen sind auch noch nicht fertig.
3 „Gefällt mir“
das hört sich doch aber toll an.
Ich finde es gut, wie du die Integration so vorantreibst 
1 „Gefällt mir“
Das Update auf v1.5.0 ist raus. Das hier ist das Change-log:
-
die Integration hat jetzt eine Einstellung für die Lebenszeit eines Sensors (sprich, der Sensor “klärt” sich nach der eingestellten Stundenzahl, wenn kein neues Erdbeben oder Update aufgezeichnet wurde)
-
die Ersteinrichtung eines Sensors ist jetzt auf zwei Bildschirme aufgeteilt - das stellt sicher daß alle Einstellungen und der “OK”-Button auch auf kleinen Bildschirmen ohne Scrollen sichtbar sind
-
Übersetzung in Ukrainisch zugefügt
-
aktualisiertes und verbessertes README.md
-
ein paar weitere Bugfixes.
Bekannter Bug: Beim Wiederherstellen eines Sensors nach HA-Neustart oder Update der Integration kann die Entität des Sensors seinen Namen vergessen und den Default “Latest Earthquake” bekommen. Ich bin daran den Fehler zu beheben und möglichst bald ein Bugfix-Update nachzuschieben.
2 „Gefällt mir“
Kannst du kurz beschreiben, wie man deine Integration mit dem Update versorgt?
Seitenleiste → HACS → Heruntergeladen → Earthquake Monitor → drei-Punkte-Menü rechts vom Namen → Informationen aktualisieren
danach wird das Update in den Einstellungen angezeigt → installieren → HA neu starten.
Im Prinzip zeigt HA solche Updates auch von selbst an, ohne daß man den oben beschriebenen Weg bräuchte. Das ist aber ziemlich unzuverlässig, bzw. funktioniert nur mit recht großer Verzögerung. Oft (aber nicht immer) werden verfügbare Updates nach einem HA Neustart angezeigt.
Eventuell musst du die Entität neu benennen (siehe oben: “Bekannter Bug”).
● Der Bug ist bestätigt — alle drei Sensoren haben original_name: “Latest Earthquake”. Die entity_ids (sensor.athen etc.) sind nur wegen manueller Umbenennung noch korrekt.
Edit file
custom_components/earthquake_monitor/sensor.py
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
123
124 await hass.async_add_executor_job(preload_geodata)
125
126 - name = config.get("name", DEFAULT_NAME)
126 + name = config.get("name") or config_entry.title or DEFAULT_NAME
127 center_latitude = config.get("center_latitude")
128 center_longitude = config.get("center_longitude")
129 radius_km = config.get("radius_km")
Der Franzose meint, Zeile 126, bin da aber nicht so weit rein
Es sieht eher so aus als liege der Bug in config_flow.py, weil er (bei mir) nur bei Entitäten auftritt, die ich im Nachhinein nochmal “nach-konfiguriert” habe. Beim Speichern der “options” werden dann die gesamtenconfig_entry.dataüberschrieben. Weil bei den Options kein Name mehr vergeben werden kann, ist die Namensfeld in den gespeicherten configs leer/undefiniert und der Restore nimmt stattdessen den Default.
Ich hab das jetzt so gelöst, daß die alten Daten beim Speichern der Optionen behalten werden und nur “neue” Daten überschrieben werden - bei mir scheint das zu klappen.
Dein Vorschlag mit name = config.get(“name”) or config_entry.title or DEFAULT_NAME kann zumindest nicht schaden, und erhöht die Robustheit - das habe ich gern auch ins Bugfix übernommen! Ich denke aber der eigentliche Fehler liegt schon früher, in config_flow.py.
Das Bugfix-Update auf v1.5.1 ist jetzt auch raus. Ich hoffe das hat den Fehler behoben, ansonsten muß ich nochmal nachbessern.
Das Update auf v1.6.0 ist raus. Zur Zeit ist mir kein Bug bekannt. Ich würde mich wie immer sehr über eure Rückmeldungen freuen. Wenn ich keine Berichte über “Show-Stopper” Bugs bekomme, werde ich das Ding dann mal an die größere Glocke hängen und im offiziellen HA Community Forum einstellen.
Changelog
-
neu: lokalisierter Default-Namen für neue Instanzen/Entities. Der Name folgt jetzt der Spracheinstellung des HA-Backends; also die Sprache, die über Einstellungen → System → Zuhause-Informationen → Sprache (ganz unten). Ich hätte bevorzugt, hier die Frontend-Sprache zu verwenden (also die, die im Benutzer-Profil eingestellt wird), aber die derzeitige Architektur von HA lässt dies nicht in einer stabilen Weise zu.
-
neu: verbesserte Konfiguration auf Geräten mit kleinem Display (um Scrolling während der Einrichtung zu vermeiden), mit zweiseitiger Konfiguration auch für die Erst-Einrichtung
-
neu: Benutzer-wählbares Format (vier Einstellungen) für “freundliche” Zeitmarken
-
verbesserte Übersetzungen
-
aktualisiertes und verbessertes README.md
-
einige kleinere Bugfixes und Code-Verbesserungen
1 „Gefällt mir“
jetzt doch gleich ein Mini-Update auf v1.6.1 hinterher, mit zwei Verbesserungen:
-
Neue Entitäten werden jetzt mit status = “cleared” initialisiert. Bisher wurde das Attribut erst beim ersten aufgezeichneten Ereignis erzeugt. Mit der neuen Lösung können Automationen immer das status-Attribut abfragen, und Dashboards benötigen keine Sonderbehandlung mehr für das nicht-existente Attribut.
-
wenn die Koordinaten des Epizentrums im Meer liegen, wird das country-Attribut jetzt als “offshore” statt als “international waters” gesetzt. Damit werden Ereignisse in landnahen (national zugeordneten) Meeresbereichen korrekter beschrieben.
Das Mini-Update ändert sonst nichts, ist also nicht absolut notwendig damit die Integration vernünftig funktioniert.