Beiträge von sval

    Das Portal von RCT wird durch die Installateure verwaltet und kann für jeden seiner Kunden eingerichtet werden.

    Hast du da ein paar Details? Konkret interessiert mich, ob es ein anderes Protokoll ist als das was die App und die Verbindung zum Support-Server nutzten, denn das "Serial Communication Protocol" ist nach meinem derzeitigen Kenntnisstand (v1.13) völlig ungeeignet, um über öffentliche Netzwerke ("das Internet") übertragen zu werden (selbst "im Haus" ist es mMn. grenzwertig), da es weder Zugriffsschutz noch Verschlüsselung unterstützt.

    Vielen Dank für deine ausführliche Antwort, sval . Sie hilft mir schon einmal weiter.


    Richtig, ich erinnere mich an Posts und Beiträge von dir in diese Richtung hier im Forum. Dann bist damit eher auf der Visualisierungsseite zu Hause?

    Bitte, immer gerne!


    Korrekt, zumindest wenns um Geräte geht die mit Strom arbeiten oder bei denen eine Steuerung eine gewisse Erfahrung bedarf oder es einfach funktionieren muss. Ansonsten habe ich auch wenig was sich lohnen würde zu steuern. Ich habe aber einen Mordsspaß dabei, die Funktions- und Arbeitsweise von Geräten und Programmen durch Beobachtung zu verstehen.

    Okay, ich werde dir mir mal anschauen. Aber vermutlich wirst du in der lib auch nur lesenden Zugriff auf die Parameter des WR implementiert haben und keinen schreibenden (wenn das überhaupt geht?)

    Peter hat alles (sogar Kommunikation mit mehreren Wechselrichtern im Verbund) implementiert. Das Protokoll selber ist auch nicht schwierig. Der rctclient-Befehl implementiert sogar "Schreiben", denn man fragt Zeitserien ab indem man den Zeitstempel des "neusten" Datenpunktes an dem man interessiert ist an die ID der gewünschten Zeitserie schreibt, und erhällt eine Tabelle als Antwort. Prinzipiell unterscheidet sich "Schreiben" und "Lesen" durch den Command den man sendet. Entweder sagst du "Schreibe an ID X den Wert Y" oder "Lese den Wert von ID X" und dann schaust du dir die Antwort an.

    Okay, RS485 war bei mir auch immereine elektrische Schnittstelle, bis mir mal jemand sagte, das sein ein Synonym für CAN. Scheint dann aber nicht der Fall zu sein. Dann ist RS485 Layer 1 und CAN bzw. ModBus Layer 2?


    Und was spricht nun der RCT WR? CAN oder ModBus? Oder ModBusTCP? Man muss sich ja auch irgendwie physikalisch an den RCT WR anschließen können. Das würde über seinen LAN Zugang gehen (so wie ich gehört habe, ist der WR da offen wie ein Scheunentor)? Dann gibt es ja noch die Eingänge für den PowerSwitch (RJ45 Buchse) und ich meine, noch einen weiteren RJ45 Eingang (was auch immer für ein Protokoll darüber läuft).

    Da war ich unpräzise, sorry. Modbus (schreibweise hab ich auch gerade nochmal nachgeschaut, natürlich hab ichs falsch geschrieben) unterscheidet grob zwischen Modbus RTU (eine differentielle 2-Draht-Kommunikation, eben RS485) und Modbus TCP (jünger, basierend auf TCP/IP, aber mit den gleichen Prinzipen was die übertragenen Daten angeht). Der Wikipedia-Artikel gibt da eine kleine Übersicht: https://de.wikipedia.org/wiki/Modbus


    Der WR spricht CAN, TCP/IP (Netzwerk über Kabel und WLAN) und Modbus RTU (Modbus über Kupfer, also RS485) und hat mehrer Schaltein- sowie -ausgänge.


    • TCP/IP wird verwendet, um einerseits die App anzusprechen und mit dem Server vom Hersteller zu kommunizieren (im Supportfall, der WR baut von sich aus dann eine Verbindung nach außen auf um durchs NAT zu kommen und wartet auf Befehle, gleiches Protokoll wie bei der App), andererseits um mit anderen RCT-Wechselrichtern zu kommunizieren (Plant-Communication).
    • Modbus RTU wird beispielsweise vom SolarLog verwendet, es gibt im Inneren des Gehäuses einen Klemmblock dafür. Ich meine der ist im Handbuch auf einem Bild drauf, hab das grade nicht zur Hand. Hier braucht man die Registerdefinition, änlich wie beim Netzwerkprotokoll wo man die IDs wissen muss die man ansprechen muss.
    • Mit dem CAN-Bus wird das BMS auf dem Akku-Stack sowie der PowerSensor und PowerSwitch angebunden. Das Protokoll eignet sich gut für die Kommunikation in Umgebungen mit Störeinflüssen, die im PowerSwitch durch die Nähe zu elektrischen Leitungen immer gegeben sind. Die einzelnen Akkus der Stacks sind glaube ich auch mit CAN am BMS angeschlossen.

    Kannst du mir mal in wenigen Worten die Grundzüge der Kommunikation zwischen deinem RCT Client und dem WR nennen? Ich bin zumindest nicht fachfremd (habe Feldbus Protokolle spezifiziert und implementiert und auch andere IT Projekte bearbeitet - aber nie Python, eher in C(++) oder Java oder ganz am Anfang auch in Pascal). Vielen Dank!


    Einen schönen Abend, Michael

    Hm, da weiß ich jetzt nicht so genau was du meinst, also Tipp ich mal auf gut Glück los. Ich hab wenig praktische Erfahrung mit Feldbussen per se.


    Generell funktioniert das Protokoll so, dass man ein Frame sendet und die Antwort abwartet. Die Granularität ist dabei immer eine ID die angesprochen wird, wobei der Wechselrichter scheinbar (Beobachtung) durchaus das Anwenden mehrerer Parameter in einem Schritt unterstützt (Transaktionen), mittels des COM service. Das wird beispielsweise verwendet um die Netzwerkeinstellungen anzuwenden; wenn man nur einen Parameter (beispielsweise die Netzmaske) ändert fliegt der WR sofort "aus dem Netz" und man kann die IP nicht mehr umstellen.


    Ein Frame ist quasi Key-Length-Value mit Extra-Schritten. Es enthällt einen Command ("Lese", "Schreibe" bei Anfragen an den WR, "Antwort" bei Antworten vom WR), eine Länge, eine ID (quasi eine Adresse), für schreibende Anfragen noch eine Payload, und eine Checksumme. Das Frame wird als Big-Endian codiert. Man muss beim Schreiben von Werten (Ändern von Parametern) und beim Auswerten einer Antwort noch wissen, welches Datenformat die Payload hat, das steht in der Registy. Es gibt Funktionen die Dinge wie codieren/decodieren, Bauen eines zu sendenen Frames und Einlesen eines empfangenen Frames, das ist aber das gleiche was auch in der Doku steht.


    Die Bibliothek rctclient selber kommuniziert garnicht sondern erwartet dass das Programm von dem sie ein Teil ist die Netzwerkkommunikation managed. Der Befehl rctclient (verwirrend, ich weiss) der optional installiert wird implementiert das Netzwerk und ein Benutzerinterface. Er schaut mit dem was du als Parameter angegeben hast in der Registry nach, welche ID (ich hab die Dinger OID genannt weil es sehr nach SNMP gerochen hat) angesprochen wird (battery.soc ist die OID 0x959930BF, das nehm ich immer als Beispiel) und verpackt dann einfach diese Informationen in ein Frame, verbindet sich mit dem WR und sendet das Frame. Das Frame ist gebaut wie in der Doku, also Startsequenz, Länge, Befehl "LESE" und die ID sowie die Checksumme.


    Der WR verarbeitet die Anfrage und bereitet die Antwort vor. Hier wirds kompliziert, denn man kann ihn durcheinanderbringen indem man ihm weitere Anfragen sendet, je nachdem wo man ihn erwischt gibt er beispielsweise eine Antwort ohne Inhalt (aber mit korrekter Checksumme) zurück, das muss man abfangen. Oder er sendet die Antworten an die falsche (oder alle gerade anfragenden) Clients, d.h. man bekommt zwischendrin Antworten für Anfragen eines anderen Clients wie der App.


    Jedenfalls wartet der rctclient dann auf Antwort. Die Daten die er erhällt werden eingelesen bis ein Frame komplett ist (es kann über mehrere TCP-Pakete aufgeteilt sein), und dann wird geschaut ob es eine Antwort auf eine Anfrage ist die man gestellt hat. Wenn die Antwort die erwartete ID hat, dann wird sie ausgewertet, dazu wird in der Registry geschaut welcher Datentyp vorliegt und dann die Payload (also der Inhalt der Antwort) decodiert und zum Benutzer ausgegeben.


    Der rctclient ist recht einfach (in cli.py implementiert), das allermeiste ist die Verarbeitung der Parameter des Benutzers und das sinnvolle Anzeigen Formatieren der Ausgabe und Tonnen an Fehlerbehandlung. Ansonsten ist es fire-and-forget: TCP-Verbindung aufbauen, Senden, Empfangen, Verbindung wieder abbauen.


    Die Herstellung eines zu versendeten Frames ist in frame.py#L51, hier werden Endeffekt Werte im richtigen Format (Big-Endian) in einen Puffer geschrieben, ein bisschen Escaped (der Start-Sequenz bzw. der Escape-Sequenz wird die Escape-Sequenz vorangestelt), ein bisschen Checksummen berechnet und dann ist das ganze fertig zum Versenden.


    Ich hoffe das hilft schonmal, ansonsten hab ich viele der Sachen in der Doku zusammengeschrieben: https://rctclient.readthedocs.io/en/latest/usage.html (natürlich sehr Python-lastig).


    Die auch einen schönen Abend!

    Stefan


    (kriegst gleich noch ne PM :) )

    as habe ich auch so gelesen, aber wohl "maintainer" missverstanden und als "Kümmerer" übersetzt.

    Stimmt ja auch, ich hab es halt nicht ursächlich Programmiert (die Lorbeeren gehen klar an Peter), das wollte ich damit sagen.

    Wozu verwendest du den RCT Client denn dann, wozu könnte man ihn verwenden?

    Meine Verwendung: Um die Statistikwerte die der WR mitschreibt zu archivieren, sowie um die Live-Daten abzuziehen. Ich hab verschiedene Sensoren (Stromverbrauch via Zwischenstecker mit Tasmota-Firmware, Temperatur und andere Umweltwerte) sowie Geräte wie die Wärmepumpe und eben den WR angezapft und erstelle mir damit meine eigenen Grafiken mit Grafana, auf denen ich beispielsweise beliebig Werte zusammen anzeigen und auswerten kann. Da ich die Daten (auch) an Prometheus exportiere kann ich auch Alarme definieren die dann beispielsweise auf dem Handy landen und muss mich nicht drauf verlassen dass die Hersteller der Geräte zusammenarbeiten oder die Geräte überhaupt was von der Existens der anderen wissen. Nur steuere ich damit keine Geräte, es wäre aber relativ problemlos möglich.


    Generell ist rctclient eine Library zur Integration in andere Projekte/Programme, zumindest hab ich das ursprünglich so vorgesehen als ich es als eigenständiges Projekt auf Github gestellt hab. Es ermöglicht einfach generell, mit den Geräten zu reden. Das rctclient-Programm was dabei ist dient dabei einerseits als Schnellstart (bzw. reicht teilweise sogar aus) und andererseits als Beispielimplementierung. Dieses Programm erlaubt einem schonmal, auf der Kommandozeile Werte abzufragen, beispielsweise in einem größeren Script dass die dann weiterverarbeitet. So arbeitet übrigends OpenWB, da wird Peters ursprüngliche Implementierung einfach von Scripten aufgerufen und die Rückgabewerte ausgelesen. Er hat auch einen Simulator geschrieben den ich mit übernommen hab, damit man eigene Implementierungen in begrenztem Umfang testen kann ohne die echte Hardware zu beeinflussen (er gibt vom Protokoll her korrekte, aber technisch unsinnige Werte zurück).

    Ansonsten enthällt es Zusatztools wie timeseries2csv.py um die im Wechselrichter aufgezeichneten Statistiken auszulesen (am Ereignislog arbeite ich noch), oder ein Tool um aufgezeichneten Netzwerkverkehr zwischen App und WR zu analysieren. Und ansonsten nutze ich das Projekt als Sammlung an Informationen über die Wechselrichter (soweit sie die Kommunikation betreffen).

    Ich hatte an eine solche Lösung gedacht, dass man feststellen kann, dass die WP Strom zieht und die Menge bestimmen kann (z.B. über einen Zähler mit S0 Ausgang). Dann müsste man der Batterie über einen Parameter mitteilen (welchen auch immer), dass sie jetzt diese Energiemenge abgeben soll, aber nur dann, wenn ihr SOC noch über eiem Schwellwert ist (auch ein Parameter). Die openWB macht ja ähnliches, soweit ich das verstanden habe. Allerdings glaube ich, dass sie die Parameter aus dem WR nur ausliest und diesen nicht steuert. Daher muss die openWB wohl auch im selben Stromkreis liegen, in dem der Hausverbrauch liegt. Dann wird die Enerabgabe über die Power Sensoren gesteuert, und die openWB schaltet dann ab, wenn der SOC unter eine konfigurierbare Schwelle gesunken ist. So habe ich zumindest openWB verstanden (und nachdem die nun mit dem RCT WR kann, habe ich mir eine bestellt und auf die von RCT verzichtet).

    Der Akku ist bei RCT nicht eigenständig, der kommuniziert zwar per CAN, aber nur mit dem WR, alles an Parametern wird über den WR abgefrühstückt. Soweit ich gesehen hab ruft OpenWB nur Parameter ab, setzt aber keine.

    Ich habe von RCT mal eine Dokumentation des RCT Protokolls und der Parameter bekommen, aber ich denke, die hast du und Peter von openWB auch, sonst könntet ihr den Client und die openWB Anbindung an RC nicht implementiert haben. Was ModBus betrifft, habe ich da RS485 (was der WR spricht) mit ModBus verwechselt, und RS485 eigentlich CAN ist?

    Peter hat die Doku, ich hab sie bisher nicht, sollte ich mich eigentlich mal drum kümmern. Ich hatte bisher sehr viel Spaß beim Reverse-Engineeren von Dingen, die in Peters Code nicht drin waren, da mit der App ja eine offizielle Implementierung vorliegt, aber es wird langsam zu Zeitaufwendig. Allerdings lernt man sehr viel wenn man der App auf die Finger schaut oder den WR im Netzwerk zuschaut. Falls einige Begriffe die im rctclient verwendet werden nicht mit der Doku übereinstimmen: Das ist der Grund.


    ModBus ist das Protokoll (Kommunikation), und es verwendet wie viele andere RS485 (elektrisch) (vereinfacht, und es gibt noch ModBusTCP was normales Netzwerk ist was manche Geräte können). CAN ist ein anderes Protokoll.

    Programmiert wurde das von Peter aus dem OpenWB-Forum, ich hab aus seinem Code lediglich ein eigenständiges Projekt gemacht und baue jetzt weiter daran rum. Darum schreib ich auch immer dass ich der Maintainer und nicht der Author bin wenn ich es verlinke (und der Transparenz wegen) :)


    Ich verwende das ganze übrigends nicht zur Steuerung der Wärmepumpe (hier werkelt eine von iDM), dafür klebt ein SolarLog im Schaltkasten, dass per ModBus am WR und per Netzwerk an der WP hängt, da die WP keinen Support für RCT-Geräte hat, es macht praktisch eine "intelligente" Protokollübersetzung. Es ist recht flexibel aber ich weiß nicht ob es für deinen Einsatzzweck geeignet wäre (und es ist recht teuer).


    Der RCT-WR hat eine Schwelle unter der er generell aufhört, im Normalbetrieb die Battery zu verwenden, und zwar "Min SOC target" beispielsweise bei 30%, theoretisch könnte man die je nach Bedarf anpassen, aber damit betrifft man ja alle angeschlossenen Verbraucher (Er geht nur im Inselbetrieb unter diese Schwelle bis runter auf "Min SOC target (island)" bei deren Erreichen er bzw. das BMS abschaltet, ohne Sonne ist er dann ganz aus und startet wieder wenn es hell wird). Es gibt einige fertige Open-Source-Projekte die auch Schaltaktionen basierend auf Verlaufswerten ausführen können, das Protokoll von RCT ist ja nun bekannt und muss im Zweifel "nur" integriert werden. Auch die IP-Symcon kann AFAIR mit dem WR reden. Übrigends hab ich keinerlei Doku oder freie Implementierung gefunden, um mit dem RCT-WR via ModBus zu kommunizieren, das würde einiges einfacher machen, da die Fähigkeiten zur Netzwerkkommunikation des WR eher in die Kategorie "interessant" fällt und man den vielleicht nicht zwingend von überall erreichbar haben möchte.

    Oh, das ist ja spannend. Das würde bedeuten, dass die App die Werte einfach nur falsch ausgibt und sie korrekt vom Wechselrichter gesendet werden.

    Vermutung: Die App kommt im Export-Prozess mit zeitlich verschobenen Datenpunkten nicht zurecht. Ich habe beobachtet, dass der Wechselrichter manche Datenpunkte außerhalb des starren Rasters (bei Tageswerten genau 5 Minuten Abstand) ausgibt, beispielsweise eine halbe Minute daneben. Damit kann man es nicht einfach in eine Zeile mit den anderen Werten packen, sondern müsste genau genommen eine eigene Zeile ausgeben, die nur diesen Wert mit seinem Zeitstempel enthällt. Das Problem ist auch, dass die einzelnen Zeitserien jede für sich Zeitstempel hat, man fragt also mehrere Zeitserien ab um einen Export zu erstellen, und in dem Prozess muss man dann Datenpunkte anhand ihres Zeitstempels in eine Zeile zusammenpacken, aber einige Datenpunkte liegen daneben. Mein Tool aus dem vorigen Post (Doku) betreibt etwas Aufwand für diesen Fall, indem es die Werte ein wenig hin- und herbewegt und schaut ob sie dannach ins Raster passen, das ganze braucht aber Python. Für den Fall dass ich mit der Vermutung richtig liege könnte dir das also helfen.


    Danke für die Daten, ich schaue die Tage mal rein!


    Das SolarLog macht seine eigenen Statistiken, d.h. es liesst via ModBus (also nicht übers Netzwerk) die aktuellen Werte aus, es ist also eine spannende Angelegenheit das anzuschließen. Ich bin kein Experte was das SolarLog angeht, und nachdem ich es nicht geschafft habe programatisch Daten auszulesen habe ich es auf die PV-basierte Steuerung der Wärmepumpe reduziert und frage den Wechselrichter und die WP direkt ab. An anderer Stelle im Forum liesst es sich, als wären SolarLogs früher recht auskunftsfreudig gewesen, aber die aktuellen Modelle (hier werkelt ein Base 15) scheinen zunehmen darauf ausgelegt zu sein, Daten nicht mehr lokal, sondern über das Portal des Herstellers übers Internet darzustellen.

    Was im Portal geht weiss ich nicht, aber ich hab eben mal durch die Menüs des Geräts selbst geklickt, und der einzige Punkt der mir Verlaufsdaten in Textform gibt ist der Datenexport (eine Art Backup), der aktuell ein fast 10MB großes File (fast 6 Monate Betrieb) ausspuckt, es ist aber durchaus möglich dass ich was übersehen hab. Das Format ist meines Wissens prinzipiell bekannt und basiert auf CSV, bedarf aber einiger Interpretation, da die Position der Werte von der Konfiguration des jeweiligen Setups abhängt, einfach als Tabelle laden scheidet also aus. Ich hab es auch geschafft, das SolarLog durch kreatives klicken oder durch programmatischen Zugriff abzuschiessen, sodass es alle Daten verloren hat und frisch von Null aufgesetzt werden musste. Wenn man vorher Backups macht kann man die wieder einspielen, hat dann aber natürlich eine Lücke, und je nachdem wie lang die ausfällt sind die Summen anders. → Ich glaube nicht, dass du damit glücklich werden würdest.

    Möglichkeiten gibts manigfaltig, die Frage ist was du erreichen möchtest und wieviel Arbeit/Zeit oder Geld du reinstecken möchtest. Prinzipiell solltest du aber wissen, dass der Wechselrichter im Netzwerk völlig ungeschützt ist und jeder der ihn ansprechen kann hat vollen Zugriff.


    Die Android-App kostet nichts (bis auf das Smartphone) und bietet deutlich weitreichendere Möglichkeiten zum Anschauen, Einstellen und um die Statistiken auszulesen, ist aber recht fummelig und scheint nicht für Endbenutzer gedacht zu sein. (Beispiele: Google Bildersuche "rct power android app"). Vergangenheitswerte können nur Live aus dem Wechselrichter ausgelesen werden, die (5-)Minutengenauen Werte reichen also nur 90 Tage zurück, die Wochen/Monats/Jahres-Statistiken mehrere Jahre. Die App ist neben dem SolarLog die einzige mir bekannte offizielle Möglichkeit, Einstellungen im WR zu ändern.


    Das SolarLog ist vermutlich die teuerste Lösung, unterstützt nach meinem Kenntnissstand nur die Anbindung via ModBus (was völlig ausreicht, aber da man dafür den WR aufschrauben muss sollte man das vielleicht nicht unbedingt selbst anschließen) und bietet begrenzt Eingriff in einige wenige Settings (bspw. Leistungsreduktion) des Wechselrichters. Es kann auch Steuerungsaufgaben basierend auf den Werten die der WR liefert ausführen, so macht es auch wohl Peak-Shaving, was der WR selbst laut Aussage RCT nicht kann (Stand 2020Q3). Es schreibt seine eigenen Statistiken und macht Auswertungen, und kann bei kompatiblen Verbrauchern auch deren Verbrauchswerte mit darstellen (wenn alle beteiligten Komponenten unterstützt werden). Die im Wechselrichter gespeicherten Statistiken liesst es nicht aus. Die Daten aus dem SolarLog rauszubekommen (beispielsweise für eigene Auswertungen) ist bei den modernen Versionen schwer, alles ist darauf ausgelegt ins Portal des Herstellers geladen zu werden. An anderer Stelle hier im Forum und im Internet ließt man, dass die früheren Versionen hier deutlich einfacher und offener waren. Ich habe eine Zeitlang versucht, selbst Werte aus dem SolarLog auszulesen um sie selbst darzustellen, und habe dann lieber die angeschlossenen Komponenten (Wechselrichter und Wärmepumpe) selbst angezapft und nutze das SolarLog nur zum Steuern einer Wärmepumpe.


    OpenWB und IP-Symcon haben Netzwerkimplementierungen und können sowohl Werte auslesen und anzeigen als auch basierend auf den Werten Steuerungsaufgaben ausführen. Für die Solaranzeige ist eine Implementierung angedacht, wartet aber noch auf Dokumentation vom Hersteller. OpenWB greift meines Wissens nicht in die Settings ein, bei IP-Symcon habe ich nicht nachgeschaut.


    Wenn man selber Hand anlegen möchte: Aus der Implementierung in OpenWB ist auch ein eigenständiges Projekt hervorgegangen (Full disclosure: Ich bin der Maintainer), das auch Tools zum Auslesen von Einzelwerten sowie den Zeitserien, die der Wechselrichter selbst mitschreibt, mitbringt. Ich lese damit die (Tages)-Statistiken aus, schreibe sie in eine InfluxDB und stelle sie via Grafana dar. Wie OpenWB, IP-Symcon und Solaranzeige könnte das auf einem Raspberry Pi laufen.

    Eher den Flash. ROMs kannst du ja nicht verändern wie der Name schon sagt. Es kann durchaus sein, dass es Schnittstellen gibt mit dem Techniker das ganze wieder ans Laufen bekommen können ohne Bauteile zu tauschen. Aber es ist müßig darüber zu diskutieren ohne Rückmeldung.

    Der Wechselrichter versorgt sich aus den PV-Modulen sofern die genug Strom liefern und ansonsten aus der Batterie. Wenn du nachts den Batteristack ausschaltest (oder unter die Insel-Schwelle entlädst) geht der WR darum auch sofort aus und geht wieder an sobald die Sonne genug Strom liefert. Die Art seiner Energieversorgung steht AFAIK auch im Handbuch beschrieben.


    Wenn das BMS den Kontakt unterbricht weil es sein Update anwendet geht der Wechselrichter dementsprechend auch aus, denn seine einzige Energiequelle ist gerade versiegt. Das ist auch der Grund warum man die Erstinbetriebname nur machen kann wenn genug Strom geliefert wird. Im Normalfall geht der WR von selber wieder an, sofern die Aktion jetzt nichts kaputtgemacht hat.


    Generell gilt bei allen Geräten (nicht nur WR): Mitten im Firmwareupdate Strom aus ist das schlimmste was man machen kann und es kann alles von "Funktioniert" bis "Totalausfall, return to vendor" passieren.

    Ich hab grade eben auf meiner 2.3.5198er Version die Daten vom Januar (Tageswerte und Monatssummen) nochmal ausgelesen und mit meiner Influx verglichen und kann keine Abweichungen für Januar feststellen. Die Total-Werte sind bei mir fürs letzte Jahr aber teilweise inkorrekt, ich kam aber noch nicht dazu bei RCT deswegen nachzufragen. Ich lese das allerdings nicht mit der App (viel zu fummelig) sondern mit timeseries2csv.py (braucht aktuell den git head, Release kommt die Tage) aus. Nach meinem Wissensstand verarbeitet die App die Daten nicht, sondern reicht sie nur durch, d.h. die Daten werden vom Wechselrichter schon so geliefert wie sie später in der CSV stehen.


    Tritt das Problem erst seit dem Update der Firmware auf? Hast du ein Beispiel von Zeitbereichen (am besten mit Zahlen) bei denen du das Problem siehst?


    Technisches blabla: