Raspi und 433Mhz-Funksteckdosenschaltung, Switch auf OpenHAB

Companion Cube, zartrosa leuchtend

Companion Cube, zartrosa leuchtend

Doch schon sechs Jahre her: da baute ich den CompanionCube mit Raspi drin, um via Raspberry-Remote eine Latte Funksteckdosen mit angeschlossener Beleuchtung zentral zu schalten. In sechs Jahren gehen SD-Speicherkarten und Raspis auch mal fratze, die Karte wurde zweimal gewechselt, der Raspi schien mir beim jetzigen Ausfall auch zumindest so ein unsicherer Kandidat, dass man sich über einen Generationenwechsel Gedanken machen sollte.

Dann ists sinnvoll, an die Zukunft zu denken: will ich in alle Ewigkeit über einen 433Mhz-Sender Flohmarkt-Funksteckdosen schalten? Vielleicht irgendwann nicht auch mal Zigbee-Infrastrukturen ausprobieren? Kann man das Alte beibehalten und neues zu- und ausbauen, vielleicht sukzessive ablösen? Das geht, und Mittel der Wahl zum 433MHz-Funksteckdosen-Schalten ist openHAB bzw. die passende Raspi-Portierung openHabian.

Im Folgenden stehen die eigentlichen Setupschritte/Anleitungen in erster Linie in zwei Howtos, die ich hauptsächlich nutzte: einmal von
· Tutorials Raspberry-Pi und ein wenig weitere Inspiration von
· Klenzel.
Im Folgenden schreib ich vor allem über Fehler und Probleme, die ich trotzdem hatte, weil die hat vielleicht jemand anderes auch.

Das beginnt mit der aktuellen Raspi-Knappheit. Für OpenHab sollte es eher ein Raspi4 sein, mit den ersten Serien wird man leistungstechnisch nicht glücklich. Woher kriegt man Raspis? Ich hatte via rpilocator geguckt und dann mangels Verfügbarkeit nicht einen Standard-Raspi geshoppt, sondern die etwas umständlichere Variante: Raspi 4 Compute Module plus CM4 IO-Board. Teurer insgesamt, größer, aber ne Latte mehr Ausgänge/Schnittstellen (die ich zugegebenermaßen nicht brauche) und eine 12V-Stromversorgung, die meinem Eindruck nach deutlich friedlicher ihren Job macht als die „normale“ Raspi-Stromversorgung (Yeah! wer schon die gelegentlichen „Netzteil macht gelegentlich 100mA zu wenig“-Probleme am Raspi hatte, wird meine Seligkeit erahnen).

Sehr schöne weitere Nebenwirkung: man braucht die clevererweise mitbestellten HighPerformance-SD-Karten gar nicht, weil das IO-Board einen eigenen eMMC-Speicher mitbringt, der im Unterschied zu den mittelfristig immer mit Schreib/Lesezyklen verschleißenden SD-Karten haltbarer sein soll. Yeah!, nur: da muss man anders das System aufsetzen. openHABian auf ein Raspi-CM mit eMMC aufspielen: Jeff Geerling sagt, wies geht. Wie nebenan beschrieben, auf dem RPI-IO-Board per Jumper das eMMC-Boot deaktivieren. Wer wie ich keine Jumper rumliegen hat, kann nen Pin-Kabelverbinder nehmen.

