SDM630 + EW11 ab und zu 0 Readings

[ArekS]

Hallo,
dank guter Doku konnte ich mich recht schnell in die Solaranzeige einfinden und das SDM630 Smartmeter iVm einem EW11 WLAN Adapter in Solaranzeige einbinden.

Leider ist mir dann aufgefallen, dass immer mal wieder eine 0 ausgelesen wird. Gefühlt am häufigsten beim Leistungsfaktor, aber auch mehrmals am Tag bei der Leistung, oder Phasenbezogenen Leistung oder Spannung usw.
Das zerhaut natürlich die schönen Diagramme.

EW11 ist im Grunde genommen so eingestellt, wie bei einigen Screenshots hier im Forum zu finden. Ich habe verschiedene Baudraten probiert und auch verschiedene Einstellungen vom EW11, größere Buffer Einstellungen usw. Ggfl. ist es mal häufiger, mal weniger häufig, schwer eine Aussage zu machen ohne eine Statistik zu erstellen, aber bei jeder Einstellung bleibt das Problem.

Hat jmd noch eine Idee was ich probieren könnte? Ansonsten würde ich gerne im Auslese-Script bei einer gelesenen 0 verhindern, dass die Daten zur Influx geschrieben werden. Ich glaube die Logik dazu ist aber eher in der phpinc/funktionen.inc.php zu suchen als in der SDM630_meter.php.


Background:
Ich habe die Solaranzeige als virtuelle Debian Maschine auf einem ESXi Server laufen. Als Multiregler Variante. Und neben dem SDM630 noch einen Huawei WR mit S Dongle.

Grüße
Arek

[mfkmfriedrich]

Hi ArekS,
ich betreibe einen GrowattSPH4600 mit SDM630V3-Smartmeter.
Bei meiner Dashboard-Eigenbastelei ist mir aufgefallen, dass ich den aktuellen Stromverbrauch gar nicht vom Wechselrichter bekomme. Der SPH4600 hat selber eine RS485-Schnittstelle zum SDM630. Aber den aktuellen Stromverbrauch kann ich ja nur über das SDM630 erhalten.
Mit meinem Raspi ziehe ich aber die Daten nur vom SPH4600 mittels des $Reglers="48" (das ist die growatt.php). Nun weiß ich nicht genau, ob ich auch zwei Regler hintereinander abfragen kann, dh. z.B. erst den $Regler 48 (also den WR) und dann noch den $Regler des SDM630.
Du hast ja scheinbar einen anderen Wechselrichter, kannst aber - so habe ich Deinen Beitrag verstanden - die Daten des SDM630 auslesen.
Welche Regler-Nr. nutzt Du dazu und machst Du das auch mit Solaranzeige oder hast Du da irgend eine andere Vorgehensweise, die ich noch nicht kenne?
Danke im Voraus für eine Reaktion.
MfG
Michael

[ArekS]

Hallo Michael,

bei dir redet der Growatt bereits mit dem SDM in einer Master-Slave Beziehung. Es ist mWn nicht möglich nun mit Solaranzeige zusätzlich den SDM auszulesen, da sich dann 2 Master in die Quere kommen.

Bei mir ist die Konstellation anders, der Huawei WR arbeitet eigenständig und weiß nichts von dem SDM. Ich habe quasi 2 separate Mod-Busse die nichts voneinander wissen.

Grundsätzlich kannst du 6 Regler abfragen, wenn du die Solaranzeige als Multiregler Version laufen lässt, dazu müssen ein paar Dateien angepasst werden, die Anleitung ist hier im Forum im entsprechenden Bereich.

Grüße
Arek

[ArekS]

Hat denn sonst niemand das Problem?

Ich habe inzwischen 2 weitere Zähler in die Installation eingefügt. Die neuen SDM120 werden übrigens prima mit SDM230 Regler gelesen (habe auch beide Modbus Register Dokus verglichen, das sollte alles so passen).

Und auch hier habe ich das selbe Problem.

Habe eine Statistik über die Leistung gezogen, im Durchschnitt 1x 0 gelesen pro Stunde. Insgesamt kommt der Fehler aber öfter vor, da andere Kanäle auch betroffen sind.

Hier ein Screenshot der Sache:

[gzi]

… Es ist mWn nicht möglich nun mit Solaranzeige zusätzlich den SDM auszulesen, da sich dann 2 Master in die Quere kommen.
…

Mit Modbus TCP kann es mehrere Master/Clients geben.
Unterstützt die Reglerdatei für den SDM630 auch Modbus TCP?

[ArekS]

Ja, beim SDM630 und auch SDM230 Regler gibt es die Option "HF2211=true" und mit entsprechendem Adapter wird es dann TCP fähig.

Ein Master mehrere Clients sehe ich keine Probleme, so habe ich es ja auch im Betrieb.

Die Geschichte mit Wechselrichter (Master) ist mit Smartester (Slave) verbunden und nun möchte man ZUSÄTZLICH per Solaranzeige auch Master spielen sehe ich persönlich schwierig. Die Abfragen dauern teilweise 3-8 Sekunden je nach Teilnehmer. Die Wahrscheinlichkeit, dass es zu parallel Abfragen durch einen 2. Master kommt sehe ich schon als hoch an. Und ich glaube sowas wie Kollisionserkennung etc. gibt es bei Modbus nicht.

