Autor Thema: neues modul fakeRoku um einzelne tasten von einer harmony an fhem zu senden  (Gelesen 108752 mal)

Offline fb-luke

  • New Member
  • *
  • Beiträge: 7
Hi,

ich wollte hier nochmal Feedback geben. Nachdem ich also alle FHEM Module und das raspbian komplett aktualisiert hatte sind keine Fehler mehr aufgetreten.
FAKE ROKU und Harmony etc läuft alles wieder wie gehabt und funktioniert perfekt.

Vielen Dank

LG

Offline mister

  • Full Member
  • ***
  • Beiträge: 247
Hallo zusammen,

lässt sich diese Modul auch auf einer Fritzbox auf der FHEM läuft nutzen? cpan install IO::Socket::Multicast geht ja hier nicht einfach so...

danke!

Offline strategy

  • Full Member
  • ***
  • Beiträge: 119
Hallo zusammen,

ich möchte nur kurz meine Erfahrungen teilen.

Bei mir läuft FHEM auf dem heimischen Server, einer Synology Disk Station.
Installation war problemlos möglich und das Modul ist sofort betriebsbereit.
Da ich aber ein VLAN für meine Iot Geräte - und damit auch den Harmony Hub - habe wurde die Verbindung allerdings nicht hergestellt.

Der Server selbst hat IP-Adressen  sowohl im normalen LAN als auch im IoT VLAN. Das Standard-Interface ist das normale LAN.

Ich konnte das Ganze wie folgt zum Laufen bringen:
1. Ich musste die IP-Adresse des VLAN explizit über das Attribut fhemIP setzen. Hier ist die IP des Servers zu verwenden, kein Subnetz oder ähnliches.
2. Die automatische Erkennung von WLAN Geräten in der Harmony Software hat bei mir nicht funktioniert. Da wurde bei allen Versuchen nichts gefunden. Daher habe ich eine "manuelle Installation" durchgeführt. Als Hersteller "Roku" und als Modell "Roku 3" ausgewählt und ein wenig gewartet.

In der Konstellation wurde meine FakeRoku erfolgreich gefunden und installiert. Läuft jetzt seit einigen Tagen problemlos.

Vielen Dank,
Matthias

Offline Chris_Worms

  • Jr. Member
  • **
  • Beiträge: 85
Hallo,

seit heute konnte ich das fakeRoku nicht mehr mit meiner Harmony bzw dem Hub benutzen. Ich habe dann das fakeRoku aus FHEM und der Harmony Software entfernt (und damit aus allen Aktionen). Anschliessend habe ich mit define roku fakeRoku ein neues fakeRoku angelegt und wollte dann auf dem iPad in der Harmony App und auf dem Mac in der Logitech App das Roku 3 Gerät wieder hinzufügen. Leider finde ich weder auf dem iPad noch in der Logitech-App auf dem Mac das Roku3 Gerät.

Hier ein Listing meines fakeRokus:

Internals:
   FUUID      5fcd47dd-f33f-5a8a-c5d9-9726b0caf5045b2d
   HAS_IO::Socket::Multicast 1
   ID         
   NAME       roku
   NR         1180
   NTFY_ORDER 50-roku
   STATE      listening
   TYPE       fakeRoku
   fhemHostname raspberrypi
   fhemIP     192.168.2.118
   reusePort  1
   READINGS:
     2020-12-06 22:12:35   state           listening
   helper:
     serial     4eb8b1d44b1594dce9993437592017b6
     listener:
       FD         19
       NAME       roku:listener
       NR         1183
       PNAME      roku
       PORT       45005
       STATE      accepting
       TEMPORARY  1
       TYPE       fakeRoku
       connections:
       phash:
     responder:
       FD         18
       NAME       roku:responder
       NR         1182
       PNAME      roku
       PORT       1901
       STATE      listening
       TEMPORARY  1
       TYPE       fakeRoku
       multicast  1
       phash:
Attributes:
   room       harmony
   serial     4eb8b1d44b1594dce9993437592017b6

Mir ist nicht klar warum das plötzlich nicht mehr geht. Vielleicht hat ja jemand von Euch eine Idee.

Danke & Gruß
Chris
Raspberry Pi 2/HM-CFG-LAN/HM-ES-PMSw1-PI/HM-LC-Sw1-PL/HM-Sec-MDIR-2/JeeLink V3/LaCrosse Temp/Humidity/Bluetooh USB Dongle/PebbleBee Bluetooth Tags

