Neue Versionen und Support zum Modbus-Modul

[Wzut]

fühle mich wie in den 80er zurück

[OT on]
Klar, Modbus entwickelt von Modicon in den 80 Jahren. War damals als noch jeder SPS Hersteller sein eigenes serielles Protokoll via 20mA/RS232/RS485 hatte bei uns die einzige Möglichkeit Geräte verschiedener Hersteller direkt zu miteinander koppeln. Fast alle konnten neben dem eigenen Hausprotokoll auch das Fremdprotokoll Modbus
[OT off]

[Knallkopp_02]

Bei mir hat sich herausgestellt, das es kein Mosbus ist, sondern eine ganz einfache serielle Verbindung die ich jetzt noch konfigurieren muss.

Hier mal der Link zum Post https://forum.fhem.de/index.php/topic,110470.0.html

Gruß Knallkopp_03

[crispyduck]

Hallo,

nach sehr langer Zeit ohne Probleme  möchte ich mein System um ein Device erweitern.

Würde hierfür aber gerne einen zweiten unabhängigen Modbus betreiben.

Ist es möglich ein zweites Modbus Device mit einem separaten USB to RS485 Adapter anzulegen?

Wenn ja, wie sieht es mit ModbusAttr aus? Hier wird ja auf kein Modbus Device verwiesen.

Lg crispyduck

[StefanStrobel]

Hallo crispyduck,

das solle kein Problem sein.
Ich habe bei mir auch mehrere Adapter für verschiedene Modbus-Geräte.
Einfach das IODev entsprechend auf das physische Modbus-Gerät setzen.

z.B.

Code Auswählen Erweitern


define Waermepumpe ModbusAttr ...
define RS485MB Modbus ...
attr Waermepumpe IODev RS485MB
...


Gruss
    Stefan

[crispyduck]

Hallo Stefan.

Ah, über das IODev Attribut! 

Super danke! Dann sollte das ja ohne Probleme Funktionieren.
Hoffentlich geht nach über einem Jahr ohne Update nach einem Update auch noch alles andere. 

Lg,
crispyduck

[crispyduck]

Hallo Stefan, hätte da noch eine Frage.

Da es zumindest für mich bei sehr vielen Modbus Registern mit den Attributen sehr schnell unübersichtlich wird hab ich mir vor längerer Zeit einmal ein device Modul geschrieben welches abhängig von einem zusätzlichem Parameter beim define paresinfo und deviceinfo aus einem cfg file ladet und dann erst MudbusLD_Define aufruft.
Funktioniert zwar, aber eben nur einmal da, wenn ich es richtig verstehe paresinfo und deviceinfo im modul hash $modules{$hash->{TYPE}}; steht und somit nur 1x pro modul und nicht pro device existiert.

Hab mir das heute nach 2,5 Jahren mal wieder angesehen, hab aber keinen Plan ob man das irgendwie hin bekommen könnte.

Wenn ich das richtig verstehe nutzen die ModbusLD subs den modul hash, was dann auch der Grund ist weshalb mir das letzte define immer alles überschreibt.

Hast du eine Idee ob und wie das überhaupt funktionieren könnte?

Lg,
crispyduck

[StefanStrobel]

Hallo crispyduck,

Ich würde einfach die Attribute einmal per "set saveAsModule" als neues Modul speichern und dann für jedes Gerät statt ModbusAttr ModbusGerät1 etc. verwenden. Dann sind die ganzen Attribute sauber in einer Datei und können dort bei Bedarf auch ergänzt oder geändert werden.
Man kann aber auch weiterhin alle Attribute von ModbusAttr auf so ein neues Modul anwenden und spontan Dinge erweitern oder überschreiben.

Eine cig-Datei wie Du es beschrieben hast, ist doch eigentlich auch nichts anderes, nur eben ein Sonderweg.

Gruß
    Stefan

[crispyduck]

Hallo Stefan,

ja, so mache ich es jetzt dann auch. Idee dahinter war ein mehr oder weniger "dummes" Modul für alles zu haben und die config der unterschiedlichen device Typen dann aus einem File aus der DB zu laden.
Hab bei mir das File System der Raspi auf welcher FHEM läuft als ro konfiguriert, und speicher eigentlich alles was die Konfiguration betrifft in der DB.
Momentan, nachdem ich damals drauf gekommen bin das ich mir den Modul hash jedesmal überschreibehabe ich eben pro device Typ ein Modul welches sich dann wiederum die config aus einem file in der DB holt. Geht zwar, aber dann braucht man erst recht wieder ein Modul pro device typ.
Wie gesagt hab da jetzt zwei Jahre nichts gemacht und gestern als ich mir das dann wieder angesehen habe ist mir dann aufgefallen das es wohl daran liegt das paresinfo und deviceinfo  im Modul hash gespeichert werden.
Wenn ich das richtig sehe gibt es ohne das Basis Modbus Modul zu ändern eigentlich keine Möglichkeit das was ich möchte umzusetzen.

Bevor ich also mein Vorhaben komplett verwerfe dachte ich ich frag mal ob es vielleicht doch eine andere Möglichkeit gibt die ich einfach nicht sehe.

Lg,
crispyduck

[crispyduck]

