Einen ähnlichen Fehler mit V1.8 gibt es auch mit Shelly 2.5/Shelly-Plug/Shelly-Plug-S und der eigenen Shelly-Cloud
Beiträge von DavidShard
-
-
Keiner meiner 5 Shelly 2.5 kann sich nach dem Update zu Cloud verbinden.
Lokal im WLan sind sie erreichbar und steuerbar.
Andere Shelly's (Shelly-Plug, Shelly-Plug-S) sind weiterhin über die Cloud erreichbar.
Ein Shelly-Plug-S was wohl ab und an auch im lokalen WLan vor dem vorletzten Update in der Vergangenheit Probleme hatte (schlechte WLan-Verbindung) will jetzt auch nicht mehr.
Ein Shelly-Plug, im Keller, der bis zum letzten Update keine Probleme hatte, wollte jetzt auch nicht mehr im WLan bleiben.
Meine Vermutung:
WLan ist sensibler geworden.
Warum auch immer.
Vor dem letzten Update lief alles perfekt. Hätte ich doch am Samstag kein "Update all Devices" gemacht ...
Hat sonst jemand mit der Firmware Probleme?
Mein WLan router ist eine Fritzbox 7590 mit aktueller Firmware.
PS:
Wenn ich im WLan die Shelly's 2.5 in Internet/Security zur Cloud verbinden will, dann gibt es nach ein paar Minuten einen Fehler-feedback.
-
Ich möchte den Shelly 2.5 als Steuerung für einen Synchronmotor 50KTYZ mit zwei Endschalter benutzen. Dadurch verhält sich der Motor wie ein Rollo und ich kann dann über die Rollo-Kalibrierung den Motor genau steuern.
Zudem brauche ich auch 3 Temperatursensoren, die man ja an einen einzelnen 1PM anschließen kann. Geht das auch am Shelly 2.5?
Mein Ziel ist eine intelligente Steuerung das Warmwasserboilers, der über Nahwärme beheizt wird.
Als erstes gibt es mehrere Zeitfenster am Tag, bei denen die Nahwärme über 60 Grad heiß ist. Das kann ich mit der Zeitsteuerung abfangen.
Als zweites geht der Thermostat des Boilers vor erreichen der Zieltemperatur immer weiter zu, so das die Zieltemperatur nie ganz erreicht wird und so immer ein Fluss ist. Da sind dann kontinuierlich 0.3kWh, obwohl der Fluss so langsam ist, das das Wasser nicht wirklich geheizt wird. Also Verschwendung. (So 30 Liter/h)
Als drittes ist die Nahwärme außerhalb der Zeitfenster von Punkt 1 unterhalb von der Wassertemperatur im Boiler. Das führt dazu, das wohl keine kWh anfallen, aber die Wärme aus dem Boiler gezogen wird, da ja der Thermostat nicht ganz zu macht bzw. bei Benutzung des Warmwasser der Thermostat grösser auf macht. Dadurch wird also Energie verloren.
Was ich also erreichen will ist:
- Nahwärme höchstens offen innerhalb der Zeitfenster mit mehr als 60 Grad (Bedingung A)
- Temperatur des Wasserboilers unter einem Schwellwert. (Bedingung B)
- Temperatur der Nahwärme über einem Schwellwertes. (Bedingung C) (Die Temperatur der Nahwärme bekommt man erst, wenn das Ventil eine Zeit lang offen ist)
Die Logik soll dann so aussehen (geprüft werden soll alle 5 Minuten in der Reihenfolge):
1. Rollo offen && !C -> schließe Rollo und setze Finish
2. Rollo geschlossen && A && B && !Finish -> öffne Rollo
3. !A -> lösche Finish
Dafür müssen 2 Temperatursensoren angeschlossen werden und die Logik in den Shelly 2.5 geladen werden.
Nun meine Fragen:
Kann ich 2 Temperatursensoren an den Shelly 2.5 anschliessen?
Kann ich die Logik mit der Standardfirmware des Shelly 2.5 im Shelly auswerten, oder brauche ich eine andere Firmware?
Danke schonmal.
-
Dann liegt das Porblem in der Cloud.
Die Shelly selbst haben bei mir die richtige Uhrzeit.
Ich glaube nicht, das es an der Cloud liegt, da Sunrise lokal berechnet wird, wohl aber ohne DST-Auto. Die Berechnung wird wohl nach einem DST Change nicht aktualisiert.
-
In unregelmäßigen Intervallen haut der Kühlschrank, den ich über den Plug messen wollte, den Plug raus. Und dann ist der Kühlschrank aus.
Das passiert mit Max-Power angehakt und auch ohne.
Ohne den Shelly Plug gibt es keine Probleme. Es ist noch nie eine Sicherung raus-geflogen.
Ich tippe mal darauf, das der Shelly Plug die Leistung pro Sekunde misst, und dann sofort der Power-Limiter anschlägt.
Das gleiche würde bei meinen Servern beim Einschalten passieren.
Da muss der Mittelwert über mehrere Messintervalle gebildet werden.
-
Heute sind alle Rollos 1 Stunde zu früh aufgegangen. Eingestellt ist z.B. Sunrise +00:45 das wäre bei mir heute 7:51.Aufgegangen sind sie aber 6:51. Sonnenaufgang 7:06
Als ich das bemerkt habe, habe ich alle wieder zugefahren und DST-Aus in allen gesetzt, in der Hoffnung, das die dann um 7:51 wieder aufgehen. Aber falsch. Sie gingen dann 8:51 auf, also eine Stunde zuspät.
Die Zeitzone war weiterhin Berlin. DST-Aus scheint wohl den GMT Offset ganz rauszunehmen und nicht nur die eine Stunde.
Oder, wurde der Sunrise, nach dem DST-Aus, mit der Localtime mit DST berechnet bzw. kann die Sunriseberechnung nur immer den DST unabhänigig von DST-Aus benutzen?
Was ist euer Vorschlag? Ich versuche als nächstest die Lokaltime auf UTC zu setzen, dann gibts nichts mehr mit DST.