Sonntag, 27. März 2016

WLAN und Jessie

Das neueste Jessie Image für den Raspberry vom 18.3.2016 macht die Wlan Konfiguration ziemlich einfach. Alle Treiber und Tools sind schon installiert.
Ich verwende den TP-Link TL-WN725N (Realtek) als externen WLAN Adapter oder den eingebauten WLAN Adapter vom Pi3 ().
In beiden Fällen können wir uns mit mit ifconfig davon überzeugen, dass der WLAN Adapter im System Treiberseitig eingebunden ist. Am Ende der Ausgabe muss ein Abschnitt mit wlan0 und der HWaddr kommen. Die Hardware Adresse könnte man gleich zur Reservierung einer festen IP Adresse verwenden.

Ein kurzer Check ob überhaupt ein Netzwerk gesehen wird:
iwlist scanning
Als Ergebnis gibt es ein Listing von den vorhandenen Netzwerken.

Die Wlan Verbindung muss manuell eingetragen werden:
 sudo nano /etc/network/interfaces  
Wir suchen diese Zeilen (und/oder ergänzen bei Bedarf):
 allow-hotplug wlan0  
 auto wlan0  
 iface wlan0 inet manual  
Vor die folgende Zeile setzen wir ein Kommentarzeichen
 #  wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf  
und nun wird angefügt
 wpa-ssid "WLAN-Name"  
 wpa-psk "WLAN-Passwort"  

Alternativ kann man auch mit der /etc/wpa_supplicant/wpa_supplicant.conf arbeiten
Wir öffnen die Datei
sudo nano /etc/wpa_supplicant/wpa_supplicant.conf 

Und tragen folgendes am Ende ein
network={
ssid="WLAN SSID"
psk="WLAN Passwort"
}
Vielfach liest man von mehr Optionen, bei mir haben die Angabe von ssid und psk genügt.

Mit dem Befehl
wpa_passphrase 'WLAN SSID' 'WLAN Passwort' >> /etc/wpa_supplicant/wpa_supplicant.conf

kann man den notwendigen Abschnitt erzeugen, dabei wird das Passwort in hexdezimaler Form codiert, steht also nicht im Klartext in der Datei. Das Klartext Passwort wird auskommentiert und kann gelöscht werden.

Das war es schon, mit
sudo systemctl daemon-reload
sudo systemctl restart networking
starten wir das netzwerk neu und der raspberry verbindet sich zum Wlan.
Meist muss man in dem Fall das wlan Interfaces mit diesem Befehl starten:
 sudo ifup wlan0
Man kann sich jetzt noch Details vom Netzwerk anzeigen lassen
 iwlist wlan0 scan

Powermanagement

Per default ist das Powermanagement in Jessie aktiv. Ganz schlechte Idee wenn der PI nur über Wlan im Netz hängt und plötzlich nicht mehr erreichbar ist.
Der folgende Befehl schaltet das Powermanagement für wlan0 sofort aus.
iw wlan0 get power_save
iw dev wlan0 set power_save off
Um es dauerhaft beim Neustart einzurichten müssen in der Datei /etc/network/interfaces diese Zeilen eingefügt werden. Aber unbedingt am Ende vom "Abschnitt" wlan0 also vor der ersten Zeile mit wlan1. Die pre/post-up und per/post-down Zeilen werden beim ifup bzw. ifdown des zugehörigen Interfaces ausgeführt. Wird das Interface nicht gestartet, wird der Befehl auch nicht ausgeführt.
post-up iw dev wlan0 set power_save off

Diese Option braucht einen Neustart ifdown wlan0 && ifup wlan0 reicht.
Der Befehl iwconfig gibt Auskunft über den Status des Powermanagements.

Zusammenfassung

Ich habe nach allen Erkenntnissen die Netzwerkdefinition in die /etc/wpa_supplicant/wpa_supplicant.conf eingetragen.
Am Ende sieht der modifizierte Abschnitt der Datei /etc/network/interfaces minimalistisch wie folgt aus:
allow-hotplug wlan0
 iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
    post-up iw dev wlan0 set power_save off

allow-hotplug wlan1
 iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Zum Nachlesen:
Debian Kapitel 5 Netzwerkkonfiguration
Elektronik Kompendium WLAN Adapter beim raspberry einrichten.
Raspberry Pi3 WLAN einrichten
Wiki Ubuntuusers WLAN
Wiki Ubuntuusers interfaces

Freitag, 11. März 2016

Fritzbox zum Quadrat

Eine 7490 war schon vorhanden und jetzt kam vom Provider noch eine 7412 als Endpunkt des neuen DSL Anschlusses. Da der Router zum Teil auch über TR-069 Protokoll vom Provider konfiguriert wird, wollte ich es auch so: die 7412 schließt die DSL Leitung ab und die 7490 macht weiterhin den Hauptjob. Da gibt es bei AVM eine gute Anleitung wie man zwei Fritzboxen koppelt. Nun kommen die beiden Boxen ja nicht aus der Verpackung, sondern meine 7490 war schon in Betrieb. Also "Migration" ist angesagt. Und hier gibt es jetzt meine Erfahrungen:

Ich konfiguriere gerne per DHCP und ich mache auch gerne feste IP Adressen über DHCP und ich tippe nicht gern ab. Also: Sicherung der Konfiguration der existierenden Box und Wiederherstellung auf der neuen Box. Dabei kann man auswählen, nur bestimmte Einstellungen wiederherzustellen - Netzwerkonfiguration.  Dabei gibt es die erste Eigenheit: Das geht irgendwie nur einmal, nach dem Auspacken (oder Werksreset) und Basiskonfiguration mit dem Modeminstallationscode. Beim zweiten Versuch fehlt genau dieser Punkt zur Auswahl?!

  • Beide Boxen haben WLAN aktiv. Die 7490 steckt am LAN und wird vom DSL getrennt.
  • Die 7412 wird am DSL angeschlossen und steckt nicht am LAN.
  • Verbindung zur 7490 und Konfiguration sichern.
  • Verbinden zur 7412 und Konfiguration wiederherstellen.
  • 7490 vom LAN trennen und 7412 mit dem LAN verbinden.
  • 7490 als IP Client konfigurieren nach einer Wartezeit wieder an LAN anschließen


Und alles läuft weiter? Naja nicht ganz...
Die Rasperry's sind von Android aus nicht mehr per Namen erreichbar, obwohl es in der Fritzbox Oberfläche alles gut aussieht. Ein Blick mit nslookup bringt es an den Tag: die Fritzbox verweigert die Auskunft obwohl sie scheinbar den Namen kennt. Abhilfe bringt eine Neuregistrierung am DHCP Server mit dhclient (oder ein Neustart). Die Windows PCs machen das scheinbar ohne extra Aufforderung. Mein HMLAN Adapter ist auch nicht per Namen erreichbar, mal sehen ob das irgendwann von alleine wird. Ich vermute, wenn der DHCP Client auf Grund der Lease Dauer seine Lease erneuern will wird es wohl klappen.

Die Windows Rechner sind zwar per DNS Namen erreichbar, die haben auch den Vorteil, dass sie Broadcast machen und die Linux Rechner auch damit auflösen können. Aber die Windows Clients ermitteln ob sie an einem bekannten Netzwerk angeschlossen sind (MAC Adresse des Default Gateway?) und packen erstmal das neue Netzwerk in die Kategorie "öffentlich" und damit unsicher! Wenn man, wie ich, etwas auf Sicherheit achtet und nicht alles immer gleich öffnet - gehen jetzt ein paar Sachen erstmal nicht mehr. Wenn man sich am Windows PC anmeldet ist das Problem mit einem Klick behoben, Windows fragt nach der Art des Netzwerkes, man klickt auf Privat und alles ist gut. Aber der Server an dem man sich maximal mal per RDP anmeldet?
Man sollte vorher RDP auf öffentliche Netzwerke freigeben, oder Monitor und Tastatur bereithalten!

Interessant wird noch die Auswertung in FHEM, beide Fritzboxen zeigen die Netzwerkgeräte an, nicht alle auf jeder Box aber auch nicht alle bloß auf einer Box.

Mittwoch, 2. März 2016

Werksimage zurücksetzen

Das Notebook funktioniert nicht mehr, eigentlich gibt es ein Recoveryimage vom Hersteller aber der Mechanismus (z.B. F9 beim booten drücken) funktioniert nicht mehr?! Windows Wiederherstellungsmedium funktioniert auch nicht? Original DVD wurde nie mitgeliefert?

Einfach "Neu machen"

Normalerweise kann man ja irgendwie an Datenträger über downloads kommen. MS hat mit Windows 8 begonnen diese über ein "Media Creation Tool" als download zur Verfügung zu stellen. Manchmal braucht man seinen Lizenzkey manchmal auch nicht. Stand heute kann man als Windows 7 / 8 / 8.1 Besitzer einfach Windows 10 herunterladen und ist damit gleich auf dem neuesten Stand. Auch hier Vorrausetzung: Lizenzkey, falls der Rechner keinen Aufkleber hat, steht dieser eventuell im BIOS (ab Windows 8 bei Auslieferung). Den braucht man dann auch nicht auszulesen, den nimmt sich Windows bei der Installation automatisch.

Restorepartition vorhanden

Aber was wenn es vielleicht doch der Auslieferungszustand mit Originalimage sein soll? Das wird typischerweise in einer extra 10-20 GB großen Partition "Restore" am Ende der Systemplatte versteckt. Achtung es gibt meist noch eine versteckte Partition "Recovery" mit ca. 900 MB - die ist es nicht.

Erstmal muss das System wieder startfähig sein. Dazu installieren wir eine Windows Version (am Besten passend, also Original Windows 8 dann Windows 8) und  zerstören dabei aber nicht die Partitionen!  Die Windows Partition kann ruhig formatiert werden (Datenverlust!?), aber nicht gelöscht werden.

Restore sichtbar machen

Im gestartete System müssen wir zunächst die Restore Partition sichtbar machen:
diskpart  
list volume
select volume n (Die Nummer mit dem Namen "Restore")
assign letter=R
rem == Fenster offen lassen um später Laufwerk zu entfernen

Jetzt müssen wir den Pfad kennen wo die Datei install.wim liegt und den Index für unser Recovery System. Wissen wir das nicht, müssen wir Zugriff auf die install.wim haben und mit dism die vorhanden Indizes ermitteln. Am einfachsten zweites cmd Fenster öffnen:
dism /get-imageinfo /ImageFile:R:\RecoveryImage\install.wim

