Beiträge von hausbenutzer

VPN/Proxy erkannt

Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.

  • 1.10 Final

    @Dimitar(Shelly team) ,

    another update to my observations after 18h using "v1.10.0-geba262d" at

    33 Shellys (4x 3EM, 4x RGBW2, 5x 1PM, 2x Plug S, 3x i3, 15x 2.5). AP Roaming disabled. Static IPs. MQTT @ iobroker,
    3x APs as mesh (Fritzbox 7590, Fritzbox 7530, Fritz!Repeater 3000 - each with latest firmware).

    21x WLAN deauthentication (reason 0x0003) initiated by *one specific* Shelly Hardware with count as follows:
    3x Shelly 2.5 (+1x retry)
    3x Shelly Plug S
    3x Shelly 1PM
    2x Shelly 2.5 (+1x retry)
    2x Shelly RGBW2
    2x Shelly 2.5
    1x Shelly RGBW2 (+1x retry)
    1x Shelly 2.5
    1x Shelly 2.5
    1x Shelly 2.5
    1x Shelly 2.5
    1x Shelly 3EM

    11x WLAN disassociation (reason 0x0002) initiated by an AP,
    3x WLAN deauthentication (reason 0x0002) initiated by AP,
    8 different Shellys rebootet at least once.

    So far no complete lockups of Shelly 1PM with temperature addon (as happened with ALL versions alpha/beta/final firmware before) - but observation time is too short to be sure.

    Result: Enough room for improvements.

    Externer Inhalt static.xx.fbcdn.net
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

  • Allterco braucht Unterstützung

    Heute morgen traute ich meinen Augen nicht:


    Nach so vielen Monaten instabiler Verbindungen (und Lockups) meiner (inzwischen 39) Shellys (mit nahezug täglichen Firmware-Updates) sehe ich in den Logfiles meiner 3 Access Points über Nacht 10h OHNE eine einzigen Verbindungsverlust.
    Verwendung fand dabei auf allen Shelly 2.5, Plug S & 1PM die Version "v1.10.0-rc4-1".

    Inzwischen liegt "v1.10.0-rc4-20" (vom 11-Mar-2021, ca 14:00 Uhr) vor, die ich soeben auch flächendeckend installiert habe. Beobachte jetzt weiter die Live-Logs meiner 3 APs und werde nach 12h mal resümieren. Ich bin erstmalig wieder zuversichtlich...

    Update (13.03, 9:30 Uhr)

    Die Zuversicht weicht den Ergebnissen nach 24h Betrieb mit "v1.10.0-rc4-20":

    • 21x hat ein Access Point den Shelly rausgeschmissen (+11x die Nachricht als Retry geschickt)
    • 23x hat sich ein Shelly aktiv selbst abgemeldet
    • 4x Shellys sind jeweils mindestens einmal rebootet.
    • 1x Shelly befindet sich im "complete lockup" (Shelly 1PM - dessen Hardware ich zuvor sogar extra wechselte, um dieser Situation zu begegnen)

    Jetzt habe ich "v1.10.0-rc4-32" ausgerollt und beobachte weiter.


    Bleiben wird das ungute Gefühl, dass bei zukünftigen Entwicklungen rund um die Firmware jeder Wechsel von eingebundenen Bibliotheken oder des zugrunde liegenden MoongooseOS (wie jetzt geschehen) potenziell erneut zu massiven Instabilitäten führen könnten, die alle Shelly Kunden dann lange leidvoll ertragen müssen.
    Wenn Anbieter generell diese Problematik nicht nachhaltig durch geeignete Qualitätssicherung in den Griff bekommen, kommt jegliche SmartHome-Lösung niemals aus der Bastel-Ecke heraus. Für "Nur-Nutzer---nicht-Techniker" sind schließlich stabile Lösungen ohne plötzliche Kinderkrankheiten für breite Akzeptanz unabdingbar - ich hoffe für Allterco, dass es hier eine Lernkurve gab.

  • Allterco braucht Unterstützung

    @Dimitar(Shelly team)

    Another update to my observations using "v1.10.0-rc3-1-g0d5587d92" (from 06th-Mar) after 12h of usage.

    General setup: 3x access points as mesh (AVM Fritz!Box 7530, Fritz!7590, Fritz!Repeater 3000 - all use same SSID, fixed channels and latest firmware).
    All Shellys (16x Shelly 2.5, 3x Shelly 1PM - two of them using temperature addon, 2x Shelly Plug S) use static IP, no cloud but MQTT with iobroker as master. Almost all Shellys have RSSI > -70.

    119(!) times disconnections initated from Shelly (PLUS 51x as re-transmission of them).

    Disconnection-Code = 0x0003.

    60(!) times disconnections initated from APs with Disconnection-Code = 0x0002.

    1 times disconnections initated from APs with Disconnection-Code = 0x0022.

    5 Shellys rebooted at least once (low uptime).

    2 Shelly 1PM locked up (power off required to restart) - only the two ones using temperature addon.

    Conclusion: Situation is still instable. None of my additional Shellys (4x Shelly RGBW2, 3x i3, 1x 3EM - all using latest official firmware release) have problems during same time at all.

    Allterco: Please investigate further to get the newer firmware as stable as the older ones to ensure that customers with "the wrong access point" don't get crazy - thanks a lot!

  • Allterco braucht Unterstützung

    ...neue Chance für eine finale Lösung:

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    @Dimitar(Shelly team) 

    Results of my observations during 12h of WLAN monitoring on all APs on 23. Feb:

    Shelly Firmware "v1.10.0-rc2-46-g093eb4327-master".
    Testing Environment: 3x AVM APs (Fritzbox 7590, 7530, Fritz!Repeater 3000) - meshed with same SSID. All APs are setup to have fixed channels, signal and service is always stable / available.

    Updated Test-Shellys: 16x Shelly 2.5, 2x Shelly PlugS, 3x Shelly 1PM.

    RSSI of each one between -45 dBm to -70 dBm. Shellys "AP Roaming" is not activated.

    WLAN log reveals:
    52 times (!) one of the above Shellys actively requested "Deauthentication":

    Reason code: Deauthenticated because sending STA is leaving (or has left) IBSS or ESS (0x0003)

    They always reconnected afterwards automatically without problems.

    A few Shellys rebooted (uptime was reset):

    1x Shelly 2.5.
    There was the following entry at WLAN-logs just before reboot time: Deauthentication initiated by Shelly. Reason code: Deauthenticated because sending STA is leaving (or has left) IBSS or ESS (0x0003)

    2x Shelly 1PM.

    For one of them there was the following entry at WLAN-logs just before reboot time:

    Deauthentication initiated by AP. Reason code: Disassociated because excessive number of frames need to be acknowledged, but are not acknowledged due to AP transmissions and/or poor channel conditions (0x0022)

    For the other there was the following entry at WLAN-logs just before reboot time:

    Deauthentication initiated by Shelly. Reason code: Deauthenticated because sending STA is leaving (or has left) IBSS or ESS (0x0003)

    Conclusion:

    Still a lot of Shelly reconnects initialized by the Shellys themself. A few Shelly reboots but so far no lockups. Room for further stability improvements, so... ;)

  • Allterco braucht Unterstützung

    Zitat

    Dear All
    We have stable version for test:

    Shelly2.5
    http://repo.shelly.cloud/firmware/dimo/SHSW-25-1MVNV.zip

    additional optimization about the load and power consumption, which give more resources device to handle network requests.

    @Dimitar(Shelly team)

    Installed. Monitoring of AP (AVM-Fritzbox and -Repeater) enabled.
    Is there Firmware to test for Shelly 1PM, too? This type of Shelly makes most problems here...
    Where do "the logs" to to? Can I see them or just Allterco only?

  • Allterco braucht Unterstützung

    Zitat von Seven of Nine

    probably iobroker auto-update.

    Very good indication, indeed:

    I was not aware of (or just forgot about) this option at the iobroker shelly-adapter, which seems to be active by default (seee attached screenshot).

    Disabling it solves the magic "reverting back to stable firmware" problem. Thanks Seven of Nine for pointing this out!

    Only strange thing is: This "automatic update" (in this case a downgrade to latest stable) did not happen for my three Shelly 1PM (after installing RC2 to them) - thats why I did not think about the iobroker-adapter causing it.

  • Allterco braucht Unterstützung

    Zitat

    Soon we will have firmware with logs which can show what happens.

    @Dimitar(Shelly team)

    Hi Dimitar, I just setup the first Shellys 1PM using "v1.10.0-rc2-9-g3ce6aa617-1530-debug-log-latest". Where do the logs to to? Anything I can see myself?

    I also tried to Update Shelly 2.5 to RC2-debug-log, too. But it failed as before:
    First it seems to work (updated version is display on webinterface and via MQTT@iobroker) but it switches back to v1.9.4 after 1 minute of running automatically. Still no clue, why...

  • Allterco braucht Unterstützung

    Hier erste Beobachtungen an einem Shelly 1PM nach dem Update auf v1.10.0-RC2 nach 4h Betrieb und WLAN-Mitschnitt via Wireshark:

    Der Shelly ist immer noch erreichbar (über das Webinterface und er meldet via MQTT). Freue mich über diese "Selbstverständlichkeit".

    Aber: Während dieser Zeit wurde die Verbindung zum WLAN bereits 3x neu aufgebaut (und gar ein Neustart durchgeführt? Die über MQTT gesendete Uptime entspricht genau der Zeit seit Verbindungsneuaufbau ...).
    AP = "Fritz! Repeater 3000" mit "Qualcomm IPQ4019, MU-MIMO: 2x2,4 GHz +" 2x5GHz ".
    RSSI ca. -60 dBm. Statische IP, inkl. DNS & MQTT.

    Wireshark zeigt, dass der Shelly wieder mal selbst/aktiv die Verbindung beendet hat. Immerhin hat bisher nicht der AP die Verbindung von sich aus beendet, wie es oftmals vor dem Update passiert ist.

    Wireshark: "Deauthenticated because sending STA is leaving (or has left) IBSS or ESS (0x0003)"
    - siehe Beispiel-Screenshot.

    Ich werde das bis morgen weiter verfolgen und informieren...

    Tag nach dem Update

    Schlechte Nachrichten zur Firmware v1.10.0-RC2 in Bezug auf die Netzwerkprobleme:
    Nach 7 Stunden und 24 Minuten Überwachung der WLAN-Verbindungen (AP: siehe Beitrag oben; zuletzt gemeldeter RSSI -56 dBm) forderte der Shelly 1PM eine WLAN-Trennung an und reagierte nicht auf erneute Verbindung - und stoppte zuzätzlich seine Arbeit insgesamt (keine temperaturbasierte lokale Aktion mit dem Addon-Modul).

    Die letzten mit Wireshark extrahierten Aktivitäten sind im beigefügten Screenshot 2 zu sehen.

    Da wartet also immer noch Detail-Arbeit auf Allterco - zumal ich bisher KEINEN meiner rund 20 Shelly 2.5 überrreden konnte, das Update auf RC2 dauerhaft einzuspielen: Update startet (via Webinterface oder ota-URL), Webinterface zeigt kurz Erfolg an, um nach wenigen Sekunden wieder die alte Version anzuzeigen, bei der es auch bleibt.

    Ein zweiter Shelly 1PM (mit RC2) am selben AP (siehe oben) hat aktuell überhaupt keine Probleme: Während der letzten 20 Stunden wurde keine WLAN-Verbindung zurückgesetzt. Läuft also bisher bei RSSI -73 dBm stabil. Spekulation: Können sich hier Bauteiltoleranzen so auswirken?

    Update 11.02. / 9:48 Uhr:
    Allterco CEO Dimitar Dimitrov schrieb mir inzwischen:
    Thanks will check what happens soon. We may provide you firmware with logs.
    Ja, damit könnte endlich nachvollzogen werden, was auf Seite des Shellys passiert. Ich bleibe dran.

  • Allterco braucht Unterstützung

    Servus zusammen,

    habe das Update auf v1.10.0-RC2 für meine drei Shelly 1PM jetzt vollzogen (die haben die meisten WLAN-Probleme trotz RSSI >-65). Laufen seit 2h damit, werde das WLAN-Verhalten in den nächsten Tagen beobachten.

    Jedoch ließ sich keiner meiner zwanzig Shelly 2.5 auf RC2 bringen: Egal ob mit angebotenem Update-Link via Web-Interface, noch mit OTA-URL direkt aufs RC-Archiv.
    Das Update startet zwar offenbar und der Shelly ist nach dem erforderlichen, automatischen Reset wieder (via Webinterface) erreichbar und es wird im Bereich Firmware die neue Version kurzzeitig sogar angezeigt (!) - einige Sekunden später wechselt die Anzeige jedoch wieder auf den Stand vor dem Update (v1.9.4) und bleibt dabei.

    Ja, Browser-Cache sind geleert, das Update im Browser-Private-Mode durchgeführt worden und der WLAN-Empfang war ausreichend (RSSI > -65). Habe Dimitar bereits darauf hingewiesen, mal schauen was zu tun ist.

    Gruß

  • Firmware 1.10 rc1 ist da ...

    Zitat von Schubbie

    Irgendwie kommt mir der Text bekannt vor, gucke ich auf das Datum, dann weiß ich auch warum.

    Yep, ist nicht der neueste FB-Post. Aber in der Tat ist diese Info in diesem Forum wohl so noch nicht offiziell platziert worden - siehe Post von Charles63 .

    Ich leite jedoch aus dem FB-Post die Erkenntnis ab, dass Ursache und Lösung für die WLAN-Probleme eher weniger auf Seite der marktüblichen APs/Router (und deren Einstellungen im Einzelnen), als vielmehr in der Verwendung eines "neuen" SDK zur Ansteuerung der Shelly WLAN-Chips liegt. Daher kann man als Shelly-Kunde (außer unfreiwilliger Beta-Tester zu sein und Feedback senden) hauptächlich abwarten, bis der Hersteller das Gesamtprodukt wieder im Griff hat. :)

  • Firmware 1.10 rc1 ist da ...

    Zitat von Dreibein

    ...

    hast du das einem der Shelly-Entwickler geschickt? Ich weiß nicht, ob und wenn ja, wie häufig die hier mitlesen. Denke aber, dass das eine wertvolle Hilfe für sie ist.

    ...

    Habe jetzt mal ein Ticket eröffnet (T-21053506) aber derzeit keinen unmittelbaren Kontakt zu einem Entwickler. Bin ja eigentlich nur Shelly-Nutzer/-Kunde, der dem Thread-Aufruf "Allterco braucht Unterstützung" gefolgt ist. Natürlich hoffe ich doch, dass mein Feedback gelesen wird und nützlich ist bei der Problem-Beseitigung - damit alle mehr Freude und weniger Frust mit dem Produkt haben.

    P.S.: Das obige Ticket wird jetzt vom Allterco-Entwickler Dimitar Stanishev bearbeitet. Hatte gerade kurz Kontakt mit ihm.

  • Firmware 1.10 rc1 ist da ...

    Servus zusammen,

    ich konnte zwei Shelly 1PM updaten auf v1.10.0-RC1 und habe ihr Verhalten im WLAN ausgewertet. Leider ist einer von beiden inzwischen wieder "stehen geblieben" und reagiert nicht mehr. Siehe meinen Post dazu für Details.

    Desweiteren versuchte ich mehr als 20x bei diversen Shelly 2.5 die angebotene Beta v1.10.0-RC1 aufzuspielen:

    • Durch Update-Klick über deren Webinterface,
    • durch Aufruf der entsprechenden ota-REST-URL,
    • durch ota-URL mit herunter geladener und lokal platzierter Beta-Firmware...

    Nichts hat letztendlich geklappt. Es scheint mir so, als ob die Beta-Version zwar kurzzeitig aufgespielt wurde (gemäß Shelly-Status in iobroker zu Version), aber beim anschließenden automatischen Neustart wieder durch das Release 1.9.4 ersetzt wurde. Seltsam.

  • Allterco braucht Unterstützung

    Andere Setups: siehe oben.

    Setup 4:

    Beobachtung 4:

    Shelly läuft viele Stunden durch. Plötzlich ist er jedoch weder über sein Webinterface erreichbar, noch sendet er Daten per MQTT.

    Ursache 4:

    Aus dem Mitschnitt am WLAN-AP ergibt sich, dass der Shelly seinen Lease am AP (EAPOL) spontan nicht mehr erneuert (er reagiert eben nicht mehr) und deshalb vom AP rausgeschmissen wird.

    Code
    7313    12:31:31,584555    AVMAudio_4b:4d:0b    Espressi_43:88:d8    EAPOL    163    Key (Group Message 1 of 2)
