Beiträge von Norfolk

IP passt und es irritiert mich ja auch, dass es nur zeitweise auftritt. Verteiler ist Plastik, aber klar, gibt viele Kabel und damit zufällige Störungen.

Habe erstmal den AP bisserl umgestellt - mal schauen ob das was gebracht hat.
Next step wäre doch noch ein LAN-Kabel zu legen bzw. zu testen, auch wenn ich das gerne vermeiden würde.

Hallo,

ich habe einen Pro3EM, der mit einem ca. 2m daneben positionierten WLAN-AP verbunden ist. RSSI bei ca -45 und Info "good". Manchmal ist er längere Zeit problemlos erreichbar, dann wieder gibts Phasen, wo er ständig disconnected bzw. kaum erreichbar ist. FW habe ich gerade erst auf 1.7.1 geupdated, hilft aber nichts.

Gibt's Ideen, was da sein könnte?

Beim WLAN-AP sind die Settings auf möglichst hohe Kompatibilität mit IOT-Geräten eingestellt, also keine fortschrittlichen Optionen o.ä. - das sollte also passen.

Der Pro3EM ist im Verteilerschrank, weshalb ein Test der LAN-Anbindung zwecks Vergleich schwierig ist.

Aufgefallen ist es abgesehen von zufälligen Verzögerungen und ggf. ignorierten Trigger bei Actions und Szenen erst, als ich längere Zeit mit der Weboberfläche via WLAN arbeiten wollte. Das war teilweise über längere Zeit problemlos mit stabiler Verbindung möglich, aber zu anderen Zeitpunkten ist die Verbindung ständig abgerissen, kaum dass die Weboberfläche im Browser aufgerufen war. Dann musste ich z.b. schonmal 5 Minuten laufend reloaden, bis ich 3 Actions mittels Schiebeschalter aktivieren konnte.

Um noch eine Antwort auf meine eigene Frage nachzureichen:

Habe nun festgestellt, dass der Pro3EM offenbar erhebliche Verbindungsprobleme hat, zumindest zeitweise - die fallen aber sonst nicht auf und wurden von mir erst zufällig festgestellt, als ich über die Weboberfläche den Pro3EM konfigurierte.

Das dürfte dann auch für die erwähnten Verzögerungen oder Ausfällen führen.

Wie kann ich der Ursache für diese Verzögerungen nachspüren? Mich wundert vor allem, dass ja beide Aktionen von einem Pro3EM ausgelöst werden und den selben Plus2PM ansteuern. Die WLAN-Verbindung wird im Shelly als "Good" angezeigt und ist auch praktisch sehr gut, sowohl bei den RSSI als auch durch die Nähe, es sind der WLAN-AP und beide Shelly-Geräte in einem Raum mit Luftline ca. 2m zueinander.

Die Unsynchronität ist auch zufällig, also manchmal wird der eine Ausgang des 2PM schneller geschaltet, manchmal der andere und manchmal fehlt eine Reaktion komplett.

Das Problem hatte ich mittels Cloud + Szenen bereits beobachtet und dort nicht nur mit dem 2PM, sondern auch mit 3 weiteren Plug S, also 5 Ausgänge. Ich dachte, das Problem wäre durch die Netzverbindung und Cloud-Lösung verursacht und wollte es mit BTHome und lokalen Aktionen beheben ... bisher ohne Erfolg.

Danke für die schnelle Antwort, läuft schon - zumindest im Testlauf.

Noch zwei ergänzende Fragen:

Wenn ich z.B. mit 1x Tastendruck insgesamt 4 Shellys gleichzeitig schalten will, kann ich ja direkt alle 4 URLs bei einer Action eintragen. Ist das der richtige Weg oder gibt's dafür auch die Möglichkeit, z.B. Gruppen zu definieren und diese gemeinsam anzusprechen?

Ich schalte nun mit 1x Tastendruck mittels 2 URLs die zwei Ausgänge eines "Plus 2PM", dabei fällt eine zufällige Unsynchronität auf. Manchmal schalten beide Ausgänge sofort, aber manchmal schaltet auch ein Ausgang nach 1 Sek und der andere Ausgang nach 4 Sekunden bzw. umgekehrt. Manchmal schaltet auch nur ein Ausgang und der andere garnicht.

