openhabforum.de

Hallo zusammen,

ich verzweifle gerade an meiner Homekit Integration.

Ich habe ein Hoftor, welches mit einem Shelly zum öffnen und schließen angesteuert wird. Das Item ist in OH so angelegt, dass es einen Exploration Timer hat, der nach betätigen des Schalters, diesen wieder auf "OFF" setzt. Damit weiß OH natürlich nicht, ob das Tor offen oder geschlossen ist.

Um den Status zu erhalten, habe ich einen Reedkontakt, der in einem zweiten ITEM den Status nachhält.

Nun würde ich gerne den Status aus dem zweiten Item an Homekit via METADATEN im schaltenden ITEM übergeben, dass Homekit weiß, ob das Tor offen oder geschlossen ist.

Nun die Frage, wie kann ich via METADATEN den Status aus einem zweiten Item übergeben? Oder bin ich mit meinem Ansatz auf dem falschen Weg?

Grüße aus dem Süden

Das Problem an dieser Stelle ist, dass es sich um zwei voneinander unabhängige Eigenschaften des Tors handelt. Grundsätzlich kannst Du die bedingt auch über ein Item abbilden, aber nicht über Metadaten.
Ein Item "Hoftor" wäre dann (gewöhnlich) ein Rollershutter Item (!), denn dieses kennt Befehle UP/DOWN/STOP und die Status 0 - 100. Du kannst dann also den Zustand (offen/geschlossen) über einen Wert 0 bzw. 100 abbilden und das Tor mittels UP/DOWN öffnen bzw. schließen.
Das gerht aber nicht direkt, stattdessen musst Du den Status über eine Rule füllen und den Steuerbefehl an ein anderes Item weiterleiten (ebenfalls per Rule). Insgesamt hast Du dann drei Items, eines zum temporären schließen des Steuerkontakts, eines für die Rückmeldung offen/geschlossen und eines, in dem die beiden Teilaspekte zusammengefasst sind, damit das ganze z.B. über einen Sprachbefehl steuerbar ist.

Gewöhnlich würde ich im Übrigen zwei Reedkontakte erwarten, einen für "vollständig geschlossen" und einen für "vollständig geöffnet", macht dann insgesamt 4 Items.

Ich habe hier Doppelflügel Tore, d.h. zwei Antriebe, die Rückmeldung erfolgt über die Auswertung der Motorspannung und Messung der Laufzeit. Die notwendigen Abgriffe habe ich in der Motorsteuerung "eingepflegt" (passend angelötet...)

Hallo @udo1toni - vielen Dank für die ausführliche Antwort.

Ich habe auch ein doppelflügiges Hoftor mit zwei Sommer-Antrieben. Die Steuerung ist relativ simpel über einen Impuls. Dieser löst bei Betätigung eine Aktion aus.

- Wenn vollständig geschlossen, öffnet das Tor.
- Wenn vollständig geöffnet, schleißt das Tor.
- Betätigung bei fahrt, stoppt das Tor. Wenn nun wieder eine Betätigung erfolgt, wird die gegenläufige Aktion ausgeführt (Also -> Betätigung 1: Tor fährt auf. Betätigung 2: bei Fahrt aus Betätigung 1 - Tor wird gestoppt. Betätigung 3: nach Stopp - Tor wird geschlossen.)


-----

Wenn ich dich nun richtig verstanden habe, würde ich dies so realisieren. Allerdings ohne Rollershutter, da mein Tor nur Impuls und keine 100 % oder Laufzeiten versteht.

Item Hoftor Steuerung: Steuert das Hoftor mittels Impuls und Auto OFF im Item als Switch
Item Hoftor Status: Enthält den Status aus dem Reedkontakt "Offen" oder "Geschlossen"
Item Hoftor: Enthält den Status durch "Offen" oder "Geschlossen" als Switch

--> Die Meldung der Zustände erfolgt dann mittels Rule aus dem Reedkontakt in das Item Hoftor.

Korrekt?

VG

Ah.
Ja, ich habe hier auch einen Sommer Torantrieb Ich habe je Motor antiparallel zwei Optokoppler mit passendem Vorwiderstand angeschlossen und bekomme so die Fahrtrichtung und -dauer pro Torflügel (Motor fährt auf -> Kontakt 1 geschlossen, Motor fährt zu -> Kontakt 2 geschlossen, Motor steht -> Kontakte offen). Daraus ergibt sich, zusammen mit der Information, wie lange eine komplette Torfahrt dauert der Öffnungsgrad in %.
Zum Ansteuern der Tore habe ich zwei weitere Optokoppler an die Tastereingänge geklemmt (Ein-/zweiflügelig). Dazu gehört ein 6-fach Binärmodul, welches die vier Ausgangssignale und 2 Eingangssignale nach knx verbindet (weil ich eh knx verbaut habe...). Über knx reiche ich die Zustände nach openHAB weiter und sende die Steuerbefehle zur Torsteuerung.
In openHAB habe ich dann ein paar Rules, welche sich darum kümmern, die Laufzeiten zu messen und in Rollershutter Items passend zu speichern. Für Positionsfahrten funktioniert das entsprechend, wenn der Torflügel 23 Sekunden Fahrtzeit von geschlossen zu offen benötigt, muss man ja lediglich
23 Sekunden mal Position in Prozent (also x/100) rechnen und nach dem Startbefehl nach der errechneten Zeit einen weiteren Start (in diesem Fall natürlich Stopp - das Tor fährt ja) Befehl senden.

