วีดีโอ

Vielen Dank für deinen Kommentar und die spannenden Gedanken zur Netzdienlichkeit dynamischer Stromtarife! Du hast völlig recht, dass die beschriebenen Automationen dazu beitragen können, das Stromnetz zu entlasten, indem große Verbraucher dann eingeschaltet werden, wenn viel Strom aus erneuerbaren Energien verfügbar ist. Das reduziert die Belastung in Zeiten geringer Verfügbarkeit und könnte langfristig tatsächlich zu einer Senkung der Netzentgelte führen, da weniger teure Redispatch-Maßnahmen erforderlich wären. Allerdings sollte man diesen Effekt auch differenziert betrachten. Einerseits setzt die Netzdienlichkeit voraus, dass ausreichend viele Haushalte solche Tarife nutzen und ihre Verbrauchszeiten flexibel anpassen. Andererseits sind dafür technische Voraussetzungen wie Smart Meter und automatisierte Steuerungen notwendig, die noch nicht flächendeckend vorhanden sind. Auch die Vorhersehbarkeit von günstigen Zeitfenstern ist nicht immer garantiert, da die Einspeisung erneuerbarer Energien wetterabhängig ist und Schwankungen unterliegt. Es gibt zudem alternative Konzepte wie lokale Energiespeicher, die überschüssige Energie zwischenspeichern und so ebenfalls zur Netzstabilität beitragen könnten. Dennoch sind dynamische Tarife ein wichtiger Schritt in Richtung eines flexibleren Strommarkts und fördern die sinnvolle Nutzung erneuerbarer Energien. Die Energiewende wird vermutlich eine Kombination aus verschiedenen Ansätzen erfordern, und es bleibt spannend zu sehen, wie sich diese Ansätze in den kommenden Jahren weiterentwickeln.

darum geht es hier aber gar nicht.

Vielen Dank für deinen Kommentar! 😊 In diesem Video geht es zwar nicht um den Fernzugriff, aber das ist definitiv ein spannendes Thema, das ich sicher in einem eigenen Video behandeln werde. VPNs sind zwar eine ziemlich sichere Lösung, aber in Sachen Usability oft etwas umständlich. Es gibt viele andere interessante und dennoch sichere Ansätze - sei gespannt auf kommende Videos, in denen ich das genauer erkläre!

@ Hm! Ich bin durchaus der Meinung, daß eine Cloud-Lösung auch dem Fernzugriff dient.

Danke für deinen Kommentar! 😊 Verständlich, dass du auf Fernzugriff verzichtest, um das Risiko zu minimieren. Tatsächlich geht es im Video aber um die verschiedenen Angriffsszenarien im Smart Home und wie man sich dagegen absichert. Der Fernzugriff ist ein spannendes Thema, zu dem es sicher noch ein eigenes Video geben wird - denn wie du sagst, wollen viele ihre Geräte von überall steuern können. Wichtig ist dabei, die Balance zwischen Sicherheit und Komfort zu finden.

Top Setup! 👍 Genau das ist ein wichtiger Punkt: Nicht nur Home Assistant absichern, sondern das gesamte Netzwerk sicher gestalten. 😊 In diesem Video geht es um typische Angriffsszenarien im Smart Home und entsprechende Schutzmaßnahmen - die Netzwerksegmentierung, wie du sie beschreibst, ist dabei ein super Beispiel! Ein eigenes VLAN für IoT-Geräte und die Nutzung von WireGuard sind tolle Ansätze, um Risiken zu minimieren. Vielleicht mache ich dazu auch mal ein Video, um zu zeigen, wie man so ein sicheres Netzwerk aufbaut.

@@smarthomeabersicher Danke, ich wünsche mir das viel mehr Leute auf Sicherheit im eigenen Netzwerk aufmerksam werden und vor allem durchsetzten - das war der Grund für diesen etwas provokanteten Kommentar .... nicht erst wenn es zu spät ist. Wobei es mich auch interessieren würde, wie du das ganze machst, ich mache das über eine OPNsense und Omada bzw. TP-Link Switches/APs - nicht jeder hat das Geld dafür(Wobei bei mir alles in der Bucht erworben wurde und das recht günstig war)

Hey Michael, danke für Deinen Kommentar. Ich gebe zu, das Thema kommt etwas zu kurz, ich habe es zwar im Diagramm dargestellt (direkte Kommunikation im Cloud-Szenario), gebe aber zu, zu wenig darüber erzählt zu haben. Muss ich in einem Folgevideo wohl nochmal ausführlicher aufzeigen!

Danke, Matthias, für deinen Kommentar! Eine solche Architektur ist sicherlich begrüßenswert, da sie Verschlüsselung und standardisierte Protokolle verwendet. Trotzdem bietet sie keineswegs absolute Sicherheit, da dies stark davon abhängt, welche Funktionalitäten über MQTT realisiert werden. Ich habe Lösungen gesehen, bei denen ein komplettes Software-Update (Firmware-Binary) auf dem MQTT-Broker abgelegt wird - ohne jegliche kryptografische Signatur. Die Geräte laden sich diese Updates herunter und sind im Handumdrehen unter der Kontrolle eines Angreifers, sollte es dieser Schaffen, Zugriff auf den Broker beim Hersteller zu erhalten. Aber auch eine Home-Assistant-Integration könnte hier zum Angriffsziel werden, wenn sie Daten vom MQTT-Broker abruft, die ein Angreifer dort manipuliert hat. Fehlt eine Überprüfung der Eingabewerte, könnte dies zu einem Pufferüberlauf führen. Solche Programmierfehler könnten einem Angreifer letztendlich vollen Zugriff auf die Home-Assistant-Installation und sogar auf das gesamte Heimnetzwerk ermöglichen. Leider kann ein Verbraucher einem Gerät nicht ansehen, wie sicher die Cloud-Kommunikation tatsächlich realisiert wurde. Das macht es umso wichtiger, sich kritisch mit solchen Lösungen auseinanderzusetzen. Natürlich möchte ich keine Panik verbreiten - davon habe ich nichts, da ich kein Produkt verkaufe, das eine Lösung verspricht ;-) Mein Ziel ist es, zu sensibilisieren, und dazu gehört auch ein zugegebenermaßen provokanter Videotitel. Ich hoffe jedoch, im Video ausreichend differenzieren zu können. Leider ist es in kurzer Zeit und ohne tief ins Detail zu gehen nicht möglich, alles umfassend und differenziert darzustellen, weshalb es an manchen Stellen zu Verallgemeinerungen kommen kann.

