UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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.

:+1: keine Fehlerausgabe

[maxclaudi]

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

:+1: 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:+1:

[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 :+1:
Bei uns .... naja, ein paar Watt bei dem Wetter :face_with_rolling_eyes:

Kamen auch keine weiteren Meldungen

:+1:

[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 :+1:
Bei uns .... naja, ein paar Watt bei dem Wetter :face_with_rolling_eyes:

Kamen auch keine weiteren Meldungen

:+1:

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ß! :sunny:

[maxclaudi]

Bisher habe ich nur ein Log von @daniel-8 (SF800Pro) – ohne seine Hilfe und dieses Log hätte es das Script nicht gegeben.
Danke, Daniel!

---

Mir fehlt noch ein Log eines SF2400AC.

edit: Danke @Mabbi :+1:

[Mabbi]

@maxclaudi
Habe Dir das Ergebnis geschickt.

[maxclaudi]

@mabbi
Dankeschön :+1:
geht nur ums auswerten SF800 (PRO)<>SF2400

[maxclaudi]

Update 16.10.2025 19:35h
Das aktualisierte Script ist im ersten Post des Threads zu finden.

---

Neu:

1. Erfolgreiche HTTP-Verbindung und Wert-Setzung werden jetzt ausgewertet
→ Im Result-Datenpunkt erscheint nun eine Rückmeldung:
"ok set <wert>" oder "error set <wert>".

2. Für die Auswertung der aktuellen Zustände
bitte ausschließlich die read-only-Datenpunkte unter properties verwenden.

3. Die Control-Datenpunkte:

• setSmartMode
• setMqttConnect
• setAcMode
• setInputLimit
• setOutputLimit
• setSocSet
• setMinSoc
• setGridReverse
• setGridStandard
• setInverseMaxPower
  werden jetzt mit -1 initialisiert
  und nach jedem Setzen automatisch wieder auf -1 zurückgesetzt.

Jeder gesetzte Wert wird vor der Ausführung auf Gültigkeit überprüft.
Ist der Wert nicht erlaubt, wird die Anfrage verworfen und es erscheint im Log:

Value xxx for id is not allowed

4. Vorübergehende Verbindungsprobleme (WiFi, Netzwerk etc.)
werden nur noch als "info" im Log protokolliert – keine Warnungen mehr.

5. Alle aktuell von Zendure angebotenen Batteriemodelle, einschließlich sämtlicher X-Varianten, werden jetzt automatisch erkannt.

6. Betrieb mehrerer Zendure-Geräte (ein Script pro Gerät)
Dieses Script steuert ein einzelnes Zendure-Gerät.
Bei mehreren Geräten kann für jedes Gerät ein eigenes Script mit individueller Konfiguration verwendet werden:

• IP-Adresse
• Seriennummer (SN)
• MQTT-Daten (Broker, Port, Benutzer, Passwort)
• Gerätespezifische Werte: maxInputLimit / maxOutputLimit (abhängig vom Gerätetyp)

Die Standard-Intervalle können beibehalten werden:

• intervalGet = 60 s
• intervalMqtt = 300 s

Für jedes Script wird das Standard-Verzeichnis automatisch angelegt:
0_userdata.0.zendure.<Seriennummer>
→ Dort befinden sich alle zugehörigen Datenpunkte des jeweiligen Geräts.
→ Es ist keine manuelle Einrichtung erforderlich.

Empfehlung:

• Bis zu 3 Geräte: völlig unkritisch
• 4 Geräte: problemlos möglich
• Mehr als 4 Geräte: nicht empfohlen!

---

💡 Hinweis: Warum -1 bei den Control-Datenpunkten?

Nach jedem Schaltvorgang wird der Wert automatisch wieder auf -1 gesetzt.
Das stellt sicher, dass auch über Blockly oder andere Skripte
derselbe Befehl mehrfach zuverlässig gesendet werden kann –
selbst wenn der vorherige Wert identisch war.

Hintergrund:
In ioBroker kann über Blockly kein ack: false gesetzt werden.
Ohne diesen automatischen Rücksprung auf -1
würde ein identischer Wert nicht erneut übertragen werden.

Der Mechanismus sorgt also für sauberes, wiederholbares Schalten – auch mit Blockly!

Beispiel:
Wenn über HTTP ein Wert auf 1 gesetzt und später über MQTT auf 0 geändert wurde,
würde der Datenpunkt (vom HTTP-zendSDK) noch 1 enthalten –
ein erneutes Senden von 1 wäre dann nicht möglich.
Mit dem -1 -Reset funktioniert das jetzt jederzeit korrekt.

---

Hinweis für VIS-Benutzer

Ich selbst verwende kein VIS.
VIS-Nutzer können aber einfach den aktuellen Status aus den
properties-(read-only)-Datenpunkten visualisieren.

Zum Steuern und Setzen von Funktionen wie

• smartMode (1 = ein / 0 = aus) oder
• MQTT aktivieren (1) bzw. deaktivieren (0)

können Buttons angelegt werden.
Dabei wird jeweils ein Button für „Ein“ und einer für „Aus“ benötigt.

---

Mir sind möglicherweise noch weitere beschreibbare Keys bekannt.
Diese habe ich bewusst nicht ins Script aufgenommen,
da sie ohne Testgerät nicht sicher geprüft werden können.

---

Warum pro Gerät jeweils ein eigenes Script?

Das ist der einzig saubere und stabile Weg im ioBroker-Kontext.

Vorteile
Isolierte Instanzen

• Jedes Script läuft unabhängig.
• Keine Race-Conditions oder Variablenkonflikte zwischen Geräten.
• Eigene Queue (curlQueue) und eigene Timer für jedes Gerät.

Einfache Wartung

• Für jedes Gerät können IP, Seriennummer, Limits usw. separat gesetzt werden – ohne Code-Chaos.
• Änderungen oder Tests betreffen nur das jeweilige Gerät.

Sauberes Scheduling

• ioBroker regelt das Timing selbst.
• Auch wenn mehrere Scripte mit gleichem Intervall laufen (z. B. alle 10 s), entstehen keine Konflikte.

Performance / Ressourcen

• Der ioBroker-JS-Adapter (Sandbox-Engine) ist leichtgewichtig.
• Solange Queue-Verarbeitung und Timeout-Handling sauber implementiert sind (wie hier), sind selbst 4 Geräte völlig unproblematisch.

Alternative (nur theoretisch)
Ein einziges großes Script mit einer Geräte-Liste (devices = [{SN, IP}, …]) wäre zwar grundsätzlich machbar, aber:

• riskant, wenn ein Gerät hängt oder verzögert antwortet
• aufwendiger zu debuggen
• fehleranfälliger bei Queue-Handling und POST-Timing
• insgesamt schwer wartbar und weniger robust

Fazit:
Ein separates Script pro Gerät ist die technisch saubere, stabile und wartungsfreundliche Lösung im ioBroker-Umfeld.

...viel Spaß :sunny: