Beiträge von gantim

Aktueller Stand:

• Problem ist: Ein Shelly (wie der 1PM Mini Gen3 für das Licht Garage) darf nicht komplett funktionslos werden, auch wenn der Empfang schlecht/wechselnd ist. Das ist aber wiederholt und mehrfach geschehen, mit aktueller Firmware.
• Aufgrund der Vermutung, dass der Rescan das Problem verursacht, habe ich das Rescan-Intervall von 60 auf 120 Sekunden gesetzt. Seitdem trat es (bisher) nicht mehr auf, obwohl der Shelly teilweise mehrmals am Tag keinen Empfang hat.
• Zum Testen habe ich einen Shelly Plug S in der Steckdose nebendran angebracht um zu sehen, ob er solche Phänomene auch zeigt.
• Demnächst teste ich mit Plus2PM (ebenfalls einigermaßen dort in der Nähe), ob ich diesen Effekt dort auch provozieren kann
• Wenn es einigermaßen sicher nur mit dem bisherigen Shelly provoziert werden kann (es tritt aber auch ohne "Verbesserungsmaßnahmen" manchmal wochenlang nicht auf, solche Tests dauern also Monate), tausche ich ihn aus und teste, ob es vielleicht nur diesen einen Shelly betrifft und dieser einen Defekt haben könnte (passt nicht zu bisherigen Erkenntnissen, wäre aber trotzdem durch Versuch auszuschließen).
• Sobald ich eine neue Erkenntnis habe, melde ich mich bei Angel (und hier) zwecks Weiterverfolgung

Es geht nicht um einen Workaround. Den Empfang zu verbessern, damit es nicht auftritt, würde nicht helfen - wird ein metallischer Gegenstand (Fahrrad, Backblech, whatever) irgendwo abgestellt, würde das ggf den Empfang beeinträchtigen und das Problem hervorrufen. Es geht darum, das Problem nachzuvollziehen (kompletter Absturz, kein Schalter reagiert, kein AP mehr vorhanden wenn schlechter Empfang in Mesh-Umgebung), damit es behoben werden kann. Shellys müssen auch unter wechselnden Empfangsbedingungen stabil ihren Dienst tun (außer natürlich WLAN, solange das keinen ausreichenden Empfang hat).

Zitat von Angel

Jeder?

In #32 habe ich Quellen verlinkt:

- Shelly hängt sich auf (Februar 2024) (Shelly Plus 1, in 2/34 Plus2PM ebenfalls mit eindeutigem Absturz!)

- Dort in #19 Link zum Support.EU. (Shelly i4, Plug)

- Shelly verlieren WLAN-Verbindung (März 2024) (Shelly Plug S, Plus 1, Plus i4)

Der Hauptakteur in den Threads hat März 2024 geäußert, dass er aufgrund der Problematik nach und nach die Shellys durch Sonoff-Produkte ersetzt.

Es wird nicht in allen Beiträgen eindeutig geschildert, dass der Shelly tatsächlich NUR durch Powercycle wiederbeleben ließ, und manchmal war es auch nur ein temporäres Empfangsproblem, bei dem der Shelly nach einer längeren Zeit wieder erreichbar war. Motto: "es soll einfach nur funktionieren" - ob Erreichbarkeit WLAN oder prinzipiell Funktionsfähigkeit des Shelly-Geräts wird leider nicht unbedingt getrennt. Die von mir geschilderte Problematik (nichts hilft, nur Strom aus) kam aber definitiv mindestens bei i4 und Plus2PM vor und wird explizit erwähnt. Das passt dazu, dass der Support das Problem "seit Jahren bekannt" nennt.

Es erscheint mir logisch, dass alle Shellys die gleichen Routinen für WLAN/Rescan verwenden.

Da der genaue Grund nicht bekannt ist, kann ich natürlich nicht ausschließen, dass es nicht betroffene Geräte gibt. Zum Beispiel Gen1, möglicherweise ist der Rescan erst seit Gen2 kaputt und wurde damals noch anders durchgeführt. Oder Gen4 könnte sich anders verhalten, wenn zufälligerweise der entsprechende Programmteil umgeschrieben wurde und dadurch der Bug nicht mehr vorhanden ist.

Derzeit gehe ich davon aus, dass jeder Shelly, der mit einem Fritz-Mesh-WLAN verbunden ist, unter den entsprechenden Umständen solche Symptome zeigen würde. Egal was für eine kaputte Antwort ein Fritz-Produkt eventuell liefert (kann gut sein, dass ein Fehler im WLAN-Protokoll auf Fritz-Seite den Fehler verursacht - etwas in der Art würde ich erwarten - andererseits meinte der Support, das Problem träte auch mit anderen Mesh auf), aussteigen sollte der Shelly deswegen nicht.

Zitat von Loetauge

Für gutes Wlan ist immer der Router und das Mesh veratwortlich und nicht der Client.

Übersteuerungen im Eingangskreis eines Emfängers führen immer zu Abregelvesuche mit deren Folgen wie Oberwellenbildung, Signalrauschen und Dopplereffekten. Das führt zu ständigen Protokollwiederholungen und Fehlermeldungen bis hin zum Signalverlust. Ergo keine störungsfreie Verbindung.

Es geht nicht darum, ob der Shelly Empfang hat. Oder eine störungsfreie Verbindung. Es geht darum, dass der (jeder!) Shelly bei schlechtem Empfang (ok, muss wohl zusätzlich ein Mesh sein, damit es auftritt) so abstürzen kann, dass ein im Edge-Modus angeschlossener Schalter nichts mehr tut und/oder beliebige andere Funktionen nichts mehr tun (zB Access Point ist auch weg).

Egal wie der Empfang ist, das darf bei so einem Gerät nicht passieren. Fehler gibt es, kann man machen, aber davon zu wissen, es über Jahre nicht zu analysieren und beheben disqualifiziert in meinen Augen einen Produkthersteller dauerhaft. Hätte ich davon gewusst, würde ich heute vermutlich keine Shelly-Produkte einsetzen.

Zitat von Finn05

Aber ich bin auch der Meinung, alle Shelly Geräte sind klein und haben Ihre Grenzen, sind auch für mich nur im Altbau oder Bestandsbau was, wer einen Neubau macht sollte KNX nehmen, das ist das wahre für mich.

Nochmal zusammengefasst die bisherige Situation:

• Mehrere AP/Repeater im Mesh
• Schlechter Empfang (warum auch immer)
• Ein beliebiger Shelly mit WLAN-Konfig wird komplett funktionslos, auch der angeschlossene Schalter bewirkt nichts

Es ist möglich, nur weil jemand ein Fahrrad oder ein Backblech zufällig eine Zeitlang vor einen Shelly stellt, dass dieser auf einmal nicht mehr ansprechbar wird und nur durch kurzes stromlos-Schalten wieder funktional. Es mag nur selten auftreten, aber es darf nicht sein.

Egal was für eine Empfangssituation, die Shelly-Geräte dürfen dadurch nicht komplett ihre Funktion verlieren. WLAN in Ordnung, dass das nicht mehr in Tritt kommt, so sei es. Finde ich auch nicht gut, dann sollte die Fehlersituation durch die Firmware festgestellt werden und halt mal rebooten, bis man bei Shelly den Fehler besser nachvollziehen kann, findet und richtig behebt. Aber ein angeschlossener Schalter im Edge-Modus, dass der sich gar nicht mehr fängt - da hört für mich der Spaß echt auf. Ist es vielleicht sogar eine Endlosschleife, bei der das Gerät wegen CPU-Last überhitzen könnte? Ich habe weder Stromverbrauch noch Temperatur gemessen.

Übrigens hatte ich das Problem bei einem Rollladen-Shelly meines Sohnes (Dachzimmer in einer Ecke - weit weg von EG- und KG-Fritzboxen) vermutlich bereits auch mehrfach. Seit ich den 1200ax als zusätzlichen Repeater habe (genau wegen diesem Problem), trat es nicht mehr auf (logisch - besserer Empfang ist Abhilfe), aber der Plus2PM hatte vor einem Jahr etwa ähnliche Phänomene. Ganz so selten ist es vielleicht doch nicht.

Dass der Support sagt "in so einem rare edge case wie schlechtem Empfang - da machen wir das Ticket einfach zu - unsere Geräte brauchen nicht zuverlässig funktionieren" lässt mich wie erwähnt mein Vertrauen in die Firma verlieren und ich bin noch nicht sicher, wie ich damit umgehen werde. Es sind nicht die Grenzen der Geräte, sondern der fehlende Anspruch von Shelly an die Zuverlässigkeit der Produkte, mit dem ich ein Problem habe. Die vom Support getätigte Aussage, dass der Fehler seit Jahren bekannt ist und nicht analysiert/behoben wird. Angel Ich hoffe, dass du keinen Ärger bekommst, wenn du es entgegen der Firmenpolitik von Shelly analysierst, die Situation kenne ich aus eigener Erfahrung. Wenn von oben entschieden wurde, dass das nicht analysiert werden soll (bringt ja nicht direkt Geld - keine Ahnung in welcher Position du bist), bekommt man auch für die tollste Analyse und den besten Bugfix Ärger.

Zitat von Angel

gantim scheinbar hast du uns noch ein paar Details vorenthalten. Stelle und bitte alle relevanten Informationen bereit, spezielle Einstellungen, Anschlusschema, die Devicedata (aus der Diagnose) und auch die evtl. auf dem Gerät laufenden Scripte. Gerne auch per PM, Danke

Ich war der Meinung, alles erwähnt zu haben, was für den Fall relevant ist. Bewusst vorenthalten habe ich sicher nichts. Scripte waren bei den ersten mindestens 3 Vorfällen nicht drauf und der (bereits gepostete und nur zusätzlich um die wifi-Logging-Zeile ergänzte) laufende watchdog.js dient nur dem erweiterten Logging (mit welchem AP bin ich verbunden?) bzw. dem Watchdog für Reset, der aber nicht gegen das Problem geholfen hat. Meine derzeitige Vermutung als "Schuss ins Blaue" wäre, dass beim Wifi-Rescan irgendein Unsinn passiert, der das Gerät abstürzen lässt.

Nachher stelle ich es zusammen (inklusive Script watchdog.js, beispielsweisem UDP-Log) und sende es per PM. Falls es nicht gleich klappt, kann es auch 2-3 Tage dauern (habe ein paar zeitkritische Anliegen). Aber ich habe starkes Interesse daran, dieses Problem möglichst zeitnah tatsächlich zu lösen und tue gerne, was in meiner Macht steht.

UDP Log direkt an Shelly: Wenn es Richtung Shelly-Cloud-Server geht, bekomme ich es ja nicht mehr, oder ist es möglich, das UDP-Log an mehrere Ziele gleichzeitig zu senden? Trennung mehrerer Adressen mit Leerzeichen, Komma oder sowas?

UDP-Log ist seit dem letzten Ausfall (kurz nach Weihnachten) aktiviert und sendet an einen Server bei mir im Intranet. Meine Shellys haben üblicherweise keinen Internetzugang, das schalte ich für Firmware-Updates speziell frei (und ich finde schade, dass es ohne Internet keine einfache Updatemöglichkeit gibt). Daher kann ich sie nicht sinnvoll mit Shelly-Support-Servern verbinden.

Sobald es wieder passiert, stelle ich die Logs zur Verfügung.

Im Ticket schrieb ich:

Zitat

There is a light attached which is configured to be switched using "Edge". This does not respond anymore. The switch just does nothing, you can't turn on the light attached to the Shelly device. The only solution is power-cycle the fuse. I'm not fine with your statement that the network stack ever gets in a state that is not recoverable without power-cycle on bad reception, but: Are you serious that you accept and do not fix that your devices malfunction/crash on bad reception in a way that the switch is not working anymore?

Antwort von Shelly:

Zitat

We do not take any responsibility for this issue, as it is related to the network the device is connected to.

These devices are designed and engineered to work with pretty much every Wi-Fi configuration available, but as we said, there are some edge cases that we cannot possibly account for.

Unfortunately, we are unable to help you any further. Therefore, we will proceed with this ticket's closure.

Thank you for your time.

Best Regards,

Shelly Support Team

Alles anzeigen

Damit ist es amtlich und erneut bestätigt: Seitens Shelly sind beliebige Ausfälle möglich, wenn die Verbindung schlecht ist. Es ist bekannt, und nicht geplant, etwas daran zu ändern.

Zitat von Angel

gantim hast du die Möglichkeit es mit einem anderen 1PM Mini Gen3 gegenzutesten?

Prinzipiell ja. Ich habe noch welche originalverpackt da (diverse Dimmer, Addon, 2pm, auch 1pm Mini gen3 auf Vorrat - habe ja über 50 Shellys verbaut und war noch weiter am Aufrüsten). Aber es ist in über 2m Höhe in der Garage und das Problem tritt nur alle 1-8 Wochen mal auf. Der Test dauert also ggf. Monate. Selbst wenn es nicht auftritt, hat das keine besondere Aussagekraft, ob es mit 1-2 dB besserem oder schlechterem Empfang auftreten würde. Seit ich die Lage des 1pm Mini Gen3 in der Verteilerdose geändert habe, trat es nicht mehr auf (kann ich aber gerne rückgängig machen). Und der Support kennt das Problem laut eigener Aussage bereits.

Insgesamt bezweifle ich, ob der Test was bringt (wäre aber im Zweifel bereit dazu, hatte beispielsweise im Ticket explizit angeboten, Tests durchzuführen).

Zitat von Cephalopod

Das kann jedem WLAN Gerät ohne Empfang passieren

Nein, das darf einfach nicht sein.

Ich habe für unsere Tiere (Königspythons) eine Steuerung geschrieben, die die Temperatur im Terrarium regelt. Das habe ich bewusst so gemacht, dass es lokal auf dem Shelly-Gerät, das das Add-on zur Temperaturmessung hat, läuft. Alle WLAN-Zugriffe sind zwar sinnvoll, um die Temperatur überwachen zu können, die Lampe ein- und ausschalten zu können. Aber ich habe bewusst dafür gesorgt, dass die Regelung weiter funktioniert, selbst wenn Home Assistant nicht erreichbar ist und/oder das WLAN ausfällt. Beim Ausfall von WLAN klappt die Kommunikation zwischen dem 2PM und dem Dimmer nicht mehr. Oberhalb der Toleranz (Hysterese) wird daher der Dimmer per Output ausgeschaltet, dafür habe ich extra einen Ausgang des 2PM mit dem Dimmer-Eingang verbunden. Es wird nicht einfach weiter maximal geheizt, weil das WLAN ausfällt. Voraussetzung ist aber, dass der 2PM weiterläuft.

Wenn ich damit rechnen muss, dass, falls der Empfang wegen Bodennebel mal schlecht ist, der Shelly 2PM (und/oder der Dimmer) komplett ausfällt, hört die Regelung auf und im schlimmsten Fall bleibt die Heizung auf Maximum. Dauerhaft. Das geht einfach nicht, das darf nicht sein. Zu kalt ist nicht direkt lebensbedrohlich, zu warm durchaus. Ja, ich überwache sowieso auch (in jedem der Terrarien) über ein weiteres (ZigBee-)Thermostat die Temperatur und lasse mir eine Warnung senden, wenn Home Assistant zu hohe Temperaturen bemerkt (die ich nicht mehr erhalten habe, seit ich den Bereich für die Warnung passend gewählt habe). Trotzdem. Es darf nicht sein.

Mittelfristig hätte ich die Idee, dass der Dimmer in meiner Terrarien-Steuerung sich bei dem 2PM (indem dieser als Repeater konfiguriert wird) anmeldet und daher immer guten Empfang hat (da er direkt nebendran ist). Das hat aber Nachteile. Zum einen ist der Dimmer nicht mehr für Home Assistant erreichbar (hatte ich mal angeschaut, würde HA den Dimmer auf eine andere Weise ohne Portnummer ansprechen, könnte man das möglich machen - geht aber nicht ohne Änderungen in HA) und ich diese Überwachung/diesen Zugriff gerne weiter haben möchte. Zum anderen sind 3 Terrarien direkt beieinander, jedes hat eine solche Steuerung und ich bin nicht sicher, ob 3 zusätzliche WLANs direkt an einem Ort eine gute Idee sind. Lieber wäre mir eine Kommunikation per Kabel, aber die gibt es leider nicht.

Mit dem jetzigen Wissen hätte ich das Projekt so nicht gestartet, sondern etwas anderes verwendet. Etwas zuverlässiges. Hättest du recht, dass ein WLAN-Gerät jederzeit beliebige Fehlfunktionen haben darf, wenn der Empfang schlecht ist, hätte ich niemals ein WLAN-Gerät auch nur angedacht. Ich bin aber sicher, dass das einfach falsch ist. Einen solchen Bug darf ein solches Gerät nicht haben, und selbst wenn es gefixt werden sollte, bleibt die Firma Shelly für mich ab sofort wegen dieser Aussage weniger vertrauenswürdig. Das hätte meiner Meinung nach vom Support niemals in dieser Form geäußert werden dürfen. Wir wissen, dass jeder Shelly abstürzt, wenn der Empfang schlecht ist, aber weil es selten vorkommt, wird es nicht gefixt? Über Jahre?

Wie darf sich Waschmaschine/Trockner/Backofen/Kochfeld mit WLAN deiner Meinung nach verhalten, wenn der WLAN-Empfang (der ebenso wie bei diesem Schalter-Shelly nicht die Hauptfunktion ist) mal kurz weg ist? Einfach den Betrieb komplett einstellen wie dieser Shelly (hoffentlich wenigstens das und nicht auf Maximum weiterlaufen!) und nicht mehr auf Tastenbedienung reagieren, bis man per Sicherung kurz den Strom klaut?

Zitat von apreick

Dann würde ich sofort ein Ticket bei Shelly erstellen, dann wird er mit Sicherheit von dort per UDP überwacht

Wie erwähnt, mehrfach verlinkt und zuletzt zitiert habe ich bei Shelly ein Ticket eingestellt. Bei schlechtem Empfang ist es ein seit Jahren bekanntes Problem, dass ein Shelly-Gerät nicht mehr reagiert und ein Fix ist nicht angedacht. Kategorie "rare edge case", Abhilfe Empfang verbessern ... könnte natürlich jederzeit passieren, wenn etwas Metallisches in den Weg gestellt, dass sowas auftritt. Aber es ist ja selten.

Insgesamt kann man Shelly-Geräte wohl einfach nicht als zuverlässig betrachten. Kann jederzeit aufhören zu funktionieren.

Wenn das Problem auftritt, funktioniert der Schalter nicht (der nicht auf detached gestellt ist, sondern auf Edge) und ein AP wird (sofern konfiguriert) vom Shelly nicht mehr bereitgestellt. Das Licht lässt sich nicht mehr einschalten! Einzige mir bekannte Abhilfe ist Sicherung raus - Sicherung rein.

Es ist nicht das Empfangsproblem, das ich primär zu lösen versuche. Das ist vorhanden und das möchte ich danach auch angehen, aber zweitrangig bzw. bewusst zu erzeugen zur Reproduktion des Problems, dass der Shelly irgendwie crasht. Der Shelly soll weiterhin funktionieren/ansprechbar sein, auch wenn der Empfang schlecht ist, zwischen verschiedenen Repeatern wechselt, mal weg ist oder sonstwas passiert.

Edit: Das UDP Log könnte Erkenntnisse bringen. Vielleicht sagt die letzte Meldung etwas aus über die Umstände, unter denen es passiert. Ich sehe keine Möglichkeit, aus einem Shelly, der nicht mehr reagiert, irgendwelche Informationen zu erhalten. Das geht nur vorher. WENN man etwas herausfinden kann, dann im UDP Log.

Edit: Auf das Ticket wurde reagiert. Aussage Shelly: Es ist bekannt und normal, dass Shellys so abstürzen, dass nichts mehr geht, wenn man längerfristig wechselnd schlechten Empfang in einem Mesh hat. Der network stack kommt in einen kaputten Zustand. Es ist seit Jahren bekannt. Es ist offensichtlich nicht angedacht, das zu fixen, man solle den Empfang verbessern. Ich habe im Ticket darauf hingewiesen, dass auch der Schalter nicht mehr funktioniert, gefragt, ob sie das ernst meinen und suche ab sofort eine Alternative zu Shellys.

Direktzitat:

Zitat

From what you describe, this does not point to a hardware failure but rather to a rare edge case related to Wi-Fi connectivity and recovery. Very poor or unstable Wi-Fi signal levels (such as -85 to -88 dBm) can put the Wi-Fi stack into a state where the device is unable to recover properly without a power cycle. In such cases, the device may stop responding to the network and also not bring up its own AP, even though it is still powered. A JavaScript watchdog cannot recover from this state because the networking subsystem itself is already stuck.

This behavior has been observed occasionally in the past across different generations when devices operate for long periods with marginal signal quality, especially in mesh environments. Fritz!Box / Fritz! Repeater setups are very common, so they tend to appear more often in reports, but they are not necessarily the root cause by themselves. The common factor is usually an unstable or fluctuating signal strength rather than a specific router brand.

Improving Wi-Fi reception is currently the most effective mitigation, and users who moved the device closer to an access point, added a repeater with a stronger signal, or switched to a less congested channel generally stopped seeing the issue. While devices should always try to recover gracefully, extremely poor reception can still lead to situations where only a power cycle resolves it.

Cephalopod Also die Idee ist, dass ein anderer Wert zusätzlich beim Rescan dafür sorgt, dass andere AP berücksichtigt werden könnten. Gut, probiere ich gerne aus. Dann weiß ich, worauf ich achten muss.

Schade ist, dass ich in den UDP Logs des Shelly nicht sehe, mit welchem AP er sich verbindet/verbunden ist. Oder kann man den Loglevel erhöhen?

Die Fritzbox zeigt zwar in der Übersicht an, über welchen Repeater der Shelly verbunden ist, aber ich sehe keine einfache Möglichkeit, es gezielt mitzuloggen. Das kann ich derzeit also nur direkt betrachten und notieren. Ich schau Mal, was ich da tun kann, um das zu verbessern.

Trotzdem ist mein Hauptproblem weiterhin, dass der Shelly unter keinen Umständen die Funktion verlieren sollte, dass man den Schalter bedienen kann. Er darf einfach nicht abstürzen, warum auch immer.

schreckus Durchaus, der minütliche Rescan mit miserablem Empfang scheint der Auslöser des Problems zu sein. Deshalb habe ich -84 eingestellt, seitdem habe ich das Problem nicht mehr gehabt (sind aber auch erst wenige Tage).

Also, ich lasse es jetzt erst noch Mal eine Woche oder so mit -84 laufen, damit ich das erst auswerten kann, dann teste ich mal -60 als Wert, ob das was ändert.

Bis das Ticket bei Shelly bearbeitet wird, wird sicher einige Zeit dauern. Ist auch OK, die sollen sich lieber Zeit lassen und es dafür genau ansehen. Falls man es kommentieren kann, lasst es bitte nach Möglichkeit sein. Der Hinweis besagt, dass die ältesten Tickets zuerst bearbeitet werden und ein Kommentar die Zeit des Tickets neu setzt.

Mein Argument bleibt: Auch bei miserablem Empfang und minütlichem Rescan darf es nicht passieren, dass der Schalter nicht mehr funktioniert. Egal was mit dem Empfang ist. Egal ob das Logging funktioniert. Schalter an - Licht an. Schalter aus - Licht aus.

(Ein abstürzendes oder Fehlfunktionen auslösendes Script wäre etwas anderes, aber das Script mit dem Watchdog stürzt nicht ab, und es trat auch ohne das Script auf - werde es wohl wieder rausnehmen)

Der Shelly bedient eine Lampe anhand eines Schalters. Diese Funktion hat er zu erfüllen, egal ob das WLAN zuverlässig, gut schlecht, zeitweise oder gar nicht funktioniert.

Ich mache mir Gedanken, wie ich den Fehler reproduzieren kann, und jetzt kommt die Aussage "Shellys funktionieren grundsätzlich nur mit ordentlichen Empfang zuverlässig"? Nicht wahr, oder?

Wo kann man das nachlesen, dass Shelly auf einmal ihre Funktion komplett verlieren, wenn der Empfang schlecht ist? Gibt es ein ordentliches Produkt, das ich statt Shellys verwenden kann, und das auch bei schlechtem Empfang, Bodennebel oder Vollmond funktionieren sollte?

Ernsthaft: Ich hoffe, dass eine solche Aussage niemals vom Hersteller kommt. Und dass das Problem analysiert und demnächst behoben wird.

Ein Wert von -60 ist höher als ein Wert von -70 ist höher als ein Wert von -80.

Alle diese Werte bewirken das gleiche, wenn mein bester Empfang bei -83 lag (ging bis -90): Es wird jedesmal gescannt. Passt zu meinen Logfiles. Es war jede Minute. Zuverlässig.

Wieso lese ich bei allen etwas, das zu dieser Aussage passt, aber gleichzeitig wird behauptet, dass bei mir ein Wert von -60 was anderes bewirken könnte als -80?

Sorry, Leute, mir ist das weiterhin zu hoch. Wieso soll einer dieser Schwellwerte jetzt bei mir was anderes bewirken als ein Rescan jede Minute, und was genau soll ich testen?

(Verbindung besteht immer wenn ich nachgesehen habe zu dem 1200ax im OG, der Shelly ist auch derzeit gelegentlich eine kurze Zeit 1-10 Sekunden nicht verfügbar - schaue ich mir die Tage noch detailliert an)

Moment jetzt.

Als Schwelle war -80 eingetragen. Zeit 60 Sekunden. Das besitzt, er prüft jede Minute und bei einem Wert unter -80 macht er einen Rescan.

Meine Werte waren alle schlechter. -84 bis -90.

Laut Logfiles machte mein Shelly jede Minute einen Rescan.

Wenn ich einen höheren Wert eintrage, ist mein Wert schlechter. Er ist unter -60, unter-70, und unter -80. Er macht jede Minute einen Rescan, daran sollte sich nichts ändern, wenn ich einen höheren Wert eintrage, der eh nie erreicht wird.

Deshalb habe ich den Wert auf -84 gesetzt und seither sind weniger Rescans im Log. (Muss mal aktuell nachsehen, jedenfalls wurden sofort keine Rescans mehr gemacht bei -81 bis -83)

Dass ein höherer Wert bei einer anderen Empfangssituation helfen kann, ist logisch.

Dass ein höherer Wert bei mir irgend etwas ändert, ist unlogisch, außer er bewirkt noch etwas anderes, das nicht offensichtlich dokumentiert ist.

Was ist denn die Vermutung, was dieser Wert tut, außer die Schwelle festzulegen?

Ich bin gerne bereit, solche Dinge ausprobieren, aber ich möchte wissen, was die Idee/Erwartung dahinter ist - ich kann auch mit "ich hatte den Eindruck, es würde was ändern" leben und die Vermutung überprüfen - aber ich möchte erst wissen, worauf ich achten soll. Was der erwartete Effekt ist. Ein besserer Empfang?

Zitat von Cephalopod

Was kam bei #11 raus?

Es war -80 eingetragen als Schwelle. Der beste Empfang, den der Shelly vor meiner Änderung hatte, war -83. Einen höheren Wert als Schwelle einzutragen ist sinnfrei. Die -83 ist niedriger als -80, aber ebenso niedriger als -60 oder -70. Was soll das bringen? Es ändert ja nichts.

Nach der Änderung der Positionierung des Shelly in der Dose habe ich daher -84 als Schwelle eingetragen, damit er nicht grundsätzlich alle 60 Sekunden scannt.

Einen weiteren Repeater möchte ich nicht einsetzen. Im Gegenteil möchte ich mittelfristig von der 7490 weg, aber die neueren Fritzboxen weigern sich standhaft, mehrseitige Faxe zu senden. (Mit Roger Router kann man wunderbar Faxen - offiziell unterstützt wird aber nur eine Seite)

Bis ich sicher bin, wie es hier mit Glasfaser wird, will ich aber erst Mal nichts ändern.

Andererseits sehe ich es irgendwie auch nicht ein, mit 52 Shellys eigentlich 52 Geräte zu haben, die Repeater spielen könnten, und mir DANN noch einen 4. Repeater hinzustellen. Für ein nicht allzu großes Haus ohne Stahlbeton.

Wenn ein Shelly einen Repeater macht, ändert sich etwas, wie man Geräte hinter ihm anspricht, und das klappt derzeit nicht mit Home Assistant. Das könnte ich ändern, aber das muss ich nur erst noch ansehen. Wobei ich gleichzeitig nicht glaube, dass ich nächstes Jahr dazu komme. Und andere wollen es eher nicht machen, die Entwickler von Home Assistant sind der Meinung (siehe KVS versus virtual components), dass man nur die aktuelle Generation voll unterstützen muss.

Egal, hier geht es erst Mal um den Absturz des Shelly, wenn der Empfang schlecht ist. Der darf nicht sein.

Also, ich habe gestern ein Ticket erstellt, darin diesen Thread verlinkt und werde hier berichten.

Mein Gedanke war: Ein Issue "Der Shelly wird unresponsive, eventuell hängt es mit schlechtem Empfang und/oder Fritz-Repeater zusammen" ist schlecht nachzuvollziehen. Eventuell sollte ich die Arbeit reinstecken, nähere Umstände herauszufinden, damit es nicht einfach geschlossen wird als "can't reproduce".

Deshalb meine Frage. Aber die Shelly QA darf ruhig auch etwas tun. Ich hoffe, dass sie genug Interesse an der Zuverlässigkeit ihrer Produkte haben, um sich das näher anzusehen.

Also, das Problem ist wohl schon älter. Denn: Auch in einem anderen Forum haben mehrere Leute berichtet, dass Shellys sich bei schlechtem Empfang in Verbindung mit einem Fritz Mesh-Netzwerk so aufhängen, dass sie nur durch stromlos-Schalten wiederbelebt werden können. Das ist schon 1,5 Jahre her, aber offensichtlich hat es niemand für nötig gehalten, den Hersteller über dieses Problem zu informieren, damit die es mal testen und beheben können.

Das darf einfach nicht sein. Egal wie schlecht oder wechselnd der Empfang ist, der Shelly muss weiterlaufen!

Es wäre also hilfreich, den schlechten Empfang bewusst herbeizuführen, um das Problem für Shelly reproduzierbar beschreiben zu können. Oder meint ihr, man kann mit dem jetzigen Stand einen Bugreport daraus machen? (Eigentlich hätte ich anderes zu tun ... aber das geht üblicherweise allen so ... und wenn ich den Empfang einfach nur verbessere, bleibt das Problem bestehen)

Wenn ich einen neuen Shelly in mein Netzwerk aufnehmen, habe ich eine quasi geskriptete Vorgehensweise. Allerdings arbeite ich das von Hand ab.

• In meine internen Wiki geplanten Namen, IP- und MAC-Adresse dokumentieren.
• In der Fritzbox das Gerät einrichten, dass der Name bekannt ist und es auf die MAC die richtige IP per DHCP erhält.
• Mit dem Shelly verbinden, Gerätename eintragen und WLAN konfigurieren (SSID/PW, sonst bitte nichts).
• Kurzzeitig allen Shellys den Internetzugang erlauben und Firmware-Update durchführen.
• Wenn der Zugriff über den Namen funktioniert (http://shellyname.fritz.box), Access Point und Bluetooth des Shelly ausschalten.
• Passwort-Authentifizierung einschalten mit meinem Standard-Shelly-PW.
• Timeserver fritz.box einstellen (Wieso ist irgendwas im Internet dafür Default statt dem Standard-Router? Grrr Shelly! Das sollte kein Internet brauchen!).
• Longitude und Latitude eintragen.
• Wenn Rolladen im DNS-Namen: Umstellen des Modus auf Cover.
• Wenn Dimmer2-Gerät: Kalibrieren.

Das würde ich gerne skripten, zumindest große Teile davon. Bevorzugt so, dass ich auch allen Shelly, bei denen etwas falsch eingestellt ist, die richtige Konfiguration "überbraten" kann. Oder zumindest anzeigen, bei welchem Shelly etwas anders eingestellt ist als es Standard ist (ggf könnte das ja Absicht sein).

Gerne als Bash-Script, aber ich habe kein Problem damit, in Python, Javascript, Java, C++ oder was auch immer zu programmieren.

Gibt es dafür schon irgendwas sinnvolles als Library/Vorlage/Umgebung? Ich bin sicher nicht der erste mit dem Problem. Die ersten Schritte habe ich begonnen, aber ganz so billig ist das nicht (gerade mit Authentifizierung), und bei Änderung einer bestehenden Konfiguration braucht man das bereits beim ersten Ansprechen).