Neue Versionen und Support zum Modbus-Modul

Begonnen von StefanStrobel, 20 August 2017, 12:11:08

Vorheriges Thema - Nächstes Thema

StefanStrobel

Hallo RobertSch,

Zitat von: RobertSch am 13 September 2022, 08:15:04
Bei meiner Recherche bin ich hier auf das 98_ModbusUMG604.pm Modul gestoßen und habe es eingebunden. Hier haben auch ein paar Leute geschrieben, wie das geht. Ich habe dazu das Modul wie folgt hinzugefügt:

define UMG604 ModbusUMG604 1 10 172.27.5.24:502 TCP

Die Verbindung zum Zähler scheint hiermit auch zu stehen und man kann die Stromwandler und Spannungswandler entsprechend einstellen. Allerdings ist das auch der Punkt, bei dem es bei mir aufhört. Ich möchte gerne gezielt die Werte auslesen, wie Spannung L1, L2, L3 sowie Leistung der einzelnen Phasen und Gesamtleistung etc.. In den Code Ausschnitten hier steht dann, das man entsprechend per attr die Daten abrufen/auslesen lassen kann.
woher hast Du denn das ModbusUMG604-Modul? Welche Werte da abgefragt werden, müsstest Du im Modulcode nachsehen oder per set Gerät CreateAttrsFromParseInfo das ganze wieder auf die ModbusAttr-Konfiguration zurückführen. Falls da dann Objekte definiert sind, die nicht abgefragt werden, dann fügst Du am besten ein Attribute für das entsprechende Register ein, z.B. obj-h100-poll o.ä. Die tatsächlichen Objekte / Adressen siehst Du nach set Gerät CreateAttrsFromParseInfo.

Gruss
   Stefan


StefanStrobel

Hallo aikawa24,

Zitat von: aikawa24 am 17 September 2022, 01:55:16
die werte die nur ein Register füllen kommen an aber wenn die 2 und mehr füllen bekomm ich das reading nicht angezeigt bzw nur 0
bei dem Namen und Serien Nummer hab ich es mit unpack a16 oder a8 hinbekommen, jenachdem wie viele Register der wert füllt.
eine doch gibts hier https://www.cfos-emobility.de/en/cfos-power-brain/modbus-registers.htm
ich habs schon mit den Standards s> f> und n probiert aber das bleibt immer 0
bei Register 8058 müsste zumindest 1307,2 kWh rauskommen

um Dir helfen zu können, müsste ich Deine tatsächliche Konfiguration kennen. Poste die doch mal zusammen mit einem Auszug aus dem Log bei verbose 5.

Gruss
   Stefan

RobertSch

Zitat von: StefanStrobel am 17 September 2022, 14:09:49
Hallo RobertSch,
woher hast Du denn das ModbusUMG604-Modul? Welche Werte da abgefragt werden, müsstest Du im Modulcode nachsehen oder per set Gerät CreateAttrsFromParseInfo das ganze wieder auf die ModbusAttr-Konfiguration zurückführen. Falls da dann Objekte definiert sind, die nicht abgefragt werden, dann fügst Du am besten ein Attribute für das entsprechende Register ein, z.B. obj-h100-poll o.ä. Die tatsächlichen Objekte / Adressen siehst Du nach set Gerät CreateAttrsFromParseInfo.

Gruss
   Stefan

Hallo Stefan!

Danke für deine Antwort. Ich stehe leider immer noch auf dem Schlauch. War zwar auch ne Woche im Urlaub und hatte gehofft, das mir die Auszeit vielleicht eine Idee bringt, aber leider ist dem nicht so.
Das Modul habe ich hier aus dem vorherigen Thread und es wurde von golem hier https://forum.fhem.de/index.php/topic,25315.msg268721.html#msg268721 geteilt.

Mein Problem liegt halt glaub ich darin, das ich wohl noch gar nicht verstanden habe, wie ich ein Modbus Gerät konfiguriere. Denn sowie ich das bisher verstehe sorgt das Modul von golem ja nur dafür, das man die Register etc. nicht mehr händisch heraussuchen muss. In dem Thread gibt es auch Einträge, wie es in der fhem.cfg konfiguriert wurde. Wenn ich die allerdings 1:1 mit passender IP versteht sich übernehme, habe ich zwar das Gerät in fhem, aber die Attribute sind nicht gesetzt. Das eine Verbindung zum Gerät steht ist mit "opened" denke ich klar, weil sonst ein "timeout" entstehen würde. Wie gesagt, im golem Modul kann ich auch mittels "set Gerät Spannungswandler_PrimärL1 Wert" entsprechend die Variablen für den Spannungswandler etc. einstellen. Ich bekomme lediglich keine Informationen zu den einzelnen Messwerten zurück. Ein "createAttrsFromParseInfo" gibt es auch, aber ich versteh nicht so ganz, was ich in das Wert/Variablen Feld dahinter setzen muss, damit was sinnvolles passiert.

