Ja das hätte man machen können
Der witz an der Sache ist aber wenn avm weiß dass das ein Problem sein kann, die Standard SSID auch Leer und Sonderzeichen hat.
Ja das hätte man machen können
Der witz an der Sache ist aber wenn avm weiß dass das ein Problem sein kann, die Standard SSID auch Leer und Sonderzeichen hat.
In meinem letzten post habe ich leider Quatsch erzählt die streams in meiner vis waren nicht schuld...
Dann habe ich doch das gemacht was avm mir empfohlen hat. Und zwar habe ich ein Sonderzeichen und ein Leerzeichen aus meiner SSID entfernt. Weil angeblich manche wlan geräte damit Probleme haben, was ich erst nicht glauben wollte. Nun läuft es aber schon seit fast einer Woche problemlos.
Bei ca. 40 wlan geräten die SSID ändern war natürlich nicht in 10 min getan
Ich bin wohl dem Problem etwas auf die Schliche gekommen.
Ich habe eine fritzbox 4040 an die 7490 als access point angeschlossen um auszuschließen dass die 7490 einen defekt hat. Bei der 4040 tritt aber das selbe Problem auch auf.
Avm meinte nur das sie nichts finden und ich meine SSID ändern soll weil diese Leerzeichen und eine # besitzt. Das ist aber bei vielen vielen sonoffs und anderen wlan geräten einfacher gesagt als getan.
Ich hatte aber festgestellt, dass das Problem oft auftritt wenn ich von der Arbeit nach Hause komme. Und immer dann mache ich mein Wandtablet an und starte meine VIS. In einem tab laufen 3-4 Streams von Überwachungskamereas. Diese laufen so wie es aussieht immer auch wenn ein anderes tab angezeigt wird.
Dies erzeugt einen relativ großen Datenverkehr und immer dann melden sich einige Sonoffs immer ab und an.
Irgendwann hängt sich dann der stream auf und es ist Ruhe bis ich die Seite neulade.
Jetzt habe ich alle Streams in der VIS deaktiviert und seit 1-2 Tagen ist nichts mehr vorgekommen. Mal schauen ob es das war und jetzt endlich Ruhe ist...
Diese Grafik konnte ich simulieren. Wenn die Auslastung bei 80-90 war liefen Streams und manche Sonoffs hatten Probleme.
Folgendes ist mir noch aufgefallen:
Um ca 19:50 - 20:05 haben viele sonoffs immer wieder die wlan Verbindung verloren.
Hier ein Auszug aus den Konsolen:
Diese Meldungen hatte ich im log vom iobroker:
In der fritzbox unter wlan funkkanel ist mir folgendes aufgefallen zu dieser zeit:
Kann dass das Problem gewesen sein? Falls ja kann ich solche Störungen irgendwie vermeiden? Normalerweise müsste die fritze dann doch selber einen anderen Kanal wählen, oder? Funkanaleinstellungen automatisch setzen ist aktiviert....
Es gibt etwas neues und zwar habe ich eine fritzbox 7490 und einen accesspoint fritzbox 4040. Normal sind alle Geräte mit Tasmota im wlan von der 7490.
Jetzt hatte ich gestern zum Test alle sieben shellys und jeweils ein basic und S20 an die 4040 angemeldet.
Heut früh hab ich gemerkt wie mein tablet kein wlan mehr hatte (hängt auch an der 7490) dann hab ich in die logs geschaut und ab dieser zeit hatte ich sehr viele Einträge vom sonoff adapter. Aber die Geräte die an der 4040 hängen waren nicht dabei!!!
Die wlan Einstellungen von der 7490 und der 4040 sind komplett gleich. Funkkanal Einstellungen automatisch setzten ist aktiviert und von 5ghz ist zum test deaktiviert.
Habt ihr eine Idee an was das liegen könnte? Nach einem Neustart von der 7490 waren die Probleme weg....
Admin kann ich offiziell noch gar nicht updaten...
Homematic und iot werde ich nicht updaten, weil das im Moment sehr stabil läuft. Sonoff habe ich zum test downgegradet und Yeelight muss ich so lassen, weil die 1.0.0 macht nur Probleme. Aber wenn mir ehrlich sind sollten doch die Adapter außer der sonoff bei meinem Problem keine Rolle spielen?!
Ich hatte gestern vormittag meinen Sonoff Adapter von 2.0.1 geupdatet auf 2.2.2, dann ist mir gestern schon aufgefallen das ich ca. 2-3 mal am Tag sehr sehr viele Einträge im Log (ähnlich wie im unten) habe immer im Zeitraum von 5-10 min danach ist von alleine wieder alles OK .
Heute früh hatte ich dann mein ganz altes Problem wieder (nicht um das was es in diesem Thema geht) und zwar schaue ich gerade um 6:55 Uhr meine VIS an und auf einmal werden alle Geräte und Lampen die an sind als aus dargestellt. In Wirklichkeit bleiben sie aber an, bis auf ein Gerät dieses hat in echt auf aus geschaltet (hatte ich genau so in der Vergangenheit auch schon, deshalb hatte ich ein downgrade auf 2.0.1 gemacht dann war Ruhe). Nach ein paar Min, wenn wieder von alleine ein neuer Status gesendet wird, schalten die Geräte und Lampen in der VIS wieder auf an.
Wenn nur Geräte betroffen gewesen wären mit tasmota 5.12.0 hätte ich gesagt es liegt an der alten Software, aber es waren eben auch shellys mit 6.4.1 betroffen.
Hier ein Auszug aus der Konsole eines shelly bei 6:55 Uhr sieht man nicht viel:
Hier ein Auszug aus dem Log vom iobroker um 6:55 Uhr hat die VIS gesponnen:
Das Problem das nur meine shellys die mqtt Verbindung verlieren, hatte ich so mit der 2.2.2 noch nicht, aber da muss ich noch abwarten um mehr sagen zu können.
Jetzt weiß ich aber nicht, was ich tun soll? Alles Sonoffs mit 5.12.0 neu mit 6.4.1 flashen und hoffen das die oben genannten Probleme weg sind, woran ich irgendwie nicht glaube? Den Adapter Schritt für Schritt downgraden und hoffen das bei irgendeiner Version beide Fehler nicht auftreten? Oder habt ihr eine ganz andere Idee? Wäre nett wenn ihr mir helfen könntet, weil ich weiß nicht mehr wirklich weiter....
Hast du die 6.4.1.15 auch auf einem shelly? Woher kommt eigentlich die 15? Weil wenn ich in weboberfläche auf info gehe steht bei mir wenn ich mich nicht täusche nur 6.4.1
Gelegentlich reconnects haben alle sonoffs das weiß ich aber gestern abend haben alle meine sieben shellys gesponnen. Um 23:38 habe ich den sonoff Adapter neugestartet und dann war wieder ruhe. Zu dieser zeit schalten die shellys auch über den normalen Lichtschalter extrem zeitverzögert (deswegen merk ich auch gleich das was nicht passt) hier der log hat schon um 22:30 angefangen:
2019-02-12 23:30:02.329 - info: sonoff.0 Client [DVES_22F787] connected
2019-02-12 23:30:08.971 - info: sonoff.0 Client [DVES_73EDCC] connected
2019-02-12 23:30:19.373 - info: sonoff.0 Client [DVES_73EDCC] closed
2019-02-12 23:30:31.781 - info: sonoff.0 Client [DVES_22F787] timeout
2019-02-12 23:30:39.883 - info: sonoff.0 Client [DVES_73EDCC] connected
2019-02-12 23:30:42.915 - info: sonoff.0 Client [DVES_22F787] connected
2019-02-12 23:30:46.803 - info: sonoff.0 Client [DVES_73EDCC] closed
2019-02-12 23:31:06.599 - info: sonoff.0 Client [DVES_1D19A0] connected
2019-02-12 23:31:06.603 - info: sonoff.0 Client [DVES_1D19A0] closed
2019-02-12 23:31:09.961 - info: sonoff.0 Client [DVES_73EDCC] connected
2019-02-12 23:31:21.382 - info: sonoff.0 Client [DVES_1D19A0] connected
2019-02-12 23:31:24.674 - info: sonoff.0 Client [DVES_1D93C8] closed
2019-02-12 23:31:48.875 - info: sonoff.0 Client [DVES_CDA5CA] connected
2019-02-12 23:31:49.021 - info: sonoff.0 Client [DVES_CD4BEE] connected
2019-02-12 23:31:49.149 - info: sonoff.0 Client [DVES_11534E] connected
2019-02-12 23:31:49.152 - info: sonoff.0 Client [DVES_73EDCC] connected
2019-02-12 23:31:49.153 - info: sonoff.0 Client [DVES_73F0DF] connected
2019-02-12 23:31:49.155 - info: sonoff.0 Client [DVES_1D9882] connected
2019-02-12 23:31:49.157 - info: sonoff.0 Client [DVES_BD2D98] connected
2019-02-12 23:31:49.169 - info: sonoff.0 Client [DVES_9FD66B] connected
2019-02-12 23:31:49.171 - info: sonoff.0 Client [DVES_228274] connected
2019-02-12 23:31:49.179 - warn: javascript.0 getState "sonoff.0.DVES_8F3EB9.alive" not found (3)
2019-02-12 23:31:49.182 - info: sonoff.0 Client [DVES_221C73] connected
2019-02-12 23:31:49.188 - info: sonoff.0 Client [DVES_857009] connected
2019-02-12 23:31:49.190 - info: sonoff.0 Client [DVES_37F24C] connected
2019-02-12 23:31:49.206 - info: sonoff.0 Client [DVES_8A2B13] connected
2019-02-12 23:31:49.216 - info: sonoff.0 Client [DVES_CA96A2] connected
2019-02-12 23:31:49.237 - info: sonoff.0 Client [DVES_8515D3] connected
2019-02-12 23:31:49.285 - info: sonoff.0 Client [DVES_9F9980] connected
2019-02-12 23:31:49.287 - info: sonoff.0 Client [DVES_B462A7] connected
2019-02-12 23:31:49.319 - info: sonoff.0 Client [DVES_9F172E] connected
2019-02-12 23:31:49.331 - info: sonoff.0 Client [DVES_953D52] connected
2019-02-12 23:31:49.333 - info: sonoff.0 Client [DVES_152637] connected
2019-02-12 23:31:49.375 - info: sonoff.0 Client [DVES_802899] connected
2019-02-12 23:31:49.378 - info: sonoff.0 Client [DVES_22F755] connected
2019-02-12 23:31:49.409 - info: sonoff.0 Client [DVES_810081] connected
2019-02-12 23:31:49.412 - info: sonoff.0 Client [DVES_B457F5] connected
2019-02-12 23:31:49.455 - info: sonoff.0 Client [DVES_80FF39] connected
2019-02-12 23:31:49.593 - info: sonoff.0 Client [DVES_747149] connected
2019-02-12 23:31:49.600 - info: sonoff.0 Client [DVES_805C8F] connected
2019-02-12 23:31:49.667 - info: sonoff.0 Client [DVES_1D19A0] connected
2019-02-12 23:31:49.694 - info: sonoff.0 Client [DVES_5DD0E1] connected
2019-02-12 23:31:49.743 - info: sonoff.0 Client [DVES_66B56C] connected
2019-02-12 23:31:49.799 - info: sonoff.0 Client [DVES_86AFED] connected
2019-02-12 23:31:49.974 - info: sonoff.0 Client [DVES_22F787] connected
2019-02-12 23:32:19.842 - info: sonoff.0 Client [DVES_73EDCC] closed
2019-02-12 23:32:27.826 - info: sonoff.0 Client [DVES_1D93C8] connected
2019-02-12 23:32:34.190 - info: sonoff.0 Client [DVES_22F755] connected
2019-02-12 23:32:40.791 - info: hm-rpc.0 xmlrpc <- listDevices ["hm-rpc.0"]
2019-02-12 23:32:40.810 - info: hm-rpc.0 xmlrpc -> 0 devices
2019-02-12 23:32:41.048 - info: hm-rpc.0 xmlrpc <- newDevices 63
2019-02-12 23:32:41.071 - info: hm-rpc.0 new HmIP devices/channels after filter: 0
2019-02-12 23:32:43.174 - info: sonoff.0 Client [DVES_22F755] closed
2019-02-12 23:32:58.177 - info: sonoff.0 Client [DVES_22F755] connected
2019-02-12 23:32:58.673 - info: sonoff.0 Client [DVES_1D93C8] connected
2019-02-12 23:33:16.302 - info: sonoff.0 Client [DVES_1D93C8] Error: read ECONNRESET
2019-02-12 23:34:21.720 - info: sonoff.0 Client [DVES_1D93C8] connected
2019-02-12 23:34:22.642 - info: sonoff.0 Client [DVES_22F787] connected
2019-02-12 23:34:22.786 - info: sonoff.0 Client [DVES_22F755] closed
2019-02-12 23:34:24.916 - info: sonoff.0 Client [DVES_1D19A0] connected
2019-02-12 23:34:24.923 - info: sonoff.0 Client [DVES_1D19A0] closed
2019-02-12 23:34:26.084 - info: sonoff.0 Client [DVES_73EDCC] connected
2019-02-12 23:34:27.048 - info: sonoff.0 Client [DVES_22F755] connected
2019-02-12 23:34:27.123 - info: sonoff.0 Client [DVES_1D19A0] connected
2019-02-12 23:34:32.610 - info: sonoff.0 Client [DVES_22F787] closed
2019-02-12 23:34:43.535 - info: sonoff.0 Client [DVES_22F787] connected
2019-02-12 23:34:57.104 - info: sonoff.0 Client [DVES_1D93C8] closed
2019-02-12 23:34:58.887 - info: sonoff.0 Client [DVES_1D19A0] connected
2019-02-12 23:34:58.892 - info: sonoff.0 Client [DVES_1D19A0] closed
2019-02-12 23:35:12.727 - info: sonoff.0 Client [DVES_1D93C8] connected
2019-02-12 23:35:18.063 - info: sonoff.0 Client [DVES_1D19A0] connected
2019-02-12 23:35:53.240 - info: sonoff.0 Client [DVES_1D19A0] closed
2019-02-12 23:35:53.947 - info: sonoff.0 Client [DVES_73EDCC] connected
2019-02-12 23:35:53.954 - info: sonoff.0 Client [DVES_73EDCC] closed
2019-02-12 23:36:07.116 - info: sonoff.0 Client [DVES_73EDCC] connected
2019-02-12 23:36:09.052 - info: sonoff.0 Client [DVES_1D19A0] connected
2019-02-12 23:36:15.279 - info: sonoff.0 Client [DVES_1D93C8] connected
2019-02-12 23:36:15.285 - info: sonoff.0 Client [DVES_1D93C8] closed
2019-02-12 23:36:33.697 - info: sonoff.0 Client [DVES_1D93C8] connected
2019-02-12 23:37:56.936 - info: sonoff.0 Client [DVES_1D93C8] disconnected
2019-02-12 23:38:02.219 - info: sonoff.0 Client [DVES_1D93C8] connected
2019-02-12 23:45:10.882 - info: hm-rpc.0 xmlrpc <- listDevices ["hm-rpc.0"]
2019-02-12 23:45:10.952 - info: hm-rpc.0 xmlrpc -> 0 devices
2019-02-12 23:45:11.199 - info: hm-rpc.0 xmlrpc <- newDevices 63
Alles anzeigen
Ok danke werden ich mal beobachten... aber generell ein wlan Problem scheint es nicht zu sein, weil ich kann auf die shellys immer zugreifen nur die mqtt Verbindung bricht ständig ab.
Meine anderen sonoffs ca. 20-25 stück mit der alten software 5.12.0d und dem core 2.4.0 haben zu dieser Zeit keine Probleme.
Sagt mir bitte mal welche version von der tasmota software mit welchen core ihr auf den shellys habt und welche version ihr von dem sonoff Adapter ihr installiert habt?
Zum testen werde ich auf einen shelly mal die 5.12.0d drauf machen, verlieren kann ich ja nichts...
Was vielleicht auch noch sein könnte, ich habe eine etwas ältere Version (2.0.1) von dem sonoff Adapter installiert. Weil mit der 2.2.2 hatte ich dauernd reconnection to db und es wurde teilweise ein falscher status in meiner VIS angezeigt, dies wiederrum könnte aber auch an der alten 5.12.0d liegen (da hatte ich noch keine shellys mit 6.4.1).
Weil wenn ich den sonoff Adapter neustarte sind die Probleme kurzzeitig wieder weg. Falls es der Test mit 5.12.0d auf dem
Shelly nichts bringt update ich den sonoff Adapter mal auf 2.2.2
Mal gespannt ob ich das zum laufen bekomm, wäre echt schade bin nämlich eigentlich ziemlich begeistert von den shellys....