Wie verbiete ich einem Rollo runter zu gehen - Immer!

Hallo.

Ich habe mir zwei Rollos mit dem Aquara Jalousien hoch/runter Dings smart gemacht.
Weil es mir schon passiert ist, dass ich ein Fenster nicht auf kipp (kein Problem), sondern richtig offen hatt, fing das Rollo runter, das Fenster war im weg und schubbs waren Knicke drin.

Um dies im Rahmen von Automationen zu verhindern habe ich mir an den beiden Fenstern, zwei Fensterkontakte angebracht. Einer schaut ob gekippt & offen ist und der andere ich so angebracht, dass er bei gekippt nicht meldet, wohl aber wenn richtig offen.

Soweit, so schön.

Frage:
Gibt es eine Möglichkeit der Aquara Entität, als auch den beiden Buttons (für Hoch und Runter am Gerät selbst), es grundsätzlich zu “verbieten”, rauf oder runte rzu gehen?
Für die Entitäten vielleicht? Aber für die beiden mechanischen Buttons wohl kaum, oder?

Hat das jemand schon mal anders gelöst oder hat ne clevere Idee, abgesehen von “da muss der Mensch halt mal aufpassen”? (Oops, das bin dann ja ich. Verflixt :slight_smile: )

VG
Andreas

Hat das Gerät eine Kinder Sicherung(Child look) die man anschalten kann?

Mir würde da einfallen eine Template Rollo Entität zu erstellen, da kann man Bedingungen mit einbauen und fragst so das Fenster ab und steuerst darüber die eigentliche Entität.
Musst dann halt überall im Dashboard dann die Template Entität hinterlegen.

LG

1 „Gefällt mir“

Hallo, ich würde eine Automation erstellen. Mit dem Auslöser Rollo fährt herunter und der Bedingung Fenster offen. Die Aktion wäre dann Rollo hochfahren

Guter Ansatz, aber ich würde eher sagen, der Befehl müsste lauten “Stop” und nicht “Hochfahren”. Bei meinen Aktoren funktioniert das so. Habe hier einen Beispielcode für eine Automation in der GUI erstellt (funktioniert auch), die Sensoren müssen selbstverständlich angepasst werden:

alias: Absicherung Rollo
description: "Verhindert das versehenliche Schließen der Jalousie, wenn das Fenster geöffnet ist"
triggers:
  - trigger: state
    entity_id:
      - cover.rolloschalter_fensterxyz
    to: closing
conditions:
  - condition: state
    entity_id: binary_sensor.fenstersensor_xyz_contact
    state: "on"
actions:
  - action: cover.stop_cover
    metadata: {}
    data: {}
    target:
      entity_id: cover.rolloschalter_fensterxyz
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: Schließ zuerst das Fenster, du Depp!
      title: Rollo Warnung
mode: single

Ob man die Benachrichtigung auch macht, welchen Inhalt sie hat und an welches Gerät (kann auch ein Voice Assistant oder das Smartphone sein) sie gehen soll, lässt sich individuell entscheiden :grinning_face_with_smiling_eyes:

1 „Gefällt mir“

Ich würde hochfahren aus Sicherheitsgründen bevorzugen. Denn je nach Reaktionszeit des Aktors könnte das Rollo schon einige Millimeter bis Zentimeter nach unten gefahren sein. Bei mehrmaligen verbotenen schließen des Rollos könnte es dann doch zu einen Crash kommen. Was duch ein wieder hochfahren verhindert wird.

1 „Gefällt mir“

Ich hab’s mit der obigen Automation getestet: bei mir setzt der Motor sich keinen Millimeter in Bewegung, weil der Aktor sofort auf “Stop” schaltet. Kann aber sein, dass manche Geräte auch träger reagieren. Ich werde nachher vielleicht mal testen, was er macht, wenn ich anstelle von “Stop” auf “Hochfahren” umstelle, ist ja kein Aufwand :wink:

Update: ich muss meine Aussage von oben revidieren. Wenn ich den Schalter (egal, ob virtuell oder am echten Schalter) 10 - 20 mal kurz hintereinander auslöse, kann man eine Bewegung des Rollos nach unten erkennen.