Evtl. ist mein Weg, den ich bisher gegangen bin auch vollkommen falsch und es gibt andere bessere Wege. Ich wäre sehr froh, wenn ich hier weiter käme. Verstehe auch noch nicht so ganz, wie die Module modbus und mobusAttr. zusammenhängen. Vielleicht liegt da auch das Problem. Kannst du mir da bitte auch einmal den groben Zusammenhang erklären? Ich hoffe ja immernoch, das irgendwann der "Aha"-Moment kommt.

Danke im Voraus!

StefanStrobel

Hallo RobertSch,

Der Status opened bedeutet zunächst mal nur dass die TCP-Verbindung steht, bzw. bei seriellen Verbindungen dass die Schnittstelle geöffnet wurde.
Ob Fhem tatsächlich mit dem Gerät kommunizieren kann, ist eine andere Frage.
Du hast geschrieben dass Du den Spannungswandler über Fhem einstellen kannst. Hast Du auch kontrolliert, ob die Werte im Gerät wirklich ankommen? Oder hat Fhem nur keine Fehlermeldung angezeigt?
Am besten sieht man das wenn man das Attribut verbose auf 5 setzt und dann im Log beobachtet, wie das Gerät antwortet.
Stimmt denn die Modbus-Id überhaupt?

Zum Auslesen:
Ich hab mir das Modul für den Zähler angesehen. Darin steht z. B.:


    "h10048"=>  {
name => "vt_priml1",
          defaultpoll => "once",
showget => 1,
reading => "Spannungswandler_PrimärL1",
          set => 1,
          min => 100,
max => 60000
          },
         



das holding register 10048 enthält offenbar den Wert für Spannungswandler_PrimärL1.
gelesen wird der Wert einmal beim Start von Fhem oder manuell per get Spannungswandler_PrimärL1
Klappt das mit dem get denn oder kommt da ein Fehler?
Auch hier hilft ein Blick ins Log.
Wenn das alles klappt und Du den Wert regelmäßig lesen möchtest, dann kannst Du das mit dem Attribut obj-h10948-poll überschreiben.
Im Prinzip ist das Modul für Deinen Zähler nur ein vorkonfigurierten ModbusAttr.

Gruß
    Stefan


ahermann86

Hallo Stefan,

ich versuche gerade mein Modul https://forum.fhem.de/index.php/topic,117416.0.html mit deinem Modbus RTU Modul zu ersetzen. Der Denkfehler an meinem Modul ist, dass ich natürlich ein Device (USB/RS485) nur einmal auf machen kann. Ich muss das ganze nun mit einem weiteren Teilnehmer erweitern...

Hier ein Teil der Modbus Definition:
defmod Mod_Pumpen ModbusAttr 2 1
attr Mod_Pumpen IODev Modbus_Dev
.
.
.
attr Mod_Pumpen obj-c3-map 0:off, 1:on
attr Mod_Pumpen obj-c3-reading Rel4
attr Mod_Pumpen obj-c3-set 1
attr Mod_Pumpen obj-d2-len 1
attr Mod_Pumpen obj-d2-poll 1
attr Mod_Pumpen obj-d2-reading In
attr Mod_Pumpen obj-d2-showGet 1
attr Mod_Pumpen obj-h16384-reading Adr
attr Mod_Pumpen obj-h16384-set 1
attr Mod_Pumpen room Modbus
.
.
.


Die Relais, welche über Coils angesteuert werden, funktionieren. Die Eingänge sollen sich über "Discrete Inputs" also mit der Funktion 02 lesen lassen. In der Beschreibung steht hierzu das:

Zitat
Read all interfaces input status
01 02 00 00 00 00 78 0a
return:
01 02 01 01 60 48 //IN1 pressed
01 02 01 02 20 49 //IN2 pressed
01 02 01 04 A0 4B //IN3 pressed
01 02 01 08 A0 4E //IN4 pressed

Wenn ich das richtig sehe, ist der Response kürzer als in der Spec.

Nun die Frage, was müsste ich tun, damit es mit deinem Modul funktioniert?

Gruß
Axel

StefanStrobel

Hallo Axel,

So spontan würde ich sagen, dass die Antwort ok ist.
Id, fcode, bytecount, data und checksum.
Der bytecount ist ja selbst nur ein Byte.

Sollte also alles funktionieren.

Gruß
   Stefan

ahermann86

Hallo Stefan,

so verstehe ich das auch.
Wenn ich das so einbaue, geht es nur, wenn der Wert 01 = 1 oder 00 = 0 ist.
Der Wert (bzw. die Bits) 02, 04 oder 08 werden ignoriert.

