RS485 an USB?

[Cannon]

Es kommen immer mehr Geräte mit dem RS485-Bus auf den Markt. Sei es nun das Thema Photovoltaik oder z.B. der Bodenfeuchte-Sensor SMT-100 von Truebner. Meine Frage ist allerdings, ob es da schon ein Plugin für den RS485-Bus gibt und inwiefern die USB-Adapter am Raspberry unterstützt werden. So richtig gefunden habe ich nichts. Kann mir aber auch nicht vorstellen, dass es dafür nichts gibt.

[Bonze]

Naja rs485 is ja nur ein standart der signalpegel..
usb adapter gibt es dafür , die funktionieren ähnlich wie die rs232 adapter..

[android]

RS485 ist nur die physiklische Übertragung, es kommt auf das Protokoll an. Es gibt hier schon einige plugins für rs485 Geräte mit eigenem proprietärem protokoll (yamaha, trovis heizungsregler usw.) und für dmx. Glaube für can und modbus rtu gibt es noch nichts. Ich habe einen danfoss wr den ich über can über ein plugin abfragen kann. da kannst du dann immer einen rs485 usb-adapter nehmen.

Für den Bodenfeuchte Sensor z.b. als modbus-variante wird es noch kein Plugin geben, sollte aber auch machbar sein. Im einfachsten Fall für einen Anfänger über eine logik. Ich würde den aber als 4-20mA nehmen und über einen knx analogaktor anschließen.


https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/15652-bodenfeuchte-sensor-f%C3%BCr-gartenbew%C3%A4sserung/page8

[Cannon]

RS485 ist nur die physiklische Übertragung, es kommt auf das Protokoll an. Es gibt hier schon einige plugins für rs485 Geräte mit eigenem proprietärem protokoll (yamaha, trovis heizungsregler usw.) und für dmx. Glaube für can und modbus rtu gibt es noch nichts. Ich habe einen danfoss wr den ich über can über ein plugin abfragen kann. da kannst du dann immer einen rs485 usb-adapter nehmen.

Achso .. deshalb die unterschiedlichen Protokolle. Verstehe. Ja Modbus ist der Feuchtesensor.

Ich würde den aber als 4-20mA nehmen und über einen knx analogaktor anschließen

Ich habe ja schon den SMT-50 mit 0-10V. So richtig gefällt mir das aber nicht. Zum einen brauche ich jedes Mal 2 Kanäle (Feuchte und Temperatur) und zum anderen ist das ziemlich viel Kabel. Und die Pegel sind bei dem SMT-50 schon sehr niedrig. So ein Bus hätte da schon Vorteile.

Der Thread ist super. Danke.

[Tom Bombadil]

Das Helios Plugin flanscht über RS485 eine pre-2014 Helios KWL an (damals wurde das Modbus-Protokoll noch von Hand implementiert).
Das bereits genannte Trovis Plugin kommuniziert mit einem Trovis Heizungsregler über RS232, nutzt dafür aber eine Bibliothek (pyModbus).

Beide nach Herstellerangaben "unsmarten" Geräte hängen bei mir per Seriell-LAN-Adapter im Netz und kommunizieren mit shNG. Die jeweils verwendeten Adapter und notwendigen Befehle sind in den verlinkten Projektwiki's zu finden.

Wie schon geschrieben wurde - im Grunde egal, ob RS232 oder RS485, da beides seriell und nur für technisch unterschiedliche Anwendungsfälle ausgelegt ist. Wenn das Gerät Modbus spricht, kann man es anprogrammieren, sobald für die verwendete Schnittstelle ein LAN- oder USB-Adapter zur Verfügung steht - egal ob 232, 485, was-auch-immer.

Rest siehe verlinkte Wiki's sowie zugehörige Threads hier im Forum (auch in den Wiki's verlinkt - z.B. für Troubleshooting bei USB-Adaptern siehe Helios-Thread).

Hoffe, das hilft Dir weiter,

/tom

Edit/Nachtrag: Es gibt glaube mittlerweile auch ein 'universelles Modbus-Plugin' für shNG. Kenne aber dazu keine Details und auch den aktuellen Stand nicht.

[Cannon]

Das Helios Plugin flanscht über RS485 eine pre-2014 Helios KWL an (damals wurde das Modbus-Protokoll noch von Hand implementiert).
Das bereits genannte Trovis Plugin kommuniziert mit einem Trovis Heizungsregler über RS232, nutzt dafür aber eine Bibliothek (pyModbus).

Gut, dass ich noch nichts gekauft habe. Ich war gedanklich schon dabei den SMT-100 mit RS485 und Modbus zu nehmen und das ganze per USB-Stick an den Raspberry zu bringen. Wenn das aber auch über Netzwerk geht, ist das ja noch viel flexibler.

Passend wäre dann wohl der USR-TCP232-304. Da sind dann auch gleich die richtigen Anschlüsse dran. Oder noch besser für die Hutschiene der USR-DR302.

Aber wenn ich das richtig verstanden habe, kann ich den dann ganz normal ansteuern, als wenn das ein Modbus-Netzwerkgerät wäre? Also mit ModbusTcpClient usw.

[Tom Bombadil]

Du solltest Dir einen virtuellen Port auf der shNG-Büchse definieren, über den die Kommunikation läuft. Ich nutze dafür immer socat. Ist hier beschrieben, wie man das einrichtet. Statt z.B. über /dev/ttyUSB0 kommunizierst Du dann über die Schnittstelle /dev/mein-eigener-socat-name (bei mir z.B. /dev/helios, /dev/trovis). IP und Port müssen natürlich stimmen, erst später werden dann im Software-Client wie z.B. dem shNG-Plugin auch Baudrate, Parität, Stopbits eingestellt (z.B. 8N1).

Ob da grundsätzlich was am Busch funkt (Modbus-seitig), lässt sich mit Vcom unter Windows gut sniffen. Das richtet unter Windows einen virtuellen COM-Port COMx: ein, arbeitet also ähnlich wie oben beschrieben. Da sieht man dann auch, ob einigermaßen sinnvolle ("strukturierte") Pakete ausgetauscht werden. Ist ebenfalls im Wiki beschrieben.

/tom

[Cannon]

Du solltest Dir einen virtuellen Port auf der shNG-Büchse definieren, über den die Kommunikation läuft. Ich nutze dafür immer socat. Ist hier beschrieben, wie man das einrichtet. Statt z.B. über /dev/ttyUSB0 kommunizierst Du dann über die Schnittstelle /dev/mein-eigener-socat-name (bei mir z.B. /dev/helios, /dev/trovis). IP und Port müssen natürlich stimmen, später dann im eigenen Software-Client auch Baudrate, Parität, Stopbits (z.B. 8N1).

Irgendwie habe ich da ein Verständnisproblem. Wieso stelle ich bei dem USR-Gerät nicht alles ein und kann dann per IP-Adresse mit dem pyModbus einfach darauf zugreifen? Stelle ich mir das zu einfach vor?

[Tom Bombadil]

Wieso stelle ich bei dem USR-Gerät nicht alles ein und kann dann per IP-Adresse mit dem pyModbus einfach darauf zugreifen?

Auf dem USR stellst Du IP und Port ein. Diese sprichst Du über die virtuelle Schnittstelle gezielt an und baust damit eine dauerhafte Verbindung auf. Das USR fungiert von nun an quasi als "verlängerte Schnittstelle" zum seriellen Bus (also: LAN-Traffic <----> Bus-Traffic). Was da kommuniziert wird und wie schnell, ist dem USR erstmal egal.

Das ganze ist vielleicht vergleichbar mit 2 weit entfernt befindlichen Menschen mit Telefonen in der Hand - beim Aufbau der Verbindung Endpoint-Endpoint ist den Telefonen erstmal egal, ob die beiden Menschen die gleiche Sprache sprechen können. Es geht erstmal nur um einen Verbindungsaufbau.