@ Danke für die ausführliche Antwort! Ja, dass IoT Geräte im großen Stil gekapert werden ist ein reales Szenario. Aber eher, um damit Botnetze für DDoS oder ähnliche Angriffe zu bauen. Dass jemand darüber an die anderen (erstmal unbekannten) Geräte im Heimnetzwerk möchte, ist ja erstmal viel Aufwand für nichts. Und ja, in einem Update für eine hacs Integration alle Zugangsdaten von Cloud-Konten an eine zentrale Stelle zu sammeln (um genau soetwas zu erreichen) wäre theoretisch auch möglich. Etwas ähnliches ist ja schon mit Browser Extensions passiert, welche dann verkauft wurden und in einem Update mit sonstwas für Code ausführen. Nur ist dieses Bild vom Angreifer, welcher es auf das eigene Heimnetz abgesehen hat, recht weit hergeholt. Daher der Kommentar. Würde mich über konkrete Videos zu Angriffsszenarien freuen. 👍

@@haus_automation ja genau darum geht es mir auch an sich und ich versteh das ganze noch viel zu wenig. Ich möchte eben alles lokal haben und keinen Zugriff von außen. Weder VPN noch sonst irgendwas... deswegen war ich verwundert, dass ich hacs direkt aus dem HA runterladen musste/konnte. Ich hab vorher gedacht, dass ich mir Sachen am PC runterladen und dann auf meine Hardware schieben muss.

@ Das müsste man ja dann bei jeder neuen Version wieder machen. Und Updates gibt es wirklich oft. Also damit gewinnt man keine Sicherheit, sondern würde es nur komplizierter machen

@@haus_automation daran habe ich gar nicht gedacht, dass wäre ja unglaublich viel Arbeit wenn man einige Geräte hat.

Am Ende führt man Code aus, dessen Inhalt man nicht kennt. Man kann also nicht pauschal sagen, dass etwas sicher oder unsicher ist. Theoretisch müsste man bei jedem Update ein Code-Review machen und alles genau anschauen. Der Code ist ja öffentlich. Aber wer hat dazu schon die Expertise und Zeit. Also muss man am Ende einfach vertrauen.

Ein lokal genutzter MQTT-Broker, auf den von außen nicht zugegriffen werden kann, stellt grundsätzlich kein großes Sicherheitsrisiko dar. Gut ist, wenn auch im internen Netzwerk keine unbefugten Geräte auf den Broker zugreifen können. Wenn du ganz sicher gehen willst, kannst du trotzdem eine Authentifizierung einrichten und MQTT über TLS absichern, auch im lokalen Netz. Das erhöht die Sicherheit, falls mal jemand in dein WLAN eindringt. Aber für den Anfang bist du mit einem rein lokalen Setup auf einem guten Weg!

Eine sehr gute Frage Manfred! Grundsätzlich gilt: Es gibt keine 100%ige Sicherheit im Bereich IT-Sicherheit. Eine seriöse Bewertung ist daher schwierig, da wir nur die öffentlich bekannten Aspekte beurteilen können (z.B. bestimmte Design-Aspekte). Die Nabu Casa Cloud legt jedoch großen Wert auf verschlüsselte Verbindungen und minimiert die Datenspeicherung. Zudem bietet sie Mechanismen wie sichere Authentifizierung, um den Schutz zu erhöhen. Trotzdem bleibt ein gewisses Restrisiko, wie bei jedem IT-System. Der kostenpflichtige Nabu Casa-Dienst bietet wesentliche Vorteile gegenüber kostenlosen Cloud-APIs von Geräteherstellern: Er sorgt durch regelmäßige Einnahmen für langfristige Stabilität und reduziert das Risiko von Ausfällen oder einer Einstellung des Dienstes. Dank der finanziellen Mittel kann Nabu Casa in hochverfügbare Serverstrukturen, Sicherheitsupdates und Weiterentwicklungen investieren. Zudem gewährleistet der Dienst Datenschutz, Unabhängigkeit von Geräteherstellern und bietet verlässlichen Support, wodurch Home Assistant-Nutzer eine sichere und nachhaltige Lösung für den Remote-Zugriff erhalten. Der Nabu Casa-Dienst ist die bessere Option im Vergleich zu einer selbst gebastelten Lösung mit Port-Forwarding. Selbst eingerichtetes Port-Forwarding birgt erhebliche Sicherheitsrisiken, da es potenziellen Angreifern einen direkten Zugang zu deinem Heimnetzwerk ermöglicht, insbesondere wenn die Konfiguration oder Absicherung nicht optimal ist. Nabu Casa hingegen bietet eine sichere, verschlüsselte Verbindung, ohne dass Ports geöffnet werden müssen, was die Angriffsfläche deutlich reduziert. Zudem entfallen der Wartungsaufwand und die Komplexität, die mit einer eigenen Lösung verbunden sind, während man von einer professionell betriebenen, sicheren und benutzerfreundlichen Remote-Zugriffsmöglichkeit profitiert. Disclaimer: das ist keine Werbung für diesen Dienst. Ich selbst nutze ihn nicht, sondern stütze meine Beurteilung ausschliesslich auf die frei verfügbaren Informationen.

