Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Homoran]

@arteck sagte in regex von "www.esyoil.com":

das ist deine

ich hab ja auch nur die eine Zeile zum auswerten :cry:
deswegen wollte ich ja den gesamten Quelltext haben.

[haus-automatisierung]

@bahnuhr Da werden noch jede Menge Infos per Ajax nachgeladen. Sogar als JSON. Würde das Thema also deutlich einfacher machen, als die Daten aus dem HTML zu parsen. Eventuell ist ja dein Wunschwert dabei:

https://api.esyoil.com/v1/calculator/bundesland/average

[bahnuhr]

@Homoran
@arteck

Nicht streiten, dafür ist es nicht wichtig genug.
Aber ja, Seite hatte ich mitgeliefert.

Ausprobiert hatte ich nun den regex von @arteck .
Klappt einwandfrei. Würde diesen jetzt ersteinmal in den parser eintragen.

@haus-automatisierung
Schau ich mir an.
Mit api kann ich ;-)
Mit regex kann ich nicht (hab ich noch nicht kapiert; Error 50 halt).

Danke euch.

mfg
Dieter

[bahnuhr]

@haus-automatisierung
Das ist cool.
Ist sogar nach Bundesland.
Danke.

Da bastel ich mir was.

[Ein ehemaliger Benutzer]

@bahnuhr

dass es einen Adapter dafuer gibt, weisst du.. ?
iobroker.heizoel

[bahnuhr]

@neuschwansteini

Ich benutze für sowas keinen extra Adapter.
Kostet nur unnötige Ressourcen.

[haus-automatisierung]

@neuschwansteini sagte in regex von "www.esyoil.com":

dass es einen Adapter dafuer gibt, weisst du.. ?

Der sieht aber verwaist aus (seit 3 Jahren kein Update). Da würde ich auch lieber ein einfaches Script schreiben. Ist ja nicht viel Arbeit.

[Ein ehemaliger Benutzer]

@haus-automatisierung

ja, wenn man nur einen oder ein paar Werte braucht, absolut gerechtfertigt.
Ist ja meist generell die Frage, was einfacher geht, ein Adapter oder ein Script - der Adapter ist fuer den User einfacher zu updaten. Wenn der einmal am Tag die Daten abfragt, braucht der auch nicht mehr Ressourcen als ein Script.
Ansonsten waere das Adapter-Design grundsaetzlich zu ueberdenken :)

Und ja, seit Jahren nix mehr gemacht, wie bei 80% der ueber 500 Adaptern.. vielleicht mach ich mal n Featurerequest beim Admin, dass er nur Adapter anzeigt, die Node >20 anzeigt und in den letzten 12Monaten aktuell gehalten worden sind.
Mal sehen, was noch uebrig bleibt..

[Homoran]

@bahnuhr sagte in regex von "www.esyoil.com":

Aber ja, Seite hatte ich mitgeliefert.

:thinking_face:
ohne Streit! Wo denn?
ich hab nur eine Zeile im Eröffnungspost

ausnahmsweise mal als Bildchen

da ist nicht mehr 😞

[bahnuhr]

@haus-automatisierung sagte in regex von "www.esyoil.com":

@bahnuhr Da werden noch jede Menge Infos per Ajax nachgeladen. Sogar als JSON. Würde das Thema also deutlich einfacher machen, als die Daten aus dem HTML zu parsen. Eventuell ist ja dein Wunschwert dabei:

https://api.esyoil.com/v1/calculator/bundesland/average

Hast du mal einen Link welche api url zur Verfügung stehen.
Konnte auf die Schnelle im Internet nix finden.

[haus-automatisierung]

@bahnuhr sagte in regex von "www.esyoil.com":

Hast du mal einen Link welche api url zur Verfügung stehen.

Entwickler-Tools im Browser aufmachen, Seite neu laden und gucken was nachgeladen wird.
Mehr weiß ich auch nicht.

[haus-automatisierung]

@neuschwansteini sagte in regex von "www.esyoil.com":

Und ja, seit Jahren nix mehr gemacht, wie bei 80% der ueber 500 Adaptern

Gerade geschaut.

• 660 Adapter in beta, nur 290 haben eine Version älter als 365 Tage. Also weit weg von 80%
• 127 benötigen davon node 20
• 269 benötigen mindestens node 18

[Homoran]

@neuschwansteini sagte in regex von "www.esyoil.com":

vielleicht mach ich mal n Featurerequest beim Admin, dass er nur Adapter anzeigt, die Node >20 anzeigt und in den letzten 12Monaten aktuell gehalten worden sind.

das kann ich jetzt nich nachvollziehen!

warum ist ein Adapter untauglich, wenn er bereits mit node v8 funktionieren würde???
Warum darf er nur mit v20 laufen?

und weiterhin:
warum muss an einem funktionierenden Adapter "was gemacht" werden?

ich nutze immer noch Adapter aus den ersten Jahren von ioBroker - ohne irgendwelche Probleme.

