Neue Versionen und Support zum Modbus-Modul

[ch.eick]

@Nobbynews:
Das ist gut zu wissen - da kann ich mir noch ein paar Werte rausklauen und muss nicht alles aus dem PDF umsetzen.

Hallo Axel,
warum arbeitet Ihr nicht direkt zusammen?
VG   Christian

[Nobbynews]

warum arbeitet Ihr nicht direkt zusammen?

Mein Modul läuft hier seit Ende März aus meiner Sicht perfekt.

[curt]

Hallo @StefanStrobel
Vor einigen Tagen wurde meine neue Weishaupt-Heizung eingebaut. Im Urzustand spricht die "WEM", hat aber optional Gateways auf KNX oder Modbus TCP.

Leider habe ich momentan gar keine Ahnung ... in der Anlage das Prinzipbild. Würde das mit dem Modul Modbus zusammenspielen?

In der mir vorliegenden Doku sind jede Menge Register (auch anderer Weishaupt-Anlagen) beschrieben. Bin ich der Erste damit und muss mit diesen Registern selbst irgendwie zurechtkommen? Ich kann Dir die Doku auch gern zeigen, es sind 1,3 MB.

Entschuldigt bitte meine dummen Fragen, ich mache das zum ersten Mal und habe im Moment keine Ahnung und auch wenig Peilung.

[ahermann86]

Hallo Axel,
warum arbeitet Ihr nicht direkt zusammen?
VG   Christian

Hallo,

naja - das habe ich tatsächlich übersehen, dass das schon jemand gemacht hat.
Ich werde das von Nobbynews so übernehmen.

Danke für den Hinweis 

Gruß
Axel

[dmq]

Hallo,

vielleicht hat hier jemand eine gute Idee:

Ich würde gerne einen Temp. LF Sensor per Modbus TCP ansteuern. Der Sensor kann selbst nur Modbus RTU. Aus diesem Grund habe ich ein Waveshare RS485 TO ETH (B) Gateway im Einsatz.

TELEGRAMME
Function 04 Read Input Register

Code Auswählen Erweitern

Register Parameter Data Type Value Range
3x0001 Temperatur Abtastung 4 s Signed 16 Bit – 350...+800 – 35.0...+80.0 °C
3x0002 Temperatur Filterung 32 s Signed 16 Bit – 350...+800 – 35.0...+80.0 °C
3x0003 Relative Feuchte Abtastung 4 s Signed 16 Bit 0...1000 0.0...100.0 % r.H.
3x0004 Relative Feuchte Filterung 32 s Signed 16 Bit 0...1000 0.0...100.0 % r.H.

Der Sensor bietet die o.a. Register an. Kann mir jemand sagen, wie diese als Objekt innerhalb ModbusAttr hinterlegt werden müssten (dec o. hex?)?

Code Auswählen Erweitern

defmod modbus_wsgw_1_1 ModbusAttr 1 10 X.Y.Z.A:502 TCP
attr modbus_wsgw_1_1 obj-i30001-len 1
attr modbus_wsgw_1_1 obj-i30001-poll 1
attr modbus_wsgw_1_1 obj-i30001-reading Temp
attr modbus_wsgw_1_1 obj-i30001-unpack N
attr modbus_wsgw_1_1 obj-i30002-len 1
attr modbus_wsgw_1_1 obj-i30002-poll 1
attr modbus_wsgw_1_1 obj-i30002-reading Temp2
attr modbus_wsgw_1_1 obj-i30002-unpack N
attr modbus_wsgw_1_1 verbose 5

Ich bekomme leider keine Kommunikation zu dem Sensor hin.

Im Log sehe ich das hier:

Code Auswählen Erweitern


