Dieses Wiki ist ein Archiv bis 2023. Das aktuelle Wiki findet sich unter https://wiki.hamburg.ccc.de/
Licht
Hardware
Da sind ein paar Licht-Dinge an der Decke. Die werden über DMX-512 angesprochen.
- Leiste Tafel/Fenster
- Leiste Tafel/Tür
- …
Ansteuerung
Es hängt ein ENTTEC Open DMX USB-Gerät rum und bespielt den DMX-Bus. ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
. Ist also im Prinzip ein normaler FTDI USB-Seriell-Wandler.
Hypervisor-Config
Da der bei uns in einer VM (mit dem Namen licht
) hängt ist noch einiges nötig.
Auf dem Hypervisor (Debian/systemd/GNU/Linux) das ftdi_sio
-Modul blacklisten:
root@red.bikeshed.hamburg.ccc.de:~# cat /etc/modprobe.d/blacklist.conf blacklist ftdi_sio
Device der VM mitgeben:
<hostdev mode='subsystem' type='usb' managed='no'> <source startupPolicy='optional'> <vendor id='0x0403'/> <product id='0x6001'/> </source> </hostdev>
Man beachte das startupPolicy
. Das ist ein USB-Gerät, das könnten Leute abziehen, und wir wollen trotzdem, dass die VM dann startet. Genau aus dem Grund müssen wir auch noch mehr tun. Obigen XML-Code in eine Datei tun, z.B. /root/dmxcontroller.xml
. Dann legen wir eine udev-Regeln an, dass beim anstöpseln des Gerätes das auch direkt an die VM geht:
# /etc/udev/rules.d/90-libvirt-usb.rules ACTION=="add", \ SUBSYSTEM=="usb", \ ENV{ID_VENDOR_ID}=="0403", \ ENV{ID_MODEL_ID}=="6001", \ RUN+="/usr/bin/virsh attach-device licht /root/dmxcontroller.xml" ACTION=="remove", \ SUBSYSTEM=="usb", \ ENV{ID_VENDOR_ID}=="0403", \ ENV{ID_MODEL_ID}=="6001", \ RUN+="/usr/bin/virsh detach-device licht /root/dmxcontroller.xml"
Lustig, nech? Bitte bitte Bescheid sagen, falls ich da ne Funktion in libvirt übersehen hab.
Treiber-Config
So, endlich haben wir das Device am Gerät. Wir erinnern uns, USB-Vendor 0x0403 und Device-ID 0x6001. Jetzt wollen wir es auch schön ansteuern. Dazu muss man dem FTDI beibringen, auch ordentliches DMX rauszupipen, das einfach aus einer Folge Bits besteht und keine doofen Start/Stopbits und so hat. Das macht der normale ftdi-Treiber im Linux Kernel nicht, also rauswerfen:
root@licht.z9:~# cat /etc/modprobe.d/dmx_usb.conf blacklist ftdi_sio
Außerdem muss man darauf achten, dass brltty
nicht dazwischenfunkt, also deinstallieren.
root@licht.z9:~# apt-get remote brltty
Jetzt müssen wir ein neues Kernelmodul installieren. Dazu brauchen wir die Kernel-Header und nen Compiler und so. Das sei dem Leser überlassen. Yay. Angeblich ist das nur für 2.6, klappt mit 3.16 aber auch noch. Wir sind gerade auf Commit ee99ca7edbd9e093480ad63341ac007394047bde.
# git clone https://github.com/lowlander/dmx_usb_module.git # cd dmx_usb_module # make # cp dmx_usb.ko /lib/modules/`uname -r`/kernel/drivers/usb/serial/ # systemctl reboot # Ist ja ne VM, geht fix ;)
Wenn alles geklappt hat müsste es jetzt ein Device /dev/dmx0
geben. Weil wir ja mit minimalen Berechtigungen arbeiten und nix als root laufen lassen wollen müssen wir noch ne udev-Regel schreiben.
# /etc/udev/rules.d/65-dmxinput.rules KERNEL=="dmx[0-9]*", GROUP="licht" ACTION=="add", \ SUBSYSTEM=="usb", \ ENV{ID_VENDOR_ID}=="0403", \ ENV{ID_MODEL_ID}=="6001" ACTION=="remove", \ SUBSYSTEM=="usb", \ ENV{ID_VENDOR_ID}=="0403", \ ENV{ID_MODEL_ID}=="6001"
Also, vorausgesetzt, unser DMX-Progrämmchen läuft in der Gruppe licht
. Wer Lust hat kann hier noch nen Symlink anlegen, damit wir auch immer das gleiche Device an derselben Stelle haben.
Software
Jetzt wird's lustig. Unser Software-Aufbau:
device fifo websockets USB-Gerät <--- dmx_repeater <--- foobardmx <--- light (Farbwechsel-Skript) ruby node ruby
Der dmx_repeater
spricht direkt mit dem Device. Zu finden ist er unter https://gitlab.hamburg.ccc.de/ccchh/dmx-repeater
.
licht@licht.z9 $ git clone https://gitlab.hamburg.ccc.de/ccchh/dmx-repeater.git. Hat als Abhängigkeit nur ruby.
Der foobardmx
ist zum einen das Web-Dashboard, zum anderen weiß es, auf welchen DMX-Kanälen was passiert. Zu finden ist es unter https://gitlab.hamburg.ccc.de/ccchh/foobardmx
und in NodeJS geschrieben. Also das Clonen und irgendwie die Abhängigkeiten installieren. Hab vergessen, wie. Foobardmx connected sich über nen FIFO zum dmx_repeater.
Das letzte ist ein Tool ohne großen Namen, heißt light
. Das macht lustige Animationen, in dem es sich zum foobardmx connected und Kommandos schickt. Der foobardmx started light, indem es den entsprechenden Service startet. https://gitlab.hamburg.ccc.de/ccchh/light
.
Die Dinge brauchen noch Systemd-Units, um auch richtig zu starten:
# /etc/systemd/system/foobardmx.service [Unit] Description=foobardmx lightig web control After=dmx-repeater.service [Service] Type=simple WorkingDirectory=/home/licht/foobardmx ExecStartPre=/bin/sleep 5 ExecStart=/usr/bin/nodejs lighting.js >/dev/null 2>/dev/null User=licht Group=licht [Install] WantedBy=multi-user.target
# /etc/systemd/system/dmx-repeater.service [Unit] Description=dmx-repeater [Service] Type=simple WorkingDirectory=/home/licht/dmx_repeater/bin ExecStart=/home/licht/dmx_repeater/bin/dmx_repeater User=licht Group=licht Restart=always [Install] WantedBy=multi-user.target
# /etc/systemd/system/light.service [Unit] Description=slowly chaning colors [Service] Type=simple WorkingDirectory=/home/licht/light ExecStart=/home/licht/light/light User=licht [Install] WantedBy=multi-user.target
# visudo licht ALL=(ALL) NOPASSWD: /bin/systemctl stop light licht ALL=(ALL) NOPASSWD: /bin/systemctl start light
Services anmachen
# systemctl enable dmx-repeater # systemctl enable foobardmx