EM530 Mit Strommesswandlern über PW11 Modbus GW betreiben

[iuATERNitg]

Hallo

ich habe ein paar Modus-WLAN GW PW11 und PE11 (einzeln) mit diversen Modbus Zählern über iobroker am Laufen.

Nun wollte ich aber mal eine Lösung ohne iobroker nutzen und habe in der Victron Kompatibilitätsliste den EM530DINAV53XS1X herausgesucht und mit passenden CTP2X2505AXXX Strommesswandlern direkt am Eingang meiner Verteilersäule montiert.

Den EM530 habe ich auch an ein PW11 über eine gewendelte auf beiden Seiten mit 120 Ω Widerständen angeschlossen.

Der PW11 liegt im gleichen Netzsegment als 192.168.16.x wie der Victron.
Den PW11 habe ich genauso angeschlossen und konfiguriert wie alle anderer PW11 und PE11 mit Modbus Zählern.
Zusätzlich habe ich den PW11 einen Dienst Telnet mit dem Ziel log konfiguriert damit man sehen kann, ob es Kommunikation gibt.

Dann habe ich testweise den Cerbus nach Zählern suchen lassen aber der Cerbus zeigt keinen Zähler an.
Parallel kann ich aber Kommunikation über Telnet auf den Logs sehen.
Dann habe ich den PW11 direkt als Gerät manuell angelegt und seit dem ist ständig Kommunikation auf dem Telnet Log des PW11 zu sehen.
Leider zeigt aber der Cerbus weiterhin den Zähler nicht an.

Im Anschluss habe ich auch noch nach dem Entfernen des im Cerbus manuell angelegten Modbus-Gerätes versucht per iobroker über den PW11 an Werte vom Zähler zu gelangen. Aber auch das ist mir nicht gelungen.

Ist irgendwas an meinem Denken wie der EM530 arbeitet anders als über die anderen Modbus-Zähler, die ich sonst verwende?
Ist irgendwas an meiner Konfiguration oder an mein Denken falsch? Ich hatte den EM530 gekauft damit ich nicht über Umwege die unzureichenden Werte von meinem Hauptzähler über Umwege an den Cerbo senden muss. Dort verwende ich einen Tasmota Lesekopf mit MQTT an iobroker der dann die Daten aufbereitet an den Cerbo senden würde. Über diesen Weg kann ich aber nur Summenwirkleistung, Bezugs- und Lieferenergie an den Cerbo liefern. Mit einem anderen günstigen Modbuszähler würde ich das genauso machen müssen auch wenn ich sehr viel bessere Werte erhalte. Allerdings kennen die meisten keine Saldierung. Daher hatte ich mich entschlossen, einen EM530 zu verwenden, wo der Umweg über iobroker oder gerne auch nodered eigentlich nicht erforderlich sein sollte.

Bilder über Konfiguration und weiteres werde ich noch nachliefern. Vielleicht habe ich ja auch etwas übersehen bzw. falsch gemacht und sehe den Fehler einfach nicht.

Wenn jemand einen EM530 (oder EM540) über ein TCP Gateway am laufen hat wäre es hilfreich wenn dieser das auch melden könnte. Dann hätte ich Gewissheit das es gehen müsste.

Danke schon mal.

[iuATERNitg]

