Habe mal denn Umgang mit dem Limit optimiert (und dabei etwas weiter gemacht), da ich gestern ins Limit gelaufen bin....
die neue Version findet sich im ersten Post im "Spoiler"
Falls sich Bugs eingeschlichen haben, solltet ihr vielleicht die letzte 1.9.2 Version erstmal irgendwo zwischenspeichern ;-)
Der API-KEY und die anzahl der Tage werden nun auch in Datenpunkten eingegeben...
Spoiler
Changelog: Wetter.com Forecast API (v1.9.2 ➔ v2.6.1)
Dieser Bericht dokumentiert die Evolution des Skripts von einem einfachen API-Abruf hin zu einer performanten, typsicheren und ausfallsicheren ioBroker-Infrastruktur-Komponente.
⚙️ v2.6.x – Perfektionierung & Usability
2.6.1 (Hotfix): * Fix: Konfigurations-Datenpunkte (api_key, forecast_days) werden nun mit write: true angelegt.
Retroaktiver Fix: Ein extendObjectAsync entsperrt automatisch Bestandsdatenpunkte, die in Vorversionen als Read-Only angelegt wurden.
2.6.0 (Ultra-Performance): * RAM-Cache (ensuredPaths): Eliminiert hunderte synchrone existsObject()-Aufrufe an die JS-Engine. I/O-Overhead beim Struktur-Check sinkt nach dem ersten Lauf auf nahezu null.
Zero-Latency: Die künstliche Drosselung wcomWait() wurde vollständig entfernt, da das System durch Caching und Batching überlastungsfrei agiert.
Memory-Management: Timeout-Clearing im HTTP-Request integriert, um Speicherlecks zu verhindern.
Semantischer Fallback: wind_speed_max fällt auf wind.avg zurück, falls die API sporadisch den Maximalwert weglässt.
🚀 v2.5.x – Batching & Deadlock-Schutz
2.5.0:
State-Write-Batching: Schreibvorgänge (setStateChangedAsync) eines Tages werden in einem internen Puffer gebündelt und per Promise.all simultan abgesetzt.
Lock-Härtung: Der HTTP-Call ist nun in ein Promise.race mit einem 10-Sekunden-Timeout gekapselt. Verhindert unendliche Blockaden des isFetching-Locks bei fehlerhaften API-Servern.
Type-Safety: Optionale Verkettung (data.hourly ?? []) schützt vor unvollständigen JSON-Antworten.
API-Resilienz: Erweiterte isNaN-Prüfung in wcomExtractValue(), um korrupte Strings der API abzufangen.
✨ v2.3.x bis v2.4.x – Dynamisierung
2.4.0 (Dynamische Tage): * FORECAST_DAYS aus dem Code in den Datenpunkt info.forecast_days ausgelagert.
Auto-Trigger: Das Skript reagiert sofort auf Änderungen dieses Wertes, passt den Abruf an und löscht überschüssige Tagesordner (cleanupObsoleteDays) rekursiv.
2.3.0 (API-Key Trigger): * Neuer on()-Trigger für info.api_key. Bei Eingabe eines neuen Keys wird sofort ein Test-Abruf (source: 'key_update') erzwungen, der den regulären Restart-Blocker überspringt.
🛡️ v2.1.x bis v2.2.x – Systemhärtung & Controller-Entlastung
2.2.0:
Zeitzonen-Fix: new Date() statt toISOString() behebt falsche Tageswechsel-Berechnungen auf Systemen mit UTC-Offset.
I/O-Reduktion: Einführung von wcomEnsureState() zur Minimierung von createStateAsync-Spam.
2.1.0:
Zero-Churn (Hourly): Das destruktive, rekursive Löschen (deleteObjectAsync) von Stundenwerten wurde durch sauberes Überschreiben abgelöst. Verhindert massive Object-Events und Controller-Spikes.
Null-Safety: wcomExtractValue() gibt strikt 0 statt null zurück, was Typerrors in Number-States verhindert.
Koordinaten-Fix: Längen- und Breitengrade von exakt 0 (Äquator/Nullmeridian) werden nicht mehr als false verworfen.
Native Logs: Das Log-Level debug wird nun korrekt an die ioBroker-Engine durchgereicht.
🔒 v2.0.x – Security & Architektur-Refactoring
2.0.1: Standardisierung des Key-Speicherorts auf 0_userdata.0.wetter_com.info.api_key.
2.0.0: * Security: API-Key aus dem Klartext-Quellcode entfernt.
Semaphore (isFetching): Verhindert Race-Conditions und Doppel-Abrufe, wenn Timer und manuelle Trigger gleichzeitig feuern.
Async-HTTP: httpGet wurde in ein asynchrones Promise gekapselt, um Netzwerkfehler im zentralen try/catch sicher fangen zu können.
Daily-Reset: Fehleranfälliger Mitternachts-Cron für requests_today wurde durch datumsbasierte, asynchrone Prüfung vor jedem API-Call ersetzt.
📉 v1.9.3 – Budget-Stabilität
1.9.3: * Restart-Schutz: Skript-Neustarts lösen keinen API-Call mehr aus, wenn am selben Tag bereits Daten abgerufen wurden (schützt das 100-Calls/Monat Limit bei der Entwicklung).
Erweiterter Economy-Mode: Unterscheidung der Trigger-Quellen (morning, afternoon, start).
Notlauf-Modus: Fällt das Budget auf einen kritischen Wert, wird nur noch jeden zweiten Tag aktualisiert.
