ecoflow-connector-Script zur dynamischen Leistungsanpassung

BlackEagleBE

@waly_de sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

Workaround: Schreibe History-Daten für die einzelnen Messwerte mit und rechne selbst in Verbrauch um, bzw. stelle es in float (Adapter) dar,

Die Idee hatte ich anfangs schon, aber das ist vermutlich leider viel zu ungenau, da ich ja nicht den Verbrauch Sekundengleich abfrage / logge...

@waly_de sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

leider ist mir noch nicht gelungen die Nachrichten, die diese Daten enthalten zu entschlüsseln. Die kommen, aber sehen übel aus. Das gleiche gilt auch für diese Daten der PS.
Vielleicht möchte jemand sich dem annehmen? In dieser Nachricht sind alle Daten enthalten. Aber mir fehlt die .Proto Definition, oder ich habs noch nicht geschnallt... (auch was für schlechtes Wetter )
0a5f0a3308c101120608a89ebba70612060880a3bba706120608d8a7bba706120608b0acbba70612060888b1bba706120608e0b5bba7061035182020012801400248850150335801800103880103ca0110485735325a44483453463635343333330a500a2408ffff03120608b8a0fea70612060890a5fea706120608e8a9fea706120608c0aefea7061035182020012801400248870150245801800103880103ca0110485735325a44483453463635343333330a780a4c08ffff0312220880b1f9a70610051a180000000000000000000000000000000000000000000a000012220880b1f9a70610061a180000000000000000000000000000000000000000000f1f00103518202001280140fe014820504c5801800103880103ca0110485735325a4448345346363534333333
https://protobuf-decoder.netlify.app

damit kann man in die Nachricht sehen. Aber ich glaube der Decoder versagt da. Mit der richtigen .proto Definition wird es besser klappen.

Danke für deine Antwort... Ich habe mich nun mal mit dem Thema Protobufs beschäftigt und ein wenig Reverse Engineering betrieben Ich denke die wichtigsten Felder scheine ich aufgelöst zu haben. Bei mir stimmen die Werte überein... wenn die Daten so in der ioBroker Objekt-Struktur landen würden, könnte man die etwas aufbereiten. Versuche es mal mit folgender .proto Datei von mir... Auf https://www.protobufpal.com konnte ich sowohl dein Beispiel als auch meine Daten damit decodieren... die konstanten Werte sind wohl alle aus dem Header.

message base {
  optional header plugData = 1;
}
message header { // --> header
  optional plug_datalists pData = 1;
  optional int32 src = 2; // immer 53  ... src
  optional int32 dest = 3; // immer 32 ... dest
  optional int32 dSrc = 4; // immer 1 ... dSrc
  optional int32 dDest = 5; // immer 1 ... dDest
  optional int32 cmdFunc = 8; // immer 254 ... cmdFunc
  optional int32 cmdId = 9; // immer 32 ... cmdId
  optional int32 dataLen = 10; // immer 76 ... dataLen
  optional int32 needAck = 11; // immer 1 ... needAck
  optional int32 version = 16; // immer 3 ... version
  optional int32 payloadVer = 17; // immer 3 ... payloadVer
  optional string deviceSn = 25; // ... deviceSn
}
enum plug_datalist_type {
  WattHours = 5;
  MinutesPoweredOn = 6;
}

message plug_datalists {
  optional int32 X_Unknown_Field1 = 1; // immer 65535
  repeated plug_datalist data = 2;
}
message plug_datalist {
  optional int32 date = 1; // unix timestamp today 00:00 GMT+0
  optional plug_datalist_type valueType = 2;
  optional bytes valuesPerHourGMT = 3;  // one value per GMT hour ... first = 00:00-0:59, second = 01:00 - 01:59, etc
}

Ich hoffe das hilft schonmal.

Nachtrag... Ach ja, evtl. eine kurze Erklärung: Er speichert den Verbrauch scheinbar je Stunde ab. Also der erste Eintrag in valuesPerHourGMT ist der Verbrauch zwischen 0:00 und 0:59:59 GMT des heutigen Tages, der zweite zwischen 1:00 und 1:59:59, etc... Leider ein bisschen blöd, da die meisten hier nicht in GMT leben Aber man bekommt alle Werte und kann sie historisieren.

Nachtrag 2: Ich habe das Script nun so angepasst, dass die Werte automatisch in den iobroker übernommen werden, indem ich die writeables erweitert habe. Dabei ist mir aufgefallen, dass im Code noch mehrfach "SP" bzw. 'SP' verwendet wird, statt dem in der letzten Version geänderten "SM" für SmartPlugs. Ebenso habe ich gesehen, dass die gleiche CmdId auch für den PS verwendet wird, dort habe ich aber noch nicht geschaut, ob identisch ist oder es ggf. weitere Enums gibt...

Waly_de

@blackeaglebe sehr schön... befasse ich mich nächste Woche mit, wenn ich wieder zuhause bin.

Waly_de

@blackeaglebe wichtig noch für deine weitere Arbeit:

mein Beispiel enthält 3 unterschiedliche Nachrichten inclusive Header
Du musst nur :

 optional header plugData = 1;

gegen

repeated header plugData = 1;

tauschen, damit das auch in deiner Definition verarbeitet werden kann.
Den header hab ch ja schon vollständig definiert im Script. vielleicht sogar Definitionen für andere Nachrichten, die ich nur noch nicht richtig zugeteilt habe. Klau dir am besten die schon bestehenden Definitionen aus dem Script. bin gespannt was du noch raus findest.

BlackEagleBE

@waly_de sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

Den header hab ch ja schon vollständig definiert im Script. vielleicht sogar Definitionen für andere Nachrichten, die ich nur noch nicht richtig zugeteilt habe. Klau dir am besten die schon bestehenden Definitionen aus dem Script.

Danke für die Info! Brauchte ich aber gar nicht - das macht dein Script scheinbar bereits automatisch
Ich hatte die .proto-Datei zuerst ohne Einbinden in deinen Code erarbeitet.
Mir ist daher auch erst später aufgefallen, dass der Header und das Handling bei dir bereits genau so drin ist und das alles von deinem Script korrekt interpretiert wird. Ich musste daher lediglich proto-Defintion (für enum, datalists, datalist) neu hinterlegen und die datalists in die writeables eintragen (und das ignor beim PS rausnehmen). Daher hatte ich kein Problem mit dem optional/repeat und dem Header... Die Daten werden bei mir übrigens bereits erstmal korrekt eingelesen und der Verbrauch (über ein eigenes Script) nach Tag/Monat/Jahr (in der korrekten zeitzone) zusammengezogen... Genau das was ich wollte. Merci.

bin gespannt was du noch raus findest.

Was fehlt denn noch außer dem einen Unknown Feld? In dieser Nachricht hatte ich sonst alles, oder?
Wenn ich dir noch irgendwie helfen kann, meld dich einfach.

Accu

@Waly_de weißt Du was dieser Fehler bedeutet und was ich dagegen machen kann?
Bildschirmfoto 2023-09-14 um 09.24.13.png

Waly_de

@blackeaglebe mega… das sind immer die Besten sagen, die einfach funktionieren
Wenn du mir Deine geänderte Version von meinem Script mit Kommentaren an Stellen die du ergänzt bzw. geändert hast schickst, wäre das super.

Ich kann im Moment leider nichts machen erst nächste Woche wieder …

Waly_de

@accu Netzwerk Probleme vermutlich… Neustart und warten könnte helfen

umele

Hallo zusammen,

ich lese hier fleissig mit und bin dank der vielen Inputs (und trotz meiner Inkompetenz) schon recht weit gekommen:
Inzwischen bekomme ich die Daten vom Sensor in iobroker, und habe die Sensor-ID im Script eingetragen.
Aaaber - ich finde nirgends das Objekt 0_userdata.0.ecoflow.RealPower (und kann auch nicht erkennen, dass sich die Einspeisung anpasst).
Was mache ich falsch?

Edit: noch ein Screenshot meiner Ecoflow-Objektstruktur Objekte iobroker.png

vielen Dank
umele

photon-harvester

Moin Moin,
habt ihr einen Tip für mich, wie ich verschiene IDs zu einem Wert addieren kann, um es anschließend zu visualisieren?
Bsp. ID:AkkuSoC1 +ID:AkkuSoC2 = ID:AkkuSoCgesammt --> dann ablegen in history für z.B. VIS
Danke
PS: kann leider nicht programmieren, nur copy-paste oder Widgets

umele

Habe das Script jetzt mal mit voller Protokollausgabe laufen lassen. Es findet anscheinend den Sensor überhaupt nicht.

Es kommt noch nicht mal dazu die Funktion SetBasePower auszuführen (in der wird das Objekt RealPower erstellt). Laut Script müsste diese Funktion geloggt werden.

Auch im Debug Modus ist nichts zu finden. Bin gerade ratlos...

Schade, dass der Debug Modus es nicht erlaubt, das Script step-by-step auszuführen - dann könnte ich das Problem vielleicht finden...

Wäre echt toll, wenn jemand eine Idee hat - Danke!!

Waly_de

@umele wie du sagst, das Script prüft die Existenz des Sensors. Es muss also an der id liegen was genau hast du denn als smartmeterid angegeben?

Dreffi

@waly_de
Direkte Frage an Markus:
Ich habe jetzt mehrfach beobachtet, dass sich einer meiner Powerstreams im falschen Prio Modus befand.

Einer ist konfiguriert bei vollem Akku auf Prio Akku zu schalten, der andere soll voll einspeisen. Das klappt soweit einwandfrei.
Gestern und heute fiel mir abends auf, dass der Powerstream der voll einspeisen soll auf Prio Akku stand.

Ich kann nicht sagen wieso hier überhaupt die Priorisierung geändert wurde und ob das Script dafür verantwortlich ist. Da der Bedarf irgendwann höher als die abgegebene Leistung war, hätte hier aber irgendwann umgeschaltet werden müssen.

Der andere Powerstream wechselte unabhängig davon wunschgemäß wegen Bedarfs von Prio Akku auf Einspeisung. Der Bedarf war schnell wieder gering. Die eingestellte AC Last betrug dann wieder 0 W, aber der Powerstream wurde trotz vollem Akku nicht wieder auf Prio Akku zurückgestellt.

Die Trigger für das Umstellen der Priorisierung scheinen nicht so richtig zuverlässig zu funktionieren.

Ralf77

Hallo zusammen, das Script ist sehr gut bei mir bis vor kurzem gelaufen. Auf einmal hat das Scrip nicht mehr funktioniert. Es ändert die AC-Leistung des Powerstreams nicht mehr. Habe heute das Update auf den neuen Host durchgeführt, leider ohne Erfolg.

Generell kommuniziert das Script mit meinem Powerstream

19:12:58.284 info javascript.0 (1960) script.js.PowerStream: Batterie runter auf 92%: Normalbetrieb.
19:13:13.267 info javascript.0 (1960) script.js.PowerStream: Batterie runter auf 92%: Normalbetrieb.
19:13:13.465 info javascript.0 (1960) Stop script script.js.PowerStream
19:13:13.474 info javascript.0 (1960) script.js.PowerStream: Ecoflow MQTT-Client beendet
19:13:13.612 info javascript.0 (1960) Start javascript script.js.PowerStream
19:13:13.852 info javascript.0 (1960) script.js.PowerStream: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
19:13:14.231 info javascript.0 (1960) script.js.PowerStream: Verbunden mit dem Ecoflow MQTT-Broker

Es gibt zudem sehr viele Protokolleinträge, welche ich nicht deuten kann.

javascript.0
2023-09-16 18:13:13.612 info Start javascript script.js.PowerStream

javascript.0
2023-09-16 18:13:13.474 info script.js.PowerStream: Ecoflow MQTT-Client beendet

javascript.0
2023-09-16 18:13:13.465 info Stop script script.js.PowerStream

