Lidl WI-FI Steckdose SWS-A1 SilverCrest IAN 103043

[mkh]

Kleiner Erfahrungsbericht nach einigen Wochen Betrieb von mehreren Weihnachtsbeleuchtungen:

Alles funktioniert grundsätzlich.

Es kommt jedoch vor, dass die Dosen nicht schalten, da ein Befehl "verschluckt" wurde.
Ich habe es so gelöst, dass ich in FHEM z.B. den WeekdayTimer 2x mit einem kleinen Versatz ausführen lassen. Das funktioniert recht zuverlässig.
Der Status der Dose entspricht nicht immer dem realen Status.

Ergebnis: Sehr gut / günstig bei nicht wichtigen Schaltungen. Ich bereue nicht diese Aktoren gekauft zu haben.
Bei hoher Anforderung, dass die Dosen auch wirklich schalten, benutze ich die Homematic Aktoren z.B. um meinen Entfeuchter im Keller zu schalten, da er sicher ein und ausgeschaltet werden muss.

Reichweite des Masters zu den Slaves liegt bei mir, je nach Anzahl/Beschaffenheit der Wände bei 3 bis 7 m.
Danach erkenne ich vermehrt "verschluckte" Befehle.

Deshalb habe ich u.a. die Weihnachtsbeleuchtung am Balkonfenster mit einem Master bestückt und direkt draussen den Wetterfesten Slave für die Balkonbeleuchtung.
Vorher war der Master in einem anderen Raum und sollte von da den Balkon und das Balkonfenster steuern.
Mit den Master (ich habe in Summe 3) gibt es so gut wie keine Steuerprobleme, nur mit den Slaves.

Ich hoffe, es hat Euch geholfen.

MKH   

[SebiM]

Hallo M.,

Kleiner Erfahrungsbericht nach einigen Wochen Betrieb von mehreren Weihnachtsbeleuchtungen:

Alles funktioniert grundsätzlich.

Es kommt jedoch vor, dass die Dosen nicht schalten, da ein Befehl "verschluckt" wurde.

Hmm mit welcher Version des FHEM-Moduls?

Also grundsätzlich, was mich betrifft und meine Patches: Ich bin weder in Perl ein großer Held (kaum Erfahrung), noch kenne ich FHEM intern auswendig. Ich hatte zuletzt im FHEM-Modul ja noch das Auslösen einer Status-Abfrage und generell die Auswertung der Statusmeldungen der Dosen eingebaut.
Ob das nun in der letzten Version (vom 26.11.16 müsste die sein) zu 100% stabil funktioniert, darf bezweifelt werden. Rein theoretisch gehen würde es aber, ich wusste nur auch nicht ganz genau, wie... mit den ganzen internen Zustands-Übergängen im Modul.
Die Theorie:
1. Initialisierung des Moduls bzw. neue Dose hinzugefügt: Erstmal den Status abfragen
2. Schaltvorgang: Senden und eben ggf. ein paar Mal wiederholen, bis über den UDP-Receiver der Schaltvorgang bestätigt wurde.

Ich hatte jetzt halt in den letzten Wochen FHEM mal wieder gar nicht im Einsatz, und das Modul nicht mehr weiterverfolgt -- u.a. auch weil es _dazu_ keine Rückmeldungen mehr gab.

Ergebnis: Sehr gut / günstig bei nicht wichtigen Schaltungen. Ich bereue nicht diese Aktoren gekauft zu haben.
Bei hoher Anforderung, dass die Dosen auch wirklich schalten, benutze ich die Homematic Aktoren z.B. um meinen Entfeuchter im Keller zu schalten, da er sicher ein und ausgeschaltet werden muss.

Hmja. Das können wir aber getrost auf die Problemchen (Bugs) im FHEM-Modul schieben; die Dosen selbst wären nicht das Problem.
Klar, die RF-Dosen sind was anderes, systembedingt....

