13
Home Assistent findet Shelly in VLAN nicht OPNsense
Hi,
ich habe mir ein paar Shellys besorgt und diese in mein IoT Netz eingebunden (testweise aktuell nur einen Plug S).
Dort wird der Shelly aber nicht als Gerät in HA gefunden, in der Shelly Home App wird er mir aber angezeigt.
Daher kann es an sich ja nicht am Routing liegen?
Zugreifen auf die GUI im IoT Netz klappt ohne Probleme.
Ich habe das UDP Broadcast Relay installiert, da diese ja zwischen VLAN laufen müssen.
HA und die Shelly Home App sind im LAN.
Es ist bestimmt wieder nur eine Kleinigkeit falsch. Vielleicht hat ja jemand den endscheidenen Tipp.
Guten Rutsch!
ich habe mir ein paar Shellys besorgt und diese in mein IoT Netz eingebunden (testweise aktuell nur einen Plug S).
Dort wird der Shelly aber nicht als Gerät in HA gefunden, in der Shelly Home App wird er mir aber angezeigt.
Daher kann es an sich ja nicht am Routing liegen?
Zugreifen auf die GUI im IoT Netz klappt ohne Probleme.
Ich habe das UDP Broadcast Relay installiert, da diese ja zwischen VLAN laufen müssen.
HA und die Shelly Home App sind im LAN.
Es ist bestimmt wieder nur eine Kleinigkeit falsch. Vielleicht hat ja jemand den endscheidenen Tipp.
Guten Rutsch!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5162370189
Url: https://administrator.de/forum/home-assistent-findet-shelly-in-vlan-nicht-opnsense-5162370189.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
13 Kommentare
Neuester Kommentar
Ich habe das UDP Broadcast Relay installiert
Bist du dir denn sicher das die Shellys Broadcasts benutzen und nicht Multicast (mDNS etc.)?Die .224er IP Adresse spricht eher deutlich dafür das du, vermutlich aus Unwissenheit, Broad- und Multicast hier etwas laienhaft verwechselt hast, denn 224... ist de facto kein Broadcast sondern Multicast.
Ein Packet Capture auf der Firewall am VLAN Interface mit der Shelly IP als Filter sollte dir da finale Gewissheit geben?!
Sofern es mDNS ist hilft der AVAHI Proxy ansonsten der Multicast Proxy:
Apple AirPrint über VLANs
Port 5863 ist ein reservierter IANA Port.
Nebenbei ist dein Regelwerk am LAN Port auch etwas unlogisch. Wenn du so oder am Ende alles erlaubst warum erlaubst du denn oben allen Traffic ins DMZ und IoT Netz nochmal separat?? Das wäre ja dann doppelt gemoppelt und völlig überflüssig weil das die "erlaube alles" Regel am Ende ja auch abfackelt?! Keep it simple stupid... 😉
Moin,
hier steht eigentlich alles, was man beachten und konfigurieren muss: https://www.home-assistant.io/integrations/shelly/
Erstmal überprüfen, ob Du Gen1 oder Gen2 Shellys hast. Bei beiden musst Du erst am Gerät noch etwas konfigurieren. Gen1 bzw. Gen2 nutzen unterschiedliche Protokolle für die Kommunikation mit der HomeAssistand-Integration.
Gruß
cykes
hier steht eigentlich alles, was man beachten und konfigurieren muss: https://www.home-assistant.io/integrations/shelly/
Erstmal überprüfen, ob Du Gen1 oder Gen2 Shellys hast. Bei beiden musst Du erst am Gerät noch etwas konfigurieren. Gen1 bzw. Gen2 nutzen unterschiedliche Protokolle für die Kommunikation mit der HomeAssistand-Integration.
Gruß
cykes
1
@aqui
Ich muss mal bei Zeiten schauen, kann sein das dort mCast bei CoIoT steht, dann wäre es falsch.
Ich habe danach gegoogelt und leider nicht sehr viel gefunden.
Die meisten nutzen nur ein Netz und nicht VLans.
Ich wurschtel mich so durch, meistens gehts damit auch aber halt nicht immer. Dafür gibts du ja immer super Tipps.
Stecke ich den Shelly in mein LAN findet er ihn logischerweise sofort, soll aber ins IoT.
Die LAN any Regel ist doppelt wie du schon meintest, ohne die beiden oberen Einträge habe ich aber keinen Zugriff auf die Netze, trotz der any any Regel. Oder blockt die DNS Regel alles weitere? Dann müsste die any Regel nach oben.
@cykes den Link schaue ich mir mal an.
Ich muss mal bei Zeiten schauen, kann sein das dort mCast bei CoIoT steht, dann wäre es falsch.
Ich habe danach gegoogelt und leider nicht sehr viel gefunden.
Die meisten nutzen nur ein Netz und nicht VLans.
Ich wurschtel mich so durch, meistens gehts damit auch aber halt nicht immer. Dafür gibts du ja immer super Tipps.
Stecke ich den Shelly in mein LAN findet er ihn logischerweise sofort, soll aber ins IoT.
Die LAN any Regel ist doppelt wie du schon meintest, ohne die beiden oberen Einträge habe ich aber keinen Zugriff auf die Netze, trotz der any any Regel. Oder blockt die DNS Regel alles weitere? Dann müsste die any Regel nach oben.
@cykes den Link schaue ich mir mal an.
Moin,
ich habe mich gestern durch das gleiche Thema gewuselt, allerdings nicht mit Home Assistent sondern mit Homebridge und Shelly. Ich habe auch das IOT Lan und das normale LAN, allerdings über Unifiy UDM SE.
Ich habe folgende FW Regeln erstellt: IOT Netz... UDP, Shelly IP, Port any --> Lan, Homebridge IP ,Port 5683
Zusätzlich im Webinterface der Shellys unter CoLoT Peer folgendes eingetragen: IP Homebridge:5683
Shelly einmal Neustarten und dann hat alles funktioniert. Die Homebridge / Shelly Plugin hat die Shelly automatisch gefunden und eingebunden.
Grüße und Frohes Neues Jahr!
ich habe mich gestern durch das gleiche Thema gewuselt, allerdings nicht mit Home Assistent sondern mit Homebridge und Shelly. Ich habe auch das IOT Lan und das normale LAN, allerdings über Unifiy UDM SE.
Ich habe folgende FW Regeln erstellt: IOT Netz... UDP, Shelly IP, Port any --> Lan, Homebridge IP ,Port 5683
Zusätzlich im Webinterface der Shellys unter CoLoT Peer folgendes eingetragen: IP Homebridge:5683
Shelly einmal Neustarten und dann hat alles funktioniert. Die Homebridge / Shelly Plugin hat die Shelly automatisch gefunden und eingebunden.
Grüße und Frohes Neues Jahr!
1Zitat von @Neonop2:
Moin,
ich habe mich gestern durch das gleiche Thema gewuselt, allerdings nicht mit Home Assistent sondern mit Homebridge und Shelly. Ich habe auch das IOT Lan und das normale LAN, allerdings über Unifiy UDM SE.
Ich habe folgende FW Regeln erstellt: IOT Netz... UDP, Shelly IP, Port any --> Lan, Homebridge IP ,Port 5683
Zusätzlich im Webinterface der Shellys unter CoLoT Peer folgendes eingetragen: IP Homebridge:5683
Shelly einmal Neustarten und dann hat alles funktioniert. Die Homebridge / Shelly Plugin hat die Shelly automatisch gefunden und eingebunden.
Grüße und Frohes Neues Jahr!
Moin,
ich habe mich gestern durch das gleiche Thema gewuselt, allerdings nicht mit Home Assistent sondern mit Homebridge und Shelly. Ich habe auch das IOT Lan und das normale LAN, allerdings über Unifiy UDM SE.
Ich habe folgende FW Regeln erstellt: IOT Netz... UDP, Shelly IP, Port any --> Lan, Homebridge IP ,Port 5683
Zusätzlich im Webinterface der Shellys unter CoLoT Peer folgendes eingetragen: IP Homebridge:5683
Shelly einmal Neustarten und dann hat alles funktioniert. Die Homebridge / Shelly Plugin hat die Shelly automatisch gefunden und eingebunden.
Grüße und Frohes Neues Jahr!
Top, danke.
Probiere ich heute Abend mal aus.
@aqui
Die Shelly Plugs laufen nur mit unicast da sie aus der Generation 1 sind.
Ein block taucht doch auf:
Die Regeln hatte ich in einem Block gefunden, mDNS scheint wohl zur Erkennung nötig zu sein aber die Gen 1 ist halt nur unicast.
EDIT: Evtl. hänge ich Home Assistant einfach in das IoT Netz, darauf habe ich ja eh zugriff. Würde wohl alles einfacher machen.
Die Shelly Plugs laufen nur mit unicast da sie aus der Generation 1 sind.
Ein block taucht doch auf:
Die Regeln hatte ich in einem Block gefunden, mDNS scheint wohl zur Erkennung nötig zu sein aber die Gen 1 ist halt nur unicast.
EDIT: Evtl. hänge ich Home Assistant einfach in das IoT Netz, darauf habe ich ja eh zugriff. Würde wohl alles einfacher machen.
Die Shelly Plugs laufen nur mit unicast da sie aus der Generation 1 sind.
Dann stellt sich aber die Frage warum du eine dann völlig sinnfreie Regel auf 224.0.1.187 Multicast Adressen in der Firewall definierst?!Nebenbei sind die beiden Multicast Regeln völlig sinnfrei, denn ohne einen IGMP Proxy oder PIM Routing auf der Firewall forwardet die keinen Multicast Traffic in andere Segmente!
mDNS/Bonjour per se gar nicht, weil das ein Link Local Multicast ist mit einer TTL von 1 der eh unroutebar ist. Da hilft nur der oben schon genannte AVAHI Proxy!
Die vielen Konjunktive oben zeigen eigentlich das du mehr rätst und spekulierst als etwas genau zu wissen.
Warum schliesst du nicht einfach einmal einen Wireshark an siehst dir einmal ganz genau an WIE die Shellys wirklich kommunizieren im Netz. Dann hätte das Ratedrama ein Ende und du hast es schwarz auf weiss und musst nicht wild im freien Fall Kristallkugeln!
1
Ich habe mal die Kommunikation zwischen PC (10.10.10.129) und meinem Test Shelly (10.10.20.30) rauskopiert:
Ich sage ja ich versuche mich da so durch zu wurschteln. Über Hilfe/Tipps bin ich dankbar.
1658 47.970217 10.10.10.129 10.10.20.30 TCP 66 50175 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
1659 47.998959 10.10.20.30 10.10.10.129 TCP 58 80 → 50175 [SYN, ACK] Seq=0 Ack=1 Win=2920 Len=0 MSS=1460
1660 47.999162 10.10.10.129 10.10.20.30 TCP 54 50175 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0
1661 48.002908 10.10.10.129 10.10.20.30 HTTP 465 GET /relay/0?turn=on HTTP/1.1
1662 48.023676 10.10.20.30 10.10.10.129 HTTP/JSON 290 HTTP/1.1 200 OK , JavaScript Object Notation (application/json)
1663 48.025907 10.10.10.129 10.10.20.30 TCP 54 50175 → 80 [ACK] Seq=412 Ack=238 Win=64004 Len=0
1664 48.029138 10.10.10.129 10.10.20.30 TCP 54 50175 → 80 [FIN, ACK] Seq=412 Ack=238 Win=64004 Len=0
1665 48.034214 10.10.20.30 10.10.10.129 TCP 54 80 → 50175 [ACK] Seq=238 Ack=413 Win=2508 Len=0
1666 48.035819 10.10.10.129 10.10.20.30 TCP 66 50176 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
1667 48.043394 10.10.20.30 10.10.10.129 TCP 58 80 → 50176 [SYN, ACK] Seq=0 Ack=1 Win=2920 Len=0 MSS=1460
1668 48.043593 10.10.10.129 10.10.20.30 TCP 54 50176 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0
1669 48.046867 10.10.10.129 10.10.20.30 HTTP 456 GET /status HTTP/1.1
1670 48.077638 10.10.20.30 10.10.10.129 HTTP/JSON 1013 HTTP/1.1 200 OK , JavaScript Object Notation (application/json)
1671 48.080003 10.10.10.129 10.10.20.30 TCP 54 50176 → 80 [ACK] Seq=403 Ack=961 Win=63281 Len=0
1672 48.082878 10.10.10.129 10.10.20.30 TCP 54 50176 → 80 [FIN, ACK] Seq=403 Ack=961 Win=63281 Len=0
1673 48.099284 10.10.20.30 10.10.10.129 TCP 54 80 → 50176 [ACK] Seq=961 Ack=404 Win=2517 Len=01692 48.749629 10.10.20.30 10.10.10.129 HTTP/JSON 1013 HTTP/1.1 200 OK , JavaScript Object Notation (application/json)
1693 48.752742 10.10.10.129 10.10.20.30 TCP 54 50177 → 80 [ACK] Seq=403 Ack=961 Win=63281 Len=0
1694 48.755891 10.10.10.129 10.10.20.30 TCP 54 50177 → 80 [FIN, ACK] Seq=403 Ack=961 Win=63281 Len=0
1695 48.762416 10.10.20.30 10.10.10.129 TCP 54 80 → 50177 [ACK] Seq=961 Ack=404 Win=2517 Len=0
1696 48.808941 10.10.10.129 10.10.20.30 TCP 66 50178 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
1697 48.816283 10.10.20.30 10.10.10.129 TCP 58 80 → 50178 [SYN, ACK] Seq=0 Ack=1 Win=2920 Len=0 MSS=1460
1698 48.816448 10.10.10.129 10.10.20.30 TCP 54 50178 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0
1699 48.820676 10.10.10.129 10.10.20.30 HTTP 466 GET /relay/0?turn=off HTTP/1.1
1700 48.840937 10.10.20.30 10.10.10.129 HTTP/JSON 291 HTTP/1.1 200 OK , JavaScript Object Notation (application/json)
1701 48.842270 10.10.10.129 10.10.20.30 TCP 54 50178 → 80 [ACK] Seq=413 Ack=239 Win=64003 Len=0
1702 48.843744 10.10.10.129 10.10.20.30 TCP 54 50178 → 80 [FIN, ACK] Seq=413 Ack=239 Win=64003 Len=0
1703 48.847253 10.10.10.129 10.10.20.30 TCP 66 50179 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
1704 48.848564 10.10.20.30 10.10.10.129 TCP 54 80 → 50178 [ACK] Seq=239 Ack=414 Win=2507 Len=0
1705 48.852740 10.10.20.30 10.10.10.129 TCP 58 80 → 50179 [SYN, ACK] Seq=0 Ack=1 Win=2920 Len=0 MSS=1460
1706 48.852847 10.10.10.129 10.10.20.30 TCP 54 50179 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0
1707 48.854719 10.10.10.129 10.10.20.30 HTTP 456 GET /status HTTP/1.1
1708 48.886796 10.10.20.30 10.10.10.129 HTTP/JSON 1014 HTTP/1.1 200 OK , JavaScript Object Notation (application/json)
1709 48.888322 10.10.10.129 10.10.20.30 TCP 54 50179 → 80 [ACK] Seq=403 Ack=962 Win=63280 Len=0
1710 48.890002 10.10.10.129 10.10.20.30 TCP 54 50179 → 80 [FIN, ACK] Seq=403 Ack=962 Win=63280 Len=0
1711 48.900440 10.10.20.30 10.10.10.129 TCP 54 80 → 50179 [ACK] Seq=962 Ack=404 Win=2517 Len=0Ich sage ja ich versuche mich da so durch zu wurschteln. Über Hilfe/Tipps bin ich dankbar.
Ich habe HA jetzt einfach in das IoT Netz gepackt und es klappt so wie es soll.
Ich glaube es ist den ganzen Aufwand nicht Wert, so reicht es mir massig.
Trotzdem Danke an dich.
Ich glaube es ist den ganzen Aufwand nicht Wert, so reicht es mir massig.
Trotzdem Danke an dich.
die Kommunikation zwischen PC (10.10.10.129) und meinem Test Shelly (10.10.20.30)
Hilft wenig, denn das ist die normale HTTP Kommunikation (vermutlich übers WebGUI) die mit den Broad- oder Multicast Announcements (oder was auch immer der Shelly da macht?!) nichts zu tun hat.Kollege @Neonop2 hatte oben ja schon einen gangbaren und eleganten Weg aufgezeit indem der HA Server statisch im Shelly definiert wird: "unter CoLoT Peer folgendes eingetragen: IP Homebridge:5683". Dann benötigt der auch kein Broad- oder Multicast mehr.
Aber egal...du hast ja jetzt eine perfekte Lösung gefunden!
Die CoIoT hatte ich angegeben lief aber nicht.
Da ich vom LAN voll aufs IoT Netz zugreifen kann, ist es so die beste Lösung für mich.
Dachte es geht einfach aber man muss das Rad ja nicht immer neu erfinden.
Da ich vom LAN voll aufs IoT Netz zugreifen kann, ist es so die beste Lösung für mich.
Dachte es geht einfach aber man muss das Rad ja nicht immer neu erfinden.
Es geht auch einfach, man muss es nur richtig machen! 😉
Dann haben wir eine andere Definition von einfach :D
