Test Adapter meteonomiqs (wetter.com)

Schimi

[Tester gesucht] ioBroker.meteonomiqs — Wettervorhersage von wetter.com

Hallo zusammen,

ich habe einen Adapter für die Meteonomiqs Public Weather API v4.0 gebaut — das ist die
Schnittstelle hinter wetter.com — und suche Leute, die ihn auf anderer Hardware und in anderen
Umgebungen ausprobieren, bevor ich über eine Einreichung ins offizielle Repository nachdenke.

Angefangen hat das als JavaScript-Skript für meine eigene Installation. Weil daraus mit der
Zeit ein paar tausend Zeilen wurden, ist jetzt ein richtiger Adapter in TypeScript daraus
geworden.

Was er kann


Tagesvorhersage	1–14 Tage: Temperatur, Niederschlag, Wind, Bewölkung, Feuchte, Sonnenstunden, Luftdruck
Tagesabschnitte	Morgen, Mittag, Abend, Nacht je Tag
Stundenwerte	Für einen oder mehrere Tage, aufgelöst in der Zeitzone des Vorhersageorts
`current`-Ordner	Werte der laufenden Stunde, stündlich aktualisiert — ohne zusätzlichen API-Call
Wetterwarnungen	Gruppe, Text und numerischer Schweregrad 0–4, damit man im Skript nicht auf Strings vergleichen muss
Sonne und Mond	Auf- und Untergang, Dämmerung, Tageslänge, Mondaufgang, Mondphase, Tierkreis
Schnee	Schneefallgrenze, Neuschnee, Wasseräquivalent
JSON-Aggregate	`forecast_json` und `hourly_json` für VIS, jarvis und Material-Widgets
Admin-Oberfläche	JSON Config in elf Sprachen

Der Haken, um den herum alles gebaut ist

Der kostenlose Meteonomiqs-Tarif erlaubt 100 Abrufe im Monat. Das ist die zentrale
Randbedingung, und der Adapter ist darauf ausgelegt statt sie zu ignorieren.

Standardmäßig wird dreimal täglich abgerufen — 01:10 für die Tagesplanung, 11:40 als Korrektur
vor dem kritischen Nachmittag, 18:40 für Nacht und Folgetag. Das sind 93 Calls in einem
31-Tage-Monat. Jeder Abruf trägt zusätzlich eine Prioritätsstufe:

Ein Abruf der Stufe N läuft nur, solange das Restbudget N Abrufe pro Tag bis Monatsende trägt.

Wird es eng, fällt zuerst der Abend weg, dann der Mittag. Der nächtliche Abruf überlebt am
längsten und schaltet im Notfall auf jeden zweiten Tag um, statt einfach stehenzubleiben.
Der Adapter hört also nicht mitten im Monat auf zu arbeiten, sondern wird schrittweise
sparsamer.

Damit nicht alle Installationen gleichzeitig auf die API einprasseln, verschiebt jede
Installation ihre Abrufzeiten um bis zu 15 Minuten. Der Versatz wird aus der
ioBroker-Installations-UUID abgeleitet, ist also über Neustarts hinweg stabil und für alle drei
Zeiten gleich, damit die Abstände untereinander erhalten bleiben.

Voraussetzungen

js-controller ≥ 6.0.11, Admin ≥ 7.6.20, Node.js ≥ 22
Ein kostenloser API-Schlüssel von Meteonomiqs.
Er wird in der Instanzkonfiguration verschlüsselt abgelegt.

Installation

Der Adapter ist auf npm veröffentlicht. Im Admin unter Adapter auf das Symbol
„Adapter aus eigener URL installieren", Reiter npm, dort auswählen:

wetter.com Vorhersage

Alternativ über den Reiter GitHub:

https://github.com/Schimi1983/ioBroker.meteonomiqs

Aktuelle Version ist 0.1.6, Lizenz MIT.

Wobei ihr mir konkret helfen könnt

Bei mir läuft er stabil, aber „bei mir läuft es" ist bekanntlich kein Testbericht. Was ich zu
Hause nicht abdecken kann:

Andere Zeitzonen. Die Stundenwerte werden in der Zeitzone des Vorhersageorts aufgelöst, nicht
in der des Hosts. Wer außerhalb von Europe/Berlin sitzt oder eine abweichende Systemzeitzone
fährt, würde mir sehr helfen — besonders die Frage, ob current.time mit der tatsächlichen
Ortszeit übereinstimmt.

Compact-Modus. Ist im Adapter aktiviert, ich habe ihn aber nicht ausgiebig unter Last
getestet. Wer ihn nutzt: Bitte melden, wenn beim Stoppen oder Neustarten der Instanz etwas im
Hostlog auffällt.

Die anderen Sprachen. Elf Sprachen sind hinterlegt, wirklich durchgesehen habe ich Deutsch
und Englisch. Wenn eine Beschriftung schief klingt, sagt gerne Bescheid.

Der Monatswechsel. Die Zähler in info sollen zum Monatsersten zurückspringen. Bei mir hat
noch kein Monatswechsel mit laufendem Adapter stattgefunden.

14 Tage Vorhersage. Ich fahre sieben. Wer die vollen vierzehn einstellt, testet einen Pfad,
den ich im Alltag nicht sehe.

Was ihr wissen solltet

Die Versionsnummer ist bewusst noch 0.1.x. Ich schließe nicht aus, dass sich Datenpunkte
noch einmal ändern — ich sage es dann aber im Changelog dazu.
current ist die Vorhersage für die laufende Stunde, keine Messung. Echte Messwerte
bräuchten die Nowcast- oder Stations-Endpunkte, und die kosten pro Abfrage einen Call — das
passt nicht in einen 100er-Tarif.
Der lokale Zähler in info.requests_month ist eine Schätzung. Die API meldet kein
Restkontingent zurück; verlässlich ist nur ein HTTP 429.

Zur Einordnung

Es gibt bereits ioBroker.wettercom von eifel-tech, das dieselbe API anspricht. Ich bin
darauf erst gestoßen, als npm meinen ursprünglichen Paketnamen wegen zu großer Ähnlichkeit
abgelehnt hat — daher der Name „meteonomiqs" nach dem tatsächlichen Anbieter der Schnittstelle.
Mein Schwerpunkt liegt auf der Budgetverwaltung, den Tagesabschnitten, den Warnungen und dem
current-Ordner. Schaut euch beide an und nehmt, was besser zu euch passt.

Rückmeldungen

Am liebsten als Issue auf GitHub, hier im Thread geht aber genauso.

Hilfreich für mich sind: Adapterversion, js-controller-Version, Betriebssystem, der Inhalt von
meteonomiqs.0.info.status und info.last_error sowie der passende Logauszug. Bei falschen
Werten bitte zusätzlich die Objekt-ID und was ihr stattdessen erwartet hättet.

Repository: https://github.com/Schimi1983/ioBroker.meteonomiqs
Issues: https://github.com/Schimi1983/ioBroker.meteonomiqs/issues
npm: https://www.npmjs.com/package/iobroker.meteonomiqs

Danke fürs Lesen und fürs Ausprobieren!

Community Forum

NEWS