Hey Joachim, vielen Dank für Dein Feedback, das ermutigt natürlich stark, das Thema wieder aufzugreifen. Aktuell lote ich noch Bedarf und Interesse aus, daher sind die ersten zwei Videos zu dem Thema erstmal sehr oberflächlich und sollen vor allem sensibilisieren. Gern nehme ich Deine Anregung auf um die Umsetzung einzelner Aspekte konkreter anzugehen und Hilfestellungen zu geben, die leicht umzusetzen sind.

Nein. Weil dann deine Gäste auf alles zugreifen können. Was man machen kann, ist ein VLAN für alle IoT-Geräte.

Im einfachsten Fall sollte Home Assistant nicht im Gastnetzwerk sein, sondern im Hauptnetzwerk. Das liegt daran, dass Home Assistant sozusagen das „Gehirn“ deines Smarthomes ist und Zugriff auf alle deine Geräte braucht, um richtig zu funktionieren. Im Gastnetzwerk wären viele Verbindungen blockiert, was Automatisierungen und Steuerungen erschweren könnte. Gastnetzwerke sind eher für unsichere oder cloudabhängige IoT-Geräte gedacht, damit diese vom restlichen Netzwerk isoliert bleiben. Home Assistant gehört dagegen in den vertrauenswürdigen Teil deines Netzwerks, da es die zentrale Steuerung für deine Geräte übernimmt. 😊

@@smarthomeabersicher Das hatte ich vermutet. Bei meiner Tapo Steckdose habe ich es jetzt so gelöst, dass sie nicht mehr im Gastnetz hängt, dafür aber nicht ins Internet darf. Wenn aber Sicherheitslücken durch Integrationen ins Hauptnetz kommen ist das auch nicht gut.

@@michaelschlichenmaier730 Ja, das Problem beim VLAn ist aber, dass Dein Home Assistant dann auch im VLAN hängen muss. Man müsste das dann richtig professionell einrichten, aber das ist für den privaten Gebrauch sicher dann überdimensioniert.

Das ist ein wichtiger Punkt! Lieferkettenangriffe sind tatsächlich eine der größten Bedrohungen, vor allem bei Open-Source-Projekten (FOSS), wo Ressourcen oft begrenzt sind. Home Assistant (HA) setzt stark auf Open-Source-Komponenten, was die Community besonders wachsam macht. Glücklicherweise wird der Code von HA regelmäßig überprüft, und es gibt Sicherheitsupdates, die bekannte Schwachstellen schnell schließen sollen. Dein Hinweis auf verwaiste Abhängigkeiten ist wichtig. Eine Möglichkeit, sich zu schützen, ist die regelmäßige Kontrolle der installierten Add-ons und Integrationen. Außerdem kann man HA so konfigurieren, dass nur offiziell unterstützte Add-ons verwendet werden, was das Risiko senkt. Danke für den Denkanstoß - das Thema Lieferkettenangriffe verdient definitiv mehr Aufmerksamkeit! 😊

Vielen Dank für deinen Kommentar und deine Rückmeldung aus der Praxis! 😊 Du hast vollkommen recht, dass eine Trennung der Geräte in verschiedene Netzwerke manchmal zu Problemen führen kann, wenn Home Assistant nicht auf die Geräte zugreifen kann. Cloud-Geräte gehören tatsächlich ins Gastnetzwerk. Der Grund ist, dass solche Geräte direkt mit dem Internet kommunizieren und das Gastnetzwerk dein Heimnetz vor möglichen Risiken durch diese Geräte schützt. Home Assistant kann solche Cloud-Geräte trotzdem steuern, weil die Kommunikation nicht direkt, sondern über die Cloud erfolgt. Lokale Geräte hingegen, die keine Internetverbindung benötigen, wie Zigbee-Sensoren, ESPHome-Geräte oder andere Smarthome-Geräte ohne Cloud-Abhängigkeit, sollten im gleichen Netzwerk wie Home Assistant bleiben. Nur so kann Home Assistant direkt mit ihnen kommunizieren. Wenn ein Gerät wie deine Tapo-Steckdose aber ausschließlich über das Heimnetz erreichbar ist, hast du genau richtig gehandelt, indem du sie ins Heimnetz gehängt und den Internetzugriff gesperrt hast. So minimierst du die Risiken und Home Assistant kann das Gerät trotzdem steuern. In Kürze wird es ein ausführliches Video zu diesem Thema geben, in dem ich genau auf solche Fragen und typische Szenarien eingehe. Ich erkläre dort, wie du Cloud- und lokale Geräte sinnvoll trennen kannst, ohne dass die Steuerung über Home Assistant eingeschränkt wird. Danke nochmal für dein Feedback - es zeigt, wie wichtig diese Diskussion ist. Wenn du noch weitere Fragen hast, lass es mich wissen!

Wenn deine Geräte in einem separaten Netz nicht funktionieren ist dein Netzwerk Setup fehlerhaft.

@@Esralabu Das ist mit einer Standardausrüstung wie in einem normalen Haushalt üblich (Fritzbox) nicht anders möglich, es sei denn ich stecke den Home Assistant auch ins Gastnetz und stelle das Gastnetz so ein, dass die Geräte untereinander kommunizieren können.

@@robinhood20233 Wie ich Dir im Kommentar oben erklärt habe, sollte Deine Home Assistant Installation nicht im Gastnetz sein, sondern nur Cloud-basierte Geräte die nicht vertrauenswürdig sind. Dann gibt es auch keine Probleme :-) Sind noch konkrete Fragen offen geblieben? Dann melde Dich gern damit.

