Garagentor mit Homekit steuern

[hardl]

@mickym Hallo mickym, bei mir im VIS läuft es unter
öffnen = 0
stop = 1
zu = 2
lüften = 3
Ich habe das zum Testen einmal in YAHKA eingetragen.
Mit door_command über TargetDoorState und map 0 = 0 und 2 = 1 läuft das Tor richtig, aber die Toranzeige und der Status ändert sich nicht, egal welche Angaben unter CurrentDoorState stehen.

[mickym]

@hardl So ich habe es noch mal angepasst wie es laufen müsste:

Was passiert?

Also man drückt die Kachel und toggelt damit zwischen Schließen und Öffnen, je nachdem was für einen Zustand das Tor hatte.
War das Tor geöffnet - sendet es doorCommand (iobroker = 2) zum Schließen an den Datenpunkt (HomeKit = 1). Stoppen oder sonst was, kann Homekit nicht.

Die Kachel geht in den Animationsmodus und man sieht ... wird geschlossen.

Nun wartet HomeKit solange bis bestätigt der CurrentDoorState den TargetDoorState erreicht und zwar mit ACK=true. Die Animation hört also erst auf bis im CurrentDoorState was ich mit passthrough gemappt habe eine bestätigte 1 steht, das Tor also geschlossen ist. Ich hatte @mike-eg6 ja gebeten die Definition unter common von dem doorState Datenpunkt zu posten, was er leider nicht getan hat, so dass ich einfach davon ausgehe, dass wie bei dem doorCommand hinter dem Text Zahlenwerte stehen (0=Offen, 1=Geschlossen).

Falls dem nicht so ist, dann muss man halt das noch mappen anstelle des passthroughs.

CurrentDoorState im HomeKit kann 5 Werte annehmen, wobei aber nur die 2 Endzustände open und closed brauchbar sind, da im Homekit die anderen Zustände nur über Skripten zu setzen wären.

Also letztlich hört sich das Rädchen erst dann zu drehen auf, bis sich im CurrentDoorState eine 1 für Tor geschlossen und zwar mit ACK=True drin steht (also entweder direkt mit passthrough oder gemappt).

Drückt man nun wieder die Kachel wieder dann ist entweder (je nachdem ob sich der CurrentState = dooState verändert hat), sofort wieder geöffnet oder Homekit wartet eben solange bis endlich der CurrentState den TargetState erreicht hat. Letztlich dreht sich das Rad in der Kachel solange bis der TargetState erreicht wurde.

Umgekehrt verhält es sich dann genauso:

War das Tor geschlossen - sendet es doorCommand (iobroker = 0) zum Öffnen an den Datenpunkt (HomeKit = 0). Stoppen oder sonst was kann Homekit nicht.

Die Kachel geht in den Animationsmodus und man sieht ... wird geöffnet.

Nun wartet HomeKit solange bis bestätigt der CurrentDoorState den TargetDoorState erreicht und zwar mit ACK=true. Die Animation hört also erst auf bis im CurrentDoorState was ich mit passthrough gemappt habe eine bestätigte 0 steht, das Tor also geschlossen ist.

Ändert sich nur der DoorState - weil man das Tor nicht über HomeKit betätigt hat, bekommt man eine Meldung, dass das Tor geöffnet oder geschlossen wurde - je nachdem ob in CurrentDoorState (doorState) eine bestätigte 1 oder 0 steht.

So mehr kann ich nun wirklich nimmer dazu sagen - weil ich das hier nur simuliere.

@mike-eg6 hat weder mit dem ACK-Flag gearbeitet - und ausserdem sind wie gesagt die Zwischenzuständen unbrauchbar und er soll den doorState Punkt und nicht den doorCommand Punkt als CurrentDoorState verwenden. Im Prinzip interessiert HomeKit nur, wann endlich der CurrentDoorState (bestätigt) den TargetDoorState (0 oder 1) annimmt, alles andere ist Nonsense.

[mike-eg6]

@mickym ECHT SUPER EIN GROßES DANKESCHÖN .
Jetzt funkt das auch .
Herzlichen Dank

[MarkusOSX]

Hi alle zusammen,

ich möchte hier kurz die Info zu meiner Lösung für HomematicIP und yahka teilen, für die ich gestern einen Beitrag verfasst hatte. Ich arbeite allerdings nicht mit dem Hörmann-Modul, so lässt sich das für jeden Garagentorantrieb umsetzten.
Beitrag findet ihr hier

Gruss

MarkusOSX

[hardl]

@mickym Vielen Dank für die ausführliche Erklärung, das hat manches plausibler gemacht.

Das Öffnen und Schließen über DoorCommand hat von Anfang an geklappt nur der Status und die Anzeige nicht.
Hier das COMMON von DoorState, es ist vom Typ String:

So habe ich das in Yahka eingegeben:

Aber die Anzeige ändert sich nicht, ob offen oder zu:

Vielleicht kannst Du nochmal drüber schauen.

[mickym]

@hardl lass mal die Gänsefüßchen beim Mapping weg, siehe mein Screenshot.

[hardl]

@mickym Hatte ich zuvor und dann mal mit"". Kein Unterschied.

[mickym]

@hardl Bei Dir steht in der DP Konfig - dass der Datenpunkt nicht beschrieben werden darf - vielleicht hast Du hier noch ein Problem.

Ansonsten befürchte ich, dass ich mit meiner Weisheit am Ende bin, denn dann hast Du es ja exakt so, wie ich das gepostet habe und bei mir funktioniert das in der Simulation.

Bei Dir ist das aber auch nicht die normale HomeApp von Apple - vielleicht liegt es ja auch an der App`?

[hardl]

@mickym Den "write"-Status habe ich mal mit "true" geändert.
Ich verwende immer die EVE-App, in der HOME-App wird das Animationsbild richtig angezeigt, aber mit "schließen..." und das Rad dreht sich ewig, bei geöffnet passt es dort.

[mickym]

@hardl Dann stimmt irgendwas mit dem Mapping nicht.

Du könntest ja nur mal, damit Du es in der App nachvollziehen kannst, ebenfalls simulieren, indem Du selbst einen Datenpunkt anlegst und erst mal mit bestätigtem 0 und 1 schauen, ob die App dann wie gewünscht agiert und dann halt schauen, wo es hängt. ICh hoffe Du verstehst was ich meine.

[hardl]

@mickym Ja, das kann ich mal testen, komme aber erst morgen dazu.

[hardl]

@mickym Hallo mickym, alles ok. Über die angelegten Datenpunkte konnte ich sehen, dass Deine Mappings stimmen.

Kannst Du mir bitte noch sagen, wo ich die "Home/Wiki/Characteristics" finde?

Mein Problem lag bei der EVE-App. Ich bin fälschlicherweise davon ausgegangen, dass die den Status 1:1 zur Home-App abbildet.

Deine Erklärungen haben trotzdem viel zu meinem Verständnis von Yahka beigetragen, danke.

[mickym]

@hardl Ist zwar für NodeRed geschrieben, aber für die Beschreibung der Services ist das auch für den YAHKA Adapter anwendbar:

https://nrchkb.github.io/wiki/introduction/quick-start/

[superbraz]

bitte löschen