Einbindung von Modbus TCP

[manhartm]

Habe einen ersten Fehler in meiner Item-Definition gefunden:

    StorCtl_Mod:                       # [StorCtl_Mod] Activate hold/discharge/charge storage control mode. Bitfield value. (bit 0: CHARGE, bit 1: DiSCHARGE)
        type: num
        modBusAddress: 40358           # 40359 bitfield16
        modBusUnit: '1'
        modBusDataType: 'uint16'       # bitfield16 (0 bis 0x7FFF)
        modBusDirection: 'read_write'
        modBusObjectType: 'HoldingRegister'
        visu_acl: rw

Ohne den modBusObjectType explizit in den Attributen des Items wird das Item nicht geschrieben. Nun sehe ich im Log:

2023-12-08  12:45:53 DEBUG    plugins.modbus_tcp  update_item:PV_GEN_24.StorCtl_Mod value:3 regToWrite:HoldingRegister.40358.1
2023-12-08  12:45:53 INFO     plugins.modbus_tcp  connected to ModbusTcpClient(192.168.10.211:502)
2023-12-08  12:45:53 DEBUG    plugins.modbus_tcp  write 3 to HoldingRegister.40358.1 (address.slaveUnit) dataType:uint16
2023-12-08  12:45:53 ERROR    plugins.modbus_tcp  something went wrong in the __write_Registers function: __init__() got multiple values for argument 'unit'

Leider ist die Fehlermeldung nicht sehr hilfreich. Hat jemand hier eine Idee ?

[Tom Bombadil]

got multiple values for argument 'unit'

Geraten: Ist 'unit' nicht für gewöhnlich ein INT/Byte? Das Zeichen '1' könnte evtl. 49 ergeben; außerdem speichert Python Strings auf mehrere Arten mit 1/2/4 Bytes pro Character - erwartet wird aber ein einzelnes Byte (Zahl 0...255) für die Unit.

Lass mal testweise die Anführungsstriche bei modBusUnit: '1' weg ...

/tom

[manhartm]

Geraten: Ist 'unit' nicht für gewöhnlich ein INT/Byte? Das Zeichen '1' könnte evtl. 49 ergeben; außerdem speichert Python Strings auf mehrere Arten mit 1/2/4 Bytes pro Character - erwartet wird aber ein einzelnes Byte (Zahl 0...255) für die Unit.

Lass mal testweise die Anführungsstriche bei modBusUnit: '1' weg ...

/tom

Habe die Definition angepasst:

    StorCtl_Mod:                       # [StorCtl_Mod] Activate hold/discharge/charge storage control mode. Bitfield value. (bit 0: CHARGE, bit 1: DiSCHARGE)
        type: num
        modBusAddress: 40358           # 40359 bitfield16
        modBusUnit: 1
        modBusDataType: 'uint16'       # bitfield16 (0 bis 0x7FFF)
        modBusDirection: 'read_write'
        modBusObjectType: 'HoldingRegister'
        visu_acl: rw

Leider kommt die Fehlermeldung weiterhin:

2023-12-08  13:49:42 ERROR    plugins.modbus_tcp  something went wrong in the __write_Registers function: __init__() got multiple values for argument 'unit'

Ich verwende die Version 1.9.5. Testweise habe ich versucht das Plugin modbus_tcp aus dem Develop zu nehmen, aber da gibt es Fehlermeldungen, so dass das Plugin scheinbar nicht mehr läuft.

[manhartm]

Fehler gefunden. Die Erklärung steht in Post https://knx-user-forum.de/forum/supp...01#post1906201.

Ich habe die Version 3.1.3 der Bibliothek pymodbus installiert und die passt nicht zum Plugin im aktuellen Master 1.9.5. Ich habe probeweise den Code gemäss dem Post angepasst und nun kann ich das Item im Fronius schreiben und der Wert bleibt auch.

Das Plugin im Develop ist hier übrigens auch noch auf dem alten Stand und kann nur mit Version <3 von pymodbus eingesetzt werden.

[Tom Bombadil]

Huch, ich dachte, wir hätten die damals alle umgestellt?

O.o

/tom

[ooUrmeloo]

Hallo zusammen,

ich hatte eine ganze Weile den Modbus Plugin mit zwei Geräten recht stabil am laufen. Bis vor einiger Zeit lief das alles recht problemlos. Jetzt ist mir aufgefallen, dass ich immer wieder folgende Fehlermeldungen bekomme. Unterschiedlich für meine beiden Geräte, eine Paradigma Heizung und ein Solaredge Wechselrichter:

2023-12-09  13:12:18 ERROR    plugins.modbus_tcp  paradigma@: read error: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received) InputRegister.40.1 (address.slaveUnit) regCount:1
2023-12-09  13:17:14 ERROR    plugins.modbus_tcp  solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.007294893264770508 seconds into read of 8 bytes without response from unit before it closed connection
2023-12-09  13:27:15 ERROR    plugins.modbus_tcp  solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.01136159896850586 seconds into read of 8 bytes without response from unit before it closed connection
2023-12-09  13:37:17 ERROR    plugins.modbus_tcp  solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.0036919116973876953 seconds into read of 8 bytes without response from unit before it closed connection
2023-12-09  13:37:20 ERROR    plugins.modbus_tcp  paradigma@: read error: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received) InputRegister.7.1 (address.slaveUnit) regCount:1
2023-12-09  13:47:18 ERROR    plugins.modbus_tcp  solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.005329132080078125 seconds into read of 8 bytes without response from unit before it closed connection
2023-12-09  13:57:19 ERROR    plugins.modbus_tcp  solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.001871347427368164 seconds into read of 8 bytes without response from unit before it closed connection
2023-12-09  14:07:20 ERROR    plugins.modbus_tcp  solaredge@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.178.67:1502): Connection unexpectedly closed 0.019519329071044922 seconds into read of 8 bytes without response from unit before it closed connection

​

In regelmäßigen Abständen klappt die Abfrage nicht. Aktuell habe 300s cycle Time eingestellt, d.h., beim Solaredge klappt jede zweite Abfrage nicht, bei der Paradigma in unregelmäßigen Abständen. Wenn ich die cycle Time ändere, verändern sich die Abstände der Fehler, sie bleiben aber nicht aus.

Wie gesagt, früher lief das besser. Ich muss aber gestehen, ich weiß nicht, was ich geändert haben könnte, was den Fehler verursacht.

Hat jemand von euch eine Idee??

[bmx]

Deine Solaredge Fehler kann ich bestätigen:

2023-12-09  03:56:57 ERROR    plugins.modbus_tcp se_inverter@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.20.68:1502): Connection unexpectedly closed 0.000308990478515625 seconds into read of 8 bytes without response from slave before it closed connection
2023-12-09  17:52:57 ERROR    plugins.modbus_tcp se_inverter@: something went wrong in the poll_device function: Modbus Error: [Connection] ModbusTcpClient(192.168.20.68:1502): Connection unexpectedly closed 2.3365020751953125e-05 seconds into read of 8 bytes without response from slave before it closed connection
​

Ich bin auf dem aktuellen develop branch unterwegs. Ich vermute das der Solaredge Wechselrichter nur eine modbus Verbindung zur Zeit erlaubt und die interne Verbindung zum zugehörigen Zähler dann schlicht gewinnt.

[ooUrmeloo]

Ja, kann natürlich sein. Bei dir scheint das aber ja auch eher zufällig zu sein. Bei mir aber super regelmäßig. Irgendwie würde ich dann auch erwarten, dass - wenn man weniger häufig Werte abholt - es weniger häufig auftritt. Wie häufig rufst Du denn ab? Ich habe mal zwischen 30s und 300s gespielt. "Gefühlt" geht bei mir jede zweite Anfrage schief, egal bei welcher cycle time ...

[bmx]

Bei mir wird über einen crontab genau in der 57. Sekunde abgefragt, das ganze dauert dann knapp eine Sekunde und das ist dann erledigt.

Bei der Google Suche nach "seconds into read of 8 bytes without response from slave before it closed connection" erscheinen einige mit ähnlichen Problemen.
Unter anderem bei HomeAssistant ist ein Problem von jemand gewesen der mal mit Node Red gespielt hatte und da wohl noch was aktiv zu sein schien.
Ich vermute Du kannst sowas ausschliessen?

[ooUrmeloo]

Node-Red oder was ähnliches kann ich eigentlich ausschließen. Habe (und hatte) nichts in der Art installiert.
Kann es sein, dass sich die beiden Instanzen irgendwie in die Quere kommen? Ich meine aber, das lief auch schon gut parallel.
Das einzige, was ich neu dazu genommen habe, ist, dass ich per jsonread meine Batterie auslese, was ja grundsätzlich erstmal nicht zusammenhängt.
Meine Batterie wiederum kommuniziert aber via Modbus mit meinem Wechselrichter ... könnte das evtl. ein Problem sein? Ich kenn mich da leider nicht so gut aus ...

Bei mir wird über einen crontab genau in der 57. Sekunde abgefragt, das ganze dauert dann knapp eine Sekunde und das ist dann erledigt.