Ich bin ein bisschen ohne Fotos weiter gekommen.
Man kann am PW11 unter Kommunikation einen weiteren Dienst Telnetd mit Bezug zum Log einrichten. Ich habe das auf Port 9999 getan und mich mal an die Konsole gehängt.
Dort konnte ich anhand des Logs sehen das der Cerbo ca. alle 10 s mit dem PW11 redet und etwas per TCP sendet (als tcp recv 12 Byte geloggt) und dann an den RS485 (per uart send 8 Byte) weiter leitet. Wenn man in der Serial Configuration des PW11 dann das Protokoll von Modbus auf None stellt, wird daraus uart send 12 Byte. Es ändert aber nichts.
Ich würde erwarten das Gerät antwortet dann irgendwie was im Log als UART recv zu sehen sein müsste.
Ich habe dann einen 2. PW 11 genommen und mal die Kabel am EM530 abgeklemmt und an diesen den angeschlossen.
Eine Logkonsole des 2. PW11 habe ich dann die Nachrichten das 1. PW11 als UART recv sehen können; im None Modus des ersten PW11 als 12 Byte und 8 Byte wenn ich den 1. auf Modbus umgestellt habe. Der 2. PW11 wurde im None Modus betrieben, da dieser sonst nur eine mir nichtssagenden Modbus Meldung loggt (weil er sich vermutlich nicht angesprochen fühlt).
Danach habe ich im Cerbo den 2. PW11 als Ziel hinterlegt und das ganze nochmal andersherum getestet. Das Ergebnis war dann das gleiche.
Darauf hin habe ich am 1. PW11 die Leitung entfernt und am EM530 wieder angeschlossen ohne das sich ein anderes Ergebnis eingestellt hat.
Darauf hin habe ich mal absichtlich die Leitungen am EM530 getauscht und sofort sah man im EM530 die TX und RX Icons regelmäßig blinken.
Ich habe dann nochmal die Doku kontrolliert und festgestellt, dass ich den EM530 tatsächlich nun „falsch“ angeschlossen habe, damit aber zumindest eine Kommunikation auf dem RS485 Bus erkannt wird.
Dann habe ich mal die ID auf 2 am EM530 geändert und nur noch das RX Icon hat geblinkt. Darauf habe ich den EM530 wieder auf Adresse 1 wie im Cerbo hinterlegt zurückgestellt.
Offensichtlich wird nun eine Kommunikation vom Cerbo zum EM530 erkannt und dieser antwortet.

Also scheint es erst einmal daran gescheitert zu sein, weil in der Anleitung vom EM530 eine falsche Beschaltung von A- und B+ angegeben ist.
So richtig kann ich noch nicht daran glauben. Aber anders herum angeschlossen reagiert der EM530 nicht mit Blinken der Icons

Leider ergibt ein Scan am Cerbo, dass dieser den EM530 weiterhin offensichtlich nicht erkennt.
Im Log des PW11 sehe ich nun aber alle 10 Sekunden haufenweise Kommunikation erkennbar an tcp und uart send und recv Meldungen.
Bei der Durchsicht ist mir dabei aufgefallen, dass hier eine Kommunikation vom Cerbo zum EM530 mit einer Meldung funcID 83 beantwortet wird.
Es gibt dann auch mal funcID 84. Einer Eingebung nach habe ich mal gegoogelt und als Antwort erhalten das 83 eine Meldung eines fehlerhaften Zugriffs (z.B. Register existiert nicht) bedeutet und 84 ein Genereller Fehler gemeldet wird.
Ich denke der Cerbo prüft einfach anhand diverser Register, ob ein unterstützter Zähler angeschlossen ist und die Meldungen daher rühren, dass es nicht der gerade getestete Zähler war.
Offensichtlich erkennt der Cerbo aber anhand der Rückmeldungen den Zähler nicht oder der Zähler meldet etwas falsches was der Cerbo nicht akzeptiert.

Da sich nun auch noch beim Neustart des Cerbo der PW11 aufgehängt hat kann ich erst morgen weiter machen.

[iuATERNitg]

So, ich habe den PW11 neu gestartet. Ich kann seit dem mit dem Programm mbpoll unter Linux die Register abfragen. Hier die ersten 30 Input Register ab Adresse 1:
Die Werte von 47-50 sind INT16 so das man diese Ignorieren sollte da ich ja INT32 abgefragt habe.

$ mbpoll -a 1 -o 3 -r 1 -t 3:int 192.168.16.184 -c 30 -1
mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus TCP
Slave configuration...: address = [1]
                        start reference = 1, count = 30
Communication.........: 192.168.16.184, port 502, t/o 3.00 s, poll rate 1000 ms
Data type.............: 32-bit integer (little endian), input register table

-- Polling slave 1...
[1]:    2258
[3]:    2256
[5]:    2269
[7]:    3902
[9]:    3918
[11]:   3930
[13]:   650
[15]:   1000
[17]:   650
[19]:   450
[21]:   550
[23]:   500
[25]:   1467
[27]:   2256
[29]:   1474
[31]:   100
[33]:   1050
[35]:   -250
[37]:   2261
[39]:   3916
[41]:   1500
[43]:   5197
[45]:   900
[47]:   15925554
[49]:   18874707
[51]:   32768001
[53]:   730
[55]:   98
[57]:   679
[59]:   115085

Leider erkennt der Victron weiterhin den EM530 nicht. Hier der Auszug aus dem Log des PW11 wenn ich ein Scan starte:

[0-1:50:15]<process> modbus clear:192.168.16.130,49211

