Closed Sineos closed 5 years ago
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 ;-)
Ich hab ein bisschen rumgespielt. Hier meine Beobachtungen:
Dummy Rega Programm:
reportValueUsage
reportValueUsage
weiterhin gesetzt zu bleiben. Auch über einen Reboot hinwegreportValueUsage über RPC Node:
["OEQ0650679:4","PRESS_SHORT",1]
false
):
rpc < binrpc method updateDevice not found: ["nr_BidCos-RF","OEQ0650679:4",1]
PRESS_SHORT
oder PRESS_LONG
macht keinen Unterschied, scheint wirklich auf den Kanal zu gehenCONFIG_PENDING
Flag gesetztpayload = true
quittiert["OEQ0650679:4","PRESS_SHORT",0]
lässt sich das ganze löschen, d.h. kein grünes quittieren mehrfalse
gesendetDer Sinn von reportValueUsage
entzieht sich mir noch etwas...
(was nichts dran ändert, dass mich der buggy PRESS_LONG
nervt)
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: https://github.com/hobbyquaker/node-red-contrib-ccu/issues/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.
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.
Wichtiger Hinweis siehe https://github.com/jens-maus/RaspberryMatic/issues/399#issuecomment-421025442
Referenz: https://github.com/jens-maus/RaspberryMatic/issues/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 gesetztenreportValueUsage
. Dazu hätte ich nun ein paar Fragen an den Experten :-)reportValueUsage
aufzurufen?HM-PB-6-WM55
reportValueUsage(String address, String value_id, Integer ref_counter)
address
ist klarvalue_id
?ref_counter
immer 1 gesetzt werden oder ist das abhängig von der Anzahl der Verwendungen?PRESS_SHORT
verarbeitet wurde?