Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Nobbi2]

Hi,
habe seit der Aktualisierung des Adapters auf v0.14 sehr viele Fehler dieser Art.
Laut History ist ja dieser Timeout Error mit der vorletzten Version hinzugefügt worden.

Ich habe da auch schon mal über 99 Fehler ( pro Tag ), und das finde ich schon recht viel.
Gibt es für mich irgendeine Möglichkeit das zu ändern ???
Ist das vielleicht ein Problem der Gegenseite ???

Systemdata	Bitte Ausfüllen
Hardwaresystem:	Intel NUCI5
Arbeitsspeicher:	16 GB
Festplattenart:	SSD
Betriebssystem:	Debian
Node-Version:	18.19.0
Nodejs-Version:	18.19.0
NPM-Version:	10.2.3
Installationsart:	Manuell	> Da bin ich mir aber nicht sicher ....
Image genutzt:	Nein

[mcm1957]

@nobbi2
Wirklich eine Antwort kann wahrscheinlich nur der dev geben.

ABER der axios Timeout kommt - wenn eine schneller Code block richtig war - dann wenn die Gegenseite nicht binnen 10s antwortet. Warum ein Webservice länger als 10s brauchen sollte - keine Ahnung iob das normal ist.

Der Adapter scheint mehrere Geräte zu unterstützen. Hast du mehrere Geräte in deiner Config?
Der Adapter dürfte alle Geräte unmittelbar hintereinander ohne Verzögerung abfragen. Ev stört sich das Webserrvice daran und verzögert die Antwort. Muss sich aber auch der dev ansehen.

Außerdem scheint die defaultmäßige Cron Einstellun * * * * zu sein - der Adapter startet jede Minute neu.
Falls die Messgeräte ihre Daten nicht so oft übermitteln (wovon ich ausgehe) versuch mal die Startfrequend runter zu schraiuben (z.b. alle 15 Minuten)

[Nobbi2]

@mcm57
Ja, ich stand mal auf 10 Sek, habe das dann auf 20 Sek geändert, das funktionierte gut. Seit dem Versionsupdate des Adapters halt jetzt eben dies Fehler....
Ich stelle jetzt mal auf 1 Min um, mal schauen ob das was bringt.
Bin aber auch in der Überlegung auf einen ESP zu wechseln. Den habe ich schon lange hier aber bin wohl etwas zu bequem
:) :)

[mcm1957]

@nobbi2 said in Powerfox2.0 Adapter, AxiosError: timeout of 10000ms exceeded:

@mcm57
Ja, ich stand mal auf 10 Sek, habe das dann auf 20 Sek geändert, das funktionierte gut. Seit dem Versionsupdate des Adapters halt jetzt eben dies Fehler....

10s bei einem Scheduled Adapter ?

Hugh ...

[Nobbi2]

@mcm57
Na, ja hat am Anfang auch gut funktioniert ... :)

[mcm1957]

@nobbi2
Hab mir eher gedacht dass ist ein cpu Test für deine ioBroker host. Alle 10s nen Adapter neu starten - da wird dem js-controller auch nicht fad :-)

Im Ernst:
Wenn eine Adapter so oft pollen soll und DARF dann ist scheduled nicht wirklich die richtige Wahl.

Problem bei zu heftiger Nutzung der Cloud ist
-) dass der Cloudbetreiber alle (identifizierten) ioBroker user aussperrt (gabs schon, soweit ich weiß z.B. bei Alexa)
-) dass der Cloudbetreiber überhaupt den Adapter untersagt und mit juristischen Schritten droht (gab gard erst wieder bei Homeassistant)

Zweiteres ist vor allem dann ein Risiko wenn das benutze Api nicht offiziell freigegeben ist sonder durch Reverse Engeneering wie z.B. analyse des App Verkehrs ermittelt wurde.

Und in jedem Fall ist hier von interesse wie oft die angeschlossenen Messgeräte ihre Daten überhaupt an die Cloud schicken. Öfter als es neue Daten gibt abzufragen bringt ja niemand was

[Nobbi2]

@mcm57
Ja ist wohl richtig, so weit ich weiß ist die API-Nutzung aber offiziell.
Für den Zählerstand ist die Zeit zwischen 2 Abfragen auch nicht so wichtig... für die echte Leistung dann schon eher.
Obwohl ich, glaube ich, auch nicht so oft drauf schaue aber wenn, dann ist 1 Minute schon echt lang :)

[JoergH]

@nobbi2 Wegen der extensiven Anfragen haben die meines Wissens die Mindestzeit für Abfragen nun auf 1 Minute geändert. Wenn man was schnell steuern will, ist es schlauer sich lokal was zu basteln, denn das Ergebnis ist hier wie immer das Gleiche...

[Dicken]

@Nobbi2 wie hast du das Problem gelöst? Habe das selbe Problem. Der Adapter steht standardmäßig auf 1 min.

LG
Dicken

[Nobbi2]

@dicken Hi,
bin weg von Powerfox, habe jetzt einen lokalen Lesekopf mit Tasmota, funktioniert deutlich zuverlässiger und ohne das die Daten irgendwo extern liegen ....