FHEM/MySQL/Apache/SmarVisu

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 115
Ich analysiere immer noch mein Problem, daß ich unerwartete fakeRoku-Events sehe (s.o.). Beim Googeln habe ich das Protokol von Roku hier gefunden: https://developer.roku.com/en-gb/docs/developer-program/debugging/external-control-api.md. Dort gibt es auch ein C-Testprogramm namens rokuExternalControl.c, das testweise mit einem Roku-Device kommuniziert: https://github.com/NewSpring/Staff-Roku/blob/master/apps/rokuExternalControl.c Es sendet ein Discovery, dann ein Query nach Apps, dann einige Left/Right, schließlich ein Launch. Das Programm habe ich mal gestartet: Nach der erfolgreichen Rückmeldung der leeren App-Liste bricht die Kommunikation mit fakeRoku ab. Trotzdem werden die Requests weiter gesendet. NACH Beendigung des C-Programms erscheinen ALLE gesendeten Events im Event-Log von fhem, aberr nicht in der erwarteten Reihenfolge, und alle quasi gleichzeitig:

... um nicht Alles zu zitieren hierr abgeschnitten ...
Ich habe immer noch das Problem, daß fakeroku bei mir immer mal wieder nicht richtig funktioniert. Heute habe ich mal fakeroku mit verbose 5 verfolgt, während dieses Testprogramm lief. In dem Logfile sieht man diese Meldungen:
2020.12.15 10:25:03 4: HarmonyController:listener:40134: disconnected
2020.12.15 10:25:03 5: HarmonyController: POST /launch/dev?url=http%3A%2F%2Fvideo.ted.com%2Ftalks%2Fpodcast%2FVilayanurRamachandran_2007_480.mp4&streamformat=mp4 HTTP/1.0


2020.12.15 10:25:03 4: HarmonyController:listener:40110: disconnected
2020.12.15 10:25:03 5: HarmonyController: POST /keydown/Left HTTP/1.0


2020.12.15 10:25:03 4: HarmonyController:listener:40128: disconnected
2020.12.15 10:25:03 5: HarmonyController: POST /keypress/Right HTTP/1.0


2020.12.15 10:25:03 4: HarmonyController:listener:40108: disconnected
2020.12.15 10:25:03 5: HarmonyController: POST /keypress/Home HTTP/1.0


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


2020.12.15 10:25:03 4: HarmonyController:listener:40132: disconnected
2020.12.15 10:25:03 5: HarmonyController: POST /keypress/Right HTTP/1.0


2020.12.15 10:25:03 4: HarmonyController:listener:40120: disconnected
2020.12.15 10:25:03 5: HarmonyController: POST /keyup/Left HTTP/1.0
(und ganz viele discover-Anfragen diversere Gerräte in meinem Netz, weggefiltert - ist schon viel DLNA-Verkehr). Die POST-Meldungen sind genau umgekehrt zur Sendereihenfolge, und die POSTs erscheinen erst, nachdem sich das Testprogramm mit timeout beendet hat. Das Testprogramm erwartet auf jedes POST eine OK-Meldung, und die sendet fakeroku definitiv nicht.

Bitte prüfen, ob fakeroku hier nicht doch einen Bug haben könnte. Vermutlich fällt das normalerweise nicht auf, da der Requester ein timeout haben wird und dann aufgibt, so wie das Testprogramm. Aber nicht immer. Mein Harmony-Hub sendet manchmal mit JEDEM Tastendruck meiner Harmony 950 (auch von nicht-fakeroku-Funktionen) das nicht bestätigte POST nochmal. Und das bedeutet in meinem usecase, daß mit jedem Tastendruck die Lautstärke um 5dB erhöht wird, d.h. für mich ist das ein errnstes Problem. Gott sei Dank passiert das (warum auch immer) nur sehr selten.

Das Testprogramm kann ich gern per email zur Verfügung stellen - ich will es hier nur nicht posten, da ich es selber (siehe meine Post vom Jahresbeginn) aus dem Netz habe.

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 115
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

« Letzte Änderung: 16 November 2021, 14:40:14 von olwaldi »

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 115
Ich habe mal fakeRoku in Zeile 735 geändert und erzwinge die "OK 200" Meldung durch
      if( 1 | $len ) {
        my $add_header;
        ...
Aber mir ist nicht klar, inwieweit das zu unerwünschten Nebenwirkungne führt. Und leider funktioniert das Testprogramm von Roku (vgl. meine früheren Posts hier) trotzdem nicht. Insbesondere sind weiterhin alle POSTs vom Testprogramm in umgekehrter Reihenfolge zur Sendereihenfolge im FHEM-Logfile.

D.h. ich muß hier wohl kapitulieren.


Grüßle, Michael

Nachtrag: Hab' auch mal probiert, ob nach der Änderung weiterhin falsche Events kommen - leider ja. Wenn ich die Taste zum Ausschalten des TV gedrückt halte und so das Autorepeat der Harmony triggere, sehe ich für jedes Repeat ein fakeroku-Event. Und die TV-Steuerung hat absolut nix mit den fakeroku-Geräten zu tun. Ein Bug im Harmony-Hub?!
« Letzte Änderung: 25 November 2021, 15:28:24 von olwaldi »

 

decade-submarginal