Erster ganz kurzer Test mit der v2.2.1-rc1@768babd8 sieht gut aus.
Dauerping wurde nach dem flashen für die Zeit des Reboots unterbrochen und danach war er sofort wieder erreichbar.
Das Webinterface ist auch aufrufbar und in der blauen App sieht es auch gut aus.
Im ioBroker kommt bis jetzt per MQTT auch kein Müll an.
Alles in allem, sieht es nach ein paar Minuten super aus.
Ich beobachte es mal den Rest des Tages und Berichte. 
Dear Mike Tirouche,
Thank you for the information shared and for your efforts!
We have risen an issue now with the developers.
We will let you know as soon as we have news from their end.As of the moment, keep the devices running 2.1.8v.
Thank you for your time!
Best Regards,
Shelly Support Team
Hab ne Antwort vom Support bekommen der Hoffnung macht. Scheinbar ist es ein Bug, zumindest haben sie es an die Entwicklung gegeben.
Poste später die Nachricht, bin nur gerade unterwegs.
Ich habe nie behauptet, dass AVM fehlerfrei ist. Die haben genug Probleme.
Du hast aber aufgrund von glaub drei Leuten die AVM nutzen direkt beschlossen, dass es an AVM liegt weil Du das Problem nicht hast und kein AVM nutzt.
Ich will mich wirklich nicht streiten und vielleicht haben wir beide auch einfach falsch reagiert oder uns unvorteilhaft ausgedrückt.
Devil Ich hab ein detailliertes Ticket aufgemacht, inkl. aller Logs die man haben wollte. Ich finde es in der IT immer mehr als schräg wenn jemand eine Software oder eine Firmware herausbringt, etwas nicht geht und man dann direkt mal die Schuld auf einen anderen Hersteller schiebt. Erlebe ich zu oft im Beruf.
Der Firstlevel in Sofia ist auch nicht mehr als Checklisten abarbeiten.
Ich mache ein Ticket auf mit der Erklärung, dass mit FW > 2.1.8 keine brauchbare Verbindung mehr möglich ist.
Die erste Reaktion: mach uns Logfiled mit der betroffenen Version…
Es wurde kein Stück darauf eingegangen, dass es sich bei dem Problem darum handelt, dass das Gerät nicht mehr erreichbar ist.
Mag sein, dass AVM im Weltmarkt keiner der big Player ist aber wenn ich Komponenten wie Shelly für den EU und D Markt verkaufe, dann Teste ich auch mit den dort am meisten verbreiteten Netzwerkkomponenten.
Devil mag sein, dass es nur im Zusammenhang mit AVM Komponenten auftritt aber das ist dann trotzdem ein Shelly Problem. Zum einen ist AVM einfach mal bei weitem der Marktführer in Deutschland und zum anderen funktioniert alles bis einschließlich 2.1.8 und dann nicht mehr. 
apreick ich behaupte es geht auch ohne Demontage. War nämlich zu faul, meine Fritte steht im Keller. Musste einfach ganz oft probieren den Downgrade befehl zu schicken bzw. direkt nach dem drücken der Reset Taste ist mein TRV auch mit 2.2.0 immer für einige Sekunden erreichbar.
Maxler Sind sie auch dauerhaft erreichbar? Also nach dem es kurz gedauert hat bis sie aufgewacht sind?
Bei mir keine Chance. Nach dem Update sind sie kurz erreichbar und dann fast permanent offline, werden auch als offline in der Cloud angezeigt. Im ioBroker sieht man via MQTT auch massive Timeouts weil die Teile was senden und dann aufhören und nicht mehr reagieren. Downgrade auf 2.1.8 und alles läuft wieder sauber. Auch Werkreset hat keinen Unterschied gemacht.
Gerade eingebaut. War etwas eng in der Dose aber hat funktioniert, auch wenn ich mit Blut dafür bezahlt habe.
Blöde Frage, kann ich irgendwo konfigurieren, dass nach einem Druck auf den Taster der Rollo solange läuft bis ich noch mal drücke?
Aktuell muss ich gedrückt halten bis die gewünschte Position erreicht ist.
Ich hab auf Cover umgestellt und den Eingabetyp auf Taster gestellt.
Ok, vergesst die Frage.
Ich hab noch mal bei Taster bzw. Button im Webinterface auf Speichern gedrückt, jetzt funktioniert es.
Jo, hab ich gestern mit der 2.1.9 auch ca 5 mal gemacht, hat aber genau nichts gebracht. Außer das ich nach dem Downgrade alles wieder neu konfigurieren musste.
Devil Bin offen für andere Theorien.
Fakt ist, dass nach dem Update die Latenz brutal in die Höhe steigt und sobald ich schaffe nen Downgrade durchzubekommen netzwerktechnisch instant alles wieder super ist.
Gerade noch mal probiert weil der Support von der 2.1.9 status, settings und debuglog haben will, haha, wenn das Gerät nicht erreichbar ist.
Hab es jetzt mit viel probieren hinbekommen. Wenn das Problem bei mir auftritt, dann kann ich den TRV immer für einige Sekunden erreichen, nach dem ich den Reset Knopf kurz gedrückt habe.
Ich könnte mir vorstellen, dass die Firmware nen Bug hat und die Sendeleistung des WLAN Moduls gegen 0 senkt.
Hab mal ein Ticket eröffnet, da der Fehler zumindest bei mir zu 100% reproduzierbar ist.
Ok, es wird immer seltsamer.
Jetzt hab ich über http://IP/ota?url=http://archive.shelly-tools.de/version/v2.1.8/SHTRV-01_build.gbl nen downgrade angestoßen, hat ewig gedauert bis der Befehl mal durchging.
Irgendwann kam die Seite mit dem Text für den downgrade. Dort wurde als alt und neu die 2.2.0 angezeigt und sofort nach dem die Anzeige da war, war der TRV wieder normal erreichbar und hat jetzt die 2.2.0.
Zu früh gefreut, ist wieder nicht erreichbar.
Keine Ahnung was die mit WLAN angestellt haben aber seit >2.1.8 ist das echt gruselig
Noch mal nen Downgrade gemacht und alles ist shiny. Webinterface ist aufrufbar und das TRV ist auch pingbar.
Über das Webinterface (Uhrzeit passt) das Upgrade angestossen, nach dem Reboot und der kurzen Anzeige von CL im Display ist der TRV noch ein paar mal pingbar und dann weg.
Ein Dauerping zeigt, dass 20-50 Pings (mit glück) mal einer beantwortet wird aber mit eine mega Latenz. Webinterface ist auch nicht aufrufbar.
Update => besser direkt in der WebUI
Dann sieht man auch gleich ob er wach ist und die Uhrzeit oben rechts funktioniert
Manchmal auch die Seite öfters anstoßen, wie gerade bei mir 2x wiederholt bis auch die Uhrzeit stimmt
Scheint das gleiche Spiel wie gestern zu werden. Nach dem ersten Versuch erreiche ich den TRV nicht mehr. Darf dann wieder versuchen per HTTP downzugraden und hoffen das der Befehl mal durchgeht.
Hab nur Angst weil es gestern genauso angefangen hat. 😂 Ich drück noch mal drauf.
Jetzt kommt die Meldung „Das Gerät konnte nicht aktualisiert werden…“
Ich soll überprüfen ob das Gerät mit dem Internet verbunden ist.
War auch mal mutig und hab auf die 2.2.0 aktualisiert. Also zumindest versucht hab ich es.
Hab über die blaue App das Update angestoßen und kurz danach war der TRV auch mal offline, hat wohl neu gestartet.
Ich erreiche ihn noch und er bietet mir wieder das 2.2.0 an und sagt er wäre auf stand 2.1.8. genauso hat es gestern auch angefangen.
Bei mir im Prinzip das gleiche Verhalten, nur das ich mir die Mühe mit anschrauben und zum Router gehen gespart hab. Ich hab per Dauer Ping gesehen, dass er ab und zu erreichbar war mit einer Latenz als ob er am Mond liegen würde. Hab einmal ganz kurz das Webinterface gesehen und da wurde ein ganz schlechter WLAN Empfang angezeigt. Im ioBroker kam per MQTT nur noch Müll an.
Nach downgrade auf die 2.1.8 funktioniert bei mir alles wieder.
Ziemlich peinlich was da abgeliefert wurde.
Funktioniert MQTT bei jemandem nach dem Update noch sauber?
Danke das war die Rettung nach mehreren Versuchen kam der Aufruf mal durch und der Downgrade lief an, seit dem ich der TRV wieder zuverlässig erreichbar und schickt auch keinen Müll mehr via MQTT.
Blöderweise muss ich jetzt wieder alle Einstellungen vornehmen, inkl. Heizpläne.
Gerade das 2.1.9 in der stable auf einen meiner TRVs installiert und seit dem ist er permanent weg aus dem WLAN. Manchmal erreiche ich ihn wieder kurz und dann isser wieder weg.
Per MQTT kommt im ioBroker nur misst an. Hoffe mal, dass es nur ein Einzelfall ist.
Wie bekomm ich jetzt ne 2.1.8 zum downgraden?
Auch Factoryreset bringt keine Besserung.
Ich verbinde mich im AP Mode mit dem TRV und versetze ihn dann in den Client Mode und geb ihm meine WLAN Daten mit. Danach startet es neu und verbindet sich nicht mehr richtig mit dem WLAN.
Ein Dauerping sieht auch übel aus:
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.179: Bytes=32 Zeit=1798ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.179: Bytes=32 Zeit=3955ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.179: Bytes=32 Zeit=1681ms TTL=255
Antwort von 192.168.178.179: Bytes=32 Zeit=2466ms TTL=255
Antwort von 192.168.178.179: Bytes=32 Zeit=2432ms TTL=255
Antwort von 192.168.178.179: Bytes=32 Zeit=2260ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.20: Zielhost nicht erreichbar.
Antwort von 192.168.178.20: Zielhost nicht erreichbar.
Antwort von 192.168.178.179: Bytes=32 Zeit=127ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.Da scheint man effektiv meinen TRV gekillt zu haben.