Die URL für Ubuntu 20.04.2 in Schritt 2 lautet:
http://at.archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/
Die URL für Ubuntu 20.04.2 in Schritt 2 lautet:
http://at.archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/
Advent, Advent,
ein Lichtlein brennt.
Erst eins, dann zwei,
dann drei, dann vier,
dann steht das Christkind vor der Tür.
Wir, die wir alljährlich am christlichen Bedeutungsgehalt des Advents vorbeigelotst werden …
Wir, die wir alljährlich dem Konsumzwang unterworfen werden und letztlich dem Bedürfnis nach der Schnäppchenjagd unterliegen …
… werden sicherlich auch trotz geschlossener Geschäfte heuer ab dem 01. Dezember 2020 00:00:01 Uhr wieder nach Online-Adventkalendern -man beachte die in Österreich gebräuchliche Schreibweise ohne „s“ in der Wortmitte – aller Art suchen. Ich möchte die Suche etwas abkürzen.
Ich fasse im Überblick einmal zusammen, was es heuer so gibt – alle Angaben ohne Gewähr:
Wenn Ihr weitere Tips habt, bitte postet sie als Kommentar. Die Liste wird ergänzt.
Wer ärgert sich nicht, wenn der geliebte Internetbrowser plötzlich ein völlig anderes Verhalten, als das, das man erwartet, an den Tag legt?
Beim Einstellen einer IP-Cam etwa, wenn man http://192.168.1.254 eingibt, weil die Kamera eben nur http kann, er es aber besser weiß und https everywhere versucht. Oder beim Testen eines frisch aufgesetzten haproxy. Die Liste, wo das lästig wird, kann man beliebig fortsetzen.
Aber es gibt Mittel und Wege dagegen:
Chrome:
Etwa beschreibt Howtogeek.com das Vorgehen, wie man Chrome das abgewöhnt.
Kurzfassung. Man rufe chrome://flags/#omnibox-context-menu-show-full-urls auf, aktiviere diese Einstellung und surfe eine Seite an. Der Browser hat das https everywhere immer noch aktiviert. Ich klicke mit der rechten Maustaste auf die URL und wähle im Kontextmenü „Immer vollständige URLs anzeigen“. Voilà http wird nicht mehr automatisch auf https umgeschrieben, und ich sehe die komplette URL wieder. Ich habe das bei mir unter Chromium 85.0.4183.102 getestet.
Firefox:
https-everywhere abschalten: about:config aufrufen. Nach browser.fixup.fallback-to-https suchen. Den Wert auf false setzen.
Vollständige URL in der Adressleiste anzeigen: browser.
Advent, Advent,
ein Lichtlein brennt.
Erst eins, dann zwei,
dann drei, dann vier,
dann steht das Christkind vor der Tür.
Wir, die wir alljährlich dem am christlichen Bedeutungsgehalt des Advents vorbeigelotst werden …
Wir, die wir alljährlich dem Konsumzwang unterworfen werden und letztlich dem Bedürfnis nach der Schnäppchenjagd unterliegen …
… werden sicherlich auch heuer ab dem 01. Dezember 2019 00:00:01 Uhr wieder nach Online-Adventkalendern -man beachte die in Österreich gebräuchliche Schreibweise ohne „s“ in der Wortmitte – aller Art suchen. Ich möchte die Suche etwas abkürzen.
Ich fasse im Überblick einmal zusammen, was es heuer so gibt – alle Angaben ohne Gewähr:
Wenn Ihr weitere Tips habt, bitte postet sie als Kommentar. Die Liste wird ergänzt.
Netz | Betreiber | max. Stückzahl SIM | Kosten brutto (netto) pro Monat 1./2./3. .. Zusatz-SIM | einmalige Zusatzentgelte: Aktivierung [A] | Bedingungen, Einschränkungen (funktioniert nicht), Besonderheiten, Quellenangabe |
---|---|---|---|---|---|
A1 | A1 | 3 | € 6,90/€ 4,90 | € 19,90 [A] | Vertragstarife, keine Datentarife Zusatz-SIM bei A1 |
Drei | Drei | 5 | € 5/€ 2 | € 15 [A] | Telefonievertrag SmartSIM bei Drei |
Drei | Drei | 5 | € 5 (4,17)/€ 2 (1,67) | € 15 (12,50) [A] | keine Wertkarte, keine Internettarife Business SmartSIM bei Drei |
Drei | HELPmobile | 5 | € 2 | Alle Tarife außer „HELP daten“ nicht zur Verfügung: - Umleitungen / Rufweiterleitungen - Mobilbox - diverse Ansagen – bspw. bei Nichterreichbarkeit Facebook-Ankündigung Help mobile | |
Drei | Spusu (Mass Response) | 5 | € 2 | - | Nicht für Spusu Daten und nicht für Spusu Wertkarte Facebook-Ankündigung Spusu - Umleitungen / Rufweiterleitungen - Mobilbox - diverse Ansagen – bspw. bei Nichterreichbarkeit |
Magenta | Magenta | 3 | € 5 (6)/€ 2,5 (3) | € 20 (16,67) [A] | Business Mobile Gold & Business Mobile Platin: pro Zusatz-SIM je € 20 (16,67) Business MultiSIM bei Magenta |
Erstentwurf – Review ausständig; Fehler möglich; Änderungen vorbehalten.
In diesem Artikel beschreibe ich stark vereinfacht und gekürzt ein paar Grundlagen des Domain Name Systems, die für Domaininhaber, die den Registrar wechseln möchten, von Relevanz sind. Immer wieder liest man in Support-Foren von verzweifelten Nutzern, denen offenbar nicht klar ist, dass ein Domain-Umzug nicht in Echtzeit abläuft, sondern, dass ein Domaintransfer ein paar Vorbereitungen und etwas Nachbearbeitung erfordert, damit die Ausfallzeiten möglichst gering ausfallen.
Wenn man sich vorher informiert, schont das die Nerven aller Beteiligten – vor allem aber die eigenen.
Für Laien erklärt, ist das DNS am ehesten mit einem Telefonbuch für eine Region vergleichbar. Es übersetzt Namenseinträge (Domainnamen und Hostnamen) in Nummern (Internetprotokolladressen – kurz IP-Adressen). Die einfachste Art eines solchen Datensatzes ist ein sogenannter „A-Eintrag“ für das Internetprotokoll in der Version 4 (IPv4), dem heutzutage noch gängigen Protokoll, oder einem „AAAA-Eintrag“ für das Nachfolgeprotokoll IPv6.
Solche Einträge sehen in etwa so aus – im Beispiel sind die öffentlich abrufbaren Google-Nameserver:
dns.google.com. IN A 8.8.8.8
dns.google.com. IN AAAA 2001:4860:4860::8888
Dieses „Telefonbuch“ ist hierarchisch aufgebaut, d.h. es gibt einen Haupteintrag, unter dem dann weitere Einträge oder Verweise zu finden sind.
Ganz oben steht die Top Level Domain („TLD“). Ein prominentes Beispiel für eine TLD ist „.com“. Für eine TLD zuständig ist eine Vergabestelle (Registry). Sie regelt, wer unter welchen Voraussetzungen einen Namen unterhalb der TLD registrieren darf. Wer eine Domain registriert, wird zum Domaininhaber (Registrant). Die Registry bedient sich meist mehrerer Vertragspartner (Registrare), um diese Domains zu verkaufen – sprich: Namensrechte auf Zeit zu lizenzieren. Die Registrare sind die primären Vertragspartner der Registrants und vermitteln gegenüber der Registry – sie verrechnen dem Registrant auch die anfallenden Gebühren und rechnen sie mit der Registry ab.
Die Registry betreibt sogenannte Root-Nameserver, die in aller Regel nur einen Verweis vom registrierten Namen vorhalten, der auf untergeordnete Nameserver (DNS-Server) zeigt. Haben diese DNS-Server einen Hostnamen, der innerhalb der Domain, um die es geht, liegen -es geht zum Beispiel um die Domain example.com, und der DNS-Server heißt ns1.example.com- ist zusätzlich ein sogenannter „Glue-Record“ vonnöten. Dabei handelt es sich schlicht um einen „A“ oder „AAAA“ -Eintrag, den allerdings der Registrar bei den Nameservern der Registry hinterlegen muss, damit er funktioniert.
Zusätzlich können die Rootserver auch noch kryptographische Schlüssel und Signaturen ausliefern, anhand derer man gefälschten Domaininformationen vorbeugen kann. Das gegenwärtig vorherrschende System dafür heißt DNSSEC.
Die Verweise vom Root-Nameserver zu den Servern des DNS-Providers (in der der Regel sind das zugleich die des Registrars) heissen „NS-Einträge“.
Im Falle dieses Blogs ist der Registrar der deutsche Hoster „netcup“ und die Einträge sehen so aus:
grundsoli.de. 120 IN NS root-dns.netcup.net.
grundsoli.de. 120 IN NS second-dns.netcup.net.
grundsoli.de. 120 IN NS third-dns.netcup.net.
Wir sehen also, dass für den Namen „grundsoli“ innerhalb der TLD „.de“ drei verschiedene Server zuständig („autoritativ“) sind.
Jeder dieser drei Server hält die sogenannte „Zone“ vor. Die Zone kann im einfachsten Fall eine Textdatei sein, oder die in ihr enthaltenen Informationen liegen in einer Datenbank.
Eine Zone setzt sich aus mehreren Resource Records („RR“) zusammen. Zu diesen RRs gehören auch die zuvor genannten NS, A und AAAA-Einträge.
Resource Records setzen sich zusammen wie folgt:
Am Beginn der Zone steht stets ein Eintrag vom Typ SOA. Kehren wir zum Beispiel mit example.com zurück:
@ 3600 IN SOA dns1.example.com. hostmaster.example.com. (
2019090900 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
600 ; nc-ttl
);
Wir haben also die Variable für den Domainnamen „@“, die Gültigkeitsdauer des SOA-Eintrag in Caches „3600“, die Klasse Internet „IN“, die Art des Eintrags „SOA“ den primären Nameserver, das ist jener autoritative Nameserver, von dem aus die Zone vervielfältigt wird „dns1.example.com“ und eine E-Mailadresse in besonderer Schreibweise „hostmaster.example.com“ für hostmaster@example.com. Die Punkte am Ende von dns1.example.com. und hostmaster.example.com. sind extrem wichtig, da sie das Ende des Werts markieren. Fehlt der Punkt am Ende wird der Domainname an den Wert erneut angehängt. Aus „dns1.example.com“ würde dann „dns1.example.com.example.com“ – ein von Anfängern häufig gemachter Fehler. Die in Klammern folgenden Zahlenwerte schlüsseln sich wie folgt auf:
1: Die RIPE-Empfehlungen gelten stets für „für kleine und stabile Zonen“.
Der Wert für Retry muss kleiner sein, als der für Refresh. Der Wert für expire darf nicht kleiner sein als die Summe von Refresh und Retry.
Und damit haben wir die technischen Grundlagen für beeinflussbare Verzögerungen beim Domaintransfer im Grunde vollständig besprochen.
Die nicht beeinflussbaren Faktoren liegen bei der Registry, die etwa Widerspruchsfristen für einen Transfer definieren kann. Sie ist es auch, die festlegt, zu welchen Tageszeiten die Root-Nameserver eine neue Information, die von einem ihrer Registrare eingemeldet worden ist – wir reden da von neuen Nameserver-Einträgen – verarbeitet wird.
Um also einen Transfer so durchzuführen, dass er möglichst schnell über die Bühne geht, sollte man Tage oder Wochen vor dem Transfer die Werte für TTL, Refresh und NC-TTL verringern, wodurch in aller Regel auch der Wert für Retry verringert werden wird müssen. Dadurch setzt man sich vorübergehend zwar einem erhöhten Risiko aus, dass die Zone im Fehlerfall des Primärservers auch auf den Sekundärservern schneller mit ausfällt, umgekehrt müssen aber auch DNS-Resolver Dritter, auf die wir im Normalfall keinen Einfluss nehmen können, sofern sie standardkonform arbeiten, die vorgehaltenen Informationen schneller verwerfen.
Wenn man sich nun noch informiert, wann die Registry die Daten neu laden lässt, kann man den Umzug auch dahingehend zeitlich koordinieren.
Laden beispielsweise etwa die Root-Nameserver laut Registry um 13 und um 16 Uhr die Daten neu, und der Registrar aktualisiert alle 15 Minuten, so kann man nach 13 Uhr die Änderungen machen. Die anderen Kunden des Registrars hätten die neuen Informationen so – sofern sie nicht in einem Cache liegen, um 13.15 Uhr, weltweit würde der Verweis auf die neuen Server erst um 16 Uhr aktiv. Um also Gleichzeitigkeit zu erwirken, wären die Änderungen nach 15.45 Uhr, aber vor 16.00 in Auftrag zu geben. Caching Server würden die alte Information aber zumindest noch für die in TTL definierte Zeit ausliefern, wenn sie die Standards einhalten – sonst länger.
Da sich heutzutage aber auch sogenannte Public-DNS-Resolver-Dienste großer Beliebtheit erfreuen – gemeint sind damit Google DNS, Cloudflare, OpenDNS und dergleichen, und diese oft eine Möglichkeit bieten, die Cache-Information über ein Webinterface neu zu laden, also den „Cache“zu „flushen“, kann man auch hier mit globaler Wirkung für alle Nutzer dieses Dienstes Einfluss auf die Erneuerung der Information nehmen. In der Linksammlung stehen einige Dienste gelistet.
Artikel in Arbeit – öffentliche Vorabversion; Fehler sind sicherlich noch enthalten.
Ein Freund hat zu Weihnachten eine TP-Link HS110 „Smart-Steckdose“ bekommen und ist davon begeistert. Ich habe vor Jahren bereits eine HS100 ausprobiert, aber meine Begeisterung für diese ganze Gerätegruppe unterschiedlicher Hersteller ist mittlerweile etwas abgeklungen. Die Geräte sind durchaus praktisch sind, sofern man etwas Vorsicht walten lässt, und man weiß, was das Gerät tut – ein Erfahrungsbericht.
Als ich mich für das Thema Smart Home zu interessieren begonnen habe, waren WLAN-Steckdosen gerade das Nonplusultra. In diversen Webshops habe ich danach gesucht und hatte für das kleinere Budget am Ende die Wahl zwischen Dosen mit und ohne „Energieverbrauchs“messung. In die engere Auswahl kamen TP-Link mit den Modellen HS100 und HS110 und Edimax mit SP-1101W und SP-2101W.
Ich habe mich dann, wie bereits erwähnt, für die HS100 von TP-Link entschieden. Dieses Modell wird mittels der App „Kasa“ angesteuert, die relativ viel App-Speicher benötigte. Für mein damaliges Smartphone, das unter permanentem Speichermangel litt, war diese Lösung auf Dauer nichts.
Zum Glück gibt es OpenSource-Lösungen wie FHEM und das FHEM-Forum, an dem eine Menge kundige Leute mitarbeiten. Relativ schnell war ein Skript gefunden, das ein anderer Forenposter dort veröffentlicht hat. Im Zuge des Threads ergab sich, dass viele Geräte der Marke „Medion“, „TP-Link“, „Maginon“ und „Silvercrest“ im Grunde einer mit einer recht ähnlichen Sequenz angesteuert werden. Ich werde diese Erkenntnisse zusammenfassen und später näher erläutern.
Aus Kostengründen bin ich dann, als eine Erweiterung anstand, zunächst auf ein Set aus WLAN-Steckdose und Funksteckdosen gestoßen. Der Artikel mit der Bezeichnung Medion MD 16173 besteht einerseits aus einer „intelligenten“ Dose und andererseits drei Funksteckdosen mit einer Fernbedienung, wie wir sie gemeinhin als „Baumarkt”-Funksteckdosen kennen. Angesteuert werden die Dosen über die App „icomen“ respektive „icomen x2“.
Ich habe später auf Amazon äußerlich baugleiche Modelle sowohl der Wlan-Steckdose („Aplic“, „CSL“) als auch der Funksteckdosen („hama“) gefunden. Zusätzlich gibt es von hama und CSL kompatible Außensteckdosen.
Die Funksteckdosen sind als Zwischenstecker ausgeführt. Sie lassen sich mit den Fernbedienungen der jeweils anderen Scheinhersteller schalten.
Über die zuvor genannten Apps icomen und icomen x2 können sowohl die WLAN-Steckdosen geschaltet werden, wozu auch ein Zeitschalt und Zufallszeit-Schaltprogramm wie bei der TP-Link HS100/HS110 gehört, als auch die Funksteckdosen, die zuvor an die jeweilige Steckdose als Gateway angelernt werden kann. Man kann sie also fortan beinahe wie über die Fernbediendung ansteuern. Eine Steckdose reagiert dabei auf zumindest bis zu drei verschiedene angelernte Codes. Der Nachteil dieser Funksteckdosen ist, dass man im Gegensatz zur Haupteinheit den Schaltzustand nicht überprüfen kann.
In den Steckdosen ist ein Modul „Hi-flying HF-LPB100“ verbaut. Die Steckdose verfügt über ein Webinterface mit dessen Hilfe sie im Grunde vollständig konfiguriert werden könnte. Im Regelfall wird man die Dose über die App einrichten. Dazu drückt muss man das Smartphone ins Ziel-WLAN-Netz einbuchen, worauf man den Ein-/Ausschalter der Dose drückt, bis seine LED schnell rot blinkt. Nun fügt dann das Gerät in der App hinzu. In der Folge muss man das WLAN über die App einrichten, während man sich in unmittelbarer Nähe des Gerätes befindet. Wenn die Dose über DHCP eine IP-Adresse und ein Gateway erhält, klappt das Pairing. Stellt man die Internetverbindung für unbekannte Geräte aber ab, schlägt auch das Pairing fehl. Wir haben es also an sich mit einem Cloud-Service zu tun.
Möchte man auf die App verzichten, gibt es einen Trick: Die Steckdose ist im Werkszustand und im Pairing-Mode darauf ausgelegt, als Client der ESSID „LSD“ zu fungieren. Konfiguriert man einen offenen Access Point/WLAN-Router mit dieser Kennung, erhält die Steckdose eine IP-Adresse aus dessen Netz und kann über das Web-Interface des HF-LBP100 konfiguriert werden.
Die Funktionsweise kann je nach Hersteller abweichend sein. Mit einem WLAN-Sniffer kann man allerdings die unverschlüsselten Daten, die die Dose anfordert, sichbar machen.
Konfiguriert man das WLAN nun manuell, kann man die Dose über ihre IP mittels UDP-Befehlssequenzen ansprechen.
Das FHEM-Forum hat alle Informationen bereits zusammengetragen. Ein PHP-Skript des dortigen Nutzers „SebiM“ mit kleinen Modifikationen zum Anschalten von Funksteckdosen kann zur Ansteuerung dienen – hier ist sein rfswitch.php:
#!/usr/bin/php
<?php
// 2016 Sebi, public domain
// Insert your WiFi plug data here // Daten der eigenen WiFi-Funksteckdose hier eintragen
$ip = $argv[2];
$mac = getMacFromArp($ip);
if ($argc==4) {
$code = $argv[3]; // Company code + device code + auth code
} else {
$code=’C1117150′;
}
// Comment out the following line for WiFi plug switching instead of RF slave plug switching
// Folgende Zeile zum Schalten der WiFi-Dose selbst anstatt einer RF-Slave-Dose auskommentieren
if ($argc==5){
$rfslave = $argv[4];
}
function getMacFromArp($IP) {
$REACHABLE=shell_exec(‚ping -W1 -c1 ‚.$IP);
$MAC=shell_exec(‚echo -n $( egrep „‚.$IP.'“ /proc/net/arp | egrep -oe \'([0-9a-f]{2}:*){6}\‘ | sed \’s/\://g\‘ | tr [:lower:] [:upper:])
‚);
return „$MAC“;
}
function encodePacket($packet) {
$td = mcrypt_module_open(MCRYPT_RIJNDAEL_128, “, MCRYPT_MODE_CBC, “);
$key = ‚0123456789abcdef‘;
mcrypt_generic_init($td, $key, $key);
$result = mcrypt_generic($td, $packet);
mcrypt_generic_deinit($td);
mcrypt_module_close($td);
return $result;
}
$msg = hex2bin(„0140{$mac}10“);
if (isset($rfslave)) {
if ($argv[1] == ‚on‘) {
$value = ’60‘;
} else if ($argv[1] == ‚off‘) {
$value = ’70‘;
} else {
exit(2);
}
$msg .= encodePacket(hex2bin(„00ffff${code}08${rfslave}${value}04040404“));
} else {
if ($argv[1] == ‚on‘) {
$value = ‚ff‘;
} else if ($argv[1] == ‚off‘) {
$value = ’00‘;
} else {
exit(2);
}
$msg .= encodePacket(hex2bin(„00ffff${code}010000${value}ff04040404“));
}
echo ‚UDP packet: ‚ . bin2hex($msg) . „\n“;
$sock = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
for ($i = 0; $i < 4; $i++) {
socket_sendto($sock, $msg, strlen($msg), 0, $ip, 8530);
usleep(50 * 1000); // 50 ms
}
socket_close($sock);
Das Skript ermittelt zunächst anhand der übergebenen Parameter die MAC-Adresse der Steckdose aus deren zuwiesener IP-Adresse. Anschließend wird eine Hexdezimalzahl der Länge 8 Byte (64 Bit) definiert, die sich von Gerät zu Gerät unterscheiden kann. Sie besteht aus dem Herstellercode, dem Gerätecode und einem Authcode. Innerhalb einer Geräteserie ist dieser Code jedenfalls ident und manche Hersteller verwenden offenbar denselben Code, der daher im Script als Fallback eingetragen ist: C1117150 (CX-Herstellercode, YY-Gerätecode; ZZZZ-Authcode. Der FHEM-User „enterpriseII“ hat dies gepostet: https://forum.fhem.de/index.php/topic,38112.msg501942.html#msg501942
Ein weiterer, optionaler Parameter enthält einen sechs Byte langen Code, der eine Funksteckdose, die zuvor angelernt worden ist, anspricht.
Das Skript generiert nun ein Paket, das anschließend über einen UDP-Socket als Unicast versendet wird. Seine Fracht enthält einen Präfix (0140), die Ziel-MAC-Adresse, einen Postfix (10) enthält, vermehrt um eine mit AES128 verschlüsselte Binärcodesequenz mit dem trivialen Schlüssel 0123456789abcdef
, die aus dem Präfix „00ffff, dem Gerätecode (C111750), der Zeichenfolge 08, dem angelernten Schaltcode der Funksteckdose, dem Schaltwert (70 für aus, 60 für ein und dem Postfix 4 mal 04 besteht. In Kenntnis dieser Details kann man es gut nachprogrammieren. Im simpelsten Fall kann ein Bash-Skript, das netcat (nc) aufruft diese Funktion erfüllen, solange man den 128 Bit Rijandel Algorithmus zur Verfügung hat.
Hat man die Funksteckdose über die App angelernt, kann man den Code mit einem weiteren Skript von SebiM vom Cloudserver abrufen. Man erhält dann einen JSON-Datensatz mit allen Dosen und deren zugehörigen Funksteckdosen.
php rfswitch.php {on|off} [IPADRESSE DER DOSE] [HERSTELLER-CODE, GERÄTECODE, AUTHCODE - Default :C1117150] [6 BYTE HEXADEZIMALZAHLEN]
php rfswitch.php {on|off} [IPADRESSE DER DOSE] [HERSTELLER-CODE, GERÄTECODE, AUTHCODE - Default :C1117150] [6 BYTE HEXADEZIMALZAHLEN]
Man sollte sich dessen bewusst sein, dass die Schaltsequenzen, die gegen den String „0123456789abcdef“ verschlüsselt sind, trotz AES128/Rijandel ausgelesen werden können. Damit kann ein Angreifer, der Zugriff auf die Broadcastdomain erlangt grundsätzlich Euer SmartHome beeinflussen.
Seit der Entdeckung der WPA2-KRACK ist das kein abwegiges Szenario mehr, denn die WLAN-Schaltdosen verfügen über das HF-LBP100-Modul zusätzlich über einen Repeater-Mode. Zwar dürfte dieser simple Repeater-Modus kein WDS beherrschen und somit höchstwahrscheinlich nicht anfällig für Key-Replay-Attacken sein, dennoch ist die Firmware V1.0.04b nicht auf dem letzten Stand. Wer nun die glorreiche Idee haben sollte, die Firmware von der Herstellerseite des Moduls zu verwenden, sei gewarnt: Wer das HF-LPB100 updated, ruiniert die Funksteckdosen-Funktionalität auf seinem Gerät unwiderbringlich. Der jeweilige Hersteller hat die Firmware an die Erfordernisse seiner Cloud und seiner Relaisanordnung angepasst.
Wer die Cloud-App verwendet, sollte sich darüber im klaren sein, dass sämtliche Schaltzeiten nebst Username und Passwort auf einem chinesischen Cloud-Server landen. Freilich fehlt jeglicher Hinweis darauf, der im Sinne der DSGVO wäre. Auch das manuelle Schalten würde, damit die Schaltzustände mit der App synchron bleiben, einen derartigen Home-Call auslösen, wenn die WLAN-Steckdose über das Internet verbunden ist.
Wer das nicht möchte, dem sei angeraten, dies über die Firewall zu unterbinden. Freilich ist damit die App nutzlos. Alternativen zu ihr, samt fremden Cloudserver bestehen in selbstgehosteten Lösungen wie FHEM.
Die beiden zuvor genannten Schaltbefehle lassen sich freilich auch ohne FHEM via Cron-Job anwenden. Der Linux-Server dienst somit als Zeitschaltuhr, die sich automatisch der Zeitumstellung anpasst.
Praktisch wird es, wenn dies etwa nach einem Backup die USB-Platte vom Netz trennt oder der SAT-IP-Server über Nacht abgeschaltet werden soll. Anwendungsmöglichkeiten gibt es viele.
… ist geboten, da es sich um Geräte handelt, die mit Netzstrom arbeiten. Achtet jedenfalls auf die maximal verträgliche Spitzen- und Dauerlast des jeweiligen Gerätes und beachtet die Sicherheitshinweise in der Bedienungsanleitung.
Noch ein Hinweis: wenn Du mehrere dieser WLAN-RF-Gateways verwendest, ist der RF-Code, wenn Du ihn über ein Skript steuerst, auf allen Dosen in Reichweite, die denselben Code angelernt haben, nutzbar. In der App ist eine Slave-Steckdose stets an einen einzigen Master gebunden. Du kannst die Befehle, die „fremde“ Slaves betreffen, aber auch in einer Schleife an all Deine Dosen senden. Das wird dann praktisch sein, wenn Du eine Funksteckdose nicht immer an derselben Wandsteckdose benützt, oder, wenn Du eine Dose im Empfangsbereich zweier Gateways hättest (1.+3. Stock Gateway, 2. Stock RF-Slave). Bei allen Dosen, die ich bisher getestet habe, besteht durchaus ein Reichweitenproblem mit der in ihnen verbauten RF-Feder-Antenne für 433 MHz. Anders als bei WLAN mit MiMo und mehreren Streams machen sich hier Abdeckungsprobleme innerhalb einer Wohnung stark bemerkbar.
Kennt man die Problem und Möglichkeiten, steht dem Spaß mit der Heimautomatisierung nicht mehr viel im Wege.
Ein herzliches Dankeschön an die Mitwirkenden im FHEM-Forum, ohne das dieser Beitrag nicht möglich gewesen wäre! Der nächste Artikel wird sich vielleicht FHEM widmen.