Das ist aber unabhängig davon, welche der beiden Varianten ich wähle.

Vielleicht ist es nur bei meinem Aktor so, aber er geht niemals direkt von “Runterfahren” auf “Hochfahren”, sondern geht immer auf “Stop”. Um also den von dir genannten Effekt zu vermeiden, dass irgendwann nach dem zigmaligen Auslösen der Automation (was zwar eigentlich idiotisch wäre, aber es gibt nichts, was es nicht gibt) die Jalousie zerknittert, muss man eigentlich nach dem “Stop” oder dem ersten “Hochfahren”-Befehl (was auf dasselbe hinauskommt) eine Verzögerung einbauen und dann eine weitere “Hochfahren” Anweisung geben.

Das wäre aber zu einfach: der Aktor merkt sich aufgrund der Kalibrierung den Stand des Rollos anhand der vergangenen Zeit. Da aber jeweils keine Sekunde vergangen ist, sich das Rollo aber trotzdem nach unten bewegt hat, ist gemäß der Kalibrierung das Rollo ganz oben, obwohl es das nicht ist. Deswegen ist die Kalibrierung korrumpiert und die Jalousie fährt nicht mehr ganz hoch.

Ich habe dann vor dem Stop eine Verzögerung von 2 Sekunden eingebaut (in denen hoffentlich noch nichts passiert, weil die Jalousie noch genug Luft hat, bis sie auf das geöffnete Fenster trifft), vor dem Wiederhochfahren eine Pause von 3 Sekunden eingebaut und nochmal getestet: Wenn man sich schlau/idiotisch genug anstellt und andauernd das Runterfahren bei geöffnetem Fenster auslösen will (und damit die Automation auslöst), verschluckt sich die Automation auch und die Jalousie fährt nicht mehr ganz hoch (und teilweise vorher aufgrund der mehrfachen zwei Sekunden auch zu weit herunter).

Eine zu 100 % idiotensichere Lösung konnte ich leider nicht finden, aber vielleicht gibt es ja noch weitere Leute hier, die sich das einmal ansehen möchten.

Hier ist mein bisheriger Zwischenstand:

alias: Absicherung Rollo
description: >-
  Verhindert das versehenliche Schließen der Jalousie, wenn das Fenster geöffnet
  ist
triggers:
  - trigger: state
    entity_id:
      - cover.rolloschalter_fensteryxz
    to: closing
conditions:
  - condition: state
    entity_id: binary_sensor.fenstersensor_contact
    state: "on"
actions:
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - action: cover.stop_cover
    metadata: {}
    data: {}
    target:
      entity_id: cover.rolloschalter_fensterxyz
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: Schließ zuerst das Fenster, du Depp!
      title: Rollo Warnung
  - delay:
      hours: 0
      minutes: 0
      seconds: 3
      milliseconds: 0
  - action: cover.open_cover
    metadata: {}
    data: {}
    target:
      entity_id: cover.rolloschalter_fensterxyz
    enabled: true
mode: single

Also versteh ich das richtig das mehrfaches Auslösen der Automation ein Kuddelmuddel auslöst.

Dann könntest du die Automation (oder Teile davon dann vllt. ein Split in zwei Automationen) “sperren” solange sie bereits ausgeführt wird.

Als einen Helfer “Schalter” (Boolsche Var) erstellen nennen der normalerweise AUS ist

Am Beginn Automation Status abfragen, wenn AUS ausführen als erste Aktion auf EIN stellen und am Ende der Automation wieder auf AUS

Geht natürlich auch mit Timer - Nur wenn Timer nicht läuft Automation starten - 1 Schritt Timer starten

Vielleicht noch was was hilft a la Latenz - Werte zwischenspeichern - regelmässig Fenstersensor abfragen und den Wert in einer Boolschen Variable/Helfer speichern - in der Automation den Helfer abfragen nicht den Sensor. Ich vermute du verwendest Zigbee da hab ich schon mal “Stau” erlebt bei zu viel “Paketverkehr” v.A. etwas weiter weg vom Coordinator mit lower LQI.

