Input via gpio

Begonnen von fhemN00b, 28 Dezember 2020, 12:00:10

Vorheriges Thema - Nächstes Thema

fhemN00b

Moin,
spricht etwas dagegen die GPIO pins des raspberry pis als input für meine Heimautomatisierung zu nutzen? Der Raspi wäre dann in der Verteilung und wird dann mit den Kabeln die zu den Schaltern/Tastern in den Räumen führen verbunden.
Spannungsabfall sollte passen, muss aber noch ausgetestet werden.

Ist das so machbar, oder gibt es potentielle gefahren die ich übersehe?

Danke schonmal

Frank_Huber

Ich mache das so.
4 Etagen, 4 Raspberry.

Ich würde aber empfehlen gegen 0V zu schalten.

fhemN00b

Ok, das ist gut zu wissen, dass jemand das bereits in der Praxis nutzt.
Genau gegen 0V war auch mein Plan.

Vielen Dank für die schnelle Antwort!

Beta-User

Bist dann halt auf eine bestimmte Hardware abonniert und vermengst Logik (FHEM) mit Hardware. Kann "Spass" machen bei updates (hell, Frank ;) ). Würde überlegen,  ob nicht eine MCU zwischen FHEM und den GPIO sinnvoller ist (Arduino via USB, z.B.).
Just my2ct...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Frank_Huber

Gutes Gedächtnis Beta-User, 😂😂😂

In der Tat. Das war mit Jessie noch. Da hat ein Kernel Update das Gpio Modul aus dem Tritt gebracht.
Ich hatte das OS Update natürlich aus der Ferne durchgeführt...
Seither habe ich einen Test PI. Erst wenn ein Update (OS und FHEM) dort fehlerfrei durch ist bekommen das die Produktiven.
Und keine Feen Updates mehr produktiv.

Aber letzenendes würde ich es wieder so aufsetzen.
Gpio des PI als Input, die Relais an mcp23017 Erweiterungen.

fhemN00b

Moin,
sicherlich ein berechtigter Hinweis. Mein Plan sieht allerdings sowieso zwei Pi's vor. Auf einem läuft fhem, auf dem anderen werden die GPIOs genutzt. Das ist dann auch mein Ausfall Schutz (wenn der erste abraucht, übernimmt der zweite).

Beta-User

#6
Na ja, nur um ein paar GPIO's anzusteuern, kommt mir ein Pi "oversized" vor, zumal man da m.E. zwingend dafür sorgen muss, dass das OS sicher bleibt. So war es jedenfalls von meiner Seite nicht gemeint gewesen mit der MCU; ein Pi ist jedenfalls für mich (EDIT:) keine MCU....
Bei einer MCU nach meinem Verständnis (wie einem Arduino Nano oder Mega - falls mehr GPIO benötigt werden) ist das sehr viel einfacher, und die Dinger sind so günstig, dass man auch einen fertig programmierten "in die Ersatzteilbox" packen kann, um "plug&play" zu wechseln; dafür ist der erstmalige Einarbeitungsaufwand ggf. etwas höher.

Bei einem Pi gibt es an GPIO auch noch das Thema mit Latenzen - ich kenne das nicht aus eigener Anschauung, aber wie Frank_Huber richtig bemerkt hat, kann ich mir manche Sachen gut merken ::) , und dazu gehört auch ein Hinweis in diese Richtung von @pah, von dem ich aber weder weiß, wie der Kontext war, noch, ob das Thema noch aktuell ist (es bezog sich allerdings auf die Plattformen bis vor etwa 2 Jahren).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

fhemN00b

Um nur die ports auszulesen, ist ein raspi sicherlich über dimensioniert. Jedoch sollte der Fhem Pi ausfallen, dann brauch ich im Zweifel nicht mehr machen als ein Usb Kabel umzustecken (vielleicht noch nichtmal das). Andersherum ist es auch nicht viel mehr. Somit immer ne schnelle Notfall Lösung, für 20 Euro mehr (oder so).

Ich werde mir die arduino Möglichkeit trotzdem nochmal anschauen. Kann ich den ohne weiteres Daten vom Arduino mit dem vorhandenen Usb port (der ja normalerweise zum übermitteln von Programmen genutzt wird) mit dem Gegenstück austauschen?

Beta-User

Das mit dem "hotswap" von zwei PI's kannst du ja gerne mal praktisch austesten (v.a., wenn die unterschiedliche Aufgaben ahebn ;) ), es macht auf alle Fälle Sinn, sowohl eine "direkt einsatzbereite" SD-Karte bereitzuhalten wie auch einen anderen Server (ich habe ein x86-System und für Notfälle einen Pi irgendwo im Keller...).

Die USB-Schnittstelle kann auch zum Austausch von laufenden Daten genutzt werden, Beispiele gibt es zuhauf - angefangen bei CUL-Geräten.
Meine persönliche Lieblingslösung ist MySensors (mehr "Intelligenz" auf der MCU), aber wenn es nur darum geht, inputs auszulesen, ist vermutlich Firmata auch einen Blick wert (da muss man aber bei Ausgängen aufpassen, vergleichsweise "dumme" Nutzung der MCU) oder was Selbstgestricktes mit keyValueProtocol (das ist im Prinzip unter "Jeelink" zu finden). In der Regel wird dabei der Arduino als Interface definiert, und - je nach Lösung - dann entweder der einzelne GPIO als separates Device (Jeelink?) oder als Reading eines Client-Gerätes (MySensors u.A.) in FHEM integriert.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

fhemN00b

Okay cool, dann habe ich ja schonmal ein paar Infos um mich schlauer machen zu können. Denke ich werde mir dann am ehesten selbst was zurecht basteln.

Erstmal werde ich jedoch wohl mit der schnellsten Lösung fortfahren, sprich Raspi GPIOs. Da wir neu bauen gibt es derzeit noch einige andere Baustellen die meine Zeit erfordern  ;)
Später kann man dann ja nochmal erweitern und austauschen.

Danke auf jedenfalls für die Anregungen