Aber natürlich ist die genaue Positionierung eher eine Spielerei. Ich habe auch Bilder für das Tor gemalt die über das Rollershutter Item gesteuert werden - wobei das ein anderes Item ist... Das Bild zeigt ein Doppeltor, bei dem wahlweise nur eine Hälfte auf steht, da habe ich damals (... 2012) etwas schummeln müssen und diesen Teil der Steuerung seither nicht mehr angefasst... Könnte ich mal etwas zeitgemäßer gestalten...

Uhhh, das klingt nach einem Riesen Projekt. Das überschreitet meine Möglichkeiten aber echt Hut ab!

Ich habe hier etwas geschummelt Ich gehe über einen Shelly.

Also mein Kommunikationsweg ist:

Sommer <--> Shelly <--> OPENHab <--> KNX bzw. HomeKIT

-----

Noch eine Frage zu meinem Aufbau:

udo1toni hat geschrieben: ↑18. Dez 2024 16:11 Item Hoftor Steuerung: Steuert das Hoftor mittels Impuls und Auto OFF im Item als Switch
Item Hoftor Status: Enthält den Status aus dem Reedkontakt "Offen" oder "Geschlossen"
Item Hoftor: Enthält den Status durch "Offen" oder "Geschlossen" als Switch

--> Die Meldung der Zustände erfolgt dann mittels Rule aus dem Reedkontakt in das Item Hoftor.

Die Rule für die ITEMS müsste doch eigentlich einmal aus dem Item Hoftor Status zu Item Hoftor bei Veränderung mittels Rule den Status übergeben. Und zusätzlich müsste das ITEM Item Hoftor bei Auslösen aus HomeKIT den Befehl mittels Rule an Item Hoftor Steuerung geben.

Problem: Dies würde ja eine ordentliche Schleife erschaffen... wie kann ich dies umgehen?

Absinthe hat geschrieben: ↑18. Dez 2024 16:32 Problem: Dies würde ja eine ordentliche Schleife erschaffen... wie kann ich dies umgehen?

Auf den ersten Blick ja, aber nein.
Angenommen: Und zwei Rules: Der wesentliche Unterschied: die eine Rule triggert bei einem Befehl an das Proxy Item, die andere Rule triggert bei einer Status Änderung des echten Torzustands.
In der UI verwendest Du ausschließlich das Item yardGateProxy. Schaltest Du dieses Item um (egal ob nun von ON auf OFF oder von OFF auf ON), triggert die erste Rule und sendet ein ON an das Item yardGateControl. Dieses ist mit dem Switch Channel des Shelly gekoppelt und sorgt dafür, dass das Relais anzieht. Wegen des expire Eintrags wird nach einer Sekunde automatisch wieder ein OFF gesendet und das Relais fällt ab.
Wenn sich der Status des Items yardGateState ändert, triggert die zweite Rule und sendet - abhängig vom neuen Status des Items - ein Status Update an yardGateProxy. Der Witz ist aber, dass dieses Status Update nur dafür sorgt, dass das Item auf die entsprechende Stellung wechselt. Ein Befehl wird dabei aber nicht gesendet und somit wird auch nicht die erste Rule ausgelöst. autoupdate="false" sorgt dafür, dass der Status des Items tatsächlich ausschließlich durch Status Updates geändert wird, aber nicht durch einen gesendeten Befehl.

Weil Du nur einen Kontakt hast, wirst Du das Problem haben, dass einer der beiden Status "verfrüht" gemeldet wird (je nachdem, ob der Kontakt bei vollständig geschlossenem Tor oder bei vollständig geöffnetem Tor ausgelöst wird - auf dem Rückweg wechselt der Kontakt dann den Status zu Beginn der Fahrt.

@Udo1toni Wieder einmal klasse erklärt - VIELEN DANK.

Ich scheitere nur leider an der Rule mit dem Status...

Da ich meine Rules in der GUI schreibe, funktioniert dies leider nicht sooooo... Ich habe dies mal versucht zu "Übersetzen"... leider funktioniert dies nicht...
Wo liegt mein Denkfehler?

Das Schlüsselwort ist if, nicht IF.
Groß/Kleinschreibung ist in openHAB wichtig.

tadaaaa - das wars

@udo1toni - vielen Dank und schöne Weihnachten!