Reichweite des Masters zu den Slaves liegt bei mir, je nach Anzahl/Beschaffenheit der Wände bei 3 bis 7 m.
Danach erkenne ich vermehrt "verschluckte" Befehle.

Die App sendet die Befehle ja auch immer ich meine 3x; das FHEM-Modul etc., je nach Version... die Neueren auch. Auch hier könnte man zur weiteren Absicherung noch was einbauen, dass er z.B. 3x nicht nur einfach gesendet hat, sondern auch 3x eine Bestätigung der Master-Steckdose bekommen hat, dass sie den RF-Befehl gesendet hat. "Sicher" wird's dadurch zwar auch nicht, aber sicherer. Wen's dann noch stört, darf halt die RF-Dosen nicht verwenden. Aber für sowas wie dezente Weihnachtsbeleuchtung sind die ja ganz okay.

Mit den Master (ich habe in Summe 3) gibt es so gut wie keine Steuerprobleme, nur mit den Slaves.
Ich hoffe, es hat Euch geholfen.

Das mit den Slaves war ja fast zu erwarten. Sonst, klar, Rückmeldungen aller Art sind immer gut...

Wie es jetzt weitergeht mit dem Modul? Keine Ahnung... *Ich* will da im Moment nichts weiter versprechen. Die Grundlage ist ja da.

[mkh]

Hallo SebiM,

danke für die Stellungsnahme.
Aus meiner Sicht funktioniert alles ausreichend gut Dadurch ist aktuell kein Handlungsbedarf nötig.
Ich habe das Modul vom 26.11.16. Daher sollte alles passen.

Ich wusste nicht, dass jeder Befehl 3x gesendet wird, ich habe bisher die Aussetzer dadurch in den Griff bekommen, dass ich eine Sekunde später noch einmal den Befehl versendet habe.

Aus meiner Sicht: ALLES BESTENS! DANKE FÜR DIE MÜHE!!

Frohes neues Jahr,

MKH

[GhostInTheBottle]

Ich muss zugeben, ich bin etwas verwirrt. Ich hatte das Medion Set erworben, als ich mich noch nicht mit Fhem beschäftigt hatte (MD16173). Nun ist es mir gelungen die MasterWifi Steckdose zu schalten (erfolgreich).
Das erste, was ich nicht verstehe, weshalb steht jetzt RFSLAVE im Log,
2017.01.06 00:02:03 3: [MedionGW] Set  MedionGW with IP 192.168.2.164 MAC AC:CF:23:C9:AC:B8 RFSLAVE  ,off
Eintrag in Fhem.cfg:

define MedionGW Silvercrest_SWS_A1_Wifi 192.168.2.164 AC:CF:23:C9:AC:B8 C1117150
attr MedionGW room AZLutz

Es handelt sich doch um die Wifi Dose ?!

Zweites (echtes) Problem: Mit den drei Funksteckdosen (Code ermitteln)  komme ich nicht wirklich weiter. Der WLAN Dump mit meiner Fritz-Box 6490 funktioniert nicht - es kommt kein 'Speichern' Dialog. Welche Alternativen habe ich? Alle drei RF Dosen sind mit icomen angelernt und funktionieren mit der App.

Beruflich bin ich IT-Admin, aber ich schäme mich, weil sich mir mit der ganzen RF und Crypt Geschichte nicht wirklich auf Anhieb erschließen

[SebiM]

Ich muss zugeben, ich bin etwas verwirrt. Ich hatte das Medion Set erworben, als ich mich noch nicht mit Fhem beschäftigt hatte (MD16173). Nun ist es mir gelungen die MasterWifi Steckdose zu schalten (erfolgreich).
Das erste, was ich nicht verstehe, weshalb steht jetzt RFSLAVE im Log,
2017.01.06 00:02:03 3: [MedionGW] Set  MedionGW with IP 192.168.2.164 MAC AC:CF:23:C9:AC:B8 RFSLAVE  ,off

