ja super .. jetzt habe ich den ganzen Inhalt nochmal zusammengefasst und beim Absenden kommt so eine tolle Meldung, dass ich vor kurzem bereits was abgesendet habe und der ganze Beitrag war weg 
Das schreibe ich sicher nicht nochmal alles zusammen !
Das ist ja ein echt toller Mechanismus, dass man zwischen den Beiträge eine Pause machen muss und dann der ganze Eintrag weg ist.
Seven of Nine : Ich habe das Thema unter "Shellies verlieren WLAN-Verbindung, rebooten ständig" ausgelagert.
Das klingt alles sehr ähnlich den Problemen, die ich auch habe. Shellies verabschieden sich vom MQTT-Broker, oder stehen auf einmal ohne IP im Netz und sind nur noch über Schalter ansprechbar oder (das machen die meisten) sie rebooten ständig.
Ich sag's nicht gerne, aber ich habe mal 2 meiner Sorgenkinder mit TASMOTA geflashed, die gleichen WLAN-Einstellungen verpasst .... und seit dem laufen sie klaglos durch. Damit ist für mich klar, dass es kein Hardwareproblem sein kann. Ich würde das mit der 1.9 gerne auch mal testen, denn eigentlich war es nicht mein Ziel, überall TASMOTA draufzuflashen...obwohl die Konsole dort schon sehr hilfreich ist und Analysen vereinfacht 
Geht die FW auch beim 2.5er bzw. gibt es hierfür auch so eine Version ?
@Seven of Nine : Danke - ich kann keinen Unterschied feststellen...
Das war die heutige Antwort vom Support - ich denke, wenn es absichtlich abgestellt wäre, müssten die es eigentlich wissen 
schau'n wir mal am Montag ....
On monday we will investigate what could be the issue and why localhost/reboot command does not trigger. We double checked and can confirm also.
We will engage our developers for this issue
Seven of Nine : Kannst du mir deine Konfig mal posten ?
Derzeit sind meine beiden "Lieblinge" wieder nicht per WLAN erreichbar - im Unifi-Controller habe ich sie verbunden... allerdings ohne IP-Adresse. Also Verbindung bekomme ich darüber aber ohne IP kann ich sie natürlich auch nicht ansprechen.
Hast du die SSID für die Shellies im 2,4 UND 5 GHz-Modus parallel laufen ?
Ich habe derzeit 18 Shellies in Betrieb. Alle haben die selben WLAN-Einstellung mit Ausnahme der IP-Adresse, die fest vergeben ist. Davon rebooten 14 täglich oder öfters - egal mit welchem meiner 3 Ubi-APs sie verbunden sind. 4 laufen stabil durch. Ich hatte ursprünglich den MQTT-Server von IP-Symcon im Verdacht, da der auf jeden Fall ein paar Mängel hat. Aber inzwischen sind alle mit dem MQTT-Server verbunden - auch die 4 stabil laufenden. Es spielt auch keine Rolle, wie gut die Verbindung ist, denn auch mit -53 db sind die Shellies nicht stabil. Ich habe auch schon Testinstallationen ohne MQTT gehabt, ich habe welche getestet ohne sie in mein Netzwerke einzubinden (mit Original-Adresse 192.168.33.1), aber auch da hatten manche ständig Reboots, andere sind stabil gelaufen. Einer von den 2.5ern, der jetzt durchläuft, war an anderer Stelle ständig abgeschmiert. Trotzt vieler Versuche konnte ich absolut keine Regel und kein Muster erkennen. Tja, und dann kommt noch dazu, dass 2 oder 3 Shellies einfach per WLAN nicht mehr erreichbar sind, aber per Schalter noch funktionieren. Daher mein Plan, diese per LongPress zu rebooten.
Da sich dies jetzt schon über Monate hinzieht, und weder hier im Forum noch beim Support sich eine Lösung für zumindest eines der beiden Problem ergibt, bin ich inzwischen schon genervt .... sorry, hat man wohl weiter oben gemerkt....
Ja, das freut mich natürlich riesig für dich, aber wenn dich nur deine Shellies interessieren, brauchst du ja hier keinen Kommentar abgeben
Ich habe das jetzt nochmal beim Support eingekippt. Ich möchte hierzu eine offizielle Aussage.
hm - bei der Action LongPress kann das doch aber nichts passieren, außerdem bleibt im höchsten Notfall immer noch Werksreset über den Knopf an der Rückseite. Die beim Support hatten gemeint, sie hätten es ausprobiert uns es hätte funktioniert 
....
So, habe bezüglich des Reboots per LongPress mehrfach mit dem Support Kontakt gehabt. Die meinten, es müsste funktionieren. Aber trotz Löschen und nochmaligem Eintrag (mit IP-Adresse - localhost sollte ich nicht nehmen) funktioniert das nicht. Leider ist das Thema bei denen damit erledigt.
.
Funktioniert es bei irgend jemand, dass er die Longpress-Funktion mit Reboot belegt ?
Die 6 sind nur meine Teststellung - 11 weitere sind im produktiven Umfeld und rebooten ständig 
aber ich habe noch keine nachvollziehbare Regel herausgefunden.
Ich habe das gleiche Problem mit dem internen MQTT-Server von IP Symcon. Ich stehe schon länger im Kontakt mit dem Shelly-Support, aber eine Lösung haben wir noch nicht. Ich teste gerade mit 6 unterschiedlichen Shellies in unterschiedlichen Konstellationen, davon laufen 4 sauber durch, die beiden anderen machen ständig Reboots.
Das mit dem Rate and Beacon habe ich bei meinem Controller nicht gefunden - alles andere ist gleich.
Welche Version hast du ?
Ich habe die Shellies in ein eigenes Subnetz verbannt. Das Gateway ist ein USG. DNS und DHCP gibt es dort keinen - daher fixe IP's.
sehr merkwürdig - ist doch ein ganz normaler HTTP-Request
daran liegt es eher nicht, denn es passiert bei allen Shellies - auch bei denen, an denen SW gar nicht angeschlossen ist. Der Support vermutet eher Netzwerkeinflüsse. Mir ist aufgefallen, dass dieser counter auch hochzählt, wenn ich gar keine Konfig geändert habe ... insofern fände ich ich eine offizielle Beschreibung der Tags hilfreich und könnte evtl. mein Augenmerk auf bestimmt Werte legen.
genau von dieser Seite rede ich - wegen ständiger Reboots meiner Shellys stehe ich schon einige Zeit im Kontakt mit dem Support und ich möchte gerne nachschauen, was die einzelnen Werte im Status bedeuten. Eine Erläuterung zu o.g. Wert habe ich bisher nirgends gefunden.... und einige andere auch.
Hallo zusammen,
ich suche verzweifelt nach einer Beschreibung verschiedener Status-Tags (u.a. cfg_changed_cnt), die in der API-Dokumentation leider fehlen.
Kann mir jemand sagen, wo ich die finden kann ? Müsste an dieser Stelle evtl. die Dokumentation erweitert werden oder suche ich an der falschen Stelle ?
Grüße Frank
FW 1.83, localhost eingetragen, aber er rebootet immer noch nicht 