Ist das Image z.B im Index 2 (wenn mehrere vorhanden sind ist die 1 häufig ein "Masterimage" sieht der Befehl zur Reaktivierung so aus
reagentc /setosimage /path R:\RecoveryImage /index 2  
reagentc /enable

Wir müssen diskpart noch schließen und die Restore Partition damit wieder unsichtbar machen (Fenster 1):
remove letter=R
exit

Wiederherstellung starten

Jetzt kann man ins Wiederherstellungssystem starten (shift + Neustart) und die Systemwiederherstellung starten.

Original HDD defekt?

Hängt jetzt ganz vom Zustand ab, was da noch zu retten ist. Manchmal stirbt eine Festplatte ja "gutmütig", d.h. Self Monitoring Analysis and Reporting meldet Fehler oder nur bestimmte Dateien lassen sich nicht mehr kopieren. Ist die Recovery Partition noch intakt, hat man auch hier eine Chance. Ich hatte zumindest einen Fall, da steckte auch der Produktschlüssel in der Recovery Partition und war weder im Bios noch auf der "Verpackung".
Also neue Festplatte her, beide Platten an einen Computer angeschlossen und wir können auch noch ein kleines Tool gut gebrauchen -> MiniTool Partition Wizard free 

Mit dem Tool können wir die Recovery Partition (normalerweise die letzte) einfach auf die neue Platte kopieren, Größe so belassen und wieder an das Ende der neuen Platte verschieben. Die genaue Größe der neuen Festplatte spielt keine Rolle.

Man könnte den Inhalt dieser Partition auch per Hand kopieren, etwas umständlicher aber es geht. Zunächst auf der Original Platte die Recovery Partition "sichtbar" machen, im cmd Fenster 1:
diskpart
list disk -> Platten Nummern notieren alte / neue Platte
list volume
select volume n (Die Nummer mit dem Namen "Restore")
assign letter=S

Auf neuer Platte Partition am Ende erstellen. Das geht nur über einen Umweg:
sel disk n (die Nummer der neue Platte)
clean
rem == Eine komplette Partition erzeugen  ==========
create partition primary 
rem == Verkleinern um den Platz für recovery image =
shrink minimum=21500
rem === Recovery image partition erzeugen ==========
create partition primary
format quick fs=ntfs label="Recovery image"
assign letter="R"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
rem === Partion am Anfang wieder löschen============
list part
sel part 1
del part
rem == wechseln in anderes Fenster 2 um den Kopiervorgang zu starten
remove letter=R
remove letter=S

Kopieren im extra cmd Fenster 2
xcopy s: r: /s/e/h
# Zurück zu Fenster 1 um Laufwerke wieder zu entfernen

Die Installation von Windows erfolgt ganz normal, man wählt einfach den freien Bereich der Festplatte dafür aus.

Links

Recovery Partition Creator
Artikel com! Magazin
MiniTool Partition Wizard free
Konfigurieren von UEFI-/GPT-basierten Festplattenpartitionen mit Windows PE und DiskPart
windows product key offline auslesen

Freitag, 26. Februar 2016

CUL Stick flashen

Irgendwie existieren gefühlt tausend Beschreibungen dazu im Internet, es gibt viele Seiten dazu im FHEM Forum und im FHEM Wiki. Alle sind ähnlich und keine führte bei mir wirklich direkt zum Ziel. Deswegen mal wieder: ich habe alles intensiv durchprobiert und einen ziemlich simplen Weg gefunden. Aber! Dieser Weg ist heute scheinbar richtig, ob das morgen noch so ist kann ich nicht garantieren.
FHEM kann es fast automatisch und bringt fast alles mit.

Vorbereitung


Man braucht den DFU-Programmer
 sudo apt-get install dfu-programmer  

Diesen müssen wir für fhem ausführbar machen damit er nicht nur unter root läuft und wir fhem nicht zu root machen müssen!
 sudo chmod u+s /usr/bin/dfu-programmer  

Programmierung


Den CUL Stick richtig stecken - und das ist nicht einfach! Man muss die kleine Taste auf der Unterseite beim Stecken gedrückt halten!
Ich finde es geht gut mit
  1. einem USB Verlängerungskabel welches man in die USB Schnittstelle steckt, 
  2. dann setzt man den USB Stecker vorsichtig an, 
  3. hält beides (Stick und USB Kupplung/Buchse) auf dem flachen Tisch mit Daumen (Stick) und Mittelfinger (Buchse) der linken Hand fest, 
  4. drückt mit der rechten und einem kleinen Stift (Zahnstocher) den Taster und 
  5. schiebt mit Daumen den Stick, der Mittelfinger fixiert die Buchse.

Jetzt gibt man in der Kommandozeile von FHEM ein
 usb scan  

Es kommt die Auschrift: CUL_V3: flash it with: CULflash none CUL_V3

Also in die Kommandozeile genau das eingeben was er sagt (copy&paste):
 CULflash none CUL_V3  

Der Erfolg wird mit der Ausschrift:
 CULflash Validating...  
 28630 bytes used (99.85%)  
und einem Blinken des CUL Stick quittiert.

In FHEM verwenden

Wenn der Stick läuft und blinkt können wir ein erneutes usb scan eingeben. Die Ausschrift die folgt kann man wieder direkt ernst nehmen:
 ### ttyACM0: checking if it is a CUL   
 create as a fhem device with: define CUL_0 CUL /dev/ttyACM0@9600 1034   
 ### ttyAMA0: checking if it is a CUL   
 cannot open the device   
und einfach die Empfehlung in die Kommandozeile kopieren
 define CUL_0 CUL /dev/ttyACM0@9600 1034  

Update oder neu flashen

Wenn der CUL Stick mal einen neue Firmware bekommen soll, geht das auch einfach in FHEM:
 CULflash CUL_0 CUL_V3  

Man kann den CUL Stick auch löschen (Terminal)
 dfu-programmer atmega32u4 erase   
Man muss es aber normalerweise nicht, einfach rausziehen und in den Programmiermodus versetzen reicht.

Montag, 22. Februar 2016

Windows Setup Stick

Vorbemerkung

Ich installiere immer mal Windows: bei Freunden, Testsysteme, meine produktiven System neu machen usw. So oft, damit sich dass komplett lohnt was ich hier beschreibe ist es auch nicht. Aber ich bin nun mal Fan von solchen Dingen.
Ab Windows 7 kann man alle Versionen in ein Setup verpacken, auch 32 bit und 64  bit Versionen kann man mischen, was jedoch schon etwas anspruchsvoller ist.
Es gibt viele "Kochanleitungen" dafür, ich habe mir eine Art Framework mit Powershell dafür gebaut und mache es ausschließlich mit Bordmitteln. Das Powershell Script läuft nicht automatisch, ich arbeite immer nur entsprechende Zeilen ab, setze mal Kommentare und modifiziere bei Bedarf.

Wenn man sich alles in eine Script schreibt und dieses mit dem Standard ps1 benennt, sollte man unbedingt diese erste Zeile einfügen:
 Exit 0  
Das schützt vor den ungeahnten Folgen eines Doppelklicks auf die Datei.

Einfach mal einen bootfähigen USB Stick erzeugen

Die einfachste Art sich einen Windows Setup Stick zu bauen funktioniert nur für eine Windows Version. Dazu braucht man
  • einen Stick mit mindestens 4 GB.
  • ISO Image oder DVD von der Windows Version
  • Das System Tool diskpart, vorhanden ab Windows XP

Achtung: genau hinschauen! 
Alle weiteren Befehle löschen vorhanden Daten auf einem Laufwerk!

Wir stecken den Stick in eine freie USB Schnittstelle und starten eine cmd shell als Administrator: z.B.  mit Windows + x und dann Eingabeaufforderung (Administrator) und legen los:

  1. Diskpart öffnet eine neue shell, wir befinden uns jetzt innerhalb von diskpart.
  2. Mit list disk lassen wir uns die Datenträger anzeigen. Diskpart begnügt sich mit den ersten drei Buchstaben eines Befehls -> für Schreibfaule: lis dis reicht.
  3. Wir identifizieren unseren USB Stick, z.B. Datenträger 3. 
  4. Mit select disk 3 wählen wir den Datenträger aus.
  5. Mit clean wird er Stick gelöscht.
  6. Nun wird mit create partition primary eine neue Partition erzeugt und diese mit dem Befehl active als Bootpartition markiert.
  7. Formatieren erfolgt mit format fs=fat32 quick. Normalerweise wird der Stick nach Abschluss der Formatierung sofort im Explorer als Laufwerk sichtbar. Sollte das nicht so sein, geben wir noch assign ein. 
  8. Mit exit verlassen wir diskpart, mit einem weiteren exit die cmd shell.

Nun ist der Stick für immer vorbereitet, diesen Vorgang brauchen wir nur einmalig zu machen. Der Stick ist bewusst im FAT32 Format formatiert, da EFI (das moderne BIOS) nur von diesem Dateisystem booten kann. Der einmal so vorbereitete Stick kann jederzeit mit einem neuen Windows als Setup Stick ausgestattet werden. Dazu wird einfach der komplette Inhalt der DVD (ISO) auf diesen Stick kopiert, mit dem Explorer, xcopy oder was auch immer. Die Wurzelverzeichnisse der Laufwerke müssen anschließen identisch aussehen,, also keine Unterverzeichnisse anlegen oder einfach die ISO Datei kopieren! Wer nur schnell einen Setup Stick braucht ist jetzt fertig. Wer alle Windows Versionen auf einen Stick haben will muss noch ein bisschen weiter machen.

Hinweis: Mittlerweile (2024) ist die Datei install.wim viel zu groß für FAT Dateisysteme, man muss diese in mehrere swm Dateien zerteilen. Weiter unten ist gezeigt wie das mit Powershell oder dism funktioniert.

Die Basisarbeit

Wir brauchen etwas an "Umgebung", performanten Speicherplatz, Tools usw. Ich arbeite alles in einer Powershell ab und habe dafür jeweils ein paar Zeilen Script vorbereitet. Diese passe ich dann gegebenenfalls einfach an.

Ich habe kein perfektes Script, was alles alleine tut.
Ich warne davor den hier vorgestellten Code einfach auszuführen ohne, dass man verstanden hat was passiert!

Die Powershell starten wir am Besten in der ISE Version (Entwicklungsumgebung) im Administrator Kontext (also ausführen als...)
Zunächst ein paar Definitionen und Pfade erzeugen:
 ########### Basis Arbeit - unbedingt ausführen  
 ########### Erzeuge Struktur zur Image Erstellung  
 $WorkDir = "D:\WindowsSetupDir"     # Arbeitsverzeichniss, Laufwerk spielt für Performance eine Rolle  
 $Source  = "E:"             # Hier liegt die Quell DVD des aktuell zu bearbeitenden Windows  
 $USBStick = "F:\"            # Laufwerk für den Ziel USB Stick  
 # Die Pfade werden als Basis gesetzt und können für Performance auch verändert werden  
 $DistDir =  "$WorkDir\" + "distribution"  
 $bootDir =  "$WorkDir\mount" + "\" + "boot"  
 $windowsDir = "$WorkDir\mount" + "\" + "windows"   
 # Erzeuge Pfadstruktur falls nicht vorhanden  
 if( -not (Test-Path $WorkDir) ) { New-Item $WorkDir -type directory }  
 if( -not (Test-Path $DistDir) ) { New-Item $DistDir -type directory }  
 if( -not (Test-Path $bootDir) ) { New-Item $bootDir -type directory }  
 if( -not (Test-Path $windowsDir) ) { New-Item $windowsDir -type directory }  

Als Basisversion für unseren Setupstick verwenden wir immer die neueste Windows Version die wir einsetzen wollen, falls Serverversionen eine Rolle spielen, die neueste Serverversion. Diese DVD kommt ins Laufwerk (E: in meinem Beispiel) und das Arbeitsverzeichnis wird vorbereitet.
 ########### Basis DVD kopieren  
 #Prüfe ob Setup DVD im Laufwerk  
 if( -not (Test-Path $Source\) )   
 {Write-Host Setup DVD nicht vorhanden. Prüfe ob eine DVD in Laufwerk $Source eingelegt  
 Exit 1   
 }  
 # Kopiere den Inhalt der Basis DVD ins Arbeitsverzeichnis falls es leer ist  
 if( (Get-ChildItem $DistDir | Measure-Object).Count -eq 0)   
 {  
 xcopy $Source\ $DistDir /s/e  
 }  
 ##########  
Klar geht das auch einfacher, aber so gibt es ein bisschen Komfort. In meinem konkreten Beispiel habe ich Windows 10 Version 1511 vom November 2015 verwendet. Da muss man jetzt noch einen Zwischenschritt einlegen: Die Datei e:\sources\install.esd muss umgewandelt werden.
Falls eine andere Version vorliegt:
Prüfen ob die Datei e:\sources\install.wim existiert - wenn ja kann der nächste Schritt übersprungen werden.

Windows 10 MediaCreationTool

Von Windows 10 werden keine ISO Images mehr zum download angeboten, vielmehr kann man sich mit dem MediaCreationTool herunterladen "was man braucht". Ich bevorzuge dabei immer ein ISO Image, das ist universell einsetzbar. Je nach Zeitpunkt des download ändert Microsoft schon mal den Inhalt der dabei heruntergeladen wird. Die für uns wichtigste Datei ist die install.wim. Neben der Endung und Form "WIM" kann die Datei auch install.esd heißen (aktuell bei der Version 1511 ist das der Fall). ESD ist eine speziell gepackte Version des WIM Formates und kann nicht so direkt weiter verarbeitet werden. Wir müssen diese Datei erst konvertieren. Ich bin ein Freund von Boardmitteln, dass geht zwar etwas umständlich, aber ich habe alles in ein paar Zeilen Script für Powershell gepackt.
Was passiert?
  • Wir erzeugen ein temporäres virtuelles Laufwerk,
  • Das Image install.esd wird darin ausgepackt
  • Das Image install.wim wird aus dem virtuellen Laufwerk wieder erzeugt.

Alle Vorgänge für Windows Images (WIM) müssen immer pro enthaltener Windows Version durchgeführt werden.
In der Datei install.esd sind zwei Versionen enthalten. Dies können wir mit dism anzeigen lassen:
 dism /Get-WimInfo /WimFile:$DistDir\sources\install.esd  
Das cmdlet von Powershell kann dafür leider nicht verwendet werden, es kann offenbar mit esd Dateien derzeit nicht umgehen, von unsere fertigen wim Datei können wir uns das aber jederzeit anzeigen lassen:
 Get-WindowsImage -ImagePath $DistDir\sources\install.wim  

Dieser Vorgang braucht jetzt etwas Zeit.
 ########## Windows 10 Image vorbeiten - aus esd wim Datei machen  
 #   
 # VHD kann später einfach formatiert werden, ist besser als Pfad da Rechte auf Trusted Installer gesetzt werden  
 # VHD auf anderes physisches Laufwerk legen als $DistDir  
 $VHDFile = "c:\temp.vhd"  
 $VHDDrive = "V:"  
 NEW-ITEM -Path bootemup.txt -ItemType file -force | OUT-NULL  
 ADD-CONTENT -Path bootemup.txt -Value “create vdisk file=$VHDFile maximum=25000 type=expandable”   
 ADD-CONTENT -Path bootemup.txt -Value “select vdisk file=$VHDFile”   
 ADD-CONTENT -Path bootemup.txt -Value “attach vdisk”   
 ADD-CONTENT -Path bootemup.txt -Value “create partition primary”   
 ADD-CONTENT -Path bootemup.txt -Value “assign letter=$VHDDrive”   
 ADD-CONTENT -Path bootemup.txt -Value “format quick label=vhd”   
 DISKPART /S .\bootemup.txt  
 # VHD erzeugt kann später ausgeworfen und gelöscht werden  
 dism /apply-image /imagefile:$DistDir\sources\install.esd /index:1 /applydir:$VHDDrive\  
 dism /capture-image /imagefile:$DistDir\sources\install.wim /capturedir:$VHDDrive\ /Compress:max /Name:"Windows 10 Pro" /Description:"Windows 10 Pro"  # Die Description darf nicht fehlen!   
 format $VHDDrive /Q /y   
 dism /apply-image /imagefile:$DistDir\sources\install.esd /index:2 /applydir:$VHDDrive\  
 dism /capture-image /imagefile:$DistDir\sources\install2.wim /capturedir:$VHDDrive\ /Compress:max /Name:"Windows 10" /Description:"Windows 10"  
 # Jetzt beide Images wieder vereinigen  
 Export-WindowsImage -SourceImagePath $DistDir\sources\install2.wim -SourceIndex 1 -DestinationImagePath $distDir\sources\install.wim # -DestinationName "Windows 10"   
 # esd Datei und temporäre wim Datei löschen  
 del $DistDir\sources\install.esd  
 del $DistDir\sources\install2.wim  

Das erzeugte virtuelle Laufwerk können wir später auswerfen und die VHD Datei löschen. Die erzeugte install.wim von Windows 10 sollte man sich für weitere Experimente eventuell separat sichern, da die Erzeugung doch einiges an Zeit beansprucht.

Mehrere Windows Versionen

Da Microsoft seit Windows 7 beim Setup vereinfacht gesagt nur noch von einem Image (boot.wim) bootet um dann anschließen ein anderes Image (install.wim) auf den Datenträger zu kopieren, ist dieser Vorgang relativ Versionsunabhängig. Das WIM (Windows Image) Format ist zudem noch Platzsparend, da es identische Dateien nur einmal speichert. Somit belegen z.B. Windows 8.1 in 2 Varianten sowie Server 2012 R2 in 4 Varianten in einer install.wim kaum mehr Speicherplatz als ein einzelne Version, da der Code ja weitestgehend identisch ist.
Mehrere Windows Versionen in eine install.wim packen ist simpel und schnell gemacht. (wenn man nur eine Sprache (DE) und nur eine Prozessorarchitektur (64 bit) verwendet)
Genau wie bei der Vorbereitung von Windows 10 beschrieben, wird einfach pro Version (nicht pro Installationsmedium) ein "Export" des Windows Images in die Basis install.wim durchgeführt.

Es ist jetzt eine Kombination aus Handarbeit und Scriptzeilen ausführen:
  • DVD auswerfen
  • Neue Windows DVD einlegen (wieder Laufwerk E:)
  • Anzeigen lassen welche Versionen vorhanden sind
  • Die Versionen exportieren die man haben möchte  
 ######## Weitere Images exportieren  
 # Neue DVD in Laufwerk $Source  
 Get-WindowsImage -ImagePath $Source\sources\install.wim  
 # Abfrage Index Nummer  
 $a = read-host "Welches Windows Image exportieren? -a- für Abruch"  
 If ($a -eq "a") {Exit 1}   
 Export-WindowsImage -SourceImagePath $Source\sources\install.wim -SourceIndex $a -DestinationImagePath $distDir\sources\install.wim   

Damit wir alle Versionen bei der Installation auswählen können ohne einen Windows Setup Key eingeben zu müssen, brauchen wir die Datei ei.cfg im Setup Verzeichnis. Diese wird wieder einfach mit einem kurzen Script erzeugt:

 ########## Windows ohne Seriennummer installieren   
 # Windows 10 fragt nach dem Key und diese Frage könnte man überspringen  
 # mit ei.cfg kommt die Frage nach dem Key nicht  
 "[EditionID]  
 [Channel]  
 Retail  
 [VL]  
 0"| out-file -filepath "$DistDir\sources\ei.cfg"   

USB Stick

Für einen USB Setup Stick könnten wir jetzt wieder einfach alle Dateien aus dem $DistDir auf den Stick kopieren. Aber die install.wim Datei ist je nach Anzahl der integrierten Windows Versionen jetzt größer als 4 GB - die magische Grenze für FAT32. Wir müssen die install.wim also in handliche Teile splitten und es ensteht eine Gruppe aus install.swm + install<n>.swm Dateien.

Leider ist die Exclude Funktion und die Fehlerbehandlung von Copy-Item etwas grottig und ich habe es nicht besser hinbekommen:
Die erste Zeile kopiert alle Dateien auf den Stick, wenn dabei ein Fehler auftritt (WriteError: (install.wim:FileInfo)) kann man mit der zweiten Zeile, die zu große install.wim direkt gesplittet auf den Stick kopieren.

In der Powershellkonsole:
# Alles auf USB Stick kopieren  
 Copy-Item -Path $DistDir\* -Destination $UsbStick -Recurse   
 # Image aufteilen für FAT32  
 Split-WindowsImage -ImagePath $DistDir\sources\install.wim -SplitImagePath $USBStick\sources\install.swm -FileSize 4096 -CheckIntegrity  
oder direkt in der cmd geht es mit dism (es gibt keine Ausgabe mit Fortschritt):
dism /Split-Image /ImageFile:F:\sources\install.wim /SWMFile:e:\sources\install.swm /FileSize:4096

ISO Image

Je nach Größe der install.wim wird ein jetzt erstelltes ISO Image allerdings nicht mehr auf eine DVD passen. Ich verwende es bevorzugt für Tests mit VirtualBox oder PCs die Probleme mit dem Start von USB Sticks haben.
Wir brauchen ein zusätzliches Tool: oscdimg. Das bekommen wir aus dem aktuellsten ADK (Access und Deployment Toolkit) von Microsoft
Die Installation des ADK können wir auf zwei Punkte einschränken: Installation Windows PE (bräuchten wir für weitere Modifikationen) und Bereitstellungstools (dism).

Die Aufrufzeile ist etwas komplexer um das ISO Image wieder bootfähig zu machen.

 ######## ISO erzeugen  
 $Platform = "amd64"  
 $ADKDir = "D:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit"   
 $ISOFile="d:\test.iso"  
 del $ISOFile    # falls schon vorhanden  
 $PathToOscdimg = "$ADKDir\Deployment Tools\$Platform\Oscdimg\"  
 $BootData='2#p0,e,b"{0}"#pEF,e,b"{1}"' -f "$distDir\boot\etfsboot.com","$distDir\efi\Microsoft\boot\efisys.bin"  
 & "$PathToOscdimg\oscdimg.exe" @("-bootdata:$BootData",'-u2','-udfver102',"$distDir","$ISOFile") 2>$null  

Im Gegensatz zu anderen Tools (z.B. dism) lässt sich oscdimg nicht ohne weiteres aus Powershell aufrufen, deshalb der Umweg über & und das Array mit Parametern. Außerdem liefert oscdimg einen Fehler der ignoriert werden kann, dies erledigt die Umleitung am Ende der Zeile.

Installation von zusätzlichen Dingen in das Image 

Sowohl Updates als auch zusätzliche Sprachen können direkt in die Images installiert werden. Eigentlich kann man das Setup komplett individualisieren. Ich möchte das hier nur an Hand von Updates und Sprachen zeigen.
Alles was wir bisher getan haben, passierte direkt in der Image Datei, wir haben immer nur die install.wim "gesehen".
Ab jetzt arbeiten wir innerhalb der Image Datei, dazu müssen wir mounten. Dabei die Struktur innerhalb der Image Datei in einem definierten Verzeichnis zur Verfügung gestellt. Die Basisstruktur haben wir am Anfang schon erzeugt. Um ein bestimmtes Image zu mounten hilft uns folgendes Script:

 ########## Bestimmtes Image mounten, dass Image muss ich mounten wenn ich den Inhalt des Image ändern will, z.B. Updates einspielen  
 # Jetzt Windows Image Indizies anzeigen  
 Get-WindowsImage -ImagePath $DistDir\sources\install.wim  
 # Abfrage Index Nummer  
 $a = read-host "Welches Windows Image mounten? -a- für Abruch"  
 If ($a -eq "a") {Exit 1}   
 Mount-WindowsImage -ImagePath $DistDir\sources\install.wim -Index $a -Path $windowsDir  

Das Mounten des Images funktioniert noch mit jeder Version von dism, wollen wir aber innerhalb der Images manipulieren braucht man eine dism Version mindestens so aktuell wie die Windows Version die wir gemountet haben. Theoretisch könnte man auch unter Windows 8.1 das ADK von Windows 10 installieren und müsste dism dann im ADK Pfad ausführen. Wie die cmdlets von Powershell damit zurecht kommen?

Hinweis:
Bei allen Add Package Kommandos können "0x800f081e" Fehler auftreten. Das angegebene Package ist dann nicht exakt für diese Version und wird ignoriert, das ist nicht weiter schlimm.

Updates

Updates einspielen ist relativ simpel aber Zeitaufwendig. Die Updates können z.B.  mit dem Tool wsusoffline  heruntergeladen wurden.
Beim Aufruf der Scriptzeile muss die Version beachtet werden. (w6.3 --> Windows 8.1)
Eingespielt werden können Updates im cab und msu Format.

 ########## Updates dazu Dazu ist die aktuelle DISM Version notwendig geht also nur unter Windows 10?  
 # Update Verzeichnis wsusoffline   
 $Wsus = "E:\wsusoffline"  
 Add-WindowsPackage –Path $windowsDir –PackagePath $Wsus\client\w63-x64\glb  
 Add-WindowsPackage –Path $windowsDir –PackagePath $Wsus\client\w100-x64\glb  

Je nach Anzahl der Updates kann das ganz schön dauern.

Sprache 

Die Systeme sind auch weitestgehend sprachunabhängig aufgebaut, zusätzliche Sprachen werden einfach über Language Packs (LP) dazu installiert. Zum Verständnis warum es jetzt doch nicht ganz so einfach ist:
  • Wir brauchen ein boot System welches eventuell mehrere Sprachen (auswählen) kann und alle Systemversionen installieren (auswählen) kann.
  • Leider hat MS immer wieder die Bereitstellung und Integration der Sprachpakete verändert, für Windows 10 kann man aktuell die Sprachen nur noch über die Systemsteuerung installieren.
  • Für die Änderung der Startumgebung brauchen wir Teile aus den Windows PE Images. Diese haben wir mit dem ADK schon installiert.
Die folgenden Zeilen integrieren Language Packs in die Setup Images

 ########## Sprachumgebung deutsch und englisch  
 $PathToWinPE_OCs = "$ADKDir\Windows Preinstallation Environment\$Platform\WinPE_OCs"  
 $PackageBoot = @("$PathToWinPE_OCs\WinPE-Setup-Client.cab", "$PathToWinPE_OCs\WinPE-Setup-Server.cab")  
 # Zeige Index des Boot Images   
 Get-WindowsImage -ImagePath $DistDir\sources\boot.wim  
 # Boot Image mounten - nur einmal für Setup Sprache  
 Mount-WindowsImage -ImagePath $DistDir\sources\boot.wim -Index 2 -Path $bootDir  
 #Add Packages - es können 0x800f081e Fehler auftreten  
 #boot  
 $PackageBoot | foreach {Add-WindowsPackage –Path $bootDir –PackagePath $_ }  
 $AddPath = $PathToWinPE_OCs + "\en-us"  
 gci $AddPath | foreach {Add-WindowsPackage –Path $bootDir –PackagePath $_.FullName }  
 $AddPath = $PathToWinPE_OCs + "\de-de"  
 gci $AddPath | foreach {Add-WindowsPackage –Path $bootDir –PackagePath $_.FullName }  
 #Add Language zu Windows  
 #install  
 New-Item $DistDir\langpacks -type directory  
 New-Item $DistDir\langpacks\de-de -type directory  
 Copy-Item $SourceLang\langpacks\de-de\lp.cab $DistDir\langpacks\de-de  
 Add-WindowsPackage –Path $windowsDir –PackagePath $DistDir\langpacks\de-de\lp.cab  
 #Test ob Sprache korrekt  
 & 'DISM.exe' @("/image:$windowsDir", "/distribution:$DistDir", "/Get-Intl")  
 #Defaults Sprache Zeitzone usw. setzen  
 & 'DISM.exe' @("/image:$windowsDir", "/Set-TimeZone:W. Europe Standard Time")  
 & 'DISM.exe' @("/image:$windowsDir", "/Set-AllIntl:de-DE")  
 #Lang-Ini neu machen  
 & 'Dism.exe' @("/image:$bootDir", '/gen-langINI', "/distribution:$DistDir")  
 #& 'Dism.exe' @("/image:$windowsDir", '/gen-langINI', "/distribution:$DistDir")  
 #Die Datei wird in der Quelle erzeugt muss aber auch ins boot.wim  
 Copy-Item $DistDir\sources\lang.ini $bootDir\sources   
   

WIM Datei schließen

Zum Schluss muss die gemountete Image Datei wieder geschlossen werden. Dabei kann man die gemachten Änderungen speichern oder verwerfen:

 ########## Gemountetes Image schließen  
 #Variante commit Image  
 Dismount-WindowsImage -Save -Path $windowsDir  
 Dismount-WindowsImage -Save -Path $bootDir  
 #Variante Discard Image  
 #Dismount-WindowsImage -Discard -Path $windowsDir  
 #Dismount-WindowsImage -Discard -Path $bootDir  

Zwei Architekturen x86 und amd64

Zwei Architekturen in ein install.wim Image zu packen ist relativ einfach, um dann aber wirklich installieren zu können brauchen wir eine Dual Boot Umgebung. Gestartet wird die Installation mittels WindowsPE - wir müssen also eine WindowsPE Dualboot Umgebung bauen. Das wiederum von der neuesten Version. Ich nehme als Ausgangspunkt eine x64 Umgebung und addiere eine x86 Umgebung dazu. Man braucht dazu noch die x86 boot.wim entweder von der x86 DVD (ISO) oder aus dem ADK. Der folgende Script Code ist Beispielhaft und muss der konkreten Situation angepasst werden.

 ############# Für zwei Architekturen x86 und amd64  
 #Dual Boot Image erstellen, Originaleintrag lassen, boot.wim x64 so lassen, boot.wim x86 umbenennen in boot_x86.wim und ins sources verzeichnis kopieren   
 & 'bcdedit' @("/store", "$DistDir\boot\bcd", "/enum") | select-string "osdevice" #Die GUID ermitteln vom Standard  
 #-->{7619dcc8-fafe-11d9-b411-000476eba25f}  
 & 'bcdedit' @("/store", "$DistDir\boot\bcd", "/copy", "{default}", "/d", "Windows Boot X86") # Guid merken  
 #-->{d9b3b7ea-cb40-11e4-8323-000461814078}  
 # Den kopierten Eintrag editieren/ändern  
 & 'bcdedit' @("/store", "$DistDir\boot\bcd", "/set", "{d9b3b7ea-cb40-11e4-8323-000461814078}", "device", "ramdisk=[boot]\sources\boot_x86.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}")  
 & 'bcdedit' @("/store", "$DistDir\boot\bcd", "/set", "{d9b3b7ea-cb40-11e4-8323-000461814078}", "osdevice", "ramdisk=[boot]\sources\boot_x86.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}")  
 # Auswahl bei Win PE aktivieren, braucht man bei Win Setup nicht?  
 #& 'bcdedit' @("/store", "$DistDir\boot\bcd", "/deletevalue", "{default}", "bootmenupolicy")   
 ############# Ende Dualboot  

Empfehlung

Der USB Stick zum Setup ist schnell erzeugt und man braucht keine speziellen Tools. Mehrere Windows Versionen (7, 8, 8.1 und 10 oder auch Server 2008 und 2012) in einer Sprache und einer Prozessor Architektur lassen sich leicht auf einen Stick vereinen. Man hat damit ein universelles Setup Medium an der Hand.
Von Zeit zu Zeit kann man mal Updates integrieren, vor allem wenn Service Packs erschienen sind. Ansonsten ist der Zeitaufwand hierfür relativ groß.
Die Mischung von Sprachversionen und Prozessor Architekturen auf einem Setup Medium ist aufwendig und kompliziert. Lohnt sich meines Erachtens nicht!


Mittwoch, 13. Januar 2016

Feintuning Rollladen

Ich habe Rollladenmotore von Somfy ohne Funkfernsteuerung und Homematic Jalousie Aktoren (verschieden Varianten). An meinen zweiflügligen Fenstern mit getrennten Rolläden habe ich nur einen Aktor verbaut und beide Motore über Trennrelais gekoppelt.

Bei der ersten Einrichtung habe ich mich mit der Stoppuhr hingesetzt, pro Fenstergröße die Fahrzeiten für hoch und runter gemessen, diese in die Register eingetragen und alles war gut.

Ein Freund wies mich kürzlich darauf hin: Die Zeiten die man dort einträgt, die stimmen nicht: der Aktor schaltet länger als der Rollladen fährt. Aufmerksam zugehört und es stimmt, der Aktor schaltet ca. 3 sec länger als die eingetragenen Zeiten. An sich nicht schlimm, der Motor hat ja eine Endabschaltung.

Allerdings kann man die Rollläden ja auch in eine bestimmte Position fahren. Man sagt dem Aktor "geh auf 50%" und die Firmware ermittelt aus den eingetragenen Zeiten die Zeit, die benötigt wird um den Rollladen auf 50% zu bringen - naja so ungefähr.
Je besser die Zeit für hoch und runter an der Echten dran ist, um so genauer. Das Problem bei Rollläden ist ja, dass der Behang beweglich ist, d.h. wenn der Behang  unten ist, ist er noch nicht geschlossen. Eine Öffnung von 50% verstehen wir aber: der Behang verdeckt 50% vom Fenster, dazu muss der Motor von unten kommend aber länger fahren. Kein einfaches Thema, aber braucht man es denn ganz genau?

Werte ermitteln

Ich bin einfach so vorgegangen:

  • Zeiten messen (hatte ich ja schon)
  • Den Wert um 3 reduziert
  • Probelauf, sah eigentlich gut aus, ich habe aber noch etwas weiter probiert:
  • Den Wert noch um 1 sec verringert, den Rollladen in die Endposition gesteuert. Das sah auch noch gut aus. Optisch war die Endposition erreicht.
  • Nach Abschluss der Fahrt habe ich mit dem up bzw. down Kommando versucht ob da noch "Luft" war. Es war, und so habe ich den Wert noch um 0.5 sec korrigiert.

Der Unterschied zwischen auf und ab lag bei mir immer bei 1 sec.

Register setzen

Ich habe nun alle Werte einheitlich in die jeweiligen Fenstergrößen geschrieben und fertig. Dazu einfach ein kleines Script gemacht: einfach Befehlszeile mit Copy & Paste vervielfachen und die Werte anpassen. Anschließen lässt man alles per Copy in die (Telnet)Kommandozeile "fallen"
Einzelne Werte kann man natürlich auch in der Oberfläche "klicken"

Ergebnis

Die 50% Position (zumindest von "offen" angefahren) stimmt jetzt ziemlich gut.
Fahrtzeit down für 50% 11,2 sec
Fahrtzeit up für 50% 11,7 sec
Fahrtzeit down für zu 24,0 sec
Fahrtzeit up für auf 25,3 sec

Man sieht, die Firmware rechnet irgendwie mit.

Ich habe im Forum gelesen, dass mancher es ganz genau haben will. Die Idee ist z.B. die 50% Postion aus beiden Richtungen anzufahren und den Wert für Up und Down immer wieder anzupassen. Diese Arbeit kann man sich sparen, die Rollläden öffnen und schließen mit den so ermittelten Werten nicht mehr richtig.

Montag, 11. Januar 2016

Anwesenheitserkennung

Da gibt es viele Artikel die sich mit der Lösung beschäftigen - aber was ist eigentlich das Problem?

Ich will nicht einfach ein Code Beispiel liefern, ich will vor allem beschreiben, warum es so komplex scheint. Der hier beschriebene Code funktioniert fast vollständig als Trockenübung. In der realen Umgebung müssen einige Definitionen angepasst werden.

Erkennung von Geräten

Heute hat praktisch jeder ein Smartphone. Das WLAN und Bluetooth Modul bieten eine gute Möglichkeit der Erkennung. Wlan durch Anmeldung beim Router, Bluetooth durch einen "Ping" auf die MAC Adresse. Die MAC Adresse ist eine eindeutige Hardware Adresse des Gerätemoduls. Sicher bzw. Fälschungssicher ist diese nicht! Für die Erkennung muss die WLAN und Bluetooth MAC bekannt sein!

Die Anwesenheit der Geräte (Komponenten) wird durch ein PRESENCE Device oder dummy Devices erzeugt. Die Anzahl der Komponenten, die eine Person als vorhanden ermitteln können, kann fast beliebig sein. Dabei gilt:

  • ist ein Gerät vorhanden, ist die Person da. 
  • Sind alle Geräte abwesend ist die Person abwesend.

Alle Geräte (PRESENCE Definitionen) werden dafür einfach in eine structure gepackt. Damit die erwartungsgemäß funktioniert, muss festgelegt werden wie die Komponenten die structure beeinflussen soll. Dies wird durch drei Attribute erreicht: clientstate_behavior, clientstate_priority, event-on-change-reading.

Erkennung von Personen

Die Person selbst wird durch einen dummy device erzeugt. Diese zusätzliche Geräteinstanz ist nötig um einen gewisse Toleranz bei Abwesenheit zu erzeugen (Neustart Gerät, mal kurz im Keller oder vorm Haus usw.) D.h. die Gerätegruppe (structure) wird abgefragt und entsprechend ein dummy gesetzt. Wird die structure als present erkannt, ist jemand gekommen und der Status des dummy wird sofort gesetzt. Wird die structure als absent erkannt, wird eine gewisse Zeit gewartet. Sollte die structure nicht zurück auf present gesetzt werden, wird der Status auf absent gesetzt. Typischerweise nimmt man dafür eine watchdog Funktion. Diese lässt sich ziemlich einfach mit einem DOIF realisieren.

Der Code

Die Definition für FHEM sieht Beispielhaft so aus:
 define Dev11 dummy  
 attr Dev11 event-on-change-reading state  
 attr Dev11 eventMap 0:absent 1:present  
 attr Dev11 room Status  
 attr Dev11 webCmd present:absent  
 define Dev12 dummy  
 attr Dev12 event-on-change-reading state  
 attr Dev12 eventMap 0:absent 1:present  
 attr Dev12 room Status  
 attr Dev12 webCmd present:absent  
 define st_Dev1 structure bewohner Dev11 Dev12  
 attr st_Dev1 clientstate_behavior relative  
 attr st_Dev1 clientstate_priority present|1 absent|0  
 attr st_Dev1 event-on-change-reading state  
 attr st_Dev1 room Status  
 define PersonD1 dummy  
 attr PersonD1 room Status  
 define di_st_Dev1 DOIF ([st_Dev1] eq "absent")(set PersonD1 absent) DOELSEIF ([st_Dev1] eq "present")(set PersonD1 present)  
 attr di_st_Dev1 room Status  
 attr di_st_Dev1 wait 10  

Der Trick mit Telnet

Mittlerweile ist der "Trick" mit Telnet überholt. Aktuell arbeitet man besser mit der Raw Definition.
So landet das Codebeispiel direkt über die Commandzeile in der fhem.cfg

Mit putty (oder einem anderen Terminalprogramm) auf den Host (RaspberryPi) verbinden. Im Terminal folgendes eingeben:

 telnet localhost 7072  

Wenn ein Telnet Passwort vergeben wurde, wird dies abgefragt. Anschließen sooft enter drücken bis der fhem> Prompt erscheint. Jetzt einfach die Codezeilen in die Zeile kopieren.

Die Abfrage der Fritzbox

Um die Fritzbox abzufragen, verwende ich die checkAllFritzMACpresent Funktion aus dem Wiki . Die Fritzbox wird durch ein FRITZBOX Device in FHEM abgebildet.
Ich habe ein DOIF gebaut, das mehrere Geräte abfragen kann. Dazu werden die Geräte Stati in userReadings geschrieben. Bitte die userReadings und dummy's nicht gleich benennen, das führt zu Eigenheiten wenn man etwas loggen will.
 define di_FBAbfrage DOIF ([FB7490:?lastReadout.*]) (set Dev11 [di_FBAbfrage:D11], set Dev21 [di_FBAbfrage:D21])  
 attr di_FBAbfrage do always  
 attr di_FBAbfrage room Status  
 attr di_FBAbfrage userReadings D11 {checkAllFritzMACpresent("AA:BB:CC:DD:EE:FF")}, D21 {checkAllFritzMACpresent("11:22:33:44:55:66")}
 attr di_FBAbfrage wait 2

Das DOIF wird immer getriggert wenn die Fritzbox abgefragt wird. Es pollt also nicht zusätzlich wie die meisten anderen Lösungen. Um sicherzustellen, dass die Abfrage der Fritzbox abgeschlossen und die userReadings gesetzt sind wird mit der commando Ausführung 2 sec gewartet.
Diese Lösung erklärt auch die eventMap Attribute in dem Geräte dummy. Diese übersetzen die Resultate der Subroutine (0|1) in Presenceinformationen (absent|present).

Die Bewohner

Mehrere Personen können jetzt noch in eine structure zusammengefasst werden. Dabei gehen wir analog der Dev1 structure vor. Der zusätzliche dummy und das Watchdog werden nicht benötigt.

define st_Bewohner structure bewohner PersonD1 PersonD2

Damit ist es möglich sowohl Personen als auch Bewohner bezogene Aktionen auszulösen. Hierfür definiert man notify's oder DOIF's die dem Personen dummy oder der Bewohner structur getriggert werden.

Die Skalierung

Steht einmal die gesamte Struktur der Anwesenheitserkennung, gibt es zwei Ansatzpunkte um leicht etwas zu ändern:
Zusätzliches Kriterium der Anwesenheit der Person: einfach zusätzliche definieren und anschließend die Structure der Geräte mit addstruct bzw. delstruct.
addstruct st_Dev1 Dev13
Zusätzliche Person: einfach die Person definieren und mit addstruct bzw. delstruct zur Structure der Bewohner hinzufügen
addstruct st_Bewohner PersonNeu