Test Adapter Zendure Solarflow

maxclaudi

@nograx sagte in Test Adapter Zendure Solarflow:

@rene55 sagte in Test Adapter Zendure Solarflow:

@nograx Jetzt ist ja die Version 2.0.1 im Stable. Kann/soll ich das jetzt für meinen HUB1200 nutzen? Dann wahrscheinlich mit "control.smartMode" = true und dann über "control.setOutputLimit" und eben nicht über "control.setDeviceAutomationInOutLimit".
Oder soll/muss ich bei 1.15.4 bleiben?

Was pricht dagegen das mit dem Hub zu nutzen? Empfehlen kann ich definitiv "setDeviceAutomationInOutLimit".

Das folgende spricht dagegen:

Die Funktion invoke (setDeviceAutomationInOutLimit) wurde von HA übernommen und das nicht vollständig, wie HA es macht.
z.B. der Zwischenschritt von Laden zu Entladen mit Mode:0 usw.(?)
Die Funktion ist nicht zur direkten Steuerung vorgesehen und verwendet original eher ein Richtwert mit mapping.
Wurde zweckentfremdet mit ungewissen Ausmaß, ohne genauen Background.
Dadurch kommt es zu Fehlern und Folgefehlern.
Das betrifft die HA-Integration und weil das die Basis für den solar-flow-Adapter ist auch diesen.
z. B. plötzliche mqtt-Probleme, woher komme die?
auch beim Hyper...

Lösung: wie von Zendure vorgesehen steuern.
Keine (mqtt-)Probleme, weil es Zendure für lokale Verwendung vorgesehen hat und das nun auch offiziell über mqtt/App bei neueren Geräte:
Verwendung von den dafür bestimmten Keys: acMode, inputLimit, outputLimit.

Warum?
Alles wird in Flash geschrieben. Wie bei den meisten auf dem Markt befindlichen Geräten im Consumer-Bereich.
Auch Function Invoke von Zendure macht das:
Rückkmeldung von Zendure
Auswertung

Flash schreiben ist bei Consumer-Geräte leider üblich. Tabelle

Bisherige Erkenntnis

übliche Lebensdauer von Flash im Consumbereich

Feststellungen

Du empfiehlst die Funktion "definitiv" für den HUB.
Ohne eine ausführliche Begründung?
Ein kurzer Satz, wie "Zendure macht das auch so" ist nicht richtig und kann nicht belegt werden.
Bei allem Respekt für Deine bisherige, großartige Arbeit.
Nur das unvollständige Übernehmen inkl. Fehlern von der HA Integration finde ich nicht zielführend.
Wir wissen doch Alle nicht, in welchem Zusammenhang und wie (mapping etc.) die originale Basis funktioniert und was sie alles erwartet.
Für reines, beliebiges und beliebig oft, Werte setzen ist sie nicht gedacht.

Die einzige sinnvollen Strategien sind: Keys verwenden, die auch freigegeben wurden.
Schreibvorgänge auf das nötigste zu begrenzen für ein langes Flash-Leben.
Das wurde von Zendure bestätigt (neue Geräte) und auch von Zendure wirklich so gemacht.

Hinweis:
Habe lange überlegt ob ich mich überhaupt noch dazu äußern soll.
Bin wieder an dem Punkt mich unbeliebt zu machen, nur weil ich schreibe was ist und was herausgefunden und beobachtet wurde.

Jeder wie er möchte, für mich ist das Thema "invoke" durch.

@felli sagte in Test Adapter Zendure Solarflow:

@maxclaudi ... Ob mit oder ohne Last es bleibt eine mechanische Komponente die, je weniger man sie nutzt, entsprechend länger hält.
....
Daher alles gut und wenn man weiß was man tut ist es ja auch mehr als okay 👍🏼 Mache es z.B. bei Relais im ACE so, das ich nur zweimal am Tag schalte. Morgens auf Eingang, abends auf Ausgang und fertig.

:+1:

Ja, das ist das auch eine mechanische Komponente.
Die genau dafür ausgewählt wurde und nicht übertrieben oft, sondern mäßig, im richtigen Zeitpunkt, genutzt werden sollte bzw. kann.

