S10, E3DC, Problem mit ModbusAttr(CONNECTED,DISCONNECTED,reappeared)

Begonnen von h002, 10 September 2020, 23:42:31

Vorheriges Thema - Nächstes Thema

h002

Nach dem wiederholten Neustart meiner E3DC S10 kann ich mich immer noch nicht mit der S10 über Modbus verbinden und keine Werte mehr auslesen.

Mit dem Tool https://sourceforge.net/projects/easymodbustcp/files/V5.5/ kann ich mich allerdings erfolgreich verbinden und Werte auslesen.

Kann mir bitte jemand helfen, wie ich das Problem weiter eingrenzen kann?

Vielen Dank!

Logauszug auf verbose 5.


2020.09.10 23:30:53 5 : Starting notify loop for S10, 1 event(s), first is DISCONNECTED
2020.09.10 23:30:53 4 : DbLog dbLog -> ################################################################
2020.09.10 23:30:53 4 : DbLog dbLog -> ###              start of new Logcycle                       ###
2020.09.10 23:30:53 4 : DbLog dbLog -> ################################################################
2020.09.10 23:30:53 4 : DbLog dbLog -> number of events received: 1 for device: S10
2020.09.10 23:30:53 4 : DbLog dbLog -> check Device: S10 , Event: DISCONNECTED
2020.09.10 23:30:53 5 : End notify loop for S10
2020.09.10 23:30:53 5 : HttpUtils url=http://10.0.0.60:502/
2020.09.10 23:30:53 4 : IP: 10.0.0.60 -> 10.0.0.60
2020.09.10 23:30:53 3 : 10.0.0.60:502 reappeared (S10)
2020.09.10 23:30:53 5 : Starting notify loop for S10, 1 event(s), first is CONNECTED
2020.09.10 23:30:53 4 : DbLog dbLog -> ################################################################
2020.09.10 23:30:53 4 : DbLog dbLog -> ###              start of new Logcycle                       ###
2020.09.10 23:30:53 4 : DbLog dbLog -> ################################################################
2020.09.10 23:30:53 4 : DbLog dbLog -> number of events received: 1 for device: S10
2020.09.10 23:30:53 4 : DbLog dbLog -> check Device: S10 , Event: CONNECTED
2020.09.10 23:30:53 5 : End notify loop for S10
2020.09.10 23:30:53 5 : S10: SetartUpdateTimer called from OpenCB kept existing timer, will call GetUpdate in 15.9 sec at 2020-09-10 23:31:09, interval 20
2020-09-10 23:30:53 ModbusAttr S10 CONNECTED
2020-09-10 23:30:53 ModbusAttr S10 DISCONNECTED
2020-09-10 23:30:53 ModbusAttr S10 CONNECTED


Device Definition


Internals:
   DEF        2 20 10.0.0.60:502 TCP
   DevIoJustClosed 1
   DeviceName 10.0.0.60:502
   EXPECT     idle
   FUUID      5f44c3f4-f33f-8b20-9b4c-b2e561800f0a0bad
   INTERVAL   20
   IODev      S10
   LASTOPEN   1599773520.73946
   MODBUSID   2
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       S10
   NOTIFYDEV  global
   NR         338
   NTFY_ORDER 50-S10
   PROTOCOL   TCP
   STATE      disconnected
   TCPConn    1
   TRIGGERTIME 1599773529.2454
   TRIGGERTIME_FMT 2020-09-10 23:32:09
   TRIGGERTIME_SAVED
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1599773509.2454
   nextOpenDelay 60
   FRAME:
   QUEUE:
     HASH(0x62ac110)
     HASH(0x5186b40)
     HASH(0x62ac938)
     HASH(0x5186b58)
     HASH(0x637e270)
     HASH(0x51872c0)
     HASH(0x63e3548)
   READ:
     BUFFER     
   READINGS:
     2020-09-10 23:20:42   abregelung      0
     2020-09-09 22:41:29   ae              25443
     2020-09-10 23:20:42   autarkie        99
     2020-09-09 22:41:30   battsoc         85
     2020-09-10 23:20:42   battwatt        -978
     2020-09-09 22:41:30   battwatt0       64558
     2020-09-10 23:20:42   eigenverbrauch  99
     2020-09-09 22:41:30   ems             4
     2020-09-10 23:20:42   entladesperre   0
     2020-09-10 23:20:42   entladesperrzeit 0
     2020-09-10 23:20:42   gridwatt        4
     2020-09-09 22:41:30   gridwatt0       4
     2020-09-10 23:20:42   homewatt        973
     2020-09-09 22:41:30   homewatt0       4294902732
     2020-09-10 23:20:42   ladesperre      0
     2020-09-10 23:20:42   ladesperrzeit   0
     2020-09-10 23:20:42   notstrom        1
     2020-09-10 23:20:42   prognoseladen   0
     2020-09-10 23:32:00   state           disconnected
     2020-09-09 22:41:29   sunwatt         0
   REMEMBER:
     lid        2
     lname      S10
     lsend      1599773471.27413
   defptr:
     S10        2
   lastRead:
Attributes:
   dev-h-defPoll 1
   event-min-interval .*:120
   event-on-change-reading .*
   obj-h40066-len 2
   obj-h40066-reading sunwatt
   obj-h40066-unpack N
   obj-h40068-len 2
   obj-h40068-reading battwatt0
   obj-h40068-unpack N
   obj-h40070-len 2
   obj-h40070-reading homewatt0
   obj-h40070-unpack N
   obj-h40072-len 2
   obj-h40072-max 65537
   obj-h40072-min 0
   obj-h40072-reading gridwatt0
   obj-h40072-unpack N
   obj-h40081-len 1
   obj-h40081-reading ae
   obj-h40081-unpack n
   obj-h40082-len 1
   obj-h40082-reading battsoc
   obj-h40082-unpack n
   obj-h40084-len 1
   obj-h40084-reading ems
   obj-h40084-unpack n
   room       Dimplex,E3DC
   stateFormat {"Batt: ".ReadingsVal("$name","battsoc", undef)."%, SunWatt: ".ReadingsVal("$name","sunwatt", undef)."Wh, HomeWatt: ".ReadingsVal("$name","homewatt", undef)."Wh, E: ".(ReadingsVal("PROPLANTA","fc0_rad", undef) * 38 * 0.17)."kWh E1: ".(ReadingsVal("PROPLANTA","fc1_rad", undef) * 38 * 0.17)."kWh"}
   userReadings gridwatt { if (ReadingsVal("S10", "gridwatt0", "") <= 32768 ) {(ReadingsVal("S10", "gridwatt0", ""))} else {(ReadingsVal("S10", "gridwatt0", "")) - 65536 }; },
battwatt { if (ReadingsVal("S10", "battwatt0", "") <= 32768 ) {(ReadingsVal("S10", "battwatt0", ""))} else {(ReadingsVal("S10", "battwatt0", "")) - 65536 }; },
homewatt { if (ReadingsVal("S10", "homewatt0", "") <= 4294901759 ) {(ReadingsVal("S10", "homewatt0", ""))} else {(ReadingsVal("S10", "homewatt0", "")) - 4294967295 + 65536 }; },
autarkie { ((ReadingsVal("S10", "ae", "")) & 0xFF00) >> 8; },
eigenverbrauch { (ReadingsVal("S10", "ae", "")) & 0xFF; },
ladesperre { ((ReadingsVal("S10", "ems", "")) & 0x1) >> 0; },
entladesperre { ((ReadingsVal("S10", "ems", "")) & 0x2) >> 1; },
notstrom { ((ReadingsVal("S10", "ems", "")) & 0x4) >> 2; },
prognoseladen { ((ReadingsVal("S10", "ems", "")) & 0x8) >> 3; },
abregelung { ((ReadingsVal("S10", "ems", "")) & 0x10) >> 4; },
ladesperrzeit { ((ReadingsVal("S10", "ems", "")) & 0x20) >> 5; },
entladesperrzeit { ((ReadingsVal("S10", "ems", "")) & 0x40) >> 6; }
   userattr   dev-h-defPoll event-aggregator event-min-interval event-on-change-reading obj-h40066-len obj-h40066-poll obj-h40066-reading obj-h40066-unpack obj-h40068-len obj-h40068-poll obj-h40068-reading obj-h40068-unpack obj-h40070-len obj-h40070-poll obj-h40070-reading obj-h40070-unpack obj-h40072-len obj-h40072-max obj-h40072-min obj-h40072-poll obj-h40072-reading obj-h40072-unpack obj-h40081-len obj-h40081-poll obj-h40081-reading obj-h40081-unpack obj-h40082-len obj-h40082-poll obj-h40082-reading obj-h40082-unpack obj-h40084-len obj-h40084-reading obj-h40084-unpack obj-h40101-len obj-h40101-poll obj-h40101-reading obj-h40101-unpack obj-h40102-len obj-h40102-poll obj-h40102-reading obj-h40102-unpack userReadings


Anbei noch ein Bild des tcpdumps.

h002