Kann es sein, dass das Modus das Ergebnis mit 0x01 ausmaskiert, sodass nur das erste Bit bewertet wird?

Gruß
Axel

franky08

Hallo, ich komme irgendwie nicht weiter und habe einen neuen Thread aufgemacht, kann da mal jemand drüber schauen?

https://forum.fhem.de/index.php/topic,129367.0.html

Vielen Dank
Frank
Debian Wheezy auf ZBOX nano/ Debian Bullseye auf 2.ter ZBOX nano F2F an 2x RaspiB
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu ,fhem5.8, CCU2,
ECMD an AVR-NET-IO mit DAC u. ADC an Junkers Stetigregelung, Siemens LOGO!8, JeeLink uvm...

ahermann86

Hallo Stefan,

ich habe noch ein wenig geforscht. Die Antwort passt aber dein Modul ist sehr genau, was es mit Antworten auf sich hat ;)
In Zeile 2542 wird aus allem was größer als 0 ist eine 1 gemacht.
Zitat..SplitDataString shortened coil / input bit string to..
Nach Spec ist das richtig aber für mich nicht gut.

Ich habe das mal geändert und das if umgebaut.. es würde so gehen - bis ich das Modul updaten würde.

Nun meine Frage, würdest du ein Atttribut einführen, was auch Zahlen größer 1 für discrete zulässt?
Alternativ würde ich die Datei 98_Modbus.pm kopieren, umbenennen und anpassen .. Problem: Das ist mit dem Namespace (glaube es liegt an package..?) etwas kompliziert und auf die Schnelle so nicht machbar.
Oder: ich ändere die original 98_Modbus.pm für mich und nehme die aus dem Updatevorgang raus - gibt es diese Möglichkeit?

Gruß
Axel

StefanStrobel

Hallo Axel,

Du hast recht, es hängt an der Längenangabe.
Das Modul verwendet die im Request angegebene Anzahl an discrete inputs (oder coils) um die relevanten Bits der Response in Readings zu setzen.
In Deinem Fall antwortet das Gerät bei Anzahl 0 mit allen Inputs und das Modul nimmt bei 0 wenigstens den ersten Eingang.
Was passiert eigentlich wenn Du im Request statt 0 eine 4 als echte Länge angibst?
Wenn das funktioniert (so wäre es vom Standard vorgesehen) dann wäre ja keine Änderung nötig.
Falls nicht kann ich gerne ein weiteres brokenFCxx Attribut für Sonderfälle / nicht korrekte Modbus-Implementationen hinzufügen.

Gruß
   Stefan

ahermann86

Hallo Stefan,

wenn ich eine Länge angebe, ändert das auch nichts. So wie ich verstanden habe, meinst du das so:


attr Mod_Pumpen dev-c-defLen 4
attr Mod_Pumpen dev-d-defLen 4
attr Mod_Pumpen obj-d2-len 4


Wenn ich aber den Code richtig verstehe, bringt das nichts, da mit Z2542: if ($type =~ '[cd]') und Z2556: $unpack  = 'a'; das wieder gekürzt wird. Die Länge wird hier nicht beachtet...