Das ist schon in Ordnung. Das bedeutet nur, dass eben keine RF-Adresse angegeben ist, also eine WiFi-Master-Dose gemeint ist. Dann ist der Parameter RFSLAVE einfach leer.
Das Modul sendet eben unterschiedliche Kommandos an die WiFi-Dose, je nachdem wer nun wirklich geschaltet werden soll.

Zweites (echtes) Problem: Mit den drei Funksteckdosen (Code ermitteln)  komme ich nicht wirklich weiter. Der WLAN Dump mit meiner Fritz-Box 6490 funktioniert nicht - es kommt kein 'Speichern' Dialog. Welche Alternativen habe ich? Alle drei RF Dosen sind mit icomen angelernt und funktionieren mit der App.

Wenn das Dumping nicht geht oder machbar ist (bin da auch immer zu faul zu mit dem blöden Netzwerk-Setup; mein Asus-Router kann nicht von Haus aus dumpen), dann via die App.
Ich hatte mal ein Verfahren für gerootete Android-Geräte beschrieben; mittlerweile aber auch ein PHP-Shellscript zum Abruf der Daten gebastelt. Oder auch ein Web-Frontend, falls lokaler Webserver mit PHP zur Hand.

Links kommen per PN...

Beruflich bin ich IT-Admin, aber ich schäme mich, weil sich mir mit der ganzen RF und Crypt Geschichte nicht wirklich auf Anhieb erschließen

Kenne ich

[SebiM]

Ich wusste nicht, dass jeder Befehl 3x gesendet wird, ich habe bisher die Aussetzer dadurch in den Griff bekommen, dass ich eine Sekunde später noch einmal den Befehl versendet habe.

Aaargh nein sorry, das mit dem 3x senden habe ich nur in meinem PHP-Script eingebaut, nicht im FHEM-Modul. Da kruschtelt aber der alte originale Code noch irgendwas herum, was ich auf die Schnelle nicht ganz verstanden habe.

Irgendwann werde ich mir das alles sicherlich nochmal anschauen, spätestens wenn's mich nervt. Aber im Moment habe ich noch andere Baustellen; und mein Raspi 3, auf dem derzeit alles läuft, wackelt immer mehr herum (vermutlich MicroSD-Karte hinüber), das ist zum vernünftigen Testen eh etwas blöd...
Man müsste das doch über FHEM selbst auch irgendwie machen können? Den Query-Befehl senden und gucken, ob der On/Off-Status nun passt -- und wenn nicht, nochmal senden?

[belto]

Hallo zusammen

Ich habe mir eine CASAcontrol Basis Easy von Pearl gekauft http://www.pearl.ch/ch-a-CH1810-3100.shtml

Ein- und ausschalten funktioniert mit den Befehlen:
Ein: 4CF75F5A28A181574AC1B563CD51A78D
Aus: F7B4E74B970D96F3CA2BB5D3CD1C19D0
welche als Hex auf Port 8530 UDP gesendet werden

Ganzer Python3 Code:

Code Auswählen Erweitern

#!/usr/bin/env python3
import socket
import time

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, 0)
s.connect(('192.168.1.116', 8530)) # (IP, Port) is a single variable passed to connect function
time.sleep(1)
s.send(bytes.fromhex('01 40 AC CF 23 4F 3E 60 10 4C F7 5F 5A 28 A1 81 57 4A C1 B5 63 CD 51 A7 8D')) # to switch 'on'
time.sleep(5) # sleep for 5 seconds
s.send(bytes.fromhex('01 40 AC CF 23 4F 3E 60 10 F7 B4 E7 4B 97 0D 96 F3 CA 2B B5 D3 CD 1C 19 D0')) # to switch 'off'

Was noch nicht funktioniert ist das Ansteuern der dazupassenden RF-Funksteckdose http://www.pearl.ch/ch-a-CH1811-3100.shtml
Woher bekomme ich die RF-Adresse? Das System wird über die CASAcontrol WLAN App gesteuert https://play.google.com/store/apps/details?id=com.bugull.pearl&hl=de und ist wohl baugleich mit der Lidl-Variante, CompanyCode und AuthCode sind nämlich die gleichen.