Vielen Dank für deinen Kommentar! 😊 Du sprichst ein wichtiges Thema an, das oft missverstanden wird: die Frage nach Länge vs. Komplexität bei Passwörtern. Lass mich das anhand des Begriffs Entropie erklären, der bei der Passwortsicherheit eine zentrale Rolle spielt. Entropie beschreibt, wie viele mögliche Kombinationen ein Passwort haben kann. Sie hängt von zwei Faktoren ab: 1. Zeichenvielfalt: Wie viele verschiedene Zeichen du verwendest (z. B. Zahlen, Buchstaben, Sonderzeichen). 2. Passwortlänge: Wie viele Zeichen dein Passwort insgesamt hat. Die Formel zur Berechnung der Entropie lautet: Entropie = (Anzahl der möglichen Zeichen)^Länge des Passworts. Wenn du nur Zahlen verwendest, gibt es 10 mögliche Zeichen (0-9). Ein 12-stelliges Passwort hätte: 10¹² = 1.000.000.000.000 Kombinationen. Wenn du Groß- und Kleinbuchstaben hinzufügst, gibt es 52 Zeichen. Ein 6-stelliges Passwort hätte aber "nur": 52⁶ = 19.770.609.664 Kombinationen. Auch mit einer geringen Zeichenvielfalt kann ein langes Passwort also extrem sicher sein, weil die Anzahl der möglichen Kombinationen exponentiell wächst. Ein Passwort wie „123456789012“ (12 Zeichen, nur Zahlen) ist sicherer als „P@ssw0rd“ (8 Zeichen, komplex). Die Länge des Passworts hat den größten Einfluss auf die Anzahl der Kombinationen, die ein Angreifer ausprobieren muss. Komplexität spielt nur eine Rolle, wenn das Passwort sehr kurz ist, z. B. „P@ss123“. In der Praxis ist es für die meisten Nutzer einfacher und sicherer, ein langes, leicht merkbares Passwort zu verwenden - z. B. eine Passphrase wie „diesistmeinpferd123“. Ein Passwort nur aus Zahlen kann trotzdem sicher sein, wenn es lang genug ist - z. B. 16 Zeichen oder mehr. Natürlich ist eine Kombination aus Länge und Vielfalt ideal, aber die Länge ist der entscheidende Faktor für die Sicherheit.

Ok ich denke auch nicht dass der Autor uns sagen wollte ein 20stelliges Passwort nur aus Nullen bestehend zu nutzen. Er wollte wohl eher sagen, dass du mehrere Wörter oder eine Phrase nehmen kannst, was bspw. 20 Zeichen lang ist, als ein Passwort mit 10 Zeichen, was komplett zufallsregeneriert und den kompletten ASCII-Zeichensatz enthält. Bei einer Sache muss ich dem Autor aber widersprechen: Mittlerweile synct Google die Authenticator-App in die Cloud. Es gibt weitere OpenSource-Alternativen, die mit dem Google Auth kompatibel sind, incl. das erwähnte keepass (teilweiße mit zusätzlichen AddOns)

Du hast völlig recht mit dem Google Authenticator. Danke für diesen Hinweis. Der Google Authenticator war ursprünglich eine rein offline-basierte App. Das bedeutet, dass die generierten Einmalpasswörter (TOTP, Time-Based One-Time Passwords) nur auf dem Gerät gespeichert wurden und keine Verbindung zur Cloud oder zu externen Servern benötigten. Seit 2023 bietet Google jedoch eine optionale Cloud-Synchronisierung an. Damit können Benutzer ihre gespeicherten Codes in ihrem Google-Konto sichern und bei Bedarf auf andere Geräte übertragen. Die Cloud-Synchronisierung ist nicht standardmäßig aktiviert; Nutzer müssen sie aktiv einschalten, wenn sie ihre Codes in der Cloud speichern möchten. Unterschiede: • Offline-Modus: Die Codes bleiben lokal auf dem Gerät. Höhere Sicherheit, da keine Daten in der Cloud gespeichert werden. • Cloud-Modus: Bequem, um Codes zwischen Geräten zu synchronisieren, aber potenziell anfälliger, wenn das Google-Konto kompromittiert wird. Wenn du Wert auf maximale Sicherheit legst, solltest du die Cloud-Synchronisierung deaktiviert lassen.

Vielen Dank für dein tolles Feedback! 😊 Es freut mich, dass du das Projekt ausprobieren möchtest - es macht wirklich Spaß und ist super nützlich. Zur Stromverlegung: Das Kabel des Windmessers ist relativ lang, sodass ich es problemlos bis zur nächsten Steckdose legen konnte. Dort habe ich es direkt mit dem Mikrocontroller verbunden, den ich zur Sicherheit in eine einfache Aufputz-Abzweigdose aus dem Baumarkt gepackt habe. Das schützt ihn gut vor Staub und Feuchtigkeit. Glücklicherweise habe ich auf dem Dachboden Steckdosen, was die Stromversorgung erleichtert hat. Für die Gehäuselösung mit einem 3D-Drucker ist das natürlich eine super Idee! Damit kannst du das Ganze individuell an deine Gegebenheiten anpassen. Die Konfigurationsdatei findest du übrigens in meinem Blog: joachim-wilke.de/blog/2024/11/25/windmessgerate-mit-esphome-in-home-assistant-integrieren/ Falls du noch weitere Fragen hast oder Updates zu deinem Projekt teilen möchtest, schreib gerne nochmal. Ich bin gespannt, wie es bei dir klappt! 😊 Viele Grüße!

