Übertragene Werte springen immer wieder auf unplausible values

[64horsejam]

Hi, ich habe den Adapter an einen Deye 12k angeschlossen, und es werden auch Werte übertragen. Allerdings springen die Werte bei jeder zweiten oder dritten Aktualisierung auf absolut unplausible Values.

Beispiel: PV-Leistung in Watt: 1. Akt = 1200W (ok) ; 2. Akt = 1289W (ok) ; 3.Akt = 400000W (falsch) ; 4. Akt = 1270W (ok)

Das passiert mit allen Werten nach 2 oder drei Aktualisierungszyklen.

Da ich nicht wirklich bewandert bin in diesen Themen wäre ich für jede Hilfe dankbar. In irgendeinem anderen Thread hatte ich auch mal gelesen, dass "Beta-Tester" für den Deye gesucht werden... :-) Hier bin ich ...

Gruß Lukas

[tobiasfaust]

Moin Stell mal das LogLevel auf 5 und beobachte das Log im seriellen Monitor. im LogLevel 5 wird auch die Antwort des WR unformatiert ausgegeben. Wenn solch ein unplausibler Wert kommt poste mal bitte alles von kurz vorher bis kurz danach hier in einem codeblock. Als Vergleich bitte dasselbe auch mit einem funktionierenden Beispiel.

[64horsejam]

Danke für die schnelle Antwort... Aber Du hast es mit einem "unwissenden" zu tun. Ich kenne mich damit überhaupt nicht aus und verstehe zwar prinzipiell was Du haben möchtest, der Weg es zu bekommen ist mir aber unbekannt...

Besteht die möglichkeit sowas per Teams / Teamviewer oder ähnlichem zu machen?

[tobiasfaust]

Am einfachsten wenn du dir die Arduino IDE installierst und dann den ESP via USB anschließt und dann den seriellen Monitor startest, gibt aber Unmengen an HowTos dazu im Netz :) LogLevel in der weboberfläche des ESP ;)

[tobiasfaust]

auf der FAQ Seite gibt es jetzt einen Hinweis wie man auf der seriellen Konsole am besten debuggen kann

[crazy-ahmet]

Habe das gleiche Problem an einem 10kW Deye. Hab vor ca. 2 Wo über GitHub kompilierte Version aus dem Code der Seite hochgeladen. Im Webinterface steht es wäre Release 3.2.0

Oft wird 0 in den Werten angezeigt, das kann ich noch ausfiltern, manchmal aber auch grobe Schnitzer nach oben oder unten. Wenn das Haus z. B. rund 200W braucht und Peaks mit 24kW kommen sieht das in Grafana nicht mehr aus...

Das Gerät hängt bei einem Kumpel und liefert hier Daten übers Netzwerk. Serieller Monitor ist daher nicht so einfach, da müsste ich jedes mal dort hin. War heute mal da um zu gucken und habe auch die Stromquelle geändert. Vorher am Inverter mit Step Down Wandler, dann auch direkt mit Handynetzteil und USB-Kabel. Habe auch mal die RS485 Konverterplatine etwas vom ESP weg gebogen, hat auch nichts gebraucht. Sollte man am RS485 Bus vielleicht einen Endwiderstand setzen? Kabel sind aber nur 20cm lang.

Zudem ist das Teil auch nach 6 Tagen ausgestiegen, war lt. Router noch im WiFi, man kam aber nicht mehr aufs Webinterface, mal sehen ob er das wieder macht...

[tobiasfaust]

Leider steht in der Modbus Doku des Deye nichts von Timings. Es kann gut sein das diese für den Deye angepasst werden müssen. Als erstes und als einfachste Einstellmöglichkeit würde ich das Updateintervall bei den Modbuseinstellungen hochsetzen auf mindestens 3, besser 5 Sekunden.

Wenn das nicht hilft muss der timing zwischen request und empfangen leicht erhöht werden, Modbus.cpp Zeile 450

[crazy-ahmet]

Danke für die Rückmeldung. Das Intervall habe ich schon höher gestellt und nie unter 5s gehabt. Leider ist die Datei ja nicht übers Webinterface unter Files änderbar. Habe jetzt im Code das geändert und als Pull Request angelegt obwohl ich gar nicht genau weiß was das ist. Habe es ja über Github kompilieren lassen und dann die paar Dateien die da rauskamen geflasht, anders weiß ich gar nicht wie es geht. Bekomme ich da dann jetzt eine Freigabe dass ich da genauso draufklicken kann und es kompilieren kann?

[tobiasfaust]

Das musst du mit gitpod nach Anleitung machen. Dort anpassen, kompilieren und auf deinen esp flashen. Und dann schauen ob es etwas bringt

[crazy-ahmet]

Hab das vor 2 Tagen angepasst. Timing war in Zeile 418 und nicht 450. Habe die +100ms auf +115ms gestellt, dann alles kompiliert und dann lediglich über Webinterface die neue firmware.bin hochgeladen da ich das aus der Ferne machen konnte ohne dass der ESP am USB hängen muss. Ich hoffe die anderen 3 Dateien hätten nicht auch komplett neu geflasht werden müssen. Jedenfalls funktioniert es leider noch immer nicht. Noch immer sind 0 Werte dabei und manchmal auch ganz Falsche. War die Timingerhöhung genug? Gabs denn mal ne funktionierende ältere Version?

[Teslaforce]

Ich habe exakt das gleiche Problem mit den springenden und umplausiblen Werten. Und das schon lange. Seit heute hab ich mal wieder alles angeschlossen und den miesen WLAN Empfang bereinigt. Ich nutze die Daten zum Überschuss laden. Witzig ist das er in der Weboberfläche immer mal mit den Werten springt aber in meinen anderen Programm ein teilweise völlig anderer Wert Ausgelesen wird.

Statt 1123W 315W, teilweise stimmt es dann auch wieder. Ich bin auch am ende mit meinen Know How.

Ich habe bis jetzt immer die Einbindung direkt über den WR genutzt. Problem ist aber das der Abfragezeitraum mit 5 Minuten zu lang ist. Dies führt mitunter dazu das ein hoher Wert fürs Laden angenommen wird. Kommt dann eine Wolke hat die Batterie extremen Stress dies zu kompensieren. (aktuell noch Insel Anlage)

[tobiasfaust]

Das Setzen der Timings war eine Idee und Schuss ins Blaue. Ist das Verhalten nur beim Deye so? Welche Register sind es genau die springen? Sind es welche die auch negative Werte annehmen können? Ist ggf die Registerdefinition falsch bzw muss geringfügig angepasst werden?

Zur Untersuchung brauche ich einen korrekten RAW-String sowie einen "defekten". Diese bekommt man entweder über die Weboberfläche (RawData Seite -> Entwickleroptionen -> Konsole -> den letzten XHR - Ajax Aufruf auswählen -> Antwort) oder per serielle Konsole und LogLevel 5

Die Registerdefinition des Deye hat ein anderer User mir zukommen lassen. Ich selbst habe keinen und kann daher nur bedingt helfen.

[crazy-ahmet]

Ich benutze das nur für den Deye, andere Geräte habe ich nicht zur Verfügung. Kann man hier keine PN schreiben? Ich würde Dir einen Fernzugriff auf das Teil einrichten dann kannst selbst über die Weboberfläche schauen...

[MagicSven81]

Wichtig ist, den ESP beim Deye Wechselrichter am BMS Port einzustecken und nicht am Modbus Port. Auch wenn der "Modbus" Port erst einmal logisch klingt, so ist der korrekte RS485 Anschluss auf den Pins 1+2 des BMS Steckers.

Sollte hier bereits ein Batterie Management System (BMS) einer Batterie angeschlossen sein, so kann ein RJ45 Y-Splitter mit 1:1 Belegung verwendet werden, da sich wie oben geschrieben auf Pin 1+2 die RS485 Schnittstelle und auf Pin 4+5 der CAN-Bus befindet.

Überprüfe daher bitte einmal, wie der ESP bei dir angeschlossen ist.

[Teslaforce]

Das klingt spannend, werde ich mal probieren. Kann man ggf. gleich vom pylontech akkupaket das Modul anstecken? wäre mal interessant ob das klappen würde.

[Teslaforce]

Ich habe einen 1:1 Adapter organisiert und wie beschrieben a den BMS Port gesteckt. Ausgang 1x Batterie 1X Adapter. Leider kommen nun gar keine Werte mehr. Dies scheint also auch nicht zu funktionieren. Die Kommunikation mit der Batterie vom Deye aus funktioniert aber weiterhin.

Muss noch etwas eingestellt werden? Ich bin langsam am Ende mit dem Teil…

[crazy-ahmet]

Also ich finde diese Port Info unlogisch. Es funktioniert ja am Modbus Port, nur eben manchmal 0 Werte oder starke Ausreißer. Das lässt sich bestimmt in den Griff bekommen, verstehe nur nicht viel von Timings und so, weiß aber dass andere die Teile doch auch über normale Modbus TCP Bridge auslesen. Muss hier nochmal mit Tasmota basteln aber das Projekt hier gefällt mir sehr gut da die Werte schon alle auf ner Webseite angezeigt werden und man die gewünschten einfach per MQTT schicken lassen kann.

Anbei nochmal die Port Belegung aus dem Manual des Deye. Macht also eigentlich keinen Unterschied ob Modbus oder BMS Port. Belegung ist ja gleich. Da RS-485 immer als Kette angeschlossen werden muss könnte ich mir höchstens Probleme vorstellen bei langen Kabeln aber ich hab da ohnehin nur 20cm dran.

Vielleicht mag @tobiasfaust ja dochmal in meinen Fernzugriff reinschauen und es hilft wenn er sieht was da schwankt und bekommt raus warum?

[tedesco1968]

Hallo, Ich habe auch einen deye und die gleiche Probleme, habe mir auch so ein splitter gekauft und das ganze am bms port probiert. Leider auch erfolglos wobei seltsamerweise ich es auch direkt am bms port des Deye probiert habe und direkt funktioniert es ohne Probleme (RS485 port 1 und 2). Kann ich allerdings nicht ganz nachvollziehen denn über den splitter 1:1 müsste es dann auch funktionieren tut es aber nicht! Ich habe am bms port pylontech batterien auf Can, somit dürfte es dort, sowieso keine Probleme mit den RS485 port geben. Habe dann zum testen auch 7 und 8 getestet mit dem gleichen Resultat. Also nochmals, das ganze funktioniert bei mir ohne aussetzer wenn es am bms port angeschlossen wird. Leider brauche ich diesen für die Batterie Kommunikation Can Pylontech. Splitter 1:1 funktioniert den die Pylontech Batterie geht damit. Villeicht muss man noch den minus, 3 oder 6 noch an den esp32 anschließen. Werde ich noch testen, ansonsten bin ich ratlos

[tobiasfaust]

Schonmal in Erwägung gezogen das die Deye Firmware buggy sein könnte? Erst recht wenn es ohne BMS funktioniert und mit BMS eben nicht….

[tedesco1968]

Wichtig ist, den ESP beim Deye Wechselrichter am BMS Port einzustecken und nicht am Modbus Port. Auch wenn der "Modbus" Port erst einmal logisch klingt, so ist der korrekte RS485 Anschluss auf den Pins 1+2 des BMS Steckers.

Sollte hier bereits ein Batterie Management System (BMS) einer Batterie angeschlossen sein, so kann ein RJ45 Y-Splitter mit 1:1 Belegung verwendet werden, da sich wie oben geschrieben auf Pin 1+2 die RS 485 Schnittstelle und auf Pin 7+8 der CAN-Bus befindet.

Überprüfe daher bitte einmal, wie der ESP bei dir angeschlossen ist.

Hallo Magicsven, Welche Deye Version hast du denn drauf?

[MagicSven81]

Die Deye Version läuft gut und stabil. Habe sie selbst mit 1:1 Splitter bei mir seit 4 Monaten in Betrieb. Wichtig ist, dass das BMS der Batterie über CAN an Pin 4+5 läuft und das Modul an Pin 1+2

Ich musste nach dem anschließen lediglich den Deye einmal neu starten. Keine Ahnung warum aber erst danach ging es. Dann aber wie gesagt bisher ohne Probleme und ohne 0-Werte oder Sprünge wie sie am Modbus Anschluss vorkommen können.

HMI: Ver 1001-C03E MAIN: Ver 2005-1144-1807

[MagicSven81]

Schonmal in Erwägung gezogen das die Deye Firmware buggy sein könnte? Erst recht wenn es ohne BMS funktioniert und mit BMS eben nicht….

Nein Tobias, bis auf die falsche Umrechnung der Ampere im DC Bereich (zeigt 0,9A anstelle 9A an) ist da nichts buggy. Und den Fehler kann man selbst ja einfach korrigieren.

[MagicSven81]

Nachtrag:

Ich habe an meinem Splitter übrigens die Pins entsprechend entfernt.

Am Anschluss der Batterie habe ich Pin 1+2 entfernt und am Anschluss vom ModbusModul habe ich Pin 4+5 entfernt. Einfach zur Sicherheit dass da nichts doppelt kommt.

[Teslaforce]

Das mit den Kontakte entfernen werde ich gleich mal versuchen.

Wie kann ich prüfen ob der Adapter an Pin 4 und 5 hängt? (ich habe ihn "fertig" gekauft) Die Werte nimmt er vom DEYE ja an Pin 1 und 2 ab richtig?

Welches File von den 18 Stück unter Assets muss ich downloaden und ein update auf 3.2.0 zu machen?

[tobiasfaust]

Nein Tobias, bis auf die falsche Umrechnung der Ampere im DC Bereich (zeigt 0,9A anstelle 9A an) ist da nichts buggy. Und den Fehler kann man selbst ja einfach korrigieren.

sag mir einfach was am json file geändert werden muss. Ansonsten steht jeder vor dem Problem es zu bestehen und anzupassen ;)

[Teslaforce]

Laut Foto und Beschriftung auf dem Adapter sind doch auch die Pins 1 + 2 am BMS Port entfernt?

[tedesco1968]

Hallo Magisven,

Laut bms anschlussbild im Handbuch ist 4-5 Can und 1-2 B_485 A_485 und 7-8 A_485 B_485 und anschluss 6 485_GND. Übrigens habe ich die Firmware Version 1140 drauf, die aktuellste ist die 1144 die werde ich mal flashen und das ganze wieder testen. Klar das mit dem herunterfahren scheint auch logisch zu sein, wird es aber sowieso beim flashen. Ich teste und gebe bescheid

[MagicSven81]

Nein Tobias, bis auf die falsche Umrechnung der Ampere im DC Bereich (zeigt 0,9A anstelle 9A an) ist da nichts buggy. Und den Fehler kann man selbst ja einfach korrigieren.

sag mir einfach was am json file geändert werden muss. Ansonsten steht jeder vor dem Problem es zu bestehen und anzupassen ;)

"name": "PV1DCCurrent", "realname": "PV1 DC Current", "datatype": "float", "factor": 0.01, "unit": "A"

Den Faktor bei PV1, PV2, PV3 DC Current von 0.01 auf 0.1 ändern.

[MagicSven81]

Laut Foto und Beschriftung auf dem Adapter sind doch auch die Pins 1 + 2 am BMS Port entfernt?

Sorry - natürlich Pin1+2 // ich war gedanklich gerade beim Solax Wechselrichter, der ist auf Pin4+5

Also Pin1+2 ist beim Deye RS485. Danke für die Korrektur @Teslaforce

[tobiasfaust]

Den Faktor bei PV1, PV2, PV3 DC Current von 0.01 auf 0.1 ändern.

Danke, ist eingecheckt

[B10S-github]

Hi Tobias, erstmal vielen Dank für die Entwicklung des Programms, das war bei mir der ausschlaggebende Grund mich für einen SolaX-X3 WR zu entscheiden. Mit der neuen Version 3.2.0 habe ich das gleiche Problem: Die Werte springen immer mal wieder auf extrem hohe Zahlen. Vorher hatte ich die Version vom November 2023 in Betrieb (da stand in der Weboberfläche noch keine Version), da sind die Datensprünge nicht aufgetreten. Das ganze läuft auf einem Wemos S2 mini, was leider das Debug über Konsole quasi unmöglich macht, da der die Serielle Schnittstelle über USB nur im Download Modus aktiviert. Vielleicht hilft aber schon der Hinweis, dass es nicht nur Deye WR betrifft und es das Problem früher nicht gab. Grüße aus Berlin :)

[tobiasfaust]

ich bin etwas ratlos. Ich habe natürlich auch die aktuelle Version im Einsatz mit einem Solax-X1. Anbei mal ein Screenshot des Readings "GridPower". Die 2 Sprünge die zu sehen sind sind beim Einschalten und Ausschalten des WR, sonst sind die Werte durchgängig sauber. Deswegen ist es für mich das Problem leider nicht nachzuvollziehen.... Weiterhin habe ich seit sehr langer Zeit nichts mehr am Kern, also der Modbuskommunikation geändert. Alle Änderungen betrafen ausschliesslich das Frontend und Web-handling.

Ich kann nur nochmal auf Posting 2 von oben verweisen. Ohne dieses bin ich blind und alles sind nur mutmassungen. Oder mal eine ältere Version aus den Releases oder assets aus den Actions verwenden um das Verhalten auf eine Änderung im Code zurückzuführen. Merkwürdig ist auch das nicht nur ein Wert sondern alle(!) Werte auf einmal springen..... Zum reinen Testen kann ich auch empfehlen einn 2ten ESP incl ModbusModul anzuschaffen. ;)

[B10S-github]

Ich sehe bei mir bei den oberen Items (aus der Item Config Liste) eigentlich keine Ausreißer, also GridPower, GridCurrent, GridFrequency,... auch die Batteriewerte springen nicht. Was ich heute auch festgestellt habe, dass der RawData Block manchmal kürzer ist und sich damit die hinteren Werte verschieben. Eigentlich sollte der doch immer die gleiche Länge haben, korrekt?

[tobiasfaust]

Das ist ein guter Hinweis. Die Länge sollte immer identisch sein ansonsten passt ja auch das Mapping nicht mehr. Jetzt wäre es gut, die Ausgabe der Serien Konsole zu haben ;) Die Frage ist, welche Werte an welcher Stelle fehlen.

[tobiasfaust]

noch 2 Ideen zum Testen: 1) bitte nutze, falls es nicht schon so ist, die "echten" HardwareserialPins laut Pinout deines ESP32. Da musst du genau schauen welches Modell du hast und dann im Netz das passende Pinout dazu suchen 2) stelle mal im Web -> Modbus den Wert "Intervall Live Datatransmission" auf 10 und dann ändere mal im Code modbus.cpp, zeile 1008, folgendes: alt:

//its allowed to send a new request every 800ms, we use recommend 1000ms
  if (millis() - this->LastTxInverter > 1000) {

neu

//its allowed to send a new request every 800ms, we use recommend 1000ms
  if (millis() - this->LastTxInverter > 2000) {

eventuell auch das timing ändern aus Post https://github.com/tobiasfaust/SolaxModbusGateway/issues/43#issuecomment-2059727200

Am besten über gitpod (Anleitung siehe Wiki) ändern, kompilieren und firmware neu flashen. Die littlefs frauchst du nicht für diesen Test flashen

[crazy-ahmet]

Also am Deye Inverter sun-10k-sg04lp3-eu funktioniert es nun ohne dass 0-Werte kommen oder die Werte stark springen. Die Lösung ist tatsächlich, dass man den BMS Anschluss für die RS485 Verbindung benutzen muss. Am Modbus Port gibt es immer wieder diese Ausreißer. Ich habe hier den BMS Port frei da ich ihn nicht für einen Akku brauche. Werde bei einem anderen Inverter probieren den RS485 frei zu bekommen und versuchen den Akku per CAN Bus laufen zu lassen.

[tedesco1968]

Ich kann das nur bestätigen, ich haben 12k Deye am bms port ohne aussetzer. Allerdings benötige ich diesen für die CAN Verbindung der Pylontech Batterien. Über den Splitter funktioniert die Batterie aber der Gatway nicht

[MagicSven81]

@tedesco1968 - daher meine Empfehlung, am 1:1 RJ45 Splitter die nicht benötigten Pins zu entfernen. Siehe Beitrag weiter oben.

Ich nutze den Splitter um mein BMS der Batterie (Seplos BMS) nur über Pin 4+5 & das ModbusGateaway nur über Pin1+2 anzuschließen.

Da das Seplos RS485 als auch CAN beherrscht kann es sein, dass dir die RS485 Signale des Seplos sonst dazwischen funken.

Theoretisch würde es sogar reichen, am Anschluss des BMS der Batterie die Pins 1+2 zu entfernen.

[tedesco1968]

@MagicSven81
Das mit dem Splitter habe ich doch getestet CAN liegt aber auf 4 und 5 beim Deye. Ich habe die Drähte an den lötpunkte des splitters direkt abgeschnitten 7, 8 und 3. Somit liegt am splitter nur 1,2,4,5,6 an.

Batterie geht immer, Gateway nur wenn direkt am Bms port eingesteckt wird, am splitter nicht, versteh das nicht

[B10S-github]

noch 2 Ideen zum Testen:

1. bitte nutze, falls es nicht schon so ist, die "echten" HardwareserialPins laut Pinout deines ESP32. Da musst du genau schauen welches Modell du hast und dann im Netz das passende Pinout dazu suchen
2. stelle mal im Web -> Modbus den Wert "Intervall Live Datatransmission" auf 10 und dann ändere mal im Code modbus.cpp, zeile 1008, folgendes: alt:

//its allowed to send a new request every 800ms, we use recommend 1000ms if (millis() - this->LastTxInverter > 1000) { neu

//its allowed to send a new request every 800ms, we use recommend 1000ms if (millis() - this->LastTxInverter > 2000) { eventuell auch das timing ändern aus Post #43 (comment)

Am besten über gitpod (Anleitung siehe Wiki) ändern, kompilieren und firmware neu flashen. Die littlefs frauchst du nicht für diesen Test flashen

• Intervall Live Datatransmission auf 10 gestellt, hat nichts gebracht
• LastTxInverter von 1000 auf 2000 hab ich jetzt gemacht und geflasht, warten wir mal bis morgen, wie bis dahin aussieht.

Könnte man nicht auch generell erstmal gucken, ob der empfangene Datenblock die passende Länge hat und falls nicht, den einfach verwerfen? Also lieber ein Interval keine Daten bekommen, als falsche.

[tobiasfaust]

Doch kann man, die Routine um die checksumme des gelesenen datenblocks zu prüfen ist aber noch nicht eingebaut. Das verwischt aber nur die Symptome, beseitigt die Ursache aber nicht.

Ich möchte aber Trotzdem nochmal auf Posting 2 verweisen. Ohne beispieldaten und Logs funktioniert nix.

Hast du auch auf echte Hardwarepins gewechselt?

[B10S-github]

Noch nicht, da der S2 mit dem Modbus Modul auf nem PCB verbaut ist und ich dazu erst nen paar Sachen umbauen muss. Die Anpassung des LastTxInverter Intervals war auch nicht die Lösung. Ich würde jetzt noch mal das Timing anpassen (Post #43) und wenn das nichts bringt, puzzle ich das Ding noch mal auseinander um an die Serial Pins ran zu kommen

[tobiasfaust]

Nimm mal einen einen neuen, am besten einen ESP-32 Wroom plus eines der Modbus Module. Kostet nur insgesamt um die 10€ und kann damit auch gleich einen Hardware Defekt ausschließen

[B10S-github]

Sooo, also Timing anpassen hat auch nicht geholfen, aber ich hab die Serielle Konsole zum Laufen gebracht, hier der LogOutput - Eine Anfrage mit Fehler (Nr.2) und der Durchlauf davor und danach (1+3). debug log 1 (ok).txt debug log 2 (nok).txt debug log 3 (ok).txt debug log 1+2+3.txt

Achso und ich hab die unangepasste Master 3.2.0 wieder geflasht gehabt

[tobiasfaust]

ich habe es mir mal angesehen. Dein WR sendet irgendwelchen Müll zurück der überhaupt nicht auf das Modbusprotokoll passt Das siehst du schon an den ersten 2 bytes. Das erste Byte ist die anfragende ClientID, das zweite Byte der Function code. Müsste bei dir mit den LiveDaten immer(!) "0x01 0x04" sein. Es ist aber "0x40 0x90". Streng nach Protokoll ist das die Antwort auf die Anfrage eines Clients mit der ID 64. Der FuntionCode 0x90 ist der Hinweis auf eine fehlerhafte "WriteMultipleRegister" anfrage. Allerdings passt die restliche Länge dann nicht. Dürften nur noch 3 Bytes danach kommen und nicht 240.

Würde der WR korrekt nach Protokoll einen Fehler senden so wäre das zweite Byte 0x84, dann würde ich den Wert auch verwerfen.

Request queue data to inverter: 0x01 0x04 0x00 0x78 0x00 0x77 0x30 0x35 
Read Data from Queue: 
0x40 0x90 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x07 0x2C 0x00 0x00 0x07 0x30 0x00 0x00 0x07 0x36 0x00 0x00 0x50 0x9E 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x5D 0x00 0x00 0x48 0x0B 0x00 0x00 0x00 0x8B 0x00 0x00 0x03 0xE7 0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0xDA 0x00 0xCB 0x0D 0x2E 0x0D 0x05 0x00 0x00 0x00 0x64 0x01 0x6A 0x00 0xBA 0xFF 0xE0 0x00 0xD0 0x00 0x63 0x00 0x63 0x00 0x63 0x00 0x62 0x13 0x88 0x09 0x42 0x09 0x45 0x09 0x5A 0x09 0x29 0x00 0xE9 0x00 0x4D 0x00 0x4C 0x00 0x50 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0F 0xA8 
Dataframe valid, Dateframe size: 242 bytes

Ich würde mal sagen seine Optionen sind folgende zum testen:

• vieleicht den falschen WR-Port benutzt?
• andere gpio Pins beim Gateway einstellen
• eine ältere Gateway Firmware Version testweise aufspielen
• falls eine Batterie dran ist, diese testweise komplett abziehen
• einen anderen Full-ESP32 nehmen

[tedesco1968]

Hallo zusammen,

Da ich keine Ruhe geben kann, das Gateway funktioniert 100% wenn er auch saubere Daten bekommt. Beim Deye ist es am BMS Anschluss, an 1,2 oder 7 und 8, die sind eh durchgeschleift. Wer den CAN benötigt der befindet sich an Kontakt 4 und 5. Ich habe das jetzt heute mit 2x RJ45 Schraubklemmenadapter von Amazon (10€) und ein abgeschnittenes Netzwerkkabel realisiert, sieht nicht schön aus aber funktioniert 100%.

Am RJ45 Schraubklemmenadapter für den Modbus-Gateway 1 und 2, Gelb/Weiß und Gelb. Am RJ45 Schraubklemmenadapter für die Batterie 4 und 5, Blau und Blau/Weiß

[tedesco1968]

[tedesco1968]

Hier nochmal die Probe:

So sah es vorher aus:

So sieht es jetzt aus:

[tedesco1968]

Ich denke jetzt sind alle unklarheiten beseitigt :-), es gibt kei Fehler in der Software (Modbus-Gateway).

Tobias vielen Dank nochmals für dein tolles Projekt

[B10S-github]

Ich hab mein Problem quasi auch gelöst. Habe jetzt in der modbus.cpp noch ne Abfrage eingefügt, die den DataFrame auf die richtige Größe prüft. Zwar nicht so schön, wie ne Checksummenprüfung oder dauerhaft korrekte Daten vom WR zu erhalten, aber besser als in FHEM jedes mal auf Plausibilität zu prüfen und zu korrigieren. Heute den ganzen Tag keine Ausreißer gehabt. Achtung, die 488 stimmen vermutlich nur beim Solax X3 WR.

[tobiasfaust]

Sehr gut. Zumindest als workaround das es erstmal funktioniert. Ich kann dir trotzdem nur empfehlen in Ruhe auf Ursachenforschung zu gehen, siehe meine Punkte oben. Abgesehen davon ist es mir völlig unverständlich warum du diese Probleme hast. Ganz viele andere Solax-X3 User haben absolut keine Probleme….

Ich habe auf meiner ToDo Liste jetzt auch noch eine CRC Prüfung als Wahloption hinzugefügt. Per Default muss diese ausgestellt sein da man ansonsten Fehler nicht mehr sieht. Nur deshalb ist @tedesco1968 darauf gekommen den anderen RS485 Port zu nehmen.