NEWS
Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2
-
PS @paul53: ...könntest du mir bei der Gelegenheit kurz bestätigen, ob bei deinem Modell die Seriennummer physisch auf dem Gehäuse/Typenschild ablesbar ist? Wie gesagt, ich will die Nummer nicht wissen, nur ob sie bei dir draufklebt. Danke!
Beispiele:
- HAB5MCADH280002
- FED3MCDHA320002
@maxclaudi [sagte]: Seriennummer physisch auf dem Gehäuse/Typenschild ablesbar ist?
Ja. Wozu ist das wichtig?
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]: Seriennummer physisch auf dem Gehäuse/Typenschild ablesbar ist?
Ja. Wozu ist das wichtig?
Dankeschön.
Wozu ist das wichtig?
Für meine Software.
Wenn jemand mehrere Geräte im Haus hat, muss man beim Starten des Tools natürlich das richtige Gerät auswählen können.
Zwar wird beim Bluetooth-Scan die BT-MAC-Adresse und der Bluetooth-Name des Geräts angezeigt – als Entwickler weiß man damit schnell, was zu wählen ist.
Für den normalen Anwender ist das aber oft kryptisch.Die Software soll eine sichere, einfache und für jeden verständliche Möglichkeit bieten, das gewünschte Gerät anhand der Seriennummer eindeutig zu identifizieren, bevor man es umschreibt.
-
@Daniel-8 sagte:
Also noch schneller per ZenSDk wenn er von der cloud getrennt ist?Ja, man kann aussuchen, ob man zenSDK verwendet oder reines MQTT. Wobei MQTT zu bevorzugen wäre, weil die Daten sofort und nur wenn nötig automatisch vom Gerät published werden.
Was meinst du mit sofort? Das heißt wenn er noch mit der cloud verbunden ist, rechnet er den soc falsch?
Sofort bedeutet sofort ;-)
Sobald das Gerät den lokalen Broker als Cloud-Broker akzeptiert, gibt es keinen Zendure-Cloud-Broker-Client mehr, der dazwischenfunkt.
So werden (und können) keine Befehle an das Zendure-Gerät gesendet werden, die man nicht möchte.Falsch berechnet wird von der Firmware nichts. Aber die Cloud hat die Werte in der Vergangenheit fehlerhaft korrigiert und auch diverse Einstellungen einfach überschrieben.
Lokal entscheidet man das eigenverantwortlich.
Die Firmware selbst ist m. M. n. gut genug und reagiert selbstständig auf z. B. kritische Wärme.Sobald man den Cloud-Zwang nimmt, läuft das System genau so, wie es von Anfang an hätte laufen sollen.
Das Ganze umzusetzen war alles andere als einfach, und ich muss an der Software definitiv noch weiterarbeiten... aber das wird schon
Was meinst du denn mit weiterarbeiten an der Software? Wo hackt es noch?
Es hakt nicht. Zu viel zum Schreiben. Ich arbeite z. Z. jeden Tag mehr als 12 Stunden an der Protokoll-Analyse und an weiterem Code.
@maxclaudi sagte: Falsch berechnet wird von der Firmware nichts.
Das kann ich nicht bestätigen.
Ich betreibe den SF 800 Pro 2 ohne PV als reine Notstromlösung. In diesem Fall ist die Berechnung des SoC "völlig daneben".
Folgende Werte des BMS sind ab ca. 16 Stunden nach 100-%-Kalibrierung etwa 3 Tage lang konstant:
Danach sinkt die Spannung langsam, aber der SoC bleibt weiterhin auf 100 %. Die Batterie wird mit etwa 0,2 A entladen (Selbstentladung / BMS?). Die folgenden DP-Werte passen nicht:
- state: Müsste 2 oder 0 sein, da die Batterie nicht geladen, sondern entladen wird, wie man an der Spannung sieht.
- batcur: Das Vorzeichen müsste negativ sein
"socLevel" wird anscheinend mittels "batCur" berechnet, was erklärt, dass nach Beendigung der Ladung mit "socSet" = 85 % der SoC weiter um jeweils 1 % alle 2 Stunden steigt anstatt mit dieser Rate zu sinken.
Anmerkung: Ich habe den SF per Router vom Internet abgekoppelt.
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: Falsch berechnet wird von der Firmware nichts.
Das kann ich nicht bestätigen.
Ich betreibe den SF 800 Pro 2 ohne PV als reine Notstromlösung. In diesem Fall ist die Berechnung des SoC "völlig daneben".
Folgende Werte des BMS sind ab ca. 16 Stunden nach 100-%-Kalibrierung etwa 3 Tage lang konstant:Danach sinkt die Spannung langsam, aber der SoC bleibt weiterhin auf 100 %. Die Batterie wird mit etwa 0,2 A entladen (Selbstentladung / BMS?). Die folgenden DP-Werte passen nicht:
- state: Müsste 2 oder 0 sein, da die Batterie nicht geladen, sondern entladen wird, wie man an der Spannung sieht.
- batcur: Das Vorzeichen müsste negativ sein
"socLevel" wird anscheinend mittels "batCur" berechnet, was erklärt, dass nach Beendigung der Ladung mit "socSet" = 85 % der SoC weiter um jeweils 1 % alle 2 Stunden steigt anstatt mit dieser Rate zu sinken.
Anmerkung: Ich habe den SF per Router vom Internet abgekoppelt.
@paul53
Bin bei SoC kein Erbsenzähler ;-)
Der SoC (State of Charge) ist letztlich immer ein Schätzwert und funktioniert bei keinem PV-System perfekt.Zudem muss man die Zellen regelmäßig vollpacken "grillen" – also auf 100 % laden –, damit das BMS die Zellen balancieren kann.
Selbst in diesem Bereich schützt einen Zendure recht gut, da die angezeigten 100 % in der Realität nicht die absoluten Belastungsgrenzen der Zellen sind.
Das lässt sich recht gut an der Spannung (Voltage) ablesen – vorausgesetzt, die Messwerte stimmen.
Jedenfalls sind reale Messwerte immer noch genauer als reine SoC-Schätzungen.Um die Anzeige wirklich zu kalibrieren, müsste man das System eigentlich regelmäßig so tief wie möglich entladen und wieder komplett vollmachen.
Nur so passen die SoC-Werte "halbwegs".
Soweit ich gelesen habe und meine mich erinnern zu können, betreibst du deine Batterie(n) ja sehr schonend im entspannten Wohlfühlbereich zwischen 20 % und 85 %.
Das ist für die Lebensdauer der Zellen absolut top!
Allerdings bedeutet das im Umkehrschluss leider auch, dass du den angezeigten SoC-Werten in diesem Korridor noch weniger vertrauen kannst.PS:
Dass die Werte konstant bleiben und viel schief geht liegt vermutlich daran, dass keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.
Es wird am Ende zu alle xx sek versucht den Broker zu erreichen. Gibt es keinen... -
@paul53
Bin bei SoC kein Erbsenzähler ;-)
Der SoC (State of Charge) ist letztlich immer ein Schätzwert und funktioniert bei keinem PV-System perfekt.Zudem muss man die Zellen regelmäßig vollpacken "grillen" – also auf 100 % laden –, damit das BMS die Zellen balancieren kann.
Selbst in diesem Bereich schützt einen Zendure recht gut, da die angezeigten 100 % in der Realität nicht die absoluten Belastungsgrenzen der Zellen sind.
Das lässt sich recht gut an der Spannung (Voltage) ablesen – vorausgesetzt, die Messwerte stimmen.
Jedenfalls sind reale Messwerte immer noch genauer als reine SoC-Schätzungen.Um die Anzeige wirklich zu kalibrieren, müsste man das System eigentlich regelmäßig so tief wie möglich entladen und wieder komplett vollmachen.
Nur so passen die SoC-Werte "halbwegs".
Soweit ich gelesen habe und meine mich erinnern zu können, betreibst du deine Batterie(n) ja sehr schonend im entspannten Wohlfühlbereich zwischen 20 % und 85 %.
Das ist für die Lebensdauer der Zellen absolut top!
Allerdings bedeutet das im Umkehrschluss leider auch, dass du den angezeigten SoC-Werten in diesem Korridor noch weniger vertrauen kannst.PS:
Dass die Werte konstant bleiben und viel schief geht liegt vermutlich daran, dass keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.
Es wird am Ende zu alle xx sek versucht den Broker zu erreichen. Gibt es keinen... -
@paul53
Bin bei SoC kein Erbsenzähler ;-)
Der SoC (State of Charge) ist letztlich immer ein Schätzwert und funktioniert bei keinem PV-System perfekt.Zudem muss man die Zellen regelmäßig vollpacken "grillen" – also auf 100 % laden –, damit das BMS die Zellen balancieren kann.
Selbst in diesem Bereich schützt einen Zendure recht gut, da die angezeigten 100 % in der Realität nicht die absoluten Belastungsgrenzen der Zellen sind.
Das lässt sich recht gut an der Spannung (Voltage) ablesen – vorausgesetzt, die Messwerte stimmen.
Jedenfalls sind reale Messwerte immer noch genauer als reine SoC-Schätzungen.Um die Anzeige wirklich zu kalibrieren, müsste man das System eigentlich regelmäßig so tief wie möglich entladen und wieder komplett vollmachen.
Nur so passen die SoC-Werte "halbwegs".
Soweit ich gelesen habe und meine mich erinnern zu können, betreibst du deine Batterie(n) ja sehr schonend im entspannten Wohlfühlbereich zwischen 20 % und 85 %.
Das ist für die Lebensdauer der Zellen absolut top!
Allerdings bedeutet das im Umkehrschluss leider auch, dass du den angezeigten SoC-Werten in diesem Korridor noch weniger vertrauen kannst.PS:
Dass die Werte konstant bleiben und viel schief geht liegt vermutlich daran, dass keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.
Es wird am Ende zu alle xx sek versucht den Broker zu erreichen. Gibt es keinen...@maxclaudi [sagte]: keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.
Wie kommst du darauf?
In den ersten Wochen bestand eine Internet-Verbindung. Das Verhalten war gleich.betreibst du deine Batterie(n) ja sehr schonend im entspannten Wohlfühlbereich zwischen 20 % und 85 %.
Das mache ich aufgrund der falschen SoC-Berechnung nicht mehr.
Per Skript schalte ich bei Erreichen von "minVol" <= 3,28 V den "acMode" auf Entladen. Wenn dann der SoC auf 96 % gefallen ist, schalte ich wieder um auf Laden mit "socSet" = 100 %. So sieht das im Chart aus:
Das Skript:
const idNetz = 'alias.0.USV.Netz'/*gridState - Stromnetz*/; const idSoc = 'alias.0.USV.SOC'/*electricLevel - SoC*/; const idMinV = 'alias.0.USV.minVol'/*Min cell voltage*/; const idDown = 'alias.0.USV.shutdown'/*PVE runter fahren*/; const idMode = 'alias.0.USV.acMode'/*acMode - 1: in charge, 2: out discharge*/; var netz = getState(idNetz).val; on(idNetz, function(dp) { netz = dp.state.val; sendTo('email', { subject: 'ioBroker Stromnetz', text: 'Netz ' + (netz ? 'wieder vorhanden' : 'ausgefallen!') }); }); function shutdown(text) { if(!netz) { sendTo('email', { subject: 'ioBroker PVE', text: text + '. PVE wird runter gefahren!' }); setState(idDown, true); // PVE runter fahren } } on(idSoc, function(dp) { // electricLevel if(dp.state.val < 30 && dp.oldState.val >= 30 ) { shutdown('SoC < 30 %'); } if(dp.state.val <= 96 && getState(idMode).val == 2) { setState(idMode, 1); // Laden } }); on(idMinV, function(dp) { // minVol if(dp.state.val < 3.2 && dp.oldState.val >= 3.2) { shutdown('min. Zellspannung < 3,2 V'); } if(dp.state.val <= 3.28 && dp.oldState.val > 3.28 && netz) { setState(idMode, 2); // Entladen sendTo('email', { subject: 'ioBroker USV', text: 'min. Zellspannung <= 3,28 V. Batterie wird entladen bis SoC 96 %.' }); } });Die Firmware beendet die Ladung bei "maxVol" von 3,57 V.
Die Firmware hat auch einen internen Tiefentladeschutz. Das habe ich beim Entladen beobachtet, als der SoC abrupt von 75 % auf 5 % fiel. Das anschließende Laden zeigte, dass die Batterie tatsächlich entladen war.
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]: keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.
Wie kommst du darauf?
In den ersten Wochen bestand eine Internet-Verbindung. Das Verhalten war gleich.betreibst du deine Batterie(n) ja sehr schonend im entspannten Wohlfühlbereich zwischen 20 % und 85 %.
Das mache ich aufgrund der falschen SoC-Berechnung nicht mehr.
Per Skript schalte ich bei Erreichen von "minVol" <= 3,28 V den "acMode" auf Entladen. Wenn dann der SoC auf 96 % gefallen ist, schalte ich wieder um auf Laden mit "socSet" = 100 %. So sieht das im Chart aus:Das Skript:
const idNetz = 'alias.0.USV.Netz'/*gridState - Stromnetz*/; const idSoc = 'alias.0.USV.SOC'/*electricLevel - SoC*/; const idMinV = 'alias.0.USV.minVol'/*Min cell voltage*/; const idDown = 'alias.0.USV.shutdown'/*PVE runter fahren*/; const idMode = 'alias.0.USV.acMode'/*acMode - 1: in charge, 2: out discharge*/; var netz = getState(idNetz).val; on(idNetz, function(dp) { netz = dp.state.val; sendTo('email', { subject: 'ioBroker Stromnetz', text: 'Netz ' + (netz ? 'wieder vorhanden' : 'ausgefallen!') }); }); function shutdown(text) { if(!netz) { sendTo('email', { subject: 'ioBroker PVE', text: text + '. PVE wird runter gefahren!' }); setState(idDown, true); // PVE runter fahren } } on(idSoc, function(dp) { // electricLevel if(dp.state.val < 30 && dp.oldState.val >= 30 ) { shutdown('SoC < 30 %'); } if(dp.state.val <= 96 && getState(idMode).val == 2) { setState(idMode, 1); // Laden } }); on(idMinV, function(dp) { // minVol if(dp.state.val < 3.2 && dp.oldState.val >= 3.2) { shutdown('min. Zellspannung < 3,2 V'); } if(dp.state.val <= 3.28 && dp.oldState.val > 3.28 && netz) { setState(idMode, 2); // Entladen sendTo('email', { subject: 'ioBroker USV', text: 'min. Zellspannung <= 3,28 V. Batterie wird entladen bis SoC 96 %.' }); } });Die Firmware beendet die Ladung bei "maxVol" von 3,57 V.
Die Firmware hat auch einen internen Tiefentladeschutz. Das habe ich beim Entladen beobachtet, als der SoC abrupt von 75 % auf 5 % fiel. Das anschließende Laden zeigte, dass die Batterie tatsächlich entladen war.
tcpdump, wireshark, Analyse, Erfahrung.
Gut, wenn es bei Deiner Firmware nicht so ist.Per Skript schalte ich bei Erreichen von "minVol" <= 3,28 V den "acMode" auf Entladen. Wenn dann der SoC auf 96 % gefallen ist, schalte ich wieder um auf Laden mit "socSet" = 100 %.
?
Sorry keine Zeit, muss weiter analysieren, prog. und testen... solange ich noch vor Ort bin.PS: ich (ent-)lade ausschließlich anhand von Messwerten. Limits werden auch nicht von SoC bestimmt nur Volt.
@paul53 sagte
Die Firmware beendet die Ladung bei "maxVol" von 3,57 V.bei meinen Batterien und Geräten nicht: 3,4xV.
-
tcpdump, wireshark, Analyse, Erfahrung.
Gut, wenn es bei Deiner Firmware nicht so ist.Per Skript schalte ich bei Erreichen von "minVol" <= 3,28 V den "acMode" auf Entladen. Wenn dann der SoC auf 96 % gefallen ist, schalte ich wieder um auf Laden mit "socSet" = 100 %.
?
Sorry keine Zeit, muss weiter analysieren, prog. und testen... solange ich noch vor Ort bin.PS: ich (ent-)lade ausschließlich anhand von Messwerten. Limits werden auch nicht von SoC bestimmt nur Volt.
@paul53 sagte
Die Firmware beendet die Ladung bei "maxVol" von 3,57 V.bei meinen Batterien und Geräten nicht: 3,4xV.
@paul53 sagte
Die Firmware beendet die Ladung bei "maxVol" von 3,57 V.@maxclaudi sagte:
bei meinen Batterien und Geräten nicht: 3,4xV.Bei meinen Hyper2000 und 800Pro2 hab ich Werte von 3.4xV bis 3.6xV, also immer verschieden.Habe als Typ AB2000S, AB2000X und AB2000L.
Ich meine mal gelesen zu haben das Zendure die Ladespannung und die Kapazität überwacht.
So ne Art Mischkalkulation, je nachdem was zuerst eintritt wird die Ladung gestoppt. -
@Daniel-8 sagte:
Also noch schneller per ZenSDk wenn er von der cloud getrennt ist?Ja, man kann aussuchen, ob man zenSDK verwendet oder reines MQTT. Wobei MQTT zu bevorzugen wäre, weil die Daten sofort und nur wenn nötig automatisch vom Gerät published werden.
Was meinst du mit sofort? Das heißt wenn er noch mit der cloud verbunden ist, rechnet er den soc falsch?
Sofort bedeutet sofort ;-)
Sobald das Gerät den lokalen Broker als Cloud-Broker akzeptiert, gibt es keinen Zendure-Cloud-Broker-Client mehr, der dazwischenfunkt.
So werden (und können) keine Befehle an das Zendure-Gerät gesendet werden, die man nicht möchte.Falsch berechnet wird von der Firmware nichts. Aber die Cloud hat die Werte in der Vergangenheit fehlerhaft korrigiert und auch diverse Einstellungen einfach überschrieben.
Lokal entscheidet man das eigenverantwortlich.
Die Firmware selbst ist m. M. n. gut genug und reagiert selbstständig auf z. B. kritische Wärme.Sobald man den Cloud-Zwang nimmt, läuft das System genau so, wie es von Anfang an hätte laufen sollen.
Das Ganze umzusetzen war alles andere als einfach, und ich muss an der Software definitiv noch weiterarbeiten... aber das wird schon
Was meinst du denn mit weiterarbeiten an der Software? Wo hackt es noch?
Es hakt nicht. Zu viel zum Schreiben. Ich arbeite z. Z. jeden Tag mehr als 12 Stunden an der Protokoll-Analyse und an weiterem Code.
@Daniel-8 sagte:
Also noch schneller per ZenSDk wenn er von der cloud getrennt ist?Ja, man kann aussuchen, ob man zenSDK verwendet oder reines MQTT. Wobei MQTT zu bevorzugen wäre, weil die Daten sofort und nur wenn nötig automatisch vom Gerät published werden.
Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.
Die Firmware selbst ist m. M. n. gut genug und reagiert selbstständig auf z. B. kritische Wärme.
Ja das denke ich auch das die Firmwar selbst gut genug ist. Es könnte ja auch mal die Cloud ausfallen und dann müssen die Geräte ja auch reagieren bevor etwas passiert
Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
@Daniel-8 sagte:
Also noch schneller per ZenSDk wenn er von der cloud getrennt ist?Ja, man kann aussuchen, ob man zenSDK verwendet oder reines MQTT. Wobei MQTT zu bevorzugen wäre, weil die Daten sofort und nur wenn nötig automatisch vom Gerät published werden.
Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.
Die Firmware selbst ist m. M. n. gut genug und reagiert selbstständig auf z. B. kritische Wärme.
Ja das denke ich auch das die Firmwar selbst gut genug ist. Es könnte ja auch mal die Cloud ausfallen und dann müssen die Geräte ja auch reagieren bevor etwas passiert
@Daniel-8 sagte:
Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.In dem Fall würde ich das zenSDK-Script zur MQTT-Steuerung anpassen.
Habe ich schon für einen HUB2000.
Einfach konfigurieren, Struktur und Datenpunkte bleiben identisch bzw. werden noch mehr und zusätzlich automatisch neu angelegt.Triggern statt HTTP GET pollen. Statt POST leicht verändertes JSON erzeugen und an Datenpunkte des MQTT-Adapters übergeben.
PS: Es geht beides.
In meinen Tests läuft zenSDK weiter mit dem 1600AC+ -
@Daniel-8 sagte:
Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.In dem Fall würde ich das zenSDK-Script zur MQTT-Steuerung anpassen.
Habe ich schon für einen HUB2000.
Einfach konfigurieren, Struktur und Datenpunkte bleiben identisch bzw. werden noch mehr und zusätzlich automatisch neu angelegt.Triggern statt HTTP GET pollen. Statt POST leicht verändertes JSON erzeugen und an Datenpunkte des MQTT-Adapters übergeben.
PS: Es geht beides.
In meinen Tests läuft zenSDK weiter mit dem 1600AC+@Daniel-8 sagte:
Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.In dem Fall würde ich das zenSDK-Script zur MQTT-Steuerung anpassen.
Habe ich schon für einen HUB2000.
Einfach konfigurieren, Struktur und Datenpunkte bleiben identisch bzw. werden noch mehr und zusätzlich automatisch neu angelegt.Triggern statt HTTP GET pollen. Statt POST leicht verändertes JSON erzeugen und an Datenpunkte des MQTT-Adapters übergeben.
PS: Es geht beides.
In meinen Tests läuft zenSDK weiter mit dem 1600AC+Aber beides braucht man ja eigentlich nicht oder gibt es da einen Vorteil?
Kann ich es riskieren mit dem direkten mqtt Adapter vom iobroker den Speicher auf lokal umzustellen?
Aber dafür muss ich mir mal Zeit nehmen. Das geht nicht mehr vor dem Urlaub.
Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
@Daniel-8 sagte:
Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.In dem Fall würde ich das zenSDK-Script zur MQTT-Steuerung anpassen.
Habe ich schon für einen HUB2000.
Einfach konfigurieren, Struktur und Datenpunkte bleiben identisch bzw. werden noch mehr und zusätzlich automatisch neu angelegt.Triggern statt HTTP GET pollen. Statt POST leicht verändertes JSON erzeugen und an Datenpunkte des MQTT-Adapters übergeben.
PS: Es geht beides.
In meinen Tests läuft zenSDK weiter mit dem 1600AC+Aber beides braucht man ja eigentlich nicht oder gibt es da einen Vorteil?
Kann ich es riskieren mit dem direkten mqtt Adapter vom iobroker den Speicher auf lokal umzustellen?
Aber dafür muss ich mir mal Zeit nehmen. Das geht nicht mehr vor dem Urlaub.
@Daniel-8 sagte:
Aber beides braucht man ja eigentlich nicht...Richtig, beides benötigt man nicht.
Vorteile mit Cloud-Ersatz-Broker MQTT:
-
MQTT ist komfortabler und schneller, weil es dann nicht reglementiert ist, wie das offizielle lokale MQTT. Es bietet viel mächtigere Möglichkeiten. (Was auch eine Gefahr birgt, wenn man nicht weiß, welche Topics beschrieben werden, was sie als Antwort erwarten usw.)
-
MQTT ist schneller, weil nicht gepollt werden muss. Wenn Werte sich ändern, wird es automatisch published. Man muss nur Änderungen triggern und nicht alle x Sek. die Werte abfragen.
-
WiFi / HTTP(S) wird entlastet. Man bekommt alle wahren Topics und kann Werte setzen, die sonst nicht gesetzt werden können. (Birgt auch eine Gefahr in sich, wenn man wild experimentiert oder Werte setzt, die normaler Weise für Funktionen bestimmt sind, die die Cloud nur im HEMS setzen würde. Am besten man nutzt nur zum Schreiben "properties" wie mit zenSDK.)
Vorteil von zenSDK mit Cloud-Ersatz-Broker:
-
Bei der Umstellung erst mal alles bleiben kann wie es ist und läuft dann wirklich lokal.
-
Schneller wie bisher, weil es keine Cloud gibt, die permanent irgendwas abfragen, senden oder "dazwischen funken" kann. zenSDK prüft immer wieder, ob die Verbindung zur Cloud besteht. Das ist sie ja – in Form eines lokalen Brokers.
Kann ich es riskieren mit dem direkten mqtt Adapter vom iobroker den Speicher auf lokal umzustellen?
Müsste man erst testen. Ich verwende nur mosquitto. Ausgereift, zuverlässig, schlank, ressourcenarm und schnell..
Aber dafür muss ich mir mal Zeit nehmen. Das geht nicht mehr vor dem Urlaub.
Schönen Urlaub Deiner Familie und Dir.
-
-
@maxclaudi [sagte]: keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.
Wie kommst du darauf?
In den ersten Wochen bestand eine Internet-Verbindung. Das Verhalten war gleich.betreibst du deine Batterie(n) ja sehr schonend im entspannten Wohlfühlbereich zwischen 20 % und 85 %.
Das mache ich aufgrund der falschen SoC-Berechnung nicht mehr.
Per Skript schalte ich bei Erreichen von "minVol" <= 3,28 V den "acMode" auf Entladen. Wenn dann der SoC auf 96 % gefallen ist, schalte ich wieder um auf Laden mit "socSet" = 100 %. So sieht das im Chart aus:Das Skript:
const idNetz = 'alias.0.USV.Netz'/*gridState - Stromnetz*/; const idSoc = 'alias.0.USV.SOC'/*electricLevel - SoC*/; const idMinV = 'alias.0.USV.minVol'/*Min cell voltage*/; const idDown = 'alias.0.USV.shutdown'/*PVE runter fahren*/; const idMode = 'alias.0.USV.acMode'/*acMode - 1: in charge, 2: out discharge*/; var netz = getState(idNetz).val; on(idNetz, function(dp) { netz = dp.state.val; sendTo('email', { subject: 'ioBroker Stromnetz', text: 'Netz ' + (netz ? 'wieder vorhanden' : 'ausgefallen!') }); }); function shutdown(text) { if(!netz) { sendTo('email', { subject: 'ioBroker PVE', text: text + '. PVE wird runter gefahren!' }); setState(idDown, true); // PVE runter fahren } } on(idSoc, function(dp) { // electricLevel if(dp.state.val < 30 && dp.oldState.val >= 30 ) { shutdown('SoC < 30 %'); } if(dp.state.val <= 96 && getState(idMode).val == 2) { setState(idMode, 1); // Laden } }); on(idMinV, function(dp) { // minVol if(dp.state.val < 3.2 && dp.oldState.val >= 3.2) { shutdown('min. Zellspannung < 3,2 V'); } if(dp.state.val <= 3.28 && dp.oldState.val > 3.28 && netz) { setState(idMode, 2); // Entladen sendTo('email', { subject: 'ioBroker USV', text: 'min. Zellspannung <= 3,28 V. Batterie wird entladen bis SoC 96 %.' }); } });Die Firmware beendet die Ladung bei "maxVol" von 3,57 V.
Die Firmware hat auch einen internen Tiefentladeschutz. Das habe ich beim Entladen beobachtet, als der SoC abrupt von 75 % auf 5 % fiel. Das anschließende Laden zeigte, dass die Batterie tatsächlich entladen war.
@maxclaudi [sagte]: keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.
Wie kommst du darauf?
maxclaudi sagte:
tcpdump, wireshark, Analyse, Erfahrung.
Gut, wenn es bei Deiner Firmware nicht so ist.Das wurde auch vom Zendure-Entwickler David schon früher bestätigt - wenn es nicht mit neuer Firmware verändert wurde -, siehe:
Das Problem liegt nicht am Script, sondern an der Firmware -
@maxclaudi [sagte]: keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.
Wie kommst du darauf?
maxclaudi sagte:
tcpdump, wireshark, Analyse, Erfahrung.
Gut, wenn es bei Deiner Firmware nicht so ist.Das wurde auch vom Zendure-Entwickler David schon früher bestätigt - wenn es nicht mit neuer Firmware verändert wurde -, siehe:
Das Problem liegt nicht am Script, sondern an der Firmwarewenn es nicht mit neuer Firmware verändert wurde
Es sieht danach aus. Log von heute:
2026-08-14 03:41:21.984 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 03:41:25.004 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 06:20:27.839 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 06:20:30.862 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 09:04:33.916 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 09:04:36.934 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 10:55:19.354 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 10:55:24.190 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 10:55:34.354 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 10:55:39.354 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (2): timeout of 2000ms exceeded 2026-08-14 10:55:42.398 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 10:55:49.355 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 10:55:54.355 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (2): timeout of 2000ms exceeded 2026-08-14 10:55:57.517 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 11:48:39.606 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 11:48:42.624 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OKDer SF ist schon seit Wochen vom Internet getrennt. Mein Nachbar funkt zur Zeit auf dem gleichen Kanal wie ich.
Nachtrag: Habe die WLAN-Leistung meines Routers von 25 % auf 100 % erhöht. Dadurch hat der Router meines Nachbarn den Kanal gewechselt. Seitdem kein Timeout-Log.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN42 / N100 / 8 GB / 500 GB; Proxmox mit 2 VM (iob / openCCU) -
wenn es nicht mit neuer Firmware verändert wurde
Es sieht danach aus. Log von heute:
2026-08-14 03:41:21.984 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 03:41:25.004 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 06:20:27.839 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 06:20:30.862 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 09:04:33.916 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 09:04:36.934 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 10:55:19.354 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 10:55:24.190 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 10:55:34.354 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 10:55:39.354 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (2): timeout of 2000ms exceeded 2026-08-14 10:55:42.398 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 10:55:49.355 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 10:55:54.355 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (2): timeout of 2000ms exceeded 2026-08-14 10:55:57.517 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 11:48:39.606 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 11:48:42.624 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OKDer SF ist schon seit Wochen vom Internet getrennt. Mein Nachbar funkt zur Zeit auf dem gleichen Kanal wie ich.
Nachtrag: Habe die WLAN-Leistung meines Routers von 25 % auf 100 % erhöht. Dadurch hat der Router meines Nachbarn den Kanal gewechselt. Seitdem kein Timeout-Log.
wenn es nicht mit neuer Firmware verändert wurde
Es sieht danach aus. Log von heute:....
super, wenn es so ist :-)
Beurteilen kann ich es nicht, weil ich keine Geräte "längere Zeit in die Finger" bekommen habe mit neuestem Update.Nachtrag: Habe die WLAN-Leistung meines Routers von 25 % auf 100 % erhöht. Dadurch hat der Router meines Nachbarn den Kanal gewechselt. Seitdem kein Timeout-Log.
:-)))
-
@Daniel-8 sagte:
Aber beides braucht man ja eigentlich nicht...Richtig, beides benötigt man nicht.
Vorteile mit Cloud-Ersatz-Broker MQTT:
-
MQTT ist komfortabler und schneller, weil es dann nicht reglementiert ist, wie das offizielle lokale MQTT. Es bietet viel mächtigere Möglichkeiten. (Was auch eine Gefahr birgt, wenn man nicht weiß, welche Topics beschrieben werden, was sie als Antwort erwarten usw.)
-
MQTT ist schneller, weil nicht gepollt werden muss. Wenn Werte sich ändern, wird es automatisch published. Man muss nur Änderungen triggern und nicht alle x Sek. die Werte abfragen.
-
WiFi / HTTP(S) wird entlastet. Man bekommt alle wahren Topics und kann Werte setzen, die sonst nicht gesetzt werden können. (Birgt auch eine Gefahr in sich, wenn man wild experimentiert oder Werte setzt, die normaler Weise für Funktionen bestimmt sind, die die Cloud nur im HEMS setzen würde. Am besten man nutzt nur zum Schreiben "properties" wie mit zenSDK.)
Vorteil von zenSDK mit Cloud-Ersatz-Broker:
-
Bei der Umstellung erst mal alles bleiben kann wie es ist und läuft dann wirklich lokal.
-
Schneller wie bisher, weil es keine Cloud gibt, die permanent irgendwas abfragen, senden oder "dazwischen funken" kann. zenSDK prüft immer wieder, ob die Verbindung zur Cloud besteht. Das ist sie ja – in Form eines lokalen Brokers.
Kann ich es riskieren mit dem direkten mqtt Adapter vom iobroker den Speicher auf lokal umzustellen?
Müsste man erst testen. Ich verwende nur mosquitto. Ausgereift, zuverlässig, schlank, ressourcenarm und schnell..
Aber dafür muss ich mir mal Zeit nehmen. Das geht nicht mehr vor dem Urlaub.
Schönen Urlaub Deiner Familie und Dir.
@Daniel-8 sagte:
Aber beides braucht man ja eigentlich nicht...Richtig, beides benötigt man nicht.
Vorteile mit Cloud-Ersatz-Broker MQTT:
-
MQTT ist komfortabler und schneller, weil es dann nicht reglementiert ist, wie das offizielle lokale MQTT. Es bietet viel mächtigere Möglichkeiten. (Was auch eine Gefahr birgt, wenn man nicht weiß, welche Topics beschrieben werden, was sie als Antwort erwarten usw.)
-
MQTT ist schneller, weil nicht gepollt werden muss. Wenn Werte sich ändern, wird es automatisch published. Man muss nur Änderungen triggern und nicht alle x Sek. die Werte abfragen.
-
WiFi / HTTP(S) wird entlastet. Man bekommt alle wahren Topics und kann Werte setzen, die sonst nicht gesetzt werden können. (Birgt auch eine Gefahr in sich, wenn man wild experimentiert oder Werte setzt, die normaler Weise für Funktionen bestimmt sind, die die Cloud nur im HEMS setzen würde. Am besten man nutzt nur zum Schreiben "properties" wie mit zenSDK.)
Dann sollte ja nichts passieren wenn man nur die properties nutzt. Mehr brauche ich ja sowieso nicht. Eigentlich brauche ich nur die einspeiseleistung und den min soc.
Vorteil von zenSDK mit Cloud-Ersatz-Broker:
-
Bei der Umstellung erst mal alles bleiben kann wie es ist und läuft dann wirklich lokal.
-
Schneller wie bisher, weil es keine Cloud gibt, die permanent irgendwas abfragen, senden oder "dazwischen funken" kann. zenSDK prüft immer wieder, ob die Verbindung zur Cloud besteht. Das ist sie ja – in Form eines lokalen Brokers.
Kann ich es riskieren mit dem direkten mqtt Adapter vom iobroker den Speicher auf lokal umzustellen?
Müsste man erst testen. Ich verwende nur mosquitto. Ausgereift, zuverlässig, schlank, ressourcenarm und schnell..
Das kann ich ja mal machen. Ich kann ja zur Not mit deinem Programm immer wieder auf die cloud umstellen falls es nicht geht.
Aber dafür muss ich mir mal Zeit nehmen. Das geht nicht mehr vor dem Urlaub.
Schönen Urlaub Deiner Familie und Dir.
Danke.
-
-
@maxclaudi
Bei wieviel volt schaltest du die einspeisung ab? Und wieviel soc ist das ca? Bei mir ist es grad häufig so, das der soc nach dem abschalten bei 8% ca ne halbe Stunde bis stunde später gerne mal um 3-4% nach unten springt und dann aber weiter langsam 1-2% sinkt. Somit habe ich in der früh nur noch ca.3% drinnen. Könnte es auch daran liegen das die Zellen dann kalt werden, weil es ja jetzt abends und nachts bisschen abkühlt und dann die spannung und der soc schlagartig einbricht? Spannung habe ich jetzt nicht beobachtet und geloggtSolarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
@maxclaudi
Bei wieviel volt schaltest du die einspeisung ab? Und wieviel soc ist das ca? Bei mir ist es grad häufig so, das der soc nach dem abschalten bei 8% ca ne halbe Stunde bis stunde später gerne mal um 3-4% nach unten springt und dann aber weiter langsam 1-2% sinkt. Somit habe ich in der früh nur noch ca.3% drinnen. Könnte es auch daran liegen das die Zellen dann kalt werden, weil es ja jetzt abends und nachts bisschen abkühlt und dann die spannung und der soc schlagartig einbricht? Spannung habe ich jetzt nicht beobachtet und geloggt@Daniel-8 sagte:
Bei wieviel volt schaltest du die einspeisung ab? Und wieviel soc ist das ca?3.2V ~20 % SoC (Die Batterie neigt sich dem Ende)
Bei mir ist es grad häufig so, das der soc nach dem abschalten bei 8% ca ne halbe Stunde bis stunde später gerne mal um 3-4% nach unten springt und dann aber weiter langsam 1-2% sinkt. Somit habe ich in der früh nur noch ca.3% drinnen.
tpische Zendure Batterien (AB1000/2000) sind 15S1 LiFePO4
- 3,35 V – 3,40 V: ~100 % SoC (Voll)
- 3,28 V: ~50 % SoC (flaches Mittelfeld)
- 3,20 V: ~20 % SoC (Die Batterie neigt sich dem Ende)
- 3,15 V: ~10 % SoC (Die Spannung beginnt spürbar zu sinken)
weniger Volt sind besser zu vermeiden!
Weil meine Batterien indoor betrieben werden verwende ich einen Batteriechutz auch mal mit 3.16V Weniger nicht. Outdoor und sicherer ist m. M. minVol 3.2V.
Könnte es auch daran liegen das die Zellen dann kalt werden, weil es ja jetzt abends und nachts bisschen abkühlt ....
Wenn Deine Batterien outdoor sind: Ja.
und dann die spannung und der soc schlagartig einbricht? Spannung habe ich jetzt nicht beobachtet und geloggt
Spannung schlagartig wahrscheinlich nicht.
Dein Einsatzzweck und Ziel ist klar.
Leider ist eine PV-Batterie nicht für standby gedacht und vor allem nicht im entladenen Zustand zusätzlich an einem kalten/kühlen Ort.
Es ist ja noch Sommer.
Ich würde es mit 3.2V ca 20% probieren. minVol und energieLevel loggen. -
@Daniel-8 sagte:
Bei wieviel volt schaltest du die einspeisung ab? Und wieviel soc ist das ca?3.2V ~20 % SoC (Die Batterie neigt sich dem Ende)
Bei mir ist es grad häufig so, das der soc nach dem abschalten bei 8% ca ne halbe Stunde bis stunde später gerne mal um 3-4% nach unten springt und dann aber weiter langsam 1-2% sinkt. Somit habe ich in der früh nur noch ca.3% drinnen.
tpische Zendure Batterien (AB1000/2000) sind 15S1 LiFePO4
- 3,35 V – 3,40 V: ~100 % SoC (Voll)
- 3,28 V: ~50 % SoC (flaches Mittelfeld)
- 3,20 V: ~20 % SoC (Die Batterie neigt sich dem Ende)
- 3,15 V: ~10 % SoC (Die Spannung beginnt spürbar zu sinken)
weniger Volt sind besser zu vermeiden!
Weil meine Batterien indoor betrieben werden verwende ich einen Batteriechutz auch mal mit 3.16V Weniger nicht. Outdoor und sicherer ist m. M. minVol 3.2V.
Könnte es auch daran liegen das die Zellen dann kalt werden, weil es ja jetzt abends und nachts bisschen abkühlt ....
Wenn Deine Batterien outdoor sind: Ja.
und dann die spannung und der soc schlagartig einbricht? Spannung habe ich jetzt nicht beobachtet und geloggt
Spannung schlagartig wahrscheinlich nicht.
Dein Einsatzzweck und Ziel ist klar.
Leider ist eine PV-Batterie nicht für standby gedacht und vor allem nicht im entladenen Zustand zusätzlich an einem kalten/kühlen Ort.
Es ist ja noch Sommer.
Ich würde es mit 3.2V ca 20% probieren. minVol und energieLevel loggen.@Daniel-8 sagte:
Bei wieviel volt schaltest du die einspeisung ab? Und wieviel soc ist das ca?3.2V ~20 % SoC (Die Batterie neigt sich dem Ende)
Bei mir ist es grad häufig so, das der soc nach dem abschalten bei 8% ca ne halbe Stunde bis stunde später gerne mal um 3-4% nach unten springt und dann aber weiter langsam 1-2% sinkt. Somit habe ich in der früh nur noch ca.3% drinnen.
tpische Zendure Batterien (AB1000/2000) sind 15S1 LiFePO4
- 3,35 V – 3,40 V: ~100 % SoC (Voll)
- 3,28 V: ~50 % SoC (flaches Mittelfeld)
- 3,20 V: ~20 % SoC (Die Batterie neigt sich dem Ende)
- 3,15 V: ~10 % SoC (Die Spannung beginnt spürbar zu sinken)
weniger Volt sind besser zu vermeiden!
Weil meine Batterien indoor betrieben werden verwende ich einen Batteriechutz auch mal mit 3.16V Weniger nicht. Outdoor und sicherer ist m. M. minVol 3.2V.
Dann werde ich die 3,2V mal anstreben
Könnte es auch daran liegen das die Zellen dann kalt werden, weil es ja jetzt abends und nachts bisschen abkühlt ....
Wenn Deine Batterien outdoor sind: Ja.
Ja sind sie.
und dann die spannung und der soc schlagartig einbricht? Spannung habe ich jetzt nicht beobachtet und geloggt
Spannung schlagartig wahrscheinlich nicht.
Dein Einsatzzweck und Ziel ist klar.
Leider ist eine PV-Batterie nicht für standby gedacht und vor allem nicht im entladenen Zustand zusätzlich an einem kalten/kühlen Ort.
Es ist ja noch Sommer.
Ich würde es mit 3.2V ca 20% probieren. minVol und energieLevel loggen.Werde ich mal umsetzen. Also sollte ich sie nicht viel unter 20% entladen.
Im Winter bin ich sowieso weiter oben weil da bekommt man ja die speicher so gut wie nie voll. -
Ich habe letzten Winter sehr gute Erfahrung mit meinem Wintermodus gemacht.
Mein Blockly stoppe das Entladen so lange bis der Akku voll ist. Dann startet Abends das Entladen nach Bedarf bis runter auf 50% oder minVolt <3.20 Volt - je nachdem was zuerst eintritt.
Dann stoppe ich das Entladen und lade wieder so lange bis der Akku wieder voll ist.
Mit meinen 2 kwp Solarmodulen und 3,9 kw Speicher wird der Speicher im Winter 1 bis 2 mal die Woche voll. Im Dez und Jan kann es auch mal fast 2 Wochen dauern.
Wichtig dazu, mein Speicher steht das ganze Jahr im Keller. So passen die Eckwerte für mich perfekt.
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
505
Online33.1k
Benutzende83.7k
Themen1.3m
Beiträge