Ein Lichtschalter ist auch mechanisch und diesen schalte ich auch nicht ständig als Flip-Flop/Blinker aus und ein.
Benutzen werde ich den Schalter, weil ich nicht im dunkeln stehen möchte, damit der Schalter länger lebt.

Bypass soll Batterien schonen(?).
Das weiß ich nicht und verlasse mich auf die Aussagen des Herstellers.
Wenn das so ist, dann sind bzw. wären mir defekte Relais lieber als defekte Batterien.

Damit ist auch das Thema "Relais" für mich abgeschlossen :-)

nograx

@maxclaudi sagte in Test Adapter Zendure Solarflow:

@nograx sagte in Test Adapter Zendure Solarflow:

@rene55 sagte in Test Adapter Zendure Solarflow:

@nograx Jetzt ist ja die Version 2.0.1 im Stable. Kann/soll ich das jetzt für meinen HUB1200 nutzen? Dann wahrscheinlich mit "control.smartMode" = true und dann über "control.setOutputLimit" und eben nicht über "control.setDeviceAutomationInOutLimit".
Oder soll/muss ich bei 1.15.4 bleiben?

Was pricht dagegen das mit dem Hub zu nutzen? Empfehlen kann ich definitiv "setDeviceAutomationInOutLimit".

Das folgende spricht dagegen:

Die Funktion invoke (setDeviceAutomationInOutLimit) wurde von HA übernommen und das nicht vollständig, wie HA es macht.
z.B. der Zwischenschritt von Laden zu Entladen mit Mode:0 usw.(?)

Die Funktion ist nicht zur direkten Steuerung vorgesehen und verwendet original eher ein Richtwert mit mapping.
Wurde zweckentfremdet mit ungewissen Ausmaß, ohne genauen Background.
Dadurch kommt es zu Fehlern und Folgefehlern.

Das betrifft die HA-Integration und weil das die Basis für den solar-flow-Adapter ist auch diesen.
z. B. plötzliche mqtt-Probleme, woher komme die?
auch beim Hyper...

Lösung: wie von Zendure vorgesehen steuern.
Keine (mqtt-)Probleme, weil es Zendure für lokale Verwendung vorgesehen hat und das nun auch offiziell über mqtt/App bei neueren Geräte:
Verwendung von den dafür bestimmten Keys: acMode, inputLimit, outputLimit.

Warum?
Alles wird in Flash geschrieben. Wie bei den meisten auf dem Markt befindlichen Geräten im Consumer-Bereich.
Auch Function Invoke von Zendure macht das:
Rückkmeldung von Zendure
Auswertung

Flash schreiben ist bei Consumer-Geräte leider üblich. Tabelle

Bisherige Erkenntnis

übliche Lebensdauer von Flash im Consumbereich

Feststellungen

Du empfiehlst die Funktion "definitiv" für den HUB.
Ohne eine ausführliche Begründung?
Ein kurzer Satz, wie "Zendure macht das auch so" ist nicht richtig und kann nicht belegt werden.
Bei allem Respekt für Deine bisherige, großartige Arbeit.
Nur das unvollständige Übernehmen inkl. Fehlern von der HA Integration finde ich nicht zielführend.
Wir wissen doch Alle nicht, in welchem Zusammenhang und wie (mapping etc.) die originale Basis funktioniert und was sie alles erwartet.
Für reines, beliebiges und beliebig oft, Werte setzen ist sie nicht gedacht.

Die einzige sinnvollen Strategien sind: Keys verwenden, die auch freigegeben wurden.
Schreibvorgänge auf das nötigste zu begrenzen für ein langes Flash-Leben.
Das wurde von Zendure bestätigt (neue Geräte) und auch von Zendure wirklich so gemacht.

Hinweis:
Habe lange überlegt ob ich mich überhaupt noch dazu äußern soll.
Bin wieder an dem Punkt mich unbeliebt zu machen, nur weil ich schreibe was ist und was herausgefunden und beobachtet wurde.

Jeder wie er möchte, für mich ist das Thema "invoke" durch.

@felli sagte in Test Adapter Zendure Solarflow:

@maxclaudi ... Ob mit oder ohne Last es bleibt eine mechanische Komponente die, je weniger man sie nutzt, entsprechend länger hält.
....
Daher alles gut und wenn man weiß was man tut ist es ja auch mehr als okay 👍🏼 Mache es z.B. bei Relais im ACE so, das ich nur zweimal am Tag schalte. Morgens auf Eingang, abends auf Ausgang und fertig.

:+1:

Ja, das ist das auch eine mechanische Komponente.
Die genau dafür ausgewählt wurde und nicht übertrieben oft, sondern mäßig, im richtigen Zeitpunkt, genutzt werden sollte bzw. kann.

Ein Lichtschalter ist auch mechanisch und diesen schalte ich auch nicht ständig als Flip-Flop/Blinker aus und ein.
Benutzen werde ich den Schalter, weil ich nicht im dunkeln stehen möchte, damit der Schalter länger lebt.

Bypass soll Batterien schonen(?).
Das weiß ich nicht und verlasse mich auf die Aussagen des Herstellers.
Wenn das so ist, dann sind bzw. wären mir defekte Relais lieber als defekte Batterien.

Damit ist auch das Thema "Relais" für mich abgeschlossen :-)

Weiß gar nicht genau wie ich darauf reagieren soll. Die setDeviceAutomationLimit Methode wurde ja auf deinen Hinweis hin implementiert, so wie die Integration von HA es macht (wo sollen hier die Unterschiede sein?). Das das nicht offiziell ist sollte jedem klar sein. Das war der Adapter nie - und jeder benutzt ihn auf eigene Gefahr. Ich selbe steuere jetzt seit dem meinen Hyper 2000 und einen AIO 2400 mit setDeviceAutomationLimit und das läuft ohne irgendwelcher Aussetzer oder Probleme.

Die "offizielle" Api von Zendure wird nur vom SF 800 und SF 2400 unterstützt. Hier ist zusätzlich zum MQTT ein Webserver aktiv der Befehle entgegen nimmt und das Gerät so dann steuert. Solange ich keinen SF 800 oder SF 2400 besitze kann und werde ich das nicht einbauen können.

Ich habe versucht Kontakt mit Zendure aufzunehmen, leider ist ioBroker offensichtlich kein Thema für Zendure. Der Ruf der HA Community war da wohl lauter.

lesiflo

@nograx Nachdem ich auf "setDeviceAutomationInOutLimit" umgestellt habe, war auf einmal einer meiner beiden Hyper plötzlich "eingefroren". Erst lief er eine Weile dann lies sich dieser nicht mehr ansprechen, es half nur noch ein Hardware Reset. Ich bin erstmal wieder zurück zur alten Konfiguration mit setInputLimit/setOutputLimit. Kann aber auch am Hyper gelegen haben. Ich werde das trotzdem weiter versuchen.

Rene55

@nograx Ich höre (bzw. lese) ja gerne die Erkenntnisse, die hier dargestellt werden. Ich hoffe @maxclaudi hört nicht auf, uns weiter hiermit zu versorgen. Ich bin jetzt auf der 2.0.1 und habe versucht, via "setOutputLimit" zu steuern. Ich sehe aber jetzt, dass der Wert vom Hub1200 nicht bestätigt wird und somit auch nichts aus dem Akku geholt wird.
Kann es sein, dass in der Version 2.0.1 dieser DP nicht mehr unterstützt wird und @nograx daher den "setDeviceAutomationInOutLimit" ausdrücklich empfiehlt?

lesiflo

@rene55 Moin, bei mir läuft 2.0.1 und ich schalte auch über setInputLimit/setOutputLimit. Klappt ohne Probleme. Du musst auch weiterhin den acMode setzen.

@nograx: Wenn der Flash auch mit setDeviceAutomationInOutLimit weiterhin genauso beschrieben wird wie mit setInputLimit/setOutputLimit wo ist da der Vorteil? Mit setDeviceAutomationInOutLimit hat sich einer der beiden Hyper 2 x aufgehängt. Auf was soll smartMode gesetzt werden? Ich habe die ganze Diskussion hier in letzter Zeit nicht weiter verfolgt und frage daher nochmal nach.

