Beiträge von Naderio

Etwas Details aus dem nodeRED zu meinem Workaround:

Ich habe es jetzt nach vielen Tests so gebaut, dass der Kontakt-Status nicht mehr direkt Befehle ausführt, sondern nur in eine Variable im Flow gesichert wird. Zusätzlich wird die Öffnung auch in eine DB gesichert, damit ich es visualisieren kann, das ist aber hier nicht wichtig.

Der "Inject" unten links feuert alle 15 Sekunden die Funktion ab, welche nur den Kontakt aus der Variable holt und prüft, ob "has changed" gesetzt ist. Wenn ja, dann wird ein Befehl abgesetzt (hier mit MQTT). So ist zumindest sichergestellt, dass ich diese Überschneidung nicht habe und wirklich nur ein einziger Befehl alle 15 Sekunden kommen kann

pasted-from-clipboard.png

Ich denke nicht, dass diese Lösung ideal ist, allerdings funktioniert es für mich erstmal.
Nun ist die Frage, ob dieses Verhalten von anderen nachgestellt werden kann und es sich damit um einen Bug handelt.

LG

Naderio

Ich habe das vielleicht nicht ganz ordentlich beschrieben. Ich versuche es nochmal detaillierter.

1. Fenster ist offen (kipp), angezeigt wird "offen, 8°C"

2. Fenster wird geschlossen, angezeigt wird "geschlossen, 19°C"

3. Fenster wird geöffner (kipp), angezeigt wird "offen, 8°C"

4. Fenster wird auf "schwing" geändert. Sequenz schließen, öffnen (sehr schnell)

5. Angezeigt wird "offen, 8°C"

6. Fenster wird geschlossen, angezeigt wird "geschlossen, 8°C" <= Fehler

Es ist also eine falsche Temperatur im geschlossenen Status (contact=true).

Es passiert sowohl bei HTTP, als auch bei MQTT. Also scheint es wahrscheinlich ein Bug zu sein. Ich vermute, dass die Befehle nicht nacheinander auf den Temperatur-Wert zugreifen und es irgendwie zu Überschneidungen kommt.

Ich konnte das auch provozieren, indem ich im Browser sehr schnell beide Befehle nacheinander gefeuert habe. Vielleicht kann das mal jemand probieren?

Moin!

Ich habe meinen ersten Test-TRV im Bad montiert, um mal einen zu Testen.
Bin soweit ziemlich zufrieden und werde wohl mehr davon kaufen.

Ich habe nun einen Fenstersensor hinzugefügt, der über den /window?state=open/close  die temperatur reduziert wenn das Fenster auf ist.

Wenn ich nun das Fenster von kipp auf schwing öffne, geht der Kontakt, logisch, zu -> auf innerhalb von kürzester Zeit. Der Öffnungsstatus ist korrekt, aber die Temperatur geht im geschlossenen Status nicht immer wieder hoch, sondern bleibt auf 8°C.

Ich habe dann auf MQTT umgestellt, weil ich mir dachte dass es vielleicht an den zwei fast zeitgleichen http-requests liegt, aber auch mit MQTT bleibt das problem. Ich feure beim öffnen eine 8 an shellies/mein-shelly/thermostat/0/command/target_t, beim schließen eine 19. Aber die 19 kommt beim schnellen hin und her nicht an.

Kennt jemand das Probem und es ist ggf. ein Bug, oder muss ich hier eventuell anders verfahren?

LG
Naderio

Sind die TRVs wirklich "offline", oder dauert es nur ein wenig (ein paar sekunden) bis die Webseite ausgegeben wird?

Zitat

Ich habe ausschließlich MikroTik CAPs.

Wenn du viele APs hast deren Netze sich weit überschneiden, kann das etwas frickelig werden. Du kannst eine Signalstärke in den APs einstellen, wo bei Unterschreitung der Client gekickt wird und damit dann zum nächsten AP wechselt.

Damit kannst du sicherstellen dass deine Geräte nur mit den „guten“ APs Verbunden sind.

Es beruhigt mich, dass es schonmal nicht nur bei mir zu diesem Problem kommt

Das mit dem „Another file transfer in progress“ ist ärgerlich. Darüber bin ich auch gestolpert.

Man kann die Dateien nicht gleichzeitig laden sondern muss warten bis eine Datei komplett geladen wurde, bevor die nächste angefangen werden darf.

Ich werde dann die Idee mit dem Download verwerfen und stattdessen minütlich über /status die Daten selber in eine DB loggen

Moin

Ich habe vor ein paar Tagen meine Shelly 3EM in die Verteilung gebaut und erfreue mich seither an den Daten.

Nun ist mir beim Programmieren einer Schnittstelle aufgefallen, dass die CSV Daten der Phase B aufsteigend gespeichert werden, die anderen Phasen absteigend.

pasted-from-clipboard.png

Der Tageswechsel ist entsprechend nur bei Phase B fließend, Phasen A und C "springen" nach der aktuellen Uhrzeit auf 00:00.

pasted-from-clipboard.png

Die Drei CSV Dateien sind alle direkt nacheinander heruntergeladen und ich habe das verhalten mit einem weiteren Download bestätigen können.

Das Ganze ist jetzt kein Gamechanger, aber wirkt auf mich erstmal wie ein Bug, oder ein Feature welches ich nicht begreife
Vielleicht kann mir irgendwer die Sache etwas beleuchten?

Danke und Grüße

Thomas