[GhostInTheBottle]

Also, ich kann inzwischen dumpen/tracen, weil ich nun das Netz für die Gateways nit einem AVM Repeater 300E (Lan Bridge) aufgenaut habe. Nun wird mir bei den WLAN Dumps auch immer das Speichern angeboten.Wireshark habe ich auch installiert. Aber was soll das alles? Was davon soll ich denn nun sinnvollerweise tracen.

wifi0    
ath0    

WLAN

AP (2.4 GHz, ath0) - Schnittstelle 1    
AP (2.4 GHz, ath0) - Schnittstelle 0    
HW (2.4 GHz, wifi0) - Schnittstelle 0    
WLAN Management Traffic - Schnittstelle 0

Wieso hat der AP zwei Schnittstellen - egal, der Traffic wird in Wireshark angezeigt und ich finde auch das was zwischen der FHEM Büchse und dem Medion WiFi Teil hin und her geht. Es ist allerdings schon spät und für das Ansprechen der RF Dosen mit der App fehlt mir jetzt die Zeit, denn da müssten die Packetdaten ja etwas anders aussehen. Das heisst jetzt nicht dass ich die php Geschichte nicht weiter verfolge, aber es scheitert schon bei der Identifikation am asiatischen Webserver, jedenfalls bei dem Medion Zeugs.

Ist eigentlich mit dem Tracen alles herauszubekommen, was man zur FHEM Einbindung beliebiger WiFi App Konstrukte (Licht wird über Taiwan an- und ausgeschaltet) benötigt. Bei der neuen Firmware von G-Homa ist ja nun auch irgendwie Endstation. Also noch 'ne Büchse, die die DNS Anfragen 'umbiegt', in Windows oder Linux keine Kunst, aber bei der Fritzbox eher Fehlanzeige.

[GhostInTheBottle]

Bitte mein Geschwätz von gestern vergessen... Ich habe auf meinem Fritzrepeater meine eigene WLAN SSID eingerichtet. In diesem Netz richte ich nun per App meine suspekten Schaltsteckdosen ein, die ich dann in diesem Hilfsnetz belasse. Anschliessend gehe ich mit meinem iPad in das Wlan Netz der Fritzbox. Damit erzwinge ich dass jeglicher Traffic von und zu den Steckdosen immer erst über die LAN Bridge muss. Auf dem Repeater kann ich nun eth0 tracen und bekomme wirklich alle Pakete in Wireshark zu sehen. Nun kommt das Thema entschlüsseln und da fehlt mir leider noch der Background. Um es kurz zu machen, ich sehe die Pakete, wenn ich RF-Slave 1-3 mit der icomen App ein- und ausschalte, mir fehlt aber ganz einfach der Workflow, wie ich diese Ergebnisse so umsetze, dass ich mit FHEM diese drei Slaves auch steuern kann. Muss ich wirklich noch die RF befehle der Fernbedienung belauschen?

[SebiM]

Nein, notwendig sind nur die MAC-Adresse der WiFi-Dose, die senden soll; und wenn RF-Gedöns gemeint sein soll, dessen 24-Bit-Adresse. Die IP-Adresse der WiFi-Dose ist eher Kosmetik, weil der Broadcast (4x 255) unter gewissen Betriebssytemen nicht geht.

[GhostInTheBottle]

Möglicherweise haben wir uns missverstanden, Ich habe jeweils einen Wireshark Trace (sozusagen 'man in the middle') vom Ein- und Auschalten: Der WiFi Dose, RFSlave1, RFSlave2, RFSlave3.
Ich gehe mal davon aus, die von mir benötigten zusätzlichen 24bit, um den richtigen Slave in FHEM zu definieren bzw. anzusprechen, stecken da drinn, aber genauso verschlüsselt wie die Kennung der WiFi Masterdose.Ist ja auch alles in diesem Thread wunderschön erklärt ...