javascript.0
2023-09-16 18:13:13.267 info script.js.PowerStream: Batterie runter auf 92%: Normalbetrieb.

javascript.0
2023-09-16 18:12:58.284 info script.js.PowerStream: Batterie runter auf 92%: Normalbetrieb.

admin.0
2023-09-16 18:12:48.836 info ==> Connected system.user.admin from ::ffff:192.168.178.48

javascript.0
2023-09-16 18:12:43.265 info script.js.PowerStream: Batterie runter auf 92%: Normalbetrieb.

javascript.0
2023-09-16 18:12:28.264 info script.js.PowerStream: Batterie runter auf 92%: Normalbetrieb.

javascript.0
2023-09-16 18:12:13.265 info script.js.PowerStream: Batterie runter auf 92%: Normalbetrieb.

fronius.0
2023-09-16 18:12:03.611 warn State "fronius.0.inverter.1.Power_DC_String_2" has no existing object, this might lead to an error in future versions

fronius.0
2023-09-16 18:12:03.609 warn State "fronius.0.inverter.1.Power_DC_String_2" has no existing object, this might lead to an error in future versions

Eventuell kann ja jemand einen Tipp geben, wo das Problem sein könnte.

Milchbeck

@Waly_de hab mal ne frage wie wäre es im Script einzubauen, wenn der smartmeter oder powerfox ect mal keine Daten sendet das Script auf einen grundverbrauch sagen wir mal wie bei mir 140 Watt es dann eigenständig dem Powerstream das meldet und sobald wieder Daten ankommen es wieder ganz normal läuft? Also 5 Minuten oder was auch immer keine Daten dann Grundverbrauch 140 Watt und sobald wieder Daten eintreffen Normalbetrieb…

Weil bei mir fällt ab und zu mal Server seitig der Bezug aus und wenn dann zuletzt mal 400 Watt benötigt worden sind haut der Powerstream solange den Wert bis ich dann manuell eingreife und das würde es einfach im Hintergrund erledigen

LordMinorin

Ich habe es jetzt endlich geschafft die akutelle Version mal einzubinden.

Leider fliegen mir sofort Fehlermeldungen um die Ohren:

javascript.0
2023-09-16 20:36:48.567 error at processTimers (node:internal/timers:514:7)
javascript.0
2023-09-16 20:36:48.566 error at listOnTimeout (node:internal/timers:573:17)
javascript.0
2023-09-16 20:36:48.566 error at Timeout._onTimeout (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:2743:34)
javascript.0
2023-09-16 20:36:48.566 error at Object.<anonymous> (script.js.EcoFlow_Script_v0.v1132.v1132:790:9)
javascript.0
2023-09-16 20:36:48.566 error at CheckforReconnect (script.js.EcoFlow_Script_v0.v1132.v1132:1151:9)
javascript.0
2023-09-16 20:36:48.565 error at script.js.EcoFlow_Script_v0.v1132.v1132:791:13
javascript.0
2023-09-16 20:36:48.565 error at SetBasePower (script.js.EcoFlow_Script_v0.v1132.v1132:1711:74)
javascript.0
2023-09-16 20:36:48.564 error Error in callback: TypeError: GetValAkt(...).val.toFixed is not a function

Die GetValAkt funktion habe ich daraufhin modifiziert das keine nicht numerischen Werte ausgegeben werden:

function GetValAkt(id, minuten = 15, reset = true) {
    if (isState2(id)) {
        const state = getState(id)
        if (state.ts > Date.now() - minuten * 60 * 1000) {
            return state.val; // Gib den Wert direkt zurück
        } else {
            if (typeof state.val === 'number') {
                if (reset && state.val !== 0) setState(id, 0, true)
            } else {
                if (reset && state.val !== "0") setState(id, "0", true)
            }
            state.val = 0;
            return state.val; // Gib den Wert direkt zurück
        }
    } else {
        //log("Kein State: " + id + "lege an.")
        createState(id, "0", false);
        //return getState(id)

        const leerstate = {}
        leerstate.val = "0"
        leerstate.ts = Date.now()
        return leerstate.val; // Gib den Wert direkt zurück
    }
}

Jetzt sehen die Fehler so aus:

javascript.0
2023-09-16 20:59:57.034 error at processTimers (node:internal/timers:514:7)
javascript.0
2023-09-16 20:59:57.034 error at listOnTimeout (node:internal/timers:573:17)
javascript.0
2023-09-16 20:59:57.034 error at Timeout._onTimeout (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:2743:34)
javascript.0
2023-09-16 20:59:57.033 error at Object.<anonymous> (script.js.EcoFlow_Script_v0.v1132.v1132:790:9)
javascript.0
2023-09-16 20:59:57.033 error at CheckforReconnect (script.js.EcoFlow_Script_v0.v1132.v1132:1151:9)
javascript.0
2023-09-16 20:59:57.033 error at script.js.EcoFlow_Script_v0.v1132.v1132:791:13
javascript.0
2023-09-16 20:59:57.033 error at SetBasePower (script.js.EcoFlow_Script_v0.v1132.v1132:1711:73)
javascript.0
2023-09-16 20:59:57.033 error Error in callback: TypeError: Cannot read properties of undefined (reading 'toFixed'

Bitte um Ideen

Ponti92

@milchbeck wann passiert das bei dir?
Kann es sein, dass das bei dir auch abends ist, dass er manchmal hängen bleibt?
Dann könntest du das selbe Problem wie ich haben, dass er abends/nachts zu selten sich mit dem Server verbindet.
Dazu kannst du das Intervall für abends z.B. auf 1min setzen, anstatt 15 min.


//bis eine Stunde nach Sonneuntergang kurze Reconnects dann 15 min.
if (istTag (60)) wartezeit = 1

Seitdem läufts wieder rund um die Uhr perfekt

Milchbeck

@ponti92 es liegt daran wenn der ir lesekopf mal ausfällt kein Strom ect.

umele

@waly_de ich weiss ehrlich gesagt nicht, ob das Script den Sensor sucht. Zumindest finde ich im Log keinen Hinweis - "SmartmeterID" oder "SetBasePower" erscheinen im Log nicht.

Die ID habe ich aus dem Objekt mit der Watt-Angabe des Sensors ins Script eingetragen:

Danke für Deine Unterstützung!

Waly_de

@umele was du bei smartmeterID angegeben hast ist der Name, nicht die id des Sensors. Wenn du mit der Maus da klickst wo sie im Screenshot zu sehen ist wird die richtige ID in die Zwischenablage kopiert. Sie beginnt mit „sonoff.0.“

Dreffi

@waly_de
Also mit der Version 1.1.3.2 läuft bei mir irgendwas schief.

Ich hatte heut wieder den Fall, dass einer der beiden Powerstreams ständig auf Prio Akku umgestellt wurde. Das sollte eigentlich nur beim Abschalten per RegulationState passieren.
Der Andere wiederum blieb stur auf Prio Einspeisung mit AC Last 0 W. Dieser hätte eigentlich auf Prio Akku schalten müssen.

Ich habe auch den Eindruck es gibt hier zeitweise Probleme die AC Last richtig einzustellen:
Bildschirmfoto 2023-09-17 um 20.53.34.png

Irgendwie wird scheint hier jeweils der falsche Powerstream angesteuert zu werden.

Ich habe jetzt wieder auf die Version 1.1.3 umgestellt und seitdem liegt der Bezug wieder annähernd durchgehend konstant bei 10-15 W.

Ich beobachte...

NEWS

ecoflow-connector-Script zur dynamischen Leistungsanpassung

Support us

1.5k
Online

30.5k
Users

76.7k
Topics

1.2m
Posts

NEWS

ecoflow-connector-Script zur dynamischen Leistungsanpassung

Support us

1.5kOnline

30.5kUsers

76.7kTopics

1.2mPosts

1.5k
Online

30.5k
Users

76.7k
Topics

1.2m
Posts