Ich habe noch etwas experimentiert. Die E3DC läuft in einem eigenen VLAN 10 und bekommt seine IP vom DHCP-Server. Der Modbus-Master (FHEM) ist im VLAN 1 und hat keine Firewall-Beschränkungen auf VLAN 10. Ich kann mich vom Client, wo FHEM läuft (VLAN 1), über sämtliche Ports auf VLAN 10 verbinden. In diesem Zustand kommt es immer wieder zu dem oben beschriebenen Verhalten.

Sobald ich die E3DC in den Adressbereich von VLAN 1 aufnehme, ist eine Verbindung via Modbus möglich. Irgendwie verstehe ich nicht, warum die Verbindung nicht funktioniert. Ich habe auch mal versucht, alle Firewall-Beschränkungen von VLAN 10 zu VLAN 1 aufzuheben. Leider auch ohne Erfolg. Hat hier noch jemand eine Idee?

h002

Jetzt habe ich sogar mal das VLAN 10 deaktiviert und dem E3DC eine statische IP zugewiesen. Die Verbindung aus meinem 192er in das 10er Netz des E3DC mittels SSH oder Telnet funktioniert. Es gibt keine Blockierungen von irgendwelchen Ports. Das Verhalten mit Modbus bleibt aber unverändert.

Ich kann es einfach nicht nachvollziehen, was hier das Problem sein könnte. Nehme ich die E3DC in mein 192er Netz, dann funktioniert es. Wo steckt der Teufel im Detail?

Ich möchte die E3DC von meinem 192er privaten Netz fern halten und deshalb diese in ein eigenes Subnetz stecken.

h002

Mittels QModMaster (https://sourceforge.net/projects/qmodmaster/files/) habe ich nun noch mal einen Versuch gestartet. Sobald die E3DC in einem andern Subnetz als der abfragende Client ist, habe ich dieses Problem. Den Firewall habe ich komplett deaktiviert, Routing funktioniert und immer wieder wird die Verbindung seitens E3DC beendet. Es ist also kein FHEM-Problem. ;-)

Hat jemand zufällig ebenfalls eine E3DC im Einsatz, die in einem anderen Subnetz als die FHEM-Instanz liegt?

Rewe2000

Hallo h002,

ich vermute du hängst an genau dem gleichen Problem wie ich. Auch ich wollte den Stromspeicher sauber in ein anderes Subnetz auslagern und diesen mit einem Unifi Router absichern, welchen ich mir extra deswegen gekauft habe. Ein Testaufbau mit einer WAGO Steuerung über Modbus verlief Problemlos, als ich jedoch meinen E3DC bekam und diesen anstelle der WAGO in mein Subnetz gehängt habe, bekam ich auch keine Verbindung mehr über Modbus.

Siehe meine Beiträge hierzu: https://forum.fhem.de/index.php/topic,106114.msg1046867.html#msg1046867

E3DC unterbindet die Kommunikation in ein anderes Subnetz über Modbus (Sicherheitsmerkmal oder Mangel) da bin ich mir nicht sicher.

Im Beitrag gibt es noch Lösungsvorschläge über 2 Raspi um den E3DC in ein anderes Subnetz auszulagern. Ich habe es jedoch nicht gemacht, er hängt bei mir nun im Heimnetz hinter meiner FritzBox.

Gruß Reinhard
Fhem 6.3 auf Raspberry Pi4 SSD mit Raspbian Bookworm, Homematic, Homematic IP, CCU3 mit RapberryMatic, WAGO 750-880, E3DC S10E Hauskraftwerk, E3DC Wallbox, my-PV AC ELWA-E Heizstab, Fritz!Box 7590, KIA Bluelinky

h002

Hallo Rewe2000,
vielen Dank für deine Rückmeldung. Dadurch konnte ich das Problem bei mir lösen. Ich besitze einen MikroTik Router (RB2011UiAS-2HnD) der NAT unterstützt.

FHEM läuft im 192er Netz, die E3DC im 10er. Im Mikrotik habe ich die folgende NAT-Regel eingetragen:


add action=masquerade chain=srcnat dst-address=10.0.60.60 dst-port=502 protocol=tcp src-address=192.168.178.45


Dadurch werden die Paket nicht mehr vom 10er zum 192er gesendet, sondern das 10er sendet die Packet durch die Maskierung an sein 10er-Gateway und ist damit im selben Subnetz. Anschließend leitet der Router die Pakete an das 192er Netz. Ich hoffe die laienhafte Erklärung passt so ungefähr. ;-)

Die Verbindung steht und die Daten werden ausgelesen. Mal sehen wie lange. ;-)

Viele Grüße