Beiträge von chrissiboy

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

Um den ursprünglichen Ansatz von gerty nochmals aufzugreifen ... hin und wieder lässt sich ein Shelly per WLAN nicht mehr steuern und auch nicht anpingen. Über den Schalter funktioniert er noch. Ich würde nun gerne über den LongPress die Aktion "http://<IP-Adresse>/reboot" mir das Öffnen der Schalterdose sparen. Leider wird diese Aktion wohl nicht ausgeführt, obwohl ich im MQTT-Protokoll sehe, dass dieses Ereignis stattfand. Habe ich da noch einen Denkfehler ? Über den Browser funktioniert das einwandfrei. Der Button ist auf Detached eingestellt.

Ich benutze nur IPv4. Die APs sind Unify AC Pro bzw. nano HD

das hatte ich schon und an der FB war sonst nichts dran ... löste mein Problem leider auch nicht

Hi Maik,

ja, so wie es aussieht betrifft es alle. Egal ob 2.5, 1 oder Dimmer. Es passiert vollkommen unregelmäßig und als Spannung liegen lt. Shelly zwischen 232V und 236V an. Das entspricht auch der Messung an einer Steckdose. Sämtliche Shellies werden grundsätzlich über eine Phase gesteuert. Also auch die Ein- bzw. Ausgänge. Normalerweise sind sie in einem separaten Subnetz und werden über IP Symcon und MQTT gesteuert. Aber ich hatte den einen Shelly zu Testzwecken auch schon ohne irgendwas an einen separaten Netzt an der Fritzbox und das Problem war höchstens seltener aber nie weg. Jetzt meinte der Support, es könnte ein ARP-Problem sein, aber das kann ich mir nicht vorstellen. Die Shellies haben alle eine fixe IP und sind fest einem Accesspoint zugeordnet.

Hallo zusammen,

bin jetzt seit 14 Tagen über ein Ticket mit dem Support in Kontakt. Leider sind wir trotz FW 1.80 noch nicht wirklich weitergekommen. Ich habe ohne IPS Symcon getestet, ohne MQTT ohne Anbindung irgendwo und auch nochmals in Verbindung mit der Cloud ... und natürlich mit Gerätewechsel. Leider alles ohne Erfolg.

Aber: Mir ist jetzt aufgefallen, dass jedes Mal nach der Unterbrechung die "uptime" auf 0 zurückgesetzt war und habe jetzt mal 6-8 meiner Shellies dahingehend untersucht und festgestellt, dass bei keinem eine "uptime" von über 48 Stunden erreicht wurde. Viele hatten nach 6-12 Stunden den Wert wieder zurückgestellt. Da ich ausschließen kann, dass ich echte Stromausfälle in dieser Zahl habe, die den Shelly in die Knie zwingen könnten, muss das eine andere Ursache haben. Nach meinem Verständnis rebooten die Shellies in unregelmäßigen Abständen und wenn man wie ich überall eingestellt hat, dass sie nach einem Reboot erst mal ausgeschaltet sein sollen, merkt man das natürlich nur, wenn es während einer Einschaltzeit passiert. Meinen Brunnen habe ich derzeit darauf eingestellt, in den Zustand vor dem Reboot zurückzugehen und damit verhaspelt er sich zwischendurch wegen dem Reboot, aber er läuft dann sofort wieder an.

Das passiert übrigens auch bei den Shelly 1.

Kann mal jemand schauen, ob das bei ihm auch so ist bzw. hat jemand eine Idee, mit was das zusammenhängen kann. Erwarte noch eine Antwort vom Support, den ich für seine schnellen Reaktionen hier auch mal loben will. Leider habe ich allerdings noch keine Lösung. Eine Test-FW, die mal so richtig alles mitloggt, wollten/konnten sie mir dann doch nicht geben.

Grüße Frank

OK - dann werde ich morgen tauschen

nein, habe ihn noch nicht getauscht - wollte erst mal fragen, ob es sich um ein bekanntes Thema handelt - lieber FW tauschen als Hardware

Auch ohne mqtt schaltet der Shelly ab - die Temperaturanzeige stieg nicht über 72 Grad blieb stundenlang konstant.

hatte ich ja geschrieben ..

Hallo, mein 2.5 betreibt eine kleine Brunnenpumpe, ist zum Schalten über einen Taster konfiguriert und im Prinzip funktioniert alles .... außer dass er in unregelmäßigen Abständen einfach abschaltet. Er ist über mqtt an IP Symcon angeschlossen und laut Logs geht von da aus nichts raus und es sind auch keine Timer oder Actions konfiguriert. Ich war auf FW 1.7 und bin auf die 1.61 zurück, weil alle anderen 2.5 auf der 1.61 machen was sie sollen, aber besser wurde es nicht. Gibt es das Problem auch bei anderen und ist bekannt, ob das mit der FW zusammenhängt oder ist der einfach nur defekt ? Zu heiß wird er übrigens nicht

Grüße Frank

ja - klar ... stand ja dabei