Ich verstehe nicht, wieso Du erstmal zwei Sekunden wartest. Aber die Automatisierung startet kein zweites Mal, wenn sie noch am laufen ist.
Das heißt, dass dann entsprechend auch nichts gestoppt wird und während der Wartezeit das Ganze weiter herunter fährt.

Du kannst allerdings den Modus auf Neustart stellen, wodurch die Automatisierung dann von vorne startet.
Oder auf parallel, wodurch sie dann mehrfach ausgeführt würde, was vermutlich das sinnvollste wäre.

Bei Deinem Szenario sprechen wir allerdings auch nicht mehr von einer Unachtsamkeit sondern Vorsatz.

Ich kenne niemanden, der 10 - 20 mal versehentlich auf einen Schalter drückt.

2 „Gefällt mir“

Ich habe es - wie auch oben ausführlich beschrieben - einfach getestet: wenn ich die 2 Sekunden nicht einbaue, registriert die Kalibrierung die geringe Bewegung des Rollos bzw. der Jalousie nicht, weil sie nach dem Zeitverlauf in Sekunden arbeitet.

Es war nicht mein Szenario, sondern der Einwand von @rstuck. Dass ich das mehrfache Auslösen für idiotisch halte, hatte ich geschrieben. Es ist auch nicht so, dass ich diese Automation bräuchte, es war eher so, dass ich mir das für @Mister-Burns angesehen habe.

Dann wären wir zumindest schon mal zwei :wink:

Ich habe den Einwand aus Erfahrung eingebracht, in der Wohnung meiner Tochter war ein Aktor verbaut der träge reagierte, sowohl das Senden des Status als auch das reagieren auf Befehle. Wenn der Aktor des TE direkt reagiert braucht es keine Sicherheit.
Zudem kenne ich auch niemanden der einen Schalter 10 bis 20 mal ausversehen betätigt. Idioten, die das absichtlich machen, schon.

1 „Gefällt mir“

In dem Fall zeige mir doch bitte eine Automatisierung, die verhindert, dass jemand vom HA Server den Stecker zieht …

Geht nicht? :exploding_head:

Denke realistisch sollte es schon bleiben …

2 „Gefällt mir“

Ich bin schon davon ausgegangen das er das macht … wie sonnst soll sich eine Automation sonst “verschlucken”? Hab Parallel laufende Automationen mit Prävention von Zigbee-Flooding.

Ich muss da dem User schon zustimmen - WorstCase-Szenarien gibt es - ich hab so einen Vater mit 70 Jahren für den ich extra einen “Deppenmodus” in Automationen eingebaut hab (er soll das Wort nie hören) - der würde 10 x auf den falschen Schalter drücken wenn das Licht nicht angeht und damit die E-Heizung einschalten. Und ja ist ein “Trotzmodus” auch dabei wie bei kleinen Kindern ganz analog zu “zu Fleiß”=absichtlich Mutter ignorieren.

So sind Menschen halt.

Finde das richtige Kabel, finde überhaupt mal das Raspberry - oh - es ist in einem verschlossenen Serverschrank.

Erklär mir wie mein Vater zwischen 3 Raspberries unterscheiden soll - den überfordert schon ein TouchScreen.

Welche Optionen hat er? Strom aus? Dann gibts kein Fernsehen mehr, keine Kühlschränke, …

In Haushalten muss man sowohl mit Infantilität als auch Senilität umgehen (zwei Seiten derselben Medaillie). Nicht umsonst haben viele Smart-Devices einen Child-Lock. Und philosophisch gilt - man war ein Kind, man wird wieder zum Kind.

(Always) ”Expect the Unexpected” - Muss man wirklich auf die Mikrowellenverpackung schreiben das man seinen Hamster nicht in ihr trocknen soll?

Ich hab mehrere Raspis in Betrieb an zwei kommt mein Vater nicht ran und ein Kind aufgrund der Höhe schon gar nicht.

Manchmal will man aber das Raspi via Automation abschalten/neu starten. z.B. wenn ein paar Sensoren alle 5 Tage mal abkacken und du grad in Graz bist und nicht in Wien.