Jetzt kommt die Client-App in's Spiel (z.B. shNG-Plugin). Diese 'spricht' Modbus, und Dein Endgerät auch. Richtige Einstellungen (Geschwindigkeit, Parität usw) vorausgesetzt, können nun Client-App und Gerät über die stehende Verbindung miteinander plaudern.

Oder um bei Telefonbeispiel oben zu bleiben: Beide Menschen sprechen dieselbe Sprache, und es ist ihnen egal, wie oft das Signal über LTE, Kupfer, Glasfaser usw transformiert wird, um auf die andere Seite zu kommen.

Hoffe, das hilft zum Verständnis ...

/tom

[Cannon]

Hoffe, das hilft zum Verständnis ...

Danke! :-) Das Grundprinzip ist mir ja klar. Aber ich verstehe den Teil mit dem virtuellen Port nicht. Denn für mein Verständnis stellt doch der USR das Netzwerkprotokoll zur Verfügung und in den TCP-Paketen versende ich dann meine Modbus-Daten, die dann an die RS485 gesendet werden. Also eigentlich stellt sich die Frage, wieso meine Lüftungsanlage mit Modbus TCP-Port anders behandelt werden sollte, als der Modbus TCP-Port des USR mit einer RS485- Schnittstelle?

[Tom Bombadil]

Unter Unix/Linux kommuniziert man halt über Geräte, die unter /dev liegen. Das ist eines der Grundprinzipien des Betriebssystems. Ich finde die Kommunikation über eine dedizierte Schnittstelle transparent und logisch. Mit 'direkter' Kommunikation über IP's oder per /dev/LAN1 usw hab ich mich nie beschäftigt - keine Ahnung, ob man da vielleicht noch einen extra Protokollstack programmieren muss etc. Fazit: Gute Idee - könnte gehen, muss aber nicht. Einfach ausprobieren ...

/tom

[Cannon]

Mit 'direkter' Kommunikation über IP's oder per /dev/LAN1 usw hab ich mich nie beschäftigt - keine Ahnung, ob man da vielleicht noch einen extra Protokollstack programmieren muss etc. Fazit: Gute Idee - könnte gehen, muss aber nicht. Einfach ausprobieren ...

Danke für die Tipps. Ich werde das mal probieren, indem ich das direkt über pyModbus mache und wenn das nicht geht über deinen Weg. Vielleicht habe ich da auch nur einen Denkfehler.

[Tom Bombadil]

Nachtrag: Ging mir nicht aus dem Kopf, nach dem Motto 'da war doch mal was'. Hier hat mal jemand mein Trovis-Plugin so umgebaut, dass es ohne socat per direct IP läuft. Deine Idee sollte also funktionieren, und Aufwand ist es auch keiner. Ich denke vermutlich einfach nur (auch aus beruflichen Gründen) zu sehr in Schichtenmodellen ...

/tom

[Cannon]

Nachtrag: Ging mir nicht aus dem Kopf, nach dem Motto 'da war doch mal was'. Hier hat mal jemand mein Trovis-Plugin so umgebaut, dass es ohne socat per direct IP läuft. Deine Idee sollte also funktionieren, und Aufwand ist es auch keiner. Ich denke vermutlich einfach nur (auch aus beruflichen Gründen) zu sehr in Schichtenmodellen ...

Genau das war mein Plan. Wenn man jede IP-Adresse als eigenes Gerät einrichtet, wird man ja irre.

[Tom Bombadil]

Gutes Gelingen!

/tom



Nachtrag: Hier noch eine gute Seite über Modbus. Die Links unten sind Gold wert, wenn man Modbus grundsätzlich verstehen und tiefer einsteigen will - besonders der erste Link mit der Übersicht über die verschiedenen read/write-Befehle usw.