Neue Versionen und Support zum Modbus-Modul

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

Vorheriges Thema - Nächstes Thema

Andy1981

Hallo Crispyduck,
die vorherigen seiten dieses Thread hab ich aus Zeitgründen nur überflogen und deshalb deinen Eintrag übersehen...hätte mir wahrscheinlich etwas Zeit erspart. Das mit der geschwindigkeit für den netzwerkcontroller hab ich auch gelesen, ist halt auch nur ein workaround vorrübergehend. Bei dem datendurchsatz für Fhem bin ich mir nicht sicher ob man wirklich einen nachteil hat, ich konnte bisher keinen nachteil feststellen.
Mir ging es in erster Linie mal darum, dass ich mit meinen vorhandenen mitteln die Zähler auslesen und loggen kann, nächstes Jahr bekomme ich 3 verschiedene Adapter zum testen, mal schauen wie sich die dann schlagen.
Die von mir verwendeten ftdi chips habe ich vor ca 2 jahren gekauft und bisher nur an windows PC's verwendet. Ich gehe mal davon aus, dass es sich hierbei nicht um fakes handelt, zumindest hat der windows treiber noch nicht die ID gelöscht. Hört sich allerdings nicht so toll an, wenn du mit anderen chips die gleichen Probleme am Raspberry hast.
Wünsche dir viel erfolg  mit deinem Adapter, werde mich wieder melden wenn ich die anderen adapter getestet habe.
Gruß Andreas

crispyduck

Hi,

Also ich glaube mein Digitus Adapter hat was. Habe jetzt einen Loopback test mit dem China Adapter und dem Digitus gemacht und wie es scheint sendet der neue Adapter nichts.
Habe jetzt einen neuen bestellt, mal schauen.

@FTDI an der Raspi, ich hab seit Jahren auf der selben Raspi einen Viessmann Optolink Adapter mit FT232RL ohne einen einzigen Ausfall mit USB2.0 in Betrieb.

Ich bin mir immer noch nicht ganz sicher woher der " urb stopped: -32" Fehler kommt.
Dachte erst an ein Strom Problem, habe daher den Strom an USB Bus auf das maximum aufged (max_usb_current=1), half aber auch nicht, externer USB Hub mit eigenem Powersupply scheinte erst zu helfen, aber dann nach einer Woche wieder der Fehler. Mit USB 1.1 lief es eine Woche gut, bin dann aber wieder auf USB2.0.
Hatte den Stick mal schlecht angesteckt, da kam der Fehler dann viel häufiger. Strom schließe ich nach meinen Tests aus, dürfte eher ein Kommunikationsproblem zwischen USB controller und Stick sein, welches bei schlechtem Kontakt noch häufiger auftritt und bei langsamerer Bus Geschwindigkeit nicht auftritt.

Ich probiere es nächste Woche nochmal mit dem Digitus, und wenn der dann wieder nicht läuft, weiß ich auch nicht weiter, könnte dann nur noch einen USB 1.1 Hub dazwischen hängen um nur den Stick auf 1.1 zu haben.

@Stefan: neue Version läuft bei mir ohne Probleme und ich habe viel seltener Timeouts bei get Abfragen im Sekundentakt.

Lg
Crispyduck


crispyduck

Hi,

wollte nur nochmal Rückmeldung geben.

Also der erste Digitus Adapter hatte tatsächlich was, gestern ist dann der neue gekommen und der läuft jetzt mit 150 Ohm Abschlusswiderständen und 480 Ohm Pull up und Pull down Widerständen seit gestern Vormittag ohne Probleme.

Chip in dem Adapter ist ein FTDI FT232RL.

Lg,
crispyduck

Andy1981

Hi,

und ein frohes neues Jahr an alle.
Ich hab noch einen alten Lan com server von w&t in meinem bestand gefunden und angeschlossen...funktioniert einwandfrei. Wahrscheinlich werde ich mit dieser variante weitermachen und mich vorerst nicht mehr um den zickigen usb am raspberry kümmern.
Als nächstes steht an meine pluggit lüftung an den rs485 bus zu bringen, was ziemlich lustig werden kann. Zum glück haben die Kollegen vom knx Forum da schon viel vorarbeit geleistet.

Gruß Andreas

Andy1981

Hallo Modbus/Perl Spezialisten,