[haus-automatisierung]

@homoran sagte in regex von "www.esyoil.com":

Warum darf er nur mit v20 laufen?

Darf schon mit älteren Versionen laufen. Aber die sind ja alle abgekündigt und sollten nicht mehr genutzt werden. Deswegen meckert der Adapter-Checker auch, wenn die definierte Version älter als 20 ist.

Und generell sollte man als Entwickler seine Adapter ja schon grundlegend pflegen. Das passiert in diesem Beispiel gar nicht mehr: https://github.com/TA2k/ioBroker.heizoel/issues/14

Klar, läuft noch - aber wird halt nicht mehr gepflegt. Heißt für mich im Umkehrschluss sehr oft, dass man spätestes bei ersten Problemen etwas neues suchen muss, da niemand antworten wird.

[Homoran]

@haus-automatisierung sagte in regex von "www.esyoil.com":

Darf schon mit älteren Versionen laufen. Aber die sind ja alle abgekündigt und sollten nicht mehr genutzt werden. Deswegen meckert der Adapter-Checker auch, wenn die definierte Version älter als 20 ist.

Das ist für mich eine "Überbetreuung".
Eine dependency sollte nach meinem Verständnis die technische Voraussetzung angeben.

Dass node v20 aktuell ist und genutzt werden soll steht auf einem anderen Blatt.

[haus-automatisierung]

@homoran War ja nur ein Beispiel - die Liste der offenen Themen ist lang. Vieles ist auch deprecated und sollte nicht mehr genutzt werden. Genauso sollten Dependencies aktuell gehalten werden.

Generell finde ich das Vorgehen (aus Entwickler-Sicht) schon gut. Anders kann man den Überblick gar nicht behalten oder die Qualität von Adaptern beurteilen. Ist aber eine Grundsatzdiskussion.

[OliverIO]

@homoran
Das entspricht auch genau meiner Meinung.
Wenn das muss die baseline an Anforderungen vom basissystem kommen. Iobroker 7 hat ja noch v18.
Die Entscheidung welches Risiko jemand eingeht muss beim Nutzer liegen. Gern kann man per notification da dran erinnern.
Ich persönlich würde es ja mit einer Ampel machen zum Gesamtzustand des Systems

Grün keine Aktion notwendig
Gelb Adapter Updates notwendig
Rot betriebssysystem/node/iobroker Update notwendig.

Mit der v20 dependency in package.json schließt man alle von Adapter Updates aus, die, aus welchen Gründen auch immer, noch nicht aktualisiert haben.
Wenn ich es richtig überschaue muss man für v20 auch das Betriebssystem aktualisieren, wegen 64 Bit, was dann wieder einige ältere Hardware aussortiert.
Aber wie gesagt, da bin ich mir nicht ganz so sicher.

Nur um es klar zu machen, ich bin schon dafür, das System aktuell zu halten. Nur will ich als Adapter maintainer meinen Nutzer das nicht vorschreiben wollen.

[haus-automatisierung]

@oliverio sagte in regex von "www.esyoil.com":

Nur will ich als Adapter maintainer meinen Nutzer das nicht vorschreiben wollen.

Man stellt ja nur sicher, dass es damit läuft. Und die Integration-Tests und Unit-Tests lasse ich z.B. mit node18 gar nicht mehr laufen. Zumal ich mir als Entwickler kein System mit einer abgekündigten Version aufsetze, falls jemand Probleme hat.

Erforderlich ist ja noch node18 laut Repo-Checker. node20 ist nur empfohlen. Also genau wie beim js-controller 7 auch.

https://github.com/ioBroker/ioBroker.repochecker/commit/58582aed8e70968f5649e7341079e57bf4f56c2d

[OliverIO]

Ich hatte letztens aufgrund des repocheckers auf v20 umgestellt.
Dann hab ich einen Hinweis bekommen, das jemand den Adapter nicht aktualisieren konnte, der noch ein v18 Node hatte.
Ich habe das mit einem Node 18 docker Container nachgestellt und festgestellt, das aus irgendeinem Grund das. 20, welches nur in github befand und noch nichtmal in ein Release geflossen ist, den Update dieses Adapters generell verhindert hat.
Ich vermute, das es irgendwie mit den Repo Daten zu tun hat, welcher iobroker zentral einsammelt und am Tag dann 2/3 mal bereitstellt zu tun hat, so dass der Admin dann kein Update mehr zulässt.

Daher hab ich wieder zurück gestellt.

[haus-automatisierung]

@oliverio sagte in regex von "www.esyoil.com":

und festgestellt, das aus irgendeinem Grund das. 20, welches nur in github befand und noch nichtmal in ein Release geflossen ist, den Update dieses Adapters generell verhindert hat.

Ja, weil die package.json für die Repository-Liste von GitHub geladen wird (und nicht von npmjs). Ist nicht ganz sauber. Zumal man dann angemeckerte Fehler in Adaptern beheben kann, ohne eine neue Version freizugeben.