Ich denke ich sollte für den Zustand meines Garagentors irgendwie einen Sensor erzeugen. Dieser sollte dann anhand der vorhandenen Endschalter ausgeben in welchem Zustand sich mein Tor gerade befindet.
Reizvoll wäre natürlich die gesamte Chamberlain Motorlift ML700 Steuerung auszukoppeln und den Motor direkt über einen entsprechenden Shelly oder was auch immer anzusteuern. Zum einen könnte man da die Fahrtrichtung klar vorgeben (so muss man immer ein wenig raten) zum anderen sollen bestimmte Motorsteuerungen sogar in der Lage sein eine Wunschposition anzufahren (wobei mir noch nicht klar ist wie genau die das machen wollen, ohne Positionssensor?). So könnte man auch eine Automation “Entlüften” erzeugen, welche das Tor, wenn man das Auto z.B. nach einem starken Regenguß in der Garage abgestellt wird, für eine Zeitlang noch einen Spalt offen lässt.
Einzig eine kraftbasierende Hinderniserkennung hat eine solche Steuerung wohl nicht. Ggf. könnte man über integrierte Stromsensoren zumindest einen rudimentären Schutz herstellen (wenn Tor blockiert, dann zieht es mehr Strom als üblich). So einfach ist das aber auch nicht, da die Stromabnahme nicht linear über den Laufweg des Tores ist. Besser wäre natürlich es so zu machen wie Chamberlain mit seiner eigenen Steuerung. Da sind Hall-Sensoren um das Kettenrad, die nehmen Drehrichtung und Drehimpuls auf. Zusätzlich sind Stromsensoren verbaut. Dreht sich der Antrieb also nicht weiter obwohl der müsste, liegt eine Störung vor. Gleiches bei zu hoher Stromabnahme. Zusätzlich zu dieser Sicherung brauche ich aber eh noch eine Hinderniserkennung für den Fahrtweg.
In der Doku von HA habe ich die “Cover” Integration entdeckt, welche auch wohl für Garagentorsteuerungen vorgesehen ist. Mit “Cover” wird wohl alles bezeichnet was einer beweglichen Abdeckung dient, also vom Rolladen, über Jalousie bis zur Toren und Türen.
Wenn ich es richtig verstanden habe kann diese Integration einen Sensor abfragen welcher folgende Status liefert:
- opening: The cover is in the process of opening to reach a set position.
- open: The cover has reached the open position.
- closing: The cover is in the process of closing to reach a set position.
- closed: The cover has reached the closed position.
- unavailable: The entity is currently unavailable.
- unknown: The state is not yet known.
Für meine Begriffe fehlt da aber noch ein Status, nämlich stopped? Die Integration geht ja sonst davon aus das sich das Cover entweder im Endzustand befindet, oder auf dem Weg dahin. Aber man kann es ja auch zwischendrin stoppen?
Falls vorhanden kann man der Integration wohl auch eine Position mit angeben, welche sich zwischen 0 und 100 befindet. Um eine Schwenktor-Position abzufragen könnte man einen Drehwinkel-Encoder (einfachste Variante wäre ein Potentiometer) an einem der Lager des Tores befestigen. Das wäre natürlich die Premium-Variante.
Unabhängig davon würde ich nun versuchen einen Template-Sensor zu erstellen welcher abhängig von den Endschaltern und des letzten Tor-Status den aktuellen Status gemäß der Cover-Integration liefert.
Die Endpositionsschalter habe ich an einem Shelly-UNI als Digitaleingänge verkabelt und den Shelly so eingestellt das die Eingänge als “Switch” und “Detached” sind, also unabhängig von den Relais arbeiten. Ist das Tor geschlossen meldet der als “garagedoor-position-closed” benamte Eingang den Zustand “ON”:
Öffne ich nun das Tor, geht er auf “OFF” (mit ein wenig prellen, heißt das er einige Male zwischen ON und OFF hin und her wechselt bis der Magnet weit genug weg gefahren ist, das macht es etwas tricky!).
Sobald das Tor vollständig geöffnet ist, geht der Eingang “garagedoor-position-opened” auf “ON”.
Beide Eingänge liefere ich als Entitäten zu HA, wo sie als “binary_sensor” verfügbar sind. Schaue ich über die Developer tools den Status nach, sehe ich ihn auch exakt so wiedergegeben:
Nun erzeuge ich in der configuration.yaml (ich habe es in eine separate Datei ausgelagert):
template:
- sensor
- name: garagedoor_status
state: >-
{% if is_state('binary_sensor.garagedoor_garagedoor_position_opened', 'on') %}
{{ 'open' }}
{% elif is_state('binary_sensor.garagedoor_garagedoor_position_closed', 'on') %}
{{ 'closed' }}
{% else %}
{{ 'unknown' }}
{% endif %}
Damit bekomme ich schonmal die Endpositionen. Ein Zustand in dem beide Sensoren “ON” liefern ist technisch nicht möglich, das wäre wenn eine Fehlerzustandsabfrage. Aber wenn beide “OFF” sind kann das bedeuten “Tor fährt auf” oder “Tor fährt zu” oder “Tor steht in einer Zwischenposition”.
Zum entprellen der Reed-Kontakte kann man wohl die “for:” Anweisung nutzen, die besagt das eine Zustandsänderung eines Sensors erst nach einer gewissen Weile, wenn dieser Zustand stabil bleibt, von HA verarbeitet wird. Es heißt: “In Home Assistant, the is_state condition in an automation can be “debounced” or “filtered” to prevent it from triggering too frequently due to minor fluctuations in the state of an entity. This is achieved by using the for: parameter within the is_state condition. Essentially, you specify a duration for which the state must be stable before the automation is triggered.”
Ich sehe aber nicht wie ich eine Debounce-Zeit mittels dem “for:” attribute in das is_state() Kommando einfügen könnte?
So wie es aussieht muss ich wohl einen neuen, entprellten Sensor auf Basis der vorhandenen Reed-Sensoren erstellen.
by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)
