Ich habe immer noch das Problem, daß ich unerwünschte Tastendrücke von fakeroku bekomme. Und zwar scheint der Harmony Hub bei längerem Tastendruck (Autorepeat wird aktiviert) immer zusätzlich zur gedrückten Taste auch die DAVOR gedrückte fakeroku-Taste zu senden. Alternativ kann ich mir vorstellen, daß fakeroku selber "alte" Tastendrücke erneut sendet (eher unwahrscheinlich).
Daher habe ich lange in den Source-Code geguckt, aber nur einen Widerspruch entdeckt, leider keine Lösung:
Im Modul fakeRoku_Parse wird die gedrückte Taste richtig erkannt als POST-Message und via DoTrigger an FHEM gemeldet. Als Rückgabewert kommt wohl beabsichtigt ein undef zurück. In fakeRoku_Read wird aber nur dann, wenn $len ungleich 0 ist, ein Rückgabemeldung an den Harmony Hub gesendet. In meinem Fall scheint $len gleich 0 zu sein (sehe den dazu passenden Log-Eintrag). Und genau das verstehe ich nicht, da in $len die Anzahl der gelesenen Zeichen steht - bestimmt ungleich 0, da ja ein POST-Kommando richtig erkannt wird.
Hier die Codezeilen zusammenkopiert:
sub
fakeRoku_Read($)
{
...
$len = sysread($hash->{CD}, $buf, 10240);
...
Log3 $pname, 4, "$name: disconnected" if( !$len );
my $ret;
$ret = fakeRoku_Parse($phash, $hash->{buf}) if( $hash->{buf} );
if( $len ) {
...
syswrite($hash->{CD}, $add_header) if( $add_header );
Log3 $pname, 5, "$name: add header: $add_header" if( $add_header );
...
}
sub
fakeRoku_Parse($$;$$$)
{
...
} elsif( $msg =~ '^POST\s*([^\s]*)\s*HTTP/1.\d' ) {
my $request = $1;
....
DoTrigger( $name, "key$action: $key" );
...
return undef;
}
Im Logfile sehe ich
2020.12.15 10:25:03 4: HarmonyController:listener:40124: disconnected
2020.12.15 10:25:03 5: HarmonyController: POST /keypress/Right HTTP/1.0
d.h. ich sehe ein (unerwartetes) disconnected, da $len gleich 0 ist und folgerichtig keine "add header" Meldung - klar, wenn $len 0 ist. Daher sendet fakeroku keine OK-Meldung an den Harmony Hub. Und das scheint dazu zu führen, daß der Hub das nicht bestätigte Kommando erneut zu senden versucht - eben die unerwünschten Tastendrucke.
Ich verstehe ehrlich gesagt nicht, wieso $len 0 werden kann, da ja Daten vom Hub gesendet und von fakeroku im sysread auch gelesen worden sind. Offenbar gibts irgendwann ein EOF, das aber fakeroku nicht richtig zu verarbeiten scheint.
Würde mich über jegliche Hilfe freuen,
Michael
PS: Vermutlich hilft ein list weiter:
Internals:
FUUID 5e01dce2-f33f-94f4-1d71-c0238116a37103be
HAS_IO::Socket::Multicast 1
ID
NAME HarmonyController
NR 23
NTFY_ORDER 50-HarmonyController
STATE listening
TYPE fakeRoku
fhemHostname imurr9
fhemIP 192.168.178.44
reusePort 0
READINGS:
2021-10-27 07:25:22 state listening
helper:
serial 67b290effd0caddcbe97d49846e01d14
listener:
CONNECTS 9133
FD 8
NAME HarmonyController:listener
NR 54
PNAME HarmonyController
PORT 38605
STATE accepting
TEMPORARY 1
TYPE fakeRoku
connections:
HarmonyController:listener:50101:
FD 18
NAME HarmonyController:listener:50101
NR 6491
PNAME HarmonyController
PORT 38605
STATE listening
TEMPORARY 1
TYPE fakeRoku
buf
phash:
HarmonyController:listener:52714:
FD 20
NAME HarmonyController:listener:52714
NR 9907
PNAME HarmonyController
PORT 38605
STATE listening
TEMPORARY 1
TYPE fakeRoku
buf
phash:
HarmonyController:listener:58208:
FD 19
NAME HarmonyController:listener:58208
NR 7991
PNAME HarmonyController
PORT 38605
STATE listening
TEMPORARY 1
TYPE fakeRoku
buf
phash:
phash:
responder:
FD 4
NAME HarmonyController:responder
NR 53
PNAME HarmonyController
PORT 1900
STATE listening
TEMPORARY 1
TYPE fakeRoku
multicast 1
phash:
Attributes:
fhemIP 192.168.178.44
reusePort 0
serial eba0363542139b59fc8bf26e4872c6f0
verbose 0