@@smarthomeabersicher Cool! Danke dafür. Werde mich mal in den nächsten Wochen (spätestens im Frühjahr) damit beschäftigen. Will meine Aussen-Markiese Smart machen und dann kommt das wie gelegen. Auf das Angebot mit den Fragen komme ich gerne zurück. Danke

Dank je wel! 😊 Groeten terug naar Nederland 🇳🇱 - leuk om te horen dat je de video goed vindt! 👍✨

Servus! Danke für deinen ausführlichen Kommentar - klasse, dass du dich so intensiv mit NGINX, DuckDNS und Home Assistant beschäftigst! 😊 Bevor ich auf deine Fragen eingehe, möchte ich kurz einige Begriffe klarstellen, damit wir die Themen richtig einordnen können: Gerät verschlüsseln: Das ist technisch nicht korrekt. Was du vermutlich meinst, ist, die Kommunikation zwischen einem Gerät und einem Server (oder einem Nutzer) zu verschlüsseln - z. B. über HTTPS oder andere Protokolle wie MQTT mit SSL. Die Geräte selbst werden nicht „verschlüsselt“. IP verschlüsseln: Auch das geht so nicht. Eine IP-Adresse ist eine Art digitale Adresse für Geräte im Netzwerk. Verschlüsselt wird der Datenverkehr, der über diese Adresse läuft - also z. B. die Inhalte, die zwischen deinem Gerät und NGINX oder Home Assistant übertragen werden. Damit ich besser verstehe, worauf du hinauswillst, habe ich ein paar Rückfragen: 1. Wo läuft dein NGINX-Server? Auf dem gleichen Gerät wie Home Assistant (z. B. einem Raspberry Pi)? Oder auf einem separaten Server in deinem Netzwerk? Oder sogar extern (z. B. bei einem Hosting-Anbieter)? 2. Was möchtest du genau absichern? Geht es dir darum, den Zugriff auf Geräte wie WLED, Tasmota oder ESPHome von außen sicher zu machen? Oder möchtest du, dass die Kommunikation zwischen diesen Geräten und Home Assistant intern verschlüsselt ist? 3. Wie nutzt du die Geräte? Greifst du auf Geräte wie WLED oder IP-Kameras nur lokal im Heimnetz zu? Oder möchtest du sie auch von unterwegs über DuckDNS erreichen? Mit diesen Infos kann ich dir besser helfen, die passende Lösung zu finden. Es klingt, als hättest du schon viel erreicht - jetzt geht es darum, die nächsten Schritte richtig einzuordnen. Schreib einfach nochmal, dann klären wir das!

Vielen Dank für deinen Kommentar und die Nachfrage! Der von mir verwendete Windmesser benötigt tatsächlich keine eigene Stromversorgung, da er mechanisch arbeitet und Impulse erzeugt, die direkt vom ESP8266 ausgelesen werden. Lass mich das kurz erklären: Der Sensor enthält einen Reed-Kontakt, der auf mechanischer Bewegung basiert: 1. Der Wind bewegt die Schalen des Sensors, wodurch sie sich um eine Achse drehen. 2. Bei jeder Umdrehung passiert ein kleiner Magnet den Reed-Kontakt. Dieser mechanische Schalter wird durch den Magneten kurz geschlossen und erzeugt so einen elektrischen Impuls. 3. Diese Impulse werden über den Signalanschluss (Impuls) an den ESP8266 weitergeleitet. Der Sensor selbst benötigt keine zusätzliche Stromversorgung, da er durch die mechanische Bewegung und die einfache Magnet-Schalter-Kombination funktioniert. Der ESP8266 zählt die Impulse und berechnet daraus die Windgeschwindigkeit. Die einzige Stromversorgung, die benötigt wird, ist für den ESP8266, der wie üblich mit 5V betrieben wird. Der Sensor arbeitet vollständig passiv und gibt nur die erzeugten Impulse an den Microcontroller weiter. Ich hoffe, diese Erklärung hilft dir weiter! Falls du noch Fragen hast, lass es mich gerne wissen. 😊

Vielen Dank für deinen Kommentar! Es ist auf jeden Fall richtig, dass man Updates mit Bedacht einspielen sollte, und ich verstehe, woher deine Skepsis kommt. Allerdings möchte ich ein paar Dinge ergänzen, warum es in der Praxis meistens sinnvoll ist, Updates - auch scheinbare Feature-Updates - einzuspielen. Viele Hersteller veröffentlichen keine detaillierten Informationen darüber, welche Sicherheitslücken ein Update behebt. Das hat verschiedene Gründe, unter anderem um Angreifern keine Hinweise auf mögliche Schwachstellen zu geben. Was auf den ersten Blick wie ein reines Feature-Update aussieht, kann also durchaus auch Sicherheitsverbesserungen oder Patches enthalten, die nicht explizit erwähnt werden. Das macht es schwer, zwischen „unwichtigen“ und „wichtigen“ Updates zu unterscheiden - was dafür spricht, Updates grundsätzlich regelmäßig einzuspielen. Wann sollte man dennoch ein Update auslassen? Updates nicht einzuspielen, sollte wirklich die Ausnahme sein, z. B. wenn: 1. Ein bekanntes Problem existiert: In seltenen Fällen berichten Nutzer direkt nach einem Update von Bugs, die kritische Funktionen beeinträchtigen. In solchen Situationen kann es sinnvoll sein, das Update zu verschieben, bis ein Fix veröffentlicht wurde. 2. Das System sehr spezifisch angepasst ist: Wenn du viele benutzerdefinierte Komponenten oder Integrationen verwendest, die eventuell inkompatibel mit einer neuen Version sind, solltest du Updates sorgfältig planen. Auch hier helfen Community-Feedback und vorherige Tests. Trotzdem gilt: In den meisten Fällen ist es besser, Updates zeitnah einzuspielen. Sicherheitslücken, die nicht gepatcht werden, sind ein leichtes Ziel für Angreifer - besonders in Smarthome-Systemen, die immer online und mit vielen Geräten verbunden sind. Ein System mit veralteter Software kann schnell zum Schwachpunkt werden, auch wenn es sonst gut abgesichert ist. Ich finde es wichtig, den Punkt anzusprechen, dass Updates überlegt eingespielt werden sollten. Aber in der Praxis überwiegen die Vorteile regelmäßiger Updates - gerade weil Hersteller oft nicht kommunizieren, welche Sicherheitslücken geschlossen werden.