Aber ich meine zu dieser Fragestellung gibt es hier im Forum schon etliche Threads, dort sind solche Diskussionen besser aufgehoben. Hier soll es um Fehler beim Lesen eines SDM630/SDM120 Smartmeter gehen.

[ArekS]

So, nachdem ich nun ca. 2 Wochen intensiv den Fehler gesucht habe:
-mit WLAN experimentiert habe
-versucht habe GND vom Zähler mit GND vom EW11 zu verbinden
-CAT7 Kabel mit Schirmung probiert habe
-verschiedene Abschlusswiderstände probiert habe
-meinen Schaltschrank halb zerlegt habe
-mit Oszi das Bus-Signal angeschaut habe
-verschiedene Einstellungen/Timings/Baudraten/usw. probiert habe
-TCP/IP Kommunikation mit Wireshark mitgeloggt habe
-RS485 Nachrichten mitgehört habe und selbst verschickt habe (PComm Terminal Emulator von Moxa oder Hercules von HW Group ist da ganz gut)
-Testaufbauten außerhalb vom Schaltschrank
-Profi RS485/Ethernet Gateway von Moxa NPort 5130 probiert habe
-und schlußendlich den Code von Solaranzeige zum Auslesen analysiert habe

..habe ich das Problem erkannt und gelöst.

Ich habe recht viel Zeit verschwendet, weil ich dachte der Fehler wäre bei WLAN (schlechtem Empfang), evtl. nicht schnell genug für die vielen kleinen Abfragen oder EMV Problemen wegen Störungen im Schaltschrank oder wegen dem Homematic Funkmodul nebenan, zu suchen. Zwischendrin fand ich auch heraus, dass das EW11 Gateway trotz 5V bis (glaube) 30V Spec., bei 5V nicht so wirklich gut funktioniert. Die LEDs leuchten zwar, aber erst ab grob 5,6V war es willig sich am DHCP Server zu melden.

Aber schlußendlich habe ich festgestellt, dass der Code zum Auslesen von den SDM Smartmetern nicht ganz optimal ist. Somit kann ich mir eigentlich kaum vorstellen, dass ich der einzige bin, der über dieses Problem stolpert. Ich werde aber versuchen dem schönen Projekt etwas zurückzugeben und erklären. Ich bin kein guter PHP Programmierer. Vielleicht schaut sich Ulrich den Code noch Mal an und macht ein Update.

Beim Sichten vom Code war ein Gedanke von mir, was passiert eigentlich mit dem CRC Check der vom Smartmeter mitgeschickt wird. Beim Senden muss man ja den CRC Erzeugen und mit rausschicken, ansonsten wird die Nachricht vom Smartmeter verworfen. Andersrum obliegt es dem Programmierer sich um die Auswertung zu kümmern. Leider wird im Code der CRC nicht ausgewertet. Bei EMV Fehlern, bzw. entsprechende Übertragungsstörungen sollten über CRC erkannt werden. Und die Nachricht sollte neu angefordert werden.


Hier der orig Code.

Das Prinzip ist wie folgt:
-Buffer (also die Nachrichten über RS485 vom Gateway) lesen und löschen
-den Abfragebefehl an Smartmeter schicken
-kurz warten
-Buffer lesen und das gelesene von Binärsystem ins Hexasystem umwandeln
-Wenn 00 am Anfang vom Buffer steht UND 00 am Ende, dann passt das und die Nachricht wird zerlegt und ausgewertet (dies war bei mir nie der Fall, evtl. mit einem anderen Adapter als EW11 oder vielleicht wenn man direkt per USB ausliest?)
-Wenn am Anfang vom Buffer erst die passende Slave ID und anschließend der Funktionscode steht, dann passt es und die Nachricht wird zerlegt und ausgewertet. (diese IF Schleife war bei meiner Kombi relevant. Erklärungen zu SlaveID und Funktionscode sind ganz gut im SDM630 Modbus Register PDF erläutert)
-Wenn im Buffer ein Inhalt ist, der aber nicht passt, wird ein weiteres Mal probiert den Abfragebefehl rauszuschicken (oberste FOR Schleife)
-Wenn im Buffer nichts drin steht (keine IF Abfrage trifft zu), wird kurz gewartet und neu gelesen (2. FOR Schleife)

Da ich Gedanklich noch bei EMV Problemen hing, hielt ich es als ersten Schritt für eine gute Idee die CRC Check Funktion nachzurüsten:

-Wenn also am Anfang vom Buffer die passende Slave ID und anschließen Funktionscode drin steht, folgt eine weitere IF Abfrage ob der vom Smartmeter gesendete CRC Check zum errechneten CRC Check der empfangenen Nachricht passt. Falls nicht, erfolgt eine neue Zählerabfrage.

