Raspberry Pi - mit GPIO Taster "drücken"

Begonnen von msa1989, 07 Januar 2015, 10:10:43

Vorheriges Thema - Nächstes Thema

msa1989

Hallo,

Ich habe eine technische Frage zu meiner Idee.
Ich möchte gerne mein Garagentor über FHEM steuern können. Meine Fernbedienung hat 2 Taster (auf/zu)
Jetzt habe ich Testweise einen GPIO in FHEM eingebunden und ein Skript geschrieben was diesen für ca. 1 Sekunde einschaltet. Das ganze hab ich mit einer LED veranschaulicht.
Jetzt möchte ich aber nicht die LED kurz einschalten, sondern den jeweiligen Knopf auf meiner Fernbedienung drücken.
Soweit ich das ganze Verstanden habe muss ich anstelle der LED einen Optokoppler setzen und den Ausgang des Kopplers mit dem Taster der Fernbedienung verbinden. Denke ich da richtig? (in der Fernbedienung sind 2 3,7v Knopfbatterien in Serie)
Möchte ungern meine Fernbedienung oder den Raspberry Pi kaputt machen.
Viele Grüße
Michi

klausw

Das ganze kann auch ohne Optokoppler funktionieren.
Als erstes müsstest du ausmessen, wie die Tasten angeschlossen sind (z.B. ein Kontakt am + pol der Batterie oder an Masse)
In diesen Fällen kann man einen kleinen Transistor über die Tasterkontakte löten. Dieser wird über einen Vorwiderstand direkt an den GPIO angeschlossen.
Ausserdem könntest du noch ausprobieren, ob deine Fernbedienung noch mit 5V läuft und die in diesem Fall übers Pi versorgen.
Wenn du alles sorgfältig ausmisst und danach Stück für Stück in Betrieb nimmst sollte auch nix kaputt gehen ;).
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

msa1989

Hallo Klaus,
vielen Dank für deine Erklärung. Werde nächste Woche zum Elektroladen kommen, dann kauf ich mal ein paar Transistoren und probiere alles aus.
Melde mich dann nochmal wenn ich Fortschritte gemacht hab.
Viele Grüße
Michi

MadAndy

Hallo Michi,

sollte es noch aktuell sein, hier noch ein anderer Lösungsweg.
Wenn es eine möglichkeit der Kabelverbindung zwischen Garagentorantrieb und Raspi gibt brauchst Du nicht an der FB zu basteln.
Die Antriebe haben in den meisten fällen einen Anschluß für einen Taster in der Garage bzw. einen Schlüsselschalter. Den kannst Du dann natürlich auch direkt ansteuern.

Gruß Andreas

P.S.
Was FHEM und den Raspi angeht bin ich absoluter Einsteiger, aber was Verkabelung betrifft, mach ich das schon eine ganze weile  ;)

Pfriemler

Hi - ich möchte das mal aufwärmen, weil ich eigentlich genau das auch möchte.
Derzeit nutze ich ein PiFace letztlich nur noch, um an einer präparierten Fernbedienung vier Leitungen per open-collector gegen GND zu ziehen und so Sendevorgänge auszulösen. Die Fernbedienung läuft auf 12V (ja, wirklich); der Transistor des PiFace muss also 12V "ertragen", aber letztlich nur 0,2 mA schalten (den Rest machen die nachgerüsteten Transistoren in der Fernbedienung).

Dafür das PiFace zu betreiben ist für mich totaler overkill.

Möchte vom Pi B auf den Pi 2 B umsteigen; den GPIO werde ich vermutlich nie benutzen. Das PiFace müsste ich eh irgendwie draufpflanzen, also doch lieber gleich weglassen.
Für GPIO gibt es ein FHEM-Modul, da arbeite ich mich rein.

Dennoch meine Fragen:
a) welche Pins wären am ehesten zu empfehlen (etwa weil sie mit keiner sonst irgendwie doppelbelegten Funktion wie RS-232, I2C etc kollidieren)
b) hat jemand eine ggf. grob verbal beschriebene Idee, wie man ein paar diskrete Bauteile für diesen Zweck an den GPIO anpappt - es gibt gefühlt "tausende" Seiten über Google was man alles tolles am RPi basteln kann, aber eine GANZ KONKRETE Schaltung ist fast Mangelware.
c) Bei allem wäre wichtig, dass diese Pins beim Booten des Pi oder bei einem FHEM-(Neu-)Start nicht "rumzucken", sondern wirklich erst wenn sie gebraucht werden. Das PiFace macht das ja vorbildlich.