Sehr gerne Frank, danke für das Lob!

Hi! Erstmal toll, dass du mit Home Assistant und einem kleinen Smarthome starten möchtest - willkommen in der Welt der Smarthome-Enthusiasten! 😊 Es ist ganz normal, am Anfang viele Fragen zu haben. Ich helfe dir gern mit ein paar Infos weiter, speziell zur Sicherheit von Zigbee-Geräten und deinen Bedenken bezüglich Internet-Hubs wie denen von Aqara. 1. Sicherheit von Zigbee-Geräten: Zigbee-Geräte sind grundsätzlich recht sicher, insbesondere wenn sie lokal betrieben werden. Der Zigbee-Standard nutzt AES-128-Verschlüsselung, die sicherstellt, dass nur autorisierte Geräte miteinander kommunizieren können. Das bedeutet: - Lokalität: Wenn Zigbee-Geräte nicht mit dem Internet verbunden sind, können sie nur innerhalb der Reichweite deines Zigbee-Hubs angesprochen werden. Du brauchst dir also keine Sorgen machen, dass jemand von außen auf die Geräte zugreifen kann. - Kopplung: Normalerweise kannst du Zigbee-Geräte nur koppeln, wenn du in der Nähe des Hubs bist und den Pairing-Modus aktivierst. Das erhöht die Sicherheit zusätzlich. 2. Problem mit Aqara-Hubs und der Cloud: Viele Zigbee-Geräte wie die von Aqara setzen auf ihren eigenen Hub, der oft Cloud-abhängig ist. Das bedeutet, dass deine Daten ins Internet gehen und du die Kontrolle darüber teilweise abgibst. Das ist verständlicherweise ein Risiko, das viele vermeiden wollen. Hier kommt Zigbee2MQTT ins Spiel: Was ist Zigbee2MQTT? Es ist eine Open-Source-Lösung, mit der du Zigbee-Geräte über einen USB-Stick direkt mit Home Assistant verbinden kannst. Passende Sticks bekommst Du schon ab 30 Euro, z.B. hier amzn.to/3ZMfSdj (*) Cloudfrei: Deine Geräte kommunizieren lokal über MQTT (einen Messaging-Dienst), und du brauchst keinen Hersteller-Hub mehr. Aqara-Geräte: Viele Aqara-Geräte funktionieren perfekt mit Zigbee2MQTT - du kannst sie lokal nutzen, ohne dass sie auf die Cloud zugreifen müssen. Du findest auf der Webseite von Zigbee2MQTT eine sehr umfassende Liste der unterstützten Geräte, für Aqara Geräte zum Beispiel hier: www.zigbee2mqtt.io/supported-devices/#v=Aqara 3. Warum Zigbee2MQTT eine tolle Option ist: - Volle Kontrolle: Du behältst die komplette Kontrolle über deine Zigbee-Geräte und bist nicht von einem Hersteller-Hub oder Cloud-Diensten abhängig. - Kompatibilität: Zigbee2MQTT unterstützt eine riesige Auswahl an Zigbee-Geräten, darunter viele von Aqara, Philips Hue, IKEA Tradfri und mehr. - Flexibilität: Du kannst die Geräte direkt in Home Assistant einbinden und Automationen erstellen, ohne Umwege über die Cloud. - Sicherheit: Da alles lokal bleibt, minimierst du Sicherheitsrisiken durch Internetkommunikation. 4. Mein Tipp für Deinen Einstieg: Wenn du möglichst sicher und lokal starten möchtest, empfehle ich: - Home Assistant + Zigbee-Stick: Hol dir einen Zigbee-Stick und richte Zigbee2MQTT ein. Die Installation ist dank der vielen Community-Tutorials gut machbar - auch für Anfänger. Passende USB-Sticks findest Du zum Beispiel hier: amzn.to/3ZMfSdj (*) - Aqara-Geräte lokal nutzen: Geräte wie Tür- und Fensterkontakte, Bewegungssensoren oder smarte Taster von Aqara funktionieren perfekt mit Zigbee2MQTT. So brauchst du keinen Aqara-Hub. - Klein anfangen: Teste die Einrichtung mit ein oder zwei Geräten, um ein Gefühl dafür zu bekommen. Sobald du die Basics verstanden hast, kannst du dein Smarthome Schritt für Schritt erweitern. Falls du noch mehr Fragen hast, melde dich gerne! Die Home-Assistant-Community ist super hilfsbereit, und mit Lösungen wie Zigbee2MQTT hast du eine tolle Grundlage für ein sicheres und flexibles Smarthome. Viel Erfolg und vor allem viel Spaß beim Einstieg! 🚀😊

@@smarthomeabersichertolle, ausführliche Antwort auf eine Frage eines Einsteigers, so sollte von YTern immer reagiert werden👍😎‼️

​​@@smarthomeabersicher... AES128 als sicher zu bezeichnen ist so, als würde man ein klapperiges Scheunentor Winddicht nennen. Die Kryptomethode ist knapp 25 Jahre alt und ist seit 20 Jahren ohne größeren Aufwand knackbar.

