FHEM – wolf-u.li

Momentan beschäftige ich mich ein wenig mit Heimautomation. Da ich zur Miete wohne, kommt es leider nicht in Frage ein KNX/EIB-System zu installieren, da alle Teile wieder abnehmbar sein müssen. Daher muss ich eine Funklösung her. Als Software verwende ich FHEM, einen in Perl geschrieben Server, welcher die Verwaltung der Geräte übernimmt. Als Funk-Sender & -Empfänger kommt bei mir ein Busware COC zum Einsatz. Auf der Wiki-Seite von Busware wird wunderbar erläutert, wie man diese Einrichtung vollzieht, ich rate auf jeden Fall dazu, dort immer die aktuellsten Schritte nachzuvollziehen. Das folgende Tutorial ist auf dem Stand vom 09.05.2013.

Zunächst starte ich mit einem Raspbian auf dem ich das fhem-Debian-Paket installiere. Für die folgende Schritte wechsle ich auf den User “root”! Die folgenden Schritte sind natürlich auf eigene Gefahr!

Nachdem man die ersten Schritte auf dem System getan hat (SSH-Server einschalten usw.) kommt man dann zur Einrichtung des COC. Zunächst sollte man zuvor avrdude installieren, da man ohne dieses Tool nichts flashen kann:

apt-get install avrdude

Nun muss man zunächst einen Seriellen Port freimachen. Dazu muss man zunächst /etc/inittab editieren und die folgenden Zeilen mit einem Kommentar versehen:

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Sodass diese so aussieht:

# T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Anschließend muss man alle Einträge mit ttyAMA0 aus der Datei /boot/cmdline.txt entfernen. Meine Zeile sah vorher so aus:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Und danach dann so:

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Jetzt einmal rebooten und nach dem Boot wieder zu User “root” wechseln! Anschließend sollte man FHEM erstmal stoppen:

/etc/init.d/fhem stop

Dann wird die Firmware geflashed. Dazu muss man zunächst wissen, ob man einen COC mit 1-Wire oder ohne gekauft hat. Hat man einen mit, so muss man diese Datei herunterladen (COC.hex) andernfalls diese Datei (COC.radio_only.hex). Da ich keine 1-Wire-Extension gekauft hatte, nehme ich letztere:

wget "http://culfw.svn.sourceforge.net/viewvc/culfw/trunk/culfw/Devices/COC/COC.radio_only.hex?revision=HEAD" -O COC.radio_only.hex

Nun muss man den COC mit ein paar Kommandos ansteuern um den Bootloader anzusprechen:

echo "calling COC bootloader..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 0 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio18/value

Und nun wird die Firmware geflashed (Achtung Dateiname am Ende bei dem anderen Gerätetyp tauschen!):

avrdude -p atmega1284p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:COC.radio_only.hex

Dies sieht wie folgt aus:

COC-Firmware

Abschließend muss man nun noch die Datei /etc/init.d/fhem ein wenig abändern. Suche:

start)

Ersetze durch:

start)
	echo "resetting 868MHz extension..."
	if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
	if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
	echo out > /sys/class/gpio/gpio17/direction
	echo out > /sys/class/gpio/gpio18/direction
	echo 1 > /sys/class/gpio/gpio18/value
	echo 0 > /sys/class/gpio/gpio17/value
	sleep 1
	echo 1 > /sys/class/gpio/gpio17/value
	sleep 1

Dies initialisiert die COC-Erweiterung bei jedem Start von FHEM. Wenn man nun noch möchte, kann man einen Watchdog-Prozess installieren, welcher den Raspberry bei dauerhafter hoher CPU-Last durchpustet. Dies ist auf der Busware-Seite ganz unten beschrieben. Dort findet sich auch, wie man die Ansteuerung der 1-Wire und RTC Module vornimmt.

© 2005-2011 by Uli Wolf - This Content is distributed under the Creative Commons License
This feed is for personal, non-commercial use only.
The use of this feed on other websites without attribution to the author and notification of the author breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint: d2a576b5311479d89eff39b7ca886f6b)

Heute habe ich mir die Frage nach dem Stromverbrauch des Raspberry Pi gestellt, da ich zumindest einen im Dauerbetrieb für FHEM betreiben möchte. Ein schneller Blick in die Spezifikationen hilft hier weiter:

Raspberry Pi Model A: max. 2,5W (5V, 500 mA)
Raspberry Pi Model B: max. 3,5W (5V, 700mA)

Ich habe gerade mal nachgemessen: Beim hochfahren hatte er ~3,2W verbraucht, danach ist er nun bei ~2,8W. Das macht dann übers Jahr rund 25kW, was ich in Ordnung finde:

Raspberry Pi Stromverbrauch

Hier ein paar Fotos des aktuellen COC von Busware. Hier habe ich beschrieben wie man diesem initialisiert, um ihn mit FHEM nutzen zu können.

Gerade eben hatte ich mir vorgenommen, meine Fenstersensoren in FHEM Floorplan zu visualisieren. Dazu brauchte ich verschiedene Icons pro Schaltzustand. Um dies zu erreichen, gibt es den Link “Extend devStateIcon” am Fuße jeder Detailseite eines Gerätes.

Wenn man darauf klickt, hat man die Möglichkeit, eine Suche innerhalb des STATE, also des Status des Gerätes durchzuführen. In meinem Falle habe ich dort “closed” angegeben, da der Status zwischen “opened” und “closed” bei meinem Fenstersensor wechseln kann:

Dann muss man nur noch ein Bild auswählen. Führt man dies für beide Schaltzustände durch, so sieht dann das Attribut devStateIcon beispielsweise so aus:

Ein paar weiterführende Details (wie z.B. die Beeinflussung der Farbe bei SVG-Dateien) finden sich hier im Wiki. Bei mir sieht es in der fhem.cfg dann so aus:

# Fensterkontakt
define Fensterkontakt.Kueche MAX ShutterContact 07131f
attr Fensterkontakt.Kueche icon signal_Fenster_Offen.off
attr Fensterkontakt.Kueche room Kueche
attr Fensterkontakt.Kueche devStateIcon closed:signal_Fenster_Offen.off opened:signal_Fenster_Offen.on

Soeben habe ich mich gefragt, wie man eigentlich an die Fehlerkorrekturen (für FHEM) der FHEM-Developer kommt. Das Lesen des commandref von FHEM hat mich schließlich darauf gebracht, dass ab FHEM 5.3 eine update-Funktionalität zur Verfügung steht.

Will man wissen, was es neues gibt, so kann man sich per Telnet/WebInterface verbinden und zunächst:

update check

eingeben. Das gibt dann eine Liste der letzten Änderungen (die zwischen Versionen wie beispielsweise 5.3 und 5.4 durchgeführt wurden) aus. Für die meisten Fälle reicht es aus dann ein:

update

abzusetzen. Dann wird zunächst ein Backup durchgeführt und anschließend das Update gestartet. Zum Schluss muss man einmal FHEM durchpusten (Nicht wundern, das schiesst natürlich die Telnet-Session ab!):

shutdown restart

Damit ist das Update abgeschlossen. Bitte auf jeden Fall die commandref zum Update einmal lesen, bevor man es durchführt!

Wenn man wissen will, was geändert wurde, muss man sich nur die Datei “CHANGED” im Hauptordner von FHEM ansehen. Für Drittanbieter gibt es übrigens mittlerweile ebenfalls eine Update-Funktionalität, welche in den docs beschrieben ist.

Ich habe vor einiger Zeit meinen COC für den Raspberry PI an einen Kumpel verkauft und hatte mich eigentlich damit abgefunden, dass ich keine Funkverbindungen in meinem FHEM anbinden möchte. Das hat sich nun geändert und so habe ich über das FHEM-Forum einen CUL gekauft. Auf meiner ersten Suche in der Suchmaschine meines Vertrauens kam auch ein “Making of” Video des CUL heraus, welches ich hier kurz einbinden möchte.

Wenn man einen Busware CUL_V3 mit der CULFW Firmware flashen möchte, bekommt man viele Anleitungen, die oft veraltet sind. Diese hier ist von heute (17.09.2013) und repräsentiert mal wieder den aktuellen Stand. Sollte etwas nicht funktionieren, so gebt bitte Bescheid!

