Jeder kann machen was er möchte und hat auch seine Gründe dafür
Richtig. Ich wollte (in der an sich am Problem vorbeigehenden Diskussion über WLAN durchgängig ein oder nicht) auch nur aufzeigen, dass es eben verschiedenste Gründe gibt, warum WLAN nicht rund um die Uhr verfügbar sein muss. Klar hat es keinen Sinn das WLAN abzuschalten, wenn ich auch Aktoren nutze.
Es sind bei mir nicht bei jedem AP-Upgrade alle Shellys betroffen (gerade sind es zwei von drei Plus 1PM), d.h. vielleicht war es nur Zufall, dass es bei manchen einmal geklappt hat.
Könnte daran liegen, dass die Shelly nicht dauernd funken, sondern soweit ich gesehen habe alle 1-2 Minuten. Wenn das Zeitfenster reicht und der AP wieder online ist, passiert dann vielleicht nichts. Aber wenn einer genau in diesem Intervall an die Cloud senden will, bricht die Verbindung ab?
Wuste gar nicht wie viele Ihr Wlan Nachts ausschalten
Bei mir geht es nicht um Funkwellen oder nicht. Ich habe ein kleines Büro, bin oft auswärts weil ich auch an einer Fachhochschule unterrichte. Da haben NAS, Switch und der Router 40% meines Jahres-Stromverbrauches ausgemacht, wie mir das Monitoring mit dem Pro 3EM gezeigt hat! Wird daher abgeschaltet wenn ich nicht anwesend bin. Hat meinen Gesamtverbrauch drastisch reduziert (auch wenn er ohnehin gering war).
Das NAS fährt zeitgesteuert herunter, Switch und Router hängen an einem Plug Plus S. Somit ist alles auf Knopfdruck auf NAS + Shelly Plug eingeschaltet, wenn ich ins Büro komme.
Kurzfristige Lösung ist ja die vergabe einer festen IP im Shelly
Hätte ich am Freitag versucht, hat aber nicht geholfen. Haben sich dann gar nicht mehr angemeldet. Möglicherweise hat der Router das nicht akzeptiert, weil die IP dort im DHCP auch statisch reserviert war.
Hat das schon mal Jemand bei einem neuen Handy erlebt?. Ich nicht. Da mache ich notwendige Updates und es startet neu und macht keine Fehler. Das würde sich auch Niemand gefallen lassen, da als BETA-Tester zu arbeiten.
Also ich hatte schon einmal ein Handy, das nach einem ganz normalen Update des Google Frameworks in einem endlosen Boot-Loop gelandet ist. Nach Factory-Reset hat es funktioniert, bis die Updates wieder geladen waren. Musste mir ein neues Handy kaufen. Das Problem war dann ein paar Monate später behoben, seither habe ich ein Reservegerät herumliegen.
Also vielleicht nicht ganz so ungehalten reagieren, auch wenn ich die Verärgerung verstehen kann. Bin auch gerade von einem Bug beim letzten Update der Shelly Firmware betroffen.
Kann auch bestätigen: Sowohl Shelly Plug Plus S als auch Shelly Pro 3EM verbinden sich mit Firmware 1.2.0 nach Abschaltung des WLAN während der Nacht nicht mehr wieder. Beim Plug S kann man sich ja helfen, indem man ihn kurz vom Strom trennt. Aber das ist beim 3EM nicht so einfach. Den muss ich über die App und Bluetooth neu ins Netzwerk bringen. Auch will ich das nicht jeden Tag machen. Und hoffentlich passiert das nicht zuhause mit den 2PM Markisensteuerungen. Die vom Netz zu nehmen und auf diesem Weg neu zu starten wäre noch weniger lustig.
Problem ist laut Support bekannt und Zitat "es wird mit Hochdruck daran gearbeitet".
Würde gerne ein Downgrade der Firmware machen. Habe aber noch nirgends Firmwarefiles für diese Geräte gefunden, die ich direkt aufspielen kann.
Anmerkung: Auch die vorherige Firmware hatte schon das Problem, dass MQTT sich nicht wieder verbindet, wenn das WLAN kurz nicht verfügbar ist. Jedesmal über WLAN mit allen Shelly's zu verbinden um MQTT wieder zu reaktivieren ist auch nicht lustig, auch wenn man es zumindest ohne physischen Zugriff auf die Geräte machen kann.
How did you read that data into Matlab? If you look at the CSV using a text editor there are some things to take care about
* In general the data is not sorted by timestamp, you have to do that. That looks like being the cause for the slower ramp being at different positions. I'm not sure if Matlab is capable to process the time stamp written into that files.
* Data is shown in 1 minute intervals for some recent days, looks like that's being the part where your ramps look slower. The remaining data is stored in 10 minute intervals* consumption data is saved as Wh withing the respective time interval. So if the time interval is 10 minutes you will find 10/60 = 1/6 of the consumed power, if the timer interval is 1 minute just 1/60!
* Maybe you number format and /or delimiter is wrong. This Matlab might import the decimal places as seperate column or ignore them
* The data recorded might include text like "undervoltage", "overvoltage" or "N/A" instead of numbers in any column, which also might lead to errors parsing the CSV with the standard functions.
I have done a similar import in GNU Octave (a free "Matlab clone") - not able to deal with all special cases seen in the logfiles so far.
Best regards
