Daten über RS485 auf Anfrage empfangen

  • Hallo zusammen,

    ich möchte mit meinem Raspberry Pi mit Hilfe von Python folgendes realisieren:

    In meinem Haus befinden sich 10 Raumthermostate die per RS485 miteinander verbunden sind. Der Master, ein Raspberry Pi B+ mit Raspbian OS, soll die einzelnen Slaves ( Raumthermostate ) der Reihe nach abfragen. Die Slaves reagieren auf folgenden String der über RS485 geschickt wird:

    ST,01,GV,SP

    ST=Start
    01 = Slave Adresse ( geht von 01 bis 10 )
    GV = Get Value
    SP = Stop

    Jeder Slave empfängt das Telegramm und schaut ob die Slave Adresse seine eigene ist. Wenn dem so ist, schickt er den Temperatur Wert zurück zum Master. Das funktioniert auch prima mit einem Windows PC + Terminalprogramm + RS485 USB Wandler. Jetzt versuche ich seit ein paar Tagen das ganze über den Raspberry Pi laufen zu lassen. Folgendes Script habe ich versucht mit Anfängerkenntnissen zu programmieren:

    Am GPIO 22 hängt der Direction Pin für die Umschaltung Sende / Empfange des RS485 Bausteins. Zum Senden muss dieser auf High sein, zum empfangen auf Low. Ich bekomme mit dem Script allerdings keine Ausgabe. Das einzige was erscheint ist die Ausgabe "successful". Danach tut sich nichts mehr. Die Anfrage wird aber zum Slave geschickt und dieser schickt auch was zurück. Allerdings kommt am Raspberry scheinbar nichts an.

    Ist meine Abfrage auf x=ser.readline überhaupt korrekt ?

    Danke im Voraus
    Gruß Kay Pohl

  • Hallo Kayle,

    herzlich Willkommen in unserem Forum!


    Mir fallen spontan folgende Ursachen ein:

    1. Freigabe der seriellen Schnittstelle
    Wie hast Du die serielle Schniottstelle konfiguriert? Kannst Du mal die beiden Dateien posten?

    Code
    /boot/cmdline.txt


    und

    Code
    /etc/inittab

    2. Unterschiedliche Spannungspegel
    Weißt Du, welchen Spannungspegel die Thermostate für HIGH erzeugen? Wenn dies oberhalb 3,3V sein sollte, dann musst Du die Spannung durch einen Spannungsteiler / Pegelwandler auf max. 3,3 V verringern (Schaltung besteht aus zwei Widerständen).

    Weißt Du, welchen Spannungspegel die Thermostate für einen HIGH-Pegel erwarten? Wenn dies weniger als 3,3 V sind, dann musst Du die Spannungspegel des RPi entsprechend verstärken (Schaltung besteht aus 2x BC547 B und drei Widerständen).

    3. Keine Synchronisierung der seriellen Parameter
    Bist Du Dir sicher, dass Startbit, Anzahl der Stop-Bits, Parität auf Seite der Thermostate und beim RPi übereinstimmen?
    Hast Du mal ein einen sog. seriellen Monitor (z.B. CuteCom) eingesetzt, um dort die Parameter auszuprobieren? Wenn Dir hiermit keine Kommunikation gelingt, dann klappt das mit der selbstgestrickten Software auch nicht.

    4. Fehlerhafte Verbindung
    RXD (Pin P1-10, GPIO15) muss mit TXD der Thermostate verbunden sein (nachdem das mit den Pegeln geklärt ist).
    TXD (Pin P1-8, GPIO14) des RPi muss mit RXD der Thermostate verbunden sein (dito).

    Wozu nutzt Du den GPIO22 (Pin P1-15)? Für die serielle Übertragung reichen RXD/TXD-Verbindungen vollkommen aus. Wenn die Protokolle zur Kommunikation mit den Thermostaten Handshakes benötigen, dann werden hierfür üblicherweise die GPIO17 (Pin P1-11) für RTS (Request to Send) und GPIO16 (Pin P1-36) für CTS (Clear to Send) verwendet. Beide stehen jeweils erst nach Aktivierung der alternativen Funktion 3 zur Verfügung.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (24. September 2015 um 15:50)

  • http://www.ebay.de/itm/USB-RS485-…=item19eb94d006

    Diese Sticks setzte ich am Pi für RS485 ein, gibt's beim Aliexpress/Banggood/sonstiger Chinamann noch deutlich günstiger. Funktionieren soweit einwandfrei, ich bin aber ja auch derjenige der die Botschaft selber aufgebaut hat somit auch weiß wie diese aufgebaut ist.
    Für dich wäre es dann sinnvoll einen solchen Stick zu besorgen, die Datenleitungen für RS485 da anzupinnen und mit Cutecom oder sonstigem einfach mal zuhören. Da kannst du dann auch die verschiedenen Bauds, Paritys oder Stopbits testen. Grundsätzlich kann man sagen, wenn du bei Cutecom keine Nachricht bekommst, kannst du auch mit nichts anderem eine bekommen ;)
    Wenn ich das richtig im Kopf geschieht das umschalten zwischen Read/Write hier nur Softwareseitig, zumindest ist es in meinem Projekt so umgesetzt. (Weiß nicht ob es da auch andere RS485 Module gibt wo das Hardwareseitig passieren muss)

  • Guten Morgen zusammen,

    vielen Dank für Eure Antworten.

    @Andreas+ Raspiprojekt: Ich habe vergessen zu schreiben das nach dem RX / TX vom Raspi noch ein RS485 Controller MAX485 verbaut ist. Dieser benötigt zur Richtungsumschaltung ein Signal. Das wird vom Raspi an Pin 22 ausgegeben.

    JumpY: Solch einen Converter habe ich. Mit dem kann ich allerdings nur empfangen, senden geht nicht. Das Teil ist wohl defekt. Deswegen habe ich dann den MAX485 an der seriellen Schnittstelle direkt angeschlossen.

    Gruß Kay


  • @Andreas+ Raspiprojekt: Ich habe vergessen zu schreiben das nach dem RX / TX vom Raspi noch ein RS485 Controller MAX485 verbaut ist. Dieser benötigt zur Richtungsumschaltung ein Signal. Das wird vom Raspi an Pin 22 ausgegeben.

    Solche wichtigen Informationen sollte man unbedingt mitliefern, weil sonst jede Antwort ins Leere läuft. Da muss ich dann jetzt nochmal drauf rumdenken.

  • Solche wichtigen Informationen sollte man unbedingt mitliefern, weil sonst jede Antwort ins Leere läuft. Da muss ich dann jetzt nochmal drauf rumdenken.

    Wenn ich meinen ersten Beitrag nochmal lese dann habe ich nicht vergessen das zu schreiben:

    "Am GPIO 22 hängt der Direction Pin für die Umschaltung Sende / Empfange des RS485 Bausteins."

    Also die Information war schon da ;)


    Gruß Kay

  • Jetzt nicht wegen solchen Kleinigkeiten streiten, jetzt ist's ja klargestellt.
    Ich durchforste gleich meine Codes nochmal, vielleicht kann ich was passendes dazu finden. Die Sticks funktionieren definitiv in beide Richtungen, bei mir läuft das Prinzip so ab:
    - Raspberry reagiert auf einen GPIO von Außerhalb
    - Raspberry sendet per RS485 eine Aufforderung für eine bestimmte Nachricht
    - Slave sendet Nachricht an Raspberry
    - Raspberry prüft die Nachricht und gibt Antwort
    - Slave bestätigt Antwort

    Also funktioniert es definitiv in 2 Richtungen. Falls du noch so einen Stick brauchst, zufällig ist heute eine Lieferung aus China angekommen wo welche bei sind. (Falls du Lieferzeit sparen willst)
    Was für Sticks genau hast du? Kannst du mal einen Auszug aus dem Pi geben welcher Chipsatz das ist? PLXXXX oder sowas ist das glaube ich? Die "neuen" die ich bekommen habe, haben eine schwarze Platine die man an den Schraubanschlüssen sieht, die alten eine grüne. Die alten funktionieren aufjedenfall, die neuen noch ungetestet.

  • Das es in 2 Richtungen funktioniert bestreite ich nicht. Nur halt nicht mit meinem Stick :) Der Stick hat einen HL3040 chip und ist ein neuer mit schwarzer Platine. Genau wie Du das gemacht hast soll es bei mir auch funktionieren. Ich schicke dem Slave die Aufforderung die Temperatur zu übermitteln und dieser schickt dann die Temperatur. Eigentlich ganz simple, wenn es denn funktionieren würde. Da sind noch einige Nachtschichten Python verstehen angesagt :D

    Gruß Kay

  • So, ich habe mir das jetzt nicht nochmal genauer angesehen, ehrlich gesagt bin ich auch relativ eingespannt und verstehe von Python so gut wie nichts. (Gestern habe ich mein 1. Programm damit geschrieben)
    Ich nutze die Kommunikation zwar auf dem Raspberry, allerdings in C. Das hätte ich aber auch niemals hinbekommen, da habe ich Tagelang (oder Wochen..) mit dreamshader gesprochen und er hat mir das mehr oder weniger vorgebetet. Ob er das auch in Python kann weiß ich nicht, vielleicht findet er den Thread aber ja mehr oder weniger zufällig *hust*

    Aber grundsätzlich ist RS485 ja nur eine serielle Schnittstelle, die auf bestimmte Art interpretiert wird und vom Aufbau her genormt ist. Wie die Datenpakete aber aufgebaut sind und wie der Bus aktiviert und empfangen wird hängt ja von der Software ab. Wenn ich das richtig im Kopf habe, musst du dich also für ein Kommunikationsprotokoll entscheiden und dieses strikt befolgen, damit sich überhaupt etwas tut. Ich nutze in meinem Projekt "Modbus", darin ist genau beschrieben wie die Kommunikation softwareseitig abzulaufen hat und wie eine Nachricht aufgebaut wird.

    Du müsstest dir also ein geeignetes Protokoll aussuchen (oder eines selber erstellen, welches ich dir nicht wirklich empfehlen würde) und dich da einlesen.

    ---------------------------------------------- Ab hier erst richtig.. Das obere bleibt aber stehen, falls du damit nochwas anfangen kannst. ----------------------------------------------
    Verdammt, vergiss das alles was ich geschrieben habe, ich glaube ich hab einen enormen Denkfehler. Du hast ein fertiges System mit Temperatursensoren, die über RS485 kommunizieren können, richtig? Ich habe das nochmal nachgelesen in deinem Startpost, per Windows PC funktioniert das ja scheinbar. Kannst du mal genau beschreiben, was du da nutzt und was du sendest? Du musst an dem Rechner ja auch ein bestimmtes Protokoll einhalten. Am besten wäre es sogar, wenn du die genauen Bauteilbezeichnungen lieferst, was für Sensoren das sind.

    Wenn ich mich nicht komplett Irre, sollte folgende Konstellation funktionieren:
    Du klemmst deinen Pi mit in den Bus und öffnest ein Terminalprogramm. (Minicom oder sowas) Ebenfalls hängt dein Windowsrechner im Bus und sendet die Anforderung an die Thermostate und das Thermostat antwortet dem PC. Normalerweise müsstest du den ganzen Bus mitlesen können, da der Bus ja offen für alle ist und jeder Slave/Master alles ließt, unabhängig davon ob er adressiert wurde. Normalerweise verwirft dieser dann einfach die Information wenn die nicht für ihn gedacht war und falls doch, agiert er in irgend einer Form.
    Damit müsstest du normalerweise die genaue Botschaft die vom PC kommt empfangen und ebenfalls die, die der Sensor sendet. Vielleicht ist da ja der Fehler, dass du von einer "falschen" Nachricht ausgehst, bzw. der PC deine Nachricht anders sendet, weil er das Paket nach einem Protokoll aufbaut welches der Pi (noch nicht) kennt.

    Versuche mal ob du da irgendwas bekommst und nenne mir bitte noch die genauen Typen der Thermostate, vielleicht kann ich dazu etwas finden. (Falls du selber schon was gefunden hast, muss man unbedingt wissen welches Protokoll das System nutzt & hoffen, dass jemand dazu eine Pythonlibrary gebaut hat und diese irgendwo zu finden ist)

    EDIT: Die Botschaft müsste übrigens in HEX übertragen werden, oder ich Irre mich sehr stark. Also in der Regel müsstest du HEX-Werte empfangen, natürlich vorrausgesetzt du bist in der gleichen BAUD und Parity.
    EDIT2: Ebenfalls muss man klären, ob es sich um 2-Draht oder 4-Draht Bus handelt. Bei einem 2-Draht Bus kann nur in eine Richtung gesendet werden, also Senden -> Warten -> Empfangen, bei 4-Draht geht das zeitgleich. (Da muss natürlich entsprechende Hardware verwendet werden) Mitlesen sollte aber auch beiden Varianten möglich sein. (Eigentlich einfach mit reinhängen in den Bus, Terminal auf die entsprechende Schnittstelle einstellen und mithorchen)


  • ... dreamshader gesprochen und er hat mir das mehr oder weniger vorgebetet. Ob er das auch in Python kann weiß ich nicht, vielleicht findet er den Thread aber ja mehr oder weniger zufällig *hust*
    ...


    :lol: ... Schlangenkot - äh code ist nicht meins :)


    Probier das doch mal mit minicom aus ... ich glaube allerdings auch nicht, dass Dich da das Modbus-Protokoll weiterbringt.
    Ich denke, dass ein simples "st,1,GV,SP" da nicht klappt ...
    Das wird wohl eher eine Bytefolge sein, die quasi ein eigenes Protokoll darstellt.
    Hast Du dazu nicht mehr Infos .. oder hab ich das überlesen ?

    //EDIT: ach ja ... vergessen ... den RS485-Adapter brauchst Du imho schon, wegen der Signale, die anders daherkommen, wie auf einer "normalen" seriellen Schnittstelle. Das Handling ist aber davon unabhängig ... d.h. die RS485 verhält sich aus Deiner Sicht wie eine serielle Verbindung.


    cu,
    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!