So, bitte! Danke!
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

hexenmeister

Ich würde gar kein GPIO am Raspberry nehmen, sonder alles per USB anschliessen. Ist zukunftsicherer, da an praktisch jeder Hardware lauffähig.
Dafür kann man ein kleines Arduino (Pro Mini mit externem USB-Adapter oder Nano) nehmen und z.B. Firmata drauf flashen. Dafür gibt es bereits UNterstützung in FHEM. Geht auch per Ethernet statt USB.
Ich habe auf diese Art meine Türklingel eingebunden: http://s6z.de/cms/index.php/homeautomation/eigenbau/57-handy-meldung-beim-klingeln-an-der-tuer

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Rince

Oder du nimmst nen PanStamp...
Der kann dann mit fhem funken (wenn am fhem Rechner noch ein weiterer PanStamp hängt)
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

Pfriemler

Vielen Dank für beide Antworten - ich war nur etwas absorbiert die letzten Tage.
Beide Ideen sind natürlich prinzipiell richtig, aber faktisch reicht mir eine quick&dirty-Kabellösung tatsächlich. Man sollte noch wissen, dass die Fernbedienung im Bedarfsfall Panikalarm an der Alarmanlage auslösen soll und dabei möchte ich so wenig Komponenten wie möglich dazwischen haben, weil ich nicht absichern kann, dass HMLAN, Ethernet oder gar WiFi zu dem Zeitpunkt noch funktionieren. Umgekehrt telefoniert die Anlage (Auswertung der LEDs der Anlage mit Muster- und Blinkerkennung via Arduino und Senden mit HM-Mod-EM-8) schon mit FHEM; hier würde ich eher meine paar Zeilen noch in die FIRMATA quetschen und den Arduino per Ethernet anbinden.

Immerhin habe ich derweil schon rausbekommen, dass das RPI_GPIO kein Hexenwerk ist und die Ports ggf. 3,3V mit mehr als 1mA liefern können. Der Rest ist mir dann klar. Nur WELCHE GPIO-Pins ich nun nutze, muss sich noch zeigen.
Das Endergebnis werde ich dann zur Nachnutzung noch hier einstellen, immerhin ging es ja ursprünglich um den GPIO.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Pfriemler

#8
Nach kurzer Überlegung habe ich mich für die GPIO-Pins 9 (GND), 11,12,13 und 15 entschieden. Die dazugehörigen GPIO-Nummern (das sind die, die in der RPI_GPIO-Definition anzugeben sind) lauten 17,18,27 und 22 (in dieser Reihenfolge). Bilder mit Pinbelegungen gibt's zu Hauf im Internet.
Die verwendeten PINs kollidieren nicht mit Erweiterungen, die den SPI-Bus nutzen - so funktioniert ein PiFace parallel zu den GPIOs weiterhin einwandfrei.
Vier npn-Basteltransistoren aus meiner Grabbelkiste erledigen nun die Ansteuerung. Sie bekommen den Basisstrom über 820 Ohm und eine rote Kleinst-LED (als Funktionsanzeige) direkt von den GPIOs des Raspberry.
Ich habe mich streng an die Definition in der commandref gehalten (die allerdings ein paar Schreibfehler hat, die muss ich noch melden).

define AlarmanlageFB_Aus RPI_GPIO 17         # Bezeichnung und Nummer jeweils anpassen
attr AlarmanlageFB_Aus direction output      # Pin als Ausgang setzen
attr AlarmanlageFB_Aus restoreOnStartup off  # definierter Zustand beim (Neu-)Start immer ,,aus"
attr AlarmanlageFB_Aus room Beispielraum     # :-)

Und läuft völlig zufriedenstellend. Sowohl bis gestern auf dem Pi B, als auch auf dem gerade in Betrieb genommenen Pi 2.