2022.10.22 22:06:52 5: modbus_wsgw_1_1: checkDelays sendDelay, last send to same device was 5.987 secs ago, required delay is 0.1
2022.10.22 22:06:52 5: modbus_wsgw_1_1: checkDelays busDelayRead, last activity on bus was 10164.422 secs ago, required delay is 0
2022.10.22 22:06:52 5: modbus_wsgw_1_1: checkDelays clientSwitchDelay is not relevant
2022.10.22 22:06:52 5: modbus_wsgw_1_1: checkDelays commDelay, last communication with same device was 10164.422 secs ago, required delay is 0.1
2022.10.22 22:06:52 4: modbus_wsgw_1_1: ProcessRequestQueue (V4.4.04 - 17.7.2021) qlen 3, sending 00ad00000006010430010001 via 172.23.23.143:502, read buffer empty,
request: id 1, read fc 4 i12289, len 1, tid 173, master device modbus_wsgw_1_1, reading Temp (getUpdate for Temp len 1), queued 0.01 secs ago
2022.10.22 22:06:52 5: modbus_wsgw_1_1: Send called from ProcessRequestQueue
2022.10.22 22:06:52 5: DevIo_SimpleWrite modbus_wsgw_1_1: 00ad00000006010430010001
2022.10.22 22:06:52 5: modbus_wsgw_1_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.10.22 22:06:53 5: modbus_wsgw_1_1: ProcessRequestQueue called from Fhem internal timer as queue:modbus_wsgw_1_1, qlen 2, request: request: id 1, read fc 4 i30001, len 1, tid 98, master device modbus_wsgw_1_1, reading Temp (getUpdate for Temp len 1), queued 1.01 secs ago
2022.10.22 22:06:53 5: modbus_wsgw_1_1: ProcessRequestQueue will return, Fhem is still waiting for response, read buffer empty,
request: id 1, read fc 4 i12289, len 1, tid 173, master device modbus_wsgw_1_1, reading Temp (getUpdate for Temp len 1), queued 1.01 secs ago, sent 1.01 secs ago, qlen 2, try again in 1 seconds
2022.10.22 22:06:53 5: modbus_wsgw_1_1: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds

Danke vorab

[dmq]

Ich habe das Ganze jetzt auch mal ohne Gateway mit einem RS485 Adapter (9600,8,N,1) gemacht. Auch hier passiert nichts. Nur die rote LED beim Sensor leuchtet bei der Abfrage auf (falsches Telegram).

[ch.eick]

Hallo zusammen,
ich versuche nun das erste mal einen ModBus Slave TCP zu definieren.
Hintergrund ist einen Wechselrichter am Energiemanager zu simulieren.
Die Definitionen müssen einem vorhandenen Wechselrichter entsprechen, damit der Energiemanager den Fake nicht merkt.
Somit habe ich die benötigten ModBus Register aus dem orignal WR in dem neuen ModBus Slave mit den selben Attributen als "holding Register" definiert.

Hier kommt der erste verbindungsversuch.
Zu beginn kam diese Meldung, woraufhin ich den falschen Port 71 auf 255 geändert habe

Code Auswählen Erweitern


2022.10.27 11:10:19.134 3: WR_3_192.168.178.17_54130: _UnDef is closing WR_3_192.168.178.17_54130
2022.10.27 11:10:19.239 3: WR_3_192.168.178.17_54136: GetLogHash called from HandleRequest detected wrong Modbus Id 255, expecting 71
2022.10.27 11:10:19.725 3: WR_3_192.168.178.17_54136: read from TCP server connection got null -> closing
2022.10.27 11:10:19.726 3: WR_3_192.168.178.17_54136: _UnDef is closing WR_3_192.168.178.17_54136
2022.10.27 11:10:19.855 3: WR_3_192.168.178.17_54142: GetLogHash called from HandleRequest detected wrong Modbus Id 255, expecting 71


Nun kommen diese Meldungen, jedoch habe ich noch keine Ahnung worauf das hindeutet.

Code Auswählen Erweitern


2022.10.27 11:12:18.139 3: WR_3: port 1502 opened
2022.10.27 11:12:18.232 3: WR_3_192.168.178.17_56106: read from TCP server connection got null -> closing
2022.10.27 11:12:18.232 3: WR_3_192.168.178.17_56106: _UnDef is closing WR_3_192.168.178.17_56106
2022.10.27 11:12:18.422 3: WR_3_192.168.178.17_56108: read from TCP server connection got null -> closing
2022.10.27 11:12:18.422 3: WR_3_192.168.178.17_56108: _UnDef is closing WR_3_192.168.178.17_56108
2022.10.27 11:12:18.607 3: WR_3_192.168.178.17_56110: read from TCP server connection got null -> closing
2022.10.27 11:12:18.607 3: WR_3_192.168.178.17_56110: _UnDef is closing WR_3_192.168.178.17_56110

Im Device finde ich dann noch das hier

stacktrace

TcpServer_Close:1712 Modbus::DoClose:903 Modbus::SetLDInactive:1196 Modbus::ControlSet:1090 Modbus::SetLDFn:3950 CallFn:1957 DoSet:1989 CommandSet:1274 AnalyzeCommand:2806 FW_fC:1028 FW_answerCall:609 FW_Read:3955 CallFn:782


Hat jemand eine Idee, wo ich weiter suchen könnte, oder was ich generell schon falsch gemacht haben?

EDIT:
Die ersten Register werden vom KSEM bereits richtig gelesen, womit ich ableite, dass die Kommunikation schon läuft, jedoch werden noch keine Leistungen gelesen.
Der Name und die Seriennummer werden im KSEM richtig angezeigt.


VG
   Christian

Hier mal das bisherige List

Code Auswählen Erweitern


Internals:
   CFGFN     
   CONNECTS   78
   DEF        255 slave x.x.x.x:1502 TCP
   DeviceName x.x.x.x:1502
   EXPECT     request
   FUUID      635a4f93-f33f-61a8-de24-ef654445af0f3f58

   IODev      WR_3
   LASTCONN   WR_3_<IP des KSEM>_47132        <<<<< Der Energiemanager scheint hier schon aktiv das Device abzufragen :-)

   MODBUSID   255
   MODE       slave
   MODULEVERSION Modbus 4.4.04 - 17.7.2021
   NAME       WR_3
   NOTIFYDEV  global
   NR         555436
   NTFY_ORDER 50-WR_3
   PORT       1502
   PROTOCOL   TCP
   STATE      inactive
   TCPConn    1
   TCPServer  1
   TYPE       ModbusAttr
   eventCount 35
   stacktrace  TcpServer_Close:1712 Modbus::DoClose:903 Modbus::SetLDInactive:1196 Modbus::ControlSet:1090 Modbus::SetLDFn:3950 CallFn:1957 DoSet:1989 CommandSet:1274 AnalyzeCommand:2806 FW_fC:1028 FW_answerCall:609 FW_Read:3955 CallFn:782
   Helper:
     DBLOG:
       state:
         LogDB:
           TIME       1666862995.40365
           VALUE      opened
   READ:
   READINGS:
     2022-10-27 12:19:25   Active_P_L1     10.00
     2022-10-27 12:19:34   Active_P_L2     10.00
     2022-10-27 12:19:40   Active_P_L3     10.00
     2022-10-27 12:16:50   I_L1            0.00
     2022-10-27 12:17:01   I_L2            0.00
     2022-10-27 12:17:07   I_L3            0.00
     2022-10-27 10:56:32   Inverter_Article_number 12345678
     2022-10-27 10:56:32   Inverter_serial_number 87654321
     2022-10-27 10:56:32   Inverter_state  6
     2022-10-27 10:59:21   Productname     WR_3
     2022-10-27 10:56:32   Software-Version_IO-Controller_IOC 4711
     2022-10-27 10:56:32   Software-Version_Maincontroller_MC 0815
     2022-10-27 11:00:33   Total_AC_Active_P 0
     2022-10-27 12:17:24   U_L1            230.00
     2022-10-27 12:17:35   U_L2            230.00
     2022-10-27 12:17:44   U_L3            230.00
     2022-10-27 12:08:12   state           inactive
   REMEMBER:
     lsend      1666865292.28397
   defptr:
     WR_3       255
Attributes:
   DbLogExclude .*
   comment    Version 2022.10.27 09:00
Fremder WR am KSEM
   dev-h-combine 8
   dev-h-defFormat %.2f
   dev-h-defLen 2
   dev-h-defPoll 1
   dev-h-defRevRegs 1
   dev-h-defUnpack f>
   dev-type-STR-format %s
   dev-type-STR-len 8
   dev-type-STR-revRegs 0
   dev-type-STR-unpack a*
   disable    0
   group      PV Eigenverbrauch
   icon       sani_solar
   obj-h14-reading Inverter_serial_number
   obj-h14-type STR
   obj-h154-reading I_L1
   obj-h156-reading Active_P_L1
   obj-h158-reading U_L1
   obj-h160-reading I_L2
   obj-h162-reading Active_P_L2
   obj-h164-reading U_L2
   obj-h166-reading I_L3
   obj-h168-reading Active_P_L3
   obj-h170-reading U_L3
   obj-h172-reading Total_AC_Active_P
   obj-h38-reading Software-Version_Maincontroller_MC
   obj-h38-type STR
   obj-h46-reading Software-Version_IO-Controller_IOC
   obj-h46-type STR
   obj-h56-format %.0f
   obj-h56-reading Inverter_state
   obj-h56-unpack N
   obj-h6-reading Inverter_Article_number
   obj-h6-type STR
   obj-h768-len 32
   obj-h768-reading Productname
   obj-h768-type STR
   room       Strom->Photovoltaik
   sortby     311
   verbose    5


[dmq]

Ich habe das Ganze jetzt auch mal ohne Gateway mit einem RS485 Adapter (9600,8,N,1) gemacht. Auch hier passiert nichts. Nur die rote LED beim Sensor leuchtet bei der Abfrage auf (falsches Telegram).

Ich bin hartnäckig geblieben. Es funktioniert. Es hat nichts mit den Modulen oder seriellen Terminal Parametern zu tun. Eine Ader hatte keinen Kontakt. Sowohl modbus-tcp als auch modbus-rtu funktionieren nun gut.

[StefanStrobel]

Hallo curt,

Wenn Du eine Dokumentation der Modbus-Schnittstelle (Register etc.) hast, sollte es kein Problem sein, die Heizung anzubinden.

Gruß
    Stefan

[StefanStrobel]

Hallo Christian,

die Meldungen mit closing zeigen nur dass der Master die Verbindung geschlossen hat.
Hast Du denn einen echten Wechselrichter, mit dem Du die gelieferten Werte und deren Format vergleichen kannst?
Ich würde im Log nachsehen, welche Requests mit welcher Länge der Energiemanager genau sendet und dann genau diese Requests zum Vergleich an den echten WR schicken.

Gruß
    Stefan

[ch.eick]

die Meldungen mit closing zeigen nur dass der Master die Verbindung geschlossen hat.
Hast Du denn einen echten Wechselrichter, mit dem Du die gelieferten Werte und deren Format vergleichen kannst?
Ich würde im Log nachsehen, welche Requests mit welcher Länge der Energiemanager genau sendet und dann genau diese Requests zum Vergleich an den echten WR schicken.

Hallo Stefan,
ich bin mir nicht sicher, dass es ein Slave sein muss, da der original Kostal WR als Master fungiert und somit müsste auch mein Fake im FHEM ein Master sein.
Der Energiemanager muss die Daten nach meiner Kenntnis beim Master abholen.
In Node-Red hat die PV Community das ganze bereits am laufen, das habe ich auch bereits konfiguriert und werde da mal genauer rein schauen.
EDIT: Dort werden die Messwerte aktiv zum KSEM gesendet.

Ansonsten sind die ModBus Definitionen bereits eine Kopie des original WRs, den ich in FHEM konfiguriert habe.

Vielen Dank für die Rückmeldung
    Christian

[ch.eick]

die Meldungen mit closing zeigen nur dass der Master die Verbindung geschlossen hat.
Hast Du denn einen echten Wechselrichter, mit dem Du die gelieferten Werte und deren Format vergleichen kannst?
Ich würde im Log nachsehen, welche Requests mit welcher Länge der Energiemanager genau sendet und dann genau diese Requests zum Vergleich an den echten WR schicken.

