Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2
-
„Erkenntnis aus einer KI ohne Quelle“
Bist du denn sicher dass das nicht eh stimmt? Hast du mit dem Author der betreffenden Veröffentlichung mal Kontakt aufgenommen?
Eventuell hat ja wirklich eine AI deine Arbeit "geklaut". So ganz unwahrscheinlich ist es nicht, dass auf ein passende Frage dein Code mehr oder weniger unverändert angeboten wird. Und die meisten AI Augaben beinhalten keine Quellen. Die zitierte Angabe „Erkenntnis aus einer KI ohne Quelle“ deutet für mich eigentlich nicht darauf hin, dass sich da wer persönlich deine Arbeit unter den Nagel reißen will.
Zusatzfrage: Hast du ein Copyright / Lizenz o.ä. direkt in deinem Script stehen? Den Querbezug zwischen diesem Topic und einem Skript ist ev. auch für eine AI nicht leicht herzustellen.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer 'nen Kaffee spendieren will: https://paypal.me
-
„Erkenntnis aus einer KI ohne Quelle“
Bist du denn sicher dass das nicht eh stimmt? Hast du mit dem Author der betreffenden Veröffentlichung mal Kontakt aufgenommen?
Eventuell hat ja wirklich eine AI deine Arbeit "geklaut". So ganz unwahrscheinlich ist es nicht, dass auf ein passende Frage dein Code mehr oder weniger unverändert angeboten wird. Und die meisten AI Augaben beinhalten keine Quellen. Die zitierte Angabe „Erkenntnis aus einer KI ohne Quelle“ deutet für mich eigentlich nicht darauf hin, dass sich da wer persönlich deine Arbeit unter den Nagel reißen will.
Zusatzfrage: Hast du ein Copyright / Lizenz o.ä. direkt in deinem Script stehen? Den Querbezug zwischen diesem Topic und einem Skript ist ev. auch für eine AI nicht leicht herzustellen.
„Erkenntnis aus einer KI ohne Quelle“
Bist du denn sicher dass das nicht eh stimmt? Hast du mit dem Author der betreffenden Veröffentlichung mal Kontakt aufgenommen?
Eventuell hat ja wirklich eine AI deine Arbeit "geklaut". So ganz unwahrscheinlich ist es nicht, dass auf ein passende Frage dein Code mehr oder weniger unverändert angeboten wird. Und die meisten AI Augaben beinhalten keine Quellen. Die zitierte Angabe „Erkenntnis aus einer KI ohne Quelle“ deutet für mich eigentlich nicht darauf hin, dass sich da wer persönlich deine Arbeit unter den Nagel reißen will.
Die betreffenden Personen wissen sehr genau, was sie tun.
Zusatzfrage: Hast du ein Copyright / Lizenz o.ä. direkt in deinem Script stehen? Den Querbezug zwischen diesem Topic und einem Skript ist ev. auch für eine AI nicht leicht herzustellen.
Zur Zusatzfrage:
Ja, dieser Hinweis steht von Anfang an gut sichtbar als Textblock sowohl in der Anleitung, im ersten Post als auch direkt im Quelltext des Skripts unter „Ein Wort in eigener Sache“:
Es geht mir hierbei überhaupt nicht um irgendwelche weiteren Schritte oder endlose Foren-Diskussionen, sondern schlicht und einfach um den grundlegendsten Anstand unter Entwicklern innerhalb einer Open-Source-Community.
-
Du schreibst:
Cloud und App funktionieren dabei ganz normal herkömmlich weiter, so wie von Zendure vorgesehen.
Verständnisproblem:
Das heißt, SF800 Pro benötigt weiterhin einen Internetzugang und kontaktiert etwas alle 3min das Zuhause?Ich habe mal spaßenshalber den Internetzugang gesperrt, aber dann ist das Gerät offline (laut App) und Dein HTTP-Script wirft Fehler ("Bitte IP des Gerätes überprüfen").
Dies im Zusamnmenhang mit dem Hinweis von @nograx betreffs SSL bei neuer Firmware.Ich interpretiere das so, dass das Gerät weiterhin die Daten in die Cloud schickt und die App diese dort abholt (oder halt andersherum). Also doch nicht ganz lokaler Betrieb?
Kannst Du mir bitte auf die Sprünge helfen?
Andere Frage:
Das Steuerungsscript (ehemals für den zendure-solarflow-Adapter) hat selbst ein Interval (Standard 5000ms). Vermutlich verlängert sich dadurch die Reaktionszeit im Zusammenhang mit dem HTTP-Script. Könnte ich im Steuerungsscript das Interval weit heruntersetzen?BTW:
Darüber hinaus klappt das mit dem HTTP-Script hervorragend, allerdings wird ein kleiner, vermutlich unbedeutender Fehler/Warnung im Script signalisiert:return `${d.toLocaleTimeString("de-DE", **timeOptions**)}, ${d.toLocaleDateString("de-DE", **dateOptions**)}`; No overload matches this call. Overload 1 of 3, '(locales?: string | string[], options?: DateTimeFormatOptions): string', gave the following error. Argument of type '{ timeZone: string; hour: string; minute: string; second: string; hour12: boolean; }' is not assignable to parameter of type 'DateTimeFormatOptions'.Muss ich da etwas ändern?
Danke für Nachhilfe.
Wenns nicht geht, wie man will - muss mans tun, wie man kann. -
Du schreibst:
Cloud und App funktionieren dabei ganz normal herkömmlich weiter, so wie von Zendure vorgesehen.
Verständnisproblem:
Das heißt, SF800 Pro benötigt weiterhin einen Internetzugang und kontaktiert etwas alle 3min das Zuhause?Ich habe mal spaßenshalber den Internetzugang gesperrt, aber dann ist das Gerät offline (laut App) und Dein HTTP-Script wirft Fehler ("Bitte IP des Gerätes überprüfen").
Dies im Zusamnmenhang mit dem Hinweis von @nograx betreffs SSL bei neuer Firmware.Ich interpretiere das so, dass das Gerät weiterhin die Daten in die Cloud schickt und die App diese dort abholt (oder halt andersherum). Also doch nicht ganz lokaler Betrieb?
Kannst Du mir bitte auf die Sprünge helfen?
Andere Frage:
Das Steuerungsscript (ehemals für den zendure-solarflow-Adapter) hat selbst ein Interval (Standard 5000ms). Vermutlich verlängert sich dadurch die Reaktionszeit im Zusammenhang mit dem HTTP-Script. Könnte ich im Steuerungsscript das Interval weit heruntersetzen?BTW:
Darüber hinaus klappt das mit dem HTTP-Script hervorragend, allerdings wird ein kleiner, vermutlich unbedeutender Fehler/Warnung im Script signalisiert:return `${d.toLocaleTimeString("de-DE", **timeOptions**)}, ${d.toLocaleDateString("de-DE", **dateOptions**)}`; No overload matches this call. Overload 1 of 3, '(locales?: string | string[], options?: DateTimeFormatOptions): string', gave the following error. Argument of type '{ timeZone: string; hour: string; minute: string; second: string; hour12: boolean; }' is not assignable to parameter of type 'DateTimeFormatOptions'.Muss ich da etwas ändern?
Danke für Nachhilfe.
hallo erst mal :-)
zum Thema Cloud / lokaler Betrieb:
Das HTTP-Script selbst benötigt keinen Internetzugang.
Die Kommunikation erfolgt direkt zwischen ioBroker und dem Zendure-Gerät über dessen lokale IP-Adresse.Die App hingegen arbeitet weiterhin über die Zendure-Cloud.
Wenn Du dem Gerät den Internetzugang sperrst, erscheint es deshalb in der App als offline, obwohl es im lokalen Netzwerk möglicherweise weiterhin erreichbar ist.Mein Script greift ausschließlich auf die lokale HTTP-Schnittstelle zu und nutzt die Cloud nicht.
Wenn bei gesperrtem Internetzugang zusätzlich die Meldung "Keine Verbindung möglich.
Zendure-Geräte IP prüfen!" erscheint, bedeutet das lediglich, dass das Script keine gültige Antwort mehr vom lokalen HTTP-Endpunkt erhalten hat.
Dass die Fehlermeldung kam, bedeutet, dass vier Verbindungsversuche in Folge fehlgeschlagen sind.
Das Script läuft weiter und sobald wieder eine Verbindung zustande kommt, verschwindet die Fehlermeldung.Mein aktueller Kenntnisstand:
- Für die Aktivierung der lokalen API verlangt Zendure einmalig den HEMS-Schritt.
- Für den anschließenden Betrieb meines Scripts nutze ich kein HEMS.
- Bei mir läuft die lokale Steuerung seit langer Zeit problemlos ohne HEMS.
- Aufgrund der vielen Nutzer und der hohen Anzahl an Thread-Aufrufen gehe ich davon aus, dass die grundsätzliche Funktionsweise des Scripts korrekt ist.
Ob bei aktivem HEMS die lokale HTTP-Schnittstelle deaktiviert oder anderweitig eingeschränkt wird, kann ich Dir nicht sicher sagen.
Die bisherigen Rückmeldungen deuten jedoch darauf hin, dass HEMS und rein lokale Steuerung nicht immer problemlos zusammenarbeiten.
Bei mir ist HEMS deaktiviert.Da mein Script ausschließlich lokal per HTTP kommuniziert, wäre das zunächst nicht zu erwarten.
Warum das Gerät in diesem Fall nicht mehr auf die lokale HTTP-Abfrage antwortet, kann ich aktuell nicht sicher beurteilen.
Es wurde allerdings schon mehrfach berichtet, dass einige neuere Geräte ohne Cloud-Verbindung nicht vollständig lokal nutzbar sind.
Ob das hier die Ursache ist, kann ich nicht beurteilen.
Hier ist Zendure mit der Firmware gefragt.Zum Intervall des Steuerungsscripts:
Mein Script selbst arbeitet standardmäßig mit einem GET-Intervall von 5000 ms. Die aktuelle Gerätekonfiguration wird also alle 5 Sekunden abgefragt.
Zusätzlich werden Schreibvorgänge gesammelt und zeitnah übertragen.Das Intervall von meinem Script kann grundsätzlich verkleinert werden, ich empfehle das aber nicht.
Die HTTP-Schnittstelle liefert keine Messwerte im Millisekundenbereich und die zusätzliche Last auf Gerät und Netzwerk steigt unnötig an.Für Regelungen ist meist ohnehin das eigentliche Steuerungsscript der begrenzende Faktor.
Wenn dieses ebenfalls alle 5 Sekunden läuft, ergibt sich im Normalfall eine Reaktionszeit von wenigen Sekunden, was für Energiemanagement-Aufgaben üblicherweise ausreichend ist.
Ob Dein eigentliches Steuerungsscript 5 Sekunden benötigt, kann ich nicht beurteilen.
Beispiel: Mein Hauptscript zur Steuerung verwendet z. B. als Haupt-Trigger den Stromzählerwert.
Der Stromzählerwert wird ca alle 3 bis 5 sek. aktualisiert und damit getriggert.
Es hat sonst keine Verzögerungen.Zur TypeScript-Warnung:
Du musst nichts ändern.
Die Meldung stammt vom TypeScript-Checker des Editors und hat keine Auswirkung auf die Funktion.
Falls Du die Warnung loswerden möchtest, kannst Du timeOptions und dateOptions explizit als Intl.DateTimeFormatOptions typisieren.
Für den Betrieb des Scripts ist das aber nicht erforderlich.Der betreffende Code ist normales JavaScript und funktioniert korrekt.
Je nach Version des JavaScript-Adapters, Node.js oder der verwendeten TypeScript-Definitionen kann bei den Objekten timeOptions und dateOptions eine Typwarnung angezeigt werden.
Da das Script bei Dir korrekt läuft, musst Du daran nichts ändern. Es handelt sich lediglich um eine Editor-Warnung und nicht um einen Laufzeitfehler.
Ich würde zunächst prüfen:
- JavaScript-Adapter aktuell?
- Node.js aktuell?
- Verschwindet die Warnung nach einem Adapter-Update?
-
Guten Morgen @maxclaudi ,
und vielen Dank für die ausführliche Beantwortung meiner Fragen. Damit klärt sich einiges im BioRAM
.Mal von hinten beginnend:
Die Meldung stammt vom TypeScript-Checker des Editors und hat keine Auswirkung auf die Funktion.
Ah, ok. Und ja, Probleme damit gab es nicht. Mir ist es lediglich aufgefallen und ich war mir nicht sicher, ob das für Dich wichjtig sein könnte. - Erledigt.
Ob Dein eigentliches Steuerungsscript 5 Sekunden benötigt, kann ich nicht beurteilen.
Ja, natürlich, aber Dein Beispiel (Trigger ist Stromzähler) allein hilft mir schon weiter, weil es bei mir ähnlich läuft. Dann werde ich mal schauen, ob ich das Interval beim eigentlichen Steuerungsscript verkleinern oder ganz rausnehmen kann. Sonst wird mir das Ganze bei meiner bescheidenen Anlage zu träge.
Zum Internetzugang:
Die Kommunikation erfolgt direkt zwischen ioBroker und dem Zendure-Gerät über dessen lokale IP-Adresse.
Die App hingegen arbeitet weiterhin über die Zendure-Cloud.Ok, dann habe ich das zumindest richtig verstanden - Danke.
Das Script läuft weiter und sobald wieder eine Verbindung zustande kommt, verschwindet die Fehlermeldung.
Das muss ich nochmal überprüfen. Mir ist so, als wenn das dann permanent im Log stand.
Da melde ich mich ggfl. noch einmal...Mein aktueller Kenntnisstand:
Für die Aktivierung der lokalen API verlangt Zendure einmalig den HEMS-Schritt.
Für den anschließenden Betrieb meines Scripts nutze ich kein HEMS.
Bei mir läuft die lokale Steuerung seit langer Zeit problemlos ohne HEMS.Ok, ich habe ja seit ich das Gerät habe, mehrfach HEMS ein- und ausgeschaltet, womit die lokale API eigentlich aktiv sein sollte. Vermutlich würde sonst Dein Script wohl auch nicht funktionieren.
Auch ich nutze kein HEMS - weder vorher mit dem zendure-Adapter, noch mit Deinem Script.
Und ja, die Steuerung läuft auch hier problemlos - besten Dank für Deine Arbeit.Da ich mit Zendure in regem und angenehmen Austausch stehe, kam heute die Frage von dort, ob ich schon auf HEMS 2.0 aktualisiert habe. Natürlich erst einmal nicht.
So, nun an die Arbeit....
Bis dahin zunächst und nochmals Danke. Ich melde mich dann nochmal.Wenns nicht geht, wie man will - muss mans tun, wie man kann. -
Guten Morgen @maxclaudi ,
und vielen Dank für die ausführliche Beantwortung meiner Fragen. Damit klärt sich einiges im BioRAM
.Mal von hinten beginnend:
Die Meldung stammt vom TypeScript-Checker des Editors und hat keine Auswirkung auf die Funktion.
Ah, ok. Und ja, Probleme damit gab es nicht. Mir ist es lediglich aufgefallen und ich war mir nicht sicher, ob das für Dich wichjtig sein könnte. - Erledigt.
Ob Dein eigentliches Steuerungsscript 5 Sekunden benötigt, kann ich nicht beurteilen.
Ja, natürlich, aber Dein Beispiel (Trigger ist Stromzähler) allein hilft mir schon weiter, weil es bei mir ähnlich läuft. Dann werde ich mal schauen, ob ich das Interval beim eigentlichen Steuerungsscript verkleinern oder ganz rausnehmen kann. Sonst wird mir das Ganze bei meiner bescheidenen Anlage zu träge.
Zum Internetzugang:
Die Kommunikation erfolgt direkt zwischen ioBroker und dem Zendure-Gerät über dessen lokale IP-Adresse.
Die App hingegen arbeitet weiterhin über die Zendure-Cloud.Ok, dann habe ich das zumindest richtig verstanden - Danke.
Das Script läuft weiter und sobald wieder eine Verbindung zustande kommt, verschwindet die Fehlermeldung.
Das muss ich nochmal überprüfen. Mir ist so, als wenn das dann permanent im Log stand.
Da melde ich mich ggfl. noch einmal...Mein aktueller Kenntnisstand:
Für die Aktivierung der lokalen API verlangt Zendure einmalig den HEMS-Schritt.
Für den anschließenden Betrieb meines Scripts nutze ich kein HEMS.
Bei mir läuft die lokale Steuerung seit langer Zeit problemlos ohne HEMS.Ok, ich habe ja seit ich das Gerät habe, mehrfach HEMS ein- und ausgeschaltet, womit die lokale API eigentlich aktiv sein sollte. Vermutlich würde sonst Dein Script wohl auch nicht funktionieren.
Auch ich nutze kein HEMS - weder vorher mit dem zendure-Adapter, noch mit Deinem Script.
Und ja, die Steuerung läuft auch hier problemlos - besten Dank für Deine Arbeit.Da ich mit Zendure in regem und angenehmen Austausch stehe, kam heute die Frage von dort, ob ich schon auf HEMS 2.0 aktualisiert habe. Natürlich erst einmal nicht.
So, nun an die Arbeit....
Bis dahin zunächst und nochmals Danke. Ich melde mich dann nochmal.@Rico-Sander
Thema Trigger:
ich weiß nicht, ob es für Dich oder andere interessant ist und weiterhilft.
Hier mal eine Info, wie das mit den Triggern realisiert werden kann.Bei einem Objekt mit:
mehreren Zendure-Geräten
- 1 Hauptgerät mit 4 PV-Modulen an den MC4-Eingängen und 3x AB2000S-Batterien
- 1 weiteres Zendure-Gerät mit 2x AB2000X-Batterien, an dessen OffGrid-Steckdose zusätzlich 2 Hoymiles-Wechselrichter angeschlossen sind
- mehreren weiteren PV-Modulen mit separaten Hoymiles-Wechselrichtern, die direkt ins Hausnetz einspeisen
bestehen die Regelungen aus mehreren Scripts, die zusammenarbeiten.
Das Haupt-Script mit DPL-Regelung für das Zendure-Hauptgerät verwendet als Haupt-Trigger den aktuellen Stromzählerwert.
Der aktuelle Zählerwert wird aus einem Datenpunkt gelesen:
trigger_easy_shelly
Für diesen Datenpunkt gibt es ein separates Script.
Der Zählerwert wird redundant über zwei Quellen erfasst:
- IR-Lesekopf direkt am easyMeter-Zähler des Energieversorgers
- Shelly Pro 3EM als Fallback
Standardmäßig wird der Wert des IR-Lesekopfs verwendet.
Sollte dieser innerhalb einer definierten Zeit keine Daten mehr liefern, wird automatisch auf den Wert des Shelly umgeschaltet.
Gleichzeitig wird eine Nachricht auf das Smartphone gesendet.Sollten von beiden Quellen keine Daten mehr kommen, liegt entweder ein Stromausfall oder ein größeres Problem vor.
Dadurch hat man einen sehr zuverlässigen Trigger auf den tatsächlichen Netzbezug bzw. die Einspeisung.
Das zweite Zendure-Gerät dient hauptsächlich zur Versorgung einer nächtlichen Grundlast.
Die Leistung wird dort nur in wenigen Stufen angepasst, abhängig von Netzbezug, verfügbarer Leistung der DPL-Regelung vom anderen Haupt-Script, SoC und Zellspannungen aller Batterien.
Für dieses Script wird bewusst kein Trigger auf den Stromzählerwert verwendet.
Der Trigger ist stattdessen der vom Gerät gelieferte Zendure-Timestamp.
Der Hintergrund:
Eine Änderung des Timestamps bedeutet:
- Polling erfolgreich
- Zendure erreichbar
- aktuelle Daten empfangen
- die empfangene Geräteantwort wurde vollständig verarbeitet und ausgewertet
- die Auswertung erfolgt unmittelbar nach dem Empfang der Geräteantwort und nicht zeitversetzt über eine separate Intervall-Abfrage
Das ist für die Regelung wichtiger als ein einzelner aktueller Zählerwert, da dieser ohnehin zusätzlich im Script abgefragt wird.
Wird kein neuer Timestamp empfangen, wurde auch keine neue Geräteantwort erfolgreich verarbeitet.
In diesem Fall wird sofort eine Benachrichtigung versendet.Einen solchen Ausfall habe ich testweise simuliert. Die Benachrichtigung wurde unmittelbar ausgelöst.
Im laufenden Betrieb ist dieser Fall bisher noch nicht aufgetreten.Das Script aus diesem Thread zur Steuerung eines Zendure-Geräts pollt im festen Intervall und verarbeitet die JSON-Antwort.
Anschließend werden nur die Werte aktualisiert, die sich tatsächlich geändert haben.
Unveränderte Datenpunkte werden bewusst nicht neu geschrieben.Eine Änderung des Timestamps bedeutet daher nicht, dass sich Werte geändert haben, sondern dass eine neue Geräteantwort erfolgreich empfangen, verarbeitet und ausgewertet wurde.
Dadurch ist sichergestellt, dass die Regelung auf Basis eines vollständig verarbeiteten Datensatzes arbeitet.
Auch wenn einzelne Datenpunkte unverändert bleiben und deshalb nicht neu geschrieben werden, entsprechen sie weiterhin dem aktuellen Gerätezustand.Deshalb ist für mich hier ein Trigger auf den Datenpunkt timestamp ideal.
-
Danke für die Einblicke in ein ziemlich ausgewachsenes System - auch wenn es für mich nicht zutrifft. Interessant sind solche Infos allemal.
-
hallo erst mal :-)
zum Thema Cloud / lokaler Betrieb:
Das HTTP-Script selbst benötigt keinen Internetzugang.
Die Kommunikation erfolgt direkt zwischen ioBroker und dem Zendure-Gerät über dessen lokale IP-Adresse.Die App hingegen arbeitet weiterhin über die Zendure-Cloud.
Wenn Du dem Gerät den Internetzugang sperrst, erscheint es deshalb in der App als offline, obwohl es im lokalen Netzwerk möglicherweise weiterhin erreichbar ist.Mein Script greift ausschließlich auf die lokale HTTP-Schnittstelle zu und nutzt die Cloud nicht.
Wenn bei gesperrtem Internetzugang zusätzlich die Meldung "Keine Verbindung möglich.
Zendure-Geräte IP prüfen!" erscheint, bedeutet das lediglich, dass das Script keine gültige Antwort mehr vom lokalen HTTP-Endpunkt erhalten hat.
Dass die Fehlermeldung kam, bedeutet, dass vier Verbindungsversuche in Folge fehlgeschlagen sind.
Das Script läuft weiter und sobald wieder eine Verbindung zustande kommt, verschwindet die Fehlermeldung.Mein aktueller Kenntnisstand:
- Für die Aktivierung der lokalen API verlangt Zendure einmalig den HEMS-Schritt.
- Für den anschließenden Betrieb meines Scripts nutze ich kein HEMS.
- Bei mir läuft die lokale Steuerung seit langer Zeit problemlos ohne HEMS.
- Aufgrund der vielen Nutzer und der hohen Anzahl an Thread-Aufrufen gehe ich davon aus, dass die grundsätzliche Funktionsweise des Scripts korrekt ist.
Ob bei aktivem HEMS die lokale HTTP-Schnittstelle deaktiviert oder anderweitig eingeschränkt wird, kann ich Dir nicht sicher sagen.
Die bisherigen Rückmeldungen deuten jedoch darauf hin, dass HEMS und rein lokale Steuerung nicht immer problemlos zusammenarbeiten.
Bei mir ist HEMS deaktiviert.Da mein Script ausschließlich lokal per HTTP kommuniziert, wäre das zunächst nicht zu erwarten.
Warum das Gerät in diesem Fall nicht mehr auf die lokale HTTP-Abfrage antwortet, kann ich aktuell nicht sicher beurteilen.
Es wurde allerdings schon mehrfach berichtet, dass einige neuere Geräte ohne Cloud-Verbindung nicht vollständig lokal nutzbar sind.
Ob das hier die Ursache ist, kann ich nicht beurteilen.
Hier ist Zendure mit der Firmware gefragt.Zum Intervall des Steuerungsscripts:
Mein Script selbst arbeitet standardmäßig mit einem GET-Intervall von 5000 ms. Die aktuelle Gerätekonfiguration wird also alle 5 Sekunden abgefragt.
Zusätzlich werden Schreibvorgänge gesammelt und zeitnah übertragen.Das Intervall von meinem Script kann grundsätzlich verkleinert werden, ich empfehle das aber nicht.
Die HTTP-Schnittstelle liefert keine Messwerte im Millisekundenbereich und die zusätzliche Last auf Gerät und Netzwerk steigt unnötig an.Für Regelungen ist meist ohnehin das eigentliche Steuerungsscript der begrenzende Faktor.
Wenn dieses ebenfalls alle 5 Sekunden läuft, ergibt sich im Normalfall eine Reaktionszeit von wenigen Sekunden, was für Energiemanagement-Aufgaben üblicherweise ausreichend ist.
Ob Dein eigentliches Steuerungsscript 5 Sekunden benötigt, kann ich nicht beurteilen.
Beispiel: Mein Hauptscript zur Steuerung verwendet z. B. als Haupt-Trigger den Stromzählerwert.
Der Stromzählerwert wird ca alle 3 bis 5 sek. aktualisiert und damit getriggert.
Es hat sonst keine Verzögerungen.Zur TypeScript-Warnung:
Du musst nichts ändern.
Die Meldung stammt vom TypeScript-Checker des Editors und hat keine Auswirkung auf die Funktion.
Falls Du die Warnung loswerden möchtest, kannst Du timeOptions und dateOptions explizit als Intl.DateTimeFormatOptions typisieren.
Für den Betrieb des Scripts ist das aber nicht erforderlich.Der betreffende Code ist normales JavaScript und funktioniert korrekt.
Je nach Version des JavaScript-Adapters, Node.js oder der verwendeten TypeScript-Definitionen kann bei den Objekten timeOptions und dateOptions eine Typwarnung angezeigt werden.
Da das Script bei Dir korrekt läuft, musst Du daran nichts ändern. Es handelt sich lediglich um eine Editor-Warnung und nicht um einen Laufzeitfehler.
Ich würde zunächst prüfen:
- JavaScript-Adapter aktuell?
- Node.js aktuell?
- Verschwindet die Warnung nach einem Adapter-Update?
@maxclaudi [sagte]: Die aktuelle Gerätekonfiguration wird also alle 5 Sekunden abgefragt.
Das habe ich beibehalten.
Was gelegentlich passiert: httpGet() liefert offenbar selbst einen Error-Log:
Kann man das nicht unterdrücken?
Gerät ist ein "SF 800 Pro 2", das ich gestern in Betrieb genommen habe. Internetzugang ist im Router gesperrt.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN 42 / N100 / 8 GB / 500 GB -
Hallo @maxclaudi ,
ich reiche nochmal die angekündigten Infos nach.
SF800Pro in der Fritte Internet gesperrt, Zendure App zwangsbeendet und via pihole zwei weitere Ziele gesperrt (mqtteu.zen-iot.com, app.zendure.tech).
Script läuft prinzipiell, wirft aber jede Menge Fehler aus (Auszug aus Log):
2026-06-16 17:53:48.644 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: httpGet(url=http://192.168.178.56/properties/report, error=timeout of 2500ms exceeded) 2026-06-16 17:53:48.644 - warn: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: GET Fehler (3): timeout of 2500ms exceeded 2026-06-16 17:53:49.196 - info: admin.0 (450218) ==> Connected system.user.admin from ::ffff:192.168.178.2 2026-06-16 17:53:49.351 - info: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: Verbindung wieder OK 2026-06-16 17:53:55.176 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: httpGet(url=http://192.168.178.56/properties/report, error=socket hang up) 2026-06-16 17:53:55.176 - warn: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: GET Fehler (1): socket hang up 2026-06-16 17:53:58.198 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: httpGet(url=http://192.168.178.56/properties/report, error=socket hang up) 2026-06-16 17:53:58.199 - warn: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: GET Fehler (2): socket hang up 2026-06-16 17:54:01.216 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: httpGet(url=http://192.168.178.56/properties/report, error=socket hang up) 2026-06-16 17:54:01.217 - warn: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: GET Fehler (3): socket hang up 2026-06-16 17:54:04.198 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: httpGet(url=http://192.168.178.56/properties/report, error=socket hang up) 2026-06-16 17:54:04.198 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: Keine Verbindung möglich. Zendure-Geräte IP prüfen! 2026-06-16 17:54:07.219 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: httpGet(url=http://192.168.178.56/properties/report, error=socket hang up) 2026-06-16 17:54:10.200 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: httpGet(url=http://192.168.178.56/properties/report, error=socket hang up) 2026-06-16 17:54:13.220 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: httpGet(url=http://192.168.178.56/properties/report, error=socket hang up) 2026-06-16 17:54:16.204 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: httpGet(url=http://192.168.178.56/properties/report, error=socket hang up) 2026-06-16 17:54:19.779 - error: javascript.0 (463079) script.js.common.Projekte.Zendure-HTTP: httpGet(url=http://192.168.178.56/properties/report, error=socket hang up)Die Freigabe der beiden Domains brachten keine Änderungen. Daran liegt es also nicht.
Da es sich nicht zwingend um sensible Daten handelt,werde ich den Internetzugang wieder freigeben und die App aktivieren.
Ob sich Handlungsbedarf ergibt kann ich nicht beurteilen. Insofern siehe das bitte nicht als Kritik am Script an, sondern lediglich als Rückmeldung.
-
@maxclaudi [sagte]: Die aktuelle Gerätekonfiguration wird also alle 5 Sekunden abgefragt.
Das habe ich beibehalten.
Was gelegentlich passiert: httpGet() liefert offenbar selbst einen Error-Log:Kann man das nicht unterdrücken?
Gerät ist ein "SF 800 Pro 2", das ich gestern in Betrieb genommen habe. Internetzugang ist im Router gesperrt.
@paul53 und @Rico-Sander
Das Problem liegt nicht am Script, sondern an der Firmware
Die Geräte unterstützen zwar die lokale Steuerung über zenSDK, aber die Firmware erwartet weiterhin regelmäßige Verbindungen zu Zendure-Cloud-Diensten (MQTT/HTTPS) zur Synchronisation und Geräteverwaltung.Verliert das Gerät die Cloud-Verbindung, dann versucht das Gerät immer häufiger sich mit der Cloud zu verbinden.
Das passiert so oft und häufig bis der Zendure-ESP intern überlastet ist und eine Steuerung gar nicht mehr möglich sein kann.Wird der Internetzugang komplett gesperrt, versucht das Gerät die Cloud-Verbindungen immer wieder neu aufzubauen.
Laut Aussage eines Zendure-Entwicklers erfolgt dies derzeit mit einem recht aggressiven Wiederholungsintervall.
Dadurch werden CPU- und Netzwerkressourcen des Geräts überlastet, was dann zu Timeouts, "socket hang up" und nicht erreichbaren lokalen Schnittstellen führt.
Bis am Ende keine Steuerung mehr möglich ist.Genau dieses Verhalten sieht man in euren Logs.
Deshalb würde ich den Internetzugang für das Gerät aktuell (noch) nicht dauerhaft sperren.
Die Steuerung erfolgt trotzdem lokal, die Cloud wird nur für die von der Firmware erwarteten Synchronisationsvorgänge genutzt.Zendure hat das Verhalten bereits im Februar 2026 bestätigt und angekündigt, an einer besseren Lösung für den Local-Only-Betrieb zu arbeiten.
Aber bisher wurde das leider - Stand heute - meines Wissens nach nicht umgesetzt.
Quelle Bestätigung des Zendure Entwicklers:
Local only use creates multiple external network requests leading to overload of SolarFlow 800 ProZendure Entwickler dav1dBoy sagte:
What you are observing is indeed related to the device’s current cloud interaction mechanism.
At the moment, the firmware still relies on periodic communication with Zendure cloud services (e.g. MQTT / HTTPS endpoints) for status synchronization, device management, and consistency checks. When outgoing traffic is blocked by a firewall, the connection attempts fail immediately and the device enters a retry loop with a relatively aggressive retry interval.You are absolutely correct that retrying at such a high frequency (e.g. multiple attempts per second) is not ideal behavior, especially in constrained embedded environments. In this blocked-network scenario, the repeated connection attempts can temporarily consume CPU time and network resources, which may affect the responsiveness of local interfaces such as the Home Assistant integration.
To be clear:
• This behavior is not intended to overload the device, and
• It does not indicate a fault in Home Assistant or your local setup.At the same time, we agree with your assessment:
a more robust retry strategy (e.g. exponential backoff, longer retry intervals, or adaptive retry timing when the network is unavailable) would be healthier and more resilient.Regarding your expectation of fully local operation:
we hear this feedback very clearly. We are actively working towards a more complete local-only runtime model, where core device control logic can operate independently of continuous cloud connectivity. This is an ongoing effort and requires careful changes across firmware architecture, but it is very much aligned with the direction we are moving in.For now, please note that current firmware versions still expect periodic interaction with Zendure servers, and completely blocking internet access may lead to degraded responsiveness as you observed.
We really appreciate you taking the time to analyze this so thoroughly and to report it constructively. Feedback like this directly influences how we prioritize robustness improvements and local-control capabilities.
Thank you for your patience — and thank you for pushing us to make the zenSDK better.
@paul53 sagte:
Was gelegentlich passiert: httpGet() liefert offenbar selbst einen Error-Log:Ja. Das ist aktuell bewusst so gewählt, damit Zustandsänderungen möglichst zeitnah erkannt werden.
Die HTTP-Abfrage selbst erzeugt normalerweise keine Probleme.
Die von euch gezeigten Fehler entstehen erst dann, wenn das Gerät durch die fehlende Cloud-Anbindung zeitweise nicht mehr sauber auf lokale HTTP-Anfragen reagiert.Ja, grundsätzlich schon.
Die Log-Ausgaben stammen nicht von der Zendure-Firmware, sondern vom Script und dienen lediglich dazu, Verbindungsprobleme sichtbar zu machen.
Wer die Ursache kennt und bewusst mit einem dauerhaft geblockten Internetzugang arbeitet, kann die entsprechenden log()-Ausgaben natürlich auskommentieren oder auf ein anderes Log-Level ändern.
An Alle:
Das beseitigt allerdings nur die Meldungen im Log.
Die eigentliche Ursache – die aggressiven Cloud-Reconnect-Versuche der Firmware – bleibt unverändert bestehen.Allgemein würde ich noch den rssi Wert überprüfen.
Wenn die WLAN-Verbindung zum Gerät nicht gut genug ist, kommt es eher bzw. häufiger zu timeouts.
Sollte rssi gut genug sein (z. B. <= -60) und es dennoch zu GET - Fehler und Timeouts kommen, liegt es mit hoher Wahrscheinlicheit an dem gesperrten Internet. -
Moin,
danke für die ausführliche Info. Das erklärt dann das beobachtete Verhalten. Vielleicht kannst Du diesen Hinweis, die aktuelle Besonderheit, in Deiner ansonsten sehr guten Dokumentation zum Script unterbringen. Mir war lange Zeit nicht klar, was das script eigentlich tut. Erst durch Deine irgendwann nachgereichten Details habe ich das dann endlich verstanden.
Danke.
-
@paul53 und @Rico-Sander
Das Problem liegt nicht am Script, sondern an der Firmware
Die Geräte unterstützen zwar die lokale Steuerung über zenSDK, aber die Firmware erwartet weiterhin regelmäßige Verbindungen zu Zendure-Cloud-Diensten (MQTT/HTTPS) zur Synchronisation und Geräteverwaltung.Verliert das Gerät die Cloud-Verbindung, dann versucht das Gerät immer häufiger sich mit der Cloud zu verbinden.
Das passiert so oft und häufig bis der Zendure-ESP intern überlastet ist und eine Steuerung gar nicht mehr möglich sein kann.Wird der Internetzugang komplett gesperrt, versucht das Gerät die Cloud-Verbindungen immer wieder neu aufzubauen.
Laut Aussage eines Zendure-Entwicklers erfolgt dies derzeit mit einem recht aggressiven Wiederholungsintervall.
Dadurch werden CPU- und Netzwerkressourcen des Geräts überlastet, was dann zu Timeouts, "socket hang up" und nicht erreichbaren lokalen Schnittstellen führt.
Bis am Ende keine Steuerung mehr möglich ist.Genau dieses Verhalten sieht man in euren Logs.
Deshalb würde ich den Internetzugang für das Gerät aktuell (noch) nicht dauerhaft sperren.
Die Steuerung erfolgt trotzdem lokal, die Cloud wird nur für die von der Firmware erwarteten Synchronisationsvorgänge genutzt.Zendure hat das Verhalten bereits im Februar 2026 bestätigt und angekündigt, an einer besseren Lösung für den Local-Only-Betrieb zu arbeiten.
Aber bisher wurde das leider - Stand heute - meines Wissens nach nicht umgesetzt.
Quelle Bestätigung des Zendure Entwicklers:
Local only use creates multiple external network requests leading to overload of SolarFlow 800 ProZendure Entwickler dav1dBoy sagte:
What you are observing is indeed related to the device’s current cloud interaction mechanism.
At the moment, the firmware still relies on periodic communication with Zendure cloud services (e.g. MQTT / HTTPS endpoints) for status synchronization, device management, and consistency checks. When outgoing traffic is blocked by a firewall, the connection attempts fail immediately and the device enters a retry loop with a relatively aggressive retry interval.You are absolutely correct that retrying at such a high frequency (e.g. multiple attempts per second) is not ideal behavior, especially in constrained embedded environments. In this blocked-network scenario, the repeated connection attempts can temporarily consume CPU time and network resources, which may affect the responsiveness of local interfaces such as the Home Assistant integration.
To be clear:
• This behavior is not intended to overload the device, and
• It does not indicate a fault in Home Assistant or your local setup.At the same time, we agree with your assessment:
a more robust retry strategy (e.g. exponential backoff, longer retry intervals, or adaptive retry timing when the network is unavailable) would be healthier and more resilient.Regarding your expectation of fully local operation:
we hear this feedback very clearly. We are actively working towards a more complete local-only runtime model, where core device control logic can operate independently of continuous cloud connectivity. This is an ongoing effort and requires careful changes across firmware architecture, but it is very much aligned with the direction we are moving in.For now, please note that current firmware versions still expect periodic interaction with Zendure servers, and completely blocking internet access may lead to degraded responsiveness as you observed.
We really appreciate you taking the time to analyze this so thoroughly and to report it constructively. Feedback like this directly influences how we prioritize robustness improvements and local-control capabilities.
Thank you for your patience — and thank you for pushing us to make the zenSDK better.
@paul53 sagte:
Was gelegentlich passiert: httpGet() liefert offenbar selbst einen Error-Log:Ja. Das ist aktuell bewusst so gewählt, damit Zustandsänderungen möglichst zeitnah erkannt werden.
Die HTTP-Abfrage selbst erzeugt normalerweise keine Probleme.
Die von euch gezeigten Fehler entstehen erst dann, wenn das Gerät durch die fehlende Cloud-Anbindung zeitweise nicht mehr sauber auf lokale HTTP-Anfragen reagiert.Ja, grundsätzlich schon.
Die Log-Ausgaben stammen nicht von der Zendure-Firmware, sondern vom Script und dienen lediglich dazu, Verbindungsprobleme sichtbar zu machen.
Wer die Ursache kennt und bewusst mit einem dauerhaft geblockten Internetzugang arbeitet, kann die entsprechenden log()-Ausgaben natürlich auskommentieren oder auf ein anderes Log-Level ändern.
An Alle:
Das beseitigt allerdings nur die Meldungen im Log.
Die eigentliche Ursache – die aggressiven Cloud-Reconnect-Versuche der Firmware – bleibt unverändert bestehen.Allgemein würde ich noch den rssi Wert überprüfen.
Wenn die WLAN-Verbindung zum Gerät nicht gut genug ist, kommt es eher bzw. häufiger zu timeouts.
Sollte rssi gut genug sein (z. B. <= -60) und es dennoch zu GET - Fehler und Timeouts kommen, liegt es mit hoher Wahrscheinlicheit an dem gesperrten Internet.@maxclaudi [sagte]: Fehler entstehen erst dann, wenn das Gerät durch die fehlende Cloud-Anbindung zeitweise nicht mehr sauber auf lokale HTTP-Anfragen reagiert.
Danke für die ausführliche Information. Ich habe die Verbindung zum Internet wieder freigegeben.
Die Log-Ausgaben stammen nicht von der Zendure-Firmware, sondern vom Script
Den Error-Log erzeugt die Funktion httpGet() des Javascript-Adapters. Ich werde es mal mit axios() versuchen.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN 42 / N100 / 8 GB / 500 GB -
@maxclaudi [sagte]: Fehler entstehen erst dann, wenn das Gerät durch die fehlende Cloud-Anbindung zeitweise nicht mehr sauber auf lokale HTTP-Anfragen reagiert.
Danke für die ausführliche Information. Ich habe die Verbindung zum Internet wieder freigegeben.
Die Log-Ausgaben stammen nicht von der Zendure-Firmware, sondern vom Script
Den Error-Log erzeugt die Funktion httpGet() des Javascript-Adapters. Ich werde es mal mit axios() versuchen.
@paul53
Ein Blick auf die Zeitstempel in deinem Log zeigt sehr deutlich, warum man diese Meldungen auf keinen Fall unterdrücken, sondern ernst nehmen sollte:Um 15:14:37 Uhr läuft der lokale HTTP-Request in einen harten Timeout von 3000 ms.
Skript fragt an, aber der interne Webserver des Zendure-Geräts hat innerhalb von 3 Sekunden überhaupt nicht reagiert.Erst um 17:58:45 Uhr – also fast drei Stunden später – antwortet das Gerät wieder (Verbindung wieder OK).
Das Unterdrücken dieser Meldungen im Skript würde das Problem nicht lösen, sondern nur die Symptome verschleiern.
Das Log beweist eigentlich, dass das Gerät bei gesperrtem Internetzugang entweder den lokalen HTTP-Dienst nach einer Weile komplett schließt oder die interne CPU des Geräts (vielleicht durch permanente, fehlschlagende Cloud-Kopplungsversuche) so überlastet ist, dass sie keine lokalen Anfragen mehr verarbeiten kann.Das Skript macht hier genau das, was es soll:
Es registriert den Ausfall der Hardware, warnt Dich und baut die Verbindung vollautomatisch wieder auf, sobald das Gerät nach Stunden wieder reagiert.Das Problem liegt hier eindeutig in der Firmware-Architektur des Zendure-Geräts bei reinem Offline-Betrieb.
Die Log-Ausgaben stammen nicht von der Zendure-Firmware, sondern vom Script
Den Error-Log erzeugt die Funktion httpGet() des Javascript-Adapters. Ich werde es mal mit axios() versuchen.
Zu deiner Idee mit axios():
Ein Wechsel der HTTP-Funktion wird die Fehlermeldungen bei einer blockierten Firmware leider nicht verhindern können.Die Meldung timeout of 3000ms exceeded stammt vom JavaScript-Adapter selbst, weil die genutzte Netzwerk-Bibliothek nach Ablauf der 3 Sekunden keine Antwort vom Zendure-Webserver erhalten hat.
Egal ob man httpGet() oder axios() verwendet – wenn die CPU des Geräts blockiert oder der interne Webserver offline geht, laufen beide Funktionen unweigerlich in einen Timeout und werfen einen Fehler aus.
Das Skript muss diesen Verbindungsabbruch registrieren, um im Protokoll den Status sauber zu dokumentieren.
Solange es jetzt mit Internetverbindung wieder fehlerfrei durchläuft, passt ja alles.
-
@paul53
Ein Blick auf die Zeitstempel in deinem Log zeigt sehr deutlich, warum man diese Meldungen auf keinen Fall unterdrücken, sondern ernst nehmen sollte:Um 15:14:37 Uhr läuft der lokale HTTP-Request in einen harten Timeout von 3000 ms.
Skript fragt an, aber der interne Webserver des Zendure-Geräts hat innerhalb von 3 Sekunden überhaupt nicht reagiert.Erst um 17:58:45 Uhr – also fast drei Stunden später – antwortet das Gerät wieder (Verbindung wieder OK).
Das Unterdrücken dieser Meldungen im Skript würde das Problem nicht lösen, sondern nur die Symptome verschleiern.
Das Log beweist eigentlich, dass das Gerät bei gesperrtem Internetzugang entweder den lokalen HTTP-Dienst nach einer Weile komplett schließt oder die interne CPU des Geräts (vielleicht durch permanente, fehlschlagende Cloud-Kopplungsversuche) so überlastet ist, dass sie keine lokalen Anfragen mehr verarbeiten kann.Das Skript macht hier genau das, was es soll:
Es registriert den Ausfall der Hardware, warnt Dich und baut die Verbindung vollautomatisch wieder auf, sobald das Gerät nach Stunden wieder reagiert.Das Problem liegt hier eindeutig in der Firmware-Architektur des Zendure-Geräts bei reinem Offline-Betrieb.
Die Log-Ausgaben stammen nicht von der Zendure-Firmware, sondern vom Script
Den Error-Log erzeugt die Funktion httpGet() des Javascript-Adapters. Ich werde es mal mit axios() versuchen.
Zu deiner Idee mit axios():
Ein Wechsel der HTTP-Funktion wird die Fehlermeldungen bei einer blockierten Firmware leider nicht verhindern können.Die Meldung timeout of 3000ms exceeded stammt vom JavaScript-Adapter selbst, weil die genutzte Netzwerk-Bibliothek nach Ablauf der 3 Sekunden keine Antwort vom Zendure-Webserver erhalten hat.
Egal ob man httpGet() oder axios() verwendet – wenn die CPU des Geräts blockiert oder der interne Webserver offline geht, laufen beide Funktionen unweigerlich in einen Timeout und werfen einen Fehler aus.
Das Skript muss diesen Verbindungsabbruch registrieren, um im Protokoll den Status sauber zu dokumentieren.
Solange es jetzt mit Internetverbindung wieder fehlerfrei durchläuft, passt ja alles.
@maxclaudi [sagte]: Um 15:14:37 Uhr läuft der lokale HTTP-Request in einen harten Timeout von 3000 ms.
... Erst um 17:58:45 Uhr – also fast drei Stunden später – antwortet das Gerät wieder (Verbindung wieder OK).Nein, um 15:14:40 Uhr, also 2 Sekunden später (beim nächsten Intervall-Zyklus) hat das Gerät mit "Verbindung wieder OK" geantwortet.
Um 17:58:46 Uhr kam die Antwort 2 s nach dem zweiten Error-Log um 17:58:44 Uhr.Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN 42 / N100 / 8 GB / 500 GB -
@maxclaudi [sagte]: Um 15:14:37 Uhr läuft der lokale HTTP-Request in einen harten Timeout von 3000 ms.
... Erst um 17:58:45 Uhr – also fast drei Stunden später – antwortet das Gerät wieder (Verbindung wieder OK).Nein, um 15:14:40 Uhr, also 2 Sekunden später (beim nächsten Intervall-Zyklus) hat das Gerät mit "Verbindung wieder OK" geantwortet.
Um 17:58:46 Uhr kam die Antwort 2 s nach dem zweiten Error-Log um 17:58:44 Uhr.@paul53
danke fürs genaue Nachrechnen, du hast natürlich absolut recht.Da waren die Tomaten auf meinen Augen wohl im harten Timeout.
Am technischen Kern ändert das nichts:
Das Gerät verschluckt sich bei gesperrtem Internetzugang zyklisch so massiv, dass es unregelmäßig in diese harten 3-Sekunden-Timeouts läuft, weil die interne CPU kurzzeitig komplett blockiert.Mit axios() wirst du diese Timeouts leider auch nicht verhindern können, da der Fehler abgefangen werden muss, wenn die Hardware nicht antwortet.
Aber wenn es mit freigegebener Cloud stabil läuft, ist das Wichtigste ja erreicht.
-
@maxclaudi [sagte]: Die aktuelle Gerätekonfiguration wird also alle 5 Sekunden abgefragt.
Das habe ich beibehalten.
Was gelegentlich passiert: httpGet() liefert offenbar selbst einen Error-Log:Kann man das nicht unterdrücken?
Gerät ist ein "SF 800 Pro 2", das ich gestern in Betrieb genommen habe. Internetzugang ist im Router gesperrt.
@maxclaudi [sagte]: Die aktuelle Gerätekonfiguration wird also alle 5 Sekunden abgefragt.
Das habe ich beibehalten.
Was gelegentlich passiert: httpGet() liefert offenbar selbst einen Error-Log:Was mir gerade beim Blick auf die Sekunden im Log noch aufgefallen ist:
Dort wird eine Zeitüberschreitung von 3000 ms gemeldet (timeout of 3000ms exceeded).
Im Standard-Skript hatte ich das Timeout eigentlich auf 1500 ms vordefiniert.Falls du den Wert für das Timeout bei dir manuell erhöht hast, ist das laut der Beschreibung bei einem 5000-ms-Intervall rein mathematisch natürlich vollkommen im Rahmen (3000 < 5000).
Man sollte allerdings im Hinterkopf behalten, dass 5000ms Interval im Fall von Timeouts dann zeitlich sehr knapp wird. -
@paul53
danke fürs genaue Nachrechnen, du hast natürlich absolut recht.Da waren die Tomaten auf meinen Augen wohl im harten Timeout.
Am technischen Kern ändert das nichts:
Das Gerät verschluckt sich bei gesperrtem Internetzugang zyklisch so massiv, dass es unregelmäßig in diese harten 3-Sekunden-Timeouts läuft, weil die interne CPU kurzzeitig komplett blockiert.Mit axios() wirst du diese Timeouts leider auch nicht verhindern können, da der Fehler abgefangen werden muss, wenn die Hardware nicht antwortet.
Aber wenn es mit freigegebener Cloud stabil läuft, ist das Wichtigste ja erreicht.
@maxclaudi
Kannst du etwas zu dieser Beobachtung sagen, da du schon länger Erfahrung mit den Zendure Solarflow gemacht hast?Bis zum "socSet" (85 %) wird mit 800 W aus dem Netz geladen. Danach erhöht sich "electricLevel" alle 2 Stunden um 1 %, was zu der Angabe von "Battery pack power" = 9 W passt.
Werte unter "properties" sind dann allerdings gelogen:- "gridInputPower" = "gridOffPower" um 17 W (Mini-PC: 6 W + Router)
- "outputPackPower": 0 W
Gibt es eine Minimalleistungsaufnahme am Notstrom-Ausgang, damit nicht über den "socSet" hinaus geladen wird?
Als ich zu Beginn mal eine 75 W Glühlampe angeschlossen hatte, blieb der SOC auf 85 % konstant.EDIT: Übrigens habe ich noch folgende Werte unter "properties", die nicht der Beschreibung entsprechen:
- "pass": 3
- "socLimit": 17
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN 42 / N100 / 8 GB / 500 GB -
@maxclaudi
Kannst du etwas zu dieser Beobachtung sagen, da du schon länger Erfahrung mit den Zendure Solarflow gemacht hast?Bis zum "socSet" (85 %) wird mit 800 W aus dem Netz geladen. Danach erhöht sich "electricLevel" alle 2 Stunden um 1 %, was zu der Angabe von "Battery pack power" = 9 W passt.
Werte unter "properties" sind dann allerdings gelogen:- "gridInputPower" = "gridOffPower" um 17 W (Mini-PC: 6 W + Router)
- "outputPackPower": 0 W
Gibt es eine Minimalleistungsaufnahme am Notstrom-Ausgang, damit nicht über den "socSet" hinaus geladen wird?
Als ich zu Beginn mal eine 75 W Glühlampe angeschlossen hatte, blieb der SOC auf 85 % konstant.EDIT: Übrigens habe ich noch folgende Werte unter "properties", die nicht der Beschreibung entsprechen:
- "pass": 3
- "socLimit": 17
@maxclaudi
Kannst du etwas zu dieser Beobachtung sagen, da du schon länger Erfahrung mit den Zendure Solarflow gemacht hast?Bis zum "socSet" (85 %) wird mit 800 W aus dem Netz geladen. Danach erhöht sich "electricLevel" alle 2 Stunden um 1 %, was zu der Angabe von "Battery pack power" = 9 W passt.
Werte unter "properties" sind dann allerdings gelogen:- "gridInputPower" = "gridOffPower" um 17 W (Mini-PC: 6 W + Router)
- "outputPackPower": 0 W
Gibt es eine Minimalleistungsaufnahme am Notstrom-Ausgang, damit nicht über den "socSet" hinaus geladen wird?
Als ich zu Beginn mal eine 75 W Glühlampe angeschlossen hatte, blieb der SOC auf 85 % konstant.gut beobachtet.
Das lässt sich elektrotechnisch und physikalisch gut erklären.
Die Werte sind nicht direkt „gelogen“, sondern unterliegen den typischen Grenzen der Sensoren bei Kleinstleistungen.Hier spielen mehrere Effekte zusammen, z. B.:
Sensor-Toleranz im Mikrobereich:
Die internen Stromsensoren (Shunts) des Geräts sind für hohe Ströme (z. B. beim Laden mit 800 W) optimiert.
Wenn das Gerät bei Erreichen des socSet (85 %) das Hauptladen beendet, schaltet es in den Standby-/Erhaltungsmodus.
Die dabei fließenden Ströme sind so minimal, dass die Software auf 0 W abgerundet wird, obwohl im Hintergrund minimale Erhaltungsimpulse fließen.Eigenverbrauch vs. Last am Notstrom-Ausgang:
Dein Mini-PC und der Router ziehen zusammen ca. 17 W.
Das ist extrem wenig.
Wenn das Gerät im Standby läuft, reicht diese geringe Last am Notstrom Ausgang (gridOffPower) bestimmt nicht aus, um die minimale Erhaltungsenergie, die das System intern regelt, vollständig zu verbrauchen,
Ein Teil sickert weiterhin in die Zellen, weshalb der SOC alle 2 Stunden um 1 % nach oben kriecht.Bei 75 W Last war der Verbrauch am Ausgang hoch genug, um die gesamte bereitgestellte Erhaltungsenergie sofort abzunehmen.
Der Akku musste nichts mehr aufnehmen und blieb stabil auf den konfigurierten 85 % stehen.Das ist m. M. n. kein Zendure-eigenes Problem sondern allgemein elektrotechnisch kaum anders möglich.
Abhängig von der Güte der Sensoren, BMS, den jeweiligen Messbereichen usw.
Vermutlich gibt es keine feste „Mindestleistungsaufnahme“, sondern es ist ein reines Balance-Spiel zwischen der minimalen Erhaltungsleistung des BMS und der angeschlossenen Grundlast im Standby.
Wie das genau von Zendure gelöst ist kann ich nicht beurteilen.
Die beobachteten Werte und Wertfindung sind dabei elektrotechnisch jedoch völlig plausibel.EDIT: Übrigens habe ich noch folgende Werte unter "properties", die nicht der Beschreibung entsprechen:
- "pass": 3
- "socLimit": 17
Das ist für mich neu.
Bei mir stimmen die Werte und die Beschreibung (noch).Hast Du die Firmware aktualisiert?
Wenn ja, hat Zendure im Hintergrund vermutlich etwas an den API-Objekten geändert oder es ist ein neuer Bug.
Das ist für mich im Moment auch ein Novum, über das ich aktuell noch keine näheren Informationen habe. -
@maxclaudi
Kannst du etwas zu dieser Beobachtung sagen, da du schon länger Erfahrung mit den Zendure Solarflow gemacht hast?Bis zum "socSet" (85 %) wird mit 800 W aus dem Netz geladen. Danach erhöht sich "electricLevel" alle 2 Stunden um 1 %, was zu der Angabe von "Battery pack power" = 9 W passt.
Werte unter "properties" sind dann allerdings gelogen:- "gridInputPower" = "gridOffPower" um 17 W (Mini-PC: 6 W + Router)
- "outputPackPower": 0 W
Gibt es eine Minimalleistungsaufnahme am Notstrom-Ausgang, damit nicht über den "socSet" hinaus geladen wird?
Als ich zu Beginn mal eine 75 W Glühlampe angeschlossen hatte, blieb der SOC auf 85 % konstant.gut beobachtet.
Das lässt sich elektrotechnisch und physikalisch gut erklären.
Die Werte sind nicht direkt „gelogen“, sondern unterliegen den typischen Grenzen der Sensoren bei Kleinstleistungen.Hier spielen mehrere Effekte zusammen, z. B.:
Sensor-Toleranz im Mikrobereich:
Die internen Stromsensoren (Shunts) des Geräts sind für hohe Ströme (z. B. beim Laden mit 800 W) optimiert.
Wenn das Gerät bei Erreichen des socSet (85 %) das Hauptladen beendet, schaltet es in den Standby-/Erhaltungsmodus.
Die dabei fließenden Ströme sind so minimal, dass die Software auf 0 W abgerundet wird, obwohl im Hintergrund minimale Erhaltungsimpulse fließen.Eigenverbrauch vs. Last am Notstrom-Ausgang:
Dein Mini-PC und der Router ziehen zusammen ca. 17 W.
Das ist extrem wenig.
Wenn das Gerät im Standby läuft, reicht diese geringe Last am Notstrom Ausgang (gridOffPower) bestimmt nicht aus, um die minimale Erhaltungsenergie, die das System intern regelt, vollständig zu verbrauchen,
Ein Teil sickert weiterhin in die Zellen, weshalb der SOC alle 2 Stunden um 1 % nach oben kriecht.Bei 75 W Last war der Verbrauch am Ausgang hoch genug, um die gesamte bereitgestellte Erhaltungsenergie sofort abzunehmen.
Der Akku musste nichts mehr aufnehmen und blieb stabil auf den konfigurierten 85 % stehen.Das ist m. M. n. kein Zendure-eigenes Problem sondern allgemein elektrotechnisch kaum anders möglich.
Abhängig von der Güte der Sensoren, BMS, den jeweiligen Messbereichen usw.
Vermutlich gibt es keine feste „Mindestleistungsaufnahme“, sondern es ist ein reines Balance-Spiel zwischen der minimalen Erhaltungsleistung des BMS und der angeschlossenen Grundlast im Standby.
Wie das genau von Zendure gelöst ist kann ich nicht beurteilen.
Die beobachteten Werte und Wertfindung sind dabei elektrotechnisch jedoch völlig plausibel.EDIT: Übrigens habe ich noch folgende Werte unter "properties", die nicht der Beschreibung entsprechen:
- "pass": 3
- "socLimit": 17
Das ist für mich neu.
Bei mir stimmen die Werte und die Beschreibung (noch).Hast Du die Firmware aktualisiert?
Wenn ja, hat Zendure im Hintergrund vermutlich etwas an den API-Objekten geändert oder es ist ein neuer Bug.
Das ist für mich im Moment auch ein Novum, über das ich aktuell noch keine näheren Informationen habe.@maxclaudi [sagte]: Hast Du die Firmware aktualisiert?
Ja, bei Einrichtung in der App (HEMS 2.0).
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN 42 / N100 / 8 GB / 500 GB -
@maxclaudi [sagte]: Die aktuelle Gerätekonfiguration wird also alle 5 Sekunden abgefragt.
Das habe ich beibehalten.
Was gelegentlich passiert: httpGet() liefert offenbar selbst einen Error-Log:Was mir gerade beim Blick auf die Sekunden im Log noch aufgefallen ist:
Dort wird eine Zeitüberschreitung von 3000 ms gemeldet (timeout of 3000ms exceeded).
Im Standard-Skript hatte ich das Timeout eigentlich auf 1500 ms vordefiniert.Falls du den Wert für das Timeout bei dir manuell erhöht hast, ist das laut der Beschreibung bei einem 5000-ms-Intervall rein mathematisch natürlich vollkommen im Rahmen (3000 < 5000).
Man sollte allerdings im Hinterkopf behalten, dass 5000ms Interval im Fall von Timeouts dann zeitlich sehr knapp wird.@maxclaudi [sagte]: Falls du den Wert für das Timeout bei dir manuell erhöht hast, ist das laut der Beschreibung bei einem 5000-ms-Intervall rein mathematisch natürlich vollkommen im Rahmen (3000 < 5000).
Ja, ich hatten Timeout zwischendurch auf 3000 ms erhöht, jetzt aber wieder auf 2000 ms zurück gestellt. Dass Timeout kleiner sein muss als das Intervall, ist mir bewusst.
Mit axios() wirst du diese Timeouts leider auch nicht verhindern können
... aber vielleicht den Error-Log beim einmaligen Timeout-Error, denn den erzeugt httpGet(): Javascript-Adapter, Datei sandbox.ts, Zeile 1516.
Du hast im Skript vorgesehen, dass erst beim 4. Error-Zyklus in Folge ein Error-Log erzeugt wirdBitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN 42 / N100 / 8 GB / 500 GB
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
611
Online32.9k
Benutzer83.2k
Themen1.3m
Beiträge