@@carstuskaktus7638 Vielen Dank für deinen Kommentar und dafür, dass du etwas kritisch ansprichst! Es ist natürlich wichtig, bei Kryptographie-Standards immer auf dem neuesten Stand zu sein und mögliche Schwächen offen zu diskutieren. Deine Beschreibung erinnert mich jedoch eher an DES (Data Encryption Standard), einen älteren Verschlüsselungsalgorithmus, der tatsächlich in den frühen 2000er-Jahren als unsicher eingestuft wurde. DES verwendet nur 56-Bit-Schlüssel, was mit moderner Rechenleistung leicht zu knacken ist. DES wurde damals durch AES abgelöst - und AES-128 gilt bis heute als sicher, wenn es korrekt implementiert wird. Du erwähnst, dass AES-128 seit 20 Jahren „ohne größeren Aufwand knackbar“ sei. Das würde mich wirklich interessieren, da es bislang keinen dokumentierten Angriff gibt, der AES-128 in der Praxis unter realen Bedingungen gebrochen hat. Könntest du genauer beschreiben, auf welche Methode oder Forschung du dich beziehst? AES-128 nutzt 128-Bit-Schlüssel und bietet mit 2¹²⁸ möglichen Kombinationen einen extrem hohen Schutz gegen Brute-Force-Angriffe. Es gibt keinen dokumentierten praktischen Angriff, der diese Sicherheit untergräbt - vorausgesetzt, die Implementierung ist korrekt. Die meisten Schwachstellen entstehen durch fehlerhafte Implementierung (z. B. wiederverwendete Initialisierungsvektoren) oder unsichere Schlüsselspeicherung, nicht durch den Algorithmus selbst. Falls langfristig Quantencomputer einsatzfähig werden, könnte AES-256 für noch mehr Schutz sorgen - aber das betrifft eher Szenarien, die über Jahrzehnte sicher bleiben müssen. Falls es tatsächlich neue Erkenntnisse gibt, die AES-128 unsicher machen, wäre ich sehr daran interessiert, davon zu erfahren! Es wäre spannend zu verstehen, worauf du dich beziehst. Diskussionen wie diese sind unglaublich wichtig, um Missverständnisse zu klären und das Wissen über Kryptographie zu erweitern.

@@smarthomeabersicher ... Mal aus dem Nähkästchen eines Kryptotechnikers: ja, ich meine schon AES. Das Problem ist die Implementierung. 99.9% aller Hersteller nutzen einfach einen festen Schlüssel, welcher bei der Verbindung ausgehandelt wird, was so lange funktioniert, bis es mal jemand drauf anlegt. Hardwaretechnisch ist diese Verschlüsselung allerdings etwas aufwendiger gedacht. Der Ursprungsschlüssel ist eigentlich nur eine Größe von 16-32. Aus ihm wird ein Tagesschlüssel abgeleitet, welcher alle 60sek durch die synchrone Uhrzeit nochmals überschlüsselt wird. Das ist Hardwareseitig allerdings aufwändig, weshalb viele, bzw eigentlich fast alle Hersteller es weg lassen. Als AES 2000 eingeführt wurde benötigten wir, mit damaliger Hardware etwa 100-110 Tage um so einen Schlüssel zu knacken. Wie lange das mit heutiger Hardware und KI-Routinen dauert kann sich jeder selbst ausrechnen... genaue Zahlen werde ich dazu nicht rausrücken...

Danke für das Lob!

Dein Ansatz mit dem ESP8266 und Tasmota ist wirklich interessant und zeigt, wie vielseitig DIY-Lösungen im Smart-Home-Bereich sein können! Besonders die Idee, per HTTP-Aufruf und einer App mit HTML-Buttons die Garage zu steuern, ist kreativ. Trotzdem sehe ich ein paar Punkte, bei denen eine Lösung wie der Shelly gewisse Vorteile bietet, die man nicht unterschätzen sollte: 1. Einfache Stromversorgung: Beim Shelly kannst du direkt die 12V oder 24V nutzen, die viele Garagentorsteuerungen ohnehin bereitstellen. Das macht die Installation einfacher, weil keine zusätzliche Spannungsumwandlung nötig ist. Beim ESP8266 brauchst du dagegen 5V, was je nach Garagentor zu einem zusätzlichen Aufwand führen kann. 2. Sicherheitsfeatures:Der Shelly bietet eine stabile Integration in viele Smart-Home-Systeme (z. B. Home Assistant) und ermöglicht dort eine gesicherte Kommunikation, z. B. über MQTT oder verschlüsselte Verbindungen. Ein einfacher HTTP-Aufruf beim ESP kann unter Umständen ein Sicherheitsrisiko darstellen, wenn er nicht ausreichend abgesichert ist (z. B. durch HTTPS oder VPN). 3. Benutzerfreundlichkeit: Der Shelly lässt sich ohne zusätzliche Apps oder manuelle Konfiguration direkt über die Shelly-App oder einen Smart-Home-Hub steuern. Gerade für weniger technikaffine Nutzer könnte das ein entscheidender Vorteil sein, weil keine zusätzlichen Anpassungen oder Tools nötig sind. 4. Zuverlässigkeit: Shellys sind speziell für solche Aufgaben entwickelt und bieten in der Regel eine hohe Stabilität im Dauerbetrieb. Der ESP8266 ist zwar vielseitig, aber nicht unbedingt für Dauerlast in raueren Umgebungen (z. B. Garagen) ausgelegt, ohne zusätzliche Maßnahmen wie Watchdogs oder Resets. Natürlich hat dein Ansatz mit dem ESP auch Vorteile, besonders wenn man maximale Flexibilität und Kontrolle haben möchte. Aber ich finde, gerade für diejenigen, die eine einfachere und robustere Lösung suchen, kann ein Shelly die bessere Wahl sein. Was denkst du, wie schneiden die beiden Varianten in der Praxis im direkten Vergleich ab? Es wäre spannend, mehr über deine Erfahrungen zu hören!