nograx

@rene55 sagte in Test Adapter Zendure Solarflow:

Kann es sein, dass in der Version 2.0.1 dieser DP nicht mehr unterstützt wird und @nograx daher den "setDeviceAutomationInOutLimit" ausdrücklich empfiehlt?

Ich kann mal schauen ob da ein Fehler in der Programmierung vorliegt. Aber da die Version ja nun schon einige Zeit im Beta Kanal und seit kurzem auch im Main Kanal ist und bisher keine negativen Meldungen (auch nicht in GitHub) vorliegen gehe ich aktuell nicht davon aus das das ein generell Problem ist.

nograx

@lesiflo sagte in Test Adapter Zendure Solarflow:

@nograx: Wenn der Flash auch mit setDeviceAutomationInOutLimit weiterhin genauso beschrieben wird wie mit setInputLimit/setOutputLimit wo ist da der Vorteil? Mit setDeviceAutomationInOutLimit hat sich einer der beiden Hyper 2 x aufgehängt. Auf was soll smartMode gesetzt werden? Ich habe die ganze Diskussion hier in letzter Zeit nicht weiter verfolgt und frage daher nochmal nach.

Wie gesagt mein Hyper läuft damit seit mindestens 2 Monaten ohne Probleme. Aussetzer habe ich keine. Bist du in der Cloud unterwegs oder lokal?

SmartMode gibt es beim Hyper offensichtlich nicht.

Es gibt weder auf GitHub noch hier viele Meldungen zu dem Thema, das ist also kein generelles Problem. Ein kurzer Blick in die GitHub Issues bei der HA Integration zeigt da auch keine generellen Probleme dazu.

Der Adapter ist ja Open Source, wenn es also Handlungsbedarf gibt etwas anzupassen oder zu verbessern kann man gerne daran mitarbeiten.

lesiflo

@nograx Bin in der Cloud und hab's jetzt wieder auf setDeviceAutomationInOutLimit umgestellt. Mal schauen was wird.

nograx

@lesiflo sagte in Test Adapter Zendure Solarflow:

@nograx Bin in der Cloud und hab's jetzt wieder auf setDeviceAutomationInOutLimit umgestellt. Mal schauen was wird.

Das ist eventl. dann der Unterschied. Mein Hyper läuft lokal.

Murphy 0

@nograx
Mein Hyper läuft auch lokal, keine Probleme mit dem Adapter.
Ich benutze setDeviceAutomationInOutLimit.
Mqtt Abbrüche zum Mosquitto auch keine mehr seit ich die täglichen Schreibvorgänge auf ca. 90 bis 150 begrenzt habe.

Rene55

@lesiflo der acMode steht bei mir (permanent) auf "AC output mode". Auf was auch sonst (HUB1200)? Das mit dem 'nicht reagieren' auf 'setOutputLimit' werde ich dieser Tage nochmal testen. Vielleicht war das nur ein "Hänger" zum MQTT und somit ne einmalige Sache und kein Bug:

maxclaudi

@rene55
autoModel:0 muss auch sein.

Bernd1967