So, da mir das keine Ruhe gelassen hat hab ich mich jetzt meinen halben Urlaubstag damit beschäftigt. 

Ohne wirkliche Programmier und Perl Kenntnisse nicht so einfach.

Denke ohne wirklich was im 98_Modbus.pm Modul zu ändern ist das was ich möchte, parseInfo und devInfo per Device und nicht per Modul zu haben wohl nicht möglich.

Hab jetzt testweise in 98_Modbus.pm Modul paar kleine Änderungen gemacht.

alle

Code Auswählen Erweitern

my $parseInfo = ($hash->{parseInfo} ? $hash->{parseInfo} : $modHash->{parseInfo});
ersetzt mit

Code Auswählen Erweitern

my $parseInfo = ($hash->{parseInfo} ? $hash->{parseInfo} : ($modHash->{$hash->{NAME}}->{parseInfo} ? $modHash->{$hash->{NAME}}->{parseInfo} : $modHash->{parseInfo}));

und alle

Code Auswählen Erweitern

my $devInfo   = ($hash->{deviceInfo} ? $hash->{deviceInfo} : $modHash->{deviceInfo});   
ersetzt mit

Code Auswählen Erweitern

my $devInfo   = ($hash->{deviceInfo} ? $hash->{deviceInfo} : ($modHash->{$hash->{NAME}}->{deviceInfo} ? $modHash->{$hash->{NAME}}->{deviceInfo} : $modHash->{deviceInfo}));


Damit wäre es möglich parseInfo und deviceInfo in "modul-hash->{device-name}" zu speichern.
Sollte es "modul-hash->{device-name}->{parseInfo}" geben, so wird dies verwendet, sonst wie gehabt "modul-hash->{parseInfo}"

Spricht irgend was dagegen das so zu machen? Damit wäre es möglich statt nur pro Modul auch per Device parseInfo und deviceInfo festzulegen.

Hoffe mal ich hab hier nichts wesentliches vergessen.

Lg, crispyduck

[StefanStrobel]

Hallo crispyduck,

das muss ich mir mal in Ruhe ansehen.
Ich packs auf die Wunschliste

Gruss
   Stefan

[StefanStrobel]

Korrektur: das war schon auf der Wunschliste und ist in meiner Arbeitskopie auch schon drin.
Ich habe da allerdings auch einige andere Sachen umgestellt und noch nicht ganz zu Ende gebracht. Insbesondere wenn das Modul als Relay verwendet wird. In letzter Zeit habe ich mich mehr um die neue Version von ArduCounter gekümmert. deshalb hat sich beim Modbus-Modul weniger getan. 
Du kannst meine aktuelle Version aber gerne mal testen.
Bei mir hat sie in den letzten Monaten keine Probleme verursacht.

Gruss
   Stefan

[crispyduck]

Super, Danke! Werde ich testen.

Frage noch dazu, wo/wie muss hier parseInfo und devInfo im device hash stehen? Blick mich nicht ganz durch wo hier der device hash genommen wird.

Lg,
crispyduck

[StefanStrobel]

Hallo,

ein logisches Modul auf Basis von Modbus (wie zum Beispiel ModbusAttr oder ModbusSET) kann $hash->{parseInfo} setzen.
Zum Zugriff auf Objektinformationen (Länge, unpack etc.) wird intern meist die Funktion Modbus_ObjInfo aufgerufen.

Code Auswählen Erweitern


################################################
# Get Object Info from Attributes,
# parseInfo Hash or default from deviceInfo Hash
sub Modbus_ObjInfo($$$;$$) {
    my ($hash, $key, $oName, $defName, $lastDefault) = @_;
    #   Device  h123  unpack  defUnpack
    $hash = $hash->{CHILDOF} if ($hash->{CHILDOF});                     # take info from parent device if TCP server conn (TCP slave)
    my $name      = $hash->{NAME};
    my $modHash   = $modules{$hash->{TYPE}};
    my $parseInfo = ($hash->{parseInfo} ? $hash->{parseInfo} : $modHash->{parseInfo});


falls $hash->{parseInfo} existiert, wird diese Struktur (aus dem Hash des logischen Geräts) verwendet. Falls nicht, dann die aus dem Modulhash.
In jedem Fall aber haben Attribute nochmal Vorrang vor dem parseInfo Hash.

Gruss
   Stefan

[stolus]

Guten Abend,
läst sich die Relay Funktion auch zwischen zwei FHEM Instanzen nutzen?
In meinem Anwendungsfall ist eine Wärmepumpe über RS485 mit einem RaspberryZero verbunden.
Das funktioniert dank Hilfe von Hollo ganz gut.
Jetzt würde ich gerne auf meinem Haupt FHEM Server auf dem Dachboden, als Masterdevice die Wärmepumpe steuern.
Ich habe das relay und den Master gerade zusätzlich angelegt, leider kommt nur disconnected.

[StefanStrobel]

Hallo Stolus,

Ja, wenn eine erste Fhem-Instanz an der Wärmepumpe als Relay konfiguriert ist, und per Modbus als Master mit der Wärmepumpe als Slave reden kann, dann kann eine zweite Fhem-Instanz als Master mit der ersten Instanz als Slave reden und so auf die Wärmepumpe durchgreifen.

Poste doch mal Deine Konfiguration.

Gruß
   Stefan