Schlagwort: Hardware

Meine openHAB Hardware

Raspberry Pi:

HomeMatic:

Xiaomi:

Stromzähler:

FS20:

Feinstaub:

Router und Access Points:

  1. Amazon Affiliate Link. Bei Bestellung erhalten wir ein paar Cent Provision. Wichtig: Am Preis auf Amazon ändert sich für Dich nichts! Es handelt sich lediglich um einen Bonus, den uns Amazon für die Empfehlung gut schreibt. ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩
  2. GearBest Affiliate Link. Bei Bestellung erhalten wir ein paar Cent Provision. Wichtig: Am Preis auf GearBest ändert sich für Dich nichts! Es handelt sich lediglich um einen Bonus, den uns GearBest für die Empfehlung gut schreibt. ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩

FRITZ!Box Gast WLAN richtig mit einem TP-Link Router als Repeater verstärken

Schlimmer Titel des Beitrags, aber das ist noch vereinfacht. ;-) Was nämlich erreicht werden soll, ist folgendes:

  • Der FRITZ!Box WLAN-Gastzugang soll über einen WLAN-Repeater auch ausgestrahlt werden
  • Clients, die sich mit dem Repeater verbinden, sollen im Gastnetzbereich der FRITZ!Box landen, nicht im Heimnetz (dem „normalen“ LAN). Also wie, wenn sie sich direkt mit dem Gastnetz der FRITZ!Box verbinden würden.
  • Als Repeater kommt kein AVM-Repeater zum Einsatz sondern ein Router von TP-Link mit DD-WRT (in meinem Fall aktuell diese Version vom 9. April 2015, ich werde aber natürlich nach Verfassen dieses Beitrags regelmäßig aktualisieren, v.a., wenn die für mein Modell relevanten Bugs gefixt wurden). Ich setze den TP-Link v.a. wegen der Reichweite ein, aber auch deswegen, weil ich 2.4 GHz und 5 GHz haben möchte.

Gerade der zweite Punkt bereitet erst einmal Schwierigkeiten. Hier müssen AVM und TP-Link sinnvoll und optimal miteinander verheiratet werden. Halbe Sachen funktionieren leider auch nur halb. Das habe ich ein halbes Jahr beobachten dürfen.

Gelungen ist mir das dann mit viel Recherche im Internet und einem VLAN-fähigen Switch. Allerdings sollte es auch ohne diesen gehen, wenn man die FRITZ!Box und den TP-Link Router mit zwei seperaten Netzwerkkabeln verbindet, beispielsweise auf LAN 1 der Fritzbox das „normale“ Netz und auf LAN 4 das Gastnetz. Probiert habe ich das allerdings nicht, dachte aber, ich hätte bei Google Artikel zu dieser Konfiguration gesehen. Auch hier muss am TP-Link einiges konfiguriert werden.

Eingesetzte Hardware bei mir:

Kurzer Exkurs zu den beiden TP-Link Produkten: Wie schon erwähnt wollte ich beim Repeater eine größere Reichweite wie bei den klassischen Repeatern, die es von AVM gibt, z.B. AVM FRITZ!WLAN Repeater 310 N-Standard 2.4 GHz1, AVM FRITZ!WLAN Repeater 450E N-Standard 2.4 GHz1, AVM FRITZ!WLAN Repeater 1750E AC-/N-Standard 2.4/5 GHz1). Des Weiteren neben 2.4 GHz eben auch 5 GHz, was bei den klassischen Repeater Produkten dann schon teuer wird. Bei fertigen Repeater-Produkten von anderen Herstellern hat man einen preislichen Vorteil, büßt aber (meist) das Gäste-WLAN ein. Daher der TP-Link TL-WDR4300, der preislich und mit DD-WRT optimal für meine Zwecke ist. Strom braucht er auch kaum mehr als einer der kleinen Repeater Boxen. Der Switch ist mit 24 Ports (ich brauche tatsächlich mehr als 16 Ports…) recht günstig, v.a., da er managebar ist und neben LACP auch VLANs kann und eine sehr gute Netzwerkperformance bietet. Mein alter 16 Port von Netgear war defekt, sodass eh Ersatz her musste. Auch ist der Stromverbrauch sehr gut und mehr als angemessen.

Hinweis: Für die meisten Anwendungsfälle reichen natürlich die o.g. Repeater von AVM – ich wollte es halt perfekt haben und muss auch eine sehr dicke Mauer eines 110 Jahre alten Gebäudes überwinden und möchte eben nun einmal HD im Garten streamen können. ;-)

Ich habe folgende Howtos zur Vorlage genommen:

Auf die Installation von OpenWRT auf dem Router gehe ich nun nicht speziell ein. Ich gehe davon aus, dass dies bereits geschehen ist und dort 4 WLAN Karten virtuell erzeugt wurden, die jeweils das „normale“ WLAN mit 2.4 und 5 GHz und einmal das Gäste-WLAN, auch mit 2.4 und 5 GHz, ausstrahlen. Als Namen und Passwört der Netzwerke sowie auch die Verschlüsselungseinstellungen müssen exakt die gleichen Einstellungen gewählt werden wie auf der Fritzbox.

Nun also soll der Repeater mittels VLAN zweimal mit der Fritzbox verheiratet werden. Am Switch müssen zwei Ports für die Fritzbox vorbereitet werden. Zuerst einmal VLAN 6 erzeugen. Dann soll der erste Port das Standard VLAN („Default VLAN“) haben – das sollte schon so sein. Den zweiten Port so konfigurieren, dass hier nur das VLAN 6 aktiv ist. Dann auf der Fritzbox für den LAN 4 das Gäste-Netz aktivieren. Nun LAN 1 der Fritzbox auf den ersten vorbereiteten Switchport stecken, LAN 4 auf den zweiten vorbereiteten Switchport.

Den Repeater auf einen dritten Port des Switches stecken und für diesen beide VLANs einstellen. Hier ist zu beachten, dass der Repeater das default VLAN 1 ungetagged sendet, das weitere VLAN 6 aber tagged senden wird. Auf dem von mir eingesetzten Switch ist die richtige Einstellung für diesen einen Port GENERAL, und die Egress Rule Einstellung für VLAN 1 ist UNTAG und für VLAN 6 TAG. Ist dies nicht korrekt gesetzt, wird nichts so funktionieren, wie es soll. Sehr wichtiger Punkt! ;-)

So, alles soweit vorbereitet. Auf dem Repeater muss im DD-WRT nun unter Administration / Commands noch folgendes als Startscript eingetragen und mit Save Startup gespeichert werden:

swconfig dev eth0 set enable_vlan 6
swconfig dev eth0 vlan 6 set ports "0t 2t"
swconfig dev eth0 set apply
vconfig add eth0 6
brctl delif br0 ath0.1
brctl delif br0 ath1.1
brctl addbr br6
brctl addif br6 vlan6
brctl addif br6 ath0.1
brctl addif br6 ath1.1
ifconfig br6 up
ifconfig ath0.1 up
ifconfig ath1.1 up
ifconfig vlan6 up

So bringt man ath0.1 (2.4 GHz Gast-WLAN) und ath1.1 (5 GHz Gast-WLAN) ausschließlich auf VLAN 6 sowie die eth0 Schnittstelle zusätzlich auf VLAN 6. mit brctl show kann nach einem Reboot des Repeaters auch der Erfolg überprüft werden. Leider kann man über die Weboverfläche diese Änderungen nicht „klicken“, sodass der Umweg über das Startscript gemacht werden muss.

Nun sollte alles klappen. Benutzer des Gäste-WLANs auf dem Repeater werden zur Vergabe der IP-Adresse sowie zum Surfen im Internet über VLAN 6 an die Fritzbox geleitet und erfahren die gleichen Einschränkungen/Einstellungen wie die Gäste-WLAN Benutzer, die sich bei der Fritzbox direkt einloggen.

  1. Amazon Affiliate Link. Bei Bestellung erhalten wir ein paar Cent Provision. Wichtig: Am Preis auf Amazon ändert sich für Dich nichts! Es handelt sich lediglich um einen Bonus, den uns Amazon für die Empfehlung gut schreibt. ↩ ↩ ↩ ↩ ↩ ↩

