Beiträge von Schubbie

Und wie kommst du mit der Kleinspannung auf den Shelly? Setzt du dann Relais?

Es wird gelegentlich angesprochen, ob es Sinn macht, dass man die Leitungen der Schalter in die Verteilung zieht. Ich frage die Kunden dann, wie wahrscheinlich es ist, dass der Schalter aus dem Wohnzimmer das Licht im Schlafzimmer schalten soll.

Das was Du beschreibst wäre dann eher Richtung KNX.

Wenn die Kunden es wollen, dann bekommen die es, kommt aber sehr selten vor. Ich verplane dann eher Elektronikdose, so dass man Aktoren nachrüsten kann und schleife ggf. ein 5x1,5mm² von Leuchte zu Leuchte und dann hat man die Möglichkeit diese auf 3 verschiedene Schaltdrähte zu legen. Oftmals kommt dann aber vom Kunden, dass es doch auch Philips HUE o.ä. gibt.

Einfach von Taster zu Taster ein 5-Ader ziehen lassen, dann kann beides gemacht werden (Schalter oder Taster). Du könntest auch ein 7-Ader ziehen lassen, dann könntest du überall Serientaster verbauen und hättest immer eine Wippe für heller und dunkler, was angenehmer zu bedienen ist.

Du musst den Button Type auf momentary stellen.

Aber ihr könntet ja einen Blogeintrag dazu erstellen

SebMai Nein, das mit der Wildcard funktioniert leider nur, wenn man die Synology-Domain verwendet. Es hat mich auch schon geärgert.

Ich habe WireGuard so eingestellt, dass nur die Anfragen an meine privaten Adressen über WireGuard laufen. WireGuard hat auf Android die unangenehme Eigenschaft, dass der Netzwerkverkehr zum Erliegen kommt, wenn der Tunnel als aktiv angezeigt wird, jedoch nicht richtig steht. Das Problem besteht leider seit Anfang an und außer den VPN neu zu starten gibt es meiner Kenntnis nach noch keine Lösung. Ich habe in WireGuard einen öffentlichen DNS mit angegeben, was jedoch nicht Sinn der Sache ist.

Ich denke, dass WireGuard für mich die bessere Lösung bleibt, da es einfach weniger Wartung benötigt und man die Server nicht offen ins Netz stellt, auch wenn es mich eigentlich reizt, dass Home Assistant ohne VPN angesprochen werden kann, da es gelegentlich zu Problemen kommt, dass sich ein Smartphone als An/Abwesend per Geofencing meldet und es häufig dann zu sein scheint, wenn das Netzwerk gerade wechselt und der VPN nicht richtig arbeitet. Die App scheint dann eine ganze Weile nicht mehr zu versuchen den Sensor für den Standort zu aktualisieren.

Ich hoffe, dass es mit einer Überarbeitung meines Automate Flows besser wird.

Nehme ich FritzFon als Beispiel, dann kann ich nur eine Adresse eintragen, sprich ich bräuchte eine interne Hostweiterleitung. Setzt man diese nicht und die Anfrage geht erst ins Internet und kommt dann zurück ins Heimnetz, bringt dieses zumindest eine Ubiquiti Security Gateway nach einiger Zeit zum Absturz.

SebMai das funktioniert jedoch nur mit *. Synology.me

Zitat von SebMai

Es wäre ja immer noch nur eine Freigabe

Eine Portfreigabe, aber mehrere Geräte / Dienste freigegeben, die dann zwingend ein sicheres Kennwort benötigen. Per VPN kommt von außen niemand anderes dran und ich muss das mit den Passwörtern nicht so eng sehen.

Die Subdomains müssen dann auch in den internen Hostweiterleitungen gepflegt werden, damit die Clients diese immer gleich ansprechen können, aber wie verhält es sich dann mit dem SSL-Zertifikat, welches dann doch nicht auf Home Assistant und Co. liegt? Bekommt man bei internem Zugriff dann eine Sicherheitswarnung?

