Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro)

[Daniel 8]

@maxclaudi

    at IncomingMessage.<anonymous> (script.js.common.Testphase.@maxclaudi_mit_set:394:29)

[maxclaudi]

....done

[maxclaudi]

@daniel-8

edit Warnung(en) weg. Müsste alles funktionieren. Script ist im ersten Eingangs-Post.

[Daniel 8]

@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@daniel-8

edit Warnung(en) weg. Müsste alles funktionieren. Script ist im ersten Eingangs-Post.

    at IncomingMessage.<anonymous> (script.js.common.Testphase.@maxclaudi_mit_set:394:29)
   at IncomingMessage.<anonymous> (script.js.common.Testphase.@maxclaudi_mit_set:444:25)
at IncomingMessage.<anonymous> (script.js.common.Testphase.@maxclaudi_mit_set:445:25)

die Eine kam 2 mal

[maxclaudi]

@daniel-8
Eingangspost code.

[Daniel 8]

@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@daniel-8
Eingangspost code.

keine Fehlerausgabe

[maxclaudi]

@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

keine Fehlerausgabe

Der Code war nie kaputt – nur die Datenpunkte waren beim ersten Start zu langsam.
Jetzt wird erst angelegt und dann abgefragt. Keine Fehlermeldungen mehr, keine Panik – läuft

[maxclaudi]

@daniel-8
Dankeschön für den Hinweis.

Update 07.10.2025 03:25h
Unix-Timestamp jetzt in lesbarer Form verfügbar:

• .zendureSmartMode.timestamp
• .zendureMqttState.mqttTimestamp

[Daniel 8]

@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@daniel-8
Dankeschön für den Hinweis.

Update 07.10.2025 03:25h
Unix-Timestamp jetzt in lesbarer Form verfügbar:

• .zendureSmartMode.timestamp
• .zendureMqttState.mqttTimestamp

Das hat funtkioniert.
Hatte heute morgen noch einen Fehler vom Script was aber wahrscheinlich in dem Moment war wo irgendwie das System anfangen zu arbeiten hat und schätzungsweise kurz nicht erreichbar

script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: HTTP GET Fehler: connect EHOSTUNREACH 192.168.177.103:80

[maxclaudi]

@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@daniel-8
Dankeschön für den Hinweis.

Update 07.10.2025 03:25h
Unix-Timestamp jetzt in lesbarer Form verfügbar:

• .zendureSmartMode.timestamp
• .zendureMqttState.mqttTimestamp

Das hat funtkioniert.
Hatte heute morgen noch einen Fehler vom Script was aber wahrscheinlich in dem Moment war wo irgendwie das System anfangen zu arbeiten hat und schätzungsweise kurz nicht erreichbar

script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: HTTP GET Fehler: connect EHOSTUNREACH 192.168.177.103:80

Erklärung zur Logmeldung:

HTTP GET Fehler connect EHOSTUNREACH 192.168.177.103:80

Wenn kein weiterer Fehler im Log folgt, war das Zendure-Gerät in diesem Moment einfach nicht erreichbar. Das ist kein Skriptproblem, sondern deutet auf eine kurzzeitige Netzwerkunterbrechung oder interne Blockade des Geräts hin.

Typische Ursachen:

• WLAN kurz weg oder zu schwach:
  Das Gerät hat evtl. den Access Point gewechselt (z. B. in einem Mesh-System), war im Energiesparmodus oder die Verbindung war instabil.
  Auch vorübergehende Störungen durch andere Geräte in der Nähe oder überlappende WLAN-Kanäle können kurzzeitig den Zugriff verhindern.

• Gerät war intern beschäftigt:
  Während interner Vorgänge wie MQTT/HTTP-Umschaltung, Leistungsänderungen oder interner Tasks reagiert das Gerät evtl. für wenige Sekunden nicht.

• Netzwerkverzögerung oder ARP-Problem:
  Der Router hat die IP kurz aus der ARP-Tabelle entfernt, oder DHCP hat intern eine Neuzuweisung vorbereitet.

• Sleep / Neustart:
  Gerät war kurz im Standby oder hat einen automatischen Neustart ausgeführt (z. B. nach Konfigurationsänderung).

Wenn nach dieser Meldung keine weiteren Fehler folgen und die nächsten Abfragen wieder funktionieren, ist kein Eingreifen nötig.
Das Gerät war nur kurzzeitig nicht erreichbar und hat sich selbst erholt.

[Daniel 8]

@maxclaudi

Ja das war meine Vermutung. Wird ca. Zu dem Zeitpunkt gewesen sein wo irgendwie pv angefangen hat zu produzieren. Habe ich ja nie behauptet das es ein script Fehler ist. Kamen auch keine weiteren Meldungen

[maxclaudi]

@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@maxclaudi

Ja das war meine Vermutung. Wird ca. Zu dem Zeitpunkt gewesen sein wo irgendwie pv angefangen hat zu produzieren.

Bei Dir wurde wenigstens produziert
Bei uns .... naja, ein paar Watt bei dem Wetter

