Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2
-
Guten Morgen @paul53,
mir ging es hier primär um die technische Aufklärung zu dem Beitrag
@nograx sagte:
....Ich bin von Zendure angehalten worden mit dem Adapter bei den neuen Geräten die offiziell unterstützten Möglichkeiten zu nutzen. Und daran werde ich mich auch halten.Die offiziell unterstützten Möglichkeiten von Zendure beinhalten im zenSDK-Protokoll weder ein Cloud-Relay noch die unvollständige Manipulation von Modi wie HEMS über intransparente Funktionen.
Das halte ich technisch für riskanter – vor allem, wenn durch unvollständige Code-Basteleien Geräte-Befehle, Invoke-Methoden oder Modi verwendet werden, deren exakte Systemmatrix und Syntax gar nicht vollumfänglich bekannt sind.Zendure-Geräte sind zum Teil explizit für den Outdoor-, Camping- und Gartenhaus-Bereich konzipiert – Umgebungen, die oft weder über 230V Netzstrom noch über eine permanente Internetverbindung verfügen.
Zu Deiner Frage
@maxclaudi [sagte:
Es wird lediglich über den vorhandenen BLE-Konfigurationsmechanismus die MQTT-Serveradresse geändert, die das Gerät für seine Kommunikation verwendet.Damit bist du von der Überschrift "zenSDK local API" mittlerweile entfernt. Oder ist die Aktivierung der lokalen MQTT-Kommunikation Bestandteil des zenSDK?
Um das präzise zu beantworten:
Ja, die Aktivierung der lokalen MQTT-Kommunikation ist integraler Bestandteil des offiziellen zenSDK.Zendure dokumentiert genau diese RPC-Methoden zur lokalen Konfiguration transparent in den offiziellen Repositories Zendure/zenSDK.
Die Aktivierung erfolgt über exakt definierte API-Aufrufe wie:
POST /rpc Content-Type: application/json { "sn": "WOB1NHMAMXXXXX3", "method": "HA.Mqtt.SetConfig", "params": { "config": { "enable": true, "server": "192.168.50.48", "port":1883, "protocol":"mqtt", "username": "zendure", "password": "zendure" } } }sowie die MQTT status Abfrage:
GET /rpc?method=HA.Mqtt.GetStatusoder Get MQTT configuration
GET /rpc?method=HA.Mqtt.GetConfigAllerdings ist dieser von Zendure bereitgestellte lokale MQTT-Weg stark reglementiert und in der Übertragungsgeschwindigkeit gedrosselt.
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern.
Um mit diesen Versionen eine wirklich ruhige, stressfreie und vollständig lokale Steuerung zu betreiben, bietet der Weg über das lokale Bluetooth-Umschreiben der URL die sauberste Alternative.
In diesem Thread geht es mir um eine ganzheitliche Gesamtlösung:
Die zenSDK-Ansteuerung über mein Steuerungsskript, die Bereitstellung meines lokalen Konfigurations-Tools UND vor allem die praxisnahe, unkomplizierte Hilfe für Anfänger durch z. B. einfache Beispiel-Blockly-Skripte als Vorlage, wie die Realisierung einer 0-Einspeisung.Hierzu möchte ich ausdrücklich jeden herzlich einladen, aktiv mitzuwirken!
Ein solches Projekt lebt vom Austausch:
-
Jede(r) ist herzlich eingeladen Fragen zu stellen, Logiken zu testen und Rückmeldungen zu geben, wo Hürden liegen.
-
Erfahrene Experten und Skript-Profis – sehr gerne auch Du, @paul53 – sind eingeladen, eigene optimierte Skripte, Blocklys oder Ideen zur Verfügung zu stellen, Fehler im Code zu jagen, Timing-Probleme zu melden oder Verbesserungen einzubringen.
Wenn ein Nutzer mein Tool verwendet, um die Route auf einen eigenen, lokalen Broker umzubiegen, läuft das gesamte System m. M. n. – inklusive der lokalen zenSDK-API – um ein Vielfaches schneller, flüssiger und stabiler.
Man hat dann die freie Wahl, ob man das gedrosselte, offizielle MQTT, die zenSDK API nutzen möchte oder die uneingeschränkte MQTT-Transparenz.
Alternativ lässt sich auch pihole oder Adguard verwenden um die Cloud-URL auf eine lokale IP umzuleiten.
Falls der aktuelle Titel des Threads:
"Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2“
für die hier angebotene Gesamtlösung mittlerweile nicht mehr aussagekräftig genug oder unpräzise erscheint, freue ich mich über jeden konstruktiven Vorschlag zur Änderung.Da das Forum den Titel leider auf maximal 60 Zeichen beschränkt, ist es gar nicht so einfach, API, Skripte, Blocklys und Konfigurations-Tools in einer einzigen Zeile prägnant unterzubringen.
Liebe Grüße
maxclaudi
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern.
Wie kann man feststellen ob sich das geändert hat? Ich habe die 2.0.1 auf dem solarflow800 Pro und im Moment den InternetZugang über die fritzbox gesperrt.
Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
-
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern.
Wie kann man feststellen ob sich das geändert hat? Ich habe die 2.0.1 auf dem solarflow800 Pro und im Moment den InternetZugang über die fritzbox gesperrt.
Hallo @Daniel-8 ,
das lässt sich im Grunde mit Fakten auswerten:-
App-Fakt:
Wenn über die originale Zendure-App auf dem Smartphone keine Steuerung mehr möglich ist und die Werte dort starr einfrieren und nicht mehr aktualisiert werden, weißt Du sicher: Deine Internetsperre im Router ist aktiv und die Cloud-Verbindung ist gekappt. -
zenSDK-Fakt
Wenn trotz dieser aktiven Internetsperre Deine lokale zenSDK-Ansteuerung weiterhin unverändert schnell funktioniert, das Polling absolut plausible, frische Werte liefert und das Setzen von Parametern (wie Limits) sofort und ohne weitere Verzögerung durchgeht – UND JETZT KOMMT DER ENTSCHEIDENDE PUNKT:
Wenn Du beobachtest, dass der einlaufende timestamp (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet, das System aber trotzdem absolut stabil weiterläuft, dann hast Du die absolute Gewissheit:
Du besitzt eine Firmware-Version, die eine echte, isolierte lokale Steuerung zulässt, ohne sich bei blockierter Cloud intern aufzuhängen.
Wer eine Firmware-Version hat bei dem das System nach einer Zeit der Internetsperre träge wird und lokal bleiben möchte oder muss (z. B. Gartenhaus ohne Internetverbindung etc.) der muss eben den Weg über die DNS-Umleitung (z. B. Pi-hole / AdGuard) oder das Umschreiben der URL via Bluetooth wählen, damit der interne Kommunikations-Stack des Geräts nicht ins Leere läuft.
Liebe Grüße
maxclaudi
-
-
Hallo @Daniel-8 ,
das lässt sich im Grunde mit Fakten auswerten:-
App-Fakt:
Wenn über die originale Zendure-App auf dem Smartphone keine Steuerung mehr möglich ist und die Werte dort starr einfrieren und nicht mehr aktualisiert werden, weißt Du sicher: Deine Internetsperre im Router ist aktiv und die Cloud-Verbindung ist gekappt. -
zenSDK-Fakt
Wenn trotz dieser aktiven Internetsperre Deine lokale zenSDK-Ansteuerung weiterhin unverändert schnell funktioniert, das Polling absolut plausible, frische Werte liefert und das Setzen von Parametern (wie Limits) sofort und ohne weitere Verzögerung durchgeht – UND JETZT KOMMT DER ENTSCHEIDENDE PUNKT:
Wenn Du beobachtest, dass der einlaufende timestamp (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet, das System aber trotzdem absolut stabil weiterläuft, dann hast Du die absolute Gewissheit:
Du besitzt eine Firmware-Version, die eine echte, isolierte lokale Steuerung zulässt, ohne sich bei blockierter Cloud intern aufzuhängen.
Wer eine Firmware-Version hat bei dem das System nach einer Zeit der Internetsperre träge wird und lokal bleiben möchte oder muss (z. B. Gartenhaus ohne Internetverbindung etc.) der muss eben den Weg über die DNS-Umleitung (z. B. Pi-hole / AdGuard) oder das Umschreiben der URL via Bluetooth wählen, damit der interne Kommunikations-Stack des Geräts nicht ins Leere läuft.
Liebe Grüße
maxclaudi
@maxclaudi [sagte]: (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet
Bei mir geht der JSON-Zeitstempel jetzt 37 s nach.
Ich habe vor einer Stunde das Intervall auf 2000 ms und den Timeout auf 1500 ms verringert: Bisher keine Probleme.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN42 / N100 / 8 GB / 500 GB; Proxmox mit 2 VM (iob / openCCU) -
-
@maxclaudi [sagte]: (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet
Bei mir geht der JSON-Zeitstempel jetzt 37 s nach.
Ich habe vor einer Stunde das Intervall auf 2000 ms und den Timeout auf 1500 ms verringert: Bisher keine Probleme.
@maxclaudi [sa
gte]: (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftetBei mir geht der JSON-Zeitstempel jetzt 37 s nach.
@paul53
Damit bist Du nun gesichert vollständig lokal, wenn es weiterhin so bleibt.
und der Zeitstempel weiter driftet. :-)Ich habe vor einer Stunde das Intervall auf 2000 ms und den Timeout auf 1500 ms verringert: Bisher keine Probleme.
Siehst Du, wie plötzlich Probleme verschwinden und der ESP32 nicht mehr überfordert wird :-)
Sobald der kleine ESP32-Chip nicht mehr ununterbrochen im Sekundentakt versuchen muss, die verschlüsselte Verbindung nach China aufzubauen, hat er plötzlich alle Rechenleistung der Welt frei, um Deine lokalen zenSDK-Befehle im Millisekundentakt abzuarbeiten -
Guten Morgen @paul53,
mir ging es hier primär um die technische Aufklärung zu dem Beitrag
@nograx sagte:
....Ich bin von Zendure angehalten worden mit dem Adapter bei den neuen Geräten die offiziell unterstützten Möglichkeiten zu nutzen. Und daran werde ich mich auch halten.Die offiziell unterstützten Möglichkeiten von Zendure beinhalten im zenSDK-Protokoll weder ein Cloud-Relay noch die unvollständige Manipulation von Modi wie HEMS über intransparente Funktionen.
Das halte ich technisch für riskanter – vor allem, wenn durch unvollständige Code-Basteleien Geräte-Befehle, Invoke-Methoden oder Modi verwendet werden, deren exakte Systemmatrix und Syntax gar nicht vollumfänglich bekannt sind.Zendure-Geräte sind zum Teil explizit für den Outdoor-, Camping- und Gartenhaus-Bereich konzipiert – Umgebungen, die oft weder über 230V Netzstrom noch über eine permanente Internetverbindung verfügen.
Zu Deiner Frage
@maxclaudi [sagte:
Es wird lediglich über den vorhandenen BLE-Konfigurationsmechanismus die MQTT-Serveradresse geändert, die das Gerät für seine Kommunikation verwendet.Damit bist du von der Überschrift "zenSDK local API" mittlerweile entfernt. Oder ist die Aktivierung der lokalen MQTT-Kommunikation Bestandteil des zenSDK?
Um das präzise zu beantworten:
Ja, die Aktivierung der lokalen MQTT-Kommunikation ist integraler Bestandteil des offiziellen zenSDK.Zendure dokumentiert genau diese RPC-Methoden zur lokalen Konfiguration transparent in den offiziellen Repositories Zendure/zenSDK.
Die Aktivierung erfolgt über exakt definierte API-Aufrufe wie:
POST /rpc Content-Type: application/json { "sn": "WOB1NHMAMXXXXX3", "method": "HA.Mqtt.SetConfig", "params": { "config": { "enable": true, "server": "192.168.50.48", "port":1883, "protocol":"mqtt", "username": "zendure", "password": "zendure" } } }sowie die MQTT status Abfrage:
GET /rpc?method=HA.Mqtt.GetStatusoder Get MQTT configuration
GET /rpc?method=HA.Mqtt.GetConfigAllerdings ist dieser von Zendure bereitgestellte lokale MQTT-Weg stark reglementiert und in der Übertragungsgeschwindigkeit gedrosselt.
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern.
Um mit diesen Versionen eine wirklich ruhige, stressfreie und vollständig lokale Steuerung zu betreiben, bietet der Weg über das lokale Bluetooth-Umschreiben der URL die sauberste Alternative.
In diesem Thread geht es mir um eine ganzheitliche Gesamtlösung:
Die zenSDK-Ansteuerung über mein Steuerungsskript, die Bereitstellung meines lokalen Konfigurations-Tools UND vor allem die praxisnahe, unkomplizierte Hilfe für Anfänger durch z. B. einfache Beispiel-Blockly-Skripte als Vorlage, wie die Realisierung einer 0-Einspeisung.Hierzu möchte ich ausdrücklich jeden herzlich einladen, aktiv mitzuwirken!
Ein solches Projekt lebt vom Austausch:
-
Jede(r) ist herzlich eingeladen Fragen zu stellen, Logiken zu testen und Rückmeldungen zu geben, wo Hürden liegen.
-
Erfahrene Experten und Skript-Profis – sehr gerne auch Du, @paul53 – sind eingeladen, eigene optimierte Skripte, Blocklys oder Ideen zur Verfügung zu stellen, Fehler im Code zu jagen, Timing-Probleme zu melden oder Verbesserungen einzubringen.
Wenn ein Nutzer mein Tool verwendet, um die Route auf einen eigenen, lokalen Broker umzubiegen, läuft das gesamte System m. M. n. – inklusive der lokalen zenSDK-API – um ein Vielfaches schneller, flüssiger und stabiler.
Man hat dann die freie Wahl, ob man das gedrosselte, offizielle MQTT, die zenSDK API nutzen möchte oder die uneingeschränkte MQTT-Transparenz.
Alternativ lässt sich auch pihole oder Adguard verwenden um die Cloud-URL auf eine lokale IP umzuleiten.
Falls der aktuelle Titel des Threads:
"Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2“
für die hier angebotene Gesamtlösung mittlerweile nicht mehr aussagekräftig genug oder unpräzise erscheint, freue ich mich über jeden konstruktiven Vorschlag zur Änderung.Da das Forum den Titel leider auf maximal 60 Zeichen beschränkt, ist es gar nicht so einfach, API, Skripte, Blocklys und Konfigurations-Tools in einer einzigen Zeile prägnant unterzubringen.
Liebe Grüße
maxclaudi
maxclaudi sagte:
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern....
Demnächst bekomme ich einen SolarFlow 2400 AC Pro zum Testen bereitgestellt.
Sobald das Gerät eintrifft und die Zeit es zulässt, werde ich mit einer extra alten Firmware-Version des 2400 AC Pro sowie dem vorhandenen 1600 AC Plus umfassende Testreihen durchführen.
Geplant sind tiefgehende Bluetooth- und WLAN-Analysen.
Danach erhalten die Geräte das Update auf die aktuellen Firmware-Versionen und werden im direkten Vergleich neu analysiert.
Weil diese Testreihen extrem umfangreich werden, ich die Daten präzise bewerten und die Ergebnisse detailliert dokumentieren muss, werde ich ab dann deutlich weniger Zeit haben.
Ich bitte daher jetzt schon um Verständnis und Berücksichtigung, wenn ich auf Fragen oder Anfragen künftig nicht mehr gewohnt schnell antworten kann.
Für das Vertrauen, den Gutschein und diese geniale Möglichkeit möchte ich mich an dieser Stelle ganz herzlich bedanken!
Viele Grüße
maxclaudi
-
-
Hallo @Daniel-8 ,
das lässt sich im Grunde mit Fakten auswerten:-
App-Fakt:
Wenn über die originale Zendure-App auf dem Smartphone keine Steuerung mehr möglich ist und die Werte dort starr einfrieren und nicht mehr aktualisiert werden, weißt Du sicher: Deine Internetsperre im Router ist aktiv und die Cloud-Verbindung ist gekappt. -
zenSDK-Fakt
Wenn trotz dieser aktiven Internetsperre Deine lokale zenSDK-Ansteuerung weiterhin unverändert schnell funktioniert, das Polling absolut plausible, frische Werte liefert und das Setzen von Parametern (wie Limits) sofort und ohne weitere Verzögerung durchgeht – UND JETZT KOMMT DER ENTSCHEIDENDE PUNKT:
Wenn Du beobachtest, dass der einlaufende timestamp (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet, das System aber trotzdem absolut stabil weiterläuft, dann hast Du die absolute Gewissheit:
Du besitzt eine Firmware-Version, die eine echte, isolierte lokale Steuerung zulässt, ohne sich bei blockierter Cloud intern aufzuhängen.
Wer eine Firmware-Version hat bei dem das System nach einer Zeit der Internetsperre träge wird und lokal bleiben möchte oder muss (z. B. Gartenhaus ohne Internetverbindung etc.) der muss eben den Weg über die DNS-Umleitung (z. B. Pi-hole / AdGuard) oder das Umschreiben der URL via Bluetooth wählen, damit der interne Kommunikations-Stack des Geräts nicht ins Leere läuft.
Liebe Grüße
maxclaudi
Hallo @Daniel-8 ,
das lässt sich im Grunde mit Fakten auswerten:- App-Fakt:
Wenn über die originale Zendure-App auf dem Smartphone keine Steuerung mehr möglich ist und die Werte dort starr einfrieren und nicht mehr aktualisiert werden, weißt Du sicher: Deine Internetsperre im Router ist aktiv und die Cloud-Verbindung ist gekappt.
Das ist bei mir so
- zenSDK-Fakt
Wenn trotz dieser aktiven Internetsperre Deine lokale zenSDK-Ansteuerung weiterhin unverändert schnell funktioniert, das Polling absolut plausible, frische Werte liefert und das Setzen von Parametern (wie Limits) sofort und ohne weitere Verzögerung durchgeht
Wenn ich setoutputLImit setzte dann dauert es schon eine gewisse Zeit bist outputlimit aktualiseirt ist. Aber das sind laut Zeitstempel Millisekunden und sollte denke ich.Siehe beide Screenshoots.
– UND JETZT KOMMT DER ENTSCHEIDENDE PUNKT:
Wenn Du beobachtest, dass der einlaufende timestamp (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet, das System aber trotzdem absolut stabil weiterläuft, dann hast Du die absolute Gewissheit:
Was meinst du mit JSON Zeitstempel? Den Datenpunkt timestamp bzw. timeUpdateTimestamp?
Du besitzt eine Firmware-Version, die eine echte, isolierte lokale Steuerung zulässt, ohne sich bei blockierter Cloud intern aufzuhängen.
Dann kann ich ja es mal so weiter laufen lassen mit dem ZenSDK Script ohne die DNS Umleitung
-
-
maxclaudi sagte:
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern....
Demnächst bekomme ich einen SolarFlow 2400 AC Pro zum Testen bereitgestellt.
Sobald das Gerät eintrifft und die Zeit es zulässt, werde ich mit einer extra alten Firmware-Version des 2400 AC Pro sowie dem vorhandenen 1600 AC Plus umfassende Testreihen durchführen.
Geplant sind tiefgehende Bluetooth- und WLAN-Analysen.
Danach erhalten die Geräte das Update auf die aktuellen Firmware-Versionen und werden im direkten Vergleich neu analysiert.
Weil diese Testreihen extrem umfangreich werden, ich die Daten präzise bewerten und die Ergebnisse detailliert dokumentieren muss, werde ich ab dann deutlich weniger Zeit haben.
Ich bitte daher jetzt schon um Verständnis und Berücksichtigung, wenn ich auf Fragen oder Anfragen künftig nicht mehr gewohnt schnell antworten kann.
Für das Vertrauen, den Gutschein und diese geniale Möglichkeit möchte ich mich an dieser Stelle ganz herzlich bedanken!
Viele Grüße
maxclaudi
maxclaudi sagte:
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern....
Demnächst bekomme ich einen SolarFlow 2400 AC Pro zum Testen bereitgestellt.
Sobald das Gerät eintrifft und die Zeit es zulässt, werde ich mit einer extra alten Firmware-Version des 2400 AC Pro sowie dem vorhandenen 1600 AC Plus umfassende Testreihen durchführen.
Geplant sind tiefgehende Bluetooth- und WLAN-Analysen.
Danach erhalten die Geräte das Update auf die aktuellen Firmware-Versionen und werden im direkten Vergleich neu analysiert.
Weil diese Testreihen extrem umfangreich werden, ich die Daten präzise bewerten und die Ergebnisse detailliert dokumentieren muss, werde ich ab dann deutlich weniger Zeit haben.
Ich bitte daher jetzt schon um Verständnis und Berücksichtigung, wenn ich auf Fragen oder Anfragen künftig nicht mehr gewohnt schnell antworten kann.
Für das Vertrauen, den Gutschein und diese geniale Möglichkeit möchte ich mich an dieser Stelle ganz herzlich bedanken!
Viele Grüße
maxclaudi
Bekommst du die von Zendure?
Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
maxclaudi sagte:
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern....
Demnächst bekomme ich einen SolarFlow 2400 AC Pro zum Testen bereitgestellt.
Sobald das Gerät eintrifft und die Zeit es zulässt, werde ich mit einer extra alten Firmware-Version des 2400 AC Pro sowie dem vorhandenen 1600 AC Plus umfassende Testreihen durchführen.
Geplant sind tiefgehende Bluetooth- und WLAN-Analysen.
Danach erhalten die Geräte das Update auf die aktuellen Firmware-Versionen und werden im direkten Vergleich neu analysiert.
Weil diese Testreihen extrem umfangreich werden, ich die Daten präzise bewerten und die Ergebnisse detailliert dokumentieren muss, werde ich ab dann deutlich weniger Zeit haben.
Ich bitte daher jetzt schon um Verständnis und Berücksichtigung, wenn ich auf Fragen oder Anfragen künftig nicht mehr gewohnt schnell antworten kann.
Für das Vertrauen, den Gutschein und diese geniale Möglichkeit möchte ich mich an dieser Stelle ganz herzlich bedanken!
Viele Grüße
maxclaudi
Bekommst du die von Zendure?
- Zum Zeitstempel (Timestamp):
Ja, genau. Ich meine den Datenpunkt timestamp im JSON-Objekt,das vom Gerät über die API geliefert wird.
Oder den Datenpunkt timeUpdate das den timestamp in lesbarer Zeit darstellt.
Wenn das Gerät komplett vom Internet isoliert ist, kann es die Uhrzeit nicht mehr synchronisieren.
Die interne Uhr läuft dann starr auf der eigenen Hardware-Basis weiter und fängt mit der Zeit an, leicht nachzugehen (zu driften).
Wenn das System trotz dieser Drift absolut flüssig läuft und Deine Limits in Millisekunden quittiert werden, läuft Deine Firmware-Version lokal stabil
und Du kannst es genau so weiterlaufen lassen.- Zur Bereitstellung des Testgeräts:
Ich habe im Nachgang die Korrespondenz noch einmal genauer geprüft und wurde auf eine entsprechende Vertraulichkeit (NDA / Confidentiality Notice) hingewiesen.
Bitte habt daher Verständnis, dass ich mich zu den Hintergründen der Bereitstellung nicht weiter öffentlich äußern werde.
- Zum Zeitstempel (Timestamp):
-
- Zum Zeitstempel (Timestamp):
Ja, genau. Ich meine den Datenpunkt timestamp im JSON-Objekt,das vom Gerät über die API geliefert wird.
Oder den Datenpunkt timeUpdate das den timestamp in lesbarer Zeit darstellt.
Wenn das Gerät komplett vom Internet isoliert ist, kann es die Uhrzeit nicht mehr synchronisieren.
Die interne Uhr läuft dann starr auf der eigenen Hardware-Basis weiter und fängt mit der Zeit an, leicht nachzugehen (zu driften).
Wenn das System trotz dieser Drift absolut flüssig läuft und Deine Limits in Millisekunden quittiert werden, läuft Deine Firmware-Version lokal stabil
und Du kannst es genau so weiterlaufen lassen.- Zur Bereitstellung des Testgeräts:
Ich habe im Nachgang die Korrespondenz noch einmal genauer geprüft und wurde auf eine entsprechende Vertraulichkeit (NDA / Confidentiality Notice) hingewiesen.
Bitte habt daher Verständnis, dass ich mich zu den Hintergründen der Bereitstellung nicht weiter öffentlich äußern werde.
- Zum Zeitstempel (Timestamp):
Ja, genau. Ich meine den Datenpunkt timestamp im JSON-Objekt,das vom Gerät über die API geliefert wird.
Oder den Datenpunkt timeUpdate das den timestamp in lesbarer Zeit darstellt.
Wenn das Gerät komplett vom Internet isoliert ist, kann es die Uhrzeit nicht mehr synchronisieren.
Die interne Uhr läuft dann starr auf der eigenen Hardware-Basis weiter und fängt mit der Zeit an, leicht nachzugehen (zu driften).
Wenn das System trotz dieser Drift absolut flüssig läuft und Deine Limits in Millisekunden quittiert werden, läuft Deine Firmware-Version lokal stabil
und Du kannst es genau so weiterlaufen lassen.Dann werde ich dies mal beobachten. Ob diese Zeit überhaupt mal abweicht von der systemzeit.
Ich werde es einfach mal so laufen lassen ohne umschreiben von dns. Wenn das Gerät als inselanlage läuft hat es ja oft auch keinen Internetzugang.
- Zur Bereitstellung des Testgeräts:
Ich habe im Nachgang die Korrespondenz noch einmal genauer geprüft und wurde auf eine entsprechende Vertraulichkeit (NDA / Confidentiality Notice) hingewiesen.
Bitte habt daher Verständnis, dass ich mich zu den Hintergründen der Bereitstellung nicht weiter öffentlich äußern werde.
Kein Problem. Ist auf jedenfall gut das du was zum testen bekommst und damit ja auch weitere Erkenntnisse sammeln kannst ohne an dein eigenes System gehen zu müssen.
Es kann sich ja nur positiv auswirken was du schon alles aufgeklärt hast hier.Vielen Dank nochmals.
- Zum Zeitstempel (Timestamp):
-
wann messt ihr den Zellendrift? Wie groß sollte der maximal sein?
Ich habe jetzt die Steuerung mal so aufgebaut, das er ab 3,45V bis 3,5V an jedem Akku mit 100 Watt lädt. Wenn er über 3,5V kommt, geht die ganze energie soweit es mir möglich ist mit meinen 800W ins Haus, so das ich dann auf 0W Ladung komme.
Bei 3,54V war der eine und bei 3,52V der andere auf 100% Soc.
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
200
Online33.1k
Benutzende83.7k
Themen1.4m
Beiträge