Das kannte ich bisher aus der Cloud-Lösung mit Szenen, aber da nun die Action lokal laufen sollte, hätte ich erwartet, dass es keine nennenswerten Verzögerungen oder Ausfaller gibt. Mache ich was falsch?

PS: BT-Components und Actions sind bei einem Pro3EM hinterlegt, geschaltet werden die 2 Ausgänge vom Plus2PM und beides hängt im gleichen WLAN mit je ca. 2m Luftlinie zum selben AP. Als URL verwende ich http://192.168.2.213/relay/1?turn=toggle und http://192.168.2.213/relay/0?turn=toggle

Hallo,

ich habe zwei "Shelly BLU Wall Switch 4" bei einem Pro3EM als Components eingebunden, sie schienen dort auch als "Bluetooth (BTHome) device" auf und die Tastendrucke werden auch korrekt angezeigt.

Aber was mache ich jetzt? Ich möchte lokal mit den Buttons div. Shelly-Geräte aus-/einzuschalten - sozusagen als Lichtschalter.

Dazu wollte ich in der Pro3EM-Weboberfläche im Menüpunkt "Action" die Aktionen definieren, aber "Add action to execute" -> "Device doesn't support local actions." und bei "Add URL" habe ich keine Infos, was ich hier eingeben müsste bzw. wo ich dazu weitere Infos bekomme.

Gibt's dazu Infos oder Guides, wo ich mehr darüber finde?

Ich lese da raus, dass BTHome deutlich besser geeignet ist? Werd's wohl doch genauer anschauen müssen.

Zeitmangel - 2 Kleinkinder und so. Würd ich sonst eh gerne, weil gefühlt werden nur ca. 90% der Tastendrucke als Aktionen umgesetzt. Es ist ein Lichtschalter, also wart ich jedesmal kurz, ob er eh schaltet oder ob ich doch nochmal drücken muss bzw. gar zum anderen Schalter gehen muß ...

Hallo,

ich habe meine BLU Wall Switch 4 mit mehreren Gateways verbunden, falls ein Gateway schlechten WLAN-Empfang hat. Anfangs haben die Wall Switches öfters nicht gut reagiert. WLAN sollte jetzt besser sein, über die Bluetooth-Verbindung weiss ich nichts genaueres.

Nun wurde heute ein Tastendruck ignoriert, obwohl er im Activity Log angeführt ist, dort jedoch mit dem Kürzel "?128".

Was heist das Kürzel bzw. kann es mit den multiplen Gateways zusammenhängen?

Ein zweiter Tastendruck ca. 5 Sekunden später wurde normal aktzeptiert, führte zur gewünschten Aktion und steht auch normal, d.h. ohne dieses Kürzel im Log.

Umgekehrt sehe ich die "?128" öfters in der Liste, habe aber bisher vermutet, dass Shelly so die Mehrfachmeldungen von einem Tastendruck darstellt, also selbst weiss, dass es nur ein Tastendruck war und über die multiplen Gateways den eben mehrmals gemeldet bekommt - und berechtigt ignoriert. Mit der Vermutung bin ich dem bisher nicht nachgegangen.

Aber wie gesagt, diesmal gab es nur einen Eintrag inkl. dem Kürzel und der Tastendruck wurde ignoriert - das passt nicht zu meiner Theorie

Danke, jetzt hats funktioniert.

Nach kurzer Batterieentnahme hat der Switch sich - anders als zuvor - problemlos und schnell über die Debug BLE App am Android updaten lassen.

Ich habe noch a) einen Reset und b) die Batterieentnahme als Test geplant.

Aber es ist der Standalone-Switch, hat jemand Bilder wie man den aufmacht? Er wirkt, als würde ich ihn nur auseinanderreissen können, mit der Gefahr, dass er in Teile zerfällt... oder ist das der richtige Weg?

Am Handy dürfts nicht liegen, wie gesagt - zumindest mit Android konnte ich den 2. Switch normal updaten und im Gegensatz zum Problem-Switch reagiert der 2. Switch auch sonst viel zuverlässiger. Den Problemswitch wollte ich mir genauer anschauen, weil er immer wieder nicht reagiert.

EDIT: Standalone => Der Switch, der seinen eigenen Rahmen dabei hat. Und ich sehe nicht, wie der Switch in diesen Mini-Rahmen eingeklickt ist bzw. wie man ihn zerstörungsfrei herausnimmt.

Die Android-App kanns auch nicht. FW ist 1.0.20 und ich wollte auf 1.0.22 updaten.

Hier schaut alles normal aus, slow-ota ausgewählt, der Switch ist gepaired und wenn ich ota aufrufe, schlagt er das FW-Update vor, ich klicke ja, danach folgt "Waiting for device... / Rebooting device...." und das wars, keine weitere Reaktion. Der Switch kann dann normal bedient werden und in der App breche ich irgendwann das "Waiting ..." ab, jedoch ohne FW-Update.

Es scheint am Switch zu liegen. Ich habe 2 Switches mit identischer Verwendung. Beim 2. Switch hat es problemlos und sofort funktioniert.

Oder auch möglich: Der problematische Switch ist an der Wand ca. 10cm neben einem Lichtschalter. Könnten die Stromleitungen vom Lichtschalter ein Problem sein? Der Switch erscheint mir nämlich grundsätzlich wie eine "Diva", daher wollte ich auch das Update versuchen.

Ich habe das gleiche Problem. In der control app hängts bei "Initializing Update" und in der debug app "Preparing to update, dont leave the app". Ebenfalls über iOS.

Theoretisch könnte ich ein Android ausgraben und fitt machen - aber ist das wirklich die Lösung oder nur ein weiterer Versuch?

Danke euch allen, jetzt hab ich es endlich verstanden

Zitat von Devil

Solange mit Wifi-2 verbunden bleibt die Verbindung auch auf Wifi-2. Dort gibt es kein Roaming zwischen zwei Netzten und ist auch nicht angedacht.

Aber warum kann ich keine Verbindung mit WIFI-1 erzwingen?

Ich habe bereits die Shelly rebooted und in einem anderen Versuch beim Shelly-Menü bei WIFI-1 einen "Scan for Network" oder erneut das SSID-PWD eingegeben etc., aber trotzdem verbindet sich der Shelly immer ins WIFI-2 - und beschwert sich dann über eine viel zu schlechte Verbindung.

EDIT: Ich habe vlt. das "Wifi Roaming" im Shelly falsch verstanden. Ich dachte bisher, das führt ggf. zum Umstieg zwischen WIFI-1 und WIFI-2, aber lese zwischen den Zeilen eurer Antworten, dass es vielleicht eine SSID mit mehreren APs betrifft? Ändert aber noch nichts an meiner Verwunderung, warum auch ein Reboot vom Shelly nicht dazu führt, dass er sich zuerst ins deutlich signalstärkere WIFI-1 verbindet.

Weil das Ubiquiti-Netz mit noch zu installierenden AP im Aufbau ist und immer wieder abgeschaltet werden muss, längerfristig sollte dann nur ein WIFI 1 übrigbleiben.

Und nachdem sich die Shellys aktuell etwas zieren, den Ubiquiti-AP zu verwenden, wollte ich nicht meine einzige andere aktive Verbindungsmöglichkeit deaktivieren.

Um das nochmal anzusprechen, das ursprüngliche Problem besteht weiterhin.

Mittlerweile ist der Ubiquiti AP aufgetrennt mit 2 Netzwerken für 2,4 und 5 ghz. Daneben gibts einen ASUS AP mit 2,4 ghz.

Bei den Shellys ist als WIFI 1 der Ubiquiti hinterlegt mit RSSI -50 bis -70, als WIFI 2 der ASUS mit RSSI -82 bis -90. Roaming ist auf standardmässige -80 und 60 Sekunden.

Es müsste also alles am WIFI 1 zum Ubiquiti verbinden und ich hatte die Shellys auch schonmal im richtigen Netz - k.a. ob Zufall oder durch händische Reboots/Rescans, plötzlich waren sie dort eingeloggt.

Heute musste ich den Ubiquiti rebooten, natürlich sind die Shellys auf den WIFI 2 umgeloggt, aber trotz Rescans, Reboots und dem Roaming bleiben sie hartnäckig am ASUS - von dem sie aber praktisch kaum Daten bekommen, so schlecht ist die Verbindung... Und dann meckern sie auch in den Notification von "Weak Wi-Fi signal", statt einfach den deutlich besseren WIFI 1 zu nehmen.

Was hat's da?

Randnotiz: Ja, alle relevanten Shellys sind in einem Raum und haben daher praktisch gleichwertig gute Verbindung zum Ubiquiti bzw. schlechte zum Asus.

Ah, danke für die Infos! Controller und Übergabe etc. hatte ich bisher nicht am Radar, weil's ein gewachsenes System ist - daher auch die Vielfalt mit 3 Hersteller - WRT ist von Linksys, nicht Asus wie oben angeführt und der Ubiquiti ist eigentlich als Outdoor-AP dazugekommen. Bei 2,4 ghz reicht der 1. AP für 95% vom Haus, die anderen AP kamen dann für die Randzonen dazu. Aber klar, ein modernes Netz mit 5 ghz überall und daher entsprechend mehr AP ist es (derzeit) nicht.

Du meinst, ich sollte auf allen AP dem 2,4er Netz die gleiche SSID geben?

Ich habe einen 1. AP einen ASUS RT-N66U Router (ca. 10 Jahre alt?), als 3. AP einen noch älteren ASUS WRT320N und als Neuzukömmling der 2. AP, ein Ubiquiti UAP AC M

EDIT: Sonst gibt's bei mir keine Hardware ausser passive Switches. Alles mit Ethernet verbunden. Der Asus Router ist auch das Gateway zum Modem, inkl. NAT und DHCP. Aber was macht ein Controller?

Bspw. ein Plug S Gen3 verbindet zum als "Wifi 1" hinterlegten 1. Access Point mit SSID "netz1" und hat RSSI -91dBm, bzw. im SSID-Auswahlmenü wird es mit RSSI -87 angezeigt. Der 2. Access Point bietet ein SSID "netz2" (sowohl 2,4 ghz als auch 5 ghz), die RSSI zeigt der Plug mit -68dBm, verbindet aber nicht dorthin. WiFi-Roaming ist auf RSSI threshold -80 und Interval 60 gestellt.

Ein anderer Plug S Gen3 hat als "Wifi 1" den 2. AP mit "netz2" hinterlegt, hätte dort RSSI -52dBm, verbindet statt dessen aber zu "Wifi 2", einem 3. AP mit SSID "netz3", wo er RSSI -74 dBm sieht.

Der einzige Unterschied bei den AP: Der 1. AP bietet "netz1" für 2,4 ghz und "netz4" für 5 ghz. Der 3. AP bietet nur "netz3". Nur der 2. AP bietet das "netz2" sowohl auf 2,4ghz als auch 5 ghz. War eigentlich ein Versuch, nachdem ich früher - vor 10 Jahren - schon Probleme hatte, wenn ein AP die gleiche SSID für 2,4 ghz als auch 5 ghz verwendet hatte. Deshalb habe ich es damals auch aufgespalten und jedem AP eine eigene SSID zugewiesen, wollte aber nun beim Neuzugang - dem 2. AP - wieder testen, ob's nicht doch geht. Ich kann's heute nicht mehr testen, aber es sieht so aus als wäre auch hier 2 getrennte SSID besser?

Als Randnotiz, weils nicht Shelly betrifft: Wie gesagt, früher hatte ich Probleme, den AP auf beiden Frequenzen mit der gleichen SSID arbeiten zu lassen. Später hab ich dass absichtlich genutzt, um z.B. das 5-ghz-Netz nur gezielt für bestimmte Clients zu verwenden, während andere Clients bitte immer im 2,4er bleiben sollten. Das 2,4er deckt mein Haus zu 95% ab, das 5er nur ca. 15% und die ständigen Reconnects des Handys beim "im Haus herumgehen" ging mir einfach auf die Nerven. Technisch hätte ich es aber so verstanden, dass die Clients trotzdem unterschiedliche Netze sehen sollten und der Vorteil primär daran liegt, am Client nur ein Passwort eingeben zu müssen - statt für jede SSID einzeln ein PWD einzutippen.