Kamen auch keine weiteren Meldungen

[Daniel 8]

@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@maxclaudi

Ja das war meine Vermutung. Wird ca. Zu dem Zeitpunkt gewesen sein wo irgendwie pv angefangen hat zu produzieren.

Bei Dir wurde wenigstens produziert
Bei uns .... naja, ein paar Watt bei dem Wetter

Kamen auch keine weiteren Meldungen

Naja die Welt war es nicht. 1,5 kWh. Aber es geht noch schlechter

[Daniel 8]

@maxclaudi

Heute morgen ziemlich um die gleiche Zeit (20 Minuten früher) eine andere Meldung. Ich schätzte da ist wieder der Speicher irgendwie hochgefahren.

error: javascript.0 (32915) script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: HTTP GET Fehler: socket hang up

[maxclaudi]

@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@maxclaudi

Heute morgen ziemlich um die gleiche Zeit (20 Minuten früher) eine andere Meldung. Ich schätzte da ist wieder der Speicher irgendwie hochgefahren.

error: javascript.0 (32915) script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: HTTP GET Fehler: socket hang up

Danke Daniel.

Kurzinfo zum „socket hang up“:
Die Verbindung zum Zendure-Gerät wurde vom Gerät oder vom Netzwerk vorzeitig beendet – völlig normal und unkritisch.

Passiert z. B. wenn

• das Gerät kurz nicht erreichbar ist (WLAN-Störung, Interferenzen, Mesh-Wechsel, Sleep-Modus, Reichweite usw.),
• oder die Antwort zu lange dauert und http.request den Socket schließt (z. B. Gerät zu beschäftigt).

Der socket hang up ist kein Scriptfehler, sondern nur ein temporärer Netzwerkzustand.
Das Script läuft ganz normal weiter.
(ja, ich weiß – sagst du auch nicht , nur als Hinweis für alle.)

Im Log steht das als „Fehler“, weil in diesem Moment keine Verbindung zustande kam.
Man könnte das Script so anpassen, dass statt „Fehler“ eine „Warnung“ geloggt wird – das ändert aber nichts daran, dass diese eine Abfrage im Intervall einfach übersprungen wird.

Vermutlich liegt die Ursache in einer kleinen WLAN-Reichweiten- oder Interferenzsituation (z. B. andere Geräte auf demselben Kanal).

Solche Situationen kommen auch bei MQTT oder anderen Verbindungen gelegentlich vor – unabhängig davon, ob sie im Log auftauchen oder nicht.

Also alles gut

[maxclaudi]

@daniel-8

Update 10.10.2025 15:47h
Hier eine Liste typischer Fehlermeldungen, die in der ioBroker-JavaScript-Sandbox bei httpGet oder http.request auftreten können – selbst wenn alles korrekt programmiert ist, aber die Verbindung oder das Gerät Probleme macht.

Fehlermeldung	Bedeutung	Typische Ursache
EHOSTUNREACH	Host (IP) nicht erreichbar	Gerät offline, WLAN-Repeater gewechselt, Mesh-Roaming, kurzzeitig kein Netz
ECONNREFUSED	Verbindung aktiv abgelehnt	Gerät ist erreichbar, Dienst (Port 80) reagiert gerade nicht, z. B. Neustart
ETIMEDOUT	Timeout (keine Antwort innerhalb der Zeit)	Gerät zu beschäftigt, schwaches WLAN, Ping funktioniert, HTTP antwortet zu spät
socket hang up	Verbindung unerwartet beendet	Gerät hat Verbindung abgebrochen (z. B. keine Antwort innerhalb der Zeit)
ECONNRESET	Verbindung vom Zielgerät zurückgesetzt	Meist firmwareseitig, Request nicht vollständig verarbeitet
ENETUNREACH	Netzwerkroute nicht erreichbar	Router kurzzeitig ohne Route zur IP (häufig bei WLAN-Mesh während Kanalwechsel)
EAI_AGAIN	Temporäres DNS-Problem	DNS-Server antwortet nicht schnell genug
ENOTFOUND	Hostname konnte nicht aufgelöst werden	IP ok, aber Name nicht gefunden (z. B. bei Geräten mit mDNS wie zendure.local)

Hinweis:
Dies sind harmlose, verbindungsbedingte Fehler. Solche Kommunikationsfehler können auch bei anderen Protokollen (z. B. MQTT) auftreten.

Bisher wurden diese Fälle als „Fehler“ im LOG angezeigt, damit man sieht, dass ein Abruf oder Befehl nicht ausgeführt werden konnte. Das Script arbeitet jedoch zuverlässig weiter.

---

Script-Update:

1. Die üblichen Verdächtigen werden jetzt nicht mehr als „Fehler“, sondern als „Warnung“ ins LOG geschrieben – das hält das LOG sauberer und reduziert Panik.

2. Ein zusätzlicher Datenpunkt SetInverseMaxPower wurde hinzugefügt.

Viel Spaß!