Neues YouTube-Video: Visualisierung im Devices-Adapter

[maxclaudi]

@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]

@paul53 sagte:

@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]

@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]

@paul53 sagte:

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

[paul53]

@maxclaudi [sagte]: Hast Du die Firmware aktualisiert?

Ja, bei Einrichtung in der App (HEMS 2.0).

[paul53]

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

@maxclaudi sagte:

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 wird

[maxclaudi]

@paul53
socLimit: 17 wird wahrscheinlich kein Bug, sondern ein neues Bitmuster sein.
(z. B. 16 + 1 )
Aber das ist aktuell Spekulation.
Die offizielle zenSDK-Doku von Zendure ist leider nicht auf dem neuesten Stand.
Mit Updates warte ich immer.

[maxclaudi]

@paul53 sagte:

@maxclaudi sagte:

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 wird

@paul53 Hut ab, Volltreffer! :-)
Danke für den tiefen Blick in die sandbox.ts
Jetzt wird absolut klar, warum der JavaScript-Adapter das bei httpGet() sofort so knallrot ins Log brennt .

Da hast du natürlich recht:
Bei axios() könnte man das über ein .catch() abfangen, um das Log sauber zu halten.
Ich hatte mich beim Schreiben des Skripts damals bewusst für httpGet() entschieden, um es so schlank und kompatibel wie möglich zu halten (KISS-Prinzip), da es als native Core-Funktion ohne zusätzliche Abhängigkeiten auf jedem ioBroker sofort läuft.

[paul53]

@maxclaudi [sagte]: da es als native Core-Funktion ohne zusätzliche Abhängigkeiten auf jedem ioBroker sofort läuft.

Axios ist ebenfalls im Javascript-Adapter per require('axios') verfügbar. Aus der Doku:

The following modules are preloaded: node:dgram, node:crypto, node:dns, node:events, node:fs, node:http, node:https, node:http2, node:net, node:os, node:path, node:util, node:stream, node:zlib, suncalc2, axios, wake_on_lan, request (deprecated)

[Rico Sander]

@paul53 sagte:

Ja, bei Einrichtung in der App (HEMS 2.0).

Du hast also auf HEMS 2.0 geupdated? Was ist mit der neuen Firmware Solarflow 800 Pro V1.0.25? Bist Du da auch mitgegangen?

Gabs irgendwelche Probleme?

Im Zusammmenspiel mit dem script von @maxclaudi dütfte ja eigentlich nur die Firmware relevant sein. HEMS ist ja bei individueller Steuerung abgeschaltet, oder übersehe ich da etwas?

[paul53]

@Rico-Sander [sagte]: Was ist mit der neuen Firmware Solarflow 800 Pro V1.0.25?

Wo finde ich die Firmware-Version?
Eine Software-Version V1.1.2 finde ich nur unter "packData".

@Rico-Sander sagte:

HEMS ist ja bei individueller Steuerung abgeschaltet, oder übersehe ich da etwas?

Ja, ist abgeschaltet.

[maxclaudi]

@paul53 sagte:
Wo finde ich die Firmware-Version?
Eine Software-Version V1.1.2 finde ich nur unter "packData".

wird im JSON nicht übertragen.
Es gibt zwar 'version', aber damit ist wahrscheinlich was anderes gemeint (zenSDK-Version?). Als Wert wird dort nur 2 oder 3 übertragen.

@paul53 sagte:
Axios ist ebenfalls im Javascript-Adapter per require('axios') verfügbar.

Danke für den Hinweis zur Doku, das hatte ich tatsächlich nicht auf dem Schirm.
Gut zu wissen, dass axios (mittlerweile?) zum Standard-Inventar des Adapters gehört.
Ich lese ehrlich gesagt auch nicht die Doku und nutze am liebsten einfaches, pragmatisches JavaScript.
Komme normal aus einer anderen Ecke – zu JS hat mich erst ioBroker gezwungenermaßen gebracht.

Wie dem auch sei: Ich bin froh, dass das Skript in der Praxis genau das tut, was es soll.
Als "kleines Lichtlein" im Vergleich zu eurer geballten Entwickler-Erfahrung in JS (Du, mcm1957 u. a.) bin ich schon glücklich, dass das Script ok ist.