Übrigens: Kopieren der Definition und Anpassung auf weitere Pins geht nicht - eine Neudefinition wird verhindert, wenn der GPIO-Pin bereits belegt ist ...
Jetzt hätte ich ein PiFace Digital abzugeben ...

Je nach Fernbedienung oder Gerät (insbesondere wenn sie nicht mit Matrixabfrage arbeitet, sondern wie bei mir "handbacken" mit je einer Leitung zum Chip) sollte auch eine kleine Optokopplerbatterie funktionieren. Die Umrüstung meiner Rolladenantriebe bspw. habe ich durch Parallelschalten von Optokopplern zu den Tasten sehr einfach gelöst.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Stafan-21

Hallo,
ich möchte so ein ähnliches Projekt realisieren. Allerdings muss ich nicht nur auf ab steuern. sondern muss vorher ein Rollo auswählen. Ich bin mir aber nicht sicher wie ich das Script schreiben muss. Würdest Du mir einmal Dein Script zeigen? Wo muss das liegen und wie rufe ich das auf?

Vielen Dank

Pfriemler

Zitat von: Stafan-21 am 21 Februar 2015, 18:47:16
... muss ich nicht nur auf ab steuern. sondern muss vorher ein Rollo auswählen. Ich bin mir aber nicht sicher wie ich das Script schreiben muss. Würdest Du mir einmal Dein Script zeigen?
Ich verwende kein Skript. Ich verwende ein Dummyvariable, die ich setze, und ein DOIF, welches den Zustand der Dummyvariable "abarbeitet". Dieses Konstrukt habe ich bei mehreren Geräten gewählt, es ist übersichtlich und dennoch komfortabel, weil es Befehl und Ausführung schön trennt (ähnlich wie ein Modul).

set RolloXY dummy
set RolloXY_up RPI_GPIO 17
set RolloXY_down RPI_GPIO 18
attr RolloXY_.* direction output

set di_RolloXY_control DOIF
([RolloXY] eq "Oeffnen")
  (set RolloXY_up on, sleep 1, set RolloXY_up off, set RolloXY auf)
DOELSEIF ([RolloXY] eq "Schliessen")
  (set RolloXY_down on, sleep 1, set RolloXY_down off, set RolloXY zu)

attr di_RolloXY_control do always


Das ist eine Minimalvariante. Für jedes Rollo brauchst Du diesen Satz einmal. Die Zahl der GPIOs ist ja begrenzt, also kommst Du wohl auf maximal 8-10 solcher Sätze. Klar wäre ein Skript eleganter. Ich steuere nur drei Rollos im Haus, und das auch noch jeweils auf unterschiedliche Weise (weil sie alle anders angesteuert werden müssen).

Wird die Variable RolloXY auf "Oeffnen" oder "Schliessen" gesetzt (im Rahmen einer Zeitsteuerung oder Zustandsreaktion oder auch einfach als Notify auf einen Tastendruck), reagiert das DOIF mit entsprechenden Befehlen an die GPIOs und setzt den Zustand des Dummys als "Ausführungsquittung" auf "auf" bzw. "zu". Das hat eigentlich eher nur einen kosmetischen Effekt.

Je nach Rollo ist es möglich, eine eindeutige Stopp-Sequenz festzulegen, bei einem älteren Rademacher reicht dazu ein Viertelsekunden-Knopfdruck, bei meinem neueren schalte ich per Funkbefehl sowieso die Fahrten direkt ein (Schaltermodus). So könnte das DOIF dann zusätzlich auf "Stoppen" reagieren - und vor allem vor jeder Bewegung selbst eine Stopp-Sequenz senden, damit ein evtl. gerade fahrendes Rollo auch wirklich definiert in die Richtung fährt in die es soll (und nicht etwa nur anhält). Das richtet sich aber wirklich nach dem Verhalten der Rollos selbst.

Wenn Du selbst die "Schaltervariante" wählst (also das Rollo entsprechend lange "einschaltest" und nicht nur einen "Tastendruck" sendest, wäre ein langes "sleep" eher ungünstig. Dann lieber im DOIF ein temporäres "at" definieren. Das zu erklären führt mir gerade zu weit ...




"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."