Beiträge von micha06de

    Hallo,

    ich habe seit über einem halben Jahr mehrere Shelly BLU Motion im Einsatz und hatte noch nie einen Fehlalarm. Gestern, ich war gerade außer Haus essen, gab es zweimal kurz hintereinander, sogar innerhalb der "Blindzeit", Alarme (habe die Geräte dem Bereich "Alarm" zugeordnet). Zu meinem Entsetzen wurde beim zweiten Alarm eine Lichtstärke von "24" (vorher "0") gemeldet. Ich dachte gleich an das Schlimmste (Einbrecher), zum Glück habe ich noch Kameras, über deren Bilder/Aufzeichnungen ich den Verdacht ausräumen konnte.

    Ich frage mich (und Euch) aber trotzdem: Was kann das gewesen sein? Dass ein PIR Sensor ab und zu Fehlalarme durch Insekten, Warmluftschleier, etc. auslöst ist bekannt, aber wie kam der Wert für die Lichtstärke zustande? Es war draußen schon dunkel und in dem Raum war auch kein Licht an, die Werte vorher und nachher betrugen "0". (Gibt es einen extra Lichtsensor, oder läuft das über den PIR?)

    Kann aber auch sein, dass der Melder einfach nur falsch montiert wurde. Ohne Einblick in deinen Keller ist das schwer zu beurteilen.

    Wichtig bei Bewegungsmelder ist die Montage quer zur Laufrichtung, also mal solle weder draufzugehen noch von ihm weg gehend gescannt werden.

    Es muss auch beachtet werden, dass der PIR-Sensor nur dann in den Raum schaut, wenn der BLU Motion an einer Wand montiert ist, ist er an einer Decke montiert, schaut er nach unten und der Bereich der Bewegungserkennung ist stark eingeschränkt. S. Bild.

    IMG_7950.jpg

    Na dann brauchst Du die HTTP Shortcuts App die Kurzbefehle absendet, der Befehl ist ja immer der gleiche:

    https://shelly-xx-eu.shelly.cloud/scene/enable=f…-eingef%C3%BCgt

    es kommt

    Code
    404    "Requested method was not found"

    Mit einer so aufgebauten URK funktioniert es nicht. Wenn ich es richtig recheriert habe, funktioniert es nur mit der POST Methode (wie im ersten in #4 verlinkten Video gezeigt).

    BTW: Wo kann man die Parameter der Cloud-API nachlesen. Die URLs die Google dazu bei Shelly findet liefern nur "404".

    Um die Ventile gangbar zu halten gibt es doch unter Settings die Option "Clog Prevention":

    image.png

    ... aber ist ansonsten genau das, was du suchst., oder nicht?

    Danke, aber das ist es eher nicht. Wenn die Ventile ganz offen sind verklebt auch nichts und es wird auch kein Strom verbraucht. Hauptsächlich geht es mir ja darum, dass die Ventile nicht ständig regeln, wenn die Raumtemperatur durch die Witterung zufällig um den Sollwert schwankt.

    Vielleicht war das der Bug, der mit dem FW Update behoben wurde (?)

    Das war es wohl nicht, es passiert immer noch. Das liegt wohl daran, dass der BLU Door Windows im Beacon Mode bei jeder Statusmeldung (auch wenn die Tür sich nicht bewegt), den Status "Closed" sendet, das Script auslöst und ausschaltet. Aber das passiert nicht immer, was ich nicht verstehe (deshalb auch mein neues Thema dazu im Bereich Scripting).

    Hallo,

    bis vor kurzem nahm ich an, ich habe es verstanden, bis ich auf das Problem stieß (Script schaltet nicht, wenn das Bluetooth Gateway auf dem Shelly Plus Plug S, der geschaltet werden soll, aktiv ist).

    micha06de
    1. Mai 2024 um 12:00

    Ich habe auf dem Plus Plug S das Gateway ausgeschaltet und habe das nun auf einem (inzwischen erworbenen) BLU Gateway Stick laufen. So funktioniert es meist, aber nicht immer.

    Aber so ganz verstanden habe ich die Funktionsweise nicht. Wie ist der Übertragungsweg? Klar ist noch, das BLU Gerät (z. B. Door/Windows) sendet ein Statussignal und das Gateway empfängt es. Aber wie dann weiter? Sendet das Gateway eine Art Rundruf an alle BLE fähigen Geräte oder sendet es nur bis das "nächstbeste", es annimmt? Das Problem bei mir ist, dass das Script gelegentlich nicht ausgeführt wird. Kann es sein, dass ein anderer Shelly (ohne Script) das empfängt (ich habe mehrere, aber der, der (meist) reagiert ist in unmittelbarer Nähe zum Gateway?

    Zusätzliche Frage: Das Scripte (s. Zitat) nicht auf dem Gerät, das als Gateway fungiert, funktionieren, ist das Bug oder Feature? Bis zur vorletzten Firmwareversion hat es ja funktioniert.

    Hallo,

    jetzt, wo die Raumtemperatur - ohne dass die Heizanlage in Betrieb ist - um den am TRV eingestellten Sollwert pendelt (21 °C), regelt der TRV fleißig, obwohl es nichts zu regeln gibt, was natürlich Akku kostet.

    Die Frage ist, wie man das am elegantesten verhindert. Man könnte natürlich ein Raumsoll von 30 °C einstellen, aber wenn es in einer Woche wieder kalt sein sollte und geheizt werden muss, ist es umständlich, das jedes Mal und an mehreren Ventilen zu ändern. Hat jemand eine Idee, wie man das Problem möglichst automatisiert lösen könnte? Z. B. Vorlauf- bzw. Kesseltemperatur unter 22 °C - Raumsoll auf 30 °C bzw. "Ventil auf". Für die Messung von Vorlauf- bzw. Kesseltemperatur hätte ich einen Shelly 1 mit Addon zur Verfügung. Aber vielleicht habt ihr ja auch ganz andere und bessere Ideen (?).

    Vor dem Update auf 1.3.0 vom 25.4.2024. hatte ich übrigens ein anderes Problem mit diesem Plus Plug S, er schaltete sich seit einigen Tagen nach ca. 2 min (mal mehr mal weniger) aus, wenn man ihn über die App eingeschaltet hat, nach dem FW Update war das nicht mehr der Fall. Vielleicht war das der Bug, der mit dem FW Update behoben wurde (?)

    Hallo ak233,

    ... Schau mal, ob im Plus Plug S das Bluetooth Gateway deaktiviert ist, mit aktiviertem Gateway funktioniert es nicht.

    Ich hatte das gleiche Problem mit einem Script im Zusammenhang mit einem Shelly BLU Door Window und bin beim Recherchieren auf diesen Betrag gestoßen. Dein Tipp hat auch in meinem Fall geholfen, Danke! Vor dem Update hat es auch mit aktiviertem Gateway funktioniert. Ist das ein Bug oder gibt es einen Grund dafür? Das bedeutet ja, dass ich Plus Geräte, auf denen das BT Gateway aktiviert ist, nicht mehr für Schalthandlungen via Script verwenden kann 😕.