Beiträge von 1080p

    So, in einem eigenen Gastnetzwerk laufen die Shellys ebenfalls problemlos seit 48h. Der Zugriff aus dem Hauptnetzwerk auf Geräte in Gastnetzwerk ist hakelig, über den Funkmast und die Cloud ist aber alles in Ordnung.

    Ich würde also feststellen, dass nicht der Router an sich das Problem ist, sondern womögliche eine Wechselwirkung mit anderen WLAN Clients. Als Tips würde ich bei ähnlichen Problemen folgendes vorschlagen:

    1. Bei Dual- oder Tri-Band Routern die Netzwerke einzeln benennen. Keine Sonderzeichen oder Umlaute in die SSID und auch nicht ins Passwort. Wenn das nicht hilft ...

    2. 2,4GHz Gastnetzwerk anlegen, in dem dann nur die Shelly Produkte unter sich arbeiten. Wenn das auch nicht hilft...

    3. Einen schlichten Range Extender oder einen älteren Router als Access Point benutzen, in dem dann nur die Shellys werkeln.

    Ich denke, die Chancen stehen gut, damit alles zum Laufen zu bekommen.

    Das stimmt, die Möglichkeiten an Einstellungen an dem Router sind enorm! Allerdings habe ich die Werkseinstellungen nie grundlegend verändert und habe auch seit nunmehr 2 Jahren nie Probleme gehabt, weder im 2,4GHz noch im 5GHz Netz.

    Hier ist ein Facebook Post aus der Shelly Support Group, wo von ganz ähnlichen Problem berichtet wird: https://www.facebook.com/groups/ShellyI…55627401203270/

    Dort ist von Problemen mit den AC und den AX Routern von Asus die Rede.Ein Nutzer mit exakt meinem Router hat genau das gleiche erlebt: "After random time (1hour somethimes 6h) all devices are unavailable. I tried many configuration of 2.4GHz radio but nothing help."

    Eine ausführliche technische Erklärung für allgemeine Probleme dieser Art ist hier zu finden: https://dongknows.com/airtime-fairness-explained/

    Soweit ich es verstehe, sind die Shellys mit ihrem alten n/g/b Wifi Standard generell nicht sehr kompatibel zu modernen Wifi 6 (ax) Routern. Mit den inkompatiblen älteren Router mit ESP8266-Chipset hat das nichts zu tun. Das Fazit bleibt: Helfen tut in jedem Fall ein Access Point, der bestenfalls nicht up-to-date ist. Ein älterer Router oder wie in meinem Fall ein billiger Extender scheinen eine gute Wahl zu sein... auch wenn zusätzliche Netze grundsätzliche nicht so toll sind (Interferenzen & co.).

    Was ich aber noch ausprobieren werde, ist die Einrichtung eines 2,4GHz Gastnetzwerks am Asus Router, über den dann nur die Shellys laufen. Werde berichten, wie es damit lief.

    Nachdem die Probleme bereits offensichtlich waren, hab ich die Beta Version getestet. Als keine Besserung zu erkennen war, hab ich dann wieder auf den aktuellste Release gedowngraded.

    Ein Firmware Upgrade am Router hat leider auch nichts geändert, ABER: Seit 15 Stunden laufen jetzt alle 3 Plugs ohne zu Murren über nen Access Point. Ich berichte morgen nochmal, ob es dabei geblieben ist, dann wäre wohl eindeutig mein Router (oder dessen Einstellungen) das Problem.

    So, kurzes Feedback.

    Der dritte Plug ist installiert und läuft bisher ohne Probleme. Alle Plugs sind jetzt mehr als 5m vom Router entfernt., RSSI -55 bis -80

    Bei den beiden ursprünglich installierten Plugs hab ich wieder die letzte Firmware aufgespielt. Binnen ca. 5 Stunden sind diese beiden Plugs wieder aus dem WLAN geflogen! Die blaue LED geht 8x kurz aus und dann einmal lang aus (ca. 3 Sek.). Denke, das ist der STA-Modus, also die Verbindung zur Cloud verloren. Durch herausziehen aus der Steckdose und wieder einstecken hat sich der Plug schnell wieder erfolgreich mit WLAN und Cloud verbunden. Bei einem der Plugs habe ich jetzt den Debug-Log Modus aktiviert, mal sehen was da drin steht.

    Zwei Dinge sind mir noch aufgefallen:

    1. Die beiden Problem-Plugs sind in der Liste der Geräte meines Asus Routers mit einem "echten" Client-Namen zu finden (shellyplug-s-4022D889XXXX). Der heute neu installierte Plug taucht hingegen nur mit seiner MAC Adresse auf (40:22:D8:81:XX:XX).

    2. Beim heute installierten Plug habe ich während der erstmaligen Einbindung in der App einen individuellen "Device Name" vergeben. Diesen Namen konnte ich dann auch in den Setting wiederfinden.

    Bei den beiden anderen Plugs habe ich bei der erstmaligen Einbindung den Standard-Namen übernommen und erst später einen individuellen Namen vergeben. Dieser Name stand dann in der App, ich habe ihn aber in den Settings nicht sehen können. Dort war das Feld "Device Name" einfach leer. Evtl. verursacht das Probleme, bei einem der Plugs hab ich den Namen dort jetzt händisch eingetragen.

    EDIT, 2 Stunden später: Alle 3 Plugs sind rausgeflogen. Firmware Downgrade, Abstand zum Router (>RSSI) und Einrichtung des "Device Name" haben leider keine Änderung gebracht. Aus dem Debug-Log bin ich nicht schlau geworden, da mache ich noch einen zweiten Versuch.

    Es ist also naheliegend, dass doch irgendein Problem mit dem Router besteht. Ich habe jetzt einen 10€ Xiaomi Range Extender zum Access Point konfiguriert und einen Plug darüber verbunden. Werde berichten, ob die Verbindung so stabil bleibt.

    Meinem Router verpasse ich jetzt auch nochmal ein Firmware Update und habe zudem einen Auszug aus dessen Systemlogs gezogen. Ist recht spezifisch und passt eher in ein Asus Forum, vielleicht wird aber jemand schlau draus. Für mich liest es sich, als würde der Router den Plug rausschmeißen, weil er ihn nicht mehr erreichen kann. Nur warum?

    26 02:35:20 wlceventd: wlceventd_proc_event(491): eth5: Deauth_ind 40:22:D8:81:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-53

    Oct

    26 02:35:20 wlceventd: wlceventd_proc_event(527): eth5: Auth 40:22:D8:81:XX:XX, status: Successful (0), rssi:-53

    Oct

    26 02:35:20 wlceventd: wlceventd_proc_event(556): eth5: Assoc 40:22:D8:81:XX:XX, status: Successful (0), rssi:-53

    Oct

    26 02:35:20 wlceventd: wlceventd_proc_event(491): eth5: Deauth_ind 40:22:D8:81:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-53

    Oct

    26 02:35:20 wlceventd: wlceventd_proc_event(491): eth5: Deauth_ind 40:22:D8:81:XX:XX, status: 0, reason: Previous authentication no longer valid (2), rssi:-53

    Oct

    26 02:35:27 wlceventd: wlceventd_proc_event(527): eth5: Auth 40:22:D8:81:XX:XX, status: Successful (0), rssi:0

    Oct

    26 02:35:27 wlceventd: wlceventd_proc_event(556): eth5: Assoc 40:22:D8:81:XX:XX, status: Successful (0), rssi:-48

    Oct

    26 02:37:38 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 40:22:D8:81:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

    Oct

    26 02:37:38 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 40:22:D8:81:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

    Danke euch beiden.

    Ich habe die Reservierung der IP im Router wieder gelöscht und nur die im Shelly beibehalten. Der Router zeigt jetzt die IPs zu den Shellys nicht mehr als "manual" an sondern als "static". Mal schauen, wie es damit jetzt läuft. Der Router steht nicht auf der Liste der inkompatiblen Router.

    Als nächstes werd ich die Firmware nochmal downgraden auf 20220809-124506/v1.12-g99f7e0b. Auch den Betrieb über einen Access Point werde ich testen.

    Dass es Probleme mit Geräten geben kann, welche zu nahe am Router platziert sind, habe ich schon mehrfach gelesen. In der Realität konnte ich es aber nie bemerken, andere meiner Clients stehen praktisch unmittelbar neben dem Router.

    Ich habe heute noch einen weiteren Plug S bekommen und werde mal schauen, ob dieser sich ebenso verhält. Irgendwie wird es hoffentlich doch noch alles funktionieren und was den Betrieb als Messgerät am BKW angeht, werd ichs einfach ausprobieren und ggf. später auf einen Messsensor wechseln.

    MfG

    66er: Stefan, besten Dank auch dir für deine Antwort und danke für das Willkommenheißen.

    Mit Routern beschäftige ich mich schon immer wieder mal, wenn auch nur ganz oberflächlich. Ich kann z.B. Ports "forwarden", um einen Web- oder FTP-Server über ein NAS laufen zu lassen. Ich weiß auch, wie ich im Router einen DHCP-Bereich festlege/einschränke und wie ich IP-Adressen innerhalb des Routers reservieren (also fest vergeben) kann. Ein Grundwissen würde ich mit also schon zuschreiben.

    Wie gesagt: Das Einbinden ins Netzwerk und die (kurzzeitige) volle Kontrolle über die Shellys sind kein Problem. Mein zur Einspeise-Energiemessung missbrauchtes Plug S macht erstmal einen echt guten Job, es ist in dem Leistungsbereich scheinbar recht präzise. Und es schaltet auch die Szenen, solange beide Plugs mit WLAN/Cloud verbunden sind. Genau da liegt aber das Problem:

    Wengstens ein Plus S fliegt regelmäßig aus dem WLAN raus, ist einfach nicht mehr erreichbar. Das Symptom erinnert an Erzählungen von älteren AVM oder auch anderen Geräten, die eben nur eine gewisse Anzahl von Geräten (Clients) "handeln" können. Ich wäre aber erstaunt, wenn mein kleiner Haushalt davon betroffen wäre.

    Deine vielfältigen Infos zu den Geräten und Netzwerken hab ich nochmal überflogen. Das klingt auch alles gut und korrekt, aber mein Fall ist denkbar einfach: Ein Router, zwei Plug S in unmittelbarer Nähe. Keine Repeater oder andere AP zu berücksichtigen.

    Erstmal hab ich alles nur mit der iOS App gemacht, hat auch für kurze Zeit funktioniert. Dann hab ich angefangen zu lesen.... ich hab viel gelesen! Erst hab ich im Router den DHCP Bereich eingeschränkt, von 192.168.x.2 bis 255 auf 192.168.x.2 bis 240. Vorher hab ich nachgeschaut, es wurde nie zuvor automatisch eine IP über -200 per DHCP vergeben = keine doppelte Vergabe von IPs. Dann habe ich den beiden Shellys jeweils IP Adressen außerhalb des neuen DHCP Bereichs reserviert, sagen wir -241 und -242. So hab ich es auch in der Konfiguration der Shelly Plugs eingetragen.

    Und dennoch läuft es nicht länger als ein paar Stunden ;(

    Die Beta Software hat nichts gebracht, im Gegenteil. Problem besteht weiterhin, beide Plugs sind grad erstmalig ausm WLAN geflogen.

    Devil: Danke für die schnelle Antwort, aber als Shelly-Anfänger würde ich mich freuen, vom Shelly-Profi eine etwas präzisere Aussage zu erhalten. Ich habe mich bemüht, alle Einsteiger-Tips hier im Forum zu lesen und die Suche hab ich auch bemüht.

    1. Die Auswertung der max. 600W meines BKW funktioniert wirklich gut. Das Display vom Wechselrichter zeigt sehr genau die gleichen Werte an wie der Plug S. Warum ist das Quatsch und weshalb wäre ein EM (mit +50A) sinnvoller? Für kleine PV-Anlagen werden Shelly Plugs vielfach erfolgreich genutzt!

    2. Wo muss die statische IP Adresse eingestellt werden, am Router oder am Shelly Plug? Sofern IP-Adressen außerhalb des DHCP-Bereichs genutzt werden sollen, hat man doch kaum eine Wahl(?). Oder würde der Router automatisch eine IP außerhalb von DHCP vergeben/akzeptieren, nur weil ich diese im Shelly eingegeben habe?

    3. Guter Empfang heißt, dass beide Geräte nur 3m bzw. 8m vom Router entfernt sind. Der nähere, der bisher immer rausgeflogen ist, hat -36 dBm. Der andere zeigt -66 dBm an.

    4. Das Ladegerät für kleine LiFePo Akkus nimmt AC max. 500W (DC 30A @ 14,6V), weit entfernt von den voreingestellten 1800W beim Plug S. Überhohe Einschaltströme gibt es auch nicht, zudem steigt der Plug schon aus dem WLAN aus, bevor erstmalig geschaltet wurde.

    Wie verhält es sich mit den Shellys eigentlich in alten Hütten, in denen noch eine "klassische Nullung" verlegt ist (Also Erdung auf dem Nulleiter)? Nen Shelly dürfte man hier garnicht mehr anstecken, soviel ist klar. Aber hätte es Auswirkungen auf den WLAN Empfang, wenn man es doch täte?

    Was wäre ein sinnvoller nächster Schritt? Debuggen oder Ticket eröffenen oder ...?

    Eines noch, weil ich vieles über Fritzboxen und die Anzahl an WLAN Clients gelesen habe: Mein recht aktueller mittelklasse Router (Asus RT-AX58U) hat derzeit nie mehr als 16 Clients im WLAN zu verwalten. Kein anderes Gerät hat je Probleme gehabt. Wäre das dennoch ein Punkt um nachzuschauen?

    MfG

    Hallo,

    seit wenigen Tagen nutze ich zwei Plug S. Einer ist an meiner Balkon PV Anlage angeschlossen und schaltet mit einer Szene den zweiten, über den ein Batterieladegerät angeschlossen ist. Als Router nutze ich einen Asus RT-AX58U. Dieser ist dem inkompatiblen RT-AC88U namentlich ähnlich, ist aber eine Generation jünger. Aktuell habe ich meine Repeater abgeschaltet, so dass die Plugs sich direkt am Router angemeldet müssen bei sehr gutem Empfang.

    Die Installation und das Einbinden ins Netzwerk hat gut funktioniert. Sowohl in den Plugs als auch in meinem Router habe ich feste IPs eingetragen, welche außerhalb des DHCP-Bereichs liegen. Über die App sowie über die IP im Browser sind beide erreichbar und steuerbar. Die Cloud hab ich ebenfalls bei beiden aktiviert.

    Nun das merkwürdige: Nach zumeist nur wenigen Stunden, manchmal auch erst nach einem Tag fliegt einer der beiden (immer derselbe, am Ladegerät) aus dem WLAN raus und ist nicht mehr erreichbar. Im Router wird er noch als verbundenes Gerät angezeigt, es ist aber keine Kommunikation mehr möglich, auch nicht via Ping. Nach einem Neustart des Routers ist er denn direkt wieder verbunden und funktioniert wieder.

    Wie kann es sein, dass ein Plug einfach nicht arbeitet? Ein factory reset hat keine Änderung gebracht. Beide Plugs haben die aktuelle Firmware drauf, den Eco-Mode hab ich deaktiviert, die ID ist jeweils 12-stellig. Kann ich von einem Defekt ausgehen oder hat noch jemand eine Idee? Es scheint, als würde ein Plug ohne ausreichend lange anliegende Last schlafen gehen und nicht wieder aufwachen.

    Danke und mfG

    Edit: Gerade eben habe ich gesehen, dass ein Firmware Update verfügbar ist, wenn auch nur eine Beta: 20221014-091054/v1.12.1-rc1-gd2158aa

    Damit werd ich es nochmal probieren. Macht es ansonsten Sinn, mal den Debug-Log zu aktivieren, kann das hier jemand auswerten? Oder dann lieber ein Ticket erstellen?