mein Modbus üer den Com Server läuft nach wie vor noch stabil und ich habe jetzt mal ein bisschen weiter an der Anbindung meiner Pluggit Lüftung gearbeitet. Die Kommunikation zur Anlage läuft bereits, momentan kämpfe ich allerdings mit der unpack Schablone um die Werte in den Readings richtig anzuzeigen. Die Pluggit Anlage sendet die meisten Daten wie z.B die Temperaturen im Signed Byte Format. Im Holdingregister 9 befinden sich z.B. die Temperaturen für "Zuluft" im High Byte und "nach WT" im Low Byte. Wenn ich das Ganze jetzt mit der unpack Schablone "c" auswerte bekomme ich den richtigen Wert für das High Byte angezeigt, aber wie kann ich mir jetzt ein zweites Reading auf das gleiche Register anlegen und das Low Byte auswerten?  Gibt es eine Möglichkeit überhaupt im Modbusattr Modul die Bytes einzeln in Readings zu packen?
Meine nächste Idee wäre ansonsten das Register als Integer auszuwerten und anschließend versuchen das ganze als Userreading auszuwerten, momentan fällt mir zumindest keine andere Lösung ein.
Hat jemand einen Tipp für mich wie man die Aufteilung am besten realisieren kann?

Danke, Gruß
Andreas

StefanStrobel

Hallo Andreas,

Das Modbus-Modul geht beim Parsen davon aus, dass für jede Adresse nur ein Reading erzeugt wird.
Du könntest aber versuchen, in einer "expr" für eine Adresse per Perl readingsBulkUpdate($hash, "nachWT", $val) aufzurufen.
Die Expressions für ein Reading werden im Modul von der Funktion Modbus_CheckEval ausgewertet und dort steht der aktuelle Device-Hash und der Wert zur Verfügung.
Das hat gegenüber einem Userreading den Vorteil, dass Du das Ergebnis später als eigenes Modul für die Pluggit-Lüftung speichern kannst und andere Anwender keine zusätzlichen Attribute setzen müssen wenn Sie Dein Pluggit-Modul verwenden wollen.

Gruss
   Stefan

Negropo

Hallo,

ich bin relativ neu in der Modbus-Welt und versuche an FHEM eine Unipi Neuron Extension (xS10) via Modbus RTU anzubinden.
Ich habe folgende Konfiguration in der fhem.cfg mit der ich einige Register (die der 8 Relays) auslese


#Neuron xS10
define NeuronModbus Modbus /dev/ttyUSB0@19200,8,N,1
define NeuronxS10 ModbusAttr 15 10 RTU
attr NeuronxS10 dev-i-combine 8
attr NeuronxS10 userattr obj-i10001-reading obj-i10001-unpack obj-i10001-poll
attr NeuronxS10 obj-i10001-reading RO1
attr NeuronxS10 obj-i10001-unpack N
attr NeuronxS10 obj-i10001-poll 1

attr NeuronxS10 userattr obj-i10002-reading obj-i10002-unpack obj-i10002-poll
attr NeuronxS10 obj-i10002-reading RO2
attr NeuronxS10 obj-i10002-unpack N
attr NeuronxS10 obj-i10002-poll 1

attr NeuronxS10 userattr obj-i10003-reading obj-i10003-unpack obj-i10003-poll
attr NeuronxS10 obj-i10003-reading RO3
attr NeuronxS10 obj-i10003-unpack N
attr NeuronxS10 obj-i10003-poll 1

attr NeuronxS10 userattr obj-i10004-reading obj-i10004-unpack obj-i10004-poll
attr NeuronxS10 obj-i10004-reading RO4
attr NeuronxS10 obj-i10004-unpack N
attr NeuronxS10 obj-i10004-poll 1

attr NeuronxS10 userattr obj-i10005-reading obj-i10005-unpack obj-i10005-poll
attr NeuronxS10 obj-i10005-reading RO5
attr NeuronxS10 obj-i10005-unpack N
attr NeuronxS10 obj-i10005-poll 1

attr NeuronxS10 userattr obj-i10006-reading obj-i10006-unpack obj-i10006-poll
attr NeuronxS10 obj-i10006-reading RO6
attr NeuronxS10 obj-i10006-unpack N
attr NeuronxS10 obj-i10006-poll 1

attr NeuronxS10 userattr obj-i10007-reading obj-i10007-unpack obj-i10007-poll
attr NeuronxS10 obj-i10007-reading RO7
attr NeuronxS10 obj-i10007-unpack N
attr NeuronxS10 obj-i10007-poll 1

attr NeuronxS10 userattr obj-i10008-reading obj-i10008-unpack obj-i10008-poll
attr NeuronxS10 obj-i10008-reading RO8
attr NeuronxS10 obj-i10008-unpack N
attr NeuronxS10 obj-i10008-poll 1
attr NeuronxS10 verbose 5