Ich habe es nur hinbekommen, als ich das d aus dem Z2542: if ($type =~ '[c]') {  #[cd] ausgenommen habe.
Gleichzeitig müsste dann aber weiter unten das Z2556: $unpack  = 'a'; in der while zu z.B. 'c' geändert werden...

Gruß
Axel

RobertSch

Zitat von: StefanStrobel am 28 September 2022, 09:43:16
Hallo RobertSch,

Der Status opened bedeutet zunächst mal nur dass die TCP-Verbindung steht, bzw. bei seriellen Verbindungen dass die Schnittstelle geöffnet wurde.
Ob Fhem tatsächlich mit dem Gerät kommunizieren kann, ist eine andere Frage.
Du hast geschrieben dass Du den Spannungswandler über Fhem einstellen kannst. Hast Du auch kontrolliert, ob die Werte im Gerät wirklich ankommen? Oder hat Fhem nur keine Fehlermeldung angezeigt?
Am besten sieht man das wenn man das Attribut verbose auf 5 setzt und dann im Log beobachtet, wie das Gerät antwortet.
Stimmt denn die Modbus-Id überhaupt?

Zum Auslesen:
Ich hab mir das Modul für den Zähler angesehen. Darin steht z. B.:


    "h10048"=>  {
name => "vt_priml1",
          defaultpoll => "once",
showget => 1,
reading => "Spannungswandler_PrimärL1",
          set => 1,
          min => 100,
max => 60000
          },
         



das holding register 10048 enthält offenbar den Wert für Spannungswandler_PrimärL1.
gelesen wird der Wert einmal beim Start von Fhem oder manuell per get Spannungswandler_PrimärL1
Klappt das mit dem get denn oder kommt da ein Fehler?
Auch hier hilft ein Blick ins Log.
Wenn das alles klappt und Du den Wert regelmäßig lesen möchtest, dann kannst Du das mit dem Attribut obj-h10948-poll überschreiben.
Im Prinzip ist das Modul für Deinen Zähler nur ein vorkonfigurierten ModbusAttr.

Gruß
    Stefan

Vielen lieben Dank! Es wird so langsam. Also als erstes, die Daten gehen raus, werden geschrieben wenn ich den set-Befehl nutze und können auch per get-Befehl gelesen werden. Allerdings klappt das mit dem regelmäßigen Abruf nicht. Ich habe dazu die unterschiedlichsten Varianten versucht, aber unter Readings taucht am Ende keiner meiner Versuche auf. Darunter war auch dein obj-h10948-poll, wobei das glaub ich eigentlich obj-h10048-poll sein sollte, oder? Habe jedenfalls beides getestet und es gab keine Reaktion.

Im Log steht dann immer folgendes:
umg604: unknown attribute Real_energy_L2_Supply. Type 'attr umg604 ?' for a detailed list.

Heißt, dort ändert sich auch nur Wert des attribute, den ich zum testen vorher in der fhem.cfg eingebe. Über die fhem Leiste probiere ich es mittlerweile gar nicht erst, weil auch dort immer sofort die Fehlermeldung kommt. Ist auch egal, ob ich hier das Register h10048, deine Version mit poll am Ende, dasselbe mit poll davor, oder wie im Code direkt die Readings anspreche. Immer komt dieser Fehler.

Am Ende fehlt anscheinend nur noch ein kleines Puzzleteil um mein Problem zu beheben. Hast du da vielleicht noch eine Idee für mich, woran es haken könnte?

Gruß
Robert

StefanStrobel

#972
Hallo Axel,

nein, ich dachte eher an einen Test mit einem normalen Modbus-Programm für Windows.
Wenn Dein Gerät dann auch korrekte Requests mit Längenangabe oder Abfrage von einzelnen Inputs mit Adresse > 0 akzeptiert, dann ist der Rest ohne Änderung machbar.

Im Fhem-Modul geht das dann so dass Du für jeden Eingang ein eigenes Objekt erzeugst. Jedes mit individueller Adresse I0, I1, ... und Länge 1.
Über combine oder group kann das Modul dann die Requests zu einem einzigen zusammenfassen.

Siehe z.B. auch https://forum.fhem.de/index.php/topic,129080.msg1234340.html#msg1234340

Gruß
    Stefan

StefanStrobel

Zitat
Im Log steht dann immer folgendes:
umg604: unknown attribute Real_energy_L2_Supply. Type 'attr umg604 ?' for a detailed list.

Heißt, dort ändert sich auch nur Wert des attribute, den ich zum testen vorher in der fhem.cfg eingebe. Über die fhem Leiste probiere ich es mittlerweile gar nicht erst, weil auch dort immer sofort die Fehlermeldung kommt. Ist auch egal, ob ich hier das Register h10048, deine Version mit poll am Ende, dasselbe mit poll davor, oder wie im Code direkt die Readings anspreche. Immer komt dieser Fehler.

Am Ende fehlt anscheinend nur noch ein kleines Puzzleteil um mein Problem zu beheben. Hast du da vielleicht noch eine Idee für mich, woran es haken könnte?


Hallo Robert,

Ich vermute Du verwendest schlicht den attr-Befehl falsch.

attr UMG604 obj-h10048-poll 1

sollte funktionieren.
Wenn Du über die Fhem-Eingabezeile eine Fehlermeldung bekommst, dann machst Du definitiv etwas falsch.

Du kannst auch einfach ein set createAttrsFromParseInfo auswählen, dann werden die ganzen vorkonfigurierten Werte aus dem Modul als Attribute erzeugt und dann kannst Du das obj-h10048-poll einfach auswählen und von once auf 1 ändern.

Oder die öffnest die Moduldatei mit einem Editor und änderst es dort.

Gruß
    Stefan



ahermann86

Hallo Stefan,

welche Länge ich dem Request mitgebe, scheint dem Relayboard egal zu sein wie man auf dem Bild "Request mit L4" erkennt.
Die Antwort der jeweiligen Eingänge sieht man auf dem Bild "Response Eing 1 bis 4".

Das Datenbyte des discretes kann bei dem Board nicht nur 0 und 1 sondern auch 2, 4 und 8 - eben Bitcodiert. Ich schreibe es nur ungern aber die Lösung wäre hier nur, mit dem Attribut "brokenFCxx Attribut" alle Zahlen zuzulassen  :-\

Gruß
Axel