Nur... das reicht leider eben nicht, da ja CoAP ein Multicast Protokoll ist.
CoAP ist kein "Multicast Protokoll" sondern basiert auf UDP (UDP und multicast sind zwei ganz verschiedene Dinge). Ja, für CoAP gibt es auch eine Möglichkeit multicast für spezielle Dinge zu nutzen, siehe RFC 7252 Section 12.8
Mein openHAB läuft mit dem Shelly Binding. openHAB System und Shelly sind in verschiedenen VLANs mit unterschiedlichen IP Netzen und Router mit mDNS Reflector sowie Firewall-Regeln dazwischen.
Wie hast du das mit Multicast bei den Shellys gelöst? Nur Cloud? Nur MQTT oder wie machst du das?
In der Unifi Controller Software kann man für eine Site einen mDNS Reflector einschalten (funktioniert nur, wenn man auch ein Unifi USG hat). Der Reflector spiegelt dann die mDNS Pakete von einem LAN ins andere.
Ich nutze das eine (bisher einzige) 2.5 Shelly komplett ohne Cloud und ohne MQTT (openHAB hat ein Binding, was das CoApp Protokoll unterstützt, was ja die Shellys nun auch können). Funktioniert bis auf die Timeouts bei schnellem hin und her schalten hervorragend.
Das von mir beschriebene WLAN Roaming (oder eben nicht-roaming) ist auch besser, seitdem ich die SSID des IoT WLAN broadcaste. Zumindest bucht sich der Shelly 2.5 dann immer in den stärkeren Access Point ein (so wie ich das auch erwarte).
Hallo @da_Woody ,
falls Du mehr als einen Access Point bei Dir betreibst, so solltest Du beide (wie vorher schon mal geschrieben) auf unterschiedlichen Kanälen funken lassen. Das 2.4 GHz Band ist wirklich sehr voll. Da ich eine semi-professionelle WLAN-Ausrüsting benutze (Unifi von Ubiquiti) habe ich bei mir es so eingestellt, dass die 5 GHz fähigen Geräte (Notebooks, iPhones, iPads) zwangsweise auf 5 GHz verschoben werden (da ist bei mir fast nix von den Nachbarn los). Somit bleibt das 2.4 GHz Band bei mir für die Shellys (die können ja nur 2.4 GHz) und natürlich die Access Points der Nachbarn.
Details zur Kanalwahl siehe WLAN-Frequenzen und -Kanäle
Bei mir habe ich (weil meine Unifi Geräte das können) eine zusätzliche SSID nur für die IoT Geräte angelegt (und das auch mit VLAN, Routing und Firewall Regeln an das 'normale' LAN angebunden).
Es gibt auch noch eine SSID fürt Gäste (mit wieder eigenem VLAN, Routing und Firewall)
Ich habe also auf meinen Access Points insgesamt 3 SSIDs. Im 2.4 GHz Band benutze ich auf einem Access Point Kanal 1 und auf dem anderen Kanal 6. Beide mit 20 MHz Kanalbreite.
Auf Kanal 11 habe ich auch noch ein WLAN der Sonos Lautsprecher.(Sonos kann nur Kanäle 1,6 oder 11).
Da ich die Kanäle der Access Points der Nachbarn nicht ändern kann und insgesamt drei Kanäle brauche, habe ich mich für diese Aufteilung entschieden und leben eben mit dem Traffic und den Überlappungen (ein Nachbar hat sogar Kanal 2 und ein anderen Kanal 4 eingestellt - was natürlich zu massiven Überlappungen im Kanal 1 und im Kanal 6 führt = ist eben so 
) [Kanal Überlappungen werden von den betroffenen Access Points als Funk-Störungen verarbeitet - mehrere Access Points auf dem selben Kanal stören sich nur dahingehend, dass sie um die selbe Bandbreite kämpfen und sich gegebenenfalls gegenseitig ausbremsen).
Hoffe dies hilft Dir.
@da_Woody das WLAN Thema sollten wir in einen eigenen Thread auslagern und nicht diesen Thread hier kapern. Kannst mich gerne im ersten Post des neuen Threads @ erwähnen und ich finde ihn dadurch. Da können wir das gerne weiter diskutieren.
So, Fehler eingegrenzt. Danke SparkyMaster , Du hast mich auf eine Idee gebracht.
Die Verzögerungen und das sehr verzögerte Schalten hört sofort auf, sobald ich alle URL Einträge in den 'Actions' des Shelly lösche (und jeweils speichere). Evtl. war in den Urls bei mir was drin, was an meinem openHAB nicht schnell genug verarbeitet wurde (oder einen TimeOut verursachte).
Sowas sollte die Shelly Firmware abfangen und nicht auf die Response warten (der url Aufruf ist ja nur eine Mitteilung an ein anderes Gerät).
Die Verzögerungen scheinen also durch die Action Url-Aufrufe zu passieren. Da scheint wohl der Bug drin zu sein.
Könnte jemand ein Repro davon machen? Einmal mit Urls bei den Actions und einmal ohne?
Bei mir rufen die URL Einträge in den Shelly Actions entsprechende Endpunkte im openHAB auf. Der Entwickler des openHAB Shelly Bindings ist auch bereits an dem Thema der Timeouts dran. Könnte auch an dem Zusammenspiel der beiden liegen. siehe Thread im openHAB Community Forum Shelly Binding
ich empfehle deepl.com für die Übersetzungen. Ist eine deutsche Firma und die Übersetzungen sind wirklich super gut. Für den Hausgebrauch ist es auch kostenfrei.
OT:
Doch ist alles genau richtig und so soll man es auch machen. Benachbarte AP (auch mit derselben SSID) sollen immer auf unterschiedlichen Kanälen funken, damit sie sich nicht gegenseitig stören.
Mir wird gerade im Webinterface des Shelly 2.5 eine neue Firmware v1.5.8 angeboten.
Habe soeben Firmware eingespielt. Die von mir geschilderten Verzögerungen sind immer noch zu beobachten. (Naja, wäre ja auch etwas eigenartig, wenn innerhalb von ein paar Stunden ein Fix in einer Firmware wäre - da hatte ich nicht die Erwartung)
Problem: WiFi Stability (Nr. 1 aus der Fixes-Liste am Anfang dieses Threads)
Mein Shelly 2.5 bucht sich bevorzugt in den Access Point mit der schwächeren Empfangsleistung ein. Nicht immer, aber sehr häufig - und bleibt dann auch da fest verbunden, obwohl ein weitere Access Point (AP) im selben Netz mit selber SSID und wesentlich besserer Empfangsleistung (nur auf einem anderen Kanal) verfügbar ist.
Meine Vermutung: Shelly bucht sich immer in den AP (und dem WLAN Kanal) ein, den er beim Einrichten des WLAN Zugangs genommen hat.Erst sobald dieser AP nicht mehr verfügbar iost sucht Shelly sich einen anderen mit selber SSID. Nach einiger Zeit wechselt der Shelly dann wieder auf den alten AP, sofern dieser wieder verfügbar ist (obwohl dieser eine schlechtere Empfangsleistung hat).
Das ist für mich weder logisch noch sinnvoll.
Repro Setup:
- 2 Unifi AP im selben Netz mit selber SSID - SSID ist versteckt (kein SSID broadcast)
- 1x AP mit Wifi Kanal 1 und 1x AP mit Wifi Kanal 6
- AP mit Wifi Kanal 6 ist der vom Shelly bevorzugte AP (hier wurde der Shelly auch eingerichtet und dann später im Haus an einen anderen Ort gebracht - und dabei natürlich der Shelly auch neu gestartet)
- AP mit Wifi Kanal 1 ist eindeutig näher am Shelly und hat auch nach connect die deutlich bessere Empfangsleistung
Kann das jemand reproduzieren?
Zusatz nach weiteren Tests:
mit SSID broadcast (also nicht versteckter SSID) funktioniert dass Einbuchen in den AP mit der besseren Empfangsleistung.
OT: liest Shelly hier mit und besteht Hoffnung auf Fixes der hier erwähnten Probleme? oder gibt es einen anderen Weg Shelly über diese Probleme zu informieren? (ich nutze kein Facebook mehr und werde auch wegen Shelly nicht wieder damit anfangen)
Shelly 2.5 Rollershutter - Verzögerungen beim schnellen Umschalten.
Bei meinem neuen Shelly 2.5 treten im Rollershutter Modus mit dieser Firmware nach einigen Schaltvorgängen Verzögerungen von bis zu 10 Sekunden in den Schaltvorgängen auf, wenn ich schnell nacheinander umschalte (schnell = mit ca. 0,5-1 Sekunde Pause). Es ist das selbe Verhalten mittels der Device-Weboberfläche als auch per openHAB (mit Shelly Binding). Die Befehle werden wohl in einer Queue gehalten, denn sie werden dann zeitversetzt später ausgeführt. Während der Verzögerung sind in der Weboberfläche des Shelly dann um die Schaltknöpfe (open/unten/pause) sich bewegende gestrichelte Kreise zu sehen.
Scheint ein Bug in der Firmware zu sein.
btw: Bin ganz neu hier im Forum und es ist auch mein erstes Shelly Device. Ich nutze openHAB auf RasPI mit HomeMatic CCU2 etc.
So, Fehler eingegrenzt. Danke SparkyMaster , Du hast mich auf eine Idee gebracht.
Die Verzögerungen und das sehr verzögerte Schalten hört sofort auf, sobald ich alle URL Einträge in den 'Actions' des Shelly lösche (und jeweils speichere). Evtl. war in den Urls bei mir was drin, was an meinem openHAB nicht schnell genug verarbeitet wurde (oder einen TimeOut verursachte).
Sowas sollte die Shelly Firmware abfangen und nicht auf die Response warten (der url Aufruf ist ja nur eine Mitteilung an ein anderes Gerät).
Die Verzögerungen scheinen also durch die Action Url-Aufrufe zu passieren. Da scheint wohl der Bug drin zu sein.
Könnte jemand ein Repro davon machen? Einmal mit Urls bei den Actions und einmal ohne?
Es geht nicht um die CCU. Das Shelly Device selber hat diese Verzögerungen. Das Problem liegt definitiv im Shelly.
Shelly 2.5 Rollershutter - Verzögerungen beim schnellen Umschalten.
Bei meinem neuen Shelly 2.5 treten im Rollershutter Modus mit dieser Firmware nach einigen Schaltvorgängen Verzögerungen von bis zu 10 Sekunden in den Schaltvorgängen auf, wenn ich schnell nacheinander umschalte (schnell = mit ca. 0,5-1 Sekunde Pause). Es ist das selbe Verhalten mittels der Device-Weboberfläche als auch per openHAB (mit Shelly Binding). Die Befehle werden wohl in einer Queue gehalten, denn sie werden dann zeitversetzt später ausgeführt. Während der Verzögerung sind in der Weboberfläche des Shelly dann um die Schaltknöpfe (open/unten/pause) sich bewegende gestrichelte Kreise zu sehen.
Scheint ein Bug in der Firmware zu sein.
btw: Bin ganz neu hier im Forum und es ist auch mein erstes Shelly Device. Ich nutze openHAB auf RasPI mit HomeMatic CCU2 etc.