Nun soll doch ein Java Script in diesem Thread existieren, das die Packete decrypten kann, angeblich zu finden auf der zweiten Seite dieses Threads. Nur, da ist nichts zum Downloaden, ausser dass sich alle bei Peter bedanken.
Wurde das möglicherweise zurückgezogen/gelöscht?

Ich bin ja nicht wirklich beratungsresistent und komme, wenn das ein Irrweg ist, gerne auf die php Geschichte zurück, auch wenn das ein Thema ist, mit dem ich bisher die wenigsten Berührungspunkte hatte

[SebiM]

Möglicherweise haben wir uns missverstanden, Ich habe jeweils einen Wireshark Trace (sozusagen 'man in the middle') vom Ein- und Auschalten: Der WiFi Dose, RFSlave1, RFSlave2, RFSlave3.
Ich gehe mal davon aus, die von mir benötigten zusätzlichen 24bit, um den richtigen Slave in FHEM zu definieren bzw. anzusprechen, stecken da drinn, aber genauso verschlüsselt wie die Kennung der WiFi Masterdose.Ist ja auch alles in diesem Thread wunderschön erklärt ...

Nun soll doch ein Java Script in diesem Thread existieren, das die Packete decrypten kann, angeblich zu finden auf der zweiten Seite dieses Threads. Nur, da ist nichts zum Downloaden, ausser dass sich alle bei Peter bedanken.
Wurde das möglicherweise zurückgezogen/gelöscht?

Ich bin ja nicht wirklich beratungsresistent und komme, wenn das ein Irrweg ist, gerne auf die php Geschichte zurück, auch wenn das ein Thema ist, mit dem ich bisher die wenigsten Berührungspunkte hatte

Verstehe ich gerade nicht ganz, bin aber auch noch etwas benommen (siehe letzte PN)
Den ganzen PHP-Krams hast du doch, da steht doch an sich alles drin.
Wirf doch mal so ein getracetes UDP-Paket -- sollte 25 Bytes lang sein -- als Hex-String in meinen Online-Decoder, oder lasse das PHP-Script selbst irgendwo laufen. Dann sieht man doch den Aufbau mehr als genau.
Mit Gewalt geht das selbst auf der Shell irgendwie, wie auch mit Java, Perl und was weiß ich noch alles. Dass man hier nur schlecht was wiederfindet, öhm ja, empfinde ich auch so.
Der sog. Payload-Anteil im UDP-Paket, die letzten 16 Bytes, sind einfach nur AES-verschlüsselt, mit dem Schlüssel 0123456789ABCDEF -- und zwar als String, diesen bitte nicht als Hex lesen.

[ohuf]

Hallo zusammen!

VIELEN DANK an alle hier, aber insbesondere an SebiM!!!
Habe gestern das Modul in Betrieb genommen, und dann relativ problemlos drei ALDI WiFi-Steckdosen samt RF-Slaves am FHEM verbunden.
Danke auch für den php-Sourcecode, um die Daten aus der Cloud auszulesen -- endlich mal ein echter Zusatznutzen durch einen Cloud-Account: die RF-IDs hätte ich sonst nur schwer auslesen können...   

BTW: eine Sicherheitsfrage habe ich dann doch noch: Werden eigentlich die WLAN-Daten (SSID und Password) ebenfalls in der Cloud gespeichert? In der JSON-Datenstruktur sind sie ja nicht drin.

Weiterhin geht es mir um die Absicherung der WiFi Stecker: Die Dinger spannen ja zwei Netze auf: zum einen stecken sie als Client im Heimnetz. Hier erhalten sie die Steuerdaten von der App (bzw. vom FEHM), und kommunizieren mit der Cloud.

Zum anderen gibt es da noch das Konfigurationsnetz "Li-Link", über das (vermutlich) die initiale Konfiguration durch die App erfolgt.
Das ist als unverschlüsseltes WLAN eingerichtet. Zusammen mit dem Standard-Login auf dem Webinterface und der Möglichkeit, das Password des Heimnetzes dort im Klartext anzuschauen, bleibt ein ziemlich mulmiges Gefühl...