Du steuerst das Auslesen mit einem extra crontab? Ich setze einfach nur die "cycle time" in der plugin.yaml ...
Wie setzt Du das denn genau um?

[ooUrmeloo]

Was mir gerade noch aufgefallen ist ... Das Plugin übernimmt gar nicht die cycle time, die ich im plugin.yaml definiere:

solaredge:
    plugin_name: modbus_tcp
    instance: solaredge
    host: 192.168.178.67
    port: 1502
    cycle: 60
    plugin_enabled: true

Laut WebIF lese ich mit Default 300s aus. (was auch zu den Database Werten passt)
Was mache ich falsch?

Und aktuell bleibt es dabei. Jeder zweite Wert, d.h. alle 600s schlägt fehl.

grafik.png

[manhartm]

Ich habe den Cycle auf 30s und das klappt bei mir. Auch im Admin-Web wird es so angezeigt.

[bmx]

Hm, wie alt ist denn dein SHNG bzw das Plugin? Bei mir steht da (im develop branch) statt num ein int für port und cycle drin ...?

[ooUrmeloo]

Hm, wie alt ist denn dein SHNG bzw das Plugin? Bei mir steht da (im develop branch) statt num ein int für port und cycle drin ...?

SHNG v1.9.4-master und modbus_tcp v 1.0.8

Ich habe jetzt übrigens ein paar mal versucht, die beiden Instanzen nur einzeln einzuschalten bzw. nur einzeln auf 60s zu stellen.
Das ging ... und jetzt geht's auch mit beiden gleichzeitig ... fragt mich nicht, wieso ...
Und irgendwie gibt's jetzt auch seltener Fehler beim Auslesen, aber immer noch ab und zu ...
Irgendwie werde ich da nicht so richtig schlau draus ...

[beckerth]

Kann ich, wenn ich mit structs arbeite die modBusUnit im struct angeben? Oder muss ich die irgendwie in der Item Definition setzen? ShNG übernimmt die geänderte Unit ID nicht. Wenn ich die global definierte UnitID in der plugin.yaml ändere kann ich die Werte des ersten oder zweiten Gerätes auslesen. Die "Unit" Spalte im Web-IF wird nicht angezeigt. Und der modBusFactorwird bei int32 nicht eingerechnet?

Bin auf dem letzten Develop Stand vom Plugin mit PyModbus 3.0.2 und Python 3.9.2.

Minimalbeispiel:
Struct:

meter_sdm230:
  Voltage:
    modBusAddress@instance: '0'
    modBusDataType@instance: float32
    modBusObjectType@instance: InputRegister
    type: num
    modBusWordOrder@instance: Endian.Big
    modBusByteOrder@instance: Endian.Big
    modBusUnit: 1
  Current:
    modBusAddress@instance: '6'
    modBusDataType@instance: float32
    modBusObjectType@instance: InputRegister
    type: num
    modBusWordOrder@instance: Endian.Big
    modBusByteOrder@instance: Endian.Big
    modBusUnit: 1
  ActivePower:
    modBusAddress@instance: '12'
    modBusDataType@instance: float32
    modBusObjectType@instance: InputRegister
    type: num
    modBusWordOrder@instance: Endian.Big
    modBusByteOrder@instance: Endian.Big
    modBusUnit: 1
meter_em24:
  VoltageL1N:
    modBusAddress@instance: '0'
    modBusDataType@instance: int32
    modBusObjectType@instance: HoldingRegister
    type: num
    modBusWordOrder@instance: Endian.Little
    modBusByteOrder@instance: Endian.Big
    modBusUnit: 2
    modBusFactor: 0.1  
  VoltageL2N:
    modBusAddress@instance: '2'
    modBusDataType@instance: int32
    modBusObjectType@instance: HoldingRegister
    type: num
    modBusWordOrder@instance: Endian.Little
    modBusByteOrder@instance: Endian.Big
    modBusUnit: 2
    modBusFactor: 0.1  
  VoltageL3N:
    modBusAddress@instance: '4'
    modBusDataType@instance: int32
    modBusObjectType@instance: HoldingRegister
    type: num
    modBusWordOrder@instance: Endian.Little
    modBusByteOrder@instance: Endian.Big
    modBusUnit: 2
    modBusFactor: 0.1​

Item Definition:

modbus_meters:
    sdm230:
        struct: my.Modbus_Energy_Meters.meter_sdm230@modbus_ernergy_meters
    em24:
        struct: my.Modbus_Energy_Meters.meter_em24@modbus_ernergy_meters​

Web-Interface:image.png