Gottesdienst-Arrangement:
Bei uns läuft im Grunde alles mit Debian/GNU Linux. Wir benutzen für den Gottesdienst einen leistungsstarken (Tuxedo [„streßfreie“ Hardware für Linux] Intel i9 CPU, 16GB RAM) PC für:
1) „Beamer“ (bei uns per HDMI -> LAN an 3 Monitore, davon wird das Signal für die beiden Moniture vorne per LAN übertragen) für Liedtexte, Filme und Präsentationen.
2) Kamera-Input
3) Bildmischer
4) Ton In- und Output
5) Streamen (ggf. inkl. Zoom)
6) Archivierung / Predigt auf die Homepage
7) Scheinwerfersteuerung
Da nur eine Person am PC sitzen und den steuern kann, braucht man weitere Geräte zum Steuern. Diese Geräte sind (alte) Handys und Tablets, die meist per App bzw. Webinterface steuern.
- „Beamer“software
Wir benutzen OpenLP als Software für unsere Monitore. Der PC hat einen Display-Port (DP)- und einen HDMI-Ausgang. Der Monitor am Technik-Tisch ist per DP verbunden, der HDMI-Ausgang geht in eine „Splitter-Box“, die das Signal auf LAN überträgt, was direkt vor den Monitoren wieder in HDMI umgewandelt wird. Zudem geht von dieser Splitterbox noch ein weiteres HDMI-Kabel zu einem Monitor, den man von der Bühne aus sehen kann.
OpenLP benutzt den HDMI-Port als Präsentationsbildschirm. Dank LibreOffice (backports) können wir nahezu alle PowerPoint-Präsentationen öffnen und übertragen. Gelingt das nicht, können wir immernoch einen Windows-Laptop per HDMI anschließen, dessen Signal wir allerdings am OpenLP vorbei auf die Monitore leiten müssen. Dazu später unter 3).
OpenLP kann sich (inzwischen wieder) mit CCLI verbinden, allerdings keine Lieder „melden“, die man genutzt hat. Man kann jedoch Liedtexte importieren. Im Grunde nutzen wir OpenLP für (Lied)Texte und zum Aufrufen von Präsentationen. Dabei ist OpenLP eng mit LibreOffice verbandelt. Außerdem spielt OpenLP noch Videos und Töne mittels VLC ab.
Die Steuerung von OpenLP übernimmt weitgehend ein Samsung Galaxy Note, auf dem die passende OpenLP-App läuft. Außerdem muß Web-Remote im OpenLP aktiviert sein. Dieses Handy muß im selbem LAN sein wie der Linux-PC, der App muß man die IP-Adresse des PCs verraten und so verbindet sie sich. Seit neuestem Haben wir sogar einen eigenen Technik-WLAN-Accesspoint (AP), weil es bei zuvielen Handys während des Gottesdienstes am normalen AP zu Störungen kommen kann. (Der Technik-AP läuft mit LibreCMC, die restlichen APs sind bei Freifunk mit angeschlossen, ermöglichen aber auch zusätzlich den Zugang ins Gemeinde-LAN – natürlich paßwortgeschützt).
OpenLP kann direkt vom PC, aber auch per App (OpenLP, findet man im f-droid-archiv, googleplay und auch im Apfelladen), aber auch per Fernsteuerung bedient werden. Falls in der Technik Not am Mann ist, kann man ein altes Handy mit App herausgeben. Die Fernsteuerung schaltet nur innerhalb eines Liedes bzw. einer Präsentation hin und her und ist für einen Prediger gedacht, der eben etwas präsentiert. Die Fernsteuerung hat einen Akku, der auf 1,5h Betrieb getestet wurde und danach binnen 30min per USB-C-Buchse aufgeladen wurde. Die aktuelle Akkuspannung kann man auch abrufen, wenn die Fernsteuerung eingeschaltet ist. Es ist ein LiPo-Akku, dessen Spannung typischweise bei 3,25V-3,27V liegt. Zum Laden muß das Gerät jedoch eingeschaltet sein! Wenn der Akku voll ist, liegen 4,14V an. - Kamera-Input
Nach längeren Problemen, diversen Experimenten und Schwierigkeiten benutzen wir nun ein Samsung Galaxy S8+, das an einem einfachen, fernsteuerbaren Schwenkarm befestigt ist. Die Originalschrottware auf dem Gerät wurde durch ein /e/-OS ersetzt. Das Handy selbst ist per USB3 mit dem PC verbunden und man kann es mittels scrcpy auch Fernsteuern. Auf dem Handy läuft OBSDroid, das sich mit OBS verbindet.
Außerdem wird per (W)LAN die App ferngesteuert: Heranzoomen, Schärfe, Bildausleuchtung, etc. Eine Aufgabe an der Technik ist, das zu managen, aber im Grunde schwenkt man nur die Kamera und optimiert den Zoom etwas nach. Ab und zu wird es unscharf und man muß mit der App etwas „spielen“. - Bildmischer
Zum Zusammenmischen des Bildes benutzen wir OBS. Dabei werden die Eingänge von Kamera, den Monitoren, bei Bedarf ein HDM-In (per USB3) von einem Windows-PC, aber auch der Ton (=> Punkt 4) verarbeitet. Im OBS befindet sich außerdem noch eine „virtuelle Kamera“, die genau das Bild in eine für das Linux-System erkennbare Kamera steckt. So kann etwa Zoom diese virtuelle Kamera benutzen.
Will man PowerPoint von einem Windows-PC aus übertragen (kam in den letzten 4 Jahren 1x vor, weil es nicht anders ging), kann man das per HDMI-In über OBS in die virtuelle Kamera „packen“ und diese dann am OpenLP vorbei zB per VLC darstellen. Auf diese Weise kann man alles noch aufzeichnen bzw. streamen.
OBS wird nicht ferngesteuert, das heißt, an der Stelle ist der PC belegt. - Ton In- und Output
Auch hier hatten wir lange Zeit vieles ausprobiert und es gab ständig ein Pfeifen im Ton. Erst kürzlich haben wir den „alten“ USB-Audio-Adapter wieder ausgegraben, der vor 4 Jahren unter Linux nicht richtig funktionierte. Nun tut er. Und mit ihm verschwand auch das Pfeifen.
Gemanaged wird das erstmal mit Pulseaudio (Debian-Standart), in dem es einen recht mächtigen Tonmischer gibt, mit dem man zB Geräte abstellen kann. Man sieht schon optisch sehr gut, ob man übersteuert, oder nicht und kann auch ohne Kopfhörer recht gut vom Mischpult aus nachregeln.
Die Ein- und Ausgänge sind alle analog und nicht digital (per USB) mit dem PC verbunden.
Im OBS kann man dann noch eine kleine Verzögerung einbauen, weil die Kamera ein bischen hinterherhinkt. - Streamen
Anfangs haben wir rein über Zoom gestreamt. Dabei griff Zoom das Bild von OBS ab (virtuelle Kamera), und verwendete den Pulseaudio-Ton. Das funktioniert theoretisch immernoch, wird aber nicht mehr genutzt.
Später wurde auf einen RaspberryPi4 (4GB) mit einem nginx+rtmp-plugin gestreamt. Hierbei wird der Stream noch zusätzlich in eine HLS-Struktur verpackt. Der Pi4 ist lokal im Haus und im selben LAN, aber ist eben auch von außen (früher dyndns) erreichbar (gewesen). Von diesem Pi4 aus wird der Gottesdienst zum „Krabbelraum“ (Libreelec auf einem Pi3 mit Analog-Hifiberry-Hat) für Eltern mit Kleinkinder und Babys übertragen. Außerdem startet automatisch jeden Sonntag um 10:28Uhr eine Übertragung mittels ffmpeg vom Pi4 zu unserer Peetube-Instanz, die auf einem angemieteten Hetzner–vserver (arm64, Debian/Gnu Linux) läuft, allerdings muß dazu das Streamen von OBS aus zum Pi4 schon gestartet sein. - Archivierung und Predigtupload
Am PC wird die Predigt erstmal per OBS aufgezeichnet. Das ist im Grunde eine Kopie des Streams auf der Festplatte. Nach der Predigt kann man ein Pythonscript im Terminal starten, das die neueste Aufzeichnung findet, den Namen des Predigers und das Thema abfragt. Daraus wird dann eine neue Datei gebastelt und nachdem die als richtig befunden wurde, wird daraus ein mp3 erstellt, das dann mittels pyocclient auf die NextCloud auf den in 5) schon genannten Hetzner-Server hochlädt. Außerdem wird von dem Python-Script ein Python-CGI-Script auf dem Server ausgeführt, das eine neue Predigtliste erstellt und außerdem noch eine Podcast-XML-Datei erstellt bzw. diese aktualisiert. Diese Datei greift das WordPress-Podcast-Plugin auf und generiert so eine Predigtliste.
Als letzten Punkt wandelt das Script den Film noch in h.265 um und schiebt es auf die große Festplatte des Pi4 – zusammen mit dem mp3. Dort liegt das Archiv, das man ebenfalls per NextCloud (aber auf dem Pi4) erreichen kann. Da der letzte Punkt sehr lange braucht, wird der PC automatisch danach heruntergefahren. - Scheinwerfersteuerung
Wir haben eine DMX-Leitung zu 7 Scheinwerfern, die die Bühne mit je 6 Kanälen beleuchten. Diese Scheinwerfer sind auch baugleich, was es relativ einfach macht. Die Ansteuerung erfolgt über ein USB->DMX-Gerät, das linuxtauglich ist. Als Steuersoftware benutzen wir OLA (Debian Paket). Da läuft ein olad im Hintergrund, den man ansteuern kann und über den so die Scheinwerfer angesteuert werden.
Dazu wurden ein paar Pythonscripte gebastelt, die im Grunde letztlich den String zum olad generieren und abschicken. Mittels des GUI kann man jeden Scheinwerfer einzeln einstellen und diese Einstellungen abspeichern. Dabei muß man im Scheinwerfer-Konfigurations-Verzeichnis erstmal Textdateien anlegen, die erstmal beschreiben, welcher Scheinwerfer welchen Kanal belegt und wie die Grundeinstellungen für die einzelnen Kanäle (rot, grün, blau, weiß, bernstein, uv) innerhalb des Scheinwerfer sind.
Mit dem CGI-Script kann man die Scheinwerfer mit einem Tablet oder Handy ansteuern, auch gruppiert, zB für „Band“ oder „Pult“. Allerdings gibt es beim Ansteuern immer wieder Störungen (auch unter Windows..), so daß das CGI-Script den String mehrmals abschicken muß, um das Störungsfrei zu übertragen. Ab und an hakt auch der olad, den man ggf. Neustarten muß, das ist aber eher selten.
Heizungssteuerung:
Das Haus hat 16 verschiedene Heizkreise (Fußbodenheizung), die man proprietär per App steuern kann. Gott sei Dank wurden dabei Steuergeräte des finnischen Herstellers Uponor eingekauft. Dabei steuert pro Etage ein Gerät 7 (oben) bzw. 9 (unten) Heizkreise. Ich verstehe bis heute nicht, wieso man da WLAN-Geräte in Blechkisten einbaut, damit sie innerhalb dieser Blechkisten keinen WLAN-Empfang haben. Es geht so leidlich, gibt es mal keine Verbindung, muß der Metalldeckel abgenommen werden.
Der derzeitige Gottesdienstsaal ist dabei je 2 Kreise fürs Foyer und den eigentlichen Gottesdienstsaal unterteilt. Alle anderen Räume haben je eigene Heizkreise.
Als Gesamtkonzept für Steuerungen und Anzeigen habe ich mich schon vorher für den quelloffenen Homeassistant (HA) entschieden, um zB per MQTT diverse Zählerstände und Sensoren mit einzubinden. Jedoch ist das in meinen Augen oft schlecht erklärt, ich habe eher durch Zufall herausgefunden, daß man den HA per Docker installieren muß und eben nicht in einer Python-Venv, damit MQTT auch funktioniert. Installiert habe ich den HA zu Hause auf einen „Toaster“, in der Gemeinde auf einem Raspberry Pi 4b und dort auf einer USB3-Festplatte.
Die Raumbelegung wird per NextCloud-Kalender organisiert. Inzwischen ist eine Schule und noch eine Gemeinde mit im Haus, die an unterschiedlichen Tagen diverse Räume belegen. Jeder Raum hat dabei einen eigenen Kalender. Es ist wichtig, daß es kein ganztägiges Ererignis ist, die Zeit muß eingetragen sein. Was man als Termin/Event selbst dabei einträgt, ist egal.
Der HA kann jeden dieser freigegebenen Kalender (=Raumbelegung) per CalDAV importieren. Ich habe der Einfachheit halber einen Technik-Account auf der NextCloud angelegt, der eben diese Kalender geteilt bekommen hat (per Gruppe). Diesen Account kann man in der vom HA mitgebrachten CalDAV-Schnittstelle (Einstellungen -> Geräte & Dienste -> + Integration hinzufügen unten rechts) eintragen und schon hat man die Raumbelegung in den HA „importiert“.
Die Uponor-Integration des HA ist allerdings nicht offiziell. Leider kann man auch nur eines der beiden Geräte in den HA integrieren. Ich habe sie mir per GIT heruntergeladen und das custom_components/uponor-Verzeichnis ins custom_components-Verzeichnis des installierten HA kopiert, den HA neu gestartet. Danach wurde diese Integration, wie oben beschrieben auch die CalDAV-Schnittstelle, gefunden und man konnte sie mit der korrekten IP-Adresse des Uponor-Gerätes in Betrieb nehmen. Klappt das, taucht es auch in den Einstellungen->Geräte auf:
Die Raumnamen wurden vorher mit der App eingetragen, wahrscheinlich braucht man diese App auch zum erstmaligen Inbetriebnehmen, da bin ich mir aber nicht sicher.
Nun hat der HA ja auch einen Automatisierungsbereich (Einstellungen -> Automatisierungen und Szenen), in dem man CalDAV mit Uponor verheiraten kann:
Wenn also im Kalender „Athen“ (der vom Büro EfG Ober-Ramstadt geteilt ist) eine Belegung ist, schalte 2 Stunden vorher (Fußbodenheizung ist träge!) die Heizung ein:
Das ist jedoch nur fürs EINSCHALTEN der Heizung. Ausgeschaltet wird dann entsprechend immer 30 Minuten vor dem Ende des Ereignisses. Wahrscheinlich kann man das noch optimieren. Ich habe also pro Raum 2 Automatik-Eintragungen. Zusätzlich wird jeden Tag um Mitternacht grundsätzlich alles ausgeschaltet, falls doch mal direkt am Gerät manuell eingeschaltet werden sollte.
Nun habe ich jedoch nur das Obergeschoß automatisiert, weil ich auf demselben HA kein 2. Uponor-Endgerät integrieren kann, die Integration kann nur ein Gerät steuern. Die Lösung lag nahe, daß ich das 2. Uponor-Gerät von meinem HA zu Hause (HA-Toaster), der per VPN-LAN-LAN-Kopplung (2 FritzBoxen) direkt per LAN auf das Gemeindenetzwerk zugreifen kann, ansteuere. Ich habe zu Hause ein anderes Subnetz als in der Gemeinde. Rückwärts kann ich dann eben diese HA-Toaster-Integration per (ebenfalls inoffizielle) Remote Homassistant Integration „zurückhole“. Die installierte ich auf beiden HAs genau so wie die Uponor-Integration. Man muß bei der Einstellung einerseits sagen, daß der HA-Toaster remote gesteuert wird und das HA an sich eben auch den HA-Toaster remote steuert. Die Authentifizierung geht per Token.
Danach mußte ich die zu „importierenden“ Geräte etc. noch festlegen. Ich habe für die Heizung dann ein extra Dashboard angelegt und je eine Karte manuell für Heizung oben und Heizung unten angelegt:
Die popp_*-Geräte sind dabei von mir zu Hause (HA-Toaster) importiert. Außerdem habe ich noch unter Einstellungen -> Geräte&Dienste im Reiter „Helper“ einen Gruppenschalter für die 4 Heizkreise im Gottesdienstraum angelegt
Man kann jeden einzelnen Raum bzw. Heizschleife anklicken und dann manuell auch ansteuern, da es für diese Geräte keinen Luftfeuchtemesser gibt, wird die Luftfeuchtigkeit mit 0% angegeben:
Nun muß nachwievor die Raumbelegung eingetragen sein und schon heizt es intelligent und automatisch. Unser Gemeindeleiter muß sich nun nicht mehr an der App die Finger wundwischen. 🙂