Dann wie beschrieben den Pi per USB an den Hauptrechner anschließen (meine Erfahrung: kurze Kabel und keine Hubs/Verlängerungen – deswegen machte ich den Schritt am Schleppi). libusb auf dem Hauptrechner installieren und rpiboot bauen.
Wenn noch nicht geschehen: den Raspberry Pi Imager installieren und das RPI-OS-Image der Wahl bereitstellen (in meinem Fall naheliegenderweise openHABian, info/Howto auch hier. Entpacken und mit dem Imager aufspielen.

Nun sollte man ein openHAB laufen haben, selber brauche ich aber noch mein Funkmodul. Bzw. grundsätzlich muss man OpenHAB beibringen, womit es alles kommunizieren soll. Das geht unter Einstellungen->Bindings:

Zu installierende Bindings in OpenHAB

Zu installierende Bindings in OpenHAB

…wie man sieht, ich hab
· GPIO (zum Pins ansteuern)
· Exec (Notwendig! für Shellskripte)
· piLight (wahrscheinlich nicht nötig)
· Zigbee (für später)

draufgeworfen. Wirklich notwendig scheint mir für meinen Zweck an sich nur Exec. Die GPIO-Ansteuerung für den angeschlossenen 433MHz-Sender machen wir jetzt.

RPI-IO-Board, Pinout

RPI-IO-Board, Pinout

Anschließen, wo? Masse und 5V sind klar (4 und 6), aber der Data-PIN für 433 ist 11 (GPIO 17, lt. CM4-J8-Header-Pinout GPIO 0).
Wir brauchen die 433Utils, die kriegen wir in /opt/433Utils (anlegen) mit
git clone --recursive https://github.com/ninjablocks/433Utils.git
Mit make erstellen.
Dann brauchen wir wiringPi. Das ursprüngliche Projekt von Drogon ist down und wird auch nicht weiter gepflegt. Hier war ich recht lang am suchen, aber in /opt/WiringPi/ mit
git clone https://github.com/WiringPi/WiringPi
das Alternativprojekt holen und mit build bauen (nicht mit make wie nebenan geschrieben).

Raspberry Pi 4 Compute Module, IO-Board und 433MHz-Sender

Raspberry Pi 4 Compute Module, IO-Board und 433MHz-Sender

Jetzt sind wir an sich soweit, dass wir schon mal von der Kommandozeile aus schalten können sollten:
./send 11011 3 1
./send 11011 3 0

Die Kommandozeile funkt!

Die Kommandozeile funkt!

Wenns nicht tut: am Kabel wackeln. Im Ernst: an sich sollte das rennen. Sicherheitshalber immer was in Reichweite schalten, ich hab auch schon schlicht vergessen, dass ohne Antenne die Mini-Sender gelegentlich nicht wirklich reichweitenstark sind. Gern auch zwei Steckdosen ausprobieren, nochmal die Haus- und Gerätecodes prüfen, usw.

Jetzt gehts an das Script, mit dem dann irgendwann via openHAB alles angesteuert werden soll. Ich orientierte mich an dem von Tutorials… und hab meine Funksteckdosen analog benannt:

#!/bin/sh
if [ "$1" = "PC1" ]; then
if [ "$2" = "off" ] || [ "$2" = "0" ] || [ "$2" = "OFF" ]; then
/opt/433Utils/RPi_utils/send 11011 4 0
else
/opt/433Utils/RPi_utils/send 11011 4 1
fi
fi
if [ "$1" = "FLUR" ]; then
if [ "$2" = "off" ] || [ "$2" = "0" ] || [ "$2" = "OFF" ]; then
/opt/433Utils/RPi_utils/send 11011 5 0
else
/opt/433Utils/RPi_utils/send 11011 5 1
fi
fi
...
if [ "$1" = "LGEis" ]; then
if [ "$2" = "off" ] || [ "$2" = "0" ] || [ "$2" = "OFF" ]; then
/opt/433Utils/RPi_utils/send 11100 4 0
else
/opt/433Utils/RPi_utils/send 11100 4 1
fi
fi

…so nun 19 Dosen angesteuert :) Das Script heißt run.sh und wurde mit
sudo chmod +x run.sh

ausführbar und via
sudo chown openhab: run.sh

dem openhab-User überantwortet.

Das müssen wir nun openHAB beibringen.

Dafür muss openHAB aber auch mit Regexen aus den Scripten raus arbeiten können. unter „Einstellungen – Add-Ons – Other Add-Ons“ sind die Regex-Transformationen, die man noch nachrüsten muss:

Openhab muss Regenechsen zähmen

Dann wieder entlang des Raspi-Tutorials: zuerst legen wir die Things an. Nebenan wars immer nur eines, ich hab nun eben eine poweroutlet.things-Datei in /etc/openhab/things/ liegen, die so anfängt:

Thing exec:command:poweroutletPC1-control [ command="/opt/433Utils/RPi_utils/run.sh PC1 %2$s", interval=0, autorun=true ]
Thing exec:command:poweroutletFLUR-control [ command="/opt/433Utils/RPi_utils/run.sh FLUR %2$s", interval=0, autorun=true ]
Thing exec:command:poweroutletSZSchrank-control [ command="/opt/433Utils/RPi_utils/run.sh SZSchrank %2$s", interval=0, autorun=true ]
Thing exec:command:poweroutletSZBaum-control [ command="/opt/433Utils/RPi_utils/run.sh SZBaum %2$s", interval=0, autorun=true ]

…usw., ein Ding pro Zeile. Man bemerkt die eindeutigen Kennungen (PC1, FLUR, SZSchrank…). Die müssen hier und in den folgenden Files konsistent sein. Weiter sollen alle Dateien openhab gehören (chown…) und man vertippert sich schneller als man mag, wenn man das alles im Terminal mit nano macht.

Dann haben wir die Items (poweroutlet.items-Datei in /etc/openhab/items/):

Group grp_poweroutlets "Arbeitszimmer" String poweroutletPC1Switch "PC-Fenster" (grp_poweroutlets) [ "Switchable" ] { channel="exec:command:poweroutletPC1-control:input", autoupdate="true" }
String poweroutletFLURSwitch "Flur" (grp_poweroutlets) [ "Switchable" ] { channel="exec:command:poweroutletFLUR-control:input", autoupdate="true" }
String poweroutletSZSchrankSwitch "Schlafzimmer Schrank" (grp_poweroutlets) [ "Switchable" ] { channel="exec:command:poweroutletSZSchrank-control:input", autoupdate="true" }
String poweroutletSZBaumSwitch "Schlafzimmer Baum" (grp_poweroutlets) [ "Switchable" ] { channel="exec:command:poweroutletSZBaum-control:input", autoupdate="true" }
String poweroutletFLEDSwitch "Flur-LED" (grp_poweroutlets) [ "Switchable" ] { channel="exec:command:poweroutletFLED-control:input", autoupdate="true" }


