Donnerstag, 28. Dezember 2017

Netzlaufwerke verbinden Windows 10 Version 1709

Mit der Version 1709 von Windows 10 hat man mal wieder ein verändertes "Anmelde" Verhalten Microsoft hat da wieder kräftig "optimiert" - was (wie schon so oft im Leben von Windows) mal wieder dazu führt, dass Netzlaufwerke nach der Anmeldung mit einem roten Kreuz versehen sind und Applikationen die diese Netzlaufwerke brauchen nicht funktionieren.
Klar, ein Doppelklick auf das rote Kreuz im Explorer behebt das Problem.
Das Verhalten ist davon abhängig wie schnell man sich nach dem Systemstart anmeldet, wartet man erst eine Weile, hat man unter Umständen rote Kreuze an den Laufwerken:

Automatische Abhilfe würde eine kleine Batchdatei schaffen, die man einfach in den Autostartordner des Benutzers legt, der sich anmeldet.
Apropos Autostart Ordner - wo ist der eigentlich? - Der wird seit einigen Windows Versionen auch ziemlich versteckt. Man erreicht ihn eigentlich nur noch über:
Windows + "R"
shell:startup eintippen und enter

Dort erzeugt man eine neue Textdatei mit beliebigen Namen und der Endung bat oder cmd mit folgendem Inhalt:

@echo off
set Server=<Servername>

REM es gibt Problem mit dem find Befehl wenn man sich nicht im Systempfad befindet
cd %SystemRoot%\system32

REM zunächst prüfen ob der Server online ist, wenn nicht Warteschleife
:Loop
ping -n 1 -w 5000 %Server% | find /i "Zeit" && (goto Online)
echo Server %Server% ist nicht erreichbar! 
timemout 10
goto Loop

:Online
REM zunächst Laufwerk löschen und dann wieder verbinden
if exist V: net use /d /yes V: > NUL
net use V: \\%Server%\Videos /yes > NUL

Dieses Script muss man natürlich für Servernamen,  Laufwerk und Share anpassen. Es sind mehrere Laufwerke möglich, einfach die letzen beiden Zeilen kopieren, einfügen und modifizieren.

Eine von vielen alternativen Möglichkeiten diese Datei bei der Anmeldung auszuführen wäre die Aufgabenplanung.

Die Grundlage für mein Script stammt aus dieser Quelle. Es gibt aber ganz wesentliche Änderungen:

  1. find /i "TTL" im Original funktioniert nur für IPV4, bei IPV6 ist die Antwort ohne TTL. Das "Zeit" Feld existiert aber bei beiden IP Versionen. Hier kann sich jederzeit wieder etwas ändern. Insbesondere Sprachabhängigkeiten!
  2. net use im Original forciert nicht die vorhandene Verbindung zu überschreiben. Mit dem Zusatz /yes wird auch eine leicht anders lautende Verbindung für das gleiche Laufwerk überschrieben.

Sonntag, 26. November 2017

Windows Speicherpools umziehen

Was ist ein Speicherpool?

Speicherpools sind ein Windows Feature ab Version 8 bzw. Server 2012. Dabei werden physische Datenträger quasi virtualisiert und es lassen sich allerlei Skalierungs- und Ausfallsicherheitsfeatures einrichten.

            physische Datenträger -> Speicherpool -> virtuelle Datenträger

Wenn man einen solchen Speicherpool von einer Installation auf eine Andere einfach "umstecken" will - also im einfachsten Fall einen Server nicht aktualisieren sondern neu installieren will und die Datenplatten erhalten bleiben sollen, muss man im neuen System den Speicherpool wieder aktivieren. Er wird nicht von selbst wieder eingebunden!

Ansicht in der Datenträgerverwaltung 

Ist der Speicherpool aktiv werden die virtuellen Datenträger angezeigt, die physischen sind nicht zu sehen.
Ist der Speicherpool nicht aktiv, werden die physischen Datenträger offline oder nicht angezeigt.

Einen unbekannten Speicherpool wieder einbinden

Die Verwaltung erfolgt im Servermanager - die ersten beiden Schritte im
-> Datei und Speicherdienste -> Volumes -> Speicherpools

Es ergibt folgendes Bild:
Physischer Datenträger: ok
Virtueller Datenträger und Speicherpool: gelbes Dreieck (unbekannt/getrennt unbekannt/unbekannt)

Man klickt mit mit rechts auf den Speicherpool und wählt "Schreibzugriff festlegen".
Damit verschwindet das gelbe Dreieck vor dem Speicherpool. Offenbar wird dieser Schreibzugriff in den Speicherpool geschrieben, dies ist beim zweiten Versuch nicht mehr wiederholbar.

Danach klickt man rechts auf den virtuellen Datenträger und wählt "virtuellen Datenträger anfügen".

Man wechselt im Servermanager die Ebene für die abschließenden zwei Schritte
-> Datei und Speicherdienste -> Volumes -> Datenträger
Hier erscheint jetzt der virtuelle Datenträger aber mit dem Zusatz offline.
Mit einem Rechtsklick kann man ihn online Schalten, allerdings erhält er den nächsten freien Laufwerksbuchstaben. Den kann man hier aber sofort ändern.

Dieser virtuelle Datenträger (nicht der physische) erscheint jetzt auch in der normalen Datenträgerverwaltung.

Leider ist diese Einbindung noch nicht dauerhaft und würde einen Neustart nicht überleben.
Mit powershell und dem Befehl
Get-VirtualDisk
Sieht man das der virtuelle Datenträger auf "IsManualAttach" steht. Powershell liefert uns die Möglichkeit das zu ändern (Quelle):
Get-VirtualDisk | Where-Object {$_.IsManualAttach –eq $True} | Set-VirtualDisk –IsManualAttach $False

Freitag, 24. November 2017

Acer easystore H340 noch etwas aufpolieren

Der H340 ist zwar schon ein paar Jahre alt, aber für eine Linux basierte NAS ist er immer noch top und das Gehäuse mit 4 x 3,5" Schächten ist schön klein.
Leider braucht man einen Schacht als Systemplatte, das ist in Anbetracht kleiner SSD Platten eigentlich Verschwendung. Das Board hat aber auch nur 4 SATA Anschlüsse. Da ich keine richtig passenden Adapterkombination gefunden habe, musste ich mit dem Lötkolben etwas improvisieren.

Es gibt für unter 10 € den LT304 mSATA /SATA Adapter in verschiedenen Handelsbezeichnungen. Dazu braucht man nur noch eine mSATA  SSD (8, 16 oder 32 GB) für ca. 20 € und ein kurzes SATA Kabel aus der Bastelkiste.

Das BIOS des H340 kann leider nur von den onBoard SATA und USB Anschlüssen booten, deshalb kam mir die Idee: Die mSATA Platte einfach adaptieren und mit dem SATA 1 Anschluss auf dem Board und den SATA 1 Anschluss vom Plattenkäfig mit dem SATA Anschluss des LT304 verbinden. Vom Linux OS wird der SATA Adapter sehr wohl erkannt und unterstützt.
Die Modifikation ist minimal. Die im Bild rot markierten Kondensatoren C31-C34 verbinden den asmedia 1601 Chip mit dem mSATA Connector. Diese lassen sich mit einer breiten Lötkolbenspitze leicht entfernen. Damit ergeben sich auf der linken Seite (dem Connector zugewandt) perfekt vier kleine Lötflächen für das SATA Kabel. Ein SATA Kabel wird einfach in entsprechende Länge (ca. 18 cm) abgeschnitten, kurz abisoliert und in richtiger Reihenfolge angeschlossen.
Das flache SATA Kabel ist 1 zu 1 mit den 7 Pins verbunden, neben Pin 7 liegt die Verdrehsicherung.

Kabel   -> Cxx - Pin mSATA
1 - Gnd -> 
2 - Tx+ -> C34 - Tx+(33)
3 - Tx- -> C33 - Tx-(31)
4 - Gnd -> 
5 - Rx- -> C32 - Rx-(25)
6 - Rx+ -> C31 - Rx+(23)
7 - Gnd -> 
Verdrehsicherung






An der Kante von der Controllerplatine wird das Kabel mit etwas Heißkleber fixiert und kann so nach hinten auf kurzem Wege mit SATA Anschluss 1 auf dem Board verbunden werden. Das Kabel vom Käfig wird einfach an den SATA Anschluss oben am Controller angeschlossen.
Die mSATA  SSD kann praktisch jede x-beliebige Kapazität haben, openmediavault braucht aktuell nur knapp 2 GB an Speicherplatz. Ich habe mich für eine 32 Gb SSD entschieden.

Bei der mechanischen Befestigung muss man etwas in der Bastelkiste suchen, der Controller ist leider ein paar mm höher als Low Profile, so dass kein passendes Slotblech beiliegt. Platz ist aber im H340 genug vorhanden.

openmediavault 1-2-3 fertig

Ein paar Notizen zur Grundeinrichtung

Aktuell gültig für OMV Version 3.086

Manuelle Konfiguration nach der Installation

Ein paar Grundeinstellungen

Immer wenn man die Konfiguration ändert kommt als Abschluss noch ein gelber Balken und man muss den "Anwenden Knopf" drücken. Den kann man auch nach einer Reihe von Änderungen ganz zum Schluß einmal drücken. Wichtig ist im jeweiligen Menü den Speichern Knopf zu drücken

Genaue Zeit
Datum und Zeit
NTP Server benutzen -> aktivieren -> speichern

WOL
Netzwerk
Schnittstellen -> eth0 auswählen -> bearbeiten -> Wake-on-LAN aktivieren -> speichern

Auf Knopfdruck ausschalten
Energieverwaltung
Einschaltknopf -> Herunterfahren -> speichern

Zugang per ssh
Zugriffskontrolle -> Benutzer -> Benutzer auswählen -> bearbeiten
                             -> Gruppen -> ssh anhaken -> speichern -> anwenden

System auf neuesten Stand bringen
Aktuell müssen zwei Pakte mit 0,00 Byte nach der Neuinstallation abgewählt werden, sonst geht die Aktualisierung nicht.

Benutzer zum sudoer machen
Einfach im Terminal (putty)
sudo su
echo "<Benutzer> ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/22_<Benutzer>-nopasswd

Ein öffentliches Share einrichten

Ziel: keine Anmeldung, kein User, kein Passwort

Dateisysteme -> einbinden der vorhandenen Dateisysteme auf den Platten oder Neue anlegen

Freigegebener Ordner
               -> Hinzufügen -> Namen eintragen
               -> Laufwerk auswählen -> Pfad auswählen
               -> Zugriffsrechte -> jeder:lesen/schreiben -> speichern
         Tab ACL -> rekursiv -> Aktivieren -> anwenden -> schließen

SMB/CIFS -> aktivieren -> Local Master Browser deaktivieren -> speichern
     Tab Freigaben -> hinzufügen -> Freigegebenen Ordner auswählen
                             -> Öffentlich -> nur Gäste -> speichern

Hintergrundinformationen

Die Weboberfläche macht bei der Einrichtung eine Kombination aus Ausführung von Debian Systembefehlen und Speichern von Informationen in der /etc/openmediavault/config.xml
Systembefehle werden sofort ausgeführt und eventuelle Meldungen erscheinen im Fenster.
Änderungen in der config.xml werden sofort in der Umgebung aktiv und mit einem gelben Balken angezeigt aber erst bei "Anwenden" in diese Datei geschrieben.
Genau aus diesem Grund gibt es praktisch keine Möglichkeit die gesamte Konfiguration einfach so zu speichern und wieder herzustellen.

Sonntag, 19. November 2017

Openmediavault von Version 2 auf Version 3 aktualisieren

Update oder neu?

Es gibt zwar einen Updatepfad, aber ich habe mich für Neuinstallation entschieden.

Aber es ist relativ entspannt. USB Stick erstellen, booten und Installation starten.
Die Systemplatte wird dabei gelöscht, alle anderen Platten und Partitionen bleiben erhalten und werden sofort wieder eingebunden. Auch Software RAIDs sind kein Problem.

Allerdings müssen alle Freigaben von Hand wieder eingerichtet werden. Meine Konfiguration war aber eher minimal.

Angenehmer Nebeneffekt: Bei meinem H340 funktionierte die Power Off Funktion nicht zuverlässig (sofort Neustart und erst beim zweiten Shutdown wurde die Box ausgeschaltet). Das funktioniert jetzt sauber!

Tipp

Achtung! Unbedingt den Browser Cache nach der Umstellung löschen. Ansonsten erhält man bei jeder Konfigurationsveränderung unklare Fehlermeldungen!

Handbuch OMV

Samstag, 28. Oktober 2017

Hyper-V in in Arbeitsgruppen remote verwalten

Ich habe mal wieder etwas mit Virtualisierungsumgebungen gespielt. Hyper-V 2016 gibt es ja als freie Version ohne GUI. Damit man mit diesem Server arbeiten kann braucht man schon irgendwie den Hyper-V Manager auf einer Remotestation (Windows 10).
Nur leider so einfach geht das nicht. Die Microsoft Dokumentation beschreibt zwar viel, aber nicht alles. Ich habe hier eine Beschreibung gefunden die funktioniert, allerdings waren mir ein paar Dinge nicht ganz klar. Deswegen habe ich das Ganze nochmal aufgearbeitet.

Integrierte Firewall

Beide Maschinen sollten mit privaten Netzwerken verbunden sein. Im Netzwerk und Freigabecenter kann man das überprüfen. Ansonsten greifen die voreingestellten Firewall Regeln nicht.

Namensauflösung

Der Remote Computer muss vom Steuernden Computer per Hostnamen erreichbar sein! IP Adressen und DNS Namen sind zwar prinzipiell verwendbar, aber auch nur der Hostname muss aufgelöst werden. Notfalls muss die Maschine einfach in der Datei c:\windows\system32\drivers\etc\hosts eingetragen werden.

Einrichtung für Windows 10 Pro -> Hyper-V Server 2016

Man öffnet am Besten auf beiden Stationen eine Powershell als Administrator.

Auf dem Hyper-V Server 2016 muss Remote Management und der Credential Security Support Provider aktiviert werden.
Enable-PSRemoting
Enable-WSManCredSSP -Role server

Auf Windows 10 (bzw. steuernder Computer) muss der Hyper-V Manager und die Tools installiert werden und Remote Management  aktiviert werden. Ersteres muss man leider per Hand tun:
  • Im Punkt Windows-Features aktivieren müssen die Hyper-V Verwaltungstools ausgewählt werden. 
Enable-PSRemoting

Um in einer Workgroup eine andere Maschine zu Verwalten muss das Konto der Maschine und ein Admin Konto der zu steuernden Maschine eingetragen werden.
Dazu ein kurzes Script
$server = "<Hostname der zu steuernden Maschine>"
$user = "<lokaler user auf der zu steuerenden Maschine>"
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $server -force
Enable-WSManCredSSP -Role client -DelegateComputer $server -force
cmdkey /add:$server /user:$user /pass
Nach interaktiver Eingabe des Passwortes ist die Konfiguration abgeschlossen.
Nun kann einfach nur der Computername im Hyper-V Manager eingetragen werden und die Verbindung wird hergestellt. Sollte ein Fehler auftreten in Richtung Host wird nicht gefunden oder WinRM Client kann nicht zugreifen, dann bitte die IP Adresse und den Hostnamen in die hosts Datei eingetragen. Warum das so ist weiß ich leider nicht.

Zusätzliche Informationen

Hyper-V Feature installieren

Bei der freien Version Hyper-V Server 2016 sind natürlich alle notwendigen Features installiert. Auf allen anderen Windows und Server Versionen kann man die Installation entweder über Programme und Features oder mit Powershell erfolgen.
Mit Get-<> kann man die möglichen Features ermitteln (3 Varianten):
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V*
Get-WindowsOptionalFeature -Online | ? featurename -match 'Microsoft-Hyper-V*'
Get-WindowsOptionalFeature -FeatureName "Microsoft-Hyper-V*" -online | Format-Table 
Mit Enable-<> oder Disable-<> kann man die Features installieren oder entfernen.
Enable-WindowsOptionalFeature -Online -FeatureName <>
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Tools-All
Leider funktioniert das nicht so wie es in der Doku steht. Ist noch kein Feature von Hyper-V installiert lässt sich keines der Einzelnen Sub-Features mit Powershell installieren. Der übergeordnete Schlüssel wird in der Registry nicht gefunden. Sobald ein Feature installiert ist, können weitere Features auch per PS installiert werden.

Zwischen den Versionen

Die Remote Administration von Hyper-V funktioniert nur einwandfrei untereinander bei gleichen Windows Versionen (Windows 10 und Server 2016). Von Windows 10 einen Hyper-V auf Server 2012 R2 funktioniert nicht. Ob man mit den separaten RSAT Versionen noch etwas erreichen kann habe ich nicht probiert.

Tools, Alternativen und Tipps

Mit cmdkey kann man Anmeldeinformation für Netzwerkobjekte speichern und bearbeiten. Oder man geht in die Systemsteuerung und dort dann:
Systemsteuerung\Benutzerkonten\Anmeldeinformationsverwaltung
Als Dateimanager kann man recht einfach den FreeCommander portabel nachrüsten.

Wird auf der steuernden Maschine selbst ein Hyper-V Host ausgeführt, erzeugt Enable-PSRemoting eine Fehlermeldung. Am Ende funktioniert es trotzdem. Allerdings lässt sich auf einer solchen Station offenbar wegen dem Virtuellen Switch die Netzwerkverbindung (private public) nicht mehr ändern. Die Maske öffnet sich einfach nicht. (Windows 10 pro 1703/Netzwerk und Interneteinstellungen/Status/Verbindungseigenschaften ändern)

Will man nested Hyper-V betreiben, muss man das pro VM aktivieren (Doku):
Set-VMProcessor -VMName <Name der VM> -ExposeVirtualizationExtensions $true

Donnerstag, 5. Oktober 2017

Homematic Nachrichten sniffen

Der Wiki Artikel dazu ist ziemlich kurz.
Nachrichten Sniffen ist im Prinzip loggen mit speziellen Einstellungen. Dazu wird vor allem der HM IO in einen speziellen Log Modus versetzt. Die Nachrichten landen in der zentralen Logdatei von FHEM.

Durch setzen bzw. modifizieren folgender Attribute wird er Sniffer Modus beim Homematic IO aktiviert:
attr global verbose 1
attr global mseclog 1
attr <IO> logIDs <ID1>,<ID2>

Was genau passiert dadurch?
  • verbose 1 schaltet so ziemlich alles aus. Konzentration aufs Wesentliche!
  • mseclog 1 schaltet die "exakte" Zeit ein, es werden die Millisekunden geloggt.
  • logIDs schaltet das Logging für bestimmte HM Komponenten wieder ein. Dabei können mehrere Angaben mit Komma getrennt werden:
    • all - steht für alle Homematic Geräte
    • sys - steht für Systemnachrichten
    • <HMID> - HMID des Gerätes/Channels für ein oder mehrere selektive Geräte/Kanäle

Normales Logging - Sniffen wieder ausschalten


Ist man fertig mit Sniffen löscht man einfach die zusätzlichen Attribute und versetzt das globale Logging wieder in den gewünschten Zustand (Standard verbose 3)
deleteattr global mseclog
deleteattr <IO> logIDs
attr global verbose 3

Mehrere IOs setzen


Man kann den Namen des <IO> durch einen devSpec ersetzen. Z.B. alle IOs die der VCCU zugeordnet sind.
attr own_CCU=VCCU logIDs ID1,ID2

deleteattr own_CCU=VCCU logIDs

Praktisches Beispiel


Ich logge in einer zweiten FHEM Instanz, mein produktives System bleibt wie es ist. Ich sniffe zwei Fernbedienungen
attr global verbose 1
attr global mseclog 1
attr myHmUARTLGW logIDs 101E78,53F520

Wenn man parallel den Event Monitor öffnet kann man sehr gut verfolgen welche Nachrichten und Events zusammengehören. Im Event Monitor muss man dazu folgendes Regexp im Filter eintragen
101E78|53F520

Drücke ich jetzt auf beiden Fernbedienungen kurz eine Taste bekomme ich folgende Einträge im Log

2017.10.05 14:50:57.978 0: HMUARTLGW myHmUARTLGW recv: 01 05 00 00 31 msg: A2 A4 40 101E78 152B02 0264
2017.10.05 14:50:58.110 0: HMUARTLGW myHmUARTLGW recv: 01 05 00 00 3F msg: A2 80 02 152B02 101E78 0101C80048
2017.10.05 14:51:02.752 0: HMUARTLGW myHmUARTLGW recv: 01 05 01 00 37 msg: 3A A2 40 53F520 200DB8 0305

Dazu gehört diese Bild im Event Monitor


Erste einfache Auswertung

Die Nachrichten werden pro Gerät fortlaufend Hex nummeriert (Zahl vor msg:)

Der erste Tastendruck (msg 31) geht von Gerät (101E78) zu Gerät (152B02) und wird quittiert (msg 3F). Diese Taste ist gepeert. 

Der zweite Tastendruck geht (msg 37) vom Gerät (53F520) zur Zentrale (200DB8) und wird nicht quittiert. Diese Taste ist nicht gepeert.

Sonntag, 17. September 2017

Wassermelder mit ESP8266


Die grundlegende Sensormechanik ist dem Homematic Wassermelder entlehnt. In ein Industrie Aufputz Gehäuse IP65 mit den Abmessungen 100x67x50 werden im Boden 5 Spikes eingebaut, ein Spike wird gekürzt um die Möglichkeit eines Wasserstandes zu haben.
Damit ergibt sich eine Bodenfreiheit von ca. 13 mm.
Zwei der Spikes bilden den primären Sensor, läuft Wasser auf dem Boden schließt er den Kontakt zwischen beiden Spikes.


Für die Schaltung braucht man im Wesentlichen neben etwas Draht noch einen ESP12F, 2 x 1 MOhm, 100µF Kondensator und eine Batteriehalterung für zwei AA Batterien.
Ein kleines Stück Universalplatine ein 6 poliger und ein 2 poliger Pfostenstecker sorgen für etwas Komfort beim Aufbau.
Das Schaltungsprinzip geht auf diesen Artikel zurück.

Ich habe aber als Software lediglich ESPEasy aufgespielt.

Funktion

Der Eingang RESET und GPIO16 (D0) wird über einen Jumper verbunden. damit kann man das Modul in den Sleep Modus versetzen und es kann zyklisch oder über den EN Eingang aufwachen.
Der Eingang EN (CH_PD) ist normalerweise über einen Widerstand 1 MOhm nach Masse gezogen, das Modul befindet sich im Sleep Modus und verbraucht nur ca. 16 µA.
Wird der Eingang durch Wasser mit dem Pluspol verbunden (normaler Betrieb) startet das Modul und liefert aktuelle Werte an das ESPEasy Modul von FHEM. Diesen Event kann man in FHEM auswerten.
Der Eingang GPIO14 (D5) wird ebenfalls mit einem Widerstand 1 MOhm nach Masse gezogen und ist mit dem abgesägtem Spike verbunden. Mit ihm könnte "Wasserstand  von ca. 5 mm ermittelt werden.

Betriebsarten

Konfiguration

Das Kabel zu den drei Fühlerspitzen wird entfernt.
Der Jumper wird von den Anschlüssen RST und D0 von J2 entfernt und so auf J6 gesteckt, dass EN und VCC gebrückt werden. Damit startet das Modul im normalen Modus.
Vorsicht, jetzt zieht das Modul dauerhaft ca. 80 mA. Wird es jetzt schon mit Batterie versorgt ist diese nach ca 15 Stunden (oder eher) leer.

Bei einem neuen Modul wird jetzt das Netzwerk konfiguriert.
Grundlegend ist die Konfiguration hier beschrieben

Nach dem Neustart unter dem Reiter Config:

  • ein sinnvoller Unit Name vergeben.
  • FHEM Server eintragen
  • Im Reiter Devices
    • Gerät definieren, System RSSI
    • Gerät definieren, Switch, GPIO14, kein Pullup


Nach dem die Geräte in FHEM automatisch angelegt wurden kann man den ESP in den Sleep Mode schicken: Unter Reiter Config Häkchen setzen. Mit der Zeitspanne in µsec kann man erreichen, dass sich der Melder immer wieder schlafen legt und in diesem Abstand eine erneute Meldung absetzt.

Normaler Betrieb

Jetzt zieht man den Jumper von J6 und steckt ihn auf J2 D0-RST
Das Gerät darf jetzt nicht mehr erreichbar sein.
Die Fühlerspitzen werden mit + EN D5 verbunden.

Reset Konfiguration

Ist das ESP Modul nicht mehr erreichbar oder soll neu konfiguriert werden, kann ESP-Easy zurückgesetzt werden. 
  • Das Kabel zu den Fühlerspitzen wird entfernt.
  • Ein zweiter Jumper wird so gesteckt, das an J6 TX und RX verbunden sind.
  • Der Jumper auf J6 wird so gesteckt, dass EN und VCC gebrückt werden.
Betriebsspannung einschalten und warten bis Wlan ESP_0 zu sehen ist. Dies dauert eine Weile!

Test 

Einfach die beiden Spikes mit feuchtem Finger verbinden, die blaue LED am ESP muss kurz aufleuchten und in FHEM muss ein Event erzeugt werden.

Freitag, 1. September 2017

Homematic Türschließer

Von Homematic gibt es den HM-Sec-Key als automatischen Schließer für jedes normale Türschloß. Die Einrichtung und die mitgelieferte Beschreibung ist nicht so einfach, deshalb hier ein kleines HowTo. Da man sich ganz schnell vertan hat, fange ich mal am Ende der "ersten" Runde an:

Werksreset

Für den Schlossantrieb

  1. Man baut das Gerät vom Schloß ab
  2. Man drückt den kleinen Taster mit einer Spitze für 2 sec, die Anzeige die jetzt erscheint hängt vom vorherigen Zustand ab -> X bei angelernter Master FB oder rotierender Strich in Richtung der Schließrichtung.
  3. Jetzt dreht man das Handrad in Richtung "Schließen", solange bis die Anzeige wechselt. Bei mir war es kurz die 1 und dann sofort der rotierende Strich.
  4. Jetzt dreht man das Handrad in gleicher Richtung weiter, solange bis die Anzeige kurz ausgeht und ein Piep ertönt.
  5. Jetzt sollte das Gerät im Auslieferungszustand sein.

Für die Fernbedienung

  1. Man drückt den kleinen Taster hinten mit einer Spitze für ca. 5 sec bis es langsam blinkt, 
  2. dann lässt man kurz los und drückt wieder ca. 5 sec bis es schnell blinkt,
  3. jetzt loslassen, es hört es kurz auf mit blinken und es erfolgt ein rot grün gelb blinken als Quittung für den Neustart.

Erste Fernbedienung anlernen


Man sollte unbedingt die erste (Master) Fernbedienung an den Antrieb anlernen bevor man eines von beiden Geräten an die Zentrale (FHEM) anlernt! Die Grundeinrichtung muss abgeschlossen sein. Die Masterfernbedienung hat eine besondere Funktion (Sicherheitsabfrage quittieren)
  1. Im Display steht M. Zuerst drückt man die obere Taste (entriegeln) für 2 sec bis die Anzeige nach 1 wechselt.
  2. Innerhalb von 20 sec drückt man kurz den kleinen Taster an der Rückseite der FB mit einer Spitze. Die LED muss jetzt ruhig grün blinken!
  3. Jetzt drückt man an der FB die obere Taste (Schloß zu). Die LED an der FB muss jetzt schnell orange blinken, ein Zeichen der Datenübertragung. Am Antrieb erscheint während des gelben Blinkens nach kurzer Zeit ein Piep und ein M als Quittung. Als Abschluss leuchtet die LED an der FB grün.

Gerät in FHEM anlernen

Türschlossantrieb

  1. Mit set <vccu> hmPairForSec 60 die Zentrale in den Anlernmodus versetzen
  2. Am Antrieb die obere Taste (Schloss auf) 2 sec drücken, die Anzeige wechselt nach X
  3. Mit der Master FB durch drücken einer der beiden Tasten (Schloss auf oder zu) den Vorgang quittieren (Sicherheitsabfrage)
  4. Ein erneuter Anlernversuch wird durch Anzeige von "c" im Display verweigert.

Fernbedienung

  1. Mit set <vccu> hmPairForSec 60 die Zentrale in den Anlernmodus versetzen
  2. An der FB mit einer Spitze die Taste an der Rückseite kurz drücken. Die LED an der FB muss jetzt schnell orange blinken, ein Zeichen der Datenübertragung. Als Abschluss leuchtet die LED an der FB grün.
  3. In der Regel sind jetzt noch nicht alle Daten übertragen, der Anlernvorgang aber angefangen (Gerät ist angelegt aber die Daten sind nicht komplett). Einfach den Vorgang 2. wiederholen. Es wird eine neue Datenübertragung erfolgen.
  4. Ein erneutes Drücken der Taste an der Rückseite wird mit "rot" quittiert und der Anlernversuch damit verweigert.
Den Anlernvorgang an FHEM zum Schluss am Besten mit hmInfo configCheck überprüfen!

Sicherheit - eigenen AES Schlüssel verwenden

Um es klar zu sagen: AES muss nicht eingerichtet werden, AES machen beide Komponenten von Hause aus. Allerdings ist der Systemschlüssel, der in allen Homematic Komponenten gespeichert ist bekannt. Eine Erhöhung der Sicherheit erreicht man also nur mit einem eigenen Schlüssel.
Grundlage ist die Beschreibung im Wiki. Ich will hier die Schritte zusammenfassen

Hier wird noch gearbeitet

Dienstag, 1. August 2017

Raspberry ausschalten mit FHEM

Man kann den Raspberry einfach so vom Strom ziehen - aber schön ist das nicht!
Wenn man schon FHEM drauf hat, kann man sich auch einen Ausschaltknopf auf der Oberfläche machen.
Als erstes muss der User fhem (der User unter dem FHEM läuft) ein reboot oder halt des Systems auch dürfen. Im raspbian kann man dafür einfach ein script an den Pfad /etc/sudoers.d/ anhängen, man braucht die eigentliche sudoers Datei nicht zu editieren.
Hinweis:
Der Benutzer Pi bekommt über genau diesen Weg seine sudo Rechte /etc/sudoers.d/010_pi-nopasswd.

Rechte für User fhem setzen

Wie immer mache ich das gern mit einem Script:
#!/bin/bash
# ergänze eine Datei zum sudoers Script Verzeichnis /etc/sudoers.d/
File="011_fhem-nopasswd"
echo "fhem ALL=(ALL) NOPASSWD: /sbin/reboot, /sbin/shutdown, /sbin/halt" >/etc/sudoers.d/$File
chmod 0440 /etc/sudoers.d/$File
Man kann den Erfolg sofort testen, aber vorher save nicht vergessen, falls man gerade in FHEM etwas geändert hat!
Wenn man in der FHEM Befehlszeile "sudo /sbin/reboot" eingibt, sollte der Raspberry jetzt neu starten.

Bedienelemente in FHEM

Damit man einen Knopf in der Oberfläche von FHEM bekommt, kann man es analog zu diesem Beitrag machen. Dazu braucht man allerdings erstmal einen FHEM Befehl:
define s1 cmdalias reboot AS "sudo /sbin/reboot"
Das kann man wieder sofort testen, in dem man reboot in der Kommandozeile von FHEM eingibt - man muss nur aufpassen, dass dem Raspberry nicht schwindelig wird.
define Systembefehle weblink cmdList Restart:Restart-Fhem:shutdown+restart Restart:Restart-System:reboot Update:Update-Check:update+check Update:Update-Now:update Shutdown:Shutdown-System:halt
Der aufmerksame Leser hat gemerkt: hier fehlt noch etwas! Der alias für halt:
define s2 cmdalias halt AS "sudo /sbin/halt"
Optisch sieht das Ganze so aus:
Mit diesem Befehl kann man den Ausschalter auch links ins Menü packen:
attr WEB menuEntries System-Halt,/fhem?cmd=halt

Ein Script zum Einrichten

Für den ganz Eiligen habe ich hier noch alles in einem Script. Damit man das nicht erst noch ausführbar machen muss, kann man es einfach mit sudo bash <scriptname> starten
#!/bin/bash
# System Befehle für FHEM
File="011_fhem-nopasswd"
echo "fhem ALL=(ALL) NOPASSWD: /sbin/reboot, /sbin/shutdown, /sbin/halt" >/etc/sudoers.d/$File
chmod 0440 /etc/sudoers.d/$File
perl /opt/fhem/fhem.pl 7072 '
define s1 cmdalias reboot AS "sudo /sbin/reboot"
define s2 cmdalias halt AS "sudo /sbin/halt"
define Systembefehle weblink cmdList Restart:Restart-Fhem:shutdown+restart Restart:Restart-System:reboot Update:Update-Check:update+check Update:Update-Now:update Shutdown:Shutdown-System:halt
attr WEB menuEntries System-Befehle,/fhem?detail=Systembefehle
save
'

Kleiner Makel

Beim Restart von FHEM (und damit auch beim Restart System) ist danach der csrf Token vom Link nicht mehr gültig. Der Kontakt von FHEM kehrt also nicht allein zurück. Mit der zurück taste im Browser geht es wieder ins Menü.

Inhalt der sudoers Datei

Die durch Komma getrennten Werte in der Datei haben folgende Bedeutung und benötigen immer den vollen Pfad!

/usr/sbin -> für alles im Verzeichnis
/usr/sbin/service * -> für alle Parameter
/usr/sbin/service apache2 * -> für alle weiteren Parameter
/usr/sbin/service apache2 reload -> genau nur hierfür

Der Aufruf in FHEM muss dann genau dem Schema entsprechen:
"sudo /usr/sbin/service apache2 reload"

Freitag, 14. Juli 2017

Elektrodrachen und so

Fertige IoT Module mit dem ESP Modul gibt es mittlerweile Einige. Von SonOff eine ganze Palette, dazu gibt es auch schon Anleitungen im FHEM Wiki.
Eine Alternative mit nicht so breiter Palette liefert Electrodragon. Ich habe mir zwei Module (SPDT und VDC Version ist die Bezeichnung von Electrodragon) von denen bestellt und möchte die Einbindung in FHEM hier kurz vorstellen.
All diesen Modulen gemeinsam ist, dass sie quasi ohne Lötarbeit für FHEM einsatzbereit gemacht werden können, der Interface Stecker zur Programmierung ist schon vorhanden. Die Module enthalten den ESP 12E Baustein mit 4 MB Flash.
Im Gegensatz zu SonOff liefert Electrodragon keine fertige Software und keine App mit. Diese Module sind für den "normalen Anwender" also nicht brauchbar.

Achtung: 

  1. Niemals die Module programmieren oder im offenen Zustand betreiben wenn sie mit dem Stromnetz verbunden sind!
  2. Die Stromversorgung während der Programmierung erfolgt besser durch eine separate 5 V oder 3,3 Volt Spannungsquelle. Sonst ist der Erfolg beim Flashen nicht gewährleistet. Beim Betrieb mit 3,3 Volt funktionieren die Relais nicht sauber! 
  3. Es sind keine Güte- und Prüfsiegel vorhanden! 

Electrodragon liefert derzeit 3 fertige Relais Module, zwei mit SPST Relais (einfacher Schließer) und eines mit SPDT Relais (Umschalter). Leider ist die Beschreibung im Shop relativ dürftig, es sind aber die Schaltpläne verfügbar. Alle Module verfügen über einen bestückten 12 poligen Steckverbinder zum Anschluss der Programmierumgebung und eventuell weitere Komponenten. Sie verfügen weiterhin um einen vorbereiteten Lötanschluss für einen DHT22. Das SPST Modul mit Niederspannungsversorgung hat zusätzlich einen vorbereiteten Lötanschluss für D0-D3 VCC GND.

Verwendungsmöglichkeiten aus meiner Sicht


SPDT Variante
Separates Netzteil zur Speisung 65-250 Volt AC, der Speiseeingang ist nicht mit den Relaiskontakten verbunden! Die Umschaltkontakte der beiden Relais sind separat herausgeführt. Die Kontakte sind damit potentialfrei.

SPST Variante mit Stromversorgung 85-250 Volt AC
Die Schließerkontakte der beiden Relais sind einseitig bereits mit der Speisespannung verbunden. Dieses Modul ist zum Einsatz von Schaltaufgaben mit minimalem Verkabelungsaufwand im Haushalt gedacht. Die Netzspannung kann auf zwei Verbraucher geschaltet werden, sowohl Versorgung als auch Verbraucher haben separate zweipolige Klemmen.

SPST Variante (VDC Version) mit Niederspannung Gleichstromversorgung 5-24 Volt DC
Im Auslieferungszustand sind die Schließerkontakte der beiden Relais einseitig bereits mit der Speisespannung verbunden. Der Pluspol der Speisespannung kann auf zwei Verbraucher geschaltet werden. 
Das Board bietet aber die Möglichkeit den Pluspol der Speisespannung und Schaltspannung zu trennen. Außerdem bietet es die Möglichkeit das Modul separat mit 5 Volt zu versorgen. Dabei ist die Schaltspannung der beiden Relais wählbar (AC oder DC). 
Die Eingangsspannung kann auf zwei Verbraucher geschaltet werden, sowohl Versorgung als auch Verbraucher haben separate zweipolige Klemmen. Man hat damit auch ein Modul mit Niederspannungsversorgung und zwei potentialfreien Schließerkontakten. 
Die Konfiguration der einzelnen Varianten erfolgt mit Jumpern bzw. Lötbrücken.

Praktisches Einsatzbeispiel

Mein Freund Steffen hat mit einem SPST Modul einen Zwischenstecker realisiert. Für kleines Geld gibt es z.B. bei conrad ein universelles Gehäuse (TRU COMPONENTS TC-SG 1022 SW203) und einen Dichtring (TRU COMPONENTS TC-SG 1015 SW203).

Programmierung

Electrodragon hat eine Art Demo Software vorinstalliert, mit der man einen MQTT Server anbinden kann. Ich will das Modul mit ESPEasy flashen und an FHEM anbinden.
Notwendige Hardware: 
Eine serielle Schnittstelle mit 3,3 Volt Logikpegel! (z.B. FTDI USB Adapter)
Eine 5 Volt oder 3,3 Volt Stromversorgung die etwa 300 mA liefern kann. 

Achtung!
Der typische FTDI Adapter kann nur 50 mA liefern und eignet sich nicht zur Stromversorgung! 
Man könnte das Modul über den 5 Volt Anschluss direkt vom USB versorgen, allerdings hat mein FTDI Adapter dafür kein Pin. Mit dem CP2102 Adapter geht das.

Ich verwende ein Breadboard, eine 5 / 3,3 Volt Stromversorgung fürs Breadboard und einen USB/seriell Adapter (mit CP2102 oder FTDI Chip aber unbedingt (3,3 Volt !) sowie ein paar Steckbrücken.
  • Spannungsversorgung aus!
  • Alle Masseanschlüsse werden verbunden, Spannungsanschlüsse am USB/Seriell Wandler werden nicht mit der separaten Versorgung verbunden
  • Stromversorgung an das Modul, Aufpassen! Entweder -> 5 V an 5 V ODER 3,3, V an 3,3 V
  • RX von der seriellen Schnittstelle an TX vom Modul
  • TX  von der seriellen Schnittstelle an RX vom Modul
  • USB Stecker an USB seriell Adapter
  • Spannungsversorgung ein.
Wird die allgemeine Spannungsversorgung mit verbundenem TX RX aber spannungslosem USB/seriell Wandler hergestellt, kann es sein, dass der ESP nicht richtig startet oder sogar "Factory Reset" durchführt.

Zum flashen muss beim Einschalten der Spannungsversorgung, der BTN2 (BTN) Knopf gedrückt  werden. Als Quittung leuchtet die Status LED dauerhaft. Die Bezeichnung der Knöpfe im Plan und Aufdruck ist nicht ganz konsistent.
Man muss beim Aufbau dafür sorgen, dass man leicht mit einer Hand die Stromversorgung stecken kann (Breadboard und Steckbrücke).
Im Detail ist der Flashvorgang hier beschrieben 

Auf dem SPST/VDC Board ist der zweite Knopf (RST) wirklich der Reset Knopf.
Auf dem SPST (Netzteilversion) /SPDT Board ist der zweite Knopf (BTN1) mit GPIO-02 verbunden. Hier muss der Reset also durch kurze Spannungsunterbrechung erfolgen.

Die Einbindung in FHEM zeige ich in diesem Artikel

Montag, 10. Juli 2017

Einbindung von ESPEasy Schaltern in FHEM

Die aktuellen Informationen findet man in der Doku  und im Forum.
Hier habe ich schon mal die Einbindung beschrieben.
ESPEasy kennt kein Relais Gerät als Output. Es kennt nur einen Switch Input. Ein GPIO Pin wird in dem Moment, wo man einen logischen Zustand setzt, einfach auf Ausgang gesetzt. Beispiel
in der ESPEasy Weboberfläche gpio,12,1
in FHEM set <ESPEasy Device Name> gpio 12 on
Genau genommen bräuchte man in ESPEasy für FHEM nichts definieren, allerdings würde das ESPEasy Modul dann auch kein Gerät erzeugen. Da man von seinem Schalter ja auch Lebenszeichen erhalten will, konfigurieren wir die Übertragung der Feldstärke (rssi) und als Status Rückmeldung einen Switch Input. Der eigentliche Schaltvorgang wird über eine eventMap erzeugt.
Durch die Wahl des Namen auf den Deviceseiten erzeugt man in FHEM ein oder mehrere Geräte. Der Name muss also nicht Unikat sein und soll es für diesen Fall auch nicht! Bei gleichen Namen erzeugt FHEM einfach ein weiteres Reading. Der Name im Feld Value bestimmt den Namen des Reading.

ESPEasy konfigurieren

Nach der WLAN Konfiguration mit dem Smartphone (mit ESP_0 verbinden) kommt man mit http://newdevice auf die Weboberfläche. Ich habe diesmal mit der Version 2.0.0 dev10 gearbeitet.
Die einzelnen Konfigurationsschritte (Seiten) immer mit Submit abschicken und das Häkchen bei Enabled nicht vergessen!

Config
Den Namen setzen: EDSPST1
Der neue Name ist im Browser sofort sichtbar, wirkt als Hostname aber erst nach dem nächsten Neustart.

Controllers
Hier ist ein Wert per default vorkonfiguriert, den ändern wir mit Edit.
Hinweis: Das Feld für Controller User und Password wird nur ausgefüllt wenn in FHEM bei der espBridge das Attribute authentication auf 1 gesetzt ist und die Werte für user und pass übergeben wurden!

Hardware
Keine Änderung.

Devices
Hier konfiguriert man zunächst zwei Geräte für die Relais, welche mit GPIO-12 und GPIO-13 verdrahtet sind.


Zusätzlich konfiguriert man noch den RSSI Wert, damit hat man eine Information über den WiFi Empfang des Moduls und dieser Wert sorgt für permanente Status Updates. Dieses Gerät erzeugt man zweimal, nur der Name wird unterschiedlich SW1 bzw. SW2.

Zum Schluss sieht die Konfiguration so aus

Pro vergebenen Device Namen (Name Spalte) wird von der espBridge ein Gerät erzeugt. Der Value Name (Value Spalte) erzeugt je ein Reading.
In FHEM sind durch diese Konfiguration zwei Geräte mit je zwei Readings entstanden.

FHEM konfigurieren

Durch die Übertragung der rssi Werte hat die espBridge in FHEM zwei Geräte erzeugt mit dem Namen ESPEasy_EDSPST1_SW1 und ESPEasy_EDSPST1_SW2. Diese muss man jetzt noch so konfigurieren, das die Schalter auch bedient werden können. Das wichtigste ist eine eventMap:
attr ESPEasy_EDSPST1_SW1 eventMap /gpio 12 on:on/gpio 12 off:off/
attr ESPEasy_EDSPST1_SW2 eventMap /gpio 13 on:on/gpio 13 off:off/
Damit entstehen on und off Kommandos für den set Befehl und für webCmd. Jetzt kann man die Schaltfunktion prüfen.

Damit der Status richtig angezeigt wird, braucht man noch ein angepasstes stateFormat

attr ESPEasy_EDSPST1_SW1 stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"Switch","")}

Das sieht jetzt schon mal gut aus, ist aber noch nicht perfekt.

Nur mal zur Vollständigkeit die bis hierher komplette Definition, also das automatisch Erzeugte und Ergänzungen/Änderungen:
defmod ESPEasy_ED230V_SW1 ESPEasy 192.168.178.107 80 espBridge ED230V_SW1
attr ESPEasy_ED230V_SW1 IODev espBridge
attr ESPEasy_ED230V_SW1 Interval 300
attr ESPEasy_ED230V_SW1 eventMap /gpio 12 on:on/gpio 12 off:off/
attr ESPEasy_ED230V_SW1 group ESPEasy Device
attr ESPEasy_ED230V_SW1 presenceCheck 1
attr ESPEasy_ED230V_SW1 readingSwitchText 1
attr ESPEasy_ED230V_SW1 room ESPEasy
attr ESPEasy_ED230V_SW1 setState 3
attr ESPEasy_ED230V_SW1 stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"Switch","")}


Mit attr <> setState 0 kann man die interne Erzeugung des state Readings ausschalten. Nun kann man mit verschiedenen Methoden z.B. einem userReadings sein eigenes state erzeugen.
state {ReadingsVal($name,"Switch","") }

Noch die Idee aus dem Forum für on-for-timer muss ich noch probieren

attr <deinEsp> eventMap /longpulse 5 on:on-for-timer/longpulse 5 off:off-for-timer/gpio 5 on:on/gpio 12 off:off/status gpio 15:check/

Hier wird noch gearbeitet ...

Sonntag, 5. März 2017

csrf Token und FHEM

Wenn ich es richtig verstanden habe, gibt es eine Bedrohung wenn man im Browser mehrere Seiten offen hat und eine davon ist "böse". Diese Seite könnte die aktive Anmeldung an einem anderen Webserver ausnutzen und diesen angreifen. Heise hat das hier ganz gut beschrieben.

In FHEM wurde Anfang des Jahres mit der Version 5.8 der csrfToken als eine Abwehr Maßnahme scharf geschaltet. Was leider dazu führt, dass man nicht mehr mit einem einfachen http Link auf das FHEMWEB zugreifen kann.
Was bisher einfach so ging:
curl http://localhost:8083/fhem?cmd=set%20Office%20on
muss jetzt um den Token ergänzt werden. Man beachte auch: die URL muss dafür in Anführungszeichen stehen!
curl "http://localhost:8083/fhem?cmd=set%20Office%20on&fwcsrf="
Mit dem Einzeiler
curl -s -D - 'http://localhost:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}'
kann man den aktuellle csrfToken aus dem Header extrahieren und muss ihn nur noch an den Aufruf anhängen. Das Ganze mit einmaliger Angabe des Hostnamen(IP) und dem FHEM Befehl mit normalen Leerzeichen, sieht so aus:
h='host:Port'; c='FHEM Befehl'; curl --data "fwcsrf=$(curl -s -D - http://$h/fhem?XHR=1 | awk '/X-FHEM-csrfToken/{print $2}')" http://$h/fhem?cmd=$(echo $c|sed 's/ /%20/g')

Da bei Headerfeldern immer ein cr+lf angehängt wird (danke für den Hinweis unten im Kommentar), kann man den ermittelten Token nicht so wie hier kurz gezeigt direkt anhängen.  Diese Zeile
curl "http://localhost:8083/fhem?cmd=set%20Office%20on&XHR=1&fwcsrf="`curl -s -D - 'http://localhost:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}'`
oder auch diese Schreibweise:
curl "http://localhost:8083/fhem?cmd=set%20Office%20on&XHR=1&fwcsrf="$(curl -s -D - 'http://localhost:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}')
führt zu dem Fehler: curl: (3) Illegal characters found in URL

So wird cr+lf verhindert ( Diskussion im Forum ):
curl "http://fhem.example.org:8083/fhem?cmd=set%20Office%20on&XHR=1&fwcsrf="`curl -s -D - 'http://fhem.example.org:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}' | tr -d "\r\n"`
Mir persönlich gefällt die Variante mit -d (--data) besser.

Der csrfToken wird bei einem Neustart von FHEM neu generiert. Bis dahin bleibt er gültig. Hat man mehrere Anweisungen in Folge, genügt es den Token einmal auszulesen und zu speichern. Hier zwei Varianten.
Bash Script:
token=$(curl -s -D - 'http://<host>:8083/fhem?XHR=1' | awk '/X-FHEM-csrfToken/{print $2}')
curl --data "fwcsrf=$token" http://<host>:8083/fhem?cmd=set%20Aktor1%20off
Powershell:
# Wenn man mehr aus dem Request herausziehen will, erstmal in ein Objekt
# UseBasicParsing verhindert die Verwendung des IE und dessen Securityabfragen
$wp=Invoke-WebRequest -UseBasicParsing -Uri "http://<host>:8083/fhem?XHR=1"
$token = $wp.Headers["X-FHEM-csrfToken"]
# Alternativ nur der Token
$token = Invoke-WebRequest -UseBasicParsing -Uri "http://<host>:8083/fhem?XHR=1" | %{$_.Headers["X-FHEM-csrfToken"]}
$URL="http://<host>:8083/fhem?cmd=set%20Aktor1%20on&fwcsrf=$token"
Invoke-WebRequest -UseBasicParsing -Uri $URL | out-null
Um den Zugriff im internen Netzwerk zu vereinfachen, kann man auch ein separates "API Web" ohne Token einrichten:
define WEBapi FHEMWEB <Port> global
attr WEBapi csrfToken none
attr WEBapi allowFrom 192.168.x.x|127.0.0.1
Im Attribute allowfrom wird wird mit einem regEx der IP Adressbereich angegeben. Einzelne Adressen kann man einfach mit | (oder) trennen, Bereiche werden etwas aufwendiger.
Ich würde es aber lesbar und übersichtlich halten, eine Hand voll Adressen geht einfach so:
192.168.178.(1|20|203|124)
Wichtig: Dieses Web für den Zugriff von Maschinen einzurichten, an denen man vom Browser aus arbeitet ist am Thema vorbei!

Donnerstag, 2. Februar 2017

FHEM - die Kommandozeile wird groß

Entwicklungen laufen ja manchmal unbemerkt an einem vorbei. Die Entwickler haben sich was gutes überlegt reden aber meist wenig darüber.
Seit einiger Zeit gibt es unter jeder definierten "Entität" den Punkt Raw definition
Wenn man da drauf klickt öffnet sich ein Fenster mit der Definition und allen zu Attributen und Status Informationen. Man kann die kopieren und an andere Stelle weiterverwenden Sehr einfach und praktisch.
Man kann aber auch einfach etwas verändern, oder auch alles rauslöschen und etwas völlig neues hineinschreiben/kopieren. In dem Moment wo man dies tut, erscheint unten ein neuer Button:
Execute commands. Das kann man wörtlich nehmen, es passiert in diesem Moment nichts unmittelbar in dieser Definition wo man steht, sondern die Zeilen werden geprüft und in FHEM übernommen! Man braucht also kein Telnet Fenster mehr um ganze Code Blöcke zu übernehmen, man muss dazu auch nicht die fhem.cfg direkt editieren (gar nicht zu empfehlen). Im Wiki ist die Sache näher beschrieben. Der kleine Codeblock zum ausprobieren erzeugt einen neuen Menüeintrag im FHEM Web
um schnell auf einen Eingabe Dummy zu springen.
define Import dummy
attr Import group Entwicklung
attr Import room Entwicklung
attr WEB menuEntries CodeImport,/fhem?detail=Import#
Diese Ergänzung wandert direkt in meine Standard Installation.

Mittwoch, 1. Februar 2017

EasyBox zerflashed - und nun?

Ich wollte schon immer mal OpenWrt auf einen alten Router flashen. Um zu sehen wie OpenWrt so geht ...
Man kann ja die alten Dinger durchaus einfach noch zum AccessPoint umkonfigurieren. Sie liegen eh in der Kiste und bevor man was neues kauft!?
Ok, die kleinen Repeater verbrauchen nur um die 2 Watt, so eine EasyBox verbraucht ca. 7 Watt. Die Wirtschaftlichkeit schwindet also innerhalb von 2 Jahren.
Die Anleitungen zum EasyBox 803A flashen sind schon etwas alt, nicht mehr ganz aktuell und die Quellen zu manchen Dateien ziemlich versteckt. Aber nicht nur das, ich habe auch erstmal nicht richtig kapiert was zu tun ist. Ein falscher Befehl und Box bootet nicht mehr, deswegen ein kurzes HowTo mit dem was ich getan habe.
Aktuell Juni 2018: Es gibt eine neues OpenWrt Seite und einen überarbeiteten Artikel, der ist wesentlich besser lesbar als der Alte und ich hoffe die Links sind aktuell.

Vorbereitung

In diesem Wiki steht so ziemlich alles drin was man wissen muss. Ich beschreibe hier nur die wichtigsten Dinge und die Vorgänge die mir nicht klar waren.
Man muss die Box aufmachen um an die serielle Schnittstelle zu kommen. Ich habe einen FTDI Adapter mit 3,3 Volt Interface an meinen Raspberry Pi 2 gesteckt. Der Pi 1 war zum Auslesen der Box irgendwie nicht geeignet. Keine Ahnung warum, das brntool brachte lauter "!" und konnte offenbar nichts lesen! Die UART des Pi selbst hätte sicher auch funktioniert. Mit dem USB Kabel war es irgendwie handlicher.
Die beiden Python Scripte brntool und  ubootwrite  benötigen neben python noch das debian Modul python-serial. Wichtigstes Tool ist ein serielles Terminalprogramm. Ich habe hierbei mit screen gearbeitet -> einfache Kommandozeile und hat gut funktioniert. Auf einem frischen raspbian jessie braucht man nur 2 Pakete installieren:
sudo apt-get update && sudo apt-get install screen python-serial

Das U-Boot

Zentrales Tool zum Zugriff auf die Box ist der Bootloader u-boot. Die richtigen Dateien habe ich nach langer Suche hier gefunden, die Versionen im download bei OpenWrt sind zu alt und unvollständig. Für das temporäre Laden in den RAM wird die Datei openwrt-lantiq-arv752dpw22_brn-u-boot genommen, für das Flashen auf die Box wird die Datei openwrt-lantiq-arv752dpw22_nor-u-boot verwendet. Für das Recover braucht man noch von hier die u-boot.asc.
Hinweis: Der Originale Quelle für diese Datei war https://downloads.openwrt.org/attitude_adjustment/12.09-rc1/lantiq/danube/uboot-lantiq-arv752DPW22_ramboot/
Leider ist diese Datei dort nicht mehr auffindbar. Nur aus diesem Grund biete ich die unveränderte Original Datei hier zum download an.

Terminal

Bei der folgenden Arbeit macht es sich gut zwei Terminalfenster zu öffnen, eines für screen (TS) und eines für Kommandos (TK). Bei der Arbeit mit ubootwrite.py muss screen generell geschlossen werden (ctrl+a k y) bei allen anderen seriellen Zugriffen (cp, sx) war das nicht notwendig.

Datensicherung

Bevor man irgendetwas tut, sollte man wie im wiki beschrieben die Original Firmware sichern! Zweimal oder dreimal und vergleichen. Leider dauert das pro Sicherung ca. 1h!

Dateien bereitstellen

Das aktuelle Image von OpenWrt findet man im download Bereich in den Unterordnern <aktuelle Version>/lantiq/xway/....ARV752DPW22-squashfs.image
Folgende Dateien befinden sich im /home/pi
-rw-r--r-- 1 root root 8388608 Jan 29 21:26 ARV752DPW22_orig.dump
-rwxr-xr-x 1 pi   pi      2964 Jan 29 16:42 brntool.py
-rw-r--r-- 1 pi   pi   4718596 Jan 29 22:15 openwrt-15.05.1-lantiq-xway-ARV752DPW22-squashfs.image
-rw-r--r-- 1 pi   pi    182916 Jan 31 23:35 openwrt-lantiq-arv752dpw22_brn-u-boot.img
-rw-r--r-- 1 pi   pi    185572 Jan 31 23:35 openwrt-lantiq-arv752dpw22_nor-u-boot.img
-rw-r--r-- 1 pi   pi    253039 Jan 30 11:43 u-boot.asc
-rwxr-xr-x 1 pi   pi      7502 Jan 30 12:36 ubootwrite.py

Ich habe bei meinen ersten Versuchen einen Befehl falsch eingegeben, das wars: bootloader gelöscht. Jetzt war Recovery angesagt, deswegen geht es damit los. Das wichtige Bild für den UART Modus muss man sich genau einprägen. Der UART Modus ist handwerklich anspruchsvoll!

HowTo

EasyBox recover auf Original

UART Modus starten:
Kabel mit Spitze an 3,3 Volt serial Connector, spitze Pinzette, Stirnlampe, Lupenbrille, HM Steckdose in FHEM mit 6 Sek Einschaltverzögerung.
TS: screen /dev/ttyUSB0 115200
Spitze oben an R65 halten -> Steckdose ein -> schnell R80 mit Pinzette kurzschließen -> UART Modus muss beim Start erscheinen!
TK: cat u-boot.asc > /dev/ttyUSB0
TS: Bei Aufforderung eine Taste drücken bzw. später crtl+c
TS: screen beenden
TK: python ./ubootwrite.py --addr=0x80040000 --write=/home/pi/ARV752DPW22_orig.dump --verbose
# Warten bis Übertragung von ubootwrite beendet ist!
TS: screen /dev/ttyUSB0 115200
TS: crc32 80040000 00800000
TS: protect off all
TS: erase b0000000 +00800000
TS: cp.b  80040000  b0000000 00800000
Wenn fertig dann Power Reset. Die Box läuft wieder Original

Ohne Fehler auf OpenWrt flashen

Zunächst  wird die Box mit dem originalen brn Boot Loader gestartet, man muss dazu ganz kurz nach dem Start dreimal die Leertaste drücken. Screen muss also beim Einschalten schon aktiv sein!
Anschließend wird u-boot in den Speicher geladen.
Ab Adresse 0x80000000 beginnt der RAM, ab Adresse 0xB0000000 der Flash.
Im Original belegt der Bootloader bis 1FFFF ab 0xB0020000 beginnt das Haupt Image.
Bei OpenWrt belegt der Bootloader bis 3FFFF das Hauptimage beginnt ab 0xB0040000.

u-boot in den Speicher

TS: screen /dev/ttyUSB0 115200
TS: nach Reset -> drei mal space
TS: m startet den Upload in den Speicher 0x80002000
TK: sx openwrt-lantiq-arv752dpw22_brn-u-boot </dev/ttyUSB0 >/dev/ttyUSB0
TS: enter -> Übertragung abwarten dann Y drücken
TS: Bei Aufforderung eine Taste drücken bzw. später crtl+c
TS: screen beenden

u-boot in den Flash schreiben

TK: python ./ubootwrite.py --addr=0x80500000 --write=/home/pi/openwrt-lantiq-arv752dpw22_nor-u-boot.img --verbose
# Warten bis Übertragung von ubootwrite beendet ist!
TS: screen /dev/ttyUSB0 115200
TS: crc32 0x80500000 0x0002D4E4 (Mit der Ausgabe in TK vergleichen)
TS: protect off 0xB0000000 0xB002FFFF
TS: erase 0xB0000000 0xB002FFFF
TS: cp.b 0x80500000 0xB0000000 0x2D4E4
TS: protect on 0xB0000000 0xB002FFFF

Man kann jetzt zum Test booten oder OpenWrt in den Flash schreiben

Wenn der neue u-boot Loader im flash startet war das schon mal erfolgreich.
TS: reset
TS: Bei Aufforderung eine Taste drücken bzw. später crtl+c

OpenWrt in den Flash schreiben

TS: screen beenden
TK: python ./ubootwrite.py --addr=0x80040000 --write=/home/pi/openwrt-15.05.1-lantiq-xway-ARV752DPW22-squashfs.image --verbose
# Warten bis Übertragung von ubootwrite beendet ist!
TS: screen /dev/ttyUSB0 115200
TS: crc32 80040000 00480004 (Mit der Ausgabe in TK vergleichen)
TS: protect off b0040000 +00480004
TS: erase b0040000 +00480004
TS: cp.b  80040000  b0040000 00480004
TS: protect on b0040000 +00480004
TS: reset

Zum Schluss

Das war mein Vorgehen, man muss natürlich nicht das Original zurückschreiben. Diesen Schritt kann man für "nur" OpenWrt überspringen.

Kleiner Nachtrag 5.12.2017

Das OpenWrt Projekt (oder das xxWrt Projekt?) hat sich irgendwie "seitwärts" weiter entwickelt. OpenWrt steht auf dem Stand 15.05 von 2016. Durch etwas "Zufall" findet man das LEDE Projekt und wenn man noch weiter sucht, findet man auch für die Easybox noch aktuelle Downloads und auch die Datei /lantiq/xway/lede-17.01.4-lantiq-xway-ARV8539PW22-squashfs-sysupgrade.bin.
Ich musste die Datei zweimal flashen, beim ersten Mal hat es nicht funktioniert. Eventuell wird beim harten Reset (weil nach dem Flash nix mehr geht) der Speicher freigeräumt ohne den der Flashvorgang nicht möglich ist.
Bei aktuellen Routern sind diese Informationen im Wiki entsprechend verlinkt. Dadurch bin ich drauf gekommen.

Mittwoch, 18. Januar 2017

Ein Remote Taster in FHEM mit Rückmeldung

HowTo

Einfacher Taster

Zielstellung

Ein Dummy mit klickbarem Symbol für die Weboberfläche als "Taster" für verschiedenen Aktionen.

Als erste Komponente stattet man einen dummy mit dem Attribute devStateIcon aus:
define testdummy dummy
attr testdummy devStateIcon _start:on:stop _stop:off:start
attr testdummy event-on-change-reading state
set testdummy _stop

Als Zweites braucht man ein notify welches nur auf die Events start und stop vom testdummy reagiert:
define nty_test notify testdummy:(start|stop) set $NAME _$EVENT

Diese Konstruktion wirkt wie ein toggle Schalter, das Symbol beim dummy ist klickbar und bei jedem Klick schaltet es sichtbar on und off.

Die Rückmeldung des Schalters ist damit vorhanden nur er tut nicht wirklich etwas. Zur Demonstration lassen wir "noch etwas tun":
defmod nty_test notify testdummy:(start|stop) sleep 2;;set $NAME _$EVENT

Jetzt erfolgt die Reaktion auf den Klick mit kurzer Pause, stattdessen kann man natürlich auch etwas sinnvolles tun.

Remote Taster mit Rückmeldung

Zielstellung

Ein "Taster" in der Weboberfläche, der auf einem Remote System z.B. einen Dienst startet oder beendet. Mein Taster soll erst reagieren, wenn der Befehl vom Remote System ausgeführt wurde.

Die System sind mit ssh "gekoppelt", wie das geht steht in meinem vorherigen Beitrag.

Achtung! Seit  März 2017 funktioniert die hier beschriebene Steuerung von FHEM über die Webschnittstelle nicht mehr so einfach. Bitte meinen Beitrag im März beachten.

Demo Script

Auf dem Remote System wird ein Script im Home Verzeichnis des verwendeten Remote Benutzers erzeugt/abgelegt und mit chmod +x test.sh ausführbar gemacht:
#!/bin/sh
# Parameter Übergabe
host=$1
name=$2
event=$3
# Kontrollausgabe zum Test aktivieren
# echo $host $name $event
# Zur Demo ein Sleep
sleep 3
# Abfrage und Verzweigung
case "$event" in
    start)
 # hier kann etwas spezifisches bei Start passieren
    ;;

    stop)
 # hier kann etwas spezifisches bei Stop passieren
    ;;
    *)
       exit 1
    ;;

esac
# Web Kommando an FHEM absetzen
h=$host':8083'; c='set '$name' '$status; curl --data "fwcsrf=$(curl -s -D - http://$h/fhem?XHR=1 | awk '/X-FHEM-csrfToken/{print $2}')" http://$h/fhem?cmd=$(echo $c|sed 's/ /%20/g')

exit 0

Zum Test kann man dieses Script mit ./test.sh <FHEM hostname> testdummy start aufrufen. Dabei muss sich der Status unseres Dummy ändern.

Funktioniert dieser Test, wird das notify geändert, die hostnamen müssen angepasst werden:
defmod nty_test notify testdummy:(start|stop) "ssh pi@<remote hostname> ./test.sh <FHEM hostname>  $NAME $EVENT"

An der Reaktion des Dummy hat sich nicht viel geändert, da ich im Script sleep 3 gesetzt habe dauert es jetzt 1 Sekunde länger. Dafür passiert aber etwas auf einem anderen System!

Praktische Verwendung

Das Demo Script kann so als Grundgerüst verwendet werden. Im einfachsten Fall fügt man an den entsprechende Stellen einfach nur Befehle ein. Komplizierter wird es, wenn man z.B. vor Rückkehr (absetzen des Befehls an FHEM) wirklich überprüfen will/muss ob die gewünschet Aktion auch gelaufen ist.
Das notify kann für mehrere dummy verwendet werden.

Dienst steuern

Um einen Dienst zu starten und zu stoppen muss das Script und der dummy etwas angepasst werden. Zum Testen habe ich meinen Dienst aus diesem Beitrag genommen. Der Name muss entsprechend angepasst werden. Man könnte den Dienstnamen auch im notify übergeben.
Der Steuerbefehl (event) wird nochmal überprüft und übergeben. Nach kurzer Wartezeit wird der Status abgefragt und dieser direkt an FHEM übergeben. Der Status ist also direkt im dummy sichtbar
#!/bin/sh
# Parameter Übergabe
host=$1
name=$2
event=$3
service=<Dienst Name>
# Abfrage und Verzweigung
case "$event" in
    start|stop)
   # Sicherstellen das nur zulässige Events verwendet werden
   sudo systemctl $event $service 
   sleep 2
          status=$(systemctl is-active $service)
   # Web Kommando an FHEM absetzen (neu mit csrfToken)
   h=$host':8083'; c='set '$name' '$status; curl --data "fwcsrf=$(curl -s -D - http://$h/fhem?XHR=1 | awk '/X-FHEM-csrfToken/{print $2}')" http://$h/fhem?cmd=$(echo $c|sed 's/ /%20/g')

    ;;

    *)
      exit 1
    ;;

esac

exit 0

Wenn der Dienst läuft wird er als active erkannt, wenn er gestoppt ist liefert er unknown zurück. Das Mapping des devStateIcon wird einfach angepasst.

attr testdummy devStateIcon active:on:stop unknown:off:start

Montag, 16. Januar 2017

Per ssh Remote Befehle direkt ausführen

Die Secure Shell (ssh) ist auf den meisten Linux System aktiviert. Bedienung und Administration sind ohne ssh kaum vorstellbar. Was da alles so geht zeigt dieser nette Artikel.
Oft will man Dinge Remote per Befehl ausführen, ohne interactive Anmeldung. Einfach Befehl absetzen und fertig, dabei aber sicher und ohne "alle Tore aufzureißen". Glücklicherweise ermöglicht ssh nicht einfach die Übergabe der Benutzerpasswortes im Klartext.
Alle Beschreibungen die ich bisher fand, waren ziemlich kompliziert und ich habe sie am Ende nicht verstanden. Eigentlich ist es ganz einfach, vielleicht schreibt das deswegen kaum jemand auf. Ich beschreibe hier das Verfahren mit rsa Schlüsselaustausch ohne "passphrase". Damit ist sichergestellt, dass ein Benutzer auf einem lokalen System einen anderen Benutzeraccount auf einem Remote System ohne Abfrage eines Passwortes verwenden kann und dort Befehle ausführen kann, da er vorher mit den Schlüssel dazu autorisiert wurde.

Beispiel Scenario

Lokaler Host:
System: Raspbian jessie-lite; Benutzer: Pi - im Terminal angemeldet

Remote Host:
System: Raspbian jessie-lite; Benutzer: Pi - nicht angemeldet

Einrichtung

Alle Aktionen finden im Terminal des "Lokalen Hosts" statt.
# Die Frage nach der passphrase wird zweimal mit enter quittiert, also die passphrase bleibt leer
ssh-keygen -t rsa 
# passwort des remote users wird abgefragt
ssh-copy-id -i ~/.ssh/id_rsa pi@<remote-system>
Achtung!
Es kann sein, dass ssh-copy-id auf dem System nicht verfügbar ist! 
Das Tool ssh-copy-id unterstützt nur .ssh auf dem Zielsystem! Bei OpenWrt z.B. schlägt es sowohl als Quelle als auch Ziel fehl.
In beiden Fällen geht der Einzeiler aus diesem Artikel.

Verwendung

Das war es schon! Jetzt kann man remote z.B. den Status eines Dienstes abfragen, die Ausgabe kommt ins lokale Terminal!
ssh pi@<remote-system> 'sudo systemctl status myservice'

Dienst Benutzer verwenden

Serviceuser sind meist mit passwortlosem Login ausgestattet und die interaktive Anmeldung ist verhindert (z.B. Benutzer fhem). Um für diese Benutzer eine ssh remote Anmeldung zu erstellen sind noch zusätzliche Schritte nötig. Zunächst mal das Login ermöglichen und ein passwort erstellen:
sudo cp /etc/passwd /etc/passwd.sav
sudo nano /etc/passwd
# in der Zeile: fhem:x:999:20::/opt/fhem:/bin/false 
# von /bin/false auf /bin/bash ändern und speichern

Dann für den Benutzer fhem ein Kennwort eingeben
sudo passwd fhem

Nach dem Erstellen des rsa Schlüssels und Test wieder den alten Zustand herstellen
sudo cp /etc/passwd.sav /etc/passwd

Hier noch alle Schritte für den Benutzer fhem in effizienter Form. Ich habe dabei den manuellen Vorgang mit dem Editor nano durch den nicht interaktiven Stream Editor (sed) ersetzt!
sudo cp /etc/passwd /etc/passwd.sav
sudo  sed -i -e 's/fhem:.*/fhem:x:999:20::\/opt\/fhem:\/bin\/bash/' /etc/passwd
sudo passwd fhem             # Passwort vergeben und bestätigen
su fhem                      # Als fhem einloggen, es startet eine neue session!
ssh-keygen -t rsa            # Speichert automatisch in /opt/fhem/
# Achtung ssh-copy-id funktioniert nicht immer! Alternative siehe oben
ssh-copy-id -i ~/.ssh/id_rsa <user>@<remote-system> # gleich den angebotenen Test machen
ssh <user>@<remote-system>   # es startet eine neue session!
exit                         # aus der ssh Test session vom Remotehost!
exit                         # aus der Anmeldung von fhem!  
sudo cp /etc/passwd.sav /etc/passwd
Wenn man es für einen anderen Benutzer (z.B. Pi) schon gemacht hat, geht es eventuell auch einfacher: Artikel im Forum Ich habe das noch nicht getestet!

OpenSSH (Cygwin) für Windows

Mittlerweile ist dieser Abschnitt überholt, ich lasse ihn aber stehen. Am Ende habe ich die Deinstallation ergänzt. Es gibt als zukunftsorientierte Alternative, eine funktionsfähige Anleitung in meinem "Windows hat jetzt ssh" Artikel
Es gibt mehrere OpenSSH Implementierungen für Windows. Die einzige die wirklich wie gewollt funktioniert war für mich Cygwin. Die Installation läuft mehrstufig ab, hier habe ich eine gute Anleitung gefunden.

Installation

Zunächst lädt man nur eine kleine setup-x86_64.exe herunter, diese führt eine Installation mit nachladen aus dem Internet durch. Im ersten Schritt wird der Pfad für die Installation selbst bestimmt, von dort aus könnten weitere Installationen vorgenommen werden.
Dann werden die zu installierenden Pakete ausgewählt, per default ist gar nichts ausgewählt. Man kann mit search und "ssh" die Auswahl erleichtern.

Da ich kein komplettes System brauche wähle ich nur ssh aus. Die dazu notwendigen Pakete wählt das Setup Programm automatisch. Die Installation des Programmes selbst erfolgte bei mir in c:\cygwin64.

Nach der Installation hat man ein Icon "Cygwin64 Terminal" auf dem Desktop, der wird gestartet und ein "vertrautes" Terminalfenster öffnet sich. Dort wird mit ssh-host-config der ssh Daemon installiert.
Es werden eine Reihe Fragen gestellt, die ich so beantwortet habe:
*** Query: Should StrictModes be used? (yes/no) yes
*** Query: Should privilege separation be used? (yes/no) yes
*** Query: new local account 'sshd'? (yes/no) yes
*** Query: Do you want to install sshd as a service?
*** Query: (Say "no" if it is already installed as a service) (yes/no) yes
*** Query: Enter the value of CYGWIN for the daemon: []
...
*** Info: This script plans to use 'cyg_server'.
*** Info: 'cyg_server' will only be used by registered services.
*** Query: Do you want to use a different name? (yes/no) no
*** Query: Create new privileged user account '<host>\cyg_server' (Cygwin name: 'cyg_server')? (yes/no) yes
*** Query: Please enter the password:
*** Query: Reenter:

Jetzt muss der Dienst gestartet werden: 
$ net start sshd
CYGWIN sshd wird gestartet.
CYGWIN sshd wurde erfolgreich gestartet.

Damit der ssh Server nicht durch die Firewall ausgebremst wird, kann man mit folgendem Powershell Befehl noch die entsprechende Ausnahme definieren:
New-NetFirewallRule -Protocol TCP -LocalPort 22 -Direction Inbound -Action Allow -DisplayName SSH
Damit ist die Installation beendet.

Besonderheiten:
  • Der Benutzer Name wird Case Sensitiv verarbeitet, Administrator muss also groß geschrieben werden. 
  • Alle Pfadnamen in Befehlen müssen mit doppelten Backslash geschrieben werden.

Und siehe da, man kann  mit "powershell C:\\Tools\\Scripts\\SendeEmailV2.ps1" auch Powershell Befehle ausführen.
Und natürlich geht der folgende Befehl direkt aus der FHEM Kommandozeile.
"ssh @ 'powershell C:\\Tools\\Scripts\\SendeEmailV2.ps1'"

Die Pfade von Windows müssen aber innerhalb von ' ' stehen! Will man noch Variablen übergeben dürfen die nicht innerhalb ' ' stehen.
"ssh @ 'powershell C:\\Tools\\Scripts\\SendeEmailV2.ps1' $NAME $EVENT"

Deinstallation

das Setup erzeugt leider keine Deinstallation, man muss es manuell bewerkstelligen. Die Grundlage für den folgenden Code habe ich aus dem Cygwin Wiki.
# Den Service anhalten und entfernen
# Remove-Service existiert erst ab Powershell 6
Get-Service -DisplayName CYGWIN*|Stop-Service
C:\cygwin64\bin\cygrunsrv -E sshd
C:\cygwin64\bin\cygrunsrv -R sshd
# Prüfen ob der Service entfernt ist
Get-Service -DisplayName CYGWIN*

# cygwin Benutzer löschen
Get-LocalUser sshd|Remove-LocalUser
Get-LocalUser cyg*|Remove-LocalUser

# Registry Key löschen und prüfen
Test-Path HKLM:\Software\Cygwin
gci HKLM:\Software\Cygwin
Remove-Item HKLM:\Software\Cygwin

# Firewall Regel löschen
get-NetFirewallRule -DisplayName ssh*|Remove-NetFirewallRule

# Noch ein paar Pfade/Dateien löschen, einfach mit dem explorer
# C:\cygwin64, User profil von sshd und cyg*, Verknüpfungen auf dem Desktop 

Public Key für die Windows Anmeldung einrichten

Die Sache mit dem Public Key funktioniert nicht ganz so einfach wie unter Linux.
Aber ich war nicht der erste und habe hier ein gute Anleitung gefunden. Diese ist ziemlich umfangreich, deshalb habe ich diese Schritte herausgepickt:

Homedirectory auf Windows vorbereiten. 

Am einfachsten mit Putty am neuen Windows Server ssh anmelden. Dann steht man gleich im Anmelde Fenster im Homedirectory des Benutzers.
ssh <user>@<remote-system>
mkdir .ssh
cd .ssh
mkdir otherkeys

Public Key kopieren

Jetzt vom Raspberry: Achtung! Die Datei authorized_keys wird mit dem Befehl neu erzeugt/überschrieben:
su fhem
scp ~/.ssh/id_rsa.pub <user>@<remote-system>:.ssh/authorized_keys

Das wars, die ssh Anmeldung ohne Passwort sollte funktionieren.

Ärger mit known_hosts

Hat man den Ziel Host unter altem Namen oder gleicher IP neu installiert, funktioniert der alte Eintrag in der Datei .ssh/known_hosts nicht mehr. Der lässt sich nicht einfach überschreiben, man muss ihn vorher löschen. Hat man Hostname und IP-Adresse verwendet, existieren mehrere Einträge!
ssh-keygen -R <Hostname>
ssh-keygen -R <IP Adresse>

Hat man den Namen oder die IP Adresse geändert, muss ein neuer Eintrag geschrieben werden. Dazu muss man nicht zwingend wieder unter anderem Namen (fhem) angemeldet sein.
Diese Methode eignet sich auch, wenn man den Eintrag in der known_host ohne Benutzer-Interaktion vornehmen will/muss.
sudo su
ssh-keyscan -H <Hostname/IP-Adresse> >> /opt/fhem/.ssh/known_hosts

Die Einträge lassen sich mit ssh-keygen auch auflisten, im Beispiel vom aktiven User
ssh-keygen -l -f ~/.ssh/known_hosts

Sicherheit

Wie sicher ist das Ganze?

Per default erzeugt ssh-keygen 2048 bit Schlüssel, diese gelten als sicher. Die Dateien sind im Benutzerverzeichnis gesichert. Nur der öffentliche Schlüssel ist von anderen Benutzern lesbar. Der Remotehost ist verschlüsselt abgelegt.
-rw------- 1 pi pi 1679 Jan 16 14:06 id_rsa
-rw-r--r-- 1 pi pi  392 Jan 16 14:06 id_rsa.pub
-rw-r--r-- 1 pi pi  444 Jan  8 19:21 known_hosts

Lässt sich die Sicherheit erhöhen?

ssh-keygen -t rsa -b 4096
Private key in pkcs8 wandeln. -> https://www.mittwald.de/blog/mittwald/howtos/ssh-key-erstellen
Schlüssel mit passphrase erzeugen und ssh-agent verwenden oder hier.

In dem Artikel  ist auch beschrieben, wie man den ssh  Zugang zu Windows für Passwort Abfragen sperren kann, dann ist nur noch Anmeldung per Public Key möglich.

Falsche Rechte im Home Directory

Das Home Directory hat per default die Rechte Maske 755. Die obige Procedure setzt zwar die Rechte auf die .ssh Dateien, ist aber die Ordner Struktur darüber mit falschen Berechtigungen ausgestattet, wird eine Verwendung der Key Dateien vom System offenbar als "Unsicher" verhindert. Falls etwas nicht funktioniert, überprüfen:
/home/pi/.ssh:

drwx------ 2 pi pi 4096 Nov 24 17:50 .
drwxr-xr-x 3 pi pi 4096 Oct 25 14:32 ..
-rw------- 1 pi pi 1679 Jan 16  2017 id_rsa
-rw-r--r-- 1 pi pi  392 Jan 16  2017 id_rsa.pub
-rw------- 1 pi pi 1552 Nov 24 17:49 known_hosts
Siehe Beitrag im Forum.

Sudo und Passwortabfrage

Beim Benutzer pi wird das sudo Passwort nicht abgefragt, bei anderen Benutzern schon!? Ganz einfach: Die Datei /etc/sudoers enthält am Ende die Zeile #includedir /etc/sudoers.d obwohl auch in dieser Datei das Doppelkreuz für auskommentiert steht, ist es in dieser Zeile nicht so! Diese Zeile bewirkt, dass alle weiteren Dateien im Verzeichnis /etc/sudoers.d importiert werden. Unter raspbian gibt es dort eine Datei /etc/sudoers.d/010_pi-nopasswd diese enthält genau die eine Zeile, womit typischerweise die Passwortabfrage für sudo "für alles" ausgeschaltet wird.