Nun habe ich es aber nicht geschafft, mich auf das WLAN "Li-Link" zu verbinden, da die SSID des Konfigurations-AP im konfigurierten Zustand abgeschalten ist.
(im WebInterface: "Modus-Einstellung >> Modusauswahl >> STA-Modus"  und NICHT "AP+STA-Modus"!!!! )

Letzten Endes bleibt dann noch, das Kennwort des Admin-Users auf dem Webfrontend zu ändern, damit sich niemand "versehentlich" aus dem Lokalen Netz darauf verirrt.

Ach ja: Seltsam, dass zwar die Netzdaten (IP, Subnet, Gateway) vom DHCP Server im Netz übernommen werden, aber nicht der lokale DNS-Server (üblicherweise der Router). Der DNS in den Steckern ist fest eingestellt auf 114.114.114.114 (Adresse in China).
Der DNS Server  lässt sich erst ändern, wenn die IP-Adressvergabe auf "statisch" umgestellt wurde (im Webinterface: "STA-Einstellungen >> erhalten Sie" auf "Deaktivieren")
Wahrscheinlich ist es sowieso das Beste, wenn man dem Stecker verbietet, mit "draussen" zu reden. Und DNS Exfiltration ist eh schwer zu unterbinden...


Wie gesagt: DANKE für die Arbeit!!!

[derdom]

Voraussetzungen: Ein Webserver mit PHP im gleichen Netzwerk wie die Dosen

Servus SebiM, sehr, sehr coole Arbeit, vielen Dank!

Es müsste ja auch die Möglichkeit geben die Dosen per API-Aufruf zu schalten, wenn ich nicht im gleichen Netzwerk bin wie die Dosen, oder? Wie würde das funktionieren?

[SebiM]

So hi, besser ne späte Antwort als gar keine...

Hallo zusammen!

VIELEN DANK an alle hier, aber insbesondere an SebiM!!!
Habe gestern das Modul in Betrieb genommen, und dann relativ problemlos drei ALDI WiFi-Steckdosen samt RF-Slaves am FHEM verbunden.
Danke auch für den php-Sourcecode, um die Daten aus der Cloud auszulesen -- endlich mal ein echter Zusatznutzen durch einen Cloud-Account: die RF-IDs hätte ich sonst nur schwer auslesen können...   

Erstmal danke, gerne...
Tja ähm die Alternative wäre wohl nur, den Steuerbefehl an die WiFi-Dosen vollständig zu dekodieren, der sie anweist, einen RF-Code zu vergeben. Irgendwo habe ich den auch schonmal gesehen in der dekompilierten App, aber nachdem das bislang keiner brauchte...

BTW: eine Sicherheitsfrage habe ich dann doch noch: Werden eigentlich die WLAN-Daten (SSID und Password) ebenfalls in der Cloud gespeichert? In der JSON-Datenstruktur sind sie ja nicht drin.

Ne, relativ sicher nicht. Reicht ja schon, wenn das beim Anlernen über das komische SmartLink-Verfahren munter in der Gegend herumgefunkt wird...

Weiterhin geht es mir um die Absicherung der WiFi Stecker: Die Dinger spannen ja zwei Netze auf: zum einen stecken sie als Client im Heimnetz. Hier erhalten sie die Steuerdaten von der App (bzw. vom FEHM), und kommunizieren mit der Cloud.

Sicher? Einmal angelernt doch eigentlich nicht mehr, da ist doch irgendwas in der Firmware gelockt.
Achja aber nebenbei, weil's noch keiner geschrieben hat, aber wer verschiedene Dosen haben sollte sieht das im Web-Frontend sofort: Die Firmware _sind_ unterschiedlich. Aber funktionell offenkundig gleich.

Jedenfalls, einmal gekoppelt kann man meines Wissens nach praktisch nichts mehr über das Web-Frontend herumspielen. Oder irre ich mich da?