Hallo zusammen,
leider komme ich nicht weiter.

im Node-Red habe ich eine lauffähige Konfiguration

Code Auswählen Erweitern


- Dort ist ein "ModBus Server" definiert, der die eigene IP-Adresse und Port 1502 verwendet.
- Dann ist "ModBus-Flex-Write" definiert, dass die Werte anscheinen sendet.
  Auch dort ist die eigene IP-Adresse und Port 1502 konfiguriert, zusätzlich die UnitID


Mit meiner bisherigen Definition in FHEM als Slave bekomme ich den Productname und die Seriennummer meines Fakes im Energiemanger angezeigt, aber die gewünschten Werte werden nicht übermittelt/abgeholt. Der original WR ist als ModBus Master im Netz.
Testweise habe ich ein Register mit "obj-h172-set 1" versehen, was aber auch nicht weiter geholfen hat.

Wenn ich in FHEM einen Modbus Master TCP definiere bekomme ich kein connect.

Ich bräuchte da mal etwas Hilfe
   Christian

[curt]

Wenn Du eine Dokumentation der Modbus-Schnittstelle (Register etc.) hast, sollte es kein Problem sein, die Heizung anzubinden.

Hallo Stefan,
ich bin mir nicht sicher, ob die mir vorliegende Doku ausreichend ist. Ich hänge einen Screenshot sowie  das komplette Dokument an.

Deine Einschätzung ist mir wichtig: Das zusätzliche Modul kostet inkl. Installation vmtl. über 1.000 Euro. Selbstverständlich ist das schlussendlich meine Verantwortung, diese delegiere ich NICHT an Dich. Aber mir wäre deutlich wohler, wenn Du da mal kurz drüber schaust. Und mir sagst, ob das in etwa so aussehen sollte.

Ich danke Dir sehr!

[Mariomgn]

Hallo,

ich habe jetzt schon vieles durchgelesen, komme aber nicht weiter.

Ich erhalte über MQTT Temperaturwerte.

Code Auswählen Erweitern

define Temperatur_Heizung MQTT_DEVICE
attr Temperatur_Heizung IODev myBroker
attr Temperatur_Heizung devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
attr Temperatur_Heizung room Heizung
attr Temperatur_Heizung subscribeReading_Temperatur_Heizung HC/Heizung/Temp_Heizung/SENSOR

define ej.Temperatur_Heizung expandJSON Temperatur_Heizung:.*:.{.*}
attr ej.Temperatur_Heizung room Heizung
attr ej.Temperatur_Heizung verbose 1


define MQTT_Heizung_Temp_senden MQTT_BRIDGE Temperatur_Heizung
attr MQTT_Heizung_Temp_senden IODev myBroker
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-1_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-1_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-2_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-2_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-3_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-3_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-4_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-4_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-5_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-5_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-6_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-6_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-7_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-7_Temperature
attr MQTT_Heizung_Temp_senden publishReading_DS18B20-8_Temperature HC/Heizung/Temperatur_Heizung/DS18B20-8_Temperature
attr MQTT_Heizung_Temp_senden room Heizung



Diese Temperaturen sollen nun über Modbus TCP an eine Micro 820 gesendet werden.

Wie sieht die Definition für den Sendevorgang der Temperaturwerte aus?

Schon mal vielen Dank für die Antwort.

MfG Mario

[StefanStrobel]

im Node-Red habe ich eine lauffähige Konfiguration

Code Auswählen Erweitern


- Dort ist ein "ModBus Server" definiert, der die eigene IP-Adresse und Port 1502 verwendet.
- Dann ist "ModBus-Flex-Write" definiert, dass die Werte anscheinen sendet.
  Auch dort ist die eigene IP-Adresse und Port 1502 konfiguriert, zusätzlich die UnitID


Mit meiner bisherigen Definition in FHEM als Slave bekomme ich den Productname und die Seriennummer meines Fakes im Energiemanger angezeigt, aber die gewünschten Werte werden nicht übermittelt/abgeholt. Der original WR ist als ModBus Master im Netz.
Testweise habe ich ein Register mit "obj-h172-set 1" versehen, was aber auch nicht weiter geholfen hat.

