Weiter zum Inhalt
  • Home
  • Aktuell
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Hell
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dunkel
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Skripten / Logik
  4. JavaScript
  5. Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

NEWS

  • Der neue Monatsrückblick für September 2026 ist online!
    BluefoxB
    Bluefox
    9
    1
    339

  • Neu im Blog: Was die neue Website alles kann
    BluefoxB
    Bluefox
    7
    1
    274

  • Node.js 24 ist jetzt offiziell empfohlen!
    apollon77A
    apollon77
    9
    1
    549

Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

Geplant Angeheftet Gesperrt Verschoben JavaScript
628 Beiträge 24 Kommentatoren 98.0k Aufrufe 22 Beobachtet
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • maxclaudiM maxclaudi

    @petman sagte:

    @T-147
    ich hab den SF800pro2 mit 2.0.2, war schon bei der Erstinbetreiebnahme drauf, mitZwei AB2000, ein 2 Jahre alter und der vom SF800pro2
    Hatte letzte Woche auch "Tiefentladung" bis 2,56V(alter AB) bzw. 2,7V (neuerAB) am Morgen und er ist schon mehrfach im Einspeisemodus hängengeblieben aber bisher noch nie so Teifenladen. Ich musste dann eingreifen und aus dem Netz laden, was ich bisher vermieden habe weil vormittags keine Sonne. Als die Akkus wieder auf 20% waren hat er sich wieder gefangen und wieder normal gearbeitet.
    Ich habe das SDK-Skript und den Blockly von maxclaudi, 4x 450Wp OSO/WNW, je eins an einem MPT.

    Bitte verwende statt Blockly mal das JS-Script aus #Post 610
    Damit sollte der Batterieschutz übergeordnet greifen, falls die Firmware selbst einmal nicht rechtzeitig einlenkt.

    Vorher hatte ich je zwei am SF1200+HM800.
    Ich hab das Gefühl die Ausbeute war durch die OpenDTUonBatt besser, weniger ungewollte Einspeisung.

    Dazu kannst du die Regelwerte im JS-Skript ganz einfach anpassen und optimieren. Teste dafür mal die Parameter im Konfigurationsbereich:

    let intervalSec_outputLimit = 15; // Entladen frühestens nach X Sekunden. Standard: 15 s
    let intervalSec_inputLimit  = 20; // Laden frühestens nach X Sekunden. Standard: 20 s
    let chargingStep            = 50; // Schritte AC-Laden (z.B. 50 W, 100 W). Standard: 50 W
    let dischargeStep           = 10; // Schritte Entladen, wird aufgerundet. Standard: 10 W
    let wattChangeThreshold     = 20; // Hysterese Watt oder 15W testen
    let safetyReserve           = 20; // Sicherheitsreserve gegen Netzbezug beim Laden. Standard: 20 W
     
    let criticalGridPower        = 600;  // Ab wie viel Watt Netzbezug gilt es als hoher Leistungsabruf. Standard: 600 W
    let criticalOutputLimit      = 800; // Maximale Entladeleistung im Critical-Mode 
    let intervalSec_criticalMode = 30;   // So lange wird die Spitze gehalten (taktende Großverbraucher: Herd, Klima, Durchlauferhitzer)
     
    let intervalSec_change_acModeAllowed = 30; // Relais-Schutz z.B. 30s
    let batteryLockMinCellVoltage   = 3.20; // Entladesperre z.B. 3.20 V
    let batteryUnlockMinCellVoltage = 3.25; // Freigabe nach der Sperre sek
    let batteryRecoveryTimeSec      = 300;  // Beruhigungszeit der Zellen in Sekunden. Standard: 300 s (5 min)
     
    

    Subjektiv empfinde ich die Wechselrichter von Hoymiles ebenfalls um Welten besser als die integrierten Zendure-Inverter. Deswegen nutze ich inzwischen auch die gridOff-Steckdose bzw. Hoymiles direkt am Netz und lade/entlade die Zendure-Geräte ausschließlich über AC 230V.

    Trotz der zusätzlichen Wandlerverluste scheint das System inklusive der Regelung bei mir unterm Strich produktiver zu laufen, als die PV-Leistung direkt über DC in das Zendure-Gerät einzuspeisen.

    Auch wenn es theoretisch durch die Wandlungsverluste (DC ➔ AC ➔ DC ➔ AC) ineffizienter sein müsste, zeigt die Praxis bei mir, dass die exzellente MPPT-Regelung der Hoymiles und deren extrem niedrige Latenz anscheinend die träge Zendure-DC-Regelung ausstechen.

    Elektrotechnisch ist das eigentlich paradox und auf den ersten Blick schwer zu erklären – denn der direkte Weg über PV (DC) ➔ Laderegler ➔ Batterie (48V DC) müsste rein rechnerisch immer im Vorteil sein.
    Dennoch arbeiten hier völlig unterschiedliche Herstellerphilosophien auf Protokoll- und Hardwareebene gegeneinander, und in meiner Praxis bewährt sich die AC-Variante deutlich besser.


    @Daniel-8 sagte:

    Seit heute Nacht gibt es die Version 2.0.5
    Kann man die bedenkenlos installieren oder sollte man lieber noch ein bisschen abwarten?

    Die V2.0.5 kann ich für dein spezifisches Gerät – und auch allgemein – nicht beurteilen.
    Normalerweise fahre ich die Strategie: Abwarten.
    Wenn das System aktuell stabil läuft, gibt es keinen akuten Grund für Eile. Falls du jedoch gravierende Probleme im laufenden Betrieb hast, würde ich das Update vorziehen.
    Wenn alles unauffällig läuft: Lieber erst mal beobachten, was die Community berichtet.

    P
    P
    petman
    schrieb am zuletzt editiert von
    #619

    @maxclaudi sagte:

    Bitte verwende statt Blockly mal das JS-Script aus #Post 610
    Damit sollte der Batterieschutz übergeordnet greifen, falls die Firmware selbst einmal nicht rechtzeitig einlenkt.

    Dankeschön, habs eingepflegt und auf meine daten angepasst.
    Schaun mer mal...

    petman

    NUC mit Proxmox,VM's IOB, InfluxDB, Grafana, PiHole;
    Hitchi Lesekopf, jomjol AI-Device für Gas und Wasser;
    BKW, 4x485Wp, SF800Pro2, AB2000, AB2000L
    Insel: 2x430Wp, SF1200, HM800T

    1 Antwort Letzte Antwort
    0
    • maxclaudiM maxclaudi

      @petman sagte:

      @T-147
      ich hab den SF800pro2 mit 2.0.2, war schon bei der Erstinbetreiebnahme drauf, mitZwei AB2000, ein 2 Jahre alter und der vom SF800pro2
      Hatte letzte Woche auch "Tiefentladung" bis 2,56V(alter AB) bzw. 2,7V (neuerAB) am Morgen und er ist schon mehrfach im Einspeisemodus hängengeblieben aber bisher noch nie so Teifenladen. Ich musste dann eingreifen und aus dem Netz laden, was ich bisher vermieden habe weil vormittags keine Sonne. Als die Akkus wieder auf 20% waren hat er sich wieder gefangen und wieder normal gearbeitet.
      Ich habe das SDK-Skript und den Blockly von maxclaudi, 4x 450Wp OSO/WNW, je eins an einem MPT.

      Bitte verwende statt Blockly mal das JS-Script aus #Post 610
      Damit sollte der Batterieschutz übergeordnet greifen, falls die Firmware selbst einmal nicht rechtzeitig einlenkt.

      Vorher hatte ich je zwei am SF1200+HM800.
      Ich hab das Gefühl die Ausbeute war durch die OpenDTUonBatt besser, weniger ungewollte Einspeisung.

      Dazu kannst du die Regelwerte im JS-Skript ganz einfach anpassen und optimieren. Teste dafür mal die Parameter im Konfigurationsbereich:

      let intervalSec_outputLimit = 15; // Entladen frühestens nach X Sekunden. Standard: 15 s
      let intervalSec_inputLimit  = 20; // Laden frühestens nach X Sekunden. Standard: 20 s
      let chargingStep            = 50; // Schritte AC-Laden (z.B. 50 W, 100 W). Standard: 50 W
      let dischargeStep           = 10; // Schritte Entladen, wird aufgerundet. Standard: 10 W
      let wattChangeThreshold     = 20; // Hysterese Watt oder 15W testen
      let safetyReserve           = 20; // Sicherheitsreserve gegen Netzbezug beim Laden. Standard: 20 W
       
      let criticalGridPower        = 600;  // Ab wie viel Watt Netzbezug gilt es als hoher Leistungsabruf. Standard: 600 W
      let criticalOutputLimit      = 800; // Maximale Entladeleistung im Critical-Mode 
      let intervalSec_criticalMode = 30;   // So lange wird die Spitze gehalten (taktende Großverbraucher: Herd, Klima, Durchlauferhitzer)
       
      let intervalSec_change_acModeAllowed = 30; // Relais-Schutz z.B. 30s
      let batteryLockMinCellVoltage   = 3.20; // Entladesperre z.B. 3.20 V
      let batteryUnlockMinCellVoltage = 3.25; // Freigabe nach der Sperre sek
      let batteryRecoveryTimeSec      = 300;  // Beruhigungszeit der Zellen in Sekunden. Standard: 300 s (5 min)
       
      

      Subjektiv empfinde ich die Wechselrichter von Hoymiles ebenfalls um Welten besser als die integrierten Zendure-Inverter. Deswegen nutze ich inzwischen auch die gridOff-Steckdose bzw. Hoymiles direkt am Netz und lade/entlade die Zendure-Geräte ausschließlich über AC 230V.

      Trotz der zusätzlichen Wandlerverluste scheint das System inklusive der Regelung bei mir unterm Strich produktiver zu laufen, als die PV-Leistung direkt über DC in das Zendure-Gerät einzuspeisen.

      Auch wenn es theoretisch durch die Wandlungsverluste (DC ➔ AC ➔ DC ➔ AC) ineffizienter sein müsste, zeigt die Praxis bei mir, dass die exzellente MPPT-Regelung der Hoymiles und deren extrem niedrige Latenz anscheinend die träge Zendure-DC-Regelung ausstechen.

      Elektrotechnisch ist das eigentlich paradox und auf den ersten Blick schwer zu erklären – denn der direkte Weg über PV (DC) ➔ Laderegler ➔ Batterie (48V DC) müsste rein rechnerisch immer im Vorteil sein.
      Dennoch arbeiten hier völlig unterschiedliche Herstellerphilosophien auf Protokoll- und Hardwareebene gegeneinander, und in meiner Praxis bewährt sich die AC-Variante deutlich besser.


      @Daniel-8 sagte:

      Seit heute Nacht gibt es die Version 2.0.5
      Kann man die bedenkenlos installieren oder sollte man lieber noch ein bisschen abwarten?

      Die V2.0.5 kann ich für dein spezifisches Gerät – und auch allgemein – nicht beurteilen.
      Normalerweise fahre ich die Strategie: Abwarten.
      Wenn das System aktuell stabil läuft, gibt es keinen akuten Grund für Eile. Falls du jedoch gravierende Probleme im laufenden Betrieb hast, würde ich das Update vorziehen.
      Wenn alles unauffällig läuft: Lieber erst mal beobachten, was die Community berichtet.

      Murphy 0M
      Murphy 0M
      Murphy 0
      schrieb am zuletzt editiert von
      #620

      @maxclaudi sagte:
      Subjektiv empfinde ich die Wechselrichter von Hoymiles ebenfalls um Welten besser als die integrierten Zendure-Inverter. Deswegen nutze ich inzwischen auch die gridOff-Steckdose bzw. Hoymiles direkt am Netz und lade/entlade die Zendure-Geräte ausschließlich über AC 230V.

      Benutze auch meine Hoymiles weiter und lade rein AC-seitig.
      Der Hyper kann im Keller stehen und meine Steuerung per Blockly bleibt überschaubar.

      Win Win Win sozusagen.

      1 Antwort Letzte Antwort
      1
      • D Daniel 8

        @maxclaudi sagte:

        Subjektiv empfinde ich die Wechselrichter von Hoymiles ebenfalls um Welten besser als die integrierten Zendure-Inverter. Deswegen nutze ich inzwischen auch die gridOff-Steckdose bzw. Hoymiles direkt am Netz und lade/entlade die Zendure-Geräte ausschließlich über AC 230V.

        Trotz der zusätzlichen Wandlerverluste scheint das System inklusive der Regelung bei mir unterm Strich produktiver zu laufen, als die PV-Leistung direkt über DC in das Zendure-Gerät einzuspeisen.

        Auch wenn es theoretisch durch die Wandlungsverluste (DC ➔ AC ➔ DC ➔ AC) ineffizienter sein müsste, zeigt die Praxis bei mir, dass die exzellente MPPT-Regelung der Hoymiles und deren extrem niedrige Latenz anscheinend die träge Zendure-DC-Regelung ausstechen.

        Von wieviel Mehrertrag reden wir denn da? Macht das wirklich soviel aus?

        maxclaudiM
        maxclaudiM
        maxclaudi
        schrieb am zuletzt editiert von maxclaudi
        #621

        @Daniel-8 sagte:
        Von wieviel Mehrertrag reden wir denn da? Macht das wirklich soviel aus?

        Naja, vielleicht ist es auf den ersten Blick nicht so relevant, in der täglichen Praxis summiert es sich dann aber doch.

        Meine bisherigen Beobachtungen dazu:
        Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

        Die Hoymiles-Wechselrichter starten im Vergleich deutlich schneller. Sie speisen selbst bei minimalen Wattwerten bereits ein.
        Laut Datenblatt liegt die Einschaltspannung des HM-1200 und HM-400 bei gerade einmal 22 V, während der eigentliche Betriebsspannungsbereich sogar schon ab 16 V beginnt.
        Gerade zum Abend hin speisen die Hoymiles dadurch noch absolut zuverlässig Kleinstmengen ein (z. B. 6 W), wenn die Trägheit der Zendure-Regelung schon längst im Standby wäre.
        Das MPPT-Tracking der Hoymiles arbeitet meiner Meinung nach um Welten präziser und „holt einfach mehr raus“ – und das jeden Tag aufs Neue.

        Wenn das Zendure-Gerät per Skript also ausschließlich über AC geladen und entladen wird, fängt die exzellente Latenz der Hoymiles die theoretischen Wandlungsverluste (DC ➔ AC ➔ DC ➔ AC) in der Realität locker wieder auf.

        Da kommen über das Jahr gerechnet definitiv einige Kilowattstunden zusammen!

        Ich möchte und werde Zendure hier keineswegs schlecht reden.
        Es ist schlicht meine persönliche Erfahrung bei meinem spezifischen Setup und Standort.
        Gerade im Frühjahr, Herbst und Winter habe ich hier durch ein höheres Nachbarhaus und den tieferen Stand der Sonne mit schwierigen Verschattungen zu kämpfen.
        Aber insgesamt sind die Wechselrichter von Hoymiles und deren MPPT-Regelung meiner Meinung nach in solchen Szenarien einfach überlegen.

        Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

        Zendure wie 2400 AC Pro lokale IP statt Cloud: zURLtool

        D T 2 Antworten Letzte Antwort
        0
        • maxclaudiM maxclaudi

          @Daniel-8 sagte:
          Von wieviel Mehrertrag reden wir denn da? Macht das wirklich soviel aus?

          Naja, vielleicht ist es auf den ersten Blick nicht so relevant, in der täglichen Praxis summiert es sich dann aber doch.

          Meine bisherigen Beobachtungen dazu:
          Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

          Die Hoymiles-Wechselrichter starten im Vergleich deutlich schneller. Sie speisen selbst bei minimalen Wattwerten bereits ein.
          Laut Datenblatt liegt die Einschaltspannung des HM-1200 und HM-400 bei gerade einmal 22 V, während der eigentliche Betriebsspannungsbereich sogar schon ab 16 V beginnt.
          Gerade zum Abend hin speisen die Hoymiles dadurch noch absolut zuverlässig Kleinstmengen ein (z. B. 6 W), wenn die Trägheit der Zendure-Regelung schon längst im Standby wäre.
          Das MPPT-Tracking der Hoymiles arbeitet meiner Meinung nach um Welten präziser und „holt einfach mehr raus“ – und das jeden Tag aufs Neue.

          Wenn das Zendure-Gerät per Skript also ausschließlich über AC geladen und entladen wird, fängt die exzellente Latenz der Hoymiles die theoretischen Wandlungsverluste (DC ➔ AC ➔ DC ➔ AC) in der Realität locker wieder auf.

          Da kommen über das Jahr gerechnet definitiv einige Kilowattstunden zusammen!

          Ich möchte und werde Zendure hier keineswegs schlecht reden.
          Es ist schlicht meine persönliche Erfahrung bei meinem spezifischen Setup und Standort.
          Gerade im Frühjahr, Herbst und Winter habe ich hier durch ein höheres Nachbarhaus und den tieferen Stand der Sonne mit schwierigen Verschattungen zu kämpfen.
          Aber insgesamt sind die Wechselrichter von Hoymiles und deren MPPT-Regelung meiner Meinung nach in solchen Szenarien einfach überlegen.

          D
          D
          Daniel 8
          schrieb am zuletzt editiert von
          #622

          @maxclaudi sagte:

          Naja, vielleicht ist es auf den ersten Blick nicht so relevant, in der täglichen Praxis summiert es sich dann aber doch.

          Meine bisherigen Beobachtungen dazu:
          Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

          Vielen Dank für deine Meinung.
          Da ich aber keinen zur Hand habe und erst einen kaufen müsste, muss man viele kw einsparen bis dieser bezahlt ist.

          Zudem müsste ich ja um das ganze dann per ac zu laden auch einen größeren nehmen als die erlaubten 800 watt. Sonst würde mir ja das ganze auch nichts bringen.

          Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno

          maxclaudiM 1 Antwort Letzte Antwort
          0
          • D Daniel 8

            @maxclaudi sagte:

            Naja, vielleicht ist es auf den ersten Blick nicht so relevant, in der täglichen Praxis summiert es sich dann aber doch.

            Meine bisherigen Beobachtungen dazu:
            Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

            Vielen Dank für deine Meinung.
            Da ich aber keinen zur Hand habe und erst einen kaufen müsste, muss man viele kw einsparen bis dieser bezahlt ist.

            Zudem müsste ich ja um das ganze dann per ac zu laden auch einen größeren nehmen als die erlaubten 800 watt. Sonst würde mir ja das ganze auch nichts bringen.

            maxclaudiM
            maxclaudiM
            maxclaudi
            schrieb zuletzt editiert von
            #623

            @Daniel-8 sagte:
            Da ich aber keinen zur Hand habe und erst einen kaufen müsste, muss man viele kw einsparen bis dieser bezahlt ist.

            Völlig richtig, das steht außer Frage.
            Es war ja auch lediglich die Beschreibung meines spezifischen Setups, da bei mir die Hoymiles-Wechselrichter ohnehin schon vorhanden waren.
            Wenn man alles neu kaufen muss, sieht die Rechnung natürlich anders aus.

            Zudem müsste ich ja um das ganze dann per ac zu laden auch einen größeren nehmen als die erlaubten 800 watt. Sonst würde mir ja das ganze auch nichts bringen.

            Das verstehe ich ehrlich gesagt nicht ganz, denn es gibt ja verschiedene Kombinationsmöglichkeiten.

            Ein AC-Laden mit konstanter, gleichmäßiger Leistung ist oft wesentlich effizienter, energetisch stabiler und materialschonender, als die Batterie über PV-DC bei ständig wechselnder Bewölkung und permanent schwankenden Wattwerten zu füttern.
            Genau aus diesem Grund integriert man in sinnvolle Steuerungen ja auch Parameter wie eine Mindestdauer für den acMode (Relais-Schutz).

            Zudem könnte man das System ja auch als Hybrid betreiben:
            Einige wenige PV-Module, die z. B. „Problemkinder“ sind (geringere Leistung haben oder öfter verschattet werden), können oder bleiben einfach an den reinen DC-PV-Eingängen des SolarFlow angeschlossen.
            Die starken, unverschatteten Module laufen parallel über den Hoymiles.

            Der SolarFlow 800 Pro kann kontinuierlich mit bis zu 1000 W AC geladen werden – das ist für ein herkömmliches Balkonkraftwerk mehr als genug.
            Die maximale Ausgangsleistung ist gesetzlich ohnehin auf 800 W begrenzt.

            In meiner Praxis speise ich – abgesehen von kurzzeitigen Lastspitzen im criticalMode – eigentlich fast wie nie mehr als ca. ~500 W gleichzeitig ein.
            Das hängt am Ende natürlich immer vom individuellen Grundverbrauch und der Personenanzahl im Haushalt ab.

            Ein E-Auto-Lademanagement rechnet sich bei so kleinen Systemen aber im Regelfall sowieso fast nie.

            Letzten Endes hängt – wie immer – alles vom einzelnen, spezifischen Setup, den vorhandenen, realen Gegebenheiten und den persönlichen Anforderungen ab.
            Eine generelle Empfehlung ist deshalb nie möglich – nur Ratschläge und Ideen, was wie funktionieren könnte.

            Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

            Zendure wie 2400 AC Pro lokale IP statt Cloud: zURLtool

            1 Antwort Letzte Antwort
            1
            • D Daniel 8

              Seit heute Nacht gibt es die Version 2
              0.5 Kann man die bedenkenlos installieren oder sollte man lieber noch ein bisschen abwarten?

              T
              T
              T-147
              schrieb zuletzt editiert von
              #624

              @Daniel-8 sagte:

              Seit heute Nacht gibt es die Version 2
              0.5 Kann man die bedenkenlos installieren oder sollte man lieber noch ein bisschen abwarten?

              Nachdem ich bei Firmware 2.0.2 immer wieder den Fehler 33 bekam (wurde mittlerweile vom Zendure-Support als Firmware-Fehler bestätigt) kam mir das Update gestern morgen sehr gelegen.
              Ich nehm zwar ungern immer direkt die neueste Firmware, aber hier bleib mir nicht viel anderes übrig.
              Wenn man mit der installierten Firmware keine Probleme hat oder nicht unbedingt ein neues Feature erwartet/benötigt, sollte man mMn immer etwas mit dem Update warten.

              Bislang läuft mein SF800 Pro2 mit 2.0.5 ohne Auffälligkeiten und Probleme, auch mit dem ZenSDK-Script und der Nulleinspeisung von Maxclaudi (aktuell noch nicht die neueste Version, die mach ich heute erst bereit)

              1 Antwort Letzte Antwort
              0
              • maxclaudiM maxclaudi

                @Daniel-8 sagte:
                Von wieviel Mehrertrag reden wir denn da? Macht das wirklich soviel aus?

                Naja, vielleicht ist es auf den ersten Blick nicht so relevant, in der täglichen Praxis summiert es sich dann aber doch.

                Meine bisherigen Beobachtungen dazu:
                Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

                Die Hoymiles-Wechselrichter starten im Vergleich deutlich schneller. Sie speisen selbst bei minimalen Wattwerten bereits ein.
                Laut Datenblatt liegt die Einschaltspannung des HM-1200 und HM-400 bei gerade einmal 22 V, während der eigentliche Betriebsspannungsbereich sogar schon ab 16 V beginnt.
                Gerade zum Abend hin speisen die Hoymiles dadurch noch absolut zuverlässig Kleinstmengen ein (z. B. 6 W), wenn die Trägheit der Zendure-Regelung schon längst im Standby wäre.
                Das MPPT-Tracking der Hoymiles arbeitet meiner Meinung nach um Welten präziser und „holt einfach mehr raus“ – und das jeden Tag aufs Neue.

                Wenn das Zendure-Gerät per Skript also ausschließlich über AC geladen und entladen wird, fängt die exzellente Latenz der Hoymiles die theoretischen Wandlungsverluste (DC ➔ AC ➔ DC ➔ AC) in der Realität locker wieder auf.

                Da kommen über das Jahr gerechnet definitiv einige Kilowattstunden zusammen!

                Ich möchte und werde Zendure hier keineswegs schlecht reden.
                Es ist schlicht meine persönliche Erfahrung bei meinem spezifischen Setup und Standort.
                Gerade im Frühjahr, Herbst und Winter habe ich hier durch ein höheres Nachbarhaus und den tieferen Stand der Sonne mit schwierigen Verschattungen zu kämpfen.
                Aber insgesamt sind die Wechselrichter von Hoymiles und deren MPPT-Regelung meiner Meinung nach in solchen Szenarien einfach überlegen.

                T
                T
                T-147
                schrieb zuletzt editiert von T-147
                #625

                @maxclaudi sagte:
                Meine bisherigen Beobachtungen dazu:
                Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

                Ich hab hier den SF800 Pro2, der fängt morgens schon ab 10W Gesamtleistung (über alle 4 Panels/MPPT) an zu laden. In meinem Fall und Setuo scheint sich die deutlich niedrigere Start-Spannung von Zendure im Vergleich zu meinem HMS-1000 auszuzahlen.
                Vor allem, da meine 4 Panels in SO und SW ausgerichtet sind und ich wie Du (in SO-Richtung) in der dunkleren Jahreshälfte mit Verschattung durchs Nachbarhaus zu kämpfen hab.
                Den HMS-1000 werd ich jetzt mit einem zusätzlichen Panel in Richtung S an die Offgrid-Dose hängen. Mal sehen, was das über den Winter an Mehrertrag bringt.

                Leider lassen sich die Geräte von Zendure nicht so detailliert auslesen, wie die Hoymiles über eine OpenDTU zB, daher kann ich leider aus meinen Daten keine echten, direkten Vergleich herstellen.

                maxclaudiM 1 Antwort Letzte Antwort
                0
                • T T-147

                  @maxclaudi sagte:
                  Meine bisherigen Beobachtungen dazu:
                  Die Zendure-Geräte lassen sich (zumindest bei meinen Modellen) relativ viel Zeit, bevor sie mit dem Einspeisen oder dem Laden der Batterie beginnen. Teils reagieren sie erst ab einer Leistung von ≥ 40 W.

                  Ich hab hier den SF800 Pro2, der fängt morgens schon ab 10W Gesamtleistung (über alle 4 Panels/MPPT) an zu laden. In meinem Fall und Setuo scheint sich die deutlich niedrigere Start-Spannung von Zendure im Vergleich zu meinem HMS-1000 auszuzahlen.
                  Vor allem, da meine 4 Panels in SO und SW ausgerichtet sind und ich wie Du (in SO-Richtung) in der dunkleren Jahreshälfte mit Verschattung durchs Nachbarhaus zu kämpfen hab.
                  Den HMS-1000 werd ich jetzt mit einem zusätzlichen Panel in Richtung S an die Offgrid-Dose hängen. Mal sehen, was das über den Winter an Mehrertrag bringt.

                  Leider lassen sich die Geräte von Zendure nicht so detailliert auslesen, wie die Hoymiles über eine OpenDTU zB, daher kann ich leider aus meinen Daten keine echten, direkten Vergleich herstellen.

                  maxclaudiM
                  maxclaudiM
                  maxclaudi
                  schrieb zuletzt editiert von
                  #626

                  @T-147 sagte:
                  Ich hab hier den SF800 Pro2, der fängt morgens schon ab 10W Gesamtleistung (über alle 4 Panels/MPPT) an zu laden. In meinem Fall und Setuo scheint sich die deutlich niedrigere Start-Spannung von Zendure im Vergleich zu meinem HMS-1000 auszuzahlen.

                  Meiner Meinung nach sitzt du da leider einem kleinen Mess- bzw. Anzeigefehler auf, was die realen physikalischen Abläufe angeht.

                  Die SolarFlow 800er-Pro-Serie hat die Steuerelektronik, die 4 MPPT-Regler und den Wechselrichter komplett in einem Gehäuse integriert.
                  Dieses Gesamtsystem (inklusive ESP32-Chip, WLAN, Bluetooth und Batterie-Management-System) hat einen permanenten, spürbaren Eigenverbrauch für den reinen Betrieb.

                  Wenn dir die App am Morgen anzeigt, dass mit "10 W" geladen wird, bedeutet das rein physikalisch folgendes:
                  Deine PV-Module müssen zu diesem Zeitpunkt bereits den kompletten internen Grundverbrauch des Geräts (für CPU, WLAN, BMS-Aktivierung etc.) gedeckt haben. Erst die Leistung, die darüber hinausgeht, bleibt netto übrig und wandert als die von dir gesehenen 10 W in die Batterie.

                  Man darf hier die reine Startspannung der MPPT-Tracker (die beim Pro 2 erfreulicherweise schon ab 14 V liegt) nicht mit der notwendigen Mindestleistung für den Systembetrieb verwechseln.
                  Ohne dass die PV-Leistung die interne Grundlast des Speichers vorab komplett kompensiert, kann das Gerät weder einspeisen noch laden.
                  Die Solarmodule müssen real also schon deutlich mehr als 10 W liefern, damit das System überhaupt aus dem Standby erwacht.

                  Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

                  Zendure wie 2400 AC Pro lokale IP statt Cloud: zURLtool

                  T 1 Antwort Letzte Antwort
                  0
                  • maxclaudiM maxclaudi

                    @T-147 sagte:
                    Ich hab hier den SF800 Pro2, der fängt morgens schon ab 10W Gesamtleistung (über alle 4 Panels/MPPT) an zu laden. In meinem Fall und Setuo scheint sich die deutlich niedrigere Start-Spannung von Zendure im Vergleich zu meinem HMS-1000 auszuzahlen.

                    Meiner Meinung nach sitzt du da leider einem kleinen Mess- bzw. Anzeigefehler auf, was die realen physikalischen Abläufe angeht.

                    Die SolarFlow 800er-Pro-Serie hat die Steuerelektronik, die 4 MPPT-Regler und den Wechselrichter komplett in einem Gehäuse integriert.
                    Dieses Gesamtsystem (inklusive ESP32-Chip, WLAN, Bluetooth und Batterie-Management-System) hat einen permanenten, spürbaren Eigenverbrauch für den reinen Betrieb.

                    Wenn dir die App am Morgen anzeigt, dass mit "10 W" geladen wird, bedeutet das rein physikalisch folgendes:
                    Deine PV-Module müssen zu diesem Zeitpunkt bereits den kompletten internen Grundverbrauch des Geräts (für CPU, WLAN, BMS-Aktivierung etc.) gedeckt haben. Erst die Leistung, die darüber hinausgeht, bleibt netto übrig und wandert als die von dir gesehenen 10 W in die Batterie.

                    Man darf hier die reine Startspannung der MPPT-Tracker (die beim Pro 2 erfreulicherweise schon ab 14 V liegt) nicht mit der notwendigen Mindestleistung für den Systembetrieb verwechseln.
                    Ohne dass die PV-Leistung die interne Grundlast des Speichers vorab komplett kompensiert, kann das Gerät weder einspeisen noch laden.
                    Die Solarmodule müssen real also schon deutlich mehr als 10 W liefern, damit das System überhaupt aus dem Standby erwacht.

                    T
                    T
                    T-147
                    schrieb zuletzt editiert von
                    #627

                    @maxclaudi
                    Klingt plausibel.
                    Danke für den Hinweis, soweit hab ich natürlich nicht gedacht.

                    1 Antwort Letzte Antwort
                    0
                    • maxclaudiM maxclaudi

                      07.10.2026_21:20h

                      Da es dazu weltweit quasi null Infos gibt, dachte ich, ich teile meine bisherigen Erkenntnisse mal auszugsweise als kleinen Bericht mit euch.

                      Wer möchte kann den Bericht im spoiler lesen, für alle anderen ist der Beitrag dann kürzer und kann ignoriert werden :-)

                      Wie ich bereits geschrieben habe, gibt es einen Weg, um sich über Port: 1883 (ohne TLS) per MQTT zu verbinden.

                      Wenn die Verbindung steht, ist die MQTT-Struktur identisch.

                      Es gibt jedoch zwei entscheidende Unterschiede:

                      1. Fehlende automatische Reports
                      Sie finden weder über einen Timer alle x Sekunden statt, noch werden sie bei geräteinternen Wertänderungen gesendet.
                      Ein Report wird vom Gerät hier nicht automatisch alle X Sekunden abgesetzt – auch nicht, wenn sich intern im Gerät das energyLevel oder die Werte der daran angeschlossenen PV-Module und Batterien (wie solarInputPower, minVol etc.) ändern.

                      Das ist aktuell (noch) ein großes Manko für mich.

                      Es wird nur dann sehr schnell und sofort ein Report vom Gerät gesendet, wenn explizit vom Broker oder von einem anderen Gerät per MQTT ein externer Befehl beim Gerät eingeht.

                      Das funktioniert beispielsweise über ein getAll als Lesebefehl über das herkömmliche Topic:

                      iot/productId/deviceId/properties/read
                      

                      oder über einen Schreibbefehl bei den (un)bekannten Topics.

                      Von "allein" informiert das Gerät hier nicht über das gewohnte Topic:

                      /productId/deviceId/properties/report
                      

                      Ich hoffe einen Weg zu finden, das zu automatisieren bzw. einen Aufrufer zu finden, der den Report extern auslöst.

                      Vielleicht gibt es ein Command etc., um ein Flag zu setzen, damit bei dieser Verbindung über MQTT vom Gerät sofort ein Report-Payload gesendet wird, wenn sich intern ein Parameter ändert (vorzugsweise die Parameter der Batterien, der PV-Leistung, Spannungen, Energielevel etc.).

                      Was regulär vom Gerät automatisch, öfter und schneller aktualisiert wird, ist das Log-Topic:

                      /productId/deviceId/log
                      

                      Das wird bei einer geräteinternen Wertänderung schneller automatisch gesendet, aber nicht sofort wie bei einem Report.

                      Ansonsten wird log durch einen Timer alle 7700ms gesendet.
                      Genauso wie bei TLS-Verbindungen, wobei bei TLS-Verbindungen häufig Abweichungen festzustellen sind.
                      Bei TLS 8883 sind es auch 7700ms, jedoch immer wieder benötigt ein weiteres log dann auch mal 55000~ 67000ms.
                      8883 liefert, auch wenn es keine große Änderungen gibt durch einen Timer alle 5000ms ein report.
                      Das ist bei 1883 - bei mir bisher - nicht so.

                      Das Log liefert eigentlich alle relevanten Daten.
                      Für das Log fehlt mir noch das vollständige Mapping und unterscheidet sich etwas zu den älteren Gerätegenerationen.
                      Es ist ein CSV-Format, allerdings ohne Keys.
                      Dieses CSV ist bei allen neueren Geräten mit einer Firmware-Version größer als 1.6.x identisch bzw. ab api 3.

                      Das Log wird auch bei Eurer Verbindung übertragen.
                      Vielleicht möchte jemand bei einem Mapping behilflich sein.

                      Die Suche nach dem Aufrufer, der den Report extern auslöst ist, sehr, sehr harte Arbeit.
                      Ich versuche gerade, mögliche Callbacks auszuwerten und zu vergleichen, wie sich die Wege unterscheiden.

                      Ein aktueller Workaround ist Polling:
                      Ein Trigger auf log, der ein Publish mit getAll auslöst.

                      Das funktioniert einwandfrei und extrem schnell.
                      Eigentlich das was zenSDK macht und m. M. n. für MQTT nicht üblich ist.

                      ABER: Das ist nicht das Ziel.
                      Ich möchte unbedingt, dass ein MQTT-Publish sofort als Report gesendet wird – nicht wie bisher nur auf externen Befehl, sondern auch sofort, wenn intern eine Wertänderung erkannt wird (wie gewohnt bei z. B. solarInputPower).

                      Abgesehen davon funktioniert alles besser und viel schneller.
                      Es gab keinen einzigen Reconnect seit der ersten Verbindung.

                      Der TLS-Ballast kommt im RAM nicht zum Einsatz, und einiges andere ebenfalls nicht.

                      Das System läuft ruhiger und reagiert deutlich schneller.
                      Subjektiv denke ich, dass WiFi-Verbindung besser ist.

                      Mosquitto agiert als Bridge und ist zur Cloud verbunden.
                      HEMS ist deaktiviert und localAPIEnable steht auf true.

                      Bisher hat die Cloud nichts weiter getan, als die Zeit zu synchronisieren.

                      2. Erweiterte Limits im devMode
                      (ich nenne ihn jetzt einfach "devMode" was nicht exakt stimmt, aber lesbarer ist)

                      Vorweg: Ich werde keine Firmware modifizieren. Sie wird immer original bleiben.
                      Ich analysiere nur und versuche Wege zu finden, die herstellerseitig vorgesehen sind und einfach genutzt werden können.
                      Quasi einfache Konfiguration - Möglichkeiten.
                      Es handelt sich hierbei um eine Verbindung, die vermutlich nur für eine Werksverbindung oder Service-Verbindung verwendet wird.

                      Anscheinend werden im devMode einige Sperren ausgehebelt - zumindest großzügiger gemacht - oder Limits erweitert.

                      Beispiele hierfür:

                      • minSoc: Kann gefahrlos von 5 bis 95 % gesetzt werden (theoretisch bis 100%, was ich vorsichtshalber aber nicht teste).

                      • socSet: Kann gefahrlos von 5 bis 100 % gesetzt werden, solange socSet > minSoc ist (theoretisch von 0 bis 100 %, aber auch das teste ich sicherheitshalber nicht).

                      siehe Bild

                      image.jpeg

                      Alles läuft stabil, schnell und - mit Ausnahme der beschriebenen automatischen Reports, dem ich intensiv nachgehe - zu meiner vollen Zufriedenheit.
                      In einem Timer habe ich bereits eine viel versprechende Variable gefunden. Mal weiter verfolgen.

                      Sollte es keinen Weg geben oder nicht gefunden werden, dann werde ich - wie bei zenSDK - pollen aber über MQTT.

                      Warum nicht zenSDK verwenden?

                      Würde ich ehrlich gesagt sofort. Vielleicht wird das auch so werden.
                      Aber aktuell - um nur ein Beispiel zu nennen:
                      Über devMode kann socSet tiefer gesetzt werden als 70%.
                      Dadurch kann ich indirekt bestimmen, wann das Gerät in den Bypass geht oder nicht.

                      Für mich sind jetzt hauptsächlich zwei Dinge interessant:

                      1. Das Log einem korrekten Mapping zuzuordnen.

                      2. Die unglaublich vielen Stellen im Code zu analysieren, um eventuell ein zugängliches Flag etc. zu finden, welches dafür sorgt, dass künftig bei einer internen Wertänderung ein automatisches Publish ausgeführt wird.
                        Es ist unglaublich schwer zu finden, da es mehrere Verbindungswege gibt, die unterschiedlich abzweigen und teils identische, teils verschiedene Callbacks ausführen.

                      Sollte ich erreichen, dass report automatisch bei Änderung eines Wertes ein publish auslöst und der 5000ms Timer auch anspringt, dann wäre ich vorerst wunschlos glücklich - mit V2.0.2

                      Wer sich bedanken möchte, weiß ja, wo der Voting-Button ist. Ein extra Post dafür muss nicht sein. ;-)

                      maxclaudiM
                      maxclaudiM
                      maxclaudi
                      schrieb zuletzt editiert von maxclaudi
                      #628

                      15.10.2026; 16:00h Weiterer Bericht zum Betrieb über MQTT-Port 1883 und zenSDK

                      Fortsetzung von:

                      Da es dazu weltweit quasi null Infos gibt, dachte ich, ich teile meine bisherigen Erkenntnisse mal auszugsweise als kleinen Bericht mit euch.

                      Wer möchte kann den Bericht im spoiler lesen, für alle anderen ist der Beitrag dann kürzer und kann ignoriert werden

                      MQTT-Port 1883: Verbindung mit neuen Zendure-Geräten und zenSDK

                      Wenn das Zendure-Gerät über den unverschlüsselten MQTT-Port 1883 gekoppelt ist, läuft das lokale zenSDK-Skript über HTTP spürbar stabiler und reagiert subjektiv deutlich schneller.
                      In meinen Testreihen war ein HTTP-Polling im 3000-ms-Takt absolut problemlos und lückenlos möglich.

                      Im produktiven Betrieb ist ein so schnelles Intervall allerdings sinnfrei.
                      Es ist besser, das Polling bei ≥ 4000 ms zu belassen.
                      Das schont das Netzwerk (Traffic), die Netzwerk-Ressourcen des ESP32 und verhindert das hardwarebedingte Empfangen von identischen Altwerten.

                      Bei meinem aktuellen Test wird keine MQTT-Steuerung/Regelung verwendet. Die gesamte Steuerung erfolgt exklusiv über das zenSDK mittels HTTP-Befehlen aus dem Skript dieses Threads.

                      Über die unverschlüsselte MQTT-Schnittstelle (Port 1883) sende ich lediglich in einem festen Intervall eine minimale Abfrage, um die MQTT-Verbindung im Hintergrund aktiv zu halten.
                      Realisiert durch ein Mini-Skript (ein kleines Blockly ist auch kein Problem), das im festen Intervall den MQTT-Adapter-Datenpunkt mit der stets gleichen Abfrage senden lässt.

                      Für meine eigenen Testreihen habe ich das Skript lediglich um ein paar zusätzliche Helper-Funktionen zum Debuggen erweitert.

                      Genialer Nebeneffekt:
                      Über das zenSDK lassen sich plötzlich auch die erweiterten Limits für minSoc (0–95 %) und socSet (6–100 %) völlig frei einstellen und stabil nutzen.
                      Im herkömmlichen Normalbetrieb über TLS auf Port 8883 sperrt sich die Firmware hier bekanntlich strikt; Werte für socSet unter 70 % sind dort gar nicht möglich.

                      Es sollte aber zwingend darauf geachtet werden, dass der eingestellte minSoc-Wert stets kleiner ist als der socSet-Wert.

                      Ich werde wohl das Skript für mich noch um eine integrierte Schutzlogik erweitern:
                      Sollte diese Bedingung nicht erfüllt sein, wird der Schreibbefehl blockiert.
                      Zudem möchte ich, dass z. B. socSet immer mindestens 2 % höher liegen soll als minSoc, um unlogische Hystereseschleifen der Hardware zu vermeiden.

                      Durch ein niedrigeres socSet funktioniert auch weiterhin alles stabil, wie die Erkennung von socLimit und dass der Bypass (pass) mit socSet indirekt gesteuert werden kann – z. B. dass der Bypass automatisch früher ein- oder ausgeschaltet wird.

                      Befund:
                      Der allseits bekannte und nervige energyLevel- bzw. SoC-Bug (plötzliche Sprünge oder Einfrieren der Prozentwerte) tritt in diesem unverschlüsselten Setup bei mir bisher nicht auf.

                      Es ist möglich, über MQTT, das HTTP-zenSDK und Bluetooth-Properties zu regeln.
                      Alle drei Steuerungsmöglichkeiten sind bzw. wären sogar simultan möglich.

                      MQTT bietet mehr bzw. alle Möglichkeiten, die aber eigentlich nicht für den normalen, lokalen Betrieb nötig sind.

                      Richtet man den Broker zusätzlich als Bridge zur Cloud ein, kann die App weiter verwendet werden.
                      HEMS ist bei mir (bis jetzt) dauerhaft deaktiviert.
                      Außer für eine Zeitsynchronisation hat die Cloud bisher nicht in das System eingegriffen.

                      PS: Ich suche immer noch 1 Tester.

                      Außer einer DNS-Umleitung und der Zendure-App wird nichts benötigt für einen lokalen Betrieb über MQTT-Port 1883.
                      Keine weiteren Tools etc.
                      Um Bots oder Fake-Anfragen auszuschließen, ist ein bestehender Account im ioBroker-Forum oder einem etablierten PV-Forum erforderlich.
                      Interessierte ohne Foren-Historie können leider nicht berücksichtigt werden.
                      Jedes aktive Mitglied – egal ob Profi oder Einsteiger – ist herzlich willkommen!
                      Bei Interesse bitte einfach per PM oder E-Mail melden.

                      Eine Steuerung funktioniert über das zenSDK wie bisher oder auch über MQTT.
                      Allerdings ist man dann von der Cloud befreit, und ohne Bridge funktioniert die App dann natürlich nicht mehr.

                      Wer sich bedanken möchte, weiß ja, wo der Voting-Button ist. Ein extra Post dafür muss nicht sein. ;-)

                      Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

                      Zendure wie 2400 AC Pro lokale IP statt Cloud: zURLtool

                      1 Antwort Letzte Antwort
                      2

                      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 Anmelden
                      Antworten
                      • In einem neuen Thema antworten
                      Anmelden zum Antworten
                      • Älteste zuerst
                      • Neuste zuerst
                      • Meiste Stimmen


                      Support us

                      ioBroker
                      Community Adapters
                      Donate

                      512

                      Online

                      33.1k

                      Benutzende

                      84.0k

                      Themen

                      1.4m

                      Beiträge
                      Community
                      Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                      ioBroker Community 2014-2026
                      logo
                      • Anmelden

                      • Du hast noch kein Konto? Registrieren

                      • Anmelden oder registrieren, um zu suchen
                      • Erster Beitrag
                        Letzter Beitrag
                      0
                      • Home
                      • Aktuell
                      • Ungelesen 0
                      • Kategorien
                      • Unreplied
                      • Beliebt
                      • GitHub
                      • Docu
                      • Hilfe