Hey zusammen,
ich hab mal wieder eine Kleinigkeit vor aber komme nicht weiter.
INFOS:
- Windows 10 PC
- Mehrere Audio Ausgabe Geräte (Headset, Sound System)
- WLAN Schalter (Shelly Plug S)
Ich möchte gerne, wenn mein PC auf ein spezielles Ausgabe Gerät gestellt wird, dass der WLAN Schalter eingeschaltet wird und natürlich auch wieder aus.
Der Hintergrund ist eigentlich ganz einfach. Wenn ich am PC etwas mit meinem Headset mache, soll das Sound System aus sein. Wenn ich aber nun mal etwas lauter Musik an machen will, stelle ich an meinem Windows PC die Ausgabe auf den Ausgang der Soundkarte. In diesem Moment soll der WLAN Schalter eingeschaltet werden. Mit diesem geht dann auch das Sound System an und brüllt durch die Gegend. Stelle ich nun wieder auf mein Headset um, welches einen USB Dongle nutzt um die Datenströme an das Funk Headset zu senden, soll der WLAN Schalter wieder aus gehen.
Aktuell habe ich WINCONNECT mal eingerichtet. Allerdings komme ich mit der WMI Einrichtung nicht weiter. WINCONNECT selber sagt mir aber leider nicht von sich aus, was mein Haupt Audio Ausgabegerät ist. Also habe ich das aktuell nur so lösen können, dass wenn PC = an und WINCONNECT das sieht, geht der WLAN Schalter an und wenn der PC aus ist auch wieder aus. Das ist aber eigentlich sinnlos, da das Soundsystem dann oft mit läuft ohne genutzt zu werden.
Hat einer von euch eine Idee, wie man das schön lösen kann? Ich benötige eigentlich auch nicht die ganzen Infos die WINCONNECT noch so mit liefert.
Weitere Infos:
Der Name der Ausgabegeräte in Windows ist einmal Lautsprecher und einmal Headset.
Mein Aktuelles notify (so muss ich manuell einschalten aber es geht automatisch wieder aus [schon mal etwas besser]):
defmod n_az_pc_musik notify kai_pc:off set MQTT2_shellyplug_s_7AE167 off
Anbei noch ein WINCONNECT List, des betroffenen PCs:
Internals:
CFGFN
DEF 192.168.xxx.xxx 120
FUUID 5d95c98a-f33f-fcb4-67a8-648089db44dae283
INTERVAL 120
NAME kai_pc
NR 4154
STATE on
TYPE WINCONNECT
OLDREADINGS:
READINGS:
2019-10-03 13:47:47 audio on
2019-10-03 13:04:54 audio_devicename Lautsprecher
2019-10-03 13:04:58 battery_ChargeStatus NoSystemBattery
2019-10-03 13:04:58 battery_LifePercent 100
2019-10-03 13:04:58 battery_LifeRemainingsMin 0
2019-10-03 13:04:58 battery_PowerLineStatus Online
2019-10-03 13:04:57 bios_boardmanufacturer Shuttle Inc.
2019-10-03 13:04:57 bios_boardproduct SX58
2019-10-03 13:04:57 bios_boardversion V10
2019-10-03 13:04:57 bios_releasedate 01/06/2012
2019-10-03 13:04:57 bios_vendor American Megatrends Inc.
2019-10-03 13:04:57 bios_version 080016
2019-10-03 13:04:58 brightness 200
2019-10-03 13:04:54 core_temp_state not_installed
2019-10-03 13:04:55 cpu_0_mhz 3200
2019-10-03 13:04:55 cpu_0_name Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz
2019-10-03 13:04:56 cpu_1_mhz 3200
2019-10-03 13:04:55 cpu_1_name Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz
2019-10-03 13:04:56 cpu_2_mhz 3200
2019-10-03 13:04:56 cpu_2_name Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz
2019-10-03 13:04:56 cpu_3_mhz 3200
2019-10-03 13:04:56 cpu_3_name Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz
2019-10-03 13:04:56 cpu_4_mhz 3200
2019-10-03 13:04:56 cpu_4_name Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz
2019-10-03 13:04:56 cpu_5_mhz 3200
2019-10-03 13:04:56 cpu_5_name Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz
2019-10-03 13:04:56 cpu_6_mhz 3200
2019-10-03 13:04:56 cpu_6_name Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz
2019-10-03 13:04:56 cpu_7_mhz 3200
2019-10-03 13:04:56 cpu_7_name Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz
2019-10-03 13:04:57 drive_C_Format NTFS
2019-10-03 13:33:56 drive_C_Space_AvailableFree 86543
2019-10-03 13:04:57 drive_C_Space_Total 124391
2019-10-03 13:33:56 drive_C_Space_Used 37848
2019-10-03 13:04:58 drive_C_Type Fixed
2019-10-03 13:04:58 drive_D_Format NTFS
2019-10-03 13:04:58 drive_D_Space_AvailableFree 48341
2019-10-03 13:04:58 drive_D_Space_Total 351389
2019-10-03 13:04:58 drive_D_Space_Used 303048
2019-10-03 13:04:58 drive_D_Type Fixed
2019-10-03 13:04:55 file_filter *.*
2019-10-03 12:25:47 file_fullname no file found
2019-10-03 12:25:47 file_name no file found
2019-10-03 13:04:55 file_order descending
2019-10-03 13:53:59 memory_available 8.858
2019-10-03 13:04:56 memory_total 12.279
2019-10-03 13:04:54 microphone_detect False
2019-10-03 13:04:54 microphone_devicename FIXME Type = VT_BOOL
2019-10-03 12:23:31 model Windows 10 Pro
2019-10-03 13:04:54 motion_autodetect False
2019-10-03 13:04:54 motion_detect False
2019-10-03 13:04:58 mute off
2019-10-03 13:04:55 os_Domainname WORKGROUP
2019-10-03 13:04:55 os_Hostname DESKTOP-SEB195P
2019-10-03 13:04:55 os_InstallDate 06.08.2019 14:54:41
2019-10-03 13:04:55 os_Name Windows 10 Pro
2019-10-03 13:04:55 os_ReleasID 1903
2019-10-03 13:04:59 os_RunTime_days 0
2019-10-03 13:06:31 os_RunTime_hours 1
2019-10-03 13:53:31 os_RunTime_minutes 107
2019-10-03 13:04:55 os_StartTime 03.10.2019 12:06:31
2019-10-03 13:04:55 os_Type Client
2019-10-03 13:04:55 os_Username SYSTEM
2019-10-03 13:04:55 os_Version 10.0.18362.356
2019-10-03 13:04:57 printer_aktiv false
2019-10-03 13:04:57 printer_names no_printing
2019-10-03 12:25:46 speechcontrol off
2019-10-03 13:04:57 speechquality 70
2019-10-03 13:04:54 state on
2019-10-03 13:00:37 user_aktiv false
2019-10-03 13:04:57 user_aktividletime 60
2019-10-03 13:04:58 volume 22
2019-10-03 13:04:55 wincontrol 0.0.27
2019-10-03 12:12:28 wincontrol_error Download new version = 0.0.27
2019-10-03 12:12:28 wincontrol_gitlab 0.0.27
2019-10-03 12:12:28 wincontrol_gitlab_serviceurl https://gitlab.com/michael.winkler/winconnect/raw/master/WinControlService_0.0.27.exe
2019-10-03 12:12:28 wincontrol_gitlab_url https://gitlab.com/michael.winkler/winconnect/raw/master/WinControl_0.0.27.exe
2019-10-03 13:04:55 wincontrol_starttime 03.10.2019 13:04:51
2019-10-03 13:04:54 wincontrol_type Service
2019-10-03 13:04:55 wincontrol_user NT-AUTORITÄT\SYSTEM
2019-10-03 13:04:59 wmi_Realtek_High_Definition_Audio Realtek High Definition Audio
helper:
ADDRESS 192.168.xxx.xxx
Attributes:
alias Kais PC
icon it_server
Zuerst dachte ich, dass bei audio_devicename der Name stehen müsste. Dieser bleibt aber auf Lautsprecher. Und das auch immer.
Hinzu weiß ich nicht wirklich wie aufwendig es für FHEM ist, den PC regelmäßig ab zu fragen. Deswegen steht die Zeit der Abfrage bei mir auf 120 Sekunden.
Gut wäre, wenn mein PC die Info der Ausgabe an z.B. ein Dummy senden könnte, in dem Moment wo ich das am PC umstelle. Wie oben schon gesagt, brauche ich die ganzen anderen Infos nicht. Es würde ja schon reichen wenn der PC eine 1 für den einen Ausgang senden würde und eine 2 für den anderen Ausgang. 1 oder 2 sind nur Beispiele....
Ich bin gespannt wie ihr das so gelöst habt...
DANKE an alle :)
Hi,
ich habe das nicht gelöst aber hätte eine andere Idee.:
Windows ermittelt entweder per Powershell welches Audio Device aktiv ist, oder wenn das zu schwierig ist, Du setzt dein Audio-Device mit einem Powershell Script (Link auf dem Desktop oder so ähnlich)
Im gleichen Script sendest Du einen Befehl an FHEM, FHEM macht den Rest.
Die Verbindung von Powershell zu FHEM habe ich. Der Part auf Windows ist noch wage, aber scheinbar lösbar:
https://darkball.net/2018/03/change-audio-output-with-powershell-in-windows-10/
Wäre das ein Ansatz?
Gruß Otto
Hört sich gut an... So könnte ich das sogar als Hotkey verwenden.
Muss mich nur noch einlesen, wie ich von Win-PS gegen FHEM komme (Syntax und ggf. Probleme). Was Powershell Richtung Windows selber angeht, sollte ich hinbekommen.
Tatsächlich würde ich hier die zweite Lösung bevorzugen. Das diese nicht dauerhaft im Hintergrund laufen muss, sondern nur auf Knopfdruck reagieren würde.
Geile Idee, danke Otto - Wochenende gerettet :)
Melde mich dann mit Ergebnissen, wenn ich soweit bin. Sollte jemandem noch was einfallen, bitte gerne her damit. Ich denke ich bin nicht der Einzige mit solch einer Idee.
Moin,
mein Powershell - FHEM Client (https://github.com/heinz-otto/fhemcl/blob/master/fhemcl.ps1) :)
Gruß Otto
Hi,
es ist entspannter die Diskussion hier zu führen. ;)
Wenn Du https Zugriff hast: Funktioniert denn der Zugriff auf deinen FHEM Server über InternetExplorer bzw. edge von Deinem Windows PC mit dem selfsigned Zertifikat? Powershell greift eigentlich auf die Sicherheit des Internetexplorers (System) zurück.
Gruß Otto
ZitatSicherheit des Internetexplorers
Gibt es die inzwischen? 8)
LG
pah
Naja es kommt wie bei jedem Zertifikat aus nicht gekaufter stelle zu einer Warnung. Ist ein selbst signiertes. Nun könnte ich das Zertifikat natürlich hart im System bekannt machen aber in meinen Augen muss das genau wie im Browser auch so gehen.
Gesendet von meinem LG-H850 mit Tapatalk
Aber das ist doch der einzig vernünftige Weg bei selbstsignierten Zertifikaten? Es dem System bekannt zu machen und damit der ausstellenden Stelle zu vertrauen. Ansonsten kann man das auch weglassen - meine Meinung. Denn man vertraut irgendwann im Dialog stumpf jedem Zertifikat was vorgibt bekannt und sinnvoll zu sein.
Außerdem ist doch der ständige Warnungsdialog vertane Lebenszeit :)
Ansonsten hab ich hier (https://stackoverflow.com/questions/36456104/invoke-restmethod-ignore-self-signed-certs) was gefunden was man versuchen könnte.
Hey - Auch wenn das nun komisch klingt. Ich habe für mich einen besseren Weg gefunden.
Es wird bei Powershell mit dem von dir empfohlenen cmdlet bleiben. Nur sende ich die Daten einfach via MQTT an FHEM.
Das ist aufgrund dessen, das ich eh viel damit mache, für mich viel einfacher und schöner.
Wenn von Interesse, sende ich bei Fertigstellung auch mal mein Script.
Ja mqtt ist auch ein eleganter Weg. Ist für mich noch etwas Neuland aber ich arbeite mich gerade ein.
Wäre toll wenn Du das hier einfach mal beschreibst.
Und mqtt machst Du ohne TLS? ;)
Ich lese und teste auch den halben Tag schon. Hatte bisher immer nur Endgeräte bei denen man alles einträgt.
Nun habe ich mir einen Client auf dem PC installiert. Über PS geben ich dem Client die Infos die er mir in dem entsprechendem FHEM Device bereit stellen soll.
MQTT ist bei den meisten lot Geräten ohne alles.. Da kannst du alles mit lesen. Deswegen sind die auch ganz weit weg und kommen über 10 Ecken an mein Netz.
Ich teste gerade ohne TLS. Aber soweit ich gelesen habe, soll das auch verschlüsselt gehen. Wobei ich das bei MQTT noch nie gesehen habe.
Aber ich lese, wie schon gesagt auch noch wie es am besten ist usw. Am Ende ist @Beta-User schuld das ich MQTT mittlerweile so mag :-P
Ich baue erst mal zu ende und würde mich am WE aber noch melden. Es wird sicher nicht der schönste Weg sein aber für das was ich vor habe ist das klasse!
Danke für Eure Unterstützung! Ohne die Ideen wäre ich auch nicht weiter gekommen!
Naja da sind wir ja auf einem ähnlichen "Stand" mit mqtt. Ich habe mir ein paar wlan Stecker besorgt um mit mqtt zu spielen :) und mir attrTemplate anzuschauen ;)
Zitat von: 87insane am 05 Oktober 2019, 12:44:27
Am Ende ist @Beta-User schuld das ich MQTT mittlerweile so mag :-P
Es entbehrt nicht einer gewissen Ironie, wenn du mich im Zusammenhang mit diesem seltsamen OS aus redmond erwähnst :P . Und die "Schuld" darfst du eher Rudi geben, der hat die Module gebaut, die das so flexibel handhabbar/konfigurierbar machen ;D .
Zitat von: Otto123 am 05 Oktober 2019, 13:35:44
Ich habe mir ein paar wlan Stecker besorgt um mit mqtt zu spielen :) und mir attrTemplate anzuschauen ;)
@Otto: Du weißt doch: WLAN ist sch...e ;D ;D ;D
(aber attrTemplate cool :P ). (Vielleicht magst du das bei HTTPMOD mal näher ansehen, da sind ein paar templates drin, die "verbesserungsfähig" wären, aber ich bin nicht so der geübte regexer... Und evtl. hast du noch ein paar Sachen auf Lager, die man da zweckmäßigerweise reinpacken könnte?)
Dauert leider noch. Zum einen war ich mal spontan unterwegs und zum anderen muss ich so was wie eine Warteschlange bauen, damit keine Nachrichten verloren gehen. An sich habe ich aber eine lauf fähige Lösung. Will nur nix Posten was am ende Probleme macht.
Nochmal danke für die ganzen Ideen!
Zitatich habe mich gestern sehr lange mit den Passwörtern in PS auseinander gesetzt. Zudem habe ich mir mal ein aktuelles PS Buch besorgt.
Soweit so gut... Nun habe ich dein Script auch verstanden. Womit ich allerdings auch mit Beschreibungen noch nicht klar komme sind die param().
Da ich nur den Teil mit dem PW benötige, benötige ich natürlich nicht $Share usw.
Ca. so wollte bzw würde ich das übernehmen:
$PWDFile="C:\Users\BENUTZERNAME\Downloads\pwfile.txt"
#Wenn Passwort nicht gespeichert vorhanden passwort abfragen und File erzeugen
If (-not (test-path $PWDFile)) {
$credential = Get-Credential -Credential $UserName
$credential.Password | ConvertFrom-SecureString | Set-Content $PWDFile
}
#Credential aus Passwort Datei und Username erzeugen
$encrypted = Get-Content $PWDFile | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PsCredential($UserName, $encrypted)
und bekomme ein Problem bei der initialisierung von userName.
New-Object : Ausnahme beim Aufrufen von ".ctor" mit 2 Argument(en): "Das Argument kann nicht verarbeitet werden, da der Wert des Arguments "userName" ungültig ist. Ändern Sie den
Wert des Arguments "userName", und führen Sie den Vorgang erneut aus."
In C:\Users\christk1\Downloads\test.ps1:28 Zeichen:15
+ ... redential = New-Object System.Management.Automation.PsCredential($Use ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [New-Object], MethodInvocationException
+ FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand
Spontan ne Idee?
Vermutlich nur eine deklarations Geschichte, denke ich.
Sieht so aus als ob userName (also die Variable $UserName) irgendwie nicht gesetzt ist oder nicht zur Datei passt?
In den param() werden ja nur Variablen deklariert und die Übernahme aus der Kommandozeile geregelt.
Also stattdessen geht auch einfach
$UserName="willli"Edit: Ich kann den Fehler nachstellen: Der kommt genau wenn $UserName nicht existiert, Du musst die Variable also am Anfang unbedingt setzen. Ansonsten wird ja auch der Abfragedialog in Zeile 3 für das Passwort nicht gestartet!
Nochmal Edit:Dir fehlt natürlich noch das Passwort im Original zur Verwenden in deinem MQTT ich bin nicht sicher ob dort das Object direkt geht. Wenn nicht, dann so:
$credential.GetNetworkCredential().Password
$credential.GetNetworkCredential().UserNameGruß Otto
Hi nochmal,
ich habe nun echt viel rum probiert aber es fällt mir schwer.
Verständnis-frage:
$credential.Password | ConvertFrom-SecureString | Set-Content $PWDFile
sollte NUR den PW Teil (konvertiert) in die Datei packen. korrekt?
Also sollte:
$credential | ConvertFrom-SecureString | Set-Content $PWDFile
Alles in die Datei packen? (Benutzer und PW)
Hier auch Edit: ist natürlich Quark weil dann kein string existiert.
$encrypt = Get-Content $PWDFile | ConvertTo-SecureString
Sollte alles aus der Datei wieder einlesen, konvertieren und in $encrypt packen?
$cred = New-Object System.Management.Automation.PsCredential($encrypt)
Sollte also nun UserName und Passwort enthalten?
Dann müsste:
$PWDFile="C:\Users\test_user\test\pwfile.txt"
#Wenn Passwort nicht gespeichert vorhanden passwort abfragen und File erzeugen
If (-not (test-path $PWDFile)) {
$cred = Get-Credential
$cred.Password | ConvertFrom-SecureString | Set-Content $PWDFile
}
#Credential aus Passwort Datei und Username erzeugen
$encrypt = Get-Content $PWDFile | ConvertTo-SecureString
$cred = New-Object System.Management.Automation.PsCredential($encrypt)
$cred.UserName
$cred.Password
Ausgabe:
PS C:\Users\test_user\test> C:\Users\test_user\test\test.ps1
UserName Password
-------- --------
zumindest den User ausgeben oder?
Ich würde gerne Benutzer und PW in die Datei packen und den UserNamen nicht festlegen. Der kann sich ja auch ändern. So bekomme ich zumindest keinen Debug Fehler.
Mit
$credential.GetNetworkCredential().Password
$credential.GetNetworkCredential().UserName
bekomme ich:
Ausnahme beim Aufrufen von "GetNetworkCredential" mit 0 Argument(en): "Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt."
In C:\Users\christk1\Downloads\test.ps1:29 Zeichen:1
+ $cred.GetNetworkCredential().Password
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : NullReferenceException
Ausnahme beim Aufrufen von "GetNetworkCredential" mit 0 Argument(en): "Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt."
In C:\Users\christk1\Downloads\test.ps1:30 Zeichen:1
+ $cred.GetNetworkCredential().UserName
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : NullReferenceException
Wie kann man ein "unsichtbares" Szenario am besten testen? bzw wo habe ich den Denkfehler?
Edit: oder muss ich den AES key zwangsläufig alleine in eine Datei packen und Benutzernamen + konfig (ip,Topic usw) in eine andere Datei? Am liebsten hätte ich am ende eine Datei in der konfig + AES ist.
Aus meiner Sicht machst Du es einfach falsch :(
In der Datei steht nur ein verschlüsselter String. Dieser wird erzeugt aus:
dem User
dem Passwort
dem Computer/Maschinen Zertifikat/Schlüssel.
Um das Passwort aus diesem String auszulesen brauchst Du:
den gleichen Computer
den User
Alles aus dem verschlüsselten String auslesen funktioniert meines Wissens nicht. Den User musst Du angeben.
https://www.script-example.com/powershell-password
Deine Fehlermeldung zum Schluss sagt mir: Da wurde kein Objekt erzeugt. $cred oder $credential existiert nicht.
Du kannst natürlich mehr Dinge in die Datei packen, dann musst Du das Format selbst organisieren.
Du kannst Dir z.B. ein Objekt zusammenbauen und dieses Objekt mit Export-Clixml in eine Datei schreiben und später mit Import wieder reinholen.
Okay. Dachte das ich aus dem was drin steckt auch alles wieder decodieren kann. Das es der gleiche user usw sein müssen ist okay und war beabsichtigt.
Da ich aber in credentials benutzer u pw eingebe, muss ich das ja auch verwerten können. Aber dann werde ich den user einfach nochmal separat weg schreiben. Vermutlich komme ich dann um eine saubere config XML nicht drumherum. Aber eine super übung ist es am ende trotzdem.
Bezüglich dem nicht erzeugtem Objekt. Ja da habe ich mist gepostet. Ich hatte bereits eine pw Datei aus einem Test davor. Diese hat er gelesen und deswegen auch nicht die user Daten erneut abgefragt. Somit gab es auch keinen Fehler im ersten Abschnitt nachdem ich .password (den String zum verschlüsseln) weg nahm. Immerhin habe ich es später auch bemerkt und du hast es beim lesen schon gesehen. Danke für den Anstoß!
Gesendet von meinem LG-H850 mit Tapatalk
So steht anschließend alles in einer XML datei:
$ObjectFile="obj.xml"
#Wenn Object nicht gespeichert User und Passwort abfragen und File erzeugen
If (-not (test-path $ObjectFile)) {
$credential = Get-Credential
$credential |Export-Clixml $ObjectFile
}
Mit $cred=Import-Clixml $ObjectFile bekommst Du das Objekt zurück.
Kontrolle:
$cred.GetNetworkCredential().UserName
$cred.GetNetworkCredential().Password
Gruß Otto
So kann ich den User mit eingeben und er ist variabel....
Nun beschäftige ich mich mal mit der XML Sache...
$PWDFile="C:\Users\benutzername\Desktop\PS\pwfile.txt"
#Wenn Passwort nicht gespeichert vorhanden passwort abfragen und File erzeugen
If (-not (test-path $PWDFile)) {
$credential = Get-Credential
$UserName = $credential.UserName
$credential.Password | ConvertFrom-SecureString | Set-Content $PWDFile
}
#Credential aus Passwort Datei und Username erzeugen
$encrypted = Get-Content $PWDFile | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PsCredential($UserName, $encrypted)
$credential.UserName
$credential.Password
Werde versuchen via Clixml alles in eine Datei zu bekommen. Bei der Verschlüsselung werde ich bleiben. Die ist super und x mal besser als plain Text.
In PS muss ich mein Wissen genau wie in PERL noch weit ausbauen... Wobei ich jetzt schon sagen kann, PS finde ich etwas schöner.
EDIT: HÖ!? Jetzt bin ich verwirrt... Wird automatisch in xml verschlüsselt? Erst mal googlen........
Verschlüsselt wird doch im credential Objekt - bleib ganz ruhig! Nicht googeln einfach meinen Code oben nehmen! Ich hatte editiert :)
Oder habe ich da einen Denkfehler? ???
Naja ich bin in so fern verwundert, da ich ja null Ahnung habe und mich bei jedem Stichwort erstmal einlesen muss.
Vorher war es ein langer Code um in eine txt o.ä. mit verschlüsseltem Inhalt zu erzeugen. Nun sind es ein paar sehr einfache Zeilen, die direkt in xml ein nicht lesbares PW erzeugen.
Kannst du erklären wieso:
$PWDFile="pwfile.txt"
#Wenn Passwort nicht gespeichert vorhanden passwort abfragen und File erzeugen
If (-not (test-path $PWDFile)) {
$credential = Get-Credential
$UserName = $credential.UserName
$credential.Password | ConvertFrom-SecureString | Set-Content $PWDFile
}
#Credential aus Passwort Datei und Username erzeugen
$encrypted = Get-Content $PWDFile | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PsCredential($UserName, $encrypted)
$credential.UserName
$credential.Password
gegen:
$ObjectFile="obj.xml"
#Wenn Object nicht gespeichert User und Passwort abfragen und File erzeugen
If (-not (test-path $ObjectFile)) {
$cred = Get-Credential
$cred |Export-Clixml $ObjectFile
}
$cred=Import-Clixml $ObjectFile
$cred.GetNetworkCredential().UserName
$cred.GetNetworkCredential().Password
so viel einfacher ist? Es muss doch einen Nachteil geben...?
Ja Du kannst Recht haben mit der Verschlüsselung:
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/convertfrom-securestring?view=powershell-6
Ich weiß jetzt noch nicht genau, was der Unterschied zwischen einem secure string und encrypted standard string ist.
Eventuell ist der secure String bloß ein hash und nicht wirklich verschlüsselt.
Die Idee mit dem credential Objekt und Export in XML kam mir ja später. :) Im Laufe der Entwicklung wird manches auch einfacher :)
https://itluke.online/2018/11/17/what-is-the-difference-between-a-secure-string-and-an-encrypted-string/
Ich werde mal versuchen es als Gemisch zu nutzen. So das in der xml der gleiche Sicherheitsstandard herrscht wie in deinem ersten Code. Das wäre dann ja das beste.
$config="config.xml"
#Wenn Passwort nicht gespeichert vorhanden passwort abfragen und File erzeugen
If (-not (test-path $config)) {
$cred = Get-Credential
$UserName = $cred.UserName
$cred.Password | ConvertFrom-SecureString | Export-Clixml $config
}
#Credential aus Passwort Datei und Username erzeugen
$encrypt = Import-Clixml $config | ConvertTo-SecureString
$cred = New-Object System.Management.Automation.PsCredential($UserName, $encrypt)
$cred.UserName
$cred.Password
irgendwie so.... mal sehen ob das alles klappt..
Brauche nur für den User noch eine Idee...bzw muss alles mit exportieren...
Hmmm der Link erklärt zwar umfangreich den Inhalt von secure String - aber der wirkliche Unterschied der Verschlüsselung von Secure String und encryted Standard String wird mir nicht klar. Beide sind verschlüsselt. Steht auch in dem Artikel.
Ich meine, Du könntest jetzt den kompletten XML Text nehmen und als encrypted Standard String speichern ... Aber ob das gut ist? Dazu müsste man noch mehr lesen.
Sooo für heute habe ich genug aber jede Menge geschafft. Gerne für morgen Verbesserungs-Wünsche. Denke mal, man kann irgendwie direkt pipen anstelle meines langen Examples, die Variablen in die xml zu schreiben.
Habe einen Wizard drum gebaut. Bin gespannt was du sagst.
An sich behalte ich die Verschlüsselung vom Anfang bei aber schreibe alle Infos in eine XML. Ausgabe am Ende geht auch. Habe noch nicht mit MQTT getestet aber es geht ja erst mal um das Gerüst. Hat ein wenig länger gedauert da ich erst die XML Struktur halbwegs hinbekommen wollte.
#Wenn config Datei nicht vorhanden
If (-not (test-path config.xml)) {
# Auflistung der Audio Geräte
Get-AudioDevice -List
# Abfrage der Variablen
$dev1 = Read-Host "Enter first Device ID"
$dev2 = Read-Host "Enter second Device ID"
$serverip = Read-Host "Enter IP-Adress of MQTT Server"
$conid = Read-Host "Choose a MQTT connection ID"
$topic = Read-Host "Choose a MQTT Topic"
$cred = Get-Credential
$usr = $cred.UserName
$pw = $cred.Password | ConvertFrom-SecureString
#### Leere XML Datei erstellen ####
$xmlcreate = New-Object System.Xml.XmlTextWriter("config.xml",$NULL)
#### Formatierung in XML Datei anpassen ####
$xmlcreate.Formatting = "Indented"
$xmlcreate.Indentation = 1
$xmlcreate.IndentChar = "`t"
#### Inhalt für XML Datei ####
$xmlcreate.WriteStartDocument()
$xmlcreate.WriteStartElement("list")
$xmlcreate.WriteElementString("SoundDevice1",$dev1)
$xmlcreate.WriteElementString("SoundDevice2",$dev2)
$xmlcreate.WriteElementString("MQTTServerIP",$serverip)
$xmlcreate.WriteElementString("ConnectionID",$conid)
$xmlcreate.WriteElementString("MQTTTopic",$topic)
$xmlcreate.WriteElementString("UserName",$usr)
$xmlcreate.WriteElementString("Password",$pw)
$xmlcreate.WriteEndElement()
#### XML Datei beschreiben ####
$xmlcreate.WriteEndDocument()
$xmlcreate.Flush()
$xmlcreate.Close()
}
# config.xml einlesen und durchsucbar machen
[xml]$config = Get-Content "config.xml"
# Passwort aus XML entschlüsseln und einlesen
$encrypt = $config.list.Password | ConvertTo-SecureString
$cred = New-Object System.Management.Automation.PsCredential($config.list.UserName, $encrypt)
# Aktuelle Test Ausgabe
$cred
EDIT: Ich glaube nach dem 10 mal habe ich es nun auch verstanden....
$cred = New-Object System.Management.Automation.PsCredential($config.list.UserName, $encrypt)
kann nicht gehen das der User der es entschlüsselt nicht der ist, den man eingibt sondern der User, der am PC angemeldet war, während es verschlüsselt wurde?
Also ich hab den String in $config.list.Password und da kommt er auch an. Aber das PW geht so auf jeden Fall nicht. Da ich als WIN User natürlich nicht pi habe. Aber dann könnte man doch einfach die System Variable nehmen anstelle von $config.list.UserName oder habe ich immer noch einen Hänger mit dem PW verschlüsseln? Mit dem kompletten Rest komme ich schneller und besser klar :-\
Das Du dieses verschlüsselte Passwort nur an dem PC verwenden kannst an dem es erzeugt wurde habe ich aber von Anfang an gesagt.
Du kannst auf dem PC wo das Passwort verschlüsselt wurde, das Script laufen lassen. Auf einem anderen PC musst Du neu verschlüsseln, die Passwort Datei ist wertlos.
Ich habe jetzt nicht verstanden, dass Du das Powershell Script auf einem pi laufen lassen willst versteh ich nicht.
BTW ich habe hier noch einen guten Artikel (https://sylvioh.wordpress.com/2015/05/11/passwortsicherheit-in-powershell-skripten/).
Wenn das dort alles stimmt ist ein secure.string object auch begrenzt sicher im Speicher, da es gelöscht wird. Ein normaler system.string bleibt im Speicher. Mit der Verschlüsselung hat das nichts zu tun, der secure.string ist genauso verschlüsselt wie der String der durch convertfrom-SecureString erzeugt wird.
Du musst ja das powershell Script unter einem User laufen lassen. Mit dem User muss auch die verschlüsselung vorgenommen werden. Dieser User hat nichts mit dem UserName zu tun der bei get-credential angegeben wird. Das ist der Benutzer der zur Anmeldung am anderen System verwendet werden soll.
Gruß Otto
Guten Morgen,
ich denke in unserer Kommunikation ist was schief gelaufen :-\
ZitatDas Du dieses verschlüsselte Passwort nur an dem PC verwenden kannst an dem es erzeugt wurde habe ich aber von Anfang an gesagt.
Du kannst auf dem PC wo das Passwort verschlüsselt wurde, das Script laufen lassen. Auf einem anderen PC musst Du neu verschlüsseln, die Passwort Datei ist wertlos.
Das ist doch auch genau so gewollt. Dazu der Wizard, ist doch dann perfekt?! So kann jeder der das Skript nutzen will, seine Daten eingeben. Für mich alleine habe ich das nicht gebaut. Viel eher als Übung und für die Community.
ZitatIch habe jetzt nicht verstanden, dass Du das Powershell Script auf einem pi laufen lassen willst versteh ich nicht.
Also zurück zum Anfang.....
Das Skript soll auf einem WIN PC laufen. Es soll ermöglichen die Sound Devices zu wechseln und sendet das aktuelle Gerät an FHEM via MQTT. Wenn ich also an meinem PC den ersten Start des Skriptes mache, durchlaufe ich zuerst die Abfragen. Diese beinhalten:
$dev1 = Erstes Sound Ausgabegerät
$dev2 = Zweites Sound Ausgabegerät
$serverip = IP-Adresse vom MQTT Server (bei mir z.B. FHEM MQTT2)
$conid = Die eindeutige ID, die MQTT für Geräte benötigt
$topic = MQTT Topic
$usr = Benutzername um sich mit dem MQTT Server zu verbinden
$pw = Passwort um sich mit dem MQTT Server zu verbinden
Nachdem der User das alles eingegeben hat, sendet das Script die Infos via MQTT an den Server. Deswegen habe ich ja auch alles in eine XML auslagern wollen. Da du mir da so tatkräftig geholfen hast ist auch nur noch eine Kleinigkeit offen.
ZitatBTW ich habe hier noch einen guten Artikel.
Wenn das dort alles stimmt ist ein secure.string object auch begrenzt sicher im Speicher, da es gelöscht wird. Ein normaler system.string bleibt im Speicher. Mit der Verschlüsselung hat das nichts zu tun, der secure.string ist genauso verschlüsselt wie der String der durch convertfrom-SecureString erzeugt wird.
Ich bin mir da auch noch nicht sicher was ich nun mache. Aktuell habe ich das getestet mit XML aber der Verschlüsselung von deiner ersten Idee. Ob das nicht sogar für so ein Skript ein wenig zu viel ist?
ZitatDu musst ja das powershell Script unter einem User laufen lassen. Mit dem User muss auch die verschlüsselung vorgenommen werden. Dieser User hat nichts mit dem UserName zu tun der bei get-credential angegeben wird. Das ist der Benutzer der zur Anmeldung am anderen System verwendet werden soll.
Das wurde mir erst gestern klar..... Ich in davon ausgegangen das der User, der sein muss, den ich auch eingebe. Aber nach deiner Beschreibung gestern, hatte ich das korrekt verstanden. Also der User, der auch angemeldet ist. (was auch am meisten Sinn macht).
ABER bei
$cred = New-Object System.Management.Automation.PsCredential("UserName", $encrypt)ist der Name unerheblich. Das konnte ich testen und nachstellen. Ich weiß nicht warum man da überhaupt einen angeben muss aber dazu muss ich mir die Tage mal ein Test Skript bauen. Ich teste gerne so kleine Dinge mit Test-Skripten, einfach um es auch zu verstehen.
Gestern Abend hatte ich doch noch das fertige Skript getestet.... Also mit dem MQTT senden. Ich merkte aber das mein Rechner immer wieder sehr hoch ging von der CPU her. Da muss ich noch schauen warum. Vermutlich liegt es am Entschlüssen (wobei der Vorgang nur 1 Sekunde dauert).
Was mir auch aufgefallen ist:
- Egal ob der User, der die XML erzeugt hat und damit auch das PW - MQTT nimmt das Passwort nicht als $encrypt bzw cred. Ich musste beim Connect immer cred.GetNetworkCredential().Password verwenden. Bei Azure z.B. kann man direkt den AES encrypt Wert nehmen (hoffe man versteht mich). Da aber auch nur der Erzeuger des AES Keys das PW mit $cred.GetNetworkCredential().Password entschlüsseln kann, wäre das Skript eigentlich fertig. Nun ist nur die Frage ob 1. oder 2. PW Methode sinniger ist.
Ich Poste nun mal mein getestetes Skript aber
es würde mich sehr freuen wenn man das noch optimieren könnte.
#Wenn config Datei nicht vorhanden ist, werden alle Variablen abgefragt um eine config.xml zu erstellen
If (-not (test-path config.xml)) {
# Auflistung der Audio Geräte
Get-AudioDevice -List
# Abfrage der Variablen
$dev1 = Read-Host "Enter first Device ID"
$dev2 = Read-Host "Enter second Device ID"
$serverip = Read-Host "Enter IP-Adress of MQTT Server"
$conid = Read-Host "Choose a MQTT connection ID"
$topic = Read-Host "Choose a MQTT Topic"
$cred = Get-Credential
$usr = $cred.UserName
$pw = $cred.Password | ConvertFrom-SecureString
#### Leere XML Datei erstellen ####
$xmlcreate = New-Object System.Xml.XmlTextWriter("config.xml",$NULL)
#### Formatierung in XML Datei anpassen ####
$xmlcreate.Formatting = "Indented"
$xmlcreate.Indentation = 1
$xmlcreate.IndentChar = "`t"
#### Inhalt für XML Datei ####
$xmlcreate.WriteStartDocument()
$xmlcreate.WriteStartElement("list")
$xmlcreate.WriteElementString("SoundDevice1",$dev1)
$xmlcreate.WriteElementString("SoundDevice2",$dev2)
$xmlcreate.WriteElementString("MQTTServerIP",$serverip)
$xmlcreate.WriteElementString("ConnectionID",$conid)
$xmlcreate.WriteElementString("MQTTTopic",$topic)
$xmlcreate.WriteElementString("UserName",$usr)
$xmlcreate.WriteElementString("Password",$pw)
$xmlcreate.WriteEndElement()
#### XML Datei beschreiben ####
$xmlcreate.WriteEndDocument()
$xmlcreate.Flush()
$xmlcreate.Close()
}
# config.xml einlesen und durchsucbar machen
[xml]$config = Get-Content "config.xml"
# Passwort aus XML einlesen und entschlüsseln
$encrypt = $config.list.Password | ConvertTo-SecureString
$cred = New-Object System.Management.Automation.PsCredential("Username", $encrypt)
# Index der Wiedergabegeräte im System - Vorher mit Get-AudioDevice -List prüfen
$dev1=$config.list.SoundDevice1
$dev2=$config.list.SoundDevice2
# Auslesen des aktiven Ausgabe-Geräts mit Index
$aplayindex = (Get-AudioDevice -Playback).Index
$aplayname = (Get-AudioDevice -Playback).Name
# Auslesen des aktiven Aufnahme-Geräts mit Index
$arecindex = (Get-AudioDevice -Recording).Index
$arecname = (Get-AudioDevice -Recording).Name
# Geräte-Toogle
if ($aplayindex -eq $dev1) {
$indexnum=$dev2
} elseif ($aplayindex -eq $dev2) {
$indexnum=$dev1
}
# Setzen des prim. Gerätes
Set-AudioDevice -Index $indexnum > $null
$cred.GetNetworkCredential().password
######### Ab hier MQTT #########
# dll reggen
Add-Type -Path "C:\lib\M2Mqtt.4.3.0.0\lib\net45\M2Mqtt.Net.dll"
# Verbinden
$MqttClient = [uPLibrary.Networking.M2Mqtt.MqttClient]($config.list.MQTTServerIP)
# Einloggen
$mqttclient.Connect($config.list.ConnectionID, $config.list.UserName, $cred.GetNetworkCredential().password)
# Nachrichten senden mit QOS 1 (0 = Keine Prüfung / 1 = Nachricht kommt mindestens 1 mal an / 2 = Nachricht kommt maximal 1 mal an) - Kein WillReatin
$MqttClient.Publish($config.list.MQTTTopic+"/play_dev_index", [System.Text.Encoding]::UTF8.GetBytes("$aplayindex"),1,0)
$MqttClient.Publish($config.list.MQTTTopic+"/play_dev_name", [System.Text.Encoding]::UTF8.GetBytes("$aplayname"),1,0)
$MqttClient.Publish($config.list.MQTTTopic+"/rec_dev_index", [System.Text.Encoding]::UTF8.GetBytes("$arecindex"),1,0)
$MqttClient.Publish($config.list.MQTTTopic+"/rec_dev_name", [System.Text.Encoding]::UTF8.GetBytes("$arecname"),1,0)
# 5 Sekunden Delay
for ($i=0; $i -lt 5; $i++)
{
Start-Sleep 1
}
# Verbindung schließen
$MqttClient.Disconnect()
Moin,
bevor ich zum testen komme ganz kurz:
ZitatABER bei
$cred = New-Object System.Management.Automation.PsCredential("UserName", $encrypt)
ist der Name unerheblich.
Naja ich hatte auch so verstanden, dass nur das Passwort verschlüsselt als System String nach $encrypt gegeben wird.
Aber! Du kannst ja das $cred Objekt direkt nutzen z.B. um Laufwerke zu verbinden. Insofern ist es wichtig dort den richtigen UserName anzugeben.
Wenn Du aber aus $cred nur das Passwort im Klartext wieder herausziehen willst/musst ist der UserName natürlich egal.
Gruß Otto
Jo. Das ist also erstmal sicher und läuft soweit.
Nach wie vor ist die Frage ob 1. oder zweite PW Methode. Ich werde das Skript ggf. auch noch ein wenig variabler machen. Man könnte eine Art Schleife bauen und der User kann sich selber aussuchen wie viele Nachrichten er versenden will und wie die Readings in FHEM heißen. Dazu würde ich noch eine Anleitung bezüglich MQTT Client installieren schreiben.
Dann könnte jeder seinen WIN PC in einen MQTT Client für FHEM nutzen. Ich selber finde das super aber natürlich ist es das gleiche wie der HTTP Connector, nur eben über einen anderen Weg. Was hältst du von dem Projekt?
Hi,
ich habe es hinbekommen ::)
Die Vorbereitung (Setup Audio Cmdlet und M2Mqtt) war etwas holprig. Aber geht jetzt. Finde ich aber irgendwie schon wieder relativ aufwendig.
Dann läuft Dein Script einfach durch :)
Muss ich erstmal sacken lassen und noch etwas spielen.
Gruß Otto
Kann man ja alles automatisieren. Ich würde meinen pc als mqtt Device sehen und hätte damit alles möglich was man realisieren kann. Das Skript ist bzw könnte ja nur der Anfang sein.
Ja bei mir ging es auch nicht einfach so. Musste erst mal ne saubere und laufende Quelle finden.
Gesendet von meinem LG-H850 mit Tapatalk
Um das OT in dem anderen Thread nicht noch auszubauen:
Mit "Auswertung" war gemeint, ob irgendwas spezielles passieren soll/der WIN-PC irgendwas auslösen (können) soll usw.. Dazu fehlt mir aber noch jede Vorstellung, was da von wo nach wo (aus welchem grund/zu welchem Zweck) geschickt wird... Wenn es um reine Statusmeldungen geht, macht MQTT2_DEVICE schon soviel automatisch, dass sich ein template dazu kaum lohnen dürfte.
(Wenn das hier OT ist, bitte bei passender Gelegenheit dann einen neuen Thread öffnen ;) ).
Aktuell geht es hier noch um die Überschrift. Da ich das aber schon als Projekt sehe für die Zukunft, sammel ich gerne Ideen. Dafür macht natürlich ein eigener Thread Sinn.
Zum jetzigen Zeitpunkt mache ich nur folgendes:
1. Skript um Wiedergabegeräte an einem Win PC zu wechseln und diese Info via MQTT an FHEM reichen. Dann triggere ich via notify einen Schalter, der mir Strom auf die Boxen gibt oder wieder weg nimmt.
2. Skript um online und offline meines PCs via MQTT an FHEM zu senden.
Wo stelle ich so ein Thread am besten ein (Um Ideen zu sammeln und das Thema weiter aus zu bauen)?
MMn kann das ruhig erst mal hier bleiben.
Hi,
Ich mache mal noch einen Beitrag zum grundlegenden Setup, falls jemand mit Powershell und Windows testen will:
Die AudioDeviceCmdlets (https://github.com/frgnca/AudioDeviceCmdlets) installiert man einfach über Package Management Powershellgallery (https://devblogs.microsoft.com/powershell/powershellget-and-packagemanagement-in-powershell-gallery-and-github/)
Install-Module -Name AudioDeviceCmdlets
Obwohl man das Gleiche für M2Mqtt auch als als Quelle findet (https://www.msxfaq.de/code/powershell/ps_mit_mqtt.htm) funktioniert es leider nicht, da ist irgendwas passiert. Ging ja offenbar schon mal :(
Deswegen umständlicher aber als Kurzfassung von hier (https://jackgruber.github.io/2019-06-05-ps-mqtt/).
wget -O nuget.exe https://dist.nuget.org/win-x86-commandline/latest/nuget.exe
nuget.exe install M2Mqtt -o c:\lib
copy c:\lib\M2Mqtt.4.3.0.0\lib\net45\M2Mqtt.Net.dll
Add-Type -Path "M2Mqtt.Net.dll"
Ich bin immer ein Freund von knappen Setups und habe hier (https://github.com/francoisvdm)für Windows noch einen "schnellen" MQTT Client zum probieren und testen gefunden:
wget -O paho-mqtt3c.dll https://github.com/francoisvdm/TT3/raw/master/paho-mqtt3c.dll
wget -O mfc100.dll https://github.com/francoisvdm/TT3/raw/master/mfc100.dll
wget -O TT3.exe https://github.com/francoisvdm/TT3/raw/master/TT3.exe
start tt3.exe
Ein komplettes mosquitto Setup unter Windows ist vielleicht auch was: https://www.msxfaq.de/sonst/iot/mqtt.htm aber aufwendiger ;)
Gruß Otto
Danke für deine Unterstützung!
Auch wenn wir uns hier im Reich der Dinosaurier und Exen bewegen: Wie wäre es mit dem Einsatz einer Perl-lib (siehe https://metacpan.org/pod/Net::MQTT::Simple (https://metacpan.org/pod/Net::MQTT::Simple) mit weiteren Links)?
Setzt halt das Vorhandensein von Perl auf dem Win-PC voraus, dafür wären wir "in gewohnten Bahnen" und nicht abhängig von "irgendwelchen" gitub-Repos (über deren Qualität ausdrücklich kein Urteil hier gefällt werden soll)...
Naja ich arbeite unter Windows schon gern mit Powershell - da heraus jetzt ne Perl Funktion aufrufen. Auch ein interessanter Ansatz ... ;)
Ich bin morgen 30 km auf dem Elbtalweinlauf in Meißen - da hab ich Zeit (und Wein 🍷🍷🍷 ) da mal drüber nachzudenken.
Zumindest sind mir die Perl Bahnen mittlerweile etwas zugänglicher als irgendwelche C Bibliotheken im Visual Studio Klotz (zumindest ist das die auffindbare "mqtt Welt" in Windows).
Es war noch ein dummer Fehler im Script!
Der Ton konnte nicht umschalten wegen einer dummen Test-Variablen...
(Sound umstellen) - Hier richtig:
#Wenn config Datei nicht vorhanden ist, werden alle Variablen abgefragt um eine config.xml zu erstellen
If (-not (test-path config.xml)) {
# Auflistung der Audio Geräte
Get-AudioDevice -List
# Abfrage der Variablen
$dev1 = Read-Host "Enter first Device ID"
$dev2 = Read-Host "Enter second Device ID"
$serverip = Read-Host "Enter IP-Adress of MQTT Server"
$conid = Read-Host "Choose a MQTT connection ID"
$topic = Read-Host "Choose a MQTT Topic"
$cred = Get-Credential
$usr = $cred.UserName
$pw = $cred.Password | ConvertFrom-SecureString
#### Leere XML Datei erstellen ####
$xmlcreate = New-Object System.Xml.XmlTextWriter("config.xml",$NULL)
#### Formatierung in XML Datei anpassen ####
$xmlcreate.Formatting = "Indented"
$xmlcreate.Indentation = 1
$xmlcreate.IndentChar = "`t"
#### Inhalt für XML Datei ####
$xmlcreate.WriteStartDocument()
$xmlcreate.WriteStartElement("list")
$xmlcreate.WriteElementString("SoundDevice1",$dev1)
$xmlcreate.WriteElementString("SoundDevice2",$dev2)
$xmlcreate.WriteElementString("MQTTServerIP",$serverip)
$xmlcreate.WriteElementString("ConnectionID",$conid)
$xmlcreate.WriteElementString("MQTTTopic",$topic)
$xmlcreate.WriteElementString("UserName",$usr)
$xmlcreate.WriteElementString("Password",$pw)
$xmlcreate.WriteEndElement()
#### XML Datei beschreiben ####
$xmlcreate.WriteEndDocument()
$xmlcreate.Flush()
$xmlcreate.Close()
}
# config.xml einlesen und durchsucbar machen
[xml]$config = Get-Content "config.xml"
# Passwort aus XML einlesen und entschlüsseln
$encrypt = $config.list.Password | ConvertTo-SecureString
$cred = New-Object System.Management.Automation.PsCredential("Username", $encrypt)
# Index der Wiedergabegeräte im System
$dev1=$config.list.SoundDevice1
$dev2=$config.list.SoundDevice2
# Auslesen des aktiven Ausgabe-Geräts mit Index
$aplayindex = (Get-AudioDevice -Playback).Index
# Auslesen des aktiven Aufnahme-Geräts mit Index
$arecindex = (Get-AudioDevice -Recording).Index
# Geräte-Toogle
if ($aplayindex -eq $dev1) {
$aplayindex = $dev2
} elseif ($aplayindex -eq $dev2) {
$aplayindex = $dev1
}
# Setzen des prim. Gerätes
Set-AudioDevice -Index $aplayindex > $null
# Name von Ein und Ausgabegeräte auslesen
$aplayname = (Get-AudioDevice -Playback).Name
$arecname = (Get-AudioDevice -Recording).Name
######### Ab hier MQTT #########
# dll reggen
Add-Type -Path "C:\lib\M2Mqtt.4.3.0.0\lib\net45\M2Mqtt.Net.dll"
# Verbinden
$MqttClient = [uPLibrary.Networking.M2Mqtt.MqttClient]($config.list.MQTTServerIP)
# Einloggen
$mqttclient.Connect($config.list.ConnectionID, $config.list.UserName, $cred.GetNetworkCredential().password) > $null
# Nachrichten senden mit QOS 1 (0 = Keine Prüfung / 1 = Nachricht kommt mindestens 1 mal an / 2 = Nachricht kommt maximal 1 mal an) - Kein WillReatin
$MqttClient.Publish($config.list.MQTTTopic+"/play_dev_index", [System.Text.Encoding]::UTF8.GetBytes("$aplayindex"),1,0) > $null
$MqttClient.Publish($config.list.MQTTTopic+"/play_dev_name", [System.Text.Encoding]::UTF8.GetBytes("$aplayname"),1,0) > $null
$MqttClient.Publish($config.list.MQTTTopic+"/rec_dev_index", [System.Text.Encoding]::UTF8.GetBytes("$arecindex"),1,0) > $null
$MqttClient.Publish($config.list.MQTTTopic+"/rec_dev_name", [System.Text.Encoding]::UTF8.GetBytes("$arecname"),1,0) > $null
# Delay
for ($i=0; $i -lt 1; $i++)
{
Start-Sleep 1
}
# Verbindung schließen
$MqttClient.Disconnect()
Benutzer angemeldet (geht natürlich auch mit abgemeldet. Habe es bei mir via GPO drin):
# config.xml einlesen und durchsucbar machen
[xml]$config = Get-Content "config.xml"
# Passwort aus XML einlesen und entschlüsseln
$encrypt = $config.list.Password | ConvertTo-SecureString
$cred = New-Object System.Management.Automation.PsCredential("Username", $encrypt)
# dll reggen
Add-Type -Path "C:\lib\M2Mqtt.4.3.0.0\lib\net45\M2Mqtt.Net.dll"
# Verbinden
$MqttClient = [uPLibrary.Networking.M2Mqtt.MqttClient]($config.list.MQTTServerIP)
# Einloggen
$mqttclient.Connect($config.list.ConnectionID, $config.list.UserName, $cred.GetNetworkCredential().password)
# Es wird kein LastWill benötigt
#Parameter: string clientid, username, password, willRetain [0/1], willQosLevel [0/1/2], willFlag [0/1], willTopic, willMessage, cleanSession [0/1], keepAlivePeriod)
#$mqttclient.Connect($conid, "$usr", "$pw", 0, 0, 1, "$topic/hier_reading", "test", 1, 60 )
# Nachricht senden mit QOS 1 (0 = Keine Prüfung / 1 = Nachricht kommt mindestens 1 mal an / 2 = Nachricht kommt maximal 1 mal an) - Kein WillReatin
$MqttClient.Publish($config.list.MQTTTopic+"/online", [System.Text.Encoding]::UTF8.GetBytes("true"),1,0)
# Delay
for ($i=0; $i -lt 1; $i++)
{
Start-Sleep 1
}
# Verbindung schließen
$MqttClient.Disconnect()
Kennt jemand was besseres und komplettes um PS komplett unsichtbar bzw nicht im Userkontext aus zu führen? Damit ist gemein -> KEIN Fenster.
-windowstyle hidden macht zwar das Fenster fast weg aber kurz blinkt es auf.
Wie rufst Du es denn jetzt auf? Sicher das es nicht die Batch ist die kurz aufblitzt?
Ohne Batch.
Hoch und runter fahren via GPO. Das ist auch sauber ohne fenster.
Den Musik toggle mache ich via G Knopf an meiner Logitech Tastatur. Diese ruft mit Command und dem Hide Window die ps1 auf.
"powershell.exe -WindowStyle Hidden -noninteractive -command "&{C:\Users\kaich\Desktop\PS\Sound_umstellen.ps1}""
(siehe Bild)
Gesendet von meinem LG-H850 mit Tapatalk
Zitat von: Beta-User am 11 Oktober 2019, 14:16:17
....
Setzt halt das Vorhandensein von Perl auf dem Win-PC voraus, dafür wären wir "in gewohnten Bahnen" und nicht abhängig von "irgendwelchen" gitub-Repos
....
Ich habe über die "gewohnten" Bahnen nochmal nachgedacht :) - und heut zufällig auch schon was getestet. Ein durchaus gewohnter Ansatz wäre auch der mosquitto_sub Client
Das Setup unter Windows ist unkompliziert und schnell, genauso wie die Verwendung per Kommandozeile. Auch die Doku ist als manpage einfach da :) Und damit wäre die Verwendung unter Windows und linux gleich. Also auch für den Fall das man von linux Systemen ohne FHEM usw. einfach mal ein paar Werte an den FHEM Server schicken will.
Auf debian braucht man nur mosquitto-clients für mosquitto_pub
Auf Windows https://mosquitto.org/download/ die exe herunterladen und dann ohne den Dienst installieren. Anschließend hat man "C:\Program Files\mosquitto\mosquitto_pub.exe"
Kann man dann sicher auch ganz einfach aus der Powershell aufrufen.
Gute Idee und einheitlich. Müsste man nur schauen in wie weit man das bisherige Script anpassen müsste. Da mqtt immer nach dem gleichen Prinzip funktioniert, kann es nicht mal viel sein.
Hattest du das Script mal getestet? Hab es bei mir seit Fertigstellung aktiv und habe genau was ich wollte. Läuft 1a.
Einzig der delay am Ende vor dem Disconnect nervt. Wenn der auf eine sekunde steht reicht das aber am liebsten hätte ich den ganz weg. Das sorgt aber bei mehreren Nachrichten dafür, dass nicht alle durch kommen, da die Verbindung schneller getrennt ist als das gesendet worden ist. Ggf macht es der andere Client auch einfach besser. Also ein Grund mehr das zu testen.
Gruß,
Kai
EDIT: http://www.steves-internet-guide.com/mosquitto_pub-sub-clients/
Auch direkt was gefunden. Geht sogar mit Zertifikaten usw. Nochmal eine kleine Nummer besser.
@Beta-User: Kann der MQTT2 FHEM Server SSL o.ä.?
Gesendet von meinem LG-H850 mit Tapatalk
Ja klar hatte das Script getestet, lief ohne Probleme.
Mal auf die Schnelle am Ende von deinem Script umgesetzt:
$mclient="C:\Program Files\mosquitto\mosquitto_pub.exe"
$arguments = "-h",$config.list.MQTTServerIP,"-i",$config.list.ConnectionID,"-u",$config.list.UserName,"-P",$cred.GetNetworkCredential().password
$arg=$arguments + "-t",$($config.list.MQTTTopic + "/play_dev_index"),"-m",$aplayindex
& $mclient $arg
$arg=$arguments + "-t",$($config.list.MQTTTopic + "/play_dev_name"),"-m",$aplayname
& $mclient $arg
$arg=$arguments + "-t",$($config.list.MQTTTopic + "/rec_dev_index"),"-m",$arecindex
& $mclient $arg
$arg=$arguments + "-t",$($config.list.MQTTTopic + "/rec_dev_name"),"-m",$arecname
& $mclient $arg
Nur der Zeichensatz ist etwas vermurkst. Und FHEMWEB ist irgendwie kurz weg :-[
Mqtt kann ich ja ganz okay mittlerweile. Gucke ich am we auf jeden Fall nach....freu mich schon
Ach ja und beim lesen sehe ich das jedes mal eine LW Message (zumindest wegen dem immer wieder einloggen) gesendet wird - Aber LW Nachricht ohne LW. Brauchen wir hier ja nicht. Bzw du loggst dich jedes mal neu ein. Bei LW (Lastwill) Nachrichten macht das Sinn aber bei diesem Ton Zeugs nicht. Da ich aber auch noch nicht alles gelesen habe zu dem Client muss ich erstmal gucken wie das geht mit einmal einloggen und am Ende wieder trennen. Vermutlich ist das auch das Problem warum FHEM dann kurz weg ist. Oder siehst du im LOG noch ein paar Infos?
In dem Fall sollte eine normale Nachricht mit QOS 1 oder 2 gesendet werden. Ohne Retain oder oder sonst was. Allerdings hat der neue Client viel mehr Variablen. Das wird ein schönes WE :)
Gesendet von meinem LG-H850 mit Tapatalk
Zu ssl: Ich bin da nicht der Experte, aber mWn. ist das einer der Vorteile von MQTT2_(SERVER|CLIENT), dass die Kommunikation verschlüsselt werden kann (via allowed). Das müßte für den SERVER v.a. auch die Authentifizierung der Clients am Server betreffen ;) .
Zitat von: Beta-User am 16 Oktober 2019, 17:16:21
Zu ssl: Ich bin da nicht der Experte, aber mWn. ist das einer der Vorteile von MQTT2_(SERVER|CLIENT), dass die Kommunikation verschlüsselt werden kann (via allowed). Das müßte für den SERVER v.a. auch die Authentifizierung der Clients am Server betreffen ;) .
Das wäre schlecht. Sicher können nicht alle Clients verschlüsseln. Alleine die Shellys können es nicht. Also müsste ich mal gucken ob man das für einige Geräte erlauben kann und für andere nicht.... Danke!
allowed läßt sich mWn gerätespezifisch einrichten, ist halt ggf. "etwas" Aufwand...
Wenn wir schon so viel Mühe in die Codierung stecken, sollte das als Traffic nicht wieder entschlüsselt sein. Deswegen wäre es mir den Aufwand wert :)
Zitat von: 87insane am 16 Oktober 2019, 16:56:54
Ach ja und beim lesen sehe ich das jedes mal eine LW Message (zumindest wegen dem immer wieder einloggen) gesendet wird - Aber LW Nachricht ohne LW. Brauchen wir hier ja nicht. Bzw du loggst dich jedes mal neu ein.
Ja alles jedes mal in einer Zeile, ich weiß es einfach (noch) nicht anders. Es war einfach die Kommandozeile und die ging auf Anhieb :)
Denke das bekommen wir hin!
Beta-User hat schonmal gesagt das wir verschlüsseln können (ggf.)
Und du hast den neuen Client gefunden.
Nun muss das nur noch ein wenig angepasst werden... hatte mich ewig lang in MQTT eingelesen um überhaupt zu verstehen wofür genau was ist....
Zitat von: 87insane am 16 Oktober 2019, 17:26:19
Wenn wir schon so viel Mühe in die Codierung stecken, sollte das als Traffic nicht wieder entschlüsselt sein. Deswegen wäre es mir den Aufwand wert :)
Habe grade nochmal in die Doku gesehen. Es scheint so zu sein, dass man ssl halt _pro Server_ setzen kann/muß und nur die Frage, ob zusätzlich auch user/pw benötigt wird via allowed geregelt wird. Das würde ggf. bedeuten, dass man mehrere Server-Instanzen braucht...
Kannst du die Systemlast einschätzen? Ich meine wenn der Server nur rum idelt, ist bzw wäre das egal. Sollte das aber auch im Idle zu viel ziehen, hmmmm....
Verbessere mich auch mal und sage nicht mehr SSL sondern TLS. Ich finde nur sowas wie "(Hier fehlt eine Anleitung für allowed usw.)"
Kannst du mir ggf. einen Link zukommen lassen?
Würde eine kleine Wette auf "marginal" anbieten, aber im Ernst: k.A.... Bitte messen oder Rudi fragen
OT - Sagt mal, sieht man hier eigentlich wenn man @Username schreibt als Verlinkung oder nicht? Bin mir in dem Forum hier echt unsicher..
Falls sich das mit mosquitto_pub auf Kommandozeile als Sackgasse herausstellen sollte (was ich befürchte: mosquitto_pub is a simple MQTT version 5/3.1.1 client that will publish a single message on a topic and exit.) dann ist vielleicht der hier besser:
https://hivemq.github.io/mqtt-cli/
gibt es auch für windows und linux :)
Zitat von: Otto123 am 16 Oktober 2019, 23:10:38
Falls sich das mit mosquitto_pub auf Kommandozeile als Sackgasse herausstellen sollte (was ich befürchte: mosquitto_pub is a simple MQTT version 5/3.1.1 client that will publish a single message on a topic and exit.) dann ist vielleicht der hier besser:
https://hivemq.github.io/mqtt-cli/
gibt es auch für windows und linux :)
Hatte auch mal nachgesehen und du hast Recht. Es geht hier wirklich immer nur verbinden, senden, Verbindung trennen in einer Zeile. Ich schaue mal nach dem anderen Client, den du schon gefunden hattest. Gibt ja einige....
MQTT CLI kann das wieder alles! Super Ding. Hab mir mal die Doku angesehen und wenn nichts dagegen spricht würde ich diesen dann einbauen und testen.
https://hivemq.github.io/mqtt-cli/docs/shell/connect
Hier kann ich leider nur lesen und nicht testen... Normal würde ich sagen die ganzen MQTT Varianten sind kompatibel untereinander.
Bin aber aber wegen folgendem unsicher. Das teste ich aber noch.MQTT CLI is a full MQTT 5.0 and MQTT 3.1.1 compatible command line interface for MQTT clients which uses the HiveMQ MQTT Client API.Auch gut. Man kann sogar mit einem Befehl, mehrere Dinge auf einmal publishen. Da könnte der Delay dann weg fallen :)
Man muss bei dem hivemq mqtt pub auf alle Fälle -V 3 angeben.
Das mit dem mehrere Dinge in einer Zeile publishen ist aber nur die message und alles für einen Topic? Dann wird doch alle sin ein Reading geschrieben?
Ich habe da gestern abend rumprobiert, habe aber noch so meine Probleme :)
Der shell Modus macht das was Du willst, aber wie steuert man den wirklich per Commandline?
ZitatMan muss bei dem hivemq mqtt pub auf alle Fälle -V 3 angeben.
Da ich noch nicht testen konnte, weiß ich das nicht. Aber mit V5 geht nicht?
ZitatDas mit dem mehrere Dinge in einer Zeile publishen ist aber nur die message und alles für einen Topic? Dann wird doch alle sin ein Reading geschrieben?
Ne das kann man direkt in mehrere Topics werfen:
Example: Simple Publish of a message to several topics
mqtt pub -t test1 -t test2 -m "Hello Test1 and 2"
-> creates an MQTT 5 client and connects to the default broker address
-> publishes a "Hello Test1 and 2" to the test1 and test2 topics and receives two PUBACK
-> disconnects the clientQuelle: https://www.hivemq.com/blog/mqtt-cli/
ZitatDer shell Modus macht das was Du willst, aber wie steuert man den wirklich per Commandline?
Kann ja leider nur lesen und nicht testen hier....
V 5 geht nicht.
Ja sorry hatte ich verwechselt, also mehrere Topics, aber überall die gleiche message - auch nicht das was wir wollten?
Ich habe hier (https://unix.stackexchange.com/questions/188525/how-to-subscribe-a-bash-script-as-a-mqtt-client)noch was gefunden. Kurz gesagt ist das so was wie ein "Dienst", der sich beim mqtt Server anmeldet, auf Nachrichten wartet, diese Nachricht lokal als Befehl ausführt und die Ausgabe zurück published.
Guten Morgen Otto123,
ich teste erstmal ganz normal und versuche um zu bauen. Danach kann man ja schauen ob es noch ein wenig besser geht. Wenn ich die Doku richtig verstanden habe, ist bei MQTT CLI eine eigene Warteschlange mit drin. Das wäre schon mal super.
Was die Nachrichten in einer Zeile angeht, hatte ich das so verstanden, das dies auch trennbar ist. Also eine Zeile, mehrere Topics aber auch Nachrichten möglich. Aber das ist alles nur Glaskugel ohne Test. Das WE ist aber fast eingeläutet :)
SORRY!
Am WE haben sich die Ereignisse überschlagen und ich hatte keine Zeit. Hole das aber nach -> Versprochen!