Dann gibts ne STONITH-Automatisierung - zu viele Fehler triggern “Shoot the other Node in the Head” (Strom aus / Strom an / Reboot)

Mein Vater bräuchte dafür eine Brechstange.

Tut sie nicht. Aber während der Ausführung reagiert sie nicht auf ein weiteres drücken. Dadurch bleibt der runter fahren Befehl ggf. unkorrigiert bestehen. Zumindest für einige Sekunden. Und wenn man mehrfach hintereinander drückt … Daher das langsame absenken in diesem Fall.
Wird Dank der Verzögerung aber immer ein Problem bleiben.

Wie viele Raspberries gibt es denn in diesem Szenario, von denen regulär der Stecker gezogen werden soll?

In diesem Fall ist ja aber nicht die Technik sondern der Hardware Schalter das Problem.

Und für solche Sonderfälle gibt es von Schalter abbauen bis z.B. Zigbee Schalter verwenden eine Menge Möglichkeiten.

Wenn es zum Beispiel ein Shelly 2PM ist, sollte es sogar die Möglichkeit geben alles mit einem Gerät zu machen, falls man auch die auf detached schalten kann.

In dem Fall könnte man dann sogar automatisiert den Schalter direkt oder nur über den HA Umweg reagieren lassen.

Es ist also nicht so, dass es keine Möglichkeit geben würde es sicher zu lösen. Nur ist das nicht die (alleinige) Aufgabe einer HA Automatisierung, wenn die angeschlossene Hardware das Problem ist!

Ich weiß jetzt nicht. Mit wie vielen Hamstern und Mikrowellen bleibt der besagte, senile Vater denn regelmäßig alleine?

Siehst. Schalter abbauen, Problem gelöst.

Dann solltest Du dringend Deine Konfiguration überprüfen. Außerdem würde ich empfehlen dies per Automation zu tun sobald der Sensor ausfällt oder eben alle X Tage, wenn so verlässlich problematisch. Dafür gibt es ja Automatisierungen. Was Du tun möchtest wäre ein Fernzugriff. Oder zieht der senile Vater den Stecker, damit der Neustart eingeleitet wird? In dem Fall habe ich eine Idee woher die Probleme mit den Sensoren kommen könnten …
Aber Du merkst schon, dass das nicht mal mehr im entferntesten mit einem Beispiel / Vergleich zu tun hat? :rofl:

Es würde vermutlich sehr off Topic Dir jetzt zu erklären wieso das harte Ausschalten von Geräten wie einem Raspberry eine extrem dumme Idee ist …

Können wir gerne per PN oder einem neuen Thema diskutieren. Hat nur mit der Frage alles nichts mehr zu tun!

Nun ja, eine Steuerungsmöglichkeit ist gegeben und die kann man auch ohne weitere Investitionen erst mal optimieren.

Shellys aller Varianten vom Plug bis zum 3em in mehrfacher Installation use ich schon lang.

Du verstehst es nicht, gell?

Nehmen wir ein dummes Beispiel:

Besitzer des Rollos/Fenster bekocht grad seine Gäste und einer der Gäste drückt 10x auf “runterfahren” weils ihm zu sonnig ist und der Knopf so hübsch ist für “Rollo runter” weil er gar nicht versteht/verstehen kann WARUM im Falle des offenen Fensters das Rollo streikt. Der drückt dann halt “ein paar Mal” bevor er den Gastgeber in der Küche stört/fragt.

Fängt das keine Logik ab ist das Trum hin - sogar ganz ohne Senilität oder Kindsein.

Warum sollte man “Schalter abbauen” - Lichtschalter auch? Weil über Smartphone gehts eh.

Nonsense-Lösung.

:pencil2: by tarag: restliches Fullquote entfernt

Dann solltest Du dringend Deine Konfiguration überprüfen. Außerdem würde ich empfehlen dies per Automation zu tun sobald der Sensor ausfällt oder eben alle X Tage, wenn so verlässlich problematisch

[/quote]

Auf diesem Raspberry Zero läuft nicht mal ein HA - das hat NULL mit HA zu tun. Ein Raspberry Zero mit 512mb RAM HA? LoL - nicht ernsthaft, oder?