@nograx
Ich hab zwar seit einer Woche Ruhe mit dem "Hängen" bleiben meiner lokal angebundenen Hyper, aber das ist wohl nur Zufall.
Kannst Du mir sagen wofür die folgenden Parameter sind beim Laden der Speicher mit "setDeviceAutomationInOutLimit" ?

 autoModelValue: {
              upTime: 0,
              pullTime: 1800,

Die Kollegen von HA haben das am 22.7. bereits wieder raus genommen beim Hyper.

lesiflo

Moin,
heute Nacht ist wieder einer der beiden Hyper ausgestiegen, diesmal aber der andere. Von ca 23:00 bis 02:00 meinte er seinen Dienst einstellen zu müssen. Er hat sich aber selbst wieder gefangen, ein Hardware Reset war nicht nötig. Ich werde aber erstmal auf "setDeviceAutomationInOutLimit" bleiben und weiter beobachten. Scheint wohl doch an der Cloud zu liegen.

Ausschnitt der Entladekurve:

nograx

@bernd1967 sagte in Test Adapter Zendure Solarflow:

@nograx
Ich hab zwar seit einer Woche Ruhe mit dem "Hängen" bleiben meiner lokal angebundenen Hyper, aber das ist wohl nur Zufall.
Kannst Du mir sagen wofür die folgenden Parameter sind beim Laden der Speicher mit "setDeviceAutomationInOutLimit" ?
 autoModelValue: {
              upTime: 0,
              pullTime: 1800,
Die Kollegen von HA haben das am 22.7. bereits wieder raus genommen beim Hyper.

Danke für den Hinweis. Tatsächlich habe ich hier vor einigen Tagen noch mal die Methoden der HA Integration übernommen, lokal war das mit pullTime und upTime schon rausgeflogen. Werde da gleich mal ne Beta raus basteln.

Rene55

@maxclaudi oha! Bei mir steht autoModel auf "Smart Matching Mode". Eigentlich schon immer, weiß nicht seit wann?!

nograx

@rene55 sagte in Test Adapter Zendure Solarflow:

@maxclaudi oha! Bei mir steht autoModel auf "Smart Matching Mode". Eigentlich schon immer, weiß nicht seit wann?!

Das macht die Funktion setDeviceAutomationInOutLimit, das ist normal.

maxclaudi

@rene55
oder ausführlicher erklärt:

setDeviceAutomationInOutLimit schaltet automatisch in diesen Mode, da die Wertübergabe nur darin funktioniert.
Nach dem ersten Aufruf bleibt das Gerät im SmartMatching-Mode.

Falls die Firmware keine Commit-Prüfung implementiert, könnte jeder Aufruf zwei Flash-Writes auslösen:
einmal für den eigentlichen Wert und einmal für den Mode.
In der Praxis ist dies jedoch sehr unwahrscheinlich, da Zendure üblicherweise eine Änderungsprüfung nutzt und damit unnötige Commits vermeidet.

Wenn man einen Wert im SmartMatching-Mode gesetzt hat und danach wieder eine Funktion außerhalb dieses Modes nutzen möchte, muss der Mode explizit manuell zurückgesetzt werden (z. B. auf Mode:0 oder einen anderen Automatikmodus).

Modewechsel => Flash.

@Bernd1967

Kannst Du mir sagen wofür die folgenden Parameter sind beim Laden der Speicher mit "setDeviceAutomationInOutLimit" ?

Die Parameter upTime und pullTime im Original SmartMatching-Mode legen die Zeitgültigkeit des übergebenen Richtwerts fest:
upTime = Startoffset in Sekunden (0 == sofort)
pullTime = Dauer in Sekunden (1800 == 30min)

maxclaudi

@nograx sagte in Test Adapter Zendure Solarflow:

@rene55 sagte in Test Adapter Zendure Solarflow:

@maxclaudi oha! Bei mir steht autoModel auf "Smart Matching Mode". Eigentlich schon immer, weiß nicht seit wann?!

Das macht die Funktion setDeviceAutomationInOutLimit, das ist normal.

solar-flow-adapter:
Am Ende wird immer ein deviceAutomation-Payload gebaut.
In allen Pfaden, wo setDeviceAutomationInOutLimit wirklich ein _arguments befüllt, wird hart autoModel: 8 gesetzt.
Im gesamten Code gibt es keine Stelle, wo der aktuelle autoModel-Status vom Gerät abgefragt oder berücksichtigt wird, bevor der Payload gesendet wird.

Beispiel (Hyper, Output):

_arguments = [
  {
    autoModelProgram: 2,
    autoModelValue: { ... },
    msgType: 1,
    autoModel: 8,   // <--- fest!
  },
];

Bei jedem Aufruf von setDeviceAutomationInOutLimit wird autoModel:8 stumpf in die Nachricht gepackt und gesendet.

Ob das tatsächlich in zwei Flash-Schreibvorgängen endet (Limit + Mode), hängt von der Firmware-Implementierung ab. Wahrscheinlich verhindert Zendure unnötige Commits, sodass nur dann geschrieben wird, wenn sich was ändert.

Quelle solarflow-adapter: Auszug mqttService.ts

export const setDeviceAutomationInOutLimit = async (
  adapter: ZendureSolarflow,
  productKey: string,
  deviceKey: string,
  limit: number // can be negative, negative will trigger charging mode
): Promise<void> => {
  if (adapter.mqttClient && productKey && deviceKey) {
    adapter.log.debug(
      `[setDeviceAutomationInOutLimit] Set device Automation limit to ${limit}!`
    );

    if (limit) {
      limit = Math.round(limit);
    } else {
      limit = 0;
    }

    if (adapter.config.useLowVoltageBlock) {
      const lowVoltageBlockState = await adapter.getStateAsync(
        productKey + "." + deviceKey + ".control.lowVoltageBlock"
      );
      if (
        lowVoltageBlockState &&
        lowVoltageBlockState.val &&
        lowVoltageBlockState.val == true &&
        limit > 0
      ) {
        limit = 0;
      }

      const fullChargeNeeded = await adapter.getStateAsync(
        productKey + "." + deviceKey + ".control.fullChargeNeeded"
      );

      if (
        fullChargeNeeded &&
        fullChargeNeeded.val &&
        fullChargeNeeded.val == true &&
        limit > 0
      ) {
        limit = 0;
      }
    }

    if (limit < 0) {
      // Get input limit, make number positive and the new value negative
      limit = -getMinAndMaxInputLimitForProductKey(productKey, -limit);
    } else {
      limit = getMinAndMaxOutputLimitForProductKey(productKey, limit);
    }

    const topic = `iot/${productKey}/${deviceKey}/function/invoke`;

    adapter.msgCounter += 1;

    const timestamp = new Date();
    timestamp.setMilliseconds(0);

    // HUB1200 & HUB 2000
    let _arguments: IDeviceAutomationPayload[] = [];

    const productName = getProductNameFromProductKey(productKey);

    if (
      productName.toLowerCase().includes("2400 ac") ||
      productName.toLowerCase().includes("solarflow 800")
    ) {
      adapter.log.debug(
        `[setDeviceAutomationInOutLimit] Using HEMS Variant of device automation, as device '${productName}' detected!`
      );
      // HEMS Variante
      const hemsEP = {
        arguments: {
          outputPower: limit > 0 ? limit : 0,
          chargeState: limit > 0 ? 0 : 1,
          chargePower: limit > 0 ? 0 : -limit,
          mode: 9,
        },
        function: "hemsEP",
        messageId: adapter.msgCounter,
        deviceKey: deviceKey,
        timestamp: timestamp.getTime() / 1000,
      };

      adapter.mqttClient?.publish(topic, JSON.stringify(hemsEP));
      return;
    } else if (productName.toLowerCase().includes("hyper")) {
      if (limit < 0) {
        adapter.log.debug(
          `[setDeviceAutomationInOutLimit] Using CHARGE variant of HYPER device automation, as device '${productName}' detected and limit is negative!`
        );
        // Input / Charge
        _arguments = [
          {
            autoModelProgram: 1,
            autoModelValue: {
              upTime: 0,
              chargingType: 1,
              pullTime: 1800,
              price: 2,
              chargingPower: -limit,
              prices: [
                1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
                1, 1, 1,
              ],
              outPower: 0,
              freq: 0,
            },
            msgType: 1,
            autoModel: 8,
          },
        ];
      } else {
        adapter.log.debug(
          `[setDeviceAutomationInOutLimit] Using FEED IN variant of HYPER device automation, as device '${productName}' detected and limit is positive!`
        );
        // Output
        _arguments = [
          {
            autoModelProgram: 2,
            autoModelValue: {
              chargingType: 0,
              chargingPower: 0,
              freq: 0,
              outPower: limit,
            },
            msgType: 1,
            autoModel: 8,
          },
        ];
      }
    } else {
      if (limit < 0) {
        adapter.log.warn(
          `[setDeviceAutomationInOutLimit] Using CHARGE variant of Hub device automation is currently not working! You have to manualy switch acMode and inputLimit!`
        );
        /* // Input / Charge
        _arguments = [
          {
            autoModelProgram: 2,
            autoModelValue: {
              upTime: 0,
              chargingType: 1,
              pullTime: 1800,
              price: 2,
              chargingPower: -limit,
              prices: [
                1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
                1, 1, 1,
              ],
              outPower: 0,
              freq: 0,
            },
            msgType: 1,
            autoModel: 8,
          },
        ]; */
      } else {
        // Output
        adapter.log.debug(
          `[setDeviceAutomationInOutLimit] Using FEED IN variant of Hub device automation, as device '${productName}' detected and limit is positive!`
        );
        _arguments = [
          {
            autoModelProgram: 2,
            autoModelValue: limit,
            msgType: 1,
            autoModel: 8,
          },
        ];
      }
    }

    const deviceAutomation = {
      arguments: _arguments,
      function: "deviceAutomation",
      messageId: adapter.msgCounter,
      deviceKey: deviceKey,
      timestamp: timestamp.getTime() / 1000,
    };
    adapter.mqttClient?.publish(topic, JSON.stringify(deviceAutomation));
  }
};

man könnte auch den code erweitern, dass zuerst der aktuelle autoModel-State aus properties.autoModel gelesen und nur gesetzt wird, wenn er ≠ 8 ist?

Dann würde man sicherstellen, dass das Gerät nicht unnötig mit Mode:8 überschrieben wird.

z. B. zentrale Logik, die egal ob Hub, Hyper oder HEMS immer zuerst prüft, ob das Gerät schon im richtigen Mode ist. Nur wenn der autoModel ≠ 8 ist, wird autoModel: 8 in den Payload gepackt. Damit würden unnötige Doppel-Writes gespart.

Beispiel/Vorlage: vereinheitlichte Version von setDeviceAutomationInOutLimit:

export const setDeviceAutomationInOutLimit = async (
  adapter: ZendureSolarflow,
  productKey: string,
  deviceKey: string,
  limit: number
): Promise<void> => {
  if (!adapter.mqttClient || !productKey || !deviceKey) return;

  adapter.log.debug(
    `[setDeviceAutomationInOutLimit] Set device Automation limit to ${limit}!`
  );

  // normalize limit
  limit = limit ? Math.round(limit) : 0;

  // LowVoltageBlock / FullChargeNeeded prüfen
  if (adapter.config.useLowVoltageBlock) {
    const lowVoltageBlockState = await adapter.getStateAsync(
      `${productKey}.${deviceKey}.control.lowVoltageBlock`
    );
    if (lowVoltageBlockState?.val === true && limit > 0) limit = 0;

    const fullChargeNeeded = await adapter.getStateAsync(
      `${productKey}.${deviceKey}.control.fullChargeNeeded`
    );
    if (fullChargeNeeded?.val === true && limit > 0) limit = 0;
  }

  // Grenzen für Input/Output anwenden
  if (limit < 0) {
    limit = -getMinAndMaxInputLimitForProductKey(productKey, -limit);
  } else {
    limit = getMinAndMaxOutputLimitForProductKey(productKey, limit);
  }

  const topic = `iot/${productKey}/${deviceKey}/function/invoke`;
  adapter.msgCounter += 1;
  const timestamp = Math.floor(Date.now() / 1000);

  // --- geändert/neu: aktuellen Mode abfragen ---
  const currentModeState = await adapter.getStateAsync(
    `${productKey}.${deviceKey}.properties.autoModel`
  );
  const currentMode = currentModeState?.val;
  const targetMode = 8;
  const includeMode = currentMode !== targetMode;

  const productName = getProductNameFromProductKey(productKey).toLowerCase();

  let payload: any;

  if (productName.includes("2400 ac") || productName.includes("solarflow 800")) {
    // HEMS Variante, von HEMS habe ich keine Erfahrung/Ahnung! 
    payload = {
      arguments: {
        outputPower: limit > 0 ? limit : 0,
        chargeState: limit > 0 ? 0 : 1,
        chargePower: limit > 0 ? 0 : -limit,
        mode: 9,
      },
      function: "hemsEP",
      messageId: adapter.msgCounter,
      deviceKey,
      timestamp,
    };
  } else if (productName.includes("hyper")) {
    // Hyper Variante
    if (limit < 0) {
      payload = {
        arguments: [
          {
            autoModelProgram: 1,
            autoModelValue: {
              upTime: 0,
              chargingType: 1,
              pullTime: 1800,
              price: 2,
              chargingPower: -limit,
              prices: new Array(24).fill(1),
              outPower: 0,
              freq: 0,
            },
            msgType: 1,
            ...(includeMode ? { autoModel: targetMode } : {}),
          },
        ],
        function: "deviceAutomation",
        messageId: adapter.msgCounter,
        deviceKey,
        timestamp,
      };
    } else {
      payload = {
        arguments: [
          {
            autoModelProgram: 2,
            autoModelValue: {
              chargingType: 0,
              chargingPower: 0,
              freq: 0,
              outPower: limit,
            },
            msgType: 1,
            ...(includeMode ? { autoModel: targetMode } : {}),
          },
        ],
        function: "deviceAutomation",
        messageId: adapter.msgCounter,
        deviceKey,
        timestamp,
      };
    }
  } else {
    // Hub Variante
    if (limit < 0) {
      adapter.log.warn(
        `[setDeviceAutomationInOutLimit] CHARGE variant for Hub not supported – use acMode + inputLimit manually!`
      );
      return;
    } else {
      payload = {
        arguments: [
          {
            autoModelProgram: 2,
            autoModelValue: limit,
            msgType: 1,
            ...(includeMode ? { autoModel: targetMode } : {}),
          },
        ],
        function: "deviceAutomation",
        messageId: adapter.msgCounter,
        deviceKey,
        timestamp,
      };
    }
  }

  adapter.mqttClient?.publish(topic, JSON.stringify(payload));
};

HINWEIS: das war nur eine Idee / Vorlage. Nicht auf Fehler überprüft und ob es funktioniert, weiß ich auch nicht.

@nograx sagte in Test Adapter Zendure Solarflow:

Die setDeviceAutomationLimit Methode wurde ja auf deinen Hinweis hin implementiert, so wie die Integration von HA es macht (wo sollen hier die Unterschiede sein?).

Mein Hinweis war als Link auf eine der Quellen gedacht.
Was man daraus macht, ist eine andere Sache.
Auf einen Unterschied habe ich bereits gleich bei Punkt 1 meines Posts hingewiesen.
Du schaltest hart. HA macht das vom packState abhängig. Bei HA ist packState:0 nicht nur stumpf packState:0. Es werden auch andere parameter berücksichtigt, was dazu führt dass selbst wenn packState nicht 0 sein könnte, es als packSate:0 gewertet wird, wenn.... usw.

edit:
So viel ich mich erinnere, wird dann in Abhängigkeit davon vor dem sofortigen Wechsel zwischen Entladen und Laden (oder Laden auf Entladen) erst in Mode:0 gewechselt und nicht einfach direkt umgeschaltet.
Quasi wie ein 3 Stufenschalter Laden->0 -> Entladen.
Entladen -> 0 -> Laden.
Beim solar-flow-adapter findet das nicht statt.
Laden-> Entladen / Entladen-> Laden.
Korrigiert mich, wenn ich das nicht richtig verstanden habe.
Beschäftige mich nicht mehr weiter damit.
edit Ende

Ich weiß gar nicht warum ich so bin und das nicht lassen kann.
Das Thema ist doch für mich abgeschlossen?
Richtig, das muss jetzt ein Ende haben, nachdem ich zu viel Zeit damit verbracht habe.
Vielleicht waren ja ein paar Ideen/Erkenntnise/Hinweise/Beobachtungen usw. für den einen oder anderen hilfreich.

nograx

@maxclaudi

autoModel: 8 wird auch bei der HA Integration immer mit geschickt. Da das Zendure abgenickt hat (die Integration offiziell ist) muss ich davon ausgehen das das so OK ist.
packState: Kannst du das bitte erläutern und mir ein Beispiel zeigen? Kann zu "packState" in der HA Integration nicht viel finden.
"hart" schalten. Hier bräuchte ich auch mal ein Beispiel bzw. ne Referenz in dem Code der HA Integration, das verstehe ich nämlich auch nicht.

Community Forum

NEWS

Test Adapter Zendure Solarflow

Support us

408

32.4k

81.4k

1.3m