7318    12:31:31,610390    Espressi_43:88:d8    AVMAudio_4b:4d:0b    EAPOL    131    Key (Group Message 2 of 2)
7432    12:41:31,797254    AVMAudio_4b:4d:0b    Espressi_43:88:d8    EAPOL    163    Key (Group Message 1 of 2)
7436    12:41:31,825643    Espressi_43:88:d8    AVMAudio_4b:4d:0b    EAPOL    131    Key (Group Message 2 of 2)
7626    12:51:32,016829    AVMAudio_4b:4d:0b    Espressi_43:88:d8    EAPOL    163    Key (Group Message 1 of 2)
7651    12:51:33,028116    AVMAudio_4b:4d:0b    Espressi_43:88:d8    EAPOL    163    Key (Group Message 1 of 2)
7657    12:51:34,039086    AVMAudio_4b:4d:0b    Espressi_43:88:d8    EAPOL    163    Key (Group Message 1 of 2)
7664    12:51:35,050007    AVMAudio_4b:4d:0b    Espressi_43:88:d8    EAPOL    163    Key (Group Message 1 of 2)
7669    12:51:36,050643    AVMAudio_4b:4d:0b    Espressi_43:88:d8    802.11    26    Disassociate, SN=259, FN=0, Flags=........ Reason code: Previous authentication no longer valid (0x0002)

    Anschließend meldete der Shelly sich wieder selbst neu am AP an, um nach einigen Betriebsstunden sich selbst beim AP wieder abzumelden (warum auch immer):

    Code
    8615    20:35:49,533041    Espressi_43:88:d8    AVMAudio_10:a8:61    802.11    26    Disassociate, SN=1524, FN=0, Flags=....R...
Reason code: Disassociated because sending STA is leaving (or has left) BSS (0x0008)

    Anschließend meldete der Shelly sich wieder selbst neu am AP an, wurde dann aber einige Stunden später vom AP erneut abgemeldet - diesmal hat der Shelly zuviele Pakete unbeantwortet gelassen.

    Code
    12393    04:59:09,263512    AVMAudio_10:a8:61    Espressi_43:88:d8    EAPOL    163    Key (Group Message 1 of 2)
12395    04:59:09,270995    Espressi_43:88:d8    AVMAudio_10:a8:61    EAPOL    131    Key (Group Message 2 of 2)
12423    05:01:40,242213    AVMAudio_10:a8:61    Espressi_43:88:d8    802.11    26    Deauthentication, SN=259, FN=0, Flags=........
Reason code: Disassociated because excessive number of frames need to be acknowledged, but are not acknowledged due to AP transmissions and/or poor channel conditions (0x0022)

    Nach der letzten Abmeldung meldet sich der Shelly nicht mehr selbst beim AP an und bleibt unerreichbar.

    In Summe ist also auch mit der Beta-Firmware alles wie zuvor (WLAN instabil).

    Admin Ich denke, da sollte Dimitar nochmal drüber schauen....

  • Allterco braucht Unterstützung

    Setup 1 & 2 - siehe oben.

    Setup 3:

    Der hier betrachtete Shelly ist zum hier betrachteten Zeipunkt über sein lokales Webinterface (Port 80) nicht erreichbar (Webseite wird nicht aufgebaut). Aber: Er sendet munter weiter via MQTT Status-Updates und ist darüber problemlos schaltbar / anfragbar.

    Im zugehörigen WLAN-AP (Fritz-Repeater) wird er aktuell als aktiv geführt.

    Der folgende Wireshark-Ausschnitt (16s lang) des Authorisierungsverkehrs an der WLAN-Schnittstelle zeigt, dass der Shelly immer wieder irgendwann auch auf mehrfache Anfrage des APs nicht mehr reagiert und dieser ihn damit abmeldet und zur Neuanmeldung zwingt. (Zeilen 9, 22, 46: "Disassociate").

    Wie bereits für Setup 1&2 unter "Beobachtungen" berichtet, meldet sich der Shelly darüber hinaus immer mal wieder selbst aktiv & spontan vom AP ab (von ihm angefordertes "Disassociate"). Darauf folgt unmittelbar die Neuanmeldung.


    Ca. 90 Minuten nach der oben beschrieben Nicht-Erreichbarkeit des Shelly-Webinterfaces war dies wieder abrufbar. Weitere 10 Minuten später wieder nicht mehr. Wie gesagt: Per MQTT läuft er problemlos gesteuert von iobroker.

    Statistik dieses Shellys für den erfassten Zeitraum "2021-01-21 16:54:15 bis 2021-01-23 19:38:33":

    "Disassociate" ausgehend vom Shelly 2.5 = 101 Mal, davon 61 Mal als "Retry".

    "Disassociate" ausgehend vom AP (Fritz) = 190 Mal, davon 14 Mal als "Malformed Paket".

    Selbst wenn man alle "Retrys" und "Malformed Pakets" abzieht, ergeben sich 216 Verbindungsabbauten innerhalb von gut 50h - also im Mittel einer alle 14 Minuten.

  • Firmware 1.9.4 officially released

    Zitat von Loetauge

    hausbenutzer schau einfach hier: RE: Allterco braucht Unterstützung

    Das hatte ich bereits auf dem Schirm und in dem Thread meine Erfahrung gepostet. Danke.
    Dass du statt "WPA" eigentlich "WPA2 einstellen" gemeint hast, hast du ja bereits aufgeklärt - und damit wurde meine Empfehlung quasi auch überflüssig. Also kein Stress.

    Es wäre natürlich klasse, wenn Allterco die WLAN Anmeldung der Shellys soweit in den Griff bekommt, dass sie ihren Kunden nicht allzu lange dazu zwingt auf die zeitgemäße und sichere WLAN-AP-Konfiguration mit "WPA2 + WPA3" zu verzichten. Wenn durch aktive Zuarbeit der Kunden schneller herauskommt, wo die Ursachen liegen - umso besser :-)

  • Firmware 1.9.4 officially released

    Zitat von Loetauge

    Ich meinte natürlich WPA2(CCMP), aber deine Empehlung ist mir egal, ich will nur helfen. Alterco sagt "nur WPA2 einstellen!" Es wird niemand weiter helfen wenn die Ratschläge nicht angenommen werden!

    Inwieweit Dünnhäutigkeit hilft, weiß ich nicht genau.
    Aber WPA2 allein ist sicher dauerhaft ok. WPA kurzzeitig auch. WPA allein dauerhaft eher weniger - man lässt seine Haustür ja auch nicht fortan offen, wenn sie manchmal klemmt...

    Allterco wird's schon herausfinden, wenn die Benutzer genug Meldung machen. :-)