(man bemerke in beiden Files das „exec“ – hier haben wir die Anbindung an das „Exec“-Binding, mit dem Openhab externe Skripte ansteuern kann)

und die Sitemap ( (poweroutlet.sitemap-Datei in /etc/openhab/sitemap/):

sitemap poweroutlets label="Funksteckdosen" {
Frame label="Licht" {
Switch item=poweroutletPC1Switch //mappings=[ "ON"="ON", "OFF"="OFF" ]
Switch item=poweroutletFLURSwitch //mappings=[ "ON"="ON", "OFF"="OFF" ]
Switch item=poweroutletSZSchrankSwitch //mappings=[ "ON"="ON", "OFF"="OFF" ]
...
}
}

Und jetzt funktioniert gar nichts, weil OpenHAB seit neuestem eine Whitelist hat, in der alle! Befehle einzeln hinterlegt sein müssen, die als Exec aufgerufen werden, und das ist nicht etwa ein „/opt/433Utils/RPi_utils/run.sh“-Einzeiler, sondern

# For security reasons all commands that are used by the exec binding or transformation need to be whitelisted.
# Every command needs to be listed on a separate line below.
/opt/433Utils/RPi_utils/run.sh FLUR %2$s
/opt/433Utils/RPi_utils/run.sh PC1 %2$s
/opt/433Utils/RPi_utils/run.sh SZBaum %2$s
/opt/433Utils/RPi_utils/run.sh FLED %2$s
...

in der exec.whitelist unter /etc/openhab/misc/.

Spätestens jetzt sollte man beim Testen einen Blick auf die Logs werfen, um zu sehen, ob/was rumkommt. Da gibts den Logviewer direkt im Browser, in meinem Fall http://192.168.0.222:9001/:

Openhab-Logs direkt im Browser

Openhab-Logs direkt im Browser

Openhab- interne Konsole

Openhab- interne Konsole

Alternativ die Console. Dahin kommt man mit
$> openhab-cli console
Password: habopen
und log:tail.
Mit Strg-C kommt man aus dem Log, mit logout aus der Konsole.

Es sollte alles tun. Lokal aufrufbar sollte die Schaltseite nun sein unter
http://192.168.0.222:8080/basicui/app?sitemap=poweroutlets
bzw. der IP/dem Hostnamen, den ihr statt 192.168.0.222 verwendet.

Erste Schalter in der openHAB-UI

Erste Schalter in der openHAB-UI

Wenns nicht tut, wenn man schaltet, dann sollte man in den Logs wenigstens Anhaltspunkte sehen, was konkret schieflief.

Jetzt noch ein Quick and dirty-Hack meinerseits: Die URL will ich ja auch auf dem Handy, Tablet, sonstwo haben, mit Homescreen-Icon usw. Nun rennt auf openHabian standardmäßig ein Jetty-Webserver, der, nun, etwas rudimentär ausfällt. Platt gesagt: ich hatte kurz mit Apache und nginx rumgespielt und kam schnell an einen Punkt, an dem ich sagte, nee, lass, das wechselwirkt zu undurchsichtig für mein begrenztes Wissen.

Openhab-UI auf Mobile

Openhab-UI auf Mobile

Jedenfalls, Jetty hostet seine Seiten unter /openhab/html/, was dort liegt, kann unter (serverhost):8080/static/ abgerufen werden. Ich hab mir einfach eine index.html reingeworfen, dazu favicon.ico und apple-touch-icon.png, und in die index.html die einschlägigen Headerverweise auf Favicon und Homescreen-Icons, und ansonsten ein 100%/100%-iFrame, in den ich die /basicui/app?sitemap=poweroutlets reinwarf – denn das iPhone lässt mich nicht die Parameter-URL direkt bookmarken, außerdem kann ich der mein Touch-Icon nicht mitgeben, weil die openHAB-Webseiten dynamisch durch Jetty durchgeneriert werden.

Es ist meines Wissens nach kein gültiger Standard, aber hier tut es: der iFrame-Inhalt ist ganz normal responsive, wenn man den

<meta name="viewport" content="width=device-width, user-scalable=yes, initial-scale=1.0, minimum-scale=0.3, maximum-scale=3.0">

reinknallt. In meinem Fall (Filenames may vary) noch

<link rel="apple-touch-icon" href="companioncube.png">
<link rel="icon" href="favicon.ico">

Apple Touch Icon muss.

Apple Touch Icon muss.

…und wir sind durch.

Er leuchtet nicht mehr zartrosa, da muss ich mir noch was überlegen. Aber immerhin, auch das CM4-Board passte in den Cube rein. Und irgendwann nun noch Zigbee.

Gerät schaltet, ich bins zufrieden.

Kategorie: Allgemein Tags: , . Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.