Wenn ich in FHEM einen Modbus Master TCP definiere bekomme ich kein connect.

Hallo Christian,

zuerst müssen wir die Begriffe klären, sonst reden wir aneinander vorbei.
Ein Modbus-Master (neuerdings auch Client genannt) ist die aktive Komponente. Er fragt Werte von Slaves (neuerdings auch Server genannt) ab.
Ein Slave kann selbst keine Werte irgendwo hinschicken. Er beantwortet nur die Anfragen eines Masters.
Genauso liefert aber auch ein Master keine Werte sondern er holt sie von Slaves ab.

Wenn Dein Energiemanager (als Master = Client) Werte von dem Wechselrichter abfragt, dann muss Dein Wechselrichter ein Slave (=Server) sein.
Du kannst den Wechselrichter (Slave) von Fhem aus abfragen wenn Du mit ModbusAttr einen Master in Fhem erzeugst.

Wenn der Energiemanager (=Master) erfolgreich Werte von Fhem (=Slave) abholt und nur bestimmte Werte vom Energiemanager nicht abgeholt werden, dann wird es daran liegen, dass entweder Fhem die fehlenden Werte gar nicht liefert (unvollständige Konfiguration) oder dass Fhem die Werte nicht in dem vom Energiemanager erwarteten Format liefert (z.B. unpack code falsch, Länge falsch etc.).

ich bin mir nicht sicher, dass es ein Slave sein muss, da der original Kostal WR als Master fungiert und somit müsste auch mein Fake im FHEM ein Master sein.
Der Energiemanager muss die Daten nach meiner Kenntnis beim Master abholen.
...
Der original WR ist als ModBus Master im Netz

Das passt so nicht. wie kommst Du darauf, dass der WR ein Master ist? Von welchem Slave fragt er Werte ab?
Ich würde vermuten, dass der WR ein Slave ist, den Du mit Fhem abfragen kannst, wenn Du ModbusAttr als Master definierst.
Ein Modbus-TCP-Master öffnet als TCP Client eine TCP-Verbindung zu einem Modbus-TCP-Slave als TCP-Server, der den Port 502 oder auch 1502 o.ä. geöffnet hat und dort auf eingehende Verbindungen wartet. Ein Slave kann von sich aus keine Verbindung zu einem Master aufbauen. Er beantwortet nur die Requests eines Masters.
Genau so wird Dein Energiemanager als Master den WR als Slave abfragen können.

Wenn wir mal davon ausgehen, dass dem so ist, dann bringt es auch nichts wenn Du die Attribute eines Fhem-Master-Devices, mit dem Du den WR abfragen kannst, zu einem Slave kopierst.
Satt dessen musst Du herausfinden, welche Requests der Energiemanager an den WR stellt und wie genau der WR darauf antwortet. Diese Antworten musst Du dann Deinem Fake beibringen.
Dazu würde ich folgendes tun:
1) den Slave in Fhem auf verbose 5 stellen und die eingehenden Requests vom Energiemanager mit Function code, Adresse und Länge notieren (z.B. fc4 auf i123 mit len 4, fc3 auf h234 mit len 1, ...)
2) Fhem als Master konfigurieren und genau solche Requests an den echten WR schicken. Ein input register muss dabei auch ein input register bleiben und darf kein holding register werden und wenn der Energiemanager 5 Register auf einmal - also Länge 5 - abfragt, dann musst Du das genauso mit len 5 machen. Dabei verbose auf 5
3) die Antworten des echten WR (Objekte mit Längen und Werten) im Fhem-Log suchen und notieren
4) daraus die Konfiguration des Fake WR Slaves in Fhem mit festen Werten (zum Testen) ableiten und Objekt für Objekt vergleichen, ob Fhem die gleichen Antworten schickt wie der der original WR.

Wenn Du das Schritt für Schritt machst und die vollständigen Konfigurationen und Logs postest, bekommen wir das hin

Gruss
   Stefan