Betreibt man ioBroker auf einem Raspberry Pi, dann möchte man sicherlich auch die GPIOs nutzen.
Dieser Beitrag beschreibt die Installation und Einrichtung des RPI-Monitor Adapters, welcher den Zugriff auf einzelne (oder alle) GPIOs des Raspberry Pi ermöglicht.
Installation des RPI-Monitor Adapters
Die Installation des Adapters RPI-Monitor erfolgt wie gewohnt über die Administrationsoberfläche von ioBroker.
Nach der Installation öffnet sich die Adapterkonfiguration, in der wir die gewünschten Funktionen einzeln aktivieren und deaktivieren können.
Hinweis: Einige der angebotenen Funktionen sind inzwischen bereits im standardmäßig installierten Info-Adapter enthalten und können somit deaktiviert werden. Wer nur die GPIOs verwenden möchte, der kann getrost alle anderen Funktionen deaktivieren.
GPIOs
Für die Verwaltung der GPIOs gibt es in der Adapterkonfiguration einen extra Reiter. Hier kann jeder GPIO einzeln aktiviert und seine Richtung (Eingang oder Ausgang) festgelegt werden. Die GPIO-Nummerierung richtet sich dabei nach den BCM-Nummern der GPIOs.
Beim Speichern werden die GPIOs dann entsprechend der Konfiguration eingerichtet und die zugehörigen Objekte erstellt.
Ich hatte beim ersten Speichern nach dem Aktivieren eines GPIO den Fehler, dass der State für die Richtung isInput
falsch gesetzt wurde. Ein erneutes Speichern mit gleichen Einstellungen hat dies dann korrigiert.
Der aktuelle Zustand des GPIO 5 ist damit dann immer über die Objekt-ID rpi2.0.gpio.5.state
verfügbar.
7. Jan. 2020 um 10:53
Hallo,
“Betreibt man ioBroker auf einem Raspberry Pi, dann möchte man sicherlich auch die GPIOs nutzen.”
Kann ich einen anderen im selben Netzwerk befindlichen Pi auch in IoBrooker einbinden?
Quasi eine Art – Remote rpi-Monitor.
7. Jan. 2020 um 11:27
Hallo Martin,
dafür musst du dann auf dem anderen Pi ebenfalls ioBroker installieren und als Slave im Multihost-Betrieb einrichten. Auf dem Slave kannst du dann den Adapter installieren und somit die GPIOs nutzen.
7. Jan. 2020 um 12:28
Danke! Werd ich demnächst gleich ausprobieren.
21. Apr. 2020 um 11:12
Bei starten des Adapters ziehen immer alle Relais an. True /False ist invertiert.
Gibt es eine Möglichkeit das zu ändern?
21. Apr. 2020 um 12:41
Ohne genauere Infos zur Hardware kann ich hier nur raten.
Wenn die Hardware und die Config soweit zusammen passen, dann kann es noch sein, dass bei den States der einzelnen Pins das Ack-Flag nicht gesetzt wird.
Das hatte ich teilweise, wenn ich mehrere States zur genau gleichen Zeit geändert habe. Dann wurde teilweise das Ack nicht gesetzt und beim Neustart von dem Adapter haben dann alle Ausgänge ohne Ack geschaltet.
21. Apr. 2020 um 12:53
Danke für die rasche Antwort.
Ich habe dieses Relais-Modul: https://www.az-delivery.de/products/8-relais-modul?variant=8198677758048&gclid=Cj0KCQjws_r0BRCwARIsAMxfDRhUzpT2Rsv2d5dTrTFZ5P-DvK584wi17w5ADm2WvoZIO0JL3ut9zVwaAiHAEALw_wcB
Verwende einen Raspberry 3B
Sobald ich den rpi2.0 Adapter neu starte wird zb. der rpi2.0.gpio.2.isInput auf “false” gesetzt. Ich hätte diesen jedoch gerne auf “true”. Derzeit zieht das Relais beim starten des Adapter an.
22. Apr. 2020 um 13:09
Für Ausgänge ist es richtig, dass `isInput` auf `false` steht. Bei `true` wäre der GPIO als Eingang geschaltet und damit evtl. auch der interne Pullup aktiv, was erklären würde, dass das Relais anzieht.
Der Schaltzustand muss dann in `rpi2.0.gpio.2.state` geschrieben werden.
22. Apr. 2020 um 15:03
Ich habe jetzt den Adapter nochmals gelöscht und neu installiert.
Oben hab ich mich anscheinend mit “true” und “false” vertan.
rpi2.0.gpio.2.isInput steht bei Neustart des Adapters auf “true”
rpi2.0.gpio.2.state steht ebenfalls auf “true”
Wie kann ich nun den rpi2.0.gpio.2.isInput standardmäßig, also auch bei Neustart des Raspberrys auf “false” setzen?
Sobald der Adapter deaktiviert oder deinstalliert wird, ist lässt das Relais wieder aus. Hardwareseitig müsste das also so passen.
22. Apr. 2020 um 15:10
Du musst eigentlich nur in den Einstellungen der Adapterinstanz den Typ auf `out` stellen und dann speichern. Wie oben beschrieben musste ich auch die Einstellungen ohne etwas zu ändern einfach ein zweites Mal speichern, aber dann wurde es übernommen.
22. Apr. 2020 um 15:20
Das habe ich schon mehrmals versucht. Leider immer wieder auf “true”.
Wenn ich auf IN umschalte zieht es nicht an, was jedoch verständlich ist.
24. Apr. 2020 um 17:19
Die Version 1.2.0 vom RPI2 kann den Ausgang 1 oder 0 per Definitionen setzen.
24. Apr. 2020 um 20:24
Ich kann die Version 1.2.0 über den iobroker nicht installieren. Bei mir ist die letze verfügbare Version 1.1.1.
24. Apr. 2020 um 17:21
Hallo Bob, könntest du mir kurz erklären wie ich das setzen kann?
Danke
24. Apr. 2020 um 21:59
Hab es jetzt über die URL installieren können. Dann kann der Ausgang gesetzt werden. Vielen dank für die Infos.
29. Mai. 2020 um 20:44
Hallo zusammen, wenn man ein gpio auf in setzt, wo kann man dan bestimmen ob der Eingan Pullup oder Pulldown ist?
Und wo gibt es die Version 1.2.0 ?
Gruss Sascha
5. Jun. 2020 um 18:35
Hallo Sascha,
die internen Pullup/Pulldown Widerstände des RasPi lassen sich mit dem Adapter meines Wissens nach nicht aktivieren, da für die GPIOs das File-Interface verwendet wird.
Die Version 1.2.0 kannst du über die GitHub-URL https://github.com/iobroker-community-adapters/ioBroker.rpi2 installieren.
12. Jun. 2020 um 16:07
Das Update funktioniert leider nicht. Ich habe immer noch die Version 1.1.1.
Gibt es irgendeine alternative zu ioBroker?
Gruss Sascha
8. Jun. 2020 um 17:17
Hallo Peter
Vielen dank für die Info, ich habe das jetzt mit Hilfe vom Raspberry Forum, über einen Optokoppler und den 5V vom Raspberry gelöst. Doch nun habe ich ein neues Problem.
Wenn ich den Raspberry starte, wird irgendwann, wenn auch der ioBroker gestartet ist, das Relais kurz angesprochen, das ist natürlich blöd, weißt Du vielleicht voran das liegen könnte?
Gruss Sascha
9. Jun. 2020 um 20:24
Das kann viele Gründe haben. Eventuell greift irgendeine andere Software gleichzeitig auf die GPIOs zu, oder irgendwo in deiner Hardware ist noch ein Fehler.
Dafür wäre es sinnvoll herauszufinden, ob das ganze irgendeinem Muster folgt, bei bestimmten Situationen passiert, etc.
11. Jun. 2020 um 16:15
Das passiert immer, wenn ich den Raspberry neu starte, sonst funktioniert das ganze eigentlich gut. Wenn ich nur den ioBroker dienst stoppe und starte, passiert das nicht, das passiert nur bei einem Neustart/Reboot vom Raspberry
21. Jun. 2020 um 15:03
Hallo
Ich habe das ganze jetzt mal auf einem Raspberry pi3 installiert, da habe ich das mit dem Phänomen mit dem Bin wenn er startet nicht.
Hat niemand eine Idee?
22. Jun. 2020 um 9:50
Ich vermute das hängt mit deiner Hardware zusammen.
Beim Start sind alle GPIOs erst mal als Eingänge geschalten und damit hochohmig, wodurch kein definierter Pegel anliegt. Du könntest zu jedem GPIO noch einen externen PullUp- oder PullDown-Widerstand von 10 kΩ dazu bauen, jenachdem ob du ein High- oder ein Low-Signal brauchst. Beim PullUp aufpassen, dass du an die +3,3 V und nicht an die +5 V gehst! PullDown wäre gegen GND.
Das unterschiedliche Verhalten bei verschiedenen RasPi Versionen kann damit zusammenhängen, dass diese intern unterschiedliche Schaltkreise für die GPIOs nutzen.
23. Jun. 2020 um 17:20
Ich habe den “Fehler” gefunden.
Es ist so, ich habe mir ein JS Skript gemacht, welches den Pin(Raspberry) an dem das Relais hängt schaltet. Nun habe ich das JS auf starten gestellt. Also ist es logisch das bei einem Neustart, das JS Skript gestartet wird und den Pin bzw. das Relais schaltet. Damit das nicht passiert habe ich das Skript einfach auf aus gestellt.
Geschaltet wird über ein Event von der ioBroker Visualisierung.
Ich hoffe das war verständlich.
Gruss Sascha
20. Sep. 2020 um 22:16
Hallo Herr Müller,
ich habe ein IOBroker Multihost System (2x Raspberry) und möchte am Slave die GPIO’s ansteuern.
Nun stehe ich aber vor dem Problem, dass ich den rpi Monitor nur am Master installieren kann (Es kann nur eine Instanz erzeugt werden) und somit auch nur die GPIO’s des Mastersystems zur Verfügung stehen.
Kennen Sie hierfür eine Lösung?
Danke, LG
Wolfgang
22. Sep. 2020 um 12:17
Hallo Wolfgang,
direkt eine Lösung dafür habe ich nicht. Der Adapter erlaubt aktuell nur eine Instanz.
Du könntest auf der GitHub Seite des Adapters einen Issue dazu erstellen und dort nach einer Lösung fragen.
28. Sep. 2020 um 22:11
Hallo Wolfgang
verschiebe die rpi-Instanz vom Master auf den Slave und installiere dann eine zweite Instanz für den Master. So hat es bei mir funktioniert.
Gruss Wolfgang
29. Sep. 2020 um 14:17
Danke für die Info, auf die Idee wäre ich nie gekommen. 🙂
23. Mai. 2023 um 20:35
Hallo zusammen, ich habe meinen raspberrypi am Iobroker angebunden. Nun habe ich bei den gpios im state immer (null) stehen :-(.
Kann mir jemand einen Tipp geben, was ich falsch mache oder was ich tun muss?
25. Mai. 2023 um 16:13
(null) heißt, dass noch keine Daten in den State geschrieben wurden.
Hast du geschaut, dass die Adapterinstanz auch wirklich läuft und grün ist?
Bei Fehlern sollten entsprechende Meldungen in den Protokollen vermerkt sein.
28. Mai. 2023 um 18:46
Also der Adapter läuft, ist grün. Folgend Meldung finde ich aber in den Protoollen:
annot setup port 22 as input: Error: Unable to match Revision in /proc/cpuinfo: processor : 0vendor_id : GenuineIntelcpu family : 6model : 142model name : Intel(R) Core(TM) i5-7260U CPU @ 2.20GHzstepping : 9microcode : 0x62cpu MHz : 2200.000cache size : 4096 KBphysical id : 0siblings : 4core id : 1cpu cores : 2apicid : 2initial apicid : 2fpu : yesfpu_exception : yescpuid level : 22wp : yesflags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_eppvmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml ept_mode_based_execbugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_stale_data retbleedbogomips : 4399.99clflush size : 64cache_alignment : 64address sizes : 39 bits physical, 48 bits virtualpower management:processor : 1vendor_id : GenuineIntelcpu family : 6model : 142model name : Intel(R) Core(TM) i5-7260U CPU @ 2.20GHzstepping : 9microcode : 0x62cpu MHz : 2200.000cache size : 4096 KBphysical id : 0siblings : 4core id : 1cpu cores : 2apicid : 3initial apicid : 3fpu : yesfpu_exception : yescpuid level : 22wp : yesflags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_eppvmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml ept_mode_based_execbugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_stale_data retbleedbogomips : 4399.99clflush size : 64cache_alignment : 64address sizes : 39 bits physical, 48 bits virtualpower management:
28. Mai. 2023 um 18:48
Also irgendetwas ist sicher falsch, aber ich habe keine Ahnung was…
So tief stecke ich da leider auch nicht drin…
28. Mai. 2023 um 19:03
Der Meldung nach läuft der Adapter bei dir auf einem Rechner mit einer i5-7260U CPU. Das ist definitiv kein Raspi.
28. Mai. 2023 um 20:53
Ich habe Iobroker auf einem Intel NUC laufen, dazu eine raspberrymatic. Ich bin davon ausgegangen, dass der Adapter auf dem iobroker läuft, also auf dem Intel nuc
Ich sehe gerade, dass ich anscheinend keine Ahnung habe 🙁
29. Mai. 2023 um 19:27
Also hast du deinen ioBroker auf dem NUC laufen und möchtest die GPIOs von einem Raspi ansteuern?
Wenn beide im selben Netzwerk hängen, dann kannst du auf dem Raspi einen ioBroker Slave installieren, den mit deinem vorhandenen ioBroker (Master) koppeln und dann auf dem Slave den rpi2 Adapter installieren. Gesteuert wird dann alles vom Master aus, aber der Adapter läuft auf dem Slave und hat damit Zugriff auf die GPIOs.
Anleitungen zur Einrichtung des Slave solltest du im ioBroker Forum und/oder im Netz finden.
30. Mai. 2023 um 18:10
Hört sich erst mal gut an.
Allerdings läuft auf dem Raspberry Raspberrymatic.
Geht das dann überhaupt?
Ich werde nochmal recherchieren…
30. Mai. 2023 um 22:21
Ich habe jetzt in der Raspberrymatic das iobroker addin installiert. Dann habe ich auf dem iobroker auf dem NUC multihost enabled, sozusagen 😉
Anschließend auf dem iobroker addin versucht, mit dem mulithost zu connecten. Das hat so leider nicht funktioniert :-(.
Ich muss mal weiter recherchieren…
31. Mai. 2023 um 9:12
In dem Fall brauchst du keinen ioBroker Slave, sondern wahrscheinlich (habe ich nie selbst getestet) den hm-rpc ioBroker Adapter, der sich dann mit der Homematic verbindet.
Sofern du nicht aus irgendwelchen Gründen zwingend auf RaspberryMatic/Homematic angewiesen bist, würde ich empfehlen alles auf ioBroker umzustellen. Dann mit einem Master (NUC) und Slave (Raspberry).
Dann hast du ein in sich konsistentes System und ich würde behaupten, dass sich mit ioBroker alle Anwendungsfälle abdecken lassen.