Kann man das noch optimieren, z.B. durch irgend eine Kombination von Befehlen?
Wie kann ich die readings RO1, RO2... etc. in FHEM auswerten/anzeigen lassen (als Antwort kommt vom Neuron eine 0 wenn das Reay ausgeschaltet ist und eine 1 wenn ein) und die wichtigste Frage,
Wie sieht der Befehl (vermutlich ein SET) aus um das Relay zu schalten?

Vielen Dank und Gruß
Negropo

lewej

#67
Hallo Zusammen,

ich versuche ein Relay Board von Kmtronic(RS485) auslesen bzw. zu schalten, jedoch weiß ich nicht wie ich diese Adressen definieren muss. Kann mir jemand einen Tipp, bzw ein Bespiel für eine definition sagen?


Folgende habe ich bereits gemacht:
Internals:
   BUSY       0
   CFGFN     
   DEF        /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.4:1.0-port0@9600,8,N,1
   DeviceName /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.4:1.0-port0@9600,8,N,1
   FD         22
   LASTOPEN   1516646757.35302
   NAME       ModBusLine
   NR         50368
   NTFY_ORDER 50-ModBusLine
   PARTIAL   
   STATE      opened
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   READINGS:
     2018-01-22 19:45:57   state           opened
   helper:
     buffer     
Attributes:
   room       Modbus


Internals:
   CFGFN     
   DEF        5 60 RTU
   DEST       
   INTERVAL   60
   MODBUSID   5
   ModuleVersion 3.7.0 - 20.8.2017
   NAME       kmtronic1
   NOTIFYDEV  global
   NR         50584
   NTFY_ORDER 50-kmtronic1
   PROTOCOL   RTU
   STATE      ???
   TYPE       ModbusAttr
Attributes:
   room       Modbus
   userattr   


Laut Hersteller kann diese Relais Abfragen und schalten.


RS485 Relays commands




           ON Command                    OFF Command
              DEC   HEX                      DEC      HEX
Relay Board ID:01 Relay 1 Channel 1 255 1 1 FF 01 01 255 1 0 FF 01 00
Relay Board ID:01 Relay 2 Channel 2 255 2 1 FF 02 01 255 2 0 FF 02 00
Relay Board ID:01 Relay 3 Channel 3 255 3 1 FF 03 01 255 3 0 FF 03 00
Relay Board ID:01 Relay 4 Channel 4 255 4 1 FF 04 01 255 4 0 FF 04 00
Relay Board ID:01 Relay 5 Channel 5 255 5 1 FF 05 01 255 5 0 FF 05 00
Relay Board ID:01 Relay 6 Channel 6 255 6 1 FF 06 01 255 6 0 FF 06 00
Relay Board ID:01 Relay 7 Channel 7 255 7 1 FF 07 01 255 7 0 FF 07 00
Relay Board ID:01 Relay 8 Channel 8 255 8 1 FF 08 01 255 8 0 FF 08 00
Relay Board ID:02 Relay 1 Channel 9 255 9 1 FF 09 01 255 9 0 FF 09 00
Relay Board ID:02 Relay 2 Channel 10 255 10 1 FF 0A 01 255 10 0 FF 0A 00
Relay Board ID:02 Relay 3 Channel 11 255 11 1 FF 0B 01 255 11 0 FF 0B 00
Relay Board ID:02 Relay 4 Channel 12 255 12 1 FF 0C 01 255 12 0 FF 0C 00
Relay Board ID:02 Relay 5 Channel 13 255 13 1 FF 0D 01 255 13 0 FF 0D 00
Relay Board ID:02 Relay 6 Channel 14 255 14 1 FF 0E 01 255 14 0 FF 0E 00
Relay Board ID:02 Relay 7 Channel 15 255 15 1 FF 0F 01 255 15 0 FF 0F 00
Relay Board ID:02 Relay 8 Channel 16 255 16 1 FF 10 01 255 16 0 FF 10 00
Relay Board ID:03 Relay 1 Channel 17 255 17 1 FF 11 01 255 17 0 FF 11 00
Relay Board ID:03 Relay 2 Channel 18 255 18 1 FF 12 01 255 18 0 FF 12 00
Relay Board ID:03 Relay 3 Channel 19 255 19 1 FF 13 01 255 19 0 FF 13 00
Relay Board ID:03 Relay 4 Channel 20 255 20 1 FF 14 01 255 20 0 FF 14 00
Relay Board ID:03 Relay 5 Channel 21 255 21 1 FF 15 01 255 21 0 FF 15 00
Relay Board ID:03 Relay 6 Channel 22 255 22 1 FF 16 01 255 22 0 FF 16 00


Auf der Konsole kann ich die Relays schalten