Eine Wildcard beim SSL-Zertifikat war bei eigener Domain glaube ich nicht so einfach möglich, man müsste dann den Dienst von Synology nutzen.

Deswegen steht der SolarLog in Klammern, da per HA und Portal erreichbar, so wie die Wallboxen per Portal erreichbar sind.

Ich synchronisieren jedoch per VPN die Fotos, die Keepass Datenbank, Kalender und Kontakte, Home Assistant, meine Nuki Bridge erreiche ich per VPN und halt jedes einzelne Netzwerkgerät und komme dann bequem per TinyMatic auf meine Raspberrymatic. Ich glaube einfach, dass ein Reverse Proxy für mich zu umfangreich wäre und jede Freigabe stellt ein Sicherheitsrisiko dar.

Ich investiere die Zeit dann wohl besser darin meinen Automate-Flow für WireGuard endlich zu überarbeiten.

@66er ich will meinen Automate-Flow schon seit ca. 4 Monaten überarbeiten - mir fehlt einfach die Zeit

Danke, das zeigt mir, dass ich nicht so falsch gegoogelt habe.

Wer keine Subdomains anlegen kann, der braucht dann Ports, ansonsten kann man mit Subdomains arbeiten, muss sich jedoch um dessen Zertifikate kümmern, um den Vorteil der Verschlüsselung nutzen zu können.

Das mit Homeassistant ist ein Punkt. Wird der VPN nicht aufgebaut, werden auch die Sensoren nicht aktualisiert. Dieses ist per Portfreigabe vermutlich reibungsloser als per VPN, allerdings ist der VPN aktiv, hat jedoch keine Verbindung (was bei WireGuard leider ab und an passiert, besonders bei Netzwechseln), dann kommt auch die Anfrage zur Subdomain nicht durch, da das Internet des Smartphones dann quasi lahmgelegt ist.

Für mich würde das bedeuten, dass ich folgende Sub-Domains anlegen muss und auf permanentes VPN verzichte und dieses nur bei Bedarf aufbaue:

- Dateifreigabe

- Telefonie (FritzFon App)

- Home Assistant

- NodeRed

- (ggf. Wärmepumpe & SolarLog)

- Synology Chat

Grundsätzlich scheinen mir da die Möglichkeiten per VPN wesentlich umfangreicher, sicherer und einfacher zu konfigurieren, zumindest bei meinen Anforderungen.

Wer nur auf Home Assistant zugreifen möchte, der ist damit vermutlich besser bedient.

@66er vielleicht ist es eine Anregung um deinen Blogartikel um "Reverse Proxy über Synology" zu erweitern?

