reportValueUsage, PRESS_CONT und PRESS_LONG_RELEASE events

[Sineos]

Referenz: jens-maus/RaspberryMatic#399

Nachdem ich ein Dummy Programm eingesetzt habe, habe ich festgestellt, dass die Betätigung des HM-PB-6-WM55 wieder mit der grünen LED bestätigt wird. Ich nehme an, das liegt an dem nun gesetzten reportValueUsage.
Dazu hätte ich nun ein paar Fragen an den Experten :-)

1. Macht es Sinn generell für die in RedMatic verwendeten Kanäle die RPC Methode reportValueUsage aufzurufen?
2. Wenn ja, alle Kanäle oder nur Sender wie z.B. der HM-PB-6-WM55
3. reportValueUsage(String address, String value_id, Integer ref_counter)

• address ist klar
• was ist value_id?
• kann für ref_counter immer 1 gesetzt werden oder ist das abhängig von der Anzahl der Verwendungen?

4. Gibt es eine Art Rückkanal, sprich eine Bestätigung dass z.B. ein PRESS_SHORT verarbeitet wurde?

[hobbyquaker]

Soweit ich es verstehe bewirkt ein reportValueUsage dass ein ACK vom rfd zurückgesendet wird, das bewirkt auch das aufleuchten der grünen LED. Bei dem Displaytaster HM-PB-4Dis-WM oder der Fernbedienung HM-RC-Dis-H bestimmt es außerdem darüber ob eine "Displayseite" angezeigt wird oder nicht. Ich denke es ist nicht nötig es überall zu setzen, bei den Displaydingern ist es uU auch unerwünscht wenn man nicht alle Displayseiten nutzen will. Auch ist fraglich ob man den vermehrten Funkverkehr haben will (das ACK geht ja dann zu lasten des CCU DutyCycle) oder ob man auf eine grüne leuchtende LED verzichten mag.
Ich setze es bisher ausschließlich bei Tastern.

Zu 3.: value_id ist soweit ich weiss der Datenpunkt, also z.B. PRESS_SHORT. Allerdings erscheint mir der Parameter irgendwie sinnlos, das ganze wirkt sich immer auf den Kanal aus, es ist glaube ich völlig irrelevant ob man jetzt auf PRESS_SHORT oder PRESS_LONG geht. Aber vielleicht täusche ich mich auch... Ob ref_counter > 1 irgendwas anderes bewirkt als =1 weiss ich nicht, aber ich glaube nicht.

Zu 4.: Ich glaube der rfd bestätigt bei gesetzten reportValueUsage pauschal alles als erfolgreich, da leuchtet immer die grüne LED. Mir wäre nicht bekannt dass man da RPC seitig was beeinflußen könnte.

Insgesamt: auch für mich ist das reportValueUsage Thema immer noch mit vielen Fragezeichen belegt ;-)

[Sineos]

Ich hab ein bisschen rumgespielt. Hier meine Beobachtungen:

Dummy Rega Programm:

• Setzt reportValueUsage
• Baut man ein Skript mit Fehlern als Dummy ein, wird trotzdem "grün" gesendet. Scheint also kein wirklich ausgewerteten Rückkanal zu geben
• Löscht man das Dummy Programm scheint reportValueUsage weiterhin gesetzt zu bleiben. Auch über einen Reboot hinweg

reportValueUsage über RPC Node:

• Verwendeter Parameter: ["OEQ0650679:4","PRESS_SHORT",1]
• Bei der ersten Verwendung wird ein Fehler im Debug Fenster ausgegeben (Payload des return values ist false):
  rpc < binrpc method updateDevice not found: ["nr_BidCos-RF","OEQ0650679:4",1]
• Funktioniert aber trotzdem und der Taster quittiert ab sofort mit grün
• PRESS_SHORT oder PRESS_LONG macht keinen Unterschied, scheint wirklich auf den Kanal zu gehen
• Es wird beim Taster ein CONFIG_PENDING Flag gesetzt
• Weitere Aufrufe der gleichen Methode werden ohne Fehler mit payload = true quittiert
• Mit ["OEQ0650679:4","PRESS_SHORT",0] lässt sich das ganze löschen, d.h. kein grünes quittieren mehr
• Beim Löschen (0) tritt der Fehler nicht auf, es wird aber trotzdem als return false gesendet

Der Sinn von reportValueUsage entzieht sich mir noch etwas...

(was nichts dran ändert, dass mich der buggy PRESS_LONG nervt)

[hobbyquaker]

Der Fehler kommt daher dass der rfd mitteilt dass sich am Gerät was geändert hat (updateDevice), ich diese Methode aber bisher nicht implementiert hab. Habs mal auf die Todo genommen: rdmtc/node-red-contrib-ccu#23
Noch eine Beobachtung die ich gemacht hab: manche Taster (ich glaube es waren Fernbedienungen, der 6-Fach Wandtaster und die Tasterschnittstelle) senden kein PRESS_CONT solange man kein reportValueUsage gesetzt hat, setzt man es kommt der Event.

[Sineos]

Mein 6-fach Wandtaster HM-PB-6-WM55 konnte ich bisher nicht zu einem PRESS_CONT überreden. Der macht nur INSTALL_TEST.
Das ist super nervig, weil man sich damit nur schwer gegen PRESS_SHORT abgrenzen kann, da das auch INSTALL_TEST auslöst.
Ich denke die momentan einzige Lösung wird sein die INSTALL_TEST in den context zu schreiben und erst auf das zweite INSTALL_TEST zu reagieren und schliesslich über einen Timeout den context wieder zu löschen.

[hobbyquaker]

Wichtiger Hinweis siehe jens-maus/RaspberryMatic#399 (comment)