[0-1:50:15]<tcpd> recv:12-byte
[0-1:50:15]<tcpd> recv_byte=348,recv_frame=29
[0-1:50:15]<uart> send byte:8-byte,failed:0-byte
[0-1:50:15]<uart> send_byte=232,send_frame=29
[0-1:50:15]<uart> failed_byte=0,failed_frame=0
[0-1:50:15]<process> modbus from(192.168.16.130,49211):transId=01,protoId=00

[0-1:50:15]<uart> recv:5-byte
[0-1:50:15]<uart> recv_byte=625,recv_frame=29
[0-1:50:15]<process> modbus to(192.168.16.130, 49211):transId=01,protoId=00,devId=01, funcId= 83

[0-1:50:15]<tcpd> send byte:9-byte,failed:0-byte
[0-1:50:15]<tcpd> send_byte=741,send_frame=29
[0-1:50:15]<tcpd> failed_byte=0,failed_frame=0
[0-1:50:15]<tcpd> recv:12-byte
[0-1:50:15]<tcpd> recv_byte=360,recv_frame=30
[0-1:50:15]<uart> send byte:8-byte,failed:0-byte
[0-1:50:15]<uart> send_byte=240,send_frame=30
[0-1:50:15]<uart> failed_byte=0,failed_frame=0
[0-1:50:15]<process> modbus from(192.168.16.130,49211):transId=02,protoId=00

[0-1:50:15]<process> modbus clear:192.168.16.130,49211

[0-1:50:15]<process> modbus clear:192.168.16.130,60819

[0-1:50:15]<tcpd> recv:12-byte
[0-1:50:15]<tcpd> recv_byte=372,recv_frame=31
[0-1:50:15]<process> modbus from(192.168.16.130,60819):transId=03,protoId=00

[0-1:50:15]<process> modbus clear:192.168.16.130,60819

[0-1:50:15]<process> modbus clear:192.168.16.130,47119

[0-1:50:15]<tcpd> recv:12-byte
[0-1:50:15]<tcpd> recv_byte=384,recv_frame=32
[0-1:50:15]<process> modbus from(192.168.16.130,47119):transId=04,protoId=00

[0-1:50:16]<process> modbus clear:192.168.16.130,47119

[0-1:50:16]<process> modbus clear:192.168.16.130,32851

[0-1:50:16]<tcpd> recv:12-byte
[0-1:50:16]<tcpd> recv_byte=396,recv_frame=33
[0-1:50:16]<process> modbus from(192.168.16.130,32851):transId=05,protoId=00

[0-1:50:16]<uart> send byte:8-byte,failed:0-byte
[0-1:50:16]<uart> send_byte=248,send_frame=31
[0-1:50:16]<uart> failed_byte=0,failed_frame=0
[0-1:50:16]<uart> recv:11-byte
[0-1:50:16]<uart> recv_byte=636,recv_frame=30
[0-1:50:16]<process> modbus to(192.168.16.130, 32851):transId=05,protoId=00,devId=01, funcId= 03

[0-1:50:16]<tcpd> send byte:15-byte,failed:0-byte
[0-1:50:16]<tcpd> send_byte=756,send_frame=30
[0-1:50:16]<tcpd> failed_byte=0,failed_frame=0
[0-1:50:16]<tcpd> recv:12-byte
[0-1:50:16]<tcpd> recv_byte=408,recv_frame=34
[0-1:50:16]<uart> send byte:8-byte,failed:0-byte
[0-1:50:16]<uart> send_byte=256,send_frame=32
[0-1:50:16]<uart> failed_byte=0,failed_frame=0
[0-1:50:16]<process> modbus from(192.168.16.130,32851):transId=06,protoId=00

[0-1:50:16]<uart> recv:5-byte
[0-1:50:16]<uart> recv_byte=641,recv_frame=31
[0-1:50:16]<process> modbus to(192.168.16.130, 32851):transId=06,protoId=00,devId=01, funcId= 84

[0-1:50:16]<tcpd> send byte:9-byte,failed:0-byte
[0-1:50:16]<tcpd> send_byte=765,send_frame=31
[0-1:50:16]<tcpd> failed_byte=0,failed_frame=0
[0-1:50:16]<tcpd> recv:12-byte
[0-1:50:16]<tcpd> recv_byte=420,recv_frame=35
[0-1:50:16]<uart> send byte:8-byte,failed:0-byte
[0-1:50:16]<uart> send_byte=264,send_frame=33
[0-1:50:16]<uart> failed_byte=0,failed_frame=0
[0-1:50:16]<process> modbus from(192.168.16.130,32851):transId=07,protoId=00

[0-1:50:16]<uart> recv:9-byte
[0-1:50:16]<uart> recv_byte=650,recv_frame=32
[0-1:50:16]<process> modbus to(192.168.16.130, 32851):transId=07,protoId=00,devId=01, funcId= 03

[0-1:50:16]<tcpd> send byte:13-byte,failed:0-byte
[0-1:50:16]<tcpd> send_byte=778,send_frame=32
[0-1:50:16]<tcpd> failed_byte=0,failed_frame=0
[0-1:50:16]<tcpd> recv:12-byte
[0-1:50:16]<tcpd> recv_byte=432,recv_frame=36
[0-1:50:16]<uart> send byte:8-byte,failed:0-byte
[0-1:50:16]<uart> send_byte=272,send_frame=34
[0-1:50:16]<uart> failed_byte=0,failed_frame=0
[0-1:50:16]<process> modbus from(192.168.16.130,32851):transId=08,protoId=00

[0-1:50:16]<process> modbus clear:192.168.16.130,32851

[0-1:50:16]<process> modbus clear:192.168.16.130,42835

[0-1:50:16]<tcpd> recv:12-byte
[0-1:50:16]<tcpd> recv_byte=444,recv_frame=37
[0-1:50:16]<process> modbus from(192.168.16.130,42835):transId=09,protoId=00

[0-1:50:17]<process> modbus clear:192.168.16.130,42835

[0-1:50:17]<process> modbus clear:192.168.16.130,37327

[0-1:50:17]<tcpd> recv:12-byte
[0-1:50:17]<tcpd> recv_byte=456,recv_frame=38
[0-1:50:17]<process> modbus from(192.168.16.130,37327):transId=0A,protoId=00

[0-1:50:17]<process> modbus clear:192.168.16.130,37327

Ich habe den Verdacht das der Zähler erkannt wird aber dem Cerbo irgendwas nicht schmeckt.
Hat jemand eine Idee was das sein könnte?

[iuATERNitg]

So, ich habe mal den Zähler in meinem iobroker angelegt und frage Ihn derzeit dort ab.
Mir ist ja oben schon aufgefallen das mbpoll little endian Werte korrekt wiedergibt.
Alle meinen anderen diversen Modbus-Strommessgeräte müssen als Big-Endian eingerichtet werden.

Ein Gegentest mit der Option -B für Big Endian ergibt dann die Spannungswerte * 10:

-- Polling slave 1...
[1]:    149291008
[3]:    148439040
[5]:    149159936

In der Doku zum Modbus Protokoll der EM500-Serie steht, das für die Spannungs-Register INT32 verwendet wird.
Nun steht dort auch:

(Bei der 232 ist wohl 2^32 gemeint)

Mit einem Test nur erst mal die INT16 Werte abzurufen wurden diese korrekt mit Signed 16 Bit Big Endian angezeigt.
Soweit so gut.
Als INT32 unter iobroker als Signed 32 Bit Big Endian waren die Wert extrem hoch. Mit Signed 32 Bit Big Endian Word Swap waren die Werte dann aber wieder in Ordnung.

Hier zum Vergleich die Werte aus den MPII mit dem Cerbo. Die Werte weichen etwas ab da diese sich die ganze Zeit ein wenig ändern:

Bei den Leistungswerten nun passt es aber soweit nur dem Betrag nach her. Die Werte für L1 und L3 sind eigentlich negativ und das würde ich nun auch hier erwarten.
Da scheint noch etwas nicht zu stimmen. Der Erinnerung nach zeigt der Zähler auf dem Display auch Negativwerte an.
Generell scheint es zu funktionieren. Die Leistungsfaktoren werden auch negativ ausgelesen:

Was die nach Phasen zusammengefassten Werte ab Register 247 sein sollen, ist noch nicht ganz klar außer das sich zumindest schonmal der zusammengesetzte Leistungs-Wert unterscheidet (Durchschnitt zu Summe?)

Fazit: Generell funktioniert der Zähler also. Das keine Negativen Leistungs- und Stromwerte ausgelesen werden ist noch ein Mysterium für mich. Das es geht zeigt das die Leistungsfaktorwerte negativ sein können.

Interessant könnten noch die Werte für die Firmware und das Gerät sein:

 mbpoll -a 1 -o 3 -r 771 -t 4:hex 192.168.16.184 -1 
mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus TCP
Slave configuration...: address = [1]
                        start reference = 771, count = 1
Communication.........: 192.168.16.184, port 502, t/o 3.00 s, poll rate 1000 ms
Data type.............: 16-bit register, output (holding) register table

-- Polling slave 1...
[771]:  0x1303

MSB wäre eigentlich der 0x13 Teil links und Davon Bit 0-3 wären dann 3 und 4-7 wäre 1, also Vers. 1.3.

$ mbpoll -a 1 -o 3 -r 12 -t 4:hex 192.168.16.184 -1  
mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus TCP
Slave configuration...: address = [1]
                        start reference = 12, count = 1
Communication.........: 192.168.16.184, port 502, t/o 3.00 s, poll rate 1000 ms
Data type.............: 16-bit register, output (holding) register table

-- Polling slave 1...
[12]:   0x06D0

Zumindest hier passt es schon mal.

Aber was viel wichtiger ist, dass ich immer noch nicht weiß warum der Zähler vom Cerbo nicht erkannt wird und verwendet werden kann.

[iuATERNitg]

Hallo,

ich habe gerade mal den Messmode auf C gestellt.

Das war mittels ModBus Write auf die Holding Adresse (4)4356 mit dem Wert 2 möglich und erfolgreich.

Nun erhalte ich auch negative Leistungs- und Stromwerte beim Auslesen mit iobroker und mbpoll:

Hier die Werte je Phase für V Lx-N, V Lx-Ly, I Lx, P Lx:

$ mbpoll -a 1 -o 3 -r 1 -t 3:int 192.168.16.184 -1  -c 12
mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus TCP
Slave configuration...: address = [1]
                        start reference = 1, count = 12
Communication.........: 192.168.16.184, port 502, t/o 3.00 s, poll rate 1000 ms
Data type.............: 32-bit integer (little endian), input register table

-- Polling slave 1...
[1]:    2270
[3]:    2251
[5]:    2264
[7]:    3916
[9]:    3901
[11]:   3936
[13]:   1050
[15]:   1550
[17]:   950
[19]:   -1350
[21]:   2650
[23]:   -1250

Die Werte ab Register 247 sind auch erklärt. Es handelt sich um die Durchschnittswerte der vergangenen Messperiode. Die ist einstellbar und steht derzeit auf 15 Min:

$ mbpoll -a 1 -o 3 -r 4113 -t 3 192.168.16.184 -1 
mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus TCP
Slave configuration...: address = [1]
                        start reference = 4113, count = 1
Communication.........: 192.168.16.184, port 502, t/o 3.00 s, poll rate 1000 ms
Data type.............: 16-bit register, input register table

-- Polling slave 1...
[4113]:         3

Allerdings wird im Cerbo weiterhin nicht der EM530 gefunden.

[iuATERNitg]

So, nun habe ich die Portgeschwindigkeit erfolgreich mit iobroker getestet auf 115,2 kB umstellen können.
Aber der Cerbo mag den EM530 noch immer nicht.

Wenn nun niemand noch eine Idee hat muss ich wohl oder übel mal bei Victron nachfragen.

[iuATERNitg]

So, ich habe erst mal einen Workaround über Node-Red gebaut:

Da ich mich mit Node-Red noch nicht so gut auskenne habe ich es so gemacht.

Da die UIP und die Energie + In Register zu weit entfernt sind, habe ich zwei Abfragen eingebaut die im 250 ms Rhythmus die Werte abfragen. Die Werte kommen als 16 bit Rohdaten aus dem Knoten.

Da die Werte aus dem EM530 aber alles INT32 LittleEndian Werte mit Word Swap sind, musste ich die buffer parser dazwischen bauen. Die nehmen je zwei Werte und interpretieren diese als INT32 LE.
Über die Change Knoten habe ich dann die reinen Werte benannt, dann gemeinsam in den Split Knoten verfrachtet der die große Nachricht in viele kleine aufteilt und der Switch verteilt diese dann über den mitgegebenen Namen auf die einzelnen dbus Injektoren des virtuellen Zählers.

Das funktioniert auch so weit. Sollte sich aber die Verbindung zum EM530 aufhängen weiß ich nicht wie sich das System verhalten wird. Wenn man den kompletten Flow abschaltet, dann scheint Venus OS wieder auf die internen Messinstrumente zurückzugreifen. Wenn keine Daten mehr kommen scheinbar nicht.

Nicht schön aber ich kann es zumindest erst mal testen.