Herausforderungen wären die Subdomains (alternativ mehrere Portfreigaben) und die SSL-Zertifikate für die Subdomains (Let's encrypt auf Synology). Ansonsten sieht das alles recht easy aus.

Moin,

grundsätzlich kann ich mir nicht erklären, warum ein Reverse Proxy sicher sein soll und möchte nach Erfahrungen fragen. Vermutlich ist VPN für mich jedoch die bessere Wahl und ich bleibe bei WireGuard.

Für einen Reverse Proxy richte ich Sub-Domains ein, um meine Geräte von außen erreichen zu können und genau dort fangen meine Bedenken an:

- ich benötige für jedes Gerät eine Sub-Domain oder zumindest einen eigenen Port?

- warum soll der Reverse Proxy sicher sein? Gegenüber der Portfreigaben auf dem Router sehe ich nur den Vorteil, dass der Reverse Proxy per HTTPs läuft (das macht meine Synology Filestation aber generell, diese steht zeitweise passwortgeschützt im Internet) und dass man zulässige IP-Bereiche angeben kann. Ich kann damit nicht verhindern, dass jedermann (IP-Begrenzung ausgenommen - wer hat auf dem Smartphone schon eine feste IP...) von außen Login-Versuche starten kann, die dann per HTTPs verschlüsselt sind.

Vorteile VPN:

- Zugriff auf das gesamte (freigegebene) Netzwerk, wie zu hause

- VPN müsste gehackt werden, bevor man sich von außen an den Zugriff der Clients machen könnte

- gesamter Datenverkehr ist immer verschlüsselt

Nachteil VPN:

- der Client muss mit dem VPN-Server verbunden sein

Vorteil Reverse Proxy:

- kein VPN-Client nötig, damit immer sofort erreichbar, ohne einen VPN aufbauen zu müssen (bei bestehender Internetverbindung sofort verfügbar)

Nachteil Reverse Proxy:

- Portfreigaben in das Netzwerk notig (für VPN nur eine, bzw. läuft der VPN-Server direkt auf dem Router, bzw. der Firewall)

- jeder, der über die Domain geht, kann Login-Versuche an den verlinkten Servern im Heimnetz starten ohne zusätzlicher Sicherheitsabfrage

- idealerweise für jeden Server (jeden Shelly) eine eigene Sub-Domain oder eigenen Port erforderlich

- höherer Wartungsaufwand durch Punkt zuvor

Dieses sind keine Fakten, sondern Annahmen, bzw. Fragen aufgrund kurzer Google-Recherche. Ich bitte darum, dass diese wiederlegt oder bestätigt werden.

Grundsätzlich sind aufgrund der obigen Punkte VPN und Reverse Proxy nicht wirklich gut vergleichbar, da der VPN darauf abzielt unterwegs wie zu Hause arbeiten zu können und der Reverse Proxy anscheinend nur für einzelne oder weniger Server im Heimnetz zu empfehlen ist, auf die per sicherer Verbindung über eine Homepage (FQDN) zugegriffen werden soll.

Ich freue mich über einen regen Austausch.

Da sieht man wieder, dass messen unerlässlich ist und nicht einfach nach Farben oder aufgrund von Vermutungen geklemmt werden darf.

Der Taster liegt ganz einfach auf einer anderen Phase als der Shelly, was die Fehlerursache ist.

Vielleicht rebootet er beim Tasten. Auf jeden Fall dürfen dort keine 400V anliegen.

Ok, die Bezeichnung ähnelt der von AVM, aber im Eingangspost steht es ja.

Mein Tipp wäre weiterhin ein IP-Konflikt oder die Repeater können kein Unicast.

Könnte ein IP-Adressenkonflikt sein.

Wie sind die IPs vergeben?

Warum nutzt du einen Speedport und dann Repeater im AP-Mode von AVM?

P.s.: Bitte nicht Begriffe "Router" und "Repeater" durcheinander würfeln.

Hast du denn auch die IP gefolgt von dem Port eingetragen?

Ich habe testweise einfach "mcast" stehen lassen. Vielleicht Home Assistant neu starten, wenn das bei den Shellies bereits aktiviert ist.

Mit einem Shelly 1PM sind Wochenplan, Sunrise und Sunset möglich. Mit einem Shelly 1 vermutlich dann auch.

Der FI fliegt beim Bau ab und an mal? Ist die Ursache bekannt? Oder lag es nur daran, dass Du 30mA-FIs hast und mal mit N und PE zusammenkommst, wenn du Leitungen kürzt oder einführst? Ansonsten würde ich erstmal die Ursache hierfür beseitigen, nicht dass doch etwas falsch geklemmt ist, z.B. auf einem falschen N liegt oder irgendwo ein N keinen richtigen Kontakt hat.

Mich würde die Spannung zwischen SW und L interessieren, wenn der Taster gedrückt ist.

Die Actions zum Dimmen (Dim= Cycle) gab es mal, wurden aber leider entfernt. Per Script und Shelly i4 würde es wohl noch gehen.

Eigentlich hört sich alles so wie üblich an.

Die SW reagieren auf L und N, die Spannung dort ist normal. Kann sich der SW N über einen Verbraucher ziehen, gilt dieser als ausgelöst und ein Tasten bewirkt nichts.

Du hast somit die ganzen Problematiken nochmals zusammengefasst, nur den möglichen Widerstand vor SW vergessen oder kennst den nicht.