[Gelöst] Idee: AKC/NACK-Flag in virtuellem Device für Fernbed.-LED-Rückmeldung?

[Pfriemler]

Angeregt zum Wiki-Eintrag zur 12-Tasten-Fernbedienung hatte ich selbst mal ein bischen herumexperimentiert, aber noch nicht den Lösungsansatz dort verfolgt. Es wird dort ja beschrieben, dass die Komposition der Rückmeldung in Echtzeit mitunter zeitkritisch ist...

Meine Aufgabenstellung: Ich möchte den Zustand eines Geräte per Fernbedienung abfragen .
Es ist ja problemlos möglich, einen virtuellen Aktor in FHEM mit einer realen HM-Fernbedienung zu koppeln und dadurch ein grünes Licht in der FB  als ACK für den gesendeten Befehl zu bekommen, unabhängig von weiteren Aktionen. Eine einfache Statusabfrage ließe sich m.E. nun allein dadurch erledigen, indem man die ACK-Meldung entweder sendet - oder eben nicht.

Hierfür würde ich mir ein (neues?) Attribut beim virtuellen Aktor vorstellen. Das kann ich durch ein Notify, verursacht durch das zu überwachende Gerät, entsprechend setzen und im Falle einer Fernbedienungsaktion wäre kein weiterer Aufwand nötig.

Konkret:
1. Garagentor wird durch Neigungssensor überwacht. Bei Statusänderung des Tores setzt dieser ein Flag bzw. ein Attribut im zur Fernbedienung gepeerten virtuellen Aktor, etwa ACK=no für offenes und AKC=yes für geschlossenes Tor.
2. Wird die vorgesehene Taste an der Fernbedienung kurz gedrückt, wird nur der virtuelle Aktor quasi als Dummy umgeschaltet, sendet nun aber nur ein ACK, wenn das Attribut entsprechend gesetzt ist, sonst keines. Damit würde ich an der FB grünes Licht für ¨Tor geschlossen¨ bekommen, sonst rot. Ob die FB FHEM erreicht hat oder andere Probleme vorliegen, würde hier keine Rolle spielen.
3. Ein langer Tastendruck wird per Notify abgefangen und zum Schalten des Garagentorantriebes benutzt. Die LED-Rückmeldung wäre hier zwar dann auch ggf. rot, aber das wäre hinnehmbar. (Ideal: unterschiedliches ACK je nach Länge des Tastendrucks ...)

So könnte ich mit nur einer Taste auf der FB den Status abfragen und eine Schaltaktion auslösen, je nachdem wie lange ich drücke...

Wäre das für die Entwicklung interessant?
Welche Probleme wären schon jetzt zu erwarten?
Gibt es vielleicht schon eine andere oder bessere Lösung?

Fragt
grüßend
Pfriemler

Geht nich gips nich

[martinp876]

Aktuell wird ein ACK gesendet, wenn der virtuelle Aktor gepeert ist.
peeren eines virtuellen Aktors geht eigentlich einfach über das setzen des Attributs peerIDs.
Wenn du also das Attribut peerIDs setzt (mit der peerID des FB-buttons natürlich) oder leerst / löschst bekommst du ein ack oder eben nicht

[Pfriemler]

Hm, wir bleiben ja in FHEM. Das peerID-Attribut hatte ich mit realen Homematic-Komponenten schon angefasst, natürlich recht erfolglos. Bin daher inzwischen peerChan gewöhnt und das Anlernen... Der Wald vor Bäumen...

Geht nich gips nich

[martinp876]

Reale Komponenten haben die peers (natürlich) intern (im Flash ) gespeichert. In FHEM kann ich nur darstellen, was ich aus den Devices auslese...
Es wird nicht empfohlen, das Attribut zu ändern - es ändert ja das Flash nicht!

Bei Virtuellen Entities ist das (auch natürlich) anders. Da ist kein flash, ist ja auch keine Komponente. Wenn du also hier das Attribut änderst ist das eine komplett andere geschichte - "das ist ja IM virtuellen Device".
Eine allgemeine Empfehlung ist dies nicht, nur für deine NACK spielerei.

[Pfriemler]

Richtig, Martin, so hatte ich mir das auch gedacht - ein Ändern des Attributs eines virtuellen Devices sollte hier reichen.
Aktuell funktioniert es aber (noch) nicht.

Ich habe einen Handsender FB4V mit den Buttons ~_Btn1 bis _Btn4. Btn2 ist gepeert mit dem Button1 eines virtuellen Aktors, HMACK1_Btn1. Das funktioniert statisch einwandfrei.

Ändere ich jetzt per Notify auf den Neigungssensor das Attribut "peerIDs" dieses virtuellen Aktors, so wird dies auch richtig in den Eigenschaften angezeigt.

Code Auswählen Erweitern

define GaragentorClosing notify Garagentor:closed attr HMACK1_Btn1 peerIDs 2547B402 # das ist die ID des Fernbedienungsknopfes
define GaragentorOpening notify Garagentor:open attr HMACK1_Btn1 peerIDs 000000
Im Falle von 000000 oder auch 123456 verschwindet der Eintrag "peerList" aus den Internals des HMACK1_Btn1. In der Attributliste erscheint unter peerIDs der gerade gesetzte Eintrag immer.
Wenn ich bspw. als peerIDs die peerID eines existierenden HMACK2_Btn4 (FBAC0304) eintrage,

Code Auswählen Erweitern

define GaragentorOpening notify Garagentor:open attr HMACK1_Btn1 peerIDs FBACe0304
wird durch das Betätigen des Neigungssensors in den Internals richtig die "peerList" auf  HMACK2_Btn4 geändert und angezeigt. Die Rückänderung bei schließendem Tor klappt ebenso.

Soweit ist alles richtig.

Allein die Fernbedienung leuchtet bei jeder Tastenbetätigung grün, obwohl ich das gepeerte Gerät zu HMACK1_Btn1 ja gerade angeblich erfolgreich geändert habe, so dass dessen Betätigungsrückmeldung eigentlich ins Nirvana gehen sollte.
Und das einzige gepeerte Gerät zu dem Knopf auf der Fernbedienung ist eben der virtuelle Button HMACK1_Btn1.

Wat nu?

[martinp876]

da war ein ack zu großzügig.

Sollte morgen im Update behoben sein

[Pfriemler]

Oh, danke. Ich zweifelte schon wieder an mir. Kann ich leider erst nächste Woche testen, da unterwegs. Meldung folgt.

Geht nich gips nich

[Pfriemler]

da war ein ack zu großzügig. Sollte morgen im Update behoben sein

Update erfolgt, Funktion ohne weitere Änderung jetzt einwandfrei. Das "Problem" ist für mich gelöst, danke!