Die Automation im HA steuert Zigbeedevices (5v für 1wire-bus-sensoren ON/OFF) und wichtiger einen shelly 1pm via WIFI - Warum? Tja, erklärs mir warum die 4k-cam sich spontan entscheidet alle paar Tage “abzumelden” - und ich habs mit zwei identen Modellen probiert btw. :wink:

Das kannst du ruhig öffentlich machen - davon haben mehr Diskutanten was

STONITH ist immer nur eine Ausnahmesituation, NIEMALS die Regel

Dazu gibt es Vorstufen - wie bspw. das die Sensoren am GPIO-Header angeschlossen eine eigene 5V-Spannungsversorgung haben und VOR einem kompletten STONITH nur die Sensor-Spannungsversorgung gekappt/reaktiviert wird.

Und wenn sich deine 4k-Videokamera/Webcam die alle 15 min 3 Shots macht sich vom rasperry zero verabschiedet gibts nur A) Ein-/Ausstecken oder B) STONITH

Mehr Kontrolle hast du halt nicht bei Raspberries(Zero)

Der bis dahin schon lange eine Warnung bekommen hat. Aber Du hast interessante Gäste …
Insbesondere weil der Gast ungefragt und wiederholt Schalter des (mutmaßlich) Rollladen drückt, während das Fenster offen ist …

Naja … Eine gewisse Beschränktheit gehört meiner Meinung nach schon dazu, wenn man in fremden Wohnungen bewusst Dinge tut, die offensichtlich dumm sind.
Da frage ich mich, wie die Menschheit vor Smart Home überlebt hat. Rollladen Motoren gibt es seit den 1950ern…

Damit der senile Mensch aus Deinem Szenario bei geöffnetem Fenster, alleine in der Wohnung, keinen Schaden anrichten kann. Aber wer spricht von Lichtschaltern?!

Und das hat noch welchen Bezug zum Rollladen?

Dann eröffne dafür bitte ein neues Thema oder nutze einfach die Suchfunktion. :wink:

Aber bitte lass uns aufhören diesen Thread zu zerstören. Insbesondere, da es Dir offensichtlich nicht um die Thematik selbst geht.

woher soll der Gast das wissen das Rollo dann kaputt geht? Drückst du nicht auf einen Lichtschalter und gehst im dunklen aufs Klo?

Wie ist das mit besoffenen Gästen?

Kennst DAU? Dümmster anzunehmender User - eine Maxime im Produkt/Softwaredesign.

Du scheinst ja “Vollprofi” zu sein - so stellst du dich dar - und schon die Erwartungshaltung das jeder das sein muss und keine Fehler passieren dürfen spricht für das genaue Gegenteil.

Vollprofis rechnen mit dem DAU, versuchen soweit wie möglich das vermeintlich unmögliche zu bedenken und integrieren. Ob in Software, Automationen, Skripten, … das ist Vollprofi.

Nicht jemand der sich darstellt als Alleschecker und Andere nur für “dumm” erklärt, du lebst vielleicht in einem SingleHaushalt?

Wärs dein Rolladen der Kaputt gegangen ist würdest du auch drüber nachdenken das in Zukunft zu vermeiden und DAU/Deppensicher.

Eh keinen nur dein Gefasel das man das mit HA doch im Griff haben sollte und du mein Setup zwar nicht kennst, nicht verstanden hast usf.

Ganz schön viel Meinung für so wenig Ahnung und Erfahrung.

Ernsthaft? Wenn Du eine Automation entwickelt hast, dass die meine Vase nicht runterwerfen können, können wir reden.

Ansonsten wird nur immer offensichtlicher, dass es Dir nicht um die eigentliche Thematik geht!

Du sprachst von Gästen?!

Persönliche Abwertungen haben hier nichts verloren!

@tarag ist kein Noob und Stammgast im Forum seit mehreren Jahren. Er versucht jedem bestmöglich zu helfen, das Forum lebt von gegenseitigen Respekt und freundlichen miteinander…. Just my 2ct

2 „Gefällt mir“

Danke Dir vielmals - hat genau das bewirkt, was ich brauchte

2 „Gefällt mir“