Garagentoröffner mit Alexa "simulieren"

[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.