echo -e '\xff\x01\x01' >  /dev/serial/by-path/pci-0000\:00\:14.0-usb-0\:4.4\:1.0-port0
echo -e '\xff\x01\x00' >  /dev/serial/by-path/pci-0000\:00\:14.0-usb-0\:4.4\:1.0-port0


Gruß
lewej

Mike73

Hallo Lewej,

es scheint, dass dieses Board zwar eine RS485-Schnittstelle besitzt, jedoch nicht Modbus "spricht" . Das Modbus-Modul wird dir also hier nicht weiterhelfen können.

Vielmehr sieht das nach einer sehr einfachen seriellen Befehlsübertragung aus.

LG
Mike


lewej

Hi,

laut Hersteller schon, oder interpretiere ich das falsch?


Communication Parameters:
8 Data, 1 Stop, No Parity
Baud rate : 9600

MODBUS Commands:
01 (0x01) Read Coils
05 (0x05) Write Single Coil

Coil 0000: Relay 01
Coil 0001: Relay 02
Coil 0002: Relay 03
Coil 0003: Relay 04
Coil 0004: Relay 05
Coil 0005: Relay 06
Coil 0006: Relay 07
Coil 0007: Relay 08



Zitat von: Mike73 am 22 Januar 2018, 21:40:31
Hallo Lewej,

es scheint, dass dieses Board zwar eine RS485-Schnittstelle besitzt, jedoch nicht Modbus "spricht" . Das Modbus-Modul wird dir also hier nicht weiterhelfen können.

Vielmehr sieht das nach einer sehr einfachen seriellen Befehlsübertragung aus.

LG
Mike

StefanStrobel

Hallo lewej,

die Befehle, die bei Dir über die Konsole funktionieren, sind keine Modbus-Frames.
Entweder muss erst noch von den einfachen seriellen Befehlen auf Modbus umgestellt werden
oder Dein Board verstehen zwei Protokolle gleichzeitig
oder Modbus geht gar nicht ...

Wenn Du es mit Modbus versuchen möchtest, dann müsstest Du die Modbus-Id des Boards kennen (oft einfach 1) und Du müsstest Die Coils mit obj-c001-... definieren.
Im Wiki, hier im Forum und der Commandref findest Du Beispiele.

Gruss
   Stefan

Mike73

es steht so da ... ja.


Da du das Modell nicht angegeben hast, habe ich nur mal auf die Schnelle bei KMtronic geschaut, der zum Beispiel https://www.kmtronic.com/RS485%20Relay%20Controllers?product_id=73 verwendet genau das von dir beschriebene Befehlsformat. RS485 ( physical serial Layer ) Ja, Modbus Nein.


StefanStrobel

Hallo Negropo,

Zitat
Kann man das noch optimieren, z.B. durch irgend eine Kombination von Befehlen?
Du kannst z.B. statt bei jedem Input-Register erneut den Unpack-Code und -poll anzugeben entsprechende Defaults für alle Input-Register setzen (dev-i...)
Zitat
Wie kann ich die readings RO1, RO2... etc. in FHEM auswerten/anzeigen lassen (als Antwort kommt vom Neuron eine 0 wenn das Reay ausgeschaltet ist und eine 1 wenn ein)
Diese Frage verstehe ich nicht. Die Readings werden doch in Fhemweb angezeigt sobald Werte erfolgreich gelesen wurden. Oder klappt das Lesen schon nicht?
Zitat
und die wichtigste Frage,
Wie sieht der Befehl (vermutlich ein SET) aus um das Relay zu schalten?
Auch der set-Befehl muss mit Attributen je Objekt aktiviert werden.
obj-xy-set 1
Im Wiki und der Commandref ist dafür sogar ein Beispiel.

Gruss
   Stefan


lewej

Zitat von: Mike73 am 22 Januar 2018, 22:07:12
es steht so da ... ja.


Da du das Modell nicht angegeben hast, habe ich nur mal auf die Schnelle bei KMtronic geschaut, der zum Beispiel https://www.kmtronic.com/RS485%20Relay%20Controllers?product_id=73 verwendet genau das von dir beschriebene Befehlsformat. RS485 ( physical serial Layer ) Ja, Modbus Nein.

Wie recht du hast :(.

Die haben das selbe Board noch mit Modbus:
https://sigma-shop.com/product/153/rs485-8-channel-relay-controller-modbus-rtu.html


lewej

Hallo Zusammen,

Ich hab eine Frage zur Reaktionszeit, wenn ich per Modbus eine Digital Input Board anschliesse, wie schnell reagiert fhem hier? Liegt man im millisekunden Bereich oder eher im Sekunden Bereich?

Gruss
Lewej