Wake On Lan über "Dritte"

Zum Thema Wake On Lan habe ich ja schon ein paar Artikel geschrieben. Es gibt Situationen, da erreicht das Magic Paket nicht direkt sein Ziel. Falls also auch der "directed Broadcast" nicht funktioniert, ist vielleicht der "Agent" im Zielnetz eine Lösung!?

Auslöser für diese Notiz war dieser Beitrag im Forum.

Ein Magic Paket aus einer MAC Adresse zu bauen ist keine große Wissenschaft, dieses Paket muss man dann einfach per UDP und Port 9 ins Zielnetz schicken. Viel Code ist zur Lösung nicht nötig, das Meiste ist wie immer das User Interface und Fehlerbehandlung. 

Mir fallen drei Lösungsansätze ein, alle benötigen keine erhöhten Rechte!

Voraussetzung: ssh Verbindung mit public Key ist eingerichtet und funktioniert!

Linux Host

Auf der Suche nach einem simplen Script bin ich nur bei einer Perl Lösung fündig geworden, eine Lösung mit netcat werde ich noch bereitstellen. 

Das Setup auf dem "Remote Agenten" kann man dann auch gleich per ssh machen:

ssh user@host 'wget -qO wakeonlan https://raw.githubusercontent.com/jpoliv/wakeonlan/master/wakeonlan;chmod +x wakeonlan'

Das Script wird heruntergeladen und ausführbar gemacht. Dann ist die Verwendung simpel: 

• mac Adresse übergeben
• Parameter -q für quiet Modus
• Parameter -i für eine directed Broadcast Adresse.

ssh user@host ./wakeonlan -q 12:34:56:AB:CD:EF

Windows Host

Ich hatte da mal ein PowerShellScript gemacht. Windows kann auch ssh, also kann man auch per ssh die Einrichtung und Steuerung vornehmen.

Fritzbox und TR064

Falls die Fritzbox als zentraler Router dient und die MAC Adressen dort registriert sind, kann man auch die Fritzbox benutzen um das Gerät per WOL zu starten. Per FHEM geht das simpel. Es gibt auch Powershellscripte dafür.

get <FritzBoxName> tr064Command Hosts:1 hosts X_AVM-DE_WakeOnLANByMACAddress NewMACAddress "12:34:56:78:9A:BC"

Definition in FHEM

Das WOL Modul in FHEM bietet mittlerweile den CMD Modus. Hier kann man separate Befehle zum aufwecken angeben, das Ganze auch über ssh (siehe den Link oben). 

In wolCmd steht ein FHEM Befehl. Der Platzhalter $MAC wird bei der Ausführung durch die mac Adresse in der Definition ersetzt.

Beispiel mit der Fritzbox:

Das Gerät muss in der Fritzbox registriert sein! Die Fritzbox kann Broadcast nur im eigenen Netzwerk! 

attr WolDevice wolCmd get Fritzbox tr064Command Hosts:1 hosts X_AVM-DE_WakeOnLANByMACAddress NewMACAddress $MAC

Beispiel mit Remote Host und ssh

Wir brauchen 3 Dinge - ausgeführt so als Block in der Raw Definition:

1. Das Programm/Script auf dem Agenten,
2. den Shell Befehl der auf dem Agenten ausgeführt werden soll,
3. den sshHost in üblicher Form.

"ssh user@host 'wget -qO wakeonlan https://raw.githubusercontent.com/jpoliv/wakeonlan/master/wakeonlan;;chmod +x wakeonlan'"
attr WolDevice wolCmd "./wakeonlan -q $MAC"
attr WolDevice sshHost user@host

CodeSpace

ssh mit public key

ich habe dazu schon mehrfach was geschrieben - aber man lernt ja immer wieder dazu. Deshalb noch ein ziemlich komprimierter Artikel: 

Ein HowTo für die Automatisierung von Remote Aufgaben in FHEM über ssh. 

Nachtrag 2023: Es gibt einen neuen Artikel, der die Einrichtung ganz kompakt mit einem Script zeigt.

Crash Recovery

Das System verhält sich komisch? Raspbian bleibt beim Start hängen?

Die SD Card als Datenträger beim Raspberry soll ja häufig den Geist aufgeben. Ich hatte das noch nie, ich behaupte immer das passiert bevorzugt wenn Datenbanken im Spiel sind - aber jetzt hatte es einen Kumpel aus heiterem Himmel getroffen. Ohne Datenbank, ohne aktuellem Backup. Ich konnte ihm helfen und daraus ist dieser Artikel geworden.

Was tun?

Zutaten

• Neue SD Card für das neue System, Größe "egal"
• USB Stick oder zweite SD Card + Reader mit dem Speicherplatz mindestens der alten SD Card.
• Image Tool  (win32diskimager, USB Image Tool, Etcher oder mit Linux Bordmitteln dd.)

In jedem Fall eine Kopie der SD Card anfertigen: Imagedatei ablegen.

Die Originalkarte sollte nicht weiter manipuliert werden und meist ist eine Reparatur der defekten Karte weder sinnvoll noch möglich!

Den Raspberry neu machen

• neue SD Card, 
• aktuelles Raspbian Image aufspielen, 
• starten, 
• System und FHEM Setup.

An der Stelle der Hinweis, auf diesen Artikel falls man nicht mehr weiß, welche Perl Module für die persönliche Installation nötig sind.

systemctl stop fhem

Dateisystem prüfen und Zugriff herstellen

Die 1:1 Kopie auf dem USB Stick (oder SD Card in SD Reader) in den Raspberry stecken. 

Achtung: Das geht bei einem Pi ab Version 2 nach meiner Erfahrung gut. Ein 1er Exemplar würde ich zum Stecken herunterfahren, er wird beim einstecken von selbst neu starten. 

Oder die Imagedatei direkt mounten, siehe weiter unten.

Danach sollte sich folgendes Bild ergeben:

pi@raspib31:~ $ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1 29,8G  0 disk
├─sda1        8:1    1 41,7M  0 part
└─sda2        8:2    1   15G  0 part
mmcblk0     179:0    0 14,9G  0 disk
├─mmcblk0p1 179:1    0  256M  0 part /boot
└─mmcblk0p2 179:2    0 14,7G  0 part /

Der USB "Stick" wird als sda erkannt, die interessante Partition ist sda2. Für die jetzt folgende Reparatur darf sda2 nicht gemountet sein/werden! 

Ein erster Check ohne Optionen erledigt offenbar schon mal alles, mir ist nicht klar in welchem Fall welche zusätzlichen Optionen (oft empfohlen -l, Hilfe mit -h) notwendig sind.

Alle weiteren Befehle erfordern erhöhte Rechte, deswegen erstmal sudo su. 

Die Ausgabe ist nur ein Beispiel und kann je nach Fehler völlig anders sein!

sudo su
fsck /dev/sda2
# fsck from util-linux 2.33.1
# e2fsck 1.44.5 (15-Dec-2018)
# /dev/sda2: recovering journal
# Setting free inodes count to 899857 (was 899863)
# Setting free blocks count to 3338902 (was 3339342)
# /dev/sda2: clean, 46703/946560 files, 577130/3916032 blocks

SD Card mounten 

Jetzt die interessante Partition mounten und hoffen dass etwas lesbar ist.

mkdir /mnt/sda2
mount /dev/sda2 /mnt/sda2

Alte Dateien kopieren

Alle Dateien von dem alten System werden kopiert und die Rechte entsprechend gesetzt, zuletzt wird das USB Gerät ausgeworfen. In der Hoffnung, dass nichts wichtiges kaputt ist!

Idee: Man könnte die Backup Dateien ausschließen  oder rsync verwenden.

cp -R /mnt/sda2/opt/fhem/* /opt/fhem/
chown -R fhem: /opt/fhem/
umount /mnt/sda2

System prüfen

systemctl start fhem

Das kann eine Weile dauern, z.B. wenn Moduldateien fehlerhaft sind. Der Ungeduldige kann derweil ins Log schauen.

tail /opt/fhem/log/fhem-$(date +%Y)-$(date +%m).log

Wenn das System Fehler zu defekten Modulen liefert, nach dem Start in FHEM erstmal ein update versuchen.

update force

Neu starten und System wieder prüfen

systemctl restart fhem

Wenn es doch nicht läuft

• Es fehlen System Pakete? Da hatte ich hier schon mal was geschrieben.
• Wenigsten mit der fhem.cfg neu anfangen, notfalls eine Alte aus dem restoreDir pfad. Siehe Wikiartikel.
• Ist eine Backupdatei in /opt/fhem/backup vorhanden? Einfach das letzte Backup versuchen, siehe hier.

Alternative - Image Datei direkt mounten

Die kopierte Image Datei wird direkt als Block Laufwerk eingebunden. Ich habe dazu hier eine gute Erklärung gefunden. Das sieht alles etwas komplizierter aus, aber eigentlich spart man die Zeit für die Kopie auf den USB Stick und man muss nichts stecken.

Tipp: Image mit linux erstellen:

sudo dd if=/dev/sdX of=./kopieSdDefekt.img bs=4M status=progress

Zunächst den Pfad zum Image z.B. über cifs (SMB) einbinden:

sudo su
# SMB Laufwerk mounten
mp="/mnt/daten"
mkdir $mp
mount -t cifs -o username=UserName,password=Passwort //server/sicherung $mp
# Loop Device erstellen
img="$mp/fhem/raspib3/kopieSdDefekt.img"
ldev=$(losetup --show -f -P "$img")

An der Stelle hat man quasi "den USB Stick gesteckt" d.h. man hat einen /dev/ Eintrag den man wie ein angeschlossenes Laufwerk behandeln kann. Dies(e) Gerät(e) anzeigen:

losetup -l

Jetzt kann man wie oben beschrieben fsck ausführen. dafür kann man einfach die Variable $ldev verwenden:

fsck ${ldev}p2

Ist der Vorgang erfolgreich kann man die Partitionen mounten:

Achtung: Diese Schleife mounted nicht, sie gibt nur die Befehle aus!

#Alle Partitionen mounten
for part in ${ldev}p*
do 
  dst=/mnt/$(basename $part)
  echo "mkdir $dst"
  echo "mount $part $dst"
done

Nachdem man analog zu oben die Dateien kopiert hat, kann man alles wieder aufräumen:

umount /mnt/loop0*
rm -R /mnt/loop0*
losetup -D        #losetup -d $ldev
umount $mp

Backup einrichten!

Siehe dazu auch meinem Artikel zur externen Sicherung des FHEM backups.

Worx Landroid per MQTT

Vor einem Jahr habe ich den neuen Mähroboter an FHEM angebunden. Nach einiger Zeit wurde mir irgendwie klar: Die Cloud Anbindung des Roboters läuft doch mit MQTT!?

Die Anbindung über zwei nodejs Services und ein FHEM Modul erschien mir ziemlich aufwendig:

 Cloud-MQTT - iobroker.worx - fhem-landroid-s - 74_LANDROID.pm

Ein Beitrag im Forum gab die entscheidenden Hinweise. Ich habe das ganze noch etwas weiter geführt und mich dabei auch mal etwas eingehender mit attrTemplate beschäftigt.

Vorbereitung

Zur Vorbereitung der Installation braucht man ein Tool um die Informationen für den Zugang zum Cloudserver zu bekommen.

• Broker Server Adresse
• Board ID z.B. bei den 2019 Modellen PRM100
• Mac zwölf stellig
• SSL Zertifikat AWS.p12
• Eine neue Uuid -> kann einfach selbst erzeugt werden: 
• cat /proc/sys/kernel/random/uuid 
• oder im Browser hier .

Ich habe die Version V0.0.24 - Net.zip verwendet. Das Tool erfordert keine Installation. Man trägt einfach seinen Cloudzugang ein, nach der Verbindung zeigt das Tool die notwendigen Daten und das Zertifikat liegt im gleichen Pfad.

Das Zertifikat muss noch zerlegt werden, um es in FHEM mit MQTT2_CLIENT verwenden zu können.

Einrichtung

Mit scp kopiert man die Datei AWS.p12 auf den FHEM Server: 

scp "d:\Downloads\V0.0.24 - Net\AWS.p12" pi@raspib3:

Ab hier sind die Befehle für die FHEM Kommandozeile oder die Raw Definition aufbereitet!

Das Zertifikat muss zerlegt werden damit fhem die Dateien verwenden kann.

"openssl pkcs12 -in /home/pi/AWS.p12 -nokeys -passin pass: -out aws.cer -clcerts"
"openssl pkcs12 -in /home/pi/AWS.p12 -nodes -passin pass: -out aws.key -nocerts"
"chmod 0600 aws.*"

Die Template Datei kann man jederzeit aktualisieren ohne ein komplettes Update machen zu müssen. Nichtsdestotrotz muss FHEM halbwegs aktuell sein und attrTemplate funktioniert.

{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }

Jetzt in FHEM den Connector zum Broker herstellen und testen.

define MQTT_Worx MQTT2_CLIENT <broker-server-adresse>:8883
attr MQTT_Worx SSL 1
attr MQTT_Worx autocreate simple
{my $uuid=qx(cat /proc/sys/kernel/random/uuid);;fhem("attr MQTT_Worx clientId android-$uuid")}
attr MQTT_Worx keepaliveTimeout 600
attr MQTT_Worx mqttVersion 3.1.1
attr MQTT_Worx msgAfterConnect <BoardID>/<MAC>/commandIn {}
attr MQTT_Worx sslargs SSL_version:TLSv12 SSL_cert_file:aws.cer SSL_key_file:aws.key SSL_use_cert:1
attr MQTT_Worx subscriptions <BoardID>/<MAC>/commandOut

Hat man alles richtig gemacht, geht der state des Devices MQTT_Worx sofort auf opened.

Wechselt der Status hektisch zwischen opened und disconnected stimmt etwas mit dem Zertifikat nicht.

Die erste Übertragung sollte automatisch ein neues MQTT_DEVICE erstellen.

Auf dieses Device wird jetzt das Template angewendet und damit konfiguriert.

set MQTT2_.*:FILTER=IODev=MQTT_Worx attrTemplate worx_landroid

Die Readings und die Steuerung sind ähnlich das Moduls 74_LANDROID.pm
Problemlösung
Bleibt der Connector MQTT_Worx auf disconnected -> die Zertifikate prüfen:

{qx(ls -lha /opt/fhem/aws.*)}

Das Ergebnis sollte in etwa so aussehen:

-rw------- 1 fhem dialout 1.4K Jun  9 13:27 /opt/fhem/aws.cer
-rw------- 1 fhem dialout 1.8K Jun  9 13:27 /opt/fhem/aws.key/

Support

Es gibt dazu auch einen Beitrag im Forum.

sonos2mqtt - so weit bin ich

Ich habe derzeit die aktuellste Anleitung ins FHEM Wiki geschrieben, aufgeteilt in 2 Artikel.

sonos2mqtt ist (ein 2 Jahre altes?) Projekt welches aktiv entwickelt wird, offenbar primär für die Anbindung an Homeassistent. Aber von der Sache her ist es eine Bridge Sonos - MQTT.
Ich habe die "lokale Installation" gewählt (es gibt auch eine Docker Version).
Aus meiner Sicht ist die Sache unkritisch, man kann es in jede Umgebung einbinden.

Voraussetzungen für diese Anleitung

• Nodejs und pm2 installiert - Anleitung
• MQTT2_SERVER bereits in FHEM definiert - Anleitung.
• Damit die Automatik funktioniert: autocreate simple (default) 
• FHEM aktuell - Stand mindestens 28.7.2020
• Alles läuft auf einer Maschine (localhost)

Setup auf Systemebene

Diese Abschnitt wird auf der Kommandoebene von Linux ausgeführt (Terminal).
Man installiert die aktuelle sonos2mqtt Release Version (siehe Projekt Webseite):

sudo npm install -g sonos2mqtt

Es wird derzeit heftig entwickelt, die Installation oder Aktualisierung auf eine neue Beta Version geht mit dem gleichen Befehl und der Zusatz Angabe zur Beta, Beispiel "sonos2mqtt@3.0.6-beta.3".

Man kann kurz überprüfen ob bisher alles gut gegangen ist und die Version abfragen:

node /usr/lib/node_modules/sonos2mqtt --version

Setup in FHEM

Die Einbindung in FHEM erfolgt wesentlich mit generischen MQTT2_DEVICEs. Eine Bridgedevice fungiert als Verteil- und Auffangstation für MQTT Nachrichten. Dadurch werden die Player als separate MQTT2_DEVICEs erzeugt. Ein paar Templates vereinfachen die Konfiguration.

Der folgende Code ist für die Raw Definiton bzw. Kommandozeile von FHEM und realisiert diese Schritte:

• definiere die Bridge mit Template, der Topic (default: sonos) wird abgefragt!
• Das Template definiert 2 notify welche die Player automatisch konfigurieren:
• Das Erste wird getriggert wenn ein MQTT2_RINCON_ Device definiert wird. Es wird das Basistemplate für Player angewendet und die Abfrage der ZonenInfo gestartet.
• Das Zweite wird beim Eintreffen der ZonenInfo gestartet und konfiguriert den Player "fein".  
• starte die sonos2mqtt Bridge auf Systemebene im Kontext User fhem
• nach kurzer Zeit sollten die Player fertig sein.

Nur falls es noch keinen MQTT2_SERVER gibt:

define mqtt2s MQTT2_SERVER 1883 global
attr mqtt2s room MQTT_IO

Falls ein existierender MQTT2_SERVER verwendet wird, bitte unbedingt prüfen - das autocreate auf simple steht!

Der folgende Codeschnipsel richtet die Bridge manuell ein und startet die automatische Erzeugung der Player. 

define SonosBridge MQTT2_DEVICE
attr SonosBridge IODev mqtt2s
attr SonosBridge room MQTT2_DEVICE
define n_pm2_sonos notify global:INITIALIZED "pm2 -s start sonos2mqtt"
sleep global:ATTR.SonosBridge.stateFormat.connected;trigger n_pm2_sonos start
set SonosBridge attrTemplate sonos2mqtt_bridge_comfort

Ist die Bridge schon automatisch erzeugt worden, wendet man nur das Template an. (Dann ist ein rename empfohlen!)
Nach wenigen Sekunden sollten alle Player sichtbar sein. Die haben eine schlichte Oberfläche und ein paar Dinge fehlen noch. Das ganze ist aber sowieso mehr ein Baukasten als ein fertiges Modul.

Sprachausgabe - der "speak" Befehl mit Boardmitteln

Gegenüber der Beschreibung im Wiki kann man auch die bestehende Sonos Umgebung verwenden:

• Samba installiert, 
• Freigabe SonosSpeak auf /var/SonosSpeak. 

Dazu wird Text2Speech etwas anders konfiguriert:

demod SonosTTS Text2Speech none
attr SonosTTS TTS_CacheFileDir /var/SonosSpeak
attr SonosTTS userReadings cifsName:lastFilename.* {my $host=ReadingsVal($name,'host','set host first');;my $lastFileName=ReadingsVal($name,'lastFilename','');;my @arr=split('/',$lastFileName);;$arr[0]='x-file-cifs:/';;$arr[1]=$host;;join('/',@arr)}

Die Weiterentwicklung des Speak Befehls im Wiki könnte der sayText Befehl sein (Für die DEF setList):

sayText:textField { my $tts=ReadingsVal('SonosBridge','tts','SonosTTS');my ($cmd,$text)=split(' ', $EVENT,2);fhem("setreading $tts text ".ReadingsVal($tts,'text',' ').' '.$text.";sleep 0.4 tts;set $tts tts [$tts:text];sleep $tts:playing:.0 ;set $NAME notify [$tts:vol] [$tts:httpName];deletereading $tts text")}

Bei diesem Befehl muss das Volume vorher als Reading gesetzt werden. Der Befehl funktioniert also bewusst anders.

setreading SonosTTS vol 15

Tipps zur Verwendung der Player

Die automatische Konfiguration setzt den alias entsprechend dem Namen im Sonos vergeben. Die langen MQTT2_RINCON_ Namen sind unhandlich und schlecht lesbar. Man kann Player mit einem devspec ansprechen, das simpelste ist:

set alias=Büro ...

Oder alle Player

set model=sonos2mqtt_speaker leaveGroup

Was passiert im Hintergrund?

Das Template "sonos2mqtt_bridge_comfort" wendet ein Template auf das Bridge Device an und definiert zwei notify für die automatische Konfiguration.
Das Erste triggert auf den autocreate Event, wendet ein Template für den Player an und fragt über MQTT weitere Informationen für den Player ab.

define n_configSonos1 notify global:DEFINED.MQTT2_RINCON_[A-Z0-9]+ sleep 1;;set $EVTPART1 attrTemplate sonos2mqtt_speaker;;set $EVTPART1 x_raw_payload {"command": "adv-command","input": {"cmd":"GetZoneInfo","reply":"ZoneInfo"}}

Das zweite notify triggert auf die Namen der Player wenn als Antwort auf den Request von notify 1 das Reading IPAdresse gesetzt wird.

defmod n_configSonos2 notify MQTT2_RINCON_[A-Z0-9]+:IPAddress:.* {\
  no warnings 'experimental::smartmatch';;\
  my @tv = ("S14","S11");;\
  my $url="http://$EVTPART1:1400";;\
  my $xmltext = GetFileFromURL("$url/xml/device_description.xml");;\
  my ($mn)=$xmltext =~ /<modelNumber>(S[0-9]+)/;;\
  my ($img)=$xmltext =~ /<url>(.*)<\/url>/;;\
  my $icon="Sonos2mqtt_icon-$mn";;\
  my $setList=AttrVal($NAME,'setList','');;\
  fhem("setreading $NAME modelNumber $mn");;\
  fhem("\"wget -qO ./www/images/default/$icon.png $url$img\"");;\
  fhem("attr $NAME icon $icon;;sleep 4 WI;;set WEB rereadicons");;\
  if ($mn ~~ @tv) {$setList=~s/input:Queue \{/input:Queue,TV \{/};;\
  $setList=~s/;;/;;;;/g;;\
  fhem("attr $NAME setList $setList")\
}

Mit diesem Befehl wird das Anlegen aller Player getriggert:

"pm2 start sonos2mqtt"

Radio starten

In der setList sind derzeit die einzelnen Steuerbefehle. setAVTUri setzt zwar eine neue Abspielquelle, stoppt aber den Player und beginnt nicht automatisch mit spielen. Eigentlich wäre es aber praktisch.

Anmerkung: Der Befehl playUri ist im aktuellen Template enthalten! 

Die Sonos Umgebung braucht offenbar dazu einen Moment, meine derzeitige Idee ist also:

1. setAVTUri ausführen
2. 1 sec später den play Befehl starten

Die Ergänzung in der setList sähe also so aus:

playUri:textField {fhem("set $NAME setAVTUri $EVTPART1; sleep 1; set $NAME play")}

Als vorübergehende Lösung für sowas wie Radiosender habe ich mir so etwas gebaut. Das notify schreibt den Titel und die uri beim Start (auch über die Sonos App) in den Dummy. Diesen kann man dann selbst zum Starten verwenden: [Titel:DeutschlandfunkKultur]

define Titel dummy
define n_MQTT2_RINCON notify MQTT2_RINCON_[0-9A-Z]{17}:currentTrack_Title:.* {my $title=ReadingsVal($NAME,"enqueuedMetadata_Title","");;$title=~s/\W//g;;my $uri=ReadingsVal($NAME,"currentTrack_TrackUri","");;fhem("setreading Titel $title $uri") }

Nicht einfach default

Hat man den MQTT2_SERVER anders definiert, nicht lokal bzw. mit allowed abgesichert, muss beim Start von sonos2mqtt der Parameter --mqtt übergeben werden. 

Dem pm2 Befehl folgenden durch die Angabe "--" die weiteren Parameter für sonos2mqtt.

"pm2 start sonos2mqtt -- --mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800"

Mit dem Parameter --prefix könnte man den Basistopic setzen (default: sonos).

Weitere Entwicklung

Für die weitere Entwicklung ist im Player der set Punkt x_raw_payload eingebaut. Damit kann einfach json Payload "publishen". Das Original Beispiel aus der Doku, Sound abspielen:

{
  "command": "notify",
  "input": {
    "trackUri": "https://cdn.smartersoft-group.com/various/pull-bell-short.mp3",
    "onlyWhenPlaying": false,
    "timeout": 10,
    "volume": 15,
    "delayMs": 700
  }
}

Werte abfragen

Der Entwickler von sonos2mqtt hat jetzt auch die Abfrage ermöglicht. Um bei Get Befehlen etwas zurück zu bekommen, muss ein Topic übergeben werden:

{
  "command": "adv-command",
  "input": {
    "cmd": "GetFavoriteRadioStations",
    "reply": "DougRadio"
  }
}

Das Beispiel fragt die Favoriten ab. Die Ergebnisse erscheinen dann in einem Reading mit der Struktur Result_8_ItemId. Weiter Informationen findet man hier.

Anmerkung/Tipps

Anstatt FHEM komplett zu aktualisieren kann man auch nur die Templates neu laden:

{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }

Mir ist aufgefallen, dass offenbar System abhängig der Ordner node_modules bei dieser Installationsart an unterschiedlichen Orten angelegt wird! Ich hatte /usr/lib/node_modules und /node_modules. Der Befehl sudo find / -name "sonos2mqtt" hilft dabei den richtigen Pfad zu finden.

Will man auf Systemebene mit pm2 sonos2mqtt monitoren o.ä. muss man dies als User fhem tun. Ein anderer hat auf die Umgebung keinen Zugriff!

sudo -su fhem pm2 list

systemd unit file

Ich habe mich etwas mit systemd, speziell dem unit file von fhem und dem Start von für FHEM notwendigen Komponenten beschäftigt.
Für detailliertere Information wird diese Seite als Start empfohlen.  Eine Befehlsübersicht zu systemctl habe ich hier gefunden.

Windows Server 2012 Foundation - Hyper-V Treiber installieren

Microsoft hat irgendwie umfangreich verhindert, dass man Windows Server 2012 Foundation in Hyper-V virtualisieren kann. Blöd wenn man eine produktiven Server hat, mit dem man ein paar Untersuchungen anstellen will. Virtualisierung / Hyper-V ist dafür nun mal eine Super Sache.
Es gibt einen guten Artikel, der mir sehr weiter geholfen hat.
Da die Situation nach einer Virtualisierung erstmal dramatisch ist, habe ich eine Weg gesucht und gefunden, es zu vereinfachen.
Das Hauptproblem ist die fehlende Installation der Hyper-V Treiber.

Das notwendige Paket windows6.2-hypervintegrationservices-x64.cab kann man bei Microsoft herunterladen. Die ursprüngliche existierende vmguest.iso wird nicht mehr ausgeliefert.
Für den Rest habe ich ein paar Powershell Scripts erstellt.
Zunächst brauchen wir die entpackten Dateien in einem temporären Pfad.

# cab Datei entpacken und in allen inf Dateien eine Zeile ergaenzen
$cabFile="E:\support\amd64\Windows6.2-HyperVIntegrationServices-x64.cab"
# Zielpfad frisch machen
$DestDir = (split-path $cabFile -leaf) -replace '.cab'
if (Test-Path -Path $DestDir) {rm $DestDir}
md $DestDir
# cab datei auspacken
cmd.exe /c "C:\Windows\System32\expand.exe -F:* $cabFile $DestDir"

Damit die Treiber später installiert werden können, muss die inf Datei um die eine Zeile ($rString) ergänzt werden. Zusätzlich muss "neben" der inf Datei die Datei update.cat liegen.

# replace in den inf Dateien
$fString=[regex]::Escape('[Version]') # escapen wegen der Klammer []
$rString="$&`nCatalogFile=update.cat" # Der String der gefunden wurde + NL + Text
gci -Recurse $DestDir |where {$_.name -like "*.inf"}|% {(Get-Content $_.fullname) -replace $fString, $rString| Set-Content $_.fullname;copy-item "$DestDir\update.cat"  (split-path $_.fullname)}

Die mit Windows Server 2012 Foundation vorbereitete virtuelle Disk (VHD Datei) kann man per Doppelklick einfach einbinden. Die Treiber werden dann ins Offline Image integriert.

# Treiber in offline Image integrieren
$offDir="F:"
$driverDir="\\omv1\Shares\Software\vmguest"
Add-WindowsDriver -Path $offDir -Driver $driverDir -Recurse -ForceUnsigned

Sollte was schiefgegangen sein, kann man auch alles wieder entfernen, oder sich nur vergewissern das die Treiber vorhanden sind.

# Alle Treiber wieder entfernen 
$dArray=gci -Recurse $driverDir |where {$_.name -like "*.inf"}|% {$_.name}
Get-WindowsDriver -path $offDir|% {if ($dArray -match (split-path $_.OriginalFileName -leaf)){Remove-WindowsDriver -path $offDir -Driver $_.driver}}

Zum Abschluss die VHD Datei auswerfen und die virtuelle Maschine starten. Es sind keine weiteren Arbeiten erforderlich.

Für die Virtualisierung einer produktiven Server 2012 Foundation Maschine hat man damit folgenden simplen Weg:

1. Image ziehen, entweder offline mit dem USB Stick von hier, oder online mit disk2vhd.
2. Das Image auf eine neue VHD anwenden, oder die VHD Datei von disk2vhd verwenden.
3. VHD Datei als Laufwerk mounten und die Hyper-V Treiber integrieren. 
4. VHD Datei Auswerfen und in Hyper-V verwenden.

Damit funktioniert:

• Gen 2 Virtuelle Maschine
• EFI Boot
• SCSI Disk, Netzkarte usw.

Was leider bleibt:

• Die Hyper-V Dienste (vmic...) laufen nicht.