Vielen Dank für deinen ausführlichen Kommentar und die wichtigen Punkte, die du ansprichst! Es freut mich wirklich, dass du dir die Zeit genommen hast, so tief ins Thema einzutauchen und auch Herausforderungen bei der Umsetzung aufzeigst. Lass mich auf die einzelnen Aspekte eingehen: 1. IT-Sicherheit von Geräten beurteilen Ich stimme dir zu, dass es sowohl für Anfänger als auch für erfahrene Nutzer oft schwierig ist, die Sicherheit von Smarthome-Geräten zu beurteilen. Viele Hersteller machen es einem nicht leicht, da sie nicht transparent über Sicherheitsmaßnahmen oder Updates informieren. Allerdings finde ich es wichtig, hier zu betonen: Es muss nicht immer perfekt sein. Auch wenn man nicht jedes Gerät auf Herz und Nieren prüfen kann, gibt es einfache Maßnahmen, die schon viel bewirken. Zum Beispiel kann man Geräte von bekannten Marken bevorzugen oder darauf achten, dass sie regelmäßig Firmware-Updates erhalten. Das allein ist ein guter Anfang und besser, als gar nicht auf Sicherheit zu achten. 2. Separates Netzwerk und VLANs Du hast völlig recht, dass ein separates Netzwerk technisch anspruchsvoller werden kann, vor allem wenn man über die Grundfunktionen eines Gastnetzwerks hinausgeht. VLANs einzurichten ist für Anfänger oft eine echte Herausforderung, besonders wenn man mehrere Access Points oder Switches nutzt. Aber hier möchte ich betonen: Es geht nicht darum, dass alles sofort perfekt umgesetzt werden muss. Ein Gastnetzwerk in der Fritzbox einzurichten, ist für viele ein machbarer erster Schritt - selbst wenn es nicht die optimale Lösung ist. Es erhöht die Sicherheit im Vergleich dazu, alles in einem einzigen Netzwerk laufen zu lassen. Für fortgeschrittene Nutzer, die komplexere Setups haben, wäre eine vollständige VLAN-Lösung sicher der richtige Weg. Aber für Einsteiger ist es besser, mit kleinen Maßnahmen zu beginnen, als sich von der Komplexität abschrecken zu lassen und gar nichts zu machen. 3. Sonderzeichen im WLAN-Passwort und ESP32 Bluetooth Proxy Das Problem mit den Sonderzeichen in WLAN-Passwörtern beim ESP32 Bluetooth Proxy ist ein wirklich guter Punkt. Es ist natürlich ärgerlich, wenn technische Einschränkungen verhindern, dass man Passwörter mit hoher Komplexität nutzen kann - besonders wenn solche Geräte für ein Smarthome empfohlen werden. Allerdings möchte ich betonen: Ein langes Passwort aus Kleinbuchstaben - beispielsweise eine Passphrase wie „diesistmeinsehrlangespasswort“ - kann genauso sicher sein wie ein komplexes Passwort mit Sonderzeichen, Großbuchstaben und Zahlen. Entscheidend ist, dass ein Angreifer durch die Länge des Passworts so viele Kombinationen durchprobieren müsste, dass es praktisch unmöglich wird, es zu knacken (Stichwort: "Entropie").

Danke dir! 🙃

Dankeschön Joel! 🙂

Das ist korrekt!

@@smarthomeabersicher Gibt es einen Shelly, der das selbst erkennt, oder gibt es da nur die Möglichkeit mit der Erweiterungseinheit und einem Magnetschalter (was z.B. bei einem Schiebe-Einfahrtstor schwierig wird mit dem Magnetchalter zwischen den beweglichen Teilen)

@@0815DST Für die Integration eines Garagentors oder Einfahrtstors in ein Smart-Home-System bietet sich das Shelly Add-on an, das speziell für den Anschluss externer Sensoren entwickelt wurde. Es funktioniert in Kombination mit Geräten wie dem Shelly 1 oder Shelly 1PM und ermöglicht die Verwendung von Magnet- oder Reed-Sensoren, um den Zustand des Tores - also ob es offen oder geschlossen ist - zuverlässig zu erkennen. Diese Sensoren arbeiten mit einem sogenannten potentialfreien Kontakt, was bedeutet, dass sie keinen Strom leiten, sondern lediglich durch ihre Position den Kontakt schließen oder öffnen. Das Add-on wird einfach mit dem Shelly verbunden und ermöglicht so eine präzise Statusüberwachung. Besonders praktisch ist diese Lösung bei Garagentoren, wo der Sensor problemlos an der Schiene oder in der Nähe des Torrahmens montiert werden kann. Allerdings kann die Installation bei Schiebetoren anspruchsvoller sein, da die beweglichen Teile eine exakte Positionierung des Sensors und Magneten erfordern. Mit etwas Kreativität bei der Montage - etwa durch den Einsatz flexibler Halterungen oder stärkerer Magneten - lässt sich dieses Problem jedoch in der Regel gut lösen. Insgesamt ist das Shelly Add-on eine einfache und effektive Möglichkeit, die Funktionalität eines Smart-Home-Systems zu erweitern und den Komfort bei der Torsteuerung zu erhöhen.

@ danke dir für diese Antwort! Ja, mit dem Anbringen der Magneten beim Schiebetor ist das so eine Sache. Aber stärkere Magneten sind sicher eine Möglichkeit

Dankeschön 🙏 es ist ja erst ein Video im Kanal. Ich strenge mich an dass es mehr werden. Dienstag gibt’s das zweite zum Thema Garagentore smart machen.