Garagentoröffner mit Alexa "simulieren"

[Stonemuc]

Hallo Leute,

ich habe ein Problem, mein Garagentor "vernünftig" zu realisieren - vielleicht hat jemand eine Idee wie ich das einfach lösen kann....ich seh den Wald vor lauter Bäumen vermutlich niicht.
Mal zur Grundinstallation - Das Garagentor ist am Tastereingang über ein Relais über ein Eltako FMZ14 angeschlossen - dieses liefert wie z.B. ein Türöffner den Impuls zum Öfnnen und Schließen - funktioniert wunderbar, gibt aber keine Rückmeldung, ob das Tor offen oder geschlossen ist.
Deshalb habe ich zusätzlich einen kleinen Schaltkontakt über ein Eltako FTS14EM am Tor angebracht, der die Information liefert, ob das Tor geschlossen oder geöffnet ist. - funktioniert an sich auch wunderbar.

Nun aber zum Problem - ich habe jetzt zwei Devices, die mir die Information zu einem Garagentor geben.
Wie kann ich nun das Garagentor so in alexa einbinden, dass ich es mit Garagentor auf oder zu steuern kann?

Aktuell läuft es ohne Rückmeldung in alexa, da ich einen dummy als switch angelegt habe, der dann per notify das FMZ14 schaltet und den FHEM Dummy wieder auf off setzt. Allerdings sage ich jetzt zum Öffnen und Schließen immer "Alexa Garage An"
Find ich unbefriedigend.

Ich würde gern das FMZ14 direkt als Garagentor in alexa einbinden und müsste ja dann entsprechend die geforderten Werte per userReadings einbinden, denke ich....vielleicht kann mir da jemand helfen, der sich in FHEM und besonders mit den alexa mappings gut auskennt.
Ich hab alexa über den FHEM Connector verbunden. Die devices poste ich gleich noch...

Hier das Garagentor im FMZ14:

Code Auswählen Erweitern

Internals: DEF FFD1DD41 FUUID 626d2d60-f33f-37e6-4a32-c42cbc13ea28324d IODev TCM_ESP3_0 LASTInputDev TCM_ESP3_0 MSGCNT 37 NAME Garagentor NR 539 NTFY_ORDER 50-Garagentor STATE Aus TCM_ESP3_0_DestinationID FFFFFFFF TCM_ESP3_0_MSGCNT 37 TCM_ESP3_0_PacketType 1 TCM_ESP3_0_RSSI -57 TCM_ESP3_0_ReceivingQuality excellent TCM_ESP3_0_RepeatingCounter 0 TCM_ESP3_0_SubTelNum 3 TCM_ESP3_0_TIME 2022-05-05 10:56:56 TYPE EnOcean READINGS: 2022-05-01 09:58:50 IODev TCM_ESP3_0 2022-05-05 10:56:56 buttons pressed 2022-04-30 18:17:01 channelA A0 2022-05-05 10:56:56 channelB BI 2022-05-05 10:56:56 state BI 2022-04-30 14:36:48 teach RPS teach-in accepted EEP F6-02-01 Manufacturer: no ID helper: Attributes: IODev TCM_ESP3_0 alexaName Garagentor comMode confirm creator autocreate eep F6-02-01 eventMap AI:An A0:Aus genericDeviceType garage group Außen/Garage manufID 00D room EnOcean,alexa stateFormat channelA subDef FF9E6DC3 subType switch switchMode switch teachMethod RPS updateState yes webCmd An:Aus   

Hier der Kontaktschalter über FTS14EM:

Code Auswählen Erweitern

Internals: DEF FFBED086
FUUID 626bb6a0-f33f-37e6-2db8-0c160975120c58e4 IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 10
NAME Garagentorkontakt
NR 534
NTFY_ORDER 50-Garagentorkontakt
STATE zu
TYPE EnOcean

READINGS:
2022-05-01 09:58:50 IODev TCM_ESP3_0
2022-05-02 17:55:59 buttons released
2022-05-02 11:39:05 channelB B0
2022-05-02 17:55:59 state released
2022-04-29 11:57:52 teach RPS teach-in accepted EEP F6-02-01 Manufacturer: no ID
helper:
Attributes:
IODev TCM_ESP3_0
creator autocreate
eep F6-02-01
eventMap pressed:offen released:zu
manufID 00D model Eltako_FTS12
room EnOcean
stateFormat buttons
subType switch
teachMethod RPS   

Und der Garagen dummy zum Schalten in FHEM:

Code Auswählen Erweitern

  Internals: FUUID 626da041-f33f-37e6-ee4a-7ea128062e632a9d NAME Garage NR 541 STATE off TYPE dummy READINGS: 2022-05-05 10:56:51 state Aus Attributes: alexaName Garage eventMap An:on Aus:off genericDeviceType switch room alexa setList on off webCmd An:Aus   

[Beta-User]

Es gibt vermutlich viele Wege, die zum Zeil führen, dummy ist erfahrungsgemäß "der schlechteste"...

Meine Idee: Einen readingsProxy für den Torzustand definieren, und dann die "auf"- und "zu"-Befehle auf ein anderes Device (den Impuls-Aktor) umlenken. Sowas ähnliches hatten wir hier mal diskutiert: https://forum.fhem.de/index.php/topic,124240.msg1190483.html#msg1190483

(Mit RHASSPY ginge es unmittelbar, den Kontakt (also das "Basisdevice" für den o.g. readingsProxy) zu verwenden und das Kommando auf ein anderes Device umzulenken; ob sowas bei alexa auch geht, entzieht sich meiner Kenntnis).

Nachtrag noch zu dem "sidekick" in readingsProxy - vielleicht etwas besser zusammengefaßt:
https://forum.fhem.de/index.php/topic,124522.msg1190933.html#msg1190933

[mr_petz]

Über 2 Routinen in der App würde es auch gehen:
Routine 1:

Name: Garage auf

wenn: Alexa, Garage auf

Aktion: Garagentor

Modus: an



Routine 2:

Name: Garage zu

wenn: Alexa, Garage zu

Aktion: Garagentor

Modus: aus

[Stonemuc]

Die Sache mit dem readingsProxy hört sich grundsätlich vielversprechend an....muss ich mich mal reindenken bzw. mal schauen ob ich das irgendwie hinbekomme, das hab ich noch nie benutzt/benötigt und komme da sicher allein nicht so weit.

@mr_petz:
Ich möchte keine Routine in der App dafür erstellen, da ich versuchen will, dass device so hinzubekommen, dass es von alexa automatisch richtig als Garagentor erkannt wird.
Und da der Taster ja nur einen Impuls sendet, reagiert das Ding für auf und zu immer auf "An", da ja der aktuelle Status vom Tor dem device nicht bekannt ist, sondern in einem seperaten device hinterlegt ist...

[Beta-User]

Die Sache mit dem readingsProxy hört sich grundsätlich vielversprechend an....muss ich mich mal reindenken bzw. mal schauen ob ich das irgendwie hinbekomme, das hab ich noch nie benutzt/benötigt und komme da sicher allein nicht so weit.

Na ja, das hört sich im ersten Moment immer "wild" an, aber im Prinzip ist es simpel:
- Es wird immer auf genau ein Reading aus einem anderen Device verwiesen und das "beobachtet" (insoweit ein ganz normaler Event-Handler)
- ValueFn() kann dann den "abgegriffenen" Wert mehr oder weniger beliebig manipulieren ("mappen", oder z.B. auch einzelne Werte komplett ignorieren), das ist also so ähnlich wie eventMap oder stateFormat, nur dass das Ergebnis "permanent" ist;
- und man kann eben mit der setFn() "beliebige" Befehle absetzen (muss allerdings aufpassen, dass das Format jeweils gelesen werden kann, wenn man Variablen übergeben muss, was hier aber ja gar nicht der Fall ist).

Dafür bekommt man dann eben ein Device, in dem "alles beieinander" ist...

Bin opimistisch, dass du das hinbekommst, helfe aber bei Bedarf gerne .
Die größere Schwierigkeit dürfte sein, alexa das so unterzuschieben, dass es ganz auf oder zu geht (für RHASSPY wäre das wohl "genericDeviceType blind")

[Stonemuc]

Ed gibt wohl ein generic device garage mit den folgenden benötigten Readings - in Klammern mit den erforderlichen Werten:

CurrentDoorState (OPEN = 0 CLOSED = 1 OPENING = 2 CLOSING = 3 STOPPED = 4)
TargetDoorState( OPEN = 0 CLOSED = 1)
ObstructionDetected ( True/False) - wobei ich da einfach einen festen Wert false reinschreiben werde und mit einem notify oder doif reagieren möchte, wenn das Tor in Zeit X kein Rückmeldung gegeben hat und dann false reinschreibe.

Ich muss jetzt das pressed/released vom device Garagentorkontakt  auf 0/1 CurrentDoorState vom Proxy mappen und außerdem noch so weitermappen, dass ich TargetDoorState mit 0/1 so weitermappe, dass es dann den An Befehl an das device Garagentor sendet.

Code Auswählen Erweitern

define Garagentest readingsProxy Garagentorkontakt:buttons
attr Garagentest setFn { my $do=$CMD eq
attr Garagentest eventMap 0:auf 1:zu
attr Garegantest setList auf zu
attr Garagentest webCmd auf:zu

Weiter komm ich gerade nicht - was mache ich mit setFN und valueFN?

[Beta-User]

Also:

Bitte immer erst mit den "basics" anfangen, webCmd und eventMap gehören da definitiv nicht dazu.

(Nur) das hier sollte erst mal reichen:

Code Auswählen Erweitern

define Garagentest readingsProxy Garagentorkontakt:buttons
attr Garagentest valueFn {($VALUE eq 'released') ? "0":"1"}
attr Garagentest setFn {fhem('<hier kommt dein Befehl an "Garagentor" rein, und vielleicht ein setreading-Befehl auf den state des readingsProxy>')}
attr Garegantest setList open close
Wobei setList etwas "auf Verdacht" ist, vermutlich ist es egal, was da im Moment steht. Es könnte "interessant" werden, wenn man ein "setreading" absetzen würde (k.A., ob das nebenwirkungsfrei geht)...

[Stonemuc]

Okay...vielen Dank - jetzt hab ich das mit dem Value zumindest mal verstanden. Ich bin da falsch rangegangen.

Mein Set Befehl lautet ja im Prinzip immer - egal für open und close:

Code Auswählen Erweitern

set Garagentor AI

Weil er ja nur kurz den An Befehl sendet und dann nach 3 Sekunden wieder zurück auf Aus springt....
Kann ich setFn dann so schreiben? Oder vermische ich da wieder was mit den Klammern und Perl-Befehlen?

Code Auswählen Erweitern

attr Garagentest setFn {if(Garagentest("CurrentDoorState") eq "0") fhem('set Garagentor AI, setreading Garegentest TargetDoorState 1') else fhem('set Garagentor AI, setreading Garagentest TargetDoorState 0')}

Und wie bekomme ich das CurrentDorrState dann hin als Reading? Muss ich das noch mit einem user Readings lösen? Wie z.B.:

Code Auswählen Erweitern

attr Garagentor userReadings CurrentDoorState {if(ReadingsVal("Garagentorkontakt","buttons","") eq "pressed") {return 0} elseif (ReadingsVal("Garagentorkontakt","buttons","") eq "released") {return 1}},TargetDoorState {0}, ObstructionDetected {false}

[Stonemuc]

@Beta-User:
ich bekomm das einfach nicht hin - verrückt....das Reading state ist beim Proxy weiterhin pressed oder released und nicht 0 oder 1 mit dem valueFN...

Kann ich mit userReadings arbeiten?

[Beta-User]

Hmmm, weiß nicht, an was das ggf. liegt.

Habe das mal mit einem Test-dummy simuliert, und da klappt es wie es soll:

Code Auswählen Erweitern

defmod Garagentest readingsProxy Garagentorkontakt:buttons
attr Garagentest room Steuerung->Test
attr Garagentest setFn { fhem('set Garagentorkontakt AI;; setreading Garagentest state '. ($CMD eq 'open' ?'3':'4'))}
attr Garagentest setList open close
attr Garagentest valueFn {($VALUE eq 'released') ? '0':'1'}

defmod Garagentorkontakt dummy
attr Garagentorkontakt readingList buttons
attr Garagentorkontakt room Steuerung->Test
attr Garagentorkontakt setList buttons:released,pressed

(ob jetzt 3 und 4 vertauscht sind, habe ich nicht geprüft).

[Stonemuc]

So sieht mein List vom Garagentest aus:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        Garagentorkontakt:buttons
   DEVICE     Garagentorkontakt
   FUUID      6273e0ea-f33f-37e6-acef-ffe68bfabb57631a
   NAME       Garagentest
   NOTIFYDEV  global,Garagentorkontakt
   NR         868
   NTFY_ORDER 50-Garagentest
   READING    buttons
   STATE      released
   TYPE       readingsProxy
   CONTENT:
     Garagentorkontakt 1
   READINGS:
     2022-05-09 10:41:48   CurrentDoorState 0
     2022-05-05 17:01:55   ObstructionDetected false
     2022-05-05 17:01:05   TargetDoorState 1
     2022-05-05 16:37:31   state           released
Attributes:
   alexaName  Garagentest
   genericDeviceType garage
   room       Haus,alexa
   setList    open close
   valueFn    {($VALUE eq 'released') ? '0':'1'}

Er gibt mir da kein 0 oder 1 aus...nur das released im state

[Beta-User]

Hmm, dann hängt es m.E. entweder am EnOcean-Modul oder an dem eventMap.

Kannst du das mal löschen und dann nochmal testen?

Ggf. muss man die valueFn()-Abfrage erweitern, ungetestet/ungeprüft:

Code Auswählen Erweitern

{($VALUE eq 'released' || $VALUE eq 'offen') ? '0':'1'}

[Stonemuc]

Es liegt tatsächlich am eventMap....wenn ich das lösche, ändert er den state auf das gewünschte Verhalten

[Beta-User]

Es liegt tatsächlich am eventMap....wenn ich das lösche, ändert er den state auf das gewünschte Verhalten

OK, und was ist mit

Ggf. muss man die valueFn()-Abfrage erweitern[...]

[Stonemuc]

Hab ich zuerst versucht....geht aber auch nicht. Also liegt es tatsächlich am eventmap..oder ich muss den ersten Teil rauslassen
Jetzt muss ich es nur noch hiermit verwurschteln:


https://forum.fhem.de/index.php/topic,93879.0.html

[Beta-User]

Hab ich zuerst versucht....geht aber auch nicht. Also liegt es tatsächlich am eventmap..oder ich muss den ersten Teil rauslassen

Na ja, letztlich ist der readingsProxy (ggf. noch mit einem stateFormat) als Frontend-Device in FHEMWEB tauglich, von daher würde ich die EnOcean-Stammdevices halt als funktionale Devices auffassen und nichts rummappen...

Jetzt muss ich es nur noch hiermit verwurschteln:
https://forum.fhem.de/index.php/topic,93879.0.html

Diesen Thread habe ich bereits mehrfach gelesen und immer noch den Eindruck, dass das "verkorkst" ist, was und wie das da versucht wird... Ich kenne aber "alexa" nicht und kann daher auch keinen wirklich zielführenden Vorschlag machen. Vermutlich klappt es, wenn du den readingsProxy mit gDT "blind" versiehst und dann (notfalls) mit "ganz auf"-Sprachanweisungen "fütterst".

[Stonemuc]

So...den ReadingsProxy habe ich jetzt soweit fertig und er funktioniert wie er soll....vielen Dank an dich, Beta-User.

Jetzt muss ich nur noch das ganze mit den mappings über Alexa verbinden...bzw. den richtigen genericDeviceType finden.....
Hat jemand zufällig damit Erfahrung?
Wenn ich z.B. garage oder GarageDoorOpener nehme, wird es in der alexa App nur als Kontakt angezeigt. Wobei ich überhaupt nich weiß, ob alexa auch einen GarageDoorOpener aus dem homekit kennt....jedenfalls ändern sich in der App nichts, wenn ich von garage auf den GarageDoorOpener umstelle. Die richtigen benötigten Charakteristiken für garage kenne ich leider auch nicht - weiß jemand wo ich die finden kann?

Ansonsten muss ich mal mit lock experiementieren - da gibt es mir bei einem dummy im state zumindest lock locked und lock unlocked aus. Da muss ich nur wieder neu mappen - zumindest gibt es da LockCurrentState und LockTargetState laut Wiki: https://wiki.fhem.de/wiki/Alexa_und_Mappings

[Stonemuc]

@Beta-User:

Ich hab noch eine Frage bezüglich der Verbindung vom Proxy mit dem valueFn und einer externen Status Änderung von alexa.
Wenn ich den state über valueFn aktualisiere, aber in der Alexa App schalte, springt er immer wieder auf den Wert vom Device im valueFn zurück, da der sich ja nicht unmittelbar ändert, sondern erst wenn das Tor die Endlage erreicht hat - also aktuell z.B. SECURED

Fällt dir da was ein, außer dass ich den Sensor verlege und den Anschlag bei geschlossenen Tor mache, der dann schneller reagiert?

[Beta-User]

Hmm, im Prinzip kannst du in valueFn() auch komplexeren Code eintragen, und z.B. dann auch bei einem "Relay hat geschaltet" (ReadingsVal-Abfrage) erst mal einen Zwischenzustand eintragen, solange das Teil (üblicherweise) fährt.

Hier habe ich übrigens einen weiteren Schnippsel gepostet, mit dem du dann ggf. dafür sorgen könntest, dass nach dem Ablauf dieser Zeit dann der state vollends auf die (wahrscheinliche) Endlage angepaßt wird: https://forum.fhem.de/index.php/topic,127649.msg1221523.html#msg1221523

Generell würde ich aber dazu tendieren, den "Geschlossen"-Zustand mit dem Anschlag/Sensor abzufragen, das ist imo die wichtigere Info gegenüber "ganz offen".

[Stonemuc]

Wie kann ich denn die valueFn Abfrage um folgende Bedingung erweitern?

Ich habe einen zweiten Sensor verbaut, der jetzt Garagentorkontak_vorn heißt, den möchte ich jetzt folgendermaßen zusammen mit dem Garagentorkontakt abfragen:

Der ReadingsProxy soll sofort den state  UNSECURED annehmen, wenn der Garagentorkontakt_vorn geöffnet (released) wird und der Wert vom Garagentorkontakt in dem Moment noch nicht pressed ist. Umgekehrt soll der ReadingsProxy sofort den Wert SECURED annehmen, wenn der Garakentorkontakt  geöffnet wird (released) und der Wert vom Garagentorkontakt_vorn noch nicht pressed ist....

Gibt es dafür ne Möglichkeit?

[Beta-User]

Gibt es dafür ne Möglichkeit?

Prinzipiell ist readingsProxy darauf ausgelegt, genau ein Reading von genau einem Device zu überwachen.

Ergo geht es, aber nur, wenn du den konsolidierten Zustand von den zwei Kontakten "irgendwie" in einem Reading zusammenbringst. Wie üblich gibt es dafür viele Wege, und was davon ggf. die beste ist, hängt davon ab, wann es an welchen Devices welche Events gibt. Da das hier zwei Devices zu sein scheinen (?), ist der Weg über userReadings vermutlich nicht der übersichtlichste, Alternativen wären eher notify oder combine (nur über das Forum/Ankündigungen), bzw. monitoring oder DOIF.