Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Pedder007]

echt komisch.
also es ist die 1.9.2 und in der Statistik stehe ich mit meinen Abrufen auf '0'. Hatte mir den neuen (2.ten) Key heute erst (extra zum testen) geholt.
Wenn die da natürlich nun noch die IP gegenprüfen dann wirds lustig. Ich bekomme nämlich von Vodafone meist immer wieder die gleiche IP, das sagt mir zumindest mein Domain-Service, der sich ab und zu mal meldet ;-)
Im Script muss doch auch nur der Key eingetragen werden, oder übersehe ich da noch etwas? Koordinaten holt er sich ja aus den ioBroker Settings.

PS.
Habe nun gerade nochmal alles neu im Script-Editor einkopiert.
Erst Dein Script, dann den Key. Editor sagt mir, alles wie vorher, bzw. 'speichern' Taste wird nicht angezeigt.

habe da noch etwas entdeckt:
Muss das Script ZWINGEND im Ordner common liegen? Ich habe es nämlich in einem Unterordner liegen.
Vergiss die Frage, hab's mir schon gedacht. Ist egal wo es liegt, es läuft in den gleichen Anmeldefehler.

[Schimi]

ich habe es selber in einem unterordner von common

Versuch mal vielleicht die Koordinaten selbst einzutragen (ich meine auf 4 stellen nach dem Punkt/Komma)

Sonst bin ich gerade überfragt...

[Pedder007]

ich denke bei 403 ist es das eher nicht., habs trotzdem probiert, aber gleiche Fehlermeldung.

Ich hatte gerade mal parallel Gemini gefragt und dabei ist herausgekommen, dass es evtl. sein könnte, das der Provider den (2.ten) Zugang nicht freigibt, weil er mit der selben IP bereits einen aktiven Zugang sieht (bei mir läuft aktuell auch noch der dasWetter-Adapter)
Ich habe zum zweiten Account (andere Mailadresse) auch bisher keine Bestätigungsmail bekommen!?

[Schimi]

das Wetter gehört doch zu einem anderen unternehmen, meine ich....

Also ich habe 3 Api Keys zum testen... Wenn ich einen ausgereizt habe, kann ich einfsch den zweiten nutzen und trotz gleicher IP geht's direkt weiter.....

[Pedder007]

Hi, na' da habe ich mir jetzt einen geleistet .... natürlich ist das ein anderer Dienst!!!

Keine Ahnung, aber das kommt davon, wenn man zu viel parallel macht... :-(

Sorry für den Unsinn hier, ich gelobe Besserung :-)

[Bl4ckst4r]

Moin zusammen,

ich möchte mich nur kurz für das Skript bedanken. ☺️

Bis zum Ende des Free Tarifs habe ich den AccuWeather-Adapter genutzt. Da ich Wetter.com aber "privat" sowieso schon verwende, passt das Skript natürlich umso besser.

Ich steuere damit meinen Sonnenschutz und lasse die Rollos abhängig von der Anzahl der Sonnenstunden sowie der Tageshöchsttemperatur herunterfahren. Das umstellen war dank deines Skriptes quasi "Plug and Play".

Daher ein großes Dankeschön fürs Teilen! Das hat mir auf jeden Fall die Arbeit erspart, selbst etwas Eigenes zu entwickeln und bietet der Community definitiv einen echten Mehrwert. :)

Viele Grüße
Bl4ckst4r

[Schimi]

@Pedder007 wenn du jetzt noh sagst, dass das Skript weiter funktioniert... wäre ich erleichtert....

weil ich nach sie vor nicht weiss woran es liegen könnte 🙈

[Pedder007]

@Schimi ENTWARNUNG
Das Script läuft einwandfrei und hat z. B. heute um kurz vor 04:00 und nochmal um kurz vor 16:00 aktualisiert.
Das Problem saß vor der Konsole - hatte den falschen Key, also den vom anderen Anbieter, genutzt.
Sorry war am WE unterwegs und hätte das evtl. oben klarer formulieren sollen.
Danke Dir für Dein vorbildliches Care-Taking ;-)

[Schimi]

Danke für die Rückmeldung :-)

[Schimi]

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.

[nik82]

@schimi
Vielen Dank, was hast du am Limit genau geändert?
Bei mir läufts einwandfrei, aber gleich in dem Zuge noch eine Frage:
Wann wird eigentlich immer aktualisiert? Wir haben jetzt 8:22 Uhr und ich habe immer noch den Vortag drin:

Oder ist das genau wie bei dir der Fall das ich jetzt das Limit erreicht habe:

---

EDIT: Hat sich erledigt dir Frage, bei mir ist auch das Monatslimit erreicht:

[Schimi]

Das sieht nach dem Problem wie bei mir aus...

Das ist das wichtigste aus dem Changelog:

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.

Wie gut es klappt sehen wir Ende März ;-)

Dazu kommt, dass die API und die Tage im Datenpunkt angegeben werden und wenn man dieses ändert, das Skript sich sofort aktualisiert und mit den daten weiterarbeitet.

[nik82]

Habe gerade auf die neue Version umgestellt, jetzt warten wir mal bis März und schauen weiter.
Aber das Script ist auf jedenfall echt Tip Top!