Öffne zwei SSH-Verbindungen und lasse in einer (im folgenden Konsole 1) das folgende Laufen:

tail -f /var/log/syslog

Nun steckt man den CUL in den USB-Port während dessen Button auf der Rückseite gedrückt gehalten wird (WICHTIG). In Konsole 1 sollte nun folgendes erscheinen:

Sep 17 17:51:20 raspberrypi kernel: [ 128.252140] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
Sep 17 17:51:20 raspberrypi kernel: [ 128.363000] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=2ff4
Sep 17 17:51:20 raspberrypi kernel: [ 128.363031] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 17 17:51:20 raspberrypi kernel: [ 128.363049] usb 1-1.2: Product: ATm32U4DFU
Sep 17 17:51:20 raspberrypi kernel: [ 128.363063] usb 1-1.2: Manufacturer: ATMEL
Sep 17 17:51:20 raspberrypi kernel: [ 128.363077] usb 1-1.2: SerialNumber: 1.0.0

In Konsole zwei kann man nun das folgende eingeben:

lsusb

Dabei kommt nun das folgende raus:

Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 03eb:2ff4 Atmel Corp.

Nun wird die Firmware installiert. Dazu wird diese zuerst heruntergeladen:

wget http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUL/CUL_V3.hex?format=raw -O CUL_V3.hex

Nun wird der CUL einmal gelöscht:

dfu-programmer atmega32u4 erase

Und neu geflashed:

dfu-programmer atmega32u4 flash CUL_V3.hex

Das sollte etwa so aussehen:

Validating…
18268 bytes used (63.71%)

Und danach wird der CUL zurückgesetzt:

dfu-programmer atmega32u4 reset

Jetzt etwas Geduld mitbringen, das dauert einen Moment. In der Konsole 1 müsste nach einiger Zeit folgendes auftauchen:

Sep 17 17:58:15 raspberrypi kernel: [ 542.796600] usb 1-1.2: USB disconnect, device number 4
Sep 17 17:58:16 raspberrypi kernel: [ 543.548331] usb 1-1.2: new full-speed USB device number 5 using dwc_otg
Sep 17 17:58:16 raspberrypi kernel: [ 543.660164] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=204b
Sep 17 17:58:16 raspberrypi kernel: [ 543.660197] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 17 17:58:16 raspberrypi kernel: [ 543.660214] usb 1-1.2: Product: CUL868
Sep 17 17:58:16 raspberrypi kernel: [ 543.660229] usb 1-1.2: Manufacturer: busware.de
Sep 17 17:58:16 raspberrypi kernel: [ 543.730877] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
Sep 17 17:58:16 raspberrypi kernel: [ 543.735526] usbcore: registered new interface driver cdc_acm
Sep 17 17:58:16 raspberrypi kernel: [ 543.735555] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Dann war das ganze erfolgreich. Jetzt kann man in FHEM mal das folgende Kommando absetzen:

usb scan

Das sieht dann so aus:

Jetzt kann man den CUL in FHEM einbinden.

Vor kurzem hat busware den SCC veröffentlicht, welcher dank durchgeschleifter Ports wunderbar gestapelt werden kann. In diesem Beitrag möchte ich kurz die Teile physikalisch vorstellen und dann in FHEM einbinden.

So sieht das ganze dann physikalisch aus:

Wenn man diese dann stapelt, so setzt die der Steckerleiste gegenüberliegende Seite mit dem Kondensator auf der darunterliegenden Ebene auf. Dies stützt diese Seite dann. Was dann so aussieht:

Platziert man das ganze auf einem Raspberry PI, so setzt der Kondensator genau auf einem isolierten Punkt auf der Platine auf, sehr schön!

Auf den Bilder sind zwei 868 Mhz SCC und ein 433Mhz SCC zu sehen. Die angebrachten Antennen auf den letzten beiden Bilder sind die 868 Mhz +5dbi Antenne, 433Mhz

Definiert wird der SCC in der fhem.cfg wie folgt (von “unten” nach “oben”):

define SCC1 CUL /dev/ttyAMA0@38400 1234
attr SCC1 alias SCC1 MAX
attr SCC1 group CUL
attr SCC1 rfmode MAX
attr SCC1 room Technik
 
define SCC2 STACKABLE_CC SCC1
attr SCC2 alias SCC2 433Mhz SlowRF
attr SCC2 group CUL
attr SCC2 rfmode SlowRF
attr SCC2 room Technik
 
define SCC3 STACKABLE_CC SCC2
attr SCC3 alias SCC3 868Mhz SlowRF
attr SCC3 group CUL
attr SCC3 rfmode SlowRF
attr SCC3 room Technik

Wenn man genau runterliest, stellt man fest, dass der erste SCC als CUL eingebunden wird. Die weiteren werden dann mit dem Modul STACKABLE_CC eingebunden.

Übrigens: Das blinken kann man den SCCs ebenfalls wie beim CUL mittels set SCC1 led 00 (als Beispiel für SCC1) abgewöhnen

apt-get install avrdude

Nun muss man zunächst einen Seriellen Port freimachen. Dazu muss man zunächst /etc/inittab editieren und die folgenden Zeilen mit einem Kommentar versehen:

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Sodass diese so aussieht:

# T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Anschließend muss man alle Einträge mit ttyAMA0 aus der Datei /boot/cmdline.txt entfernen. Meine Zeile sah vorher so aus:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Und danach dann so:

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Jetzt einmal rebooten und nach dem Boot wieder zu User “root” wechseln! Anschließend sollte man FHEM erstmal stoppen:

/etc/init.d/fhem stop

wget "http://culfw.svn.sourceforge.net/viewvc/culfw/trunk/culfw/Devices/COC/COC.radio_only.hex?revision=HEAD" -O COC.radio_only.hex

Nun muss man den COC mit ein paar Kommandos ansteuern um den Bootloader anzusprechen:

echo "calling COC bootloader..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 0 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio18/value

Und nun wird die Firmware geflashed (Achtung Dateiname am Ende bei dem anderen Gerätetyp tauschen!):

avrdude -p atmega1284p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:COC.radio_only.hex

Dies sieht wie folgt aus:

COC-Firmware

Abschließend muss man nun noch die Datei /etc/init.d/fhem ein wenig abändern. Suche:

start)

Ersetze durch:

start)
	echo "resetting 868MHz extension..."
	if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
	if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
	echo out > /sys/class/gpio/gpio17/direction
	echo out > /sys/class/gpio/gpio18/direction
	echo 1 > /sys/class/gpio/gpio18/value
	echo 0 > /sys/class/gpio/gpio17/value
	sleep 1
	echo 1 > /sys/class/gpio/gpio17/value
	sleep 1

Raspberry Pi Model A: max. 2,5W (5V, 500 mA)
Raspberry Pi Model B: max. 3,5W (5V, 700mA)

Ich habe gerade mal nachgemessen: Beim hochfahren hatte er ~3,2W verbraucht, danach ist er nun bei ~2,8W. Das macht dann übers Jahr rund 25kW, was ich in Ordnung finde:

Raspberry Pi Stromverbrauch

Hier ein paar Fotos des aktuellen COC von Busware. Hier habe ich beschrieben wie man diesem initialisiert, um ihn mit FHEM nutzen zu können.

Dann muss man nur noch ein Bild auswählen. Führt man dies für beide Schaltzustände durch, so sieht dann das Attribut devStateIcon beispielsweise so aus:

Ein paar weiterführende Details (wie z.B. die Beeinflussung der Farbe bei SVG-Dateien) finden sich hier im Wiki. Bei mir sieht es in der fhem.cfg dann so aus:

# Fensterkontakt
define Fensterkontakt.Kueche MAX ShutterContact 07131f
attr Fensterkontakt.Kueche icon signal_Fenster_Offen.off
attr Fensterkontakt.Kueche room Kueche
attr Fensterkontakt.Kueche devStateIcon closed:signal_Fenster_Offen.off opened:signal_Fenster_Offen.on

update check

eingeben. Das gibt dann eine Liste der letzten Änderungen (die zwischen Versionen wie beispielsweise 5.3 und 5.4 durchgeführt wurden) aus. Für die meisten Fälle reicht es aus dann ein:

update

shutdown restart

Damit ist das Update abgeschlossen. Bitte auf jeden Fall die commandref zum Update einmal lesen, bevor man es durchführt!

tail -f /var/log/syslog

Nun steckt man den CUL in den USB-Port während dessen Button auf der Rückseite gedrückt gehalten wird (WICHTIG). In Konsole 1 sollte nun folgendes erscheinen:

Sep 17 17:51:20 raspberrypi kernel: [ 128.252140] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
Sep 17 17:51:20 raspberrypi kernel: [ 128.363000] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=2ff4
Sep 17 17:51:20 raspberrypi kernel: [ 128.363031] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 17 17:51:20 raspberrypi kernel: [ 128.363049] usb 1-1.2: Product: ATm32U4DFU
Sep 17 17:51:20 raspberrypi kernel: [ 128.363063] usb 1-1.2: Manufacturer: ATMEL
Sep 17 17:51:20 raspberrypi kernel: [ 128.363077] usb 1-1.2: SerialNumber: 1.0.0

In Konsole zwei kann man nun das folgende eingeben:

lsusb

Dabei kommt nun das folgende raus:

Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 03eb:2ff4 Atmel Corp.

Nun wird die Firmware installiert. Dazu wird diese zuerst heruntergeladen:

wget http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUL/CUL_V3.hex?format=raw -O CUL_V3.hex

Nun wird der CUL einmal gelöscht:

dfu-programmer atmega32u4 erase

Und neu geflashed:

dfu-programmer atmega32u4 flash CUL_V3.hex

Das sollte etwa so aussehen:

Validating…
18268 bytes used (63.71%)

Und danach wird der CUL zurückgesetzt:

dfu-programmer atmega32u4 reset

Jetzt etwas Geduld mitbringen, das dauert einen Moment. In der Konsole 1 müsste nach einiger Zeit folgendes auftauchen:

Sep 17 17:58:15 raspberrypi kernel: [ 542.796600] usb 1-1.2: USB disconnect, device number 4
Sep 17 17:58:16 raspberrypi kernel: [ 543.548331] usb 1-1.2: new full-speed USB device number 5 using dwc_otg
Sep 17 17:58:16 raspberrypi kernel: [ 543.660164] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=204b
Sep 17 17:58:16 raspberrypi kernel: [ 543.660197] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 17 17:58:16 raspberrypi kernel: [ 543.660214] usb 1-1.2: Product: CUL868
Sep 17 17:58:16 raspberrypi kernel: [ 543.660229] usb 1-1.2: Manufacturer: busware.de
Sep 17 17:58:16 raspberrypi kernel: [ 543.730877] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
Sep 17 17:58:16 raspberrypi kernel: [ 543.735526] usbcore: registered new interface driver cdc_acm
Sep 17 17:58:16 raspberrypi kernel: [ 543.735555] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Dann war das ganze erfolgreich. Jetzt kann man in FHEM mal das folgende Kommando absetzen:

usb scan

Das sieht dann so aus:

Jetzt kann man den CUL in FHEM einbinden.

So sieht das ganze dann physikalisch aus:

Wenn man diese dann stapelt, so setzt die der Steckerleiste gegenüberliegende Seite mit dem Kondensator auf der darunterliegenden Ebene auf. Dies stützt diese Seite dann. Was dann so aussieht:

Platziert man das ganze auf einem Raspberry PI, so setzt der Kondensator genau auf einem isolierten Punkt auf der Platine auf, sehr schön!

Auf den Bilder sind zwei 868 Mhz SCC und ein 433Mhz SCC zu sehen. Die angebrachten Antennen auf den letzten beiden Bilder sind die 868 Mhz +5dbi Antenne, 433Mhz

Definiert wird der SCC in der fhem.cfg wie folgt (von “unten” nach “oben”):

define SCC1 CUL /dev/ttyAMA0@38400 1234
attr SCC1 alias SCC1 MAX
attr SCC1 group CUL
attr SCC1 rfmode MAX
attr SCC1 room Technik
 
define SCC2 STACKABLE_CC SCC1
attr SCC2 alias SCC2 433Mhz SlowRF
attr SCC2 group CUL
attr SCC2 rfmode SlowRF
attr SCC2 room Technik
 
define SCC3 STACKABLE_CC SCC2
attr SCC3 alias SCC3 868Mhz SlowRF
attr SCC3 group CUL
attr SCC3 rfmode SlowRF
attr SCC3 room Technik

Wenn man genau runterliest, stellt man fest, dass der erste SCC als CUL eingebunden wird. Die weiteren werden dann mit dem Modul STACKABLE_CC eingebunden.

Übrigens: Das blinken kann man den SCCs ebenfalls wie beim CUL mittels set SCC1 led 00 (als Beispiel für SCC1) abgewöhnen

Heute habe ich meine ersten LW12 (Firmware Revision 4.02.11T.15) in mein Heimnetzwerk eingebunden. Wenn ihr nicht wisst, was das ist, dann schaut euch mal den Beitrag des Blogs “meintechblog.de” genauer an. Erwerben kann man diese Controller via Amazon oder Aliexpress (bei letzterem Vorsicht mit den Zollgrenzen bei der Einfuhr nach Deutschland). Mein konkretes Problem war die Einbindung des WLAN-Controllers in mein Heim-Netzwerk zur Steuerung mit FHEM. Mein Netzwerk hat eine Fritz!Box als Zentrale – leider wollte sich der Controller nicht damit verbinden.

Zunächst startet man diesen ganz normal und verbindet sich via des WLAN eines Notebooks, Tablets oder Smartphones darauf (SSID: LEDnetMAC-Addresse, also z.B. LEDnetACCF23318023 – das Password im Auslieferungszustand ist 88888888). Unter dem Default Gateway kann man dann die IP des kleinen Controllers sehen – meist ist es die 10.10.123.2. Verbindet man sich darauf via HTTP so meldet sich eine unkomplizierte Oberfläche zur Konfiguration des Controllers nach Eingabe der Benutzer/Passwordkombination admin/nimda.

Erster Klick: Rechts oben auf “English” – ausser ihr seid in Fremdsprachen gerüstet

LW-12 Interface

Wechsle dann zu “AP Interface Setting” (AP = Access Point). Dort kannst du den Namen des Access Points von MAC-Addresse auf einen eigenen Namen umstellen, z.B. LEDStripController1. Gleichzeitig kann man dort auch dass Passwort des WLAN ändern. Später würde ich das WLAN dann auch verstecken, denn das WLAN des Controllers wird immer aufgebaut – egal ob man es mit einem eigenen WLAN verbunden hat oder nicht. Leider wird es auch immer auf dem gleichen Kanal wie das eigene WLAN aufgebaut – egal was man in diesem Interface einstellt.

LW-12: AP Interface Setting

Wechsle dann zu “STA Interface Setting” (STA = Station). Dort kann man die Einbindung in ein eigenes WLAN einstellen. Clicke zunächst auf “Search” um das eigene WLAN zu finden. Dann trage unter “Pass Phrase” das Kennwort deines WLANs ein. Wichtig: Als Encryption Type muss AES eingestellt werden, ansonsten kann sich der Controller seltsamerweise nicht in das WLAN verbinden! Ich habe auch gleich den Hostname des Controllers umgestellt, damit er leichter erkennbar ist.

LW-12: STA Interface Settings

Unter “Application Setting” habe ich keine Änderungen vorgenommen – besser Finger weg

LW-12: Application Settings

Unter “Device Management” kann man nun das Password des Webinterfaces einstellen. Wenn das gemacht ist, einmal den Controller durchstarten.

LW-12: Device Management

Nun ist der Controller im eigenen WLAN. Die App des LED Strips (Android / iOS) geht nun natürlich genauso wie im originalen WLAN – nur dass dein Handy nicht mehr von der Aussenwelt abgeschnitten ist, wenn man es im WLAN des Controllers betreibt. Aber wirklich genial ist ja die Einbindung über FHEM via des Moduls WifiLight.

Soeben hatte ich bei einer Entwicklung das Problem, dass ich nach jeder Änderung ein Cache-Directory löschen musste…nach einer Weile ging es mir auf den Keks und ich habe mich auf die Suche nach einer praktischen Lösung gemacht. Dabei bin ich hier auf die inotify-tools gestossen.

Installiert wird das unter debian mittels:

apt-get install inotify-tools

Und so wird es verwendet:

inotifywait -r -m /var/www/pages -e create -e modify |
    while read path action file; do
        rm -Rf /var/www/temp/*;
        echo "Cleaned Temp";
    done

Vorsicht an dieser Stelle: Immer drüber nachdenken was genau man löscht und was man erzielen will. Wenn man im obigen Beispiel z.b. /var/www überwacht, braucht man sich nicht zu wundern, dass Temp immer leer ist Temporäre Dateien sind dann natürlich auch auslöser

© 2005-2014 by Uli Wolf - This Content is distributed under the Creative Commons License
This feed is for personal, non-commercial use only.
The use of this feed on other websites without attribution to the author and notification of the author breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint: d2a576b5311479d89eff39b7ca886f6b)

Vor einigen Tagen habe ich meinen Raspberry Typ B mit meiner FHEM Installation auf den Raspberry 2 Typ B umgezogen. Ich wollte jedoch nicht alles neu installieren und habe mich dafür entschieden meine bisherige microSD-Karte – dort ist Raspbian installiert – weiter zu verwenden.

Damit das Raspbian unter dem Raspberry 2 startet, muss das Verzeichnis /boot aktualisiert werden. Folgende zwei Dateien sind für die Kompatibilität verantwortlich:

kernel7.img (Kernel für ARM v7 Prozessoren)
bcm2709-rpi-2-b.dtb (Device Tree Blob des Raspberry 2)

Um diese zu erhalten musste folgende Schritte auf dem “alten” Raspberry Typ B als root durchführen:

apt-get update
apt-get upgrade
rpi-update

Hat man Raspbian mittels NOOBs installiert, sollte man diesem Link noch folgen.

Wie man aus diesem Blog entnehmen kann, habe ich drei Busware SCC im Einsatz und schon mal mit dem COC von Busware herumgespielt (letzteren habe ich an einen Kollegen verkauft). Für Details (was sich dahinter verbirgt) bitte ich in die Beiträge abzuspringen.

Nach meinem Umzug auf den Raspberry 2 Typ B von einem Raspberry Typ B kann ich nun vermelden, dass die SCCs 100% kompatibel sind. Zudem konnte mein Kumpel bestätigen, dass auch der COC nach dem Umzug noch einwandfrei funktioniert.

Wichtig war für mich vor allem, dass ich an meiner Raspbian Installation so wenig wie möglich ändern muss. Das war ausser einem Update der Dateien in /boot auch der Fall. Vielleicht hilft es ja jemandem bei der Kaufentscheidung

Installation des Busware COC auf dem Raspberry Pi für die Nutzung mit FHEM

Related posts:

Stromverbrauch des Raspberry Pi

Related posts:

Bilder des Busware COC für den Raspberry PI

Related posts:

Extend devStateIcon in FHEM kurz erläutert

Related posts:

FHEM update – Wie funktionieren Updates für Fehlerkorrekturen in FHEM?

Related posts:

FHEM: Making of CUL V3

Related posts:

Busware CUL_V3 / CUL V3.4 mit CULFW flashen

Related posts:

Verwendung des SCC in FHEM als Alternative zum CUL

Related posts:

Installation des Busware COC auf dem Raspberry Pi für die Nutzung mit FHEM

Related posts:

Stromverbrauch des Raspberry Pi

Related posts:

Bilder des Busware COC für den Raspberry PI

Related posts:

Extend devStateIcon in FHEM kurz erläutert

Related posts:

FHEM update – Wie funktionieren Updates für Fehlerkorrekturen in FHEM?

Related posts:

FHEM: Making of CUL V3

Related posts:

Busware CUL_V3 / CUL V3.4 mit CULFW flashen

Related posts:

Verwendung des SCC in FHEM als Alternative zum CUL

Related posts:

Einbindung des LW12 in das eigene WLAN – speziell einer Fritz!Box

Related posts:

Inotify-tools – Reaktion auf Dateiänderungen

Related posts:

Umzug von Raspbian von Raspberry Typ B auf Raspberry 2 Typ B

Related posts:

Kompatibilität des Busware SCC und COC zum Raspberry 2 Typ B

Related posts: