Text mit SVOX Pico TTS direkt von der Kommandozeile oder aus einer Datei durch Sprachausgabe wiedergeben

Eine relativ einfache Möglichkeit um auf dem Raspberry Pi einen einfachen Text per Sprachausgabe (TTS) wiederzugeben, kann durch den Sprachsynthesizer pico2wave realisiert werden. Dieser verwendet zur Spracherzeugung „Hidden Markov Model“ (HMM) Algorithmen. Diese TTS-Engine ist Open-Source und hat eine relativ gute Sprachqualität.

Installation unter Raspbian

Leider ist die Installation auf dem Raspberry Pi etwas umständlich, da das Programm erst kompiliert werden muss. Es gibt im Internet aber gute Anleitungen und auch fertige (inoffizielle) Debian-Pakete, die einfach heruntergeladen und installiert werden können.

Empfehlen kann ich folgende Links:

Pico TTS ausführen

Um einen einfachen Text über die Komandozeile per Spracheausgabe wiederzugeben, kann z. B. so realisiert werden.

pico2wave --lang=de-DE --wave=/tmp/test.wav "Guten Morgen"; aplay /tmp/test.wav; rm /tmp/test.wav

Text aus Datei wiedergeben

Es ist auch möglich den Text aus einer Textdatei (max. 35kb) auszulesen und danach wiederzugeben.
Hierzu kann z. B. dieses kleines Script verwendet werden:

#!/bin/bash
language="en-US"
tmpFile="/tmp/picoTmpAudio.wav"
text=""

if [ $# == 1 ]; then
	 text="${1}"
else
   language="${1}"
   text="${2}"   
fi

pico2wave -l=${language} -w=${tmpFile} "`cat ${text}`"
aplay ${tmpFile}
rm ${tmpFile}

Um das Script ausführen zu können, muss dies zuerst durch folgenden Befehl ausführbar gemacht werden.

chmod +x picoTTSFromFile.sh

Es muss der Pfad zur entsprechenden Datei als Parameter angegben werden.
Optional kann auch die verwendete Sprache angepasst werden.

./picoTTSFromFile.sh text_en.txt
./picoTTSFromFile.sh de-DE text_de.txt

Source

Das Script und Beispieldateien habe ich zusätzlich auf GitHub bereitgestellt.
GitHub: SVOX Pico TTS – Read text from file

Bildschirmhelligkeit bei Samsung Netbook unter Windows 10 einstellen (adjust screen brightness – Intel GMA 3150)

Die Freude war groß, als ich endlich Microsoft Windows 10 auf meinem Samsung N220 Plus Netbook installieren konnte. Doch sie währte nicht lange, da ich leider einige Treiberprobleme feststellen musste.
Die meisten Probleme waren aber schnell durch eine manuelle Installation behoben.

Da ich keinen Windows 10 Treiber für den verbauten Grafikchip „Intel Graphics Media Accelerator (GMA) 3150“ finden konnte, muss der aktuelle Treiber für Microsoft Windows 7 von der Intel Webseite installiert werden. Dieser scheint aber grundsätzlich zu funktionieren. Leider konnte aber die Helligkeit des Bildschirms nicht mehr verändert werden. Sowohl die Einstellung direkt in der Systemsteuerung, sowie über den „Samsung Easy Display-Manager“ funktionierte nicht.

Lösung

Die einzige Lösung die ich gefunden habe war eine Anpassung in der Registrierungsdatenbank von Windows.

Die Anpassung muss durch einen Benutzer mit Administratoren-Rechte durchgeführt werden.

1. Registrierungs-Editor öffnen
„Windows Taste + R“ drücken –> „regedit“ eingeben –> mit „OK“ bestätigen

2. Zu folgenden Pfad navigieren

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Class \
{4d36e968-E325-11CE-BFC1-08002BE10318} \ 0000

3. Eintrag „FeatureTestControl“ bearbeiten (Doppelklick)
oder als „DWORD-Wert“ erstellen, falls noch nicht vorhanden

4. Wert „FFFE“ als Hexadezimal eingeben und mit „OK“ bestätigen

5. Registrierungs-Editor schließen und Windows neu starten

Danach sollte die Helligkeit wieder angepasst werden können.

BIND DNS-Server unter Raspbian installieren und einrichten (Howto Anleitung)

Nachdem bei statischen IP’s der im Router integrierte Domain Name System (DNS)-Server die Namensauflösung verweigert, habe ich kurzerhand auf meinem Raspberry Pi einen eigenen DNS-Server installiert und eingerichtet.
Ich habe mich für den BIND Server entschieden, da dieser realtiv einfach unter Raspbian „Wheezy“ zu installieren und konfigurieren ist. Hinzu kommt, dass dieser DNS-Server mittlerweile ausgereift und relativ weit verbreitet ist.

Nachfolgend zeige ich die notwendigen Schritte, um BIND zu installieren und zu konfigurieren

Für intere Zonen im LAN wird dieser als autoritativer DNS-Server konfiguriert. Zusätzlich werden Forwarder (öffentliche DNS-Server) angegeben, um auch alle anderen Anfragen beantworten zu können. Somit ist er Router als DNS-Server eigentlich nicht mehr notwendig.

Installation

Zuerst muss BIND (aktuell in er Version 9) über das APT Paketmanagement-System durch folgenden Terminal-Befehl installiert werden.

sudo apt-get install bind9 bind9utils dnsutils

Die Pakete „bind9utils“ und „dnsutils“ sind zwar optional. Diese sollten aber trotzdem installiert werden, da dann verschiedene Programme für die Wartung, zum Testen oder zur Fehleranalsye einer BIND-Installation bereitstehen.

Nach der erfolgeichen Installation, sollte BIND automatisch gestartet werden.
Um zu prüfen ob der Server korrekt läuft, kann folgender Befehl verwendet werden.

dig @127.0.0.1 www.google.de

Hinweis: Das DNS Lookup Utility „dig“ wird vom Paket „dnsutils“ geliefert.

Läuft alles korrekt, sollte dann als Ausgabe u. a. die IP der angegeben Internetadresse erscheinen.

Konfiguration

Normalerweise sollte BIND unter „/etc/bind/“ installiert worden sein. Hier liegen dann auch die Konfigurationsdateien und Zonen-Dateien. Eine Anpassung der Konfiguration sollte aber nicht direkt in der Datei „/etc/bind/named.conf“ erfolgen. Diese importiert normalerweise nur weitere Dateien. Darunter auch die Dateien „named.conf.options“ und „named.conf.local“, die für die eigene Konfiguration und Zonen verwendet werden sollen.

Sollte die Datei „named.conf.local“ noch nicht existieren, kann diese wie folgt angelegt werden:

sudo touch /etc/bind/named.conf.local

Beispiel-Konfiguration

Kommen wir nur zur eigentlichen Einrichtung von eigenen Zonen und der Konfiguration von BIND.

Für ein einfaches Beispiel gehen wir von folgender lokalen Netzwerk-Topologie aus.

  • Netzwerk: 192.168.2.0/24
  • Subnetzmaske: 255.255.255.0
  • Broadcast-Adresse: 192.168.2.255
  • Gateways/Router: 192.168.2.1
  • Interner Server: 192.168.2.10
  • Raspberry (DNS-Server): 192.168.2.2
  • Hostname – Raspberry (DNS Servers): berry
  • DNS-Zone: berry.home

Hinweis:
Um später bei den Clients den eigenen DNS-Server eintragen zu können, sollte für den Raspberry Pi eine statische IP-Adresse eingerichtet werden.

Durch den eigenen DNS-Server soll folgendes erreicht werden:

1. Der „Interne Server“ mit der statischen IP „192.168.2.10“ soll unter „server.berry.home“ erreichbar sein.
2. Der „Raspberry Pi“ mit der statischen IP „192.168.2.2“ soll unter „berry.home“ erreichbar sein.
3. Zusätzlich ist auf dem Raspberry Pi ein HTTP-Webserver installiert. Dieser soll unter „www.berry.home“ erreichbar sein.

Hinweis:
In einigen Anleitungen findet man anstelle von „.home“ auch „.local“. Da dies aber oft zu Problemen bei der Namensauflösung unter Mac OS oder iOS führt, habe ich mich für „.home“ entschieden. Natürlich sollten hier auch keine öffentlichen Domainnamen verwendet werden!

Forward- und Reverse-Lookup Zonen anlegen

Domains die wir im DNS-Server konfigurieren wollen, werden eigene Zonen angelegt. Für jede Domain sollte es normalerweise zwei Zonen-Dateien geben. Jeweils eine Zonen-Datei für den Forward- und den Reverse-Lookup.

Zuerst muss in der Datei „/etc/bind/named.conf.local“ die Konfiguration für diese beiden Dateien unserer Beispiel-Zone „berry.home“ eingetragen werden. Um die Datei zu bearbeiten, muss diese in einem Editor (z. B. „nano“) geöffnet werden.

sudo nano /etc/bind/named.conf.local

Danach muss folgender Inhalt eingetragen und gespeichert werden.

//
// This file contains the own local DNS server configuration.
// This is where you declare the zones associated with this server's domain(s). 
// Consider adding the 1918 zones here, if they are not used in your organization 
// include "/etc/bind/zones.rfc1918";
//

// ----------------------- Zones -----------------------

// Forward-Lookup
zone "berry.home" {
    type master;
    file "/etc/bind/zones/berry.home.zone";
    allow-transfer { acl_trusted_transfer; };    //see named.conf.options for configuration
};

// Reverse-Lookup
zone "2.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.2.168.192.inv";
};

// ----------------------- Zones -----------------------

named.conf.local (GitHub) herunterladen

Hier werden zuerst nur die Zonen für BIND bekannt gemacht. Die eigentliche Konfiguration der logischen Struktur, wird dann in den jeweils unter „file“ angegeben Dateien eingetragen.

Zur besseren Übersicht habe ich diese in einen eigenen Ordner „zones“ gespeichert, welcher mit diesem Befehl angelegt wird.

sudo mkdir /etc/bind/zones

Die Datei „berry.home.zone“ muss nicht erstellt werden und kann direkt mit folgendem Befehl geöffnet werden.

sudo nano /etc/bind/zones/berry.home.zone

Folgender Inhalt muss in die Datei eingetragen und gespeichert werden.

;;
;; BIND forward data file for zone berry.home
;;

$TTL          86400   ; time-to-live - 24 hours could have been written as 24h or 1d

@             IN      SOA         ns1.berry.home. mail.berry.home. (
                                             2015061201       ; Serial - (NOTE: Needs to increment every time you restart BIND)
                                                 604800       ; Refresh
                                                  86400       ; Retry
                                                2419200       ; Expire
                                                 604800 )     ; Default TTL

              IN            NS           ns1.berry.home.      ; nameserver
              IN            A            192.168.2.2          ; loop-back address

ns1           IN            A            192.168.2.2 	
berry.home.   IN            A            192.168.2.2
server        IN            A            192.168.2.10
server        IN            TXT          "Interner Server"

www           IN            CNAME        berry.home.

berry.home.zone (GitHub) herunterladen

Für den Reverse-Lookup wird noch eine weitere Zonen-Datei „db.2.168.192.inv“ angelegt.

sudo nano /etc/bind/zones/db.2.168.192.inv

In dieser Datei muss folgender Inhalt eingetragen und gespeichert werden.

;;
;; BIND reverse data file for zone db.2.168.192.inv
;;

$TTL 	       86400         ; time-to-live - 24 hours could have been written as 24h or 1d

@              IN            SOA      ns1.berry.home. mail.berry.home. (
                                           2015061101          ; Serial  - (NOTE: Needs to increment every time you restart BIND)
                                               604800          ; Refresh
                                                86400          ; Retry
                                              2419200          ; Expire
                                               604800 )        ; Default TTL

               IN            NS       ns1.berry.home.          ; nameserver 
    
2              IN            PTR      ns1.berry.home.          ; #1 192.168.2.2
10             IN            PTR      server.berry.home.       ; #2 192.168.2.10

db.2.168.192.inv (GitHub) herunterladen

Wurde die Konfiguration angelegt, kann diese mit dem Programm „named-checkconf“ geprüft werden.

sudo named-checkconf -z

Konfiguration für BIND anpassen

Nachdem die Zonen eingetragen wurden, muss jetzt noch die Konfiguration von BIND über die Datei „named.conf.options“ erfolgen.

sudo nano /etc/bind/named.conf.options

Eine mögliche Konfigurationsdatei habe ich unter folgender Adresse zur Verfügung gestestellt:
named.conf.options (GitHub) herunterladen

Nachdem es sehr viele Konfigurationsmöglichkeiten gibt, kann ich hier nicht auf alle eingehen.
Einige möchte ich aber hier trotzdem kurz erklären.

Über den Access Control List (ACL) Eintrag „acl_trusted_transfer“ kann gesteuert werden, von welchen IP’s aus ein Transfer von DNS-Zonen erlaubt wird.

 acl "acl_trusted_transfer" {
      none;
 };

Über den Access Control List (ACL) Eintrag „acl_trusted_clients“ kann gesteuert werden, von welchen IP’s aus Anfragen (Queries & Recursion) an den DNS-Server erlaubt sind.

 acl "acl_trusted_clients" {
       // localhost (RFC 3330) - Loopback-Device addresses  
       127.0.0.0/8;     // 127.0.0.0 - 127.255.255.255  

       // Private Network (RFC 1918) - e. e. LAN            
       192.168.0.0/16;  // 192.168.0.0 - 192.168.255.255 

       // Private Network (RFC 1918) - e. g. VPN            
       // 10.0.0.0/8;   // 10.0.0.0 - 10.255.255.255
 };

Damit der DNS-Server auch Anfragen von Zonen außerhalb des lokalen Netzwerkes beantworten kann, können weitere öffentliche DNS-Server als „Forwarders“ eingetragen werden. Wird hier die IP-Adresse des Routers eingetragen, so werden die Anfragen an die DNS-Server des eigenen Providers weitergeleitet.

forwarders {
       // Router DNS
       // 192.168.2.1

       // Google Public DNS
       8.8.8.8;
       8.8.4.4;
 
       // OpenDNS
       208.67.222.222;
       208.67.220.220;
};

Jetzt muss der DNS-Server noch neu gestartet werden.

sudo service bind9 restart

oder

sudo service bind9 stop
sudo service bind9 start

Wurde alles korrekt konfiguriert, sollte der Status „ok“ ausgeben werden.

[ ok ] Starting domain name service...: bind9su.

Sollte etwas schiefgelaufen sein, empfiehlt es sich, die Meldungen in der Log-Datei „/var/log/syslog“ anzusehen.

BIND automatisch bei Systemstart starten

Damit der DNS-Server beim nächsten System Neustart automatisch gestartet wird, muss der Autostart noch durch folgenden Befehl aktiviert werden:

sudo update-rc.d bind9 defaults

DNS-Server durch DNS-Anfragen testen

Um den DNS-Server von einem Client aus testen zu können, sollten zuerst in der jeweiligen Netzwerkkonfiguration der DNS-Server eingetragen werden.
Danach kann dieser wie folgt getestet werden.

Linux
Die Funktionalität des DNS-Servers kann unter Linux durch das Tool „dig“ getestet werden.

Forward-Lookup testen

dig +noall +answer system.berry.home
dig +noall +answer www.berry.home
dig +noall +answer ns1.berry.home

Für alle Anfragen sollte der entsprechende DNS-Eintrag mit der korrekten IP-Adresse ausgegeben werden.

Reverse-Lookup testen

dig +noall +answer -x 192.168.2.10
dig +noall +answer -x 192.168.2.2

Für alle Anfragen sollte der entsprechende DNS-Eintrag mit dem korrekten Namen ausgegeben werden.

Tipp:
Durch die Angabe des Parameters „@“ kann ein beliebiger DNS-Server getestet werden, ohne das dieser in der Netzwerkkonfiguration eingetragen wurde.

Beispiel:

dig +noall +answer @192.168.2.2 system.berry.home

Windows
Die Funktionalität des DNS-Servers kann unter Windows durch das Tool „nslookup“ getestet werden.

Forward-Lookup testen

nslookup system.berry.home
nslookup www.berry.home
nslookup ns1.berry.home

Für alle Anfragen sollte die korrekte IP-Adresse ausgegeben werden.

Reverse-Lookup testen

nslookup 192.168.2.10
nslookup 192.168.2.2

Für alle Anfragen sollte der korrekte DNS-Name der jeweiligen IP-Adresse ausgegeben werden.

WLAN-Verbindung bei einem Verbindungsabbruch automatisch wiederherstellen

Ist die Netzwerkverbindung unter Raspbian mittels WLAN hergestellt, wird diese bei einem Verbindungsabbruch nicht mehr automatisch wiederhergestellt. Dies kommt z. B. dann vor, wenn der Access Point bzw. Router neu gestartet oder kurz der Stecker gezogen wird.

Damit der Raspberry Pi nach einem Abbruch der Netzwerkverbindung diese automatisch wiederherstellt, gibt es unterschiedliche Lösungsansätze. Neben Anwendungen wie wicd und Shell-Scripte, die periodisch durch einen Cronjob aufgerufen werden, gibt es folgende Möglichkeit die mir persönlich am Besten gefällt.

Normalerweise läuft standardmäßig der Dämon ifplugd. Dieser überwacht den Verbindungsstatus unterschiedlicher Interfaces, darunter auch das WLAN-Interface. Wird ein Statuswechsel erkannt, werden die in der Datei /etc/ifplugd/action.d/ifupdown definierten Aktionen ausgeführt.

Um sicherzugehen, dass der Dämon die WLAN-Verbindung auch wirklich überwacht, kann dies durch folgenden Befehl geprüft werden.

ps aux | grep ifplugd

Bei der Ausgabe sollte ein Prozess das Wort wlan0 enthalten.

root 1642 0.0 0.1 1756 1228 ? S Jun05 0:35 /usr/sbin/ifplugd -i wlan0 -q -f -u0 -d10 -w -I

Anpassung

Damit bei einem Statuswechsel automatisch versucht wird die Verbindung wiederherzustellen, muss die Datei /etc/ifplugd/action.d/ifupdown angepasst bzw. ersetzt werden.

Eine passendes Script liefert uns glücklicherweise gleich das Programm wpa_supplicant bei Raspbian mit.
Dieses findet man unter folgendem Pfad: /etc/wpa_supplicant/ifupdown.sh

Damit dieses Script verwendet wird, muss das vorhandene durch dieses ersetzt werden.
Dazu müssen folgende Befehle ausgeführt werden.

sudo su
cd /etc/ifplugd/action.d
mv ifupdown ifupdown.orginal
ln -s ../../wpa_supplicant/ifupdown.sh ifupdown

Wichtig hierbei ist, dass die vorhandene Datei nicht einfach gelöscht, sondern als Sicherung einfach umbenannt wird. Sollte man die Netzwerkverbindung des Raspberry Pi’s nicht mehr über WLAN, sondern über den Ethernet-Anschluss aufbauen, muss die orginale Datei durch folgende Befehle wiederhergestellt werden.

sudo su
cd /etc/ifplugd/action.d
rm ifupdown
cp ifupdown.original ifupdown

Hinweis
Wird ein WLAN-Adapter (z.B. von Edimax) verwendet, der bei Inaktiviät die Verbindung automatisch durch seinen Energiesparmodus unterbricht, muss diese Stromsparfunktion deaktiviert werden. Weitere Informationen dazu findet man in folgendem Beitrag:
WLAN einrichten (mittels EDIMAX EW-7811UN Adapter unter Raspbian)

WLAN einrichten (mittels EDIMAX EW-7811UN Adapter unter Raspbian)

Für den Raspberry Pi gibt es viele Adapter um per WLAN eine Verbindung ins Netzwerk aufzubauen. Der Aufwand für die Installation und Konfiguration unter dem verwendeten Betriebssystem kann sich je nach Chipsatz und Treiber deutlich unterscheiden. Ich habe mich für den EDIMAX EW-7811UN Wireless USB Adapter, 150 Mbit/s, IEEE802.11b/g/n entschieden, da unter Raspbian der Treiber für den Realtek-Chipsatz RTL8188CUS standardmäßig mitgeliefert wird.

Wireless USB Adapter Installation

Nachdem der WLAN-Stick in den USB-Anschluss eingesteckt und das Betriebssystem hochgefahren ist, sollte als erstes geprüft werden, ob der WLAN-Stick korrekt vom USB-Adapter erkannt wurde. Dies kann durch den Befehl dmesg (Display Message) erfolgen, welches die Meldungen des Kernel-Ringpuffers auf den Bildschirm ausgibt. Durch den more Befehl wird der Text zeilenweise (Entertaste) oder seitenweise (Leertaste) auf der Kommandozeile ausgeben.

dmesg | more

Folgende Ausgabe zeigt, dass der USB-Stick korrekt erkannt wurde:

[    3.609062] usb 1-1.3: new high-speed USB device number 4 using dwc_otg
[    3.720652] usb 1-1.3: New USB device found, idVendor=7392, idProduct=7811
[    3.733519] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.746158] usb 1-1.3: Product: 802.11n WLAN Adapter
[    3.756169] usb 1-1.3: Manufacturer: Realtek

Die Anzeige kann über die Taste „Q“ beendet werden.

Tipp
Bei Raspbian ist „lsusb“ standardmäßig installiert. Somit kann die Prüfung auch mittels „sudo lsusb“ erfolgen.

Jetzt müsste auch bei Eingabe des Befehls

sudo ifconfig

ein neues Netzwerkgerät als wlan0 angezeigt werden.


eth0      Link encap:Ethernet  Hardware Adresse a2:22:ab:cf:1c:1d
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
.....
.....
.....
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  Hardware Adresse 11:da:22:03:ef:1e
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Stromsparfunktion (Power Saving) abschalten

Es wird empfohlen die Stromsparfunktion des Edimax-Treibers zu deaktivieren. Diese unterbricht die Verbindung bei Inaktivität. Um dies zu verhindern muss eine Konfigurationsdatei für den Treiber angelegt werden.

sudo nano /etc/modprobe.d/8192cu.conf

Folgenden Inhalt einfügen und die Datei abspeichern. Unter nano geht das durch STRG + X, Y und Enter.

options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

WLAN Verbindung einrichten

Um eine Verbindung mit dem WLAN herzustellen, muss in der Datei /etc/network/interfaces der Bereich „wlan0“ angepasst werden,

sudo nano /etc/network/interfaces

Die Konfiguration unterscheidet sich etwas, je nachdem ob eine dynamische IP-Zuweisung mittels DHCP erfolgen soll oder ob eine statische IP zugewiesen wird. Für beide Konfigurationen müssen natürlich der WLAN-NAME und der WLAN-SCHLÜSSEL entsprechend angepasst werden.

Dynamische IP mittels DHCP

auto lo
iface lo inet loopback
iface eth0 inet dhcp

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ap-scan 1
wpa-scan-ssid 1
wpa-ssid "EIGENER-WLAN-NAME (SSID)"
wpa-psk "EIGENER-WLAN-SCHLÜSSEL (PSK)"

Statische IP zuweisen

auto lo
iface lo inet loopback
iface eth0 inet dhcp

auto wlan0
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.0.50
netmask 255.255.255.0
gateway 192.168.2.1
wpa-ap-scan 1
wpa-scan-ssid 1
wpa-ssid "EIGENER-WLAN-NAME (SSID)"
wpa-psk "EIGENER-WLAN-SCHLÜSSEL (PSK)"

Hier wird die statische IP 192.168.0.50 vergeben und als Gateway (z.B. Router) die IP 192.168.2.1 eingestellt.

Nachdem alle Einstellungen vorgenommen wurden, muss der Netzwerkdienst neu gestartet werden. Dies kann durch Eingabe, einer der beiden Befehle erfolgen:

sudo /etc/init.d/networking restart

oder

sudo service networking restart

Jetzt sollte der Raspberry über den WLAN-Adapter erreichbar sein.