Postfix als Mailrelay auf dem Raspberry Pi

Ein „richtiger“ Mailserver kann auf dem Raspberry Pi nicht schaden. Z.B. um Mails an root zu erhalten oder um laufenden Diensten und Scripts zu ermöglichen, Mails zu versenden. Ein Mailrelay Server reicht zumindest in meinem Fall absolut aus. Heißt, dass Mails vom Server aufgenommen und an einen „echten“ Mailserver weitergeleitet werden. Hier wird die gleiche Technologie verwendet wie beim Versand von Mails von einem Mailclient.

Dieser Beitrag bezieht sich auf Raspbian, kann aber z.B. auch fast ohne Änderung für Debian und somit nicht nur auf dem Raspberry Pi angewendet werden. IPv6 betrachte ich auch hier erst einmal nicht, obwohl fast alle meine Devices und Dienste auch auf IPv6 laufen, auch unsere Hot-Chilli Server. Alle Howtos zu openHAB beziehen sich auf IPv4, von daher schaue ich erst einmal, dass alles auf IPv4 läuft.

sudo apt-get install postfix mailutils

No configuration auswählen.

Standardkonfigurationsdatei kopieren, damit diese angepasst werden kann:

cp /usr/share/postfix/main.cf.debian /etc/postfix/main.cf

Nun in die /etc/postfix/main.cf unter die vorhandenen Einträge folgendes eintragen:

inet_protocols = ipv4
relayhost = mail.domain.tld:submission
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_tls_enforce_peername = no
smtp_sasl_security_options = noanonymous
myhostname = raspberrypi.$mydomain
mydomain = domain.tld
append_dot_mydomain = yes

myhostname eventuell anpassen und für mydomain am besten etwas sinnvolles einfallen lassen – eventuell steht ja eine eigene Domain zur Verfügung.

Da der Raspberry Pi momentan nur auf IPv4 läuft, muss die erste Zeile rein. Sonst gibt es Fehlermeldung ohne Ende. Die weiteren Zeilen weisen Postfix an, sich auf Port 587 (Submission) TLS-verschlüsselt auf den dort angegebenen Mailserver zu verbinden. Dieser muss natürlich auf die eigenen Bedürfnisse angepasst werden. Der passende Benutzername und das Passwort kommen aus /etc/postfix/sasl_passwd:

mail.domain.tld user@domain.tld:mailpasswort

Nun muss diese Datei noch für Postfix lesbar gemacht werden:

cd /etc/postfix
sudo postmap sasl_passwd

Dem System teilen wir nun mit, wo die Systembenutzer root und pi per Mail zu erreichen sind. So bekommen wir die Mails mit Postfix auf externe Mailaccounts zugestellt. Dazu tragen wir in /etc/aliases folgendes ein:

pi: root
root: user@domain.tld

Auch diese Datei muss für Postfix lesbar gemacht werden:

cd /etc
sudo postalias aliases

Nun noch Postfix neu starten:

sudo /etc/init.d/postfix restart

LAN und WLAN am Raspberry Pi

Betreibt man auf dem Raspberry Pi einen serverartigen Dienst (z.B. openHAB oder auch so etwas wie Kodi/XBMC) dann wäre es doch praktisch, wenn der Raspberry Pi auf jeden Fall eine feste IP-Adresse hätte. So geht nie etwas schief, egal ob der DHCP-Server verfügbar ist, ob man dort eine Reservierung eingetragen hat oder oder oder… Außerdem ist es teilweise auch ausreichend, den Raspberry Pi über WLAN statt LAN zu betreiben. Bei openHAB ist es ausreichend, in anderen Fällen muss es eventuell auch ausreichend sein, wenn der Standort beispielsweise nicht über LAN-Kabel angefahren werden kann. Investieren muss man zwischen 5 und 10 € für einen kleinen WLAN-Stick, ist also überschaubar.

Dieser Beitrag bezieht sich auf Raspbian, kann aber z.B. auch fast ohne Änderung für Debian und somit nicht nur auf dem Raspberry Pi angewendet werden. IPv6 betrachte ich erst einmal nicht, obwohl fast alle meine Devices und Dienste auch auf IPv6 laufen, auch unsere Hot-Chilli Server. Alle Howtos zu openHAB beziehen sich auf IPv4, von daher schaue ich erst einmal, dass alles auf IPv4 läuft. Ich gehe außerdem von einem WPA2-CCMP geschützten WLAN-Netz aus.

Folgendes in die /etc/network/interfaces eintragen, die ursprüngliche Datei also ersetzen:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1

auto wlan0
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.0.3
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

In /etc/wpa_supplicant/wpa_supplicant.conf am Ende folgendes einfügen:

network={
ssid="WLAN-SSID/Kennung"
psk="WLAN-Schlüssel"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
}

lo ist für das Loopback Interface, nicht verändern. eth0 ist für LAN, der Part wlan0 ist für WLAN. In beiden Dateien müssen natürlich die passenden Netzwerkparameter, also IP-Adresse, Subnetzmaske, Broadcast, Gateway und v.a. WLAN-Parameter eingetragen werden. wireless-power off schaltet die Energiesparfunktion ab und funktioniert mit vielen Netzwerkkarten und kann im Vorfeld mit sudo iwconfig wlan0 power off geprüft werden. Funktioniert das nicht, wird es aufwändiger, die Energiesparfunktion abzuschalten, siehe hier.

Ein WLAN-Stick, mit dem bei mir wunderbar funktioniert, ist der EDIMAX EW-7811UN1. Ansonsten mal nach einem Stick mit dem Ralink RT5370 Chipsatz schauen. Es gehen aber auch viele andere Chipsätze.

Ach ja, ein Blick in die /etc/resolv.conf sollte zumindest folgender Eintrag stehen:

nameserver 192.168.0.1

Das ist der DNS-Servers des Netzes. Eventuell muss dies wie auch oben angepasst werden.

  1. Amazon Affiliate Link. Bei Bestellung erhalten wir ein paar Cent Provision. Wichtig: Am Preis auf Amazon ändert sich für Dich nichts! Es handelt sich lediglich um einen Bonus, den uns Amazon für die Empfehlung gut schreibt. ↩

Realtime Clock (RTC) am Raspberry Pi betreiben

Da ich im Moment dabei bin, ein Home Automation System auf Basis eines Raspberry Pi 21 und openHAB aufzubauen, werde ich hier im Blog hin und wieder einzelne Schritte beschreiben. V.a., wenn ich selbst im Netz gar nichts, wenig oder veraltete Infos gefunden habe. Vermutlich werde ich auch noch eine Übersichtsseite hier erstellen, die auf die Blogbeiträge verlinken. Aber eines nach dem anderen… Zur (aktuellen) Sache:

Da ich den Raspberry Pi auch verwenden werde um Stromausfall per SMS zu melden (zur USV und dem UMTS Stick beizeiten an anderer Stelle mehr) dachte ich mir, dass ein Realtime Clock (RTC) Modul nicht schaden könnte. Fällt nämlich der Strom aus und der Raspberry fährt herunter, ist die Uhrzeit weg. Beim Neustart wird die Uhrzeit aus dem Internet per NTP auf die aktuelle Zeit gesetzt. Kein Internet, keine korrekte Uhrzeit, dadurch eventuell SMS Nachrichten mit „komischem“ Inhalt.

Die Hardware, also die kleine RTC DS1307 Platine, kostet übrigens um die 2 € und ist z.B. bei Amazon1 erhältlich. Auf jeden Fall beachten, dass keine „normale“ Batterie sondern eine wiederaufladbare LIR2032 Lithium-Batterie mitgeliefert wird und es diese auch tatsächlich ist!

Bin nach folgenden beiden Anleitungen vorgegangen:

Im ersten Tutorial ist ganz gut beschrieben, wie die Hardware umzulöten ist (keine Angst, das kriegt jeder mit jedem Lötkolben hin, ist aber wichtig und unumgänglich) und wie diese an den Raspberry Pi anzuschließen ist. Hier zwei Fotos der umgelöteten Platine. Auf dem zweiten Bild sieht man, wo die beiden Widerstände entfernt werden müssen und wo die vier Pins angelötet werden müssen.

RTC DS1307 Platine

RTC DS1307 Platine

Verkabelt wird das auf dem Raspberry Pi dann so:

#--------------------#
| RPi GPIO  | RTC P1 |
|-----------|--------|
|Pin 2 5V   |   VCC  |
|Pin 3 SDA  |   SDA  |
|Pin 5 SCL  |   SCL  |
|Pin 6 GND  |   GND  |
#--------------------#

Leider sind die beiden Anleitungen nicht mehr ganz aktuell was den Softwareteil anbelangt. Hier daher kurz zusammengefasst, was ich beim Raspberry Pi 2 und dem Raspbian Image vom Februar 2015 machen musste:

In der Raspberry Config unter „Advanced Options“, „A7 I2C Enable/Disable automatic loading of I2C kernel module“ das I2C aktivieren:

sudo raspi-config

Die I2C Tools installieren:

sudo apt-get install i2c-tools

Zum Test und zur Einrichtung die noch nötigen Module laden:

sudo modprobe i2c_dev
sudo modprobe rtc_ds1307

Nun sollte hier in einer Tabelle irgendwo eine „68“ auftauchen:

i2cdetect -y 1

Hiermit kann man sich die aktuell gesetzten Stunden, Minuten und Sekunden sehen:

i2cget -y 1 0x68 0
i2cget -y 1 0x68 1
i2cget -y 1 0x68 2

Virtuelle Datei für die Uhr anlegen:

echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device

Aktuelle Uhrzeit aus der Uhr auslesen:

sudo hwclock -r

Systemzeit in die Uhr speichern (bei mir stimmte sie bei Ersteinrichtung natürlich absolut überhaut nicht):

sudo hwclock -w

Ok, klappt also alles. Nun soll das ganze Thema ja auch dauerhaft nach Systemstart am Start sein.

Dazu in /etc/modules folgende Module hinzufügen:

i2c_dev
rtc_ds1307

In /etc/rc.local kommt vor exit 0 folgendes:

# RTC Uhr einbinden und Systemzeit aus RTC beim Start setzen
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
sudo hwclock -s

Zusätzlich wollen wir, dass die genaue Systemzeit (wird im Normalfall ja per NTP permanent aktualisiert) beim Shutdown in die Uhr gespeichert wird.

/etc/init.d/hwclock_w mit folgendem Inhalt erstellen:

#!/bin/sh
### BEGIN INIT INFO
# Provides: hwclock_w
# Required-Start: $local_fs $remote_fs $network
# Required-Stop: $local_fs $remote_fs $network
# Default-Start:
# Default-Stop: 0 1 6
# Short-Description: RTC Clock mit Systemzeit setzen beim Shutdown
### END INIT INFO

hwclock -w

Das Script soll bei den entsprechenden Shutdown- und Restart-Runlevels ausgeführt werden. Das erreichen wir damit:

update-rc.d hwclock_w defaults

Fertig!

Nun kann man das Thema noch testen indem man den Raspberry Pi runterfährt, ein Weilchen ausgeschaltet lässt und ohne Internet wieder startet. Dann mit date und auch sudo hwclock -r die aktuelle Uhrzeit anzeigen lassen.

Zeitbedarf hielt sich sehr in Grenzen. Mit Löterei und Recherche, warum es nicht auf Anhieb mit o.g. Anleitungen tat, eine Stunde.

  1. Amazon Affiliate Link. Bei Bestellung erhalten wir ein paar Cent Provision. Wichtig: Am Preis auf Amazon ändert sich für Dich nichts! Es handelt sich lediglich um einen Bonus, den uns Amazon für die Empfehlung gut schreibt. ↩ ↩

Ladegeräte und Ladekabel

Eigentlich peinlich, aber mir ist erst vor kurzer Zeit aufgefallen, dass es beim Laden von Geräten, konkret Geräte, die per USB geladen werden wie Smartphones oder Tablets, nicht nur auf das Ladegerät ankommt sondern auch ganz genau so sehr auf das Kabel. Der Effekt fällt einem dann auf, wenn man neben dem mitgelieferten Ladegerät und Ladekabel etwas anders verwenden möchte. Einen Mehrfachlader z.B. oder ein längeres Kabel.

Hat man also ein Ladegerät, das 2.1A bringt, aber ein „normales“ Micro-USB Kabel, kommen eventuell nur 0.5-1.0A an, teilweise sogar weniger, so das Kabel von ebay und direkt aus China ist. Da dauert dann das Laden eines Tablets oder Smartphones nicht 1-4 Stunden sondern bis zu 10 Stunden… Oder das Smartphone entlädt sich im Auto trotz angeschlossener Stromquelle schneller als es aufgeladen wird. Das ist mir mit laufender Navi-App und eingeschaltetem Display massiv passiert.

Habe viel rumprobiert und fast ebenso wieder zurückgeschickt, hier Hardware, die es bei mir dann geworden ist. Kleiner Hinweis noch: Der AWG Wert wäre hier etwas, was einem verlässlich Auskunft geben kann über die Fähigkeit des Kabels – leider bei vielen Produkten bei ebay oder Amazon nicht angegeben oder die Angabe brachte nicht die Leistung, die ich erwartet habe. Ich verwende zur Zeit die 1.8m und 3.0m Kabel, das 4fach Ladegerät von Anker (bis dahin das China Ladegerät, das ehrlich gesagt genau so schnell läft, eventuell aber etwas minderwertiger ist von der Ladeelektronik) und das TomTom Ladegerät für’s Auto.

Spannend, dass bei den Ankerkabeln kein AWG Wert zu finden war, aber der Hinweis, dass es die besten Ladeprodukte bei Amazon sind. Und dem ist auch so, kosten nicht einmal mehr wie der Mitanbieter.

  1. Amazon Affiliate Link. Bei Bestellung erhalten wir ein paar Cent Provision. Wichtig: Am Preis auf Amazon ändert sich für Dich nichts! Es handelt sich lediglich um einen Bonus, den uns Amazon für die Empfehlung gut schreibt. ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩ ↩

Wunderbar

Super Sache, dieser Baukasten von Wunderbar, zumindest macht die Vorstellung hier im Video (erstes Thema) echt Lust auf mehr:

heise show @ CeBIT 2015 (Tag 5): Wunderbar, barrierefreier Nahverkehr, IT-Sicherheit, Fazit

Wenn sich das nun auch in openHAB integrieren lässt – irgendwann in naher Zukunft… Auf jeden Fall werde ich das weiter beobachten.

Deutsche Mi Fit App für das Mi Band

Nachdem die offizielle App von Xiaomi für den Fitnesstracker Mi Band1 leider nur in englischer Sprache (was nicht so schlimm wäre), aber in weiten Teilen eben auf Chinesisch vorliegt, sind folgende beiden Links zu einer getweakten deutschen Version für Android sicherlich nicht uninteressant.

Thread über die App im decuro Forum
Direkter Download der App bei chillzz.net

Nachteil: Updates müssen von Hand eingespielt werden (wobei bei mir eine ältere Version installiert war und das Update via Google Play Store eh nicht geklappt hatte…). Des Weiteren hat die App eine andere Signatur, sodass zuerst die Einstellungen gesichert werden müssen, die offizielle App deinstalliert und dann die neue App installiert werden muss. Alles aber hinnehmbar finde ich.

  1. Amazon Affiliate Link. Bei Bestellung erhalten wir ein paar Cent Provision. Wichtig: Am Preis auf Amazon ändert sich für Dich nichts! Es handelt sich lediglich um einen Bonus, den uns Amazon für die Empfehlung gut schreibt. ↩