Zunächst dachte ich, das Problem ist gelöst, da ich keine 0 Readings mehr bekam.
Doch dann fiel mir auf, dass ich wirklich sehr oft CRC Fehler im Log habe. Zusätzlich bemerkte ich, dass ich teilweise über 10min gar keine fehlerfreien Durchläufe habe und damit 10min Pausen ohne Daten in der Influx Datenbank...

Nach weiter Analyse und weiteren eingefügten $this->log_schreiben... stieß ich aufs nächste Problem..

..to be continued..

morgen/übermorgen gehts weiter im Text. Ich werde dann auch die Tage meinen aktuellen Code posten. Für Nachmacher. Oder für ein Update.

[ArekS]

weiter gehts..

Bei den CRC Checks hatte ich bereits Log-Einträge zu Abfrage Message und Ergebnis Message. Dort ist mir aufgefallen, dass die Ergebnisse, bzw. die gelesenen Bufferinhalte oft unvollständig waren. Eigentlich kamen CRC Fehler fast ausschließlich bei unvollständigen Buffern.

Ich machte mir Gedanken zum Ablauf/Logik beim Auslesen und stellte fest, wenn, der Anfang vom Buffer passt (siehe letzter Post), dann akzeptiert der Code die Antwort und versucht sie weiter zu verarbeiten. Ich fragte mich was im Buffer stehen würde, wenn man noch 1-2 Schleifen drehen würde und einige ms später noch Mals auslesen würde, anstatt die FOR Schleife abzubrechen.

Nach weiteren eingefügten "log_schreiben"..

..lies ich die Logs voll laufen..

schleifen_log.jpg (155.74 KiB) 513 mal betrachtet

AHA! In der 9. Schleife steht ein Inhalt im Buffer. Der Anfang passt, somit wäre dieser Buffer so vom Code normalerweise akzeptiert worden. Das Ende fehlt aber! Und siehe da, wenn man stattdessen ein 10. Mal ausliest, steht die vollständige Nachricht im Buffer! Kaum hat man die ganze Nachricht, stimmt dann auch der CRC Check!


Also fügte ich dem Code eine weitere IF Bedingung hinzu. Es muss nicht nur der Anfang der empfangenen Nachricht passen, sondern es wird auch gleich gelesen, wie lange die Nachricht sein soll (siehe SDM630 Anleitung, Definition der Responds). Anschließend wird verglichen ob die Nachricht tatsächlich auch so lange ist. Nur dann wird sie akzeptiert für die weitere Verarbeitung, ansonsten wird der Buffer neu gelesen nach kurzer Wartezeit.

Seit dem läuft der Code soweit ganz gut. Ganz selten gibt es noch Fehlereinträge wo scheinbar nichts gelesen wurde, aber diese Daten werden dann auch nicht zu Influx übertragen. Hier möchte ich dann noch schauen, ob es da Verbesserungspotential gibt. Vor allem möchte ich noch schauen, wie das ganze dann läuft, wenn der Schaltschrank wieder ordentlich ist und alle Zähler wieder angeschlossen sind am Bus. Ich bin aber zuversichtlich, dass es deutlich stabiler laufen wird als vorher.

Für Überschussregelungen ist es halt relativ doof, wenn plötzlich statt 2000W Überschuss, 0W rauskommt.

Hier einfach schon Mal der vorläufige beta Code von der funktionen.inc.php:

Wie gesagt, ein bisschen tüfteln werde ich noch und dann die Tage meinen finalen Code hier reinstellen.

[ArekS]

Hier und da wurden bereits Settings für den EW11 Adapter gepostet. Jedoch habe ich im Laufe der Zeit mit den Buffer Einstellungen rumgespielt. Und da in der Anleitung vom SDM630 etwas steht von wegen min. 60ms zwischen den Abfragen habe ich beim EW11 die Gap Time auf 100ms gestellt. Zumindest denke ich, dass diese Einstellung etwas damit zu tun hat.

Na jedenfalls wurde der Buffer meistens mit der 9. Schleife erstmalig gelesen, teilweise auch deutlich später. Die im letzten Post selten vorkommenden Fehler waren so, dass er in 29 Schleifen nicht geschafft hat den Buffer zu lesen, anschließend wird die Abfrage neu geschickt und am Ende kamen im Buffer 3-4 Antworten gleichzeitig:

Die Verstellung der Config Parameter vom EW11 zu 512 Buffersize und 50 Gap Time haben das deutlich verbessert. Danach hat er meist schon bei der 5. Schleife gelesen (also schneller) und der Fehler mit "überlaufenem" Buffer kam seit dem nicht mehr wieder.

Ich bin soweit also mit dem Code zufrieden, habe nur noch ein wenig die Logging Einträge abgeändert, bzw. die Logging-Levels. Das ist also mein finaler Code der /phpinc/funktionen.inc.php

[ArekS]

Ganz selten waren jetzt doch noch Einträge mit Fehlern, weil er irgendwie mehrere Antworten hintereinander "geklebt" hat und damit waren dann alle Schleifen nicht erfolgreich.

Ich habe noch eine Zeile in den Code eingefügt, dass der Bufferinhalt auf die richtige Länge abgeschnitten wird. Damit dürfte das letzte Problemchen auch noch behoben sein..