Falls Du (oder jemand anderes) Lust hast, den Code auf axios umzubauen, zu optimieren oder ( auch z.B. @Rico-Sander ) die Dokumentation zu erweitern – fühlt euch herzlich eingeladen!

[paul53]

@maxclaudi [sagte]: zu JS hat mich erst ioBroker gezwungenermaßen gebracht.

Mich auch.

@maxclaudi sagte:

eurer geballten Entwickler-Erfahrung in JS

Bin kein Entwickler für ioBroker, sondern programmiere nur Anwendungen unter ioBroker in JS (für das Forum auch Blockly). Die Entwickler programmieren mittlerweile in Typescript, womit ich mich nicht auch noch beschäftigen will.

[Rico Sander]

@paul53 sagte:

@Rico-Sander [sagte]: Was ist mit der neuen Firmware Solarflow 800 Pro V1.0.25?

Wo finde ich die Firmware-Version?
Eine Software-Version V1.1.2 finde ich nur unter "packData".

In der App:

[Rico Sander]

@maxclaudi sagte:

Falls Du (oder jemand anderes) Lust hast, den Code auf axios umzubauen, zu optimieren oder ( auch z.B. @Rico-Sander ) die Dokumentation zu erweitern – fühlt euch herzlich eingeladen!

Ich komme aus der Ecke perl und php. Zu JS wurde ich erst durch ioB, richtig aber erst durch die Scripte für Zendure "gezwungen"
Ich entdecke zwar täglich in JS, dass ich vieles aus meiner frühen Zeit noch anwenden kann, aber zu mehr reicht es leider nicht.

Was die Hilfe zur Dokumentation angeht:
Mit @apollon77 hatte ich angefangen, die Doku zu ioB zu aktualisieren/verbessern, was aber wohl nur (hoffe ich) aus Zeitgründen im Sande verlaufen ist.
Die Doku zu Deinem Script ist doch schon ok.

Vorschlag:
Unter den Absatz:

Es funktioniert sofort und wahlweise komplett lokal oder parallel zu Cloud und App (bei deaktiviertem HEMS).
Außer der IP-Adresse des Zendure-Geräts sind keine weiteren Keys oder Authentifizierungen notwendig.

Folgende Ergänzung:

Hinweis: Aus technischen Gründen sollte sowohl dem Gerät (den Geräten?) als auch der App weiterhin der Zugang ins Internet möglich sein.

Diese Ergänzung in der Doku reicht m.E aus. Eine tiefere Begründung und techn. Hintergründe sind an der Stelle aus meiner Sicht nicht nötig.
Es sei denn, die Dokum sollte mehr als nur eine Vorstellung des Scriptes und eine Kurzanleitung sein.

[paul53]

@Rico-Sander [sagte]: In der App:

Unter Firmware-Update steht nur "Die Firmware Ihres Gerätes ist auf dem neuesten Stand".

[maxclaudi]

@Rico-Sander sagte:

Vorschlag:

Folgende Ergänzung:

Hinweis: Aus technischen Gründen sollte sowohl dem Gerät (den Geräten?) als auch der App weiterhin der Zugang ins Internet möglich sein.

Danke. Wurde in die Anleitung aufgenommen.
Allerdings liest es sich für mich jetzt so, als würde die Cloud dazwischen funken.
Die Steuerung ist ausschließlich lokal und funktioniert auch nur wenn HEMS ausgeschaltet ist.
Die meisten werden es wissen und sonst fragen :-)
Jetzt mal abwarten was HEMS 2 alles neu oder durcheinander bringen wird.
Update mache ich (noch) nicht.

[Rico Sander]

@maxclaudi sagte:

Allerdings liest es sich für mich jetzt so, als würde die Cloud dazwischen funken.
Die Steuerung ist ausschließlich lokal und funktioniert auch nur wenn HEMS ausgeschaltet ist.
Die meisten werden es wissen und sonst fragen :-)

Nunja, Du kannst ja meinen Vorschlag noch individualisieren. So, dass er in den Lesefluss passt und ggfl. Irritationen vermeidet. Ich meine, zumindest die lokale Funktion hattest Du ja schon beschrieben., Der Hinweis zu HEMS ist sicher richtig und sinnvoll.

Alles wird gut

[maxclaudi]

Punkt 3 beachten:

[maxclaudi]

@paul53
bisher ohne Update steht bei mir im Datenpunkt version:2

Vermutlich steht bei Dir dort nun 3?