Beiträge von Inhumierer

    Keine Erfahrung, aber so rein elektrotechnisch fehlt mir die Idee, wie so ein Magnet den Shelly dazu bringen soll, seine Einstellungen zu vergessen. Die Einstellungen landen ja ncht auf einer ec Karte auf dem Magnetstreifen o.ä., sondern in einem EEPROM. Darauf und auf den Rest des Shellys hat ein stationärer Magnet abgesehen vom Hall-Effekt keinen Einfluss, und der dürfte deutlich zu klein sein um Auswirkungen zu zeigen.

    WLAN 2,4GHz, Wellenlänge ca. 125mm, da hat ein Magnet von 1 oder 2 cm auch keine nennenswerte Abschirmung.

    Wenn Du den Magneten jetzt im Betrieb schnell genug drehst, könnte das anders aussehen... ;)

    ja es geht noch. die ständig gleiche leier. das sind erwachsene leute hier. wer dabei geht und eine geballert bekommt, hat selbst schuld. bei kaum einen thema wird so ein riesen drama drum gemacht wie bei der elektrik, obwohl es in anderen bereichen kein stück weniger gefährlich ist.

    Danke, aber lass gut sein ^^ Ich bin lang genug dabei, um so Dinge einfach zu ignorieren. Du musst mal in 3D-Drucker-Gruppen reinschauen, da ist es noch erheblich krasser. Macht einer nen Katzenstreu-Trichter, kommen mit Sicherheit unter irgend nem Stein Leute und fragen, ob das auch lebensmittelecht und vom TÜV abgesegnet ist... 8o

    Multimeter, Bereich Wechselspannung 500V (üblich, sonst höher) wählen, ein Kabel an die Phase, andere an den vermuteten Nullleiter. Wenn dann die Anzeige rund 210-240 beträgt, Sicherung raus, Kabel auftrennen, Multimeter Bereich auf kleinen Widerstand oder Durchgang, und vom aufgetrennten Kabel zur Dose messen, einer der beiden Kontakte sollte einen sehr kleinen Widerstand zeigen.

    Oder einen Duspol nehmen.
    Im Zweifelsfall aber einfach den Elektriker Deines Vertrauens befragen, der hat sicher einen Duspol, und der braucht wahrscheinlich nicht lange um die Frage zu klären.

    Der ESP8266 kann gleichzeiig Client & AP sein, dann könnte ein Shelly theoretisch einen Repeater spielen. Eingeschränkte CPU Power und Speicher machen den Betrieb aber wohl praktisch nicht möglich. Und er wird dabei auf einen Kanal beschränkt sein, was den Datendurchsatz noch weiter ausbremst. Und selbst wenn das soweit funktioniert, dann hast Du einen Repeater, und noch lange kein Mesh.

    Eigentlich ein bisschen schade, dass die Shellys kein Mesh können. Wie bei Zigbee und Z-Wave wäre das schon eine praktische Sache.

    Da können die Shellys wenig für, das geht prinzipiell nicht so einfach. Die Mesh-Orga müssen schon die APs bzw. der Controller machen, das können die Clients nicht. Liegt am Design.

    Wenn das Zigbee Mesh halbgar umgesetzt wird bringt es übrigens auch nix - ein Aqara Sensor, der sich an einen Hub andockt, ist offline, sobald der Hub weg ist. Er bleibt es auch, bis der Hub wieder da ist.

    Du kannst auch ohne weiteres 1000 oder mehr Clients in einem WLAN betreiben, auch bei 2,4 GHz. Voraussetzungen wären räumlich einigermaßen geschickt verteilte Access Points, die möglichst wenig überlappende Kanäle nutzen. Aktuelle WLAN-Verwaltungs-Software sollte das automatisch regeln, das kriegt sogar eine Fritzbox im Mesh Betrieb mit den Fritz Repeatern hin. Generell wäre es von Vorteil, die APs per LAN anzubinden. Wenn Du ein ganzes Einfamilienhaus versorgst, wirst Du da wahscheinlich schon mehrere haben, wenn es nicht gerade ein Holzhaus ist. 1000 Clients an einem AP wird allerdings schrwierig, schon rein räumlich ;)

    Und dann brauchst Du natürlich ein entsprechend großes IP Netz, bzw. je nach Bedarf auch mehrere. Bei einem einzelnen Haus sollte aber ein Netz reichen.
    Aus Erfahrung: Wenn bei Fritzboxen 7490 und 7590 die DHCP Lease Liste eine gewisse Grenze (1000? 2000?) überschreitet, hören sie einfach auf, IP-Adressen zu vergeben. Wenn es vierstellig wird, einfach einen DHCP Server ins Netz holen, z.B: Raspi, und die FB nur als DSL-Router nutzen.

    Und kannst Du mal bitte Real Time definieren? TCP/IP einschl. WLAN ist so ohne weiteres gar nicht dazu in der Lage, das gibt das Protokoll nicht her.

    Generell schließen sich WLAN und hohe Bandbreite aus, daher schließe ich alle Clients, die eine hohe Bandbreite brauchen, immer per Kupfer an.

    Einspruch, Euer Ehren... ;)
    Der WPA2 PSK muss tatsächlich im Klartext gespeichert werden. Das geht hier nicht anders. So wie ich das verstanden habe, muss der WPA Client den Key im Klartext kennen. Hash oder md5 o.ä. reichen hier nicht. Man könnte sicher den Key etwas verstecken, XOR, PGP oder so was, ist aber auch nur Makulatur. Wirklich sinnvoll wäre an dieser Stelle eine Art Public/Private Key Verfahren, wie bei ssh oder PGP. Allerdings wäre dann für jeden authentifizierten Client ein Eintrag auf dem Server nötig, nicth wirklich praktikabel, wenn mal Besuch reinschneit.
    Und da kommen wir wieder zu den 2 WLANs, die dann auch Sinn machen: Ein Gäste-WLAN mit PSK oder ganz offen, mit Einschränkungen. Und ein richtiges WLAN, in dem jeder Client per Key hinterlegt ist.

    Alles gut Jungs, wir widersprechen uns ja gar nicht grundlegend ;)

    Edit: Das ist nur eine Redewendung, Mädels sind an dieser Stelle explizit eingeschlossen...

    Über den Sinn eines zweiten WLANs kann man sich unterhalten, sicher. Generell sollte man Maßnahmen, die wenig oder keine zusätzliche Sicherheit, aber dafür erheblichen Verwaltungs- oder Wartungsaufwand mit sich bringen, überdenken. Wer das so aus dem Ärmel schütteln kann, soll es machen. Jemand der erst nachlesen muss, was eine Netzmaske und eine Route in einer Tabelle machen, sollte es wahrscheinlich besser lassen.

    ESPs sind (wie alle CPUs) genau so sicher wie das darauf laufende System. Die SSID wird sowieso im Klartext rausgefunkt, und der PSK muss auf dem Device im Klartext gespeichert sein, das geht gar nicht anders. Deshalb darf ich grundsätzlich den PSK nicht rausrücken, auch nicht im Flash eines defekten ESPs im Mülleimer. Als umweltbewusster Elktroniker würde ich den eh in den Elektroschrott bringen ;)

    WPA2 Enterprise können die wenigsten - Tasmota nicht, die original Shelly FW nicht, und Fritzboxen auch nicht. Unser Dienstleister will mir demnächst mal ein System zeigen, das PPSK - personal PSK - macht, damit können auch Clients ins Netz, die nur PSK können, aber jeder Client bekommt seinen eigenen Key. Auch charmant, weil kompatibel, aber auch wohl nix für den Heimgebrauch.

    Zumindest kabelgebunden sind 2 gleiche IP Adressen kein Problem, solange das Netz nicht entsprechend gesichert ist. Sonst wird es tatsächlich schwieriger. Oder man nimmt einfach in Kauf, daß das Gerät, dessen Adresse man "klaut", nicht mehr erreichbar ist. Wenn man nur kurzfristig stört, und dann möglichst zu Zeiten, in denen niemand da ist, fällt das kaum auf. Hauptsächlich bestehende TCP Verbindungen, die per Timeout gekappt werden, werden bemerkt, falls sie nicht automatisch neu gestartet werden. Ich schau auch morgens nicht ins Monitoring um zu lesen wer denn letzte Nacht ein Bäuerchen gemacht hat.
    Natürlich wächst der Aufwand, in ein Netz rein zu kommen, mit dem Aufwand, den der Betreiber macht, es zu schützen. Dann stellt sich in der Tat die Frage, ob sich der Aufwand lohnt, bei Dir zu hasue ein bisschen mit den Lichtschaltern zu spielen... ;)

    Die Unterscheidung in bekannte & unbekannte Geräte passiert aufgrund der MAC Adresse. Das bringt praktisch nix, weder im LAN noch im WLAN. Zumindest wenn derjenige der da rein will sich ein bisschen auskennt und nicht nur fertige ergoogelte Scripte startet. Das LAN allerdings hört am Kabel bzw. der Netzwerkdose auf, das WLAN nicht, das stimmt.

    Ich meine weiter: Wenn man eine bestimme Technik, z.B: WLAN mit WPA2 PSK, benutzt, dann sollte man:

    Entweder auf die verwendete Technik vertrauen, und damit gut sein lassen, sich aber regelmäßig informieren,

    Oder der Technik misstrauen, sie nur für den Transport nutzen und die Sicherheit auf anderem Wege gewährleisten, z.B: TLS.

    BTW: Es ist gar nicht so selten, daß Du bei größeren Installationen im Außenbereich direkt passende Cat Dosen findest, netterweise oft gleich mit PoE und/oder eine 230V Steckdose in der Nähe.

    Zu den vorgeschlagenen VLAN-Lösungen: Das ist eine Methode, um mehrere (logische) Netzwerke über ein gemeinsames Medium zu übertragen. Das an sich hat überhaupt nichts mit Sicherheit zu tun. Es ist lediglich eine zusätzliche Transportschicht, die die beteiligten Gegenstellen benutzen können oder auch nicht. Bei VLAN Tags findet keinerlei Prüfung o.ä. statt. Ein Gerät, daß euch jemand ins Netzwerk schmuggelt, kann VLANs benutzen, wie es möchte. Bedeutet, wenn sich jemand da rein wurstelt und Zugriff auf einen Trunk hat, bekommt er bei passender Konfiguration gleich Zugriff auf mehrere Netzwerke gleichzeitig. Damit hättet Ihr ggf. die mühevoll gewonnene "Sicherheit" durch Trennung der VLANs gleich selber ausgehebelt.

    Ein eigenes WLAN für Tasmota/Shelly halte ich für übertrieben. M.M.n. erhöht sich damit die Sicherheit nicht. Falls es jemand schafft, das WLAN für die Devices zu knacken, was sollte ihn davon abhalten, das andere WLAN auch zu hacken?

    Und wenn er es denn ins Netz geschafft hat, was macht er dann? Euer Netz für fieses Filesharing missbrauchen? Ne, heute nicht mehr. Zugriff auf Devices ist da interessanter.

    Dazu muss er zudem eine entsprechende Lücke in der IoT FW kennen und ausnutzen, dann bringt das 2. WLAN aber auch nichts.

    Eine Art Grundsicherung durch Benutzernamen/Passwörter steht aber schon auf der ToDo-Liste. ;)

    Hallo liebe Gemeinde!

    Zu meiner "Installation": FB 7490, 3 x Fritz Repeater 1750, allerdings per LAN angebunden - evtl. deshalb noch keinerlei WLAN Disconnects. Momentan 6 Shellies 1.3er & 2.5er, alle auf Tasmota umgekrempelt. Zudem noch 9 weitere Tasmota-Devices.

    Dazu kommt ein Zigbee-Netz an einem USB ConBee, momentan rund 10 Nodes, Tendenz steigend. Die Sicherheit und die Organisation bei Zigbee haben mir gefallen, leider funktioniert das Mesh nicht so gut wie die Werbeversprechen glauben machen. Aber mit den Mankos kann ich leben, und der Stromverbrauch ist für kleine Sensoren auf Batteriebetrieb einfach unschlagbar. Es war Anfangs ein CC2531 mit zigbeemqtt auf einem Raspi, aber diese Lösung hatte gleich mehrere Schwachstellen. Java bzw. JS ist m.M.n. für so eine Aufgabe völlig überdimensioniert bzw. der falsche Ansatz. Der Raspi ist damit zeitweilig schon gut ausgelastet, obwohl die Aufgabe an sich Kiki ist. Und dann noch so einen riesen Klopper Node Red laufen lassen für kleinere Übersetzungsaufgaben, die bei effizienter Programmierung von einer Armbanduhr gemacht werden könnten.

    Und weiter: Ich bin alter Elektroniker, da hab ich noch ein paar Smarthomatic-Devices - das wird wohl kaum einer kennen, ist eine komplette Eigenbau-Lösung auf ATMega-Basis auf 886 MHz Funk. Tolle Reichweite, super Verschlüsselung, Batterielebensdauer nahe an unendlich. Meine AA Zellen vergammeln eher, als das sie leer gehen. Aber leider eben auch ziemlicher Aufwand. Platine machen (lassen), bestücken, Gehäuse drucken, da werden Aqara Zigbee Devices für 10 oder 12 € schon interessant...

    Software ist Domoticz. Ein Dimmer mit 1.9er Shelly FW ist noch nicht aufgenommen, da weis ich noch nicht genau, worauf es hinausläuft.

    Edit: Wenn ich irgend was mit einer Cloud mache, dann ist das meine eigene Cloud. Alles andere - egal ob Aqara, Shelly, Google - ist nicht diskutabel.

    Guten Abend liebe Gemeinde, ich habe nun einige Shellies 1 & 2 mit Tasmonta 9.2.0 geflasht und in mein Domoticz integriert, das fluppt supi. Heute wollte ich mal meinen kleinen gekachelten Raum mit einem Dimmer versorgen, damit mir nachts das Licht nicht wie rostige Nägel in die Augen sticht :D Aber: Temperatur fluppt, sonst kommt nichts. Kein Schalter, kein Dimmer. Im MQTT sehe ich die Meldungen über Schalter offen/geschlossen, aber bei Domoticz kommt nichts an.

    Benutzt hier noch wer Domoticz?