Einbindung von Modbus TCP

[fuppy]

Hallo ivande,
sorry hat jetzt komischerweise länger gedauert, bis der Fehler wieder auftrat. Hier der Screenshot vom Admin UI:

image.png

Hier die Werte direkt vom Bus:

image.png

Hier noch der Auszug auf dem Logfile von SmarthomeNG:

2023-03-01  15:12:43 INFO     plugins.modbus_tcp  connected to ModbusTcpClient(192.168.0.181:502)
2023-03-01  15:12:43 DEBUG    plugins.modbus_tcp  read InputRegister.72.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2023-03-01  15:12:43 DEBUG    plugins.modbus_tcp  value readed: 141.15728759765625 type: <class 'float'>
2023-03-01  15:12:43 DEBUG    plugins.modbus_tcp  read InputRegister.74.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2023-03-01  15:12:43 DEBUG    plugins.modbus_tcp  value readed: 338.5069885253906 type: <class 'float'>
2023-03-01  15:12:43 DEBUG    plugins.modbus_tcp  read InputRegister.52.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2023-03-01  15:12:43 DEBUG    plugins.modbus_tcp  value readed: 230.1840057373047 type: <class 'float'>
2023-03-01  15:12:43 DEBUG    plugins.modbus_tcp  poll_device: 3 register readed requed-time: 0:00:00.051383​

Es scheint also, also ob das Plugin bereits die Werte falsch ausliest...

[fuppy]

Hallo ivande,
na klar:
Hier die Anleitung.

Und hier die item Config:

PV_Speicher:
       name: PV-Speicher
       Import:
          type: num
          name: Import
          modBusObjectType: InputRegister     #(optional) default: HoldingRegister
          modBusAddress: 72
          modBusDataType: float32
          database: 'yes'

       Export:
          type: num
          name: Export
          modBusObjectType: InputRegister     #(optional) default: HoldingRegister
          modBusAddress: 74
          modBusDataType: float32
          database: 'yes'

       TotalPower:
          type: num
          name: TotalPower
          modBusObjectType: InputRegister     #(optional) default: HoldingRegister
          modBusAddress: 52
          modBusDataType: float32
          database: 'yes'​

Screenshot vom Admin Interface reiche ich nach. Hab gestern Abend direkt im Plugin noch zwei Debug-Stellen auskommentiert, damit im Log auch die Werte, welche ausgelesen werden, angezeigt werden. Seitdem trat der Fehler "leider" nicht mehr auf 😅

[ivande]

Laut Anleitung sind die Daten in zwei aufeinanderfolgenden 16 bit Registern

hast du einen Link zur Anleitung und evtl. einen Sceenshot der falsch gelesenen Register-Werte vom Plugin(Admin-Interface) - mit Angabe wie der Wert tatsächlich aussehen sollte.

Gruß Ivan

[fuppy]

Danke Tom Bombadil für deine schnelle Antwort.

Datentypen sollten passen. Laut Anleitung sind die Daten in zwei aufeinanderfolgenden 16 bit Registern gespeichert. Als Datentyp hab ich float32 ausgewählt. Bzgl. Endianess hab ich keine Infos. Aber da die Daten aber ja zeitweise passen, kann ich mir schwer vorstellen, dass es daran liegen kann... echt komisch...

[Tom Bombadil]

Erste fixe Ideen: Stimmen Datentyp / Endianess? Evtl sind nur High- und Lowbyte vertauscht (little vs big endian). Hatte das neulich in einer anderen Supportanfrage schon mal ...

/tom

[fuppy]

Hallo zusammen,
ich hoffe, dass mir hier jemand weiterhelfen kann.
Ich benutze ebenfalls das modbus_tcp Plugin in der Version 1.0.7. Ich möchte damit über einen Waveshare RS485 to ETH Converter ein EASTRON SDM-72D-M Zähler auslesen.
Insgesamt lese ich drei Werte aus. Auf den ersten Blick passt soweit auch alles.
Jedoch habe ich das Phänomen, dass in SHNG plötzlich unsinnige Werte angezeigt werden. Bei näherer Betrachtung stellt man fest, dass die Werte vertauscht sind.

Im Debug-Modus kann ich leider nicht sehen, ob der Fehler nun innerhalb des Plugins oder schon vorher stattfindet.

Ich hab parallel dann mit einem Modbus Client den Zähler respektive den Converter ausgelesen. Hier passen die Werte... deshalb mutmaße ich, dass im Plugin irgendetwas schief läuft.

Hat jemand ne Idee, wie ich dem Ganzen auf die Schliche kommen könnte?

Danke!

[Jackhammer]

Letzteres ist evtl. der richtige Hinweis.

Versuch mal bitte ein Register weiter unten (342) oder weiter oben (344). Vermutlich fängt Deine Registerübersicht bei 1 an, während die Adressierung bei 0 beginnt (nur die alternative 40.000er-Schreibweise fängt bei 40.001 an).
/tom

Minus 1 sieht gut aus. Werde das die Tage mit den anderen Registern verproben.

Das Gerät ist übrigens ein EASTRON SDM-72D-M V2, falls hier irgendwann noch jemand das Problem haben sollte :P

[Tom Bombadil]

Tom Bombadil: Danke für den Link. Ich komme aber dennoch nicht weiter.

Den angezeigten Wert aus SHNG bekomme ich in QModMaster angezeigt, wenn ich in den Setting als Base Address 0 auswähle.

Letzteres ist evtl. der richtige Hinweis.

Versuch mal bitte ein Register weiter unten (342) oder weiter oben (344). Vermutlich fängt Deine Registerübersicht bei 1 an, während die Adressierung bei 0 beginnt (nur die alternative 40.000er-Schreibweise fängt bei 40.001 an).

Ein Beispiel dafür hier - beide Arten der Adressierung für dasselbe Register sind in diesem Beispiel enthalten, die 'kleine' über die ID und die 'große' über HoldingRegister HR.

/tom

[Jackhammer]

Tom Bombadil: Danke für den Link. Ich komme aber dennoch nicht weiter.

Wenn ich das InputRegister 343 mit QModMaster auslese wird der Wert richtig angezeigt. In SHNG ist der Wert immer falsch, egal ob ich Endian.Big oder Little auswähle.
Den angezeigten Wert aus SHNG bekomme ich in QModMaster angezeigt, wenn ich in den Setting als Base Address 0 auswähle.
Das Item ist wie folgt konfiguriert:

    TotalActiveEnergy:
        type: num
        name: TotalActiveEnergy
        modBusObjectType: InputRegister     #(optional) default: HoldingRegister
        modBusAddress: 343
        modBusDataType: float32               #(optional) default: uint16
        modBusByteOrder: 'Endian.Big'    #(optional) default: 'Endian.Big'
        modBusWordOrder: 'Endian.Big'    #(optional) default: 'Endian.Big'
        #modBusDirection: 'read'       #(optional) default: 'read'
        #modBusUnit: 2                   #(optional) default: slaveUnit aus der Plugin-Konfig
        #modBusFactor: 0.1                  #(optional) default: 1
        #modBusDirection: read_write        #(optional) default: 'read'​

[tullsta]

Hallo,

nur ein kurzer Kommentar und falls doppelt bitte ignorieren:
bekam gestern eine Fehlermeldung beim Laden von modbus_tcp v1.0.7 mit pymodbus v3.0.2 / pymodbus3 v1.0.0:

ModuleNotFoundError: No module named 'pymodbus.client.sync'
No module named 'pymodbus.client.sync'

Hab' dann die Loesung die ich in pluggit von msinn gefunden haben uebernommen:

try:
    # for newer versions of pymodbus
    from pymodbus.client.tcp import ModbusTcpClient
except:
    # for older versions of pymodbus
    from pymodbus.client.sync import ModbusTcpClient

HTH + LG - tullsta

[Tom Bombadil]

Bei grundsätzlichen Fragen zu Modbus hilft evtl. --> das hier.

/tom

[Jackhammer]

Ja ich auch. Ich hatte verstanden, dass das wenigstens im Develop drin ist. Wie sollen die Leute denn das dann testen?



Geht das überhaupt? So wie ich das sehe muss man immer das komplette Release als Basis nehmen, was ich ehrlich gesagt als etwas umständlich erachte. Denn man hat Mühe überhaupt festzustellen, wo was geändert wurde. Einzeln runterladen kann man das ja bei github auch nicht - geht immer nur das komplette Paket. Oder ich stelle mich da auch zu doof für an.

ich hab mir mal den Stand aus deinem Repo geklont und in SHNG 1.9.3 in Betrieb genommen. Das Plugin läuft jetzt, ich bekomme auch Werte vom Bus. Die sind allerdings noch nicht richtig. Da das mein erster Modbus versuch ist kann das aber an mir liegen

[Msinn]

Da wird er nix finden, da Deine Änderungen noch nicht akzeptiert wurden. Die sind noch in einem 'Zwischenstadium', siehe oben. Irgendwann lernen wir beide vielleicht mal, wie man auf Github auch gegen *einzelne* Plugins *einzelne* PR's machen kann (ich bin zu doof dafür) - dann geht's wohl auch schneller.

Tom Bombadil Zu dem Kudelmuddel um diesen PR und den Aussagen dazu in diesem Thread habe ich Dir eine PN geschrieben.

[Cannon]

ich bin zu doof dafür

Ja ich auch. Ich hatte verstanden, dass das wenigstens im Develop drin ist. Wie sollen die Leute denn das dann testen?

einzelne* Plugins *einzelne* PR's machen kann

Geht das überhaupt? So wie ich das sehe muss man immer das komplette Release als Basis nehmen, was ich ehrlich gesagt als etwas umständlich erachte. Denn man hat Mühe überhaupt festzustellen, wo was geändert wurde. Einzeln runterladen kann man das ja bei github auch nicht - geht immer nur das komplette Paket. Oder ich stelle mich da auch zu doof für an.

[Tom Bombadil]

Schau mal im develop branch bei den plugins.

Da wird er nix finden, da Deine Änderungen noch nicht akzeptiert wurden. Die sind noch in einem 'Zwischenstadium', siehe oben. Irgendwann lernen wir beide vielleicht mal, wie man auf Github auch gegen *einzelne* Plugins *einzelne* PR's machen kann (ich bin zu doof dafür) - dann geht's wohl auch schneller.

/tom