neues modul fakeRoku um einzelne tasten von einer harmony an fhem zu senden

Begonnen von justme1968, 31 März 2016, 14:17:58

Vorheriges Thema - Nächstes Thema

fb-luke

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

mister

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!

strategy

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

Chris_Worms

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

olwaldi

Zitat von: olwaldi am 05 Januar 2020, 09:38:31
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.

olwaldi

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


olwaldi

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?!

olwaldi

Nutze mittlerweile anstelle von fakeroku den Weg über die Harmony Bluetooth MCE Tastatur. Das fakeroku Device habe ich in Harmony und FHEM gelöscht. Seither habe ich kein Problem mehr mit ungewollter Wiederholung von fakeroku-Tasten.

Da ich aber auch bei dem Bluetooth-Weg ein Problem (anderer Natur) mit ungewollte wiederholten Tastendrücken habe, vermute ich mal, daß die wirkliche Ursache meiner Probleme in der Harmony liegt. Langes Googeln hat ergeben, daß insbesondere die Smarthome-Tasten der Harmony 950 oder der Companion oft zu merkwürdigem Verhalten führen. Und die unerwünschten Tastendrücke bei fakeroku waren immer an die Smarthome-Wipptasten +- gebunden. Jetzt bei der Nutzung der MCE-Tastatur-Emulation durch Harmony Hub gibt es IMMER auf den +- Tasten unendliches Autorepeat. Das könnte sogar die beabsichtigte Smathome-Funktionsweise sein, um so ein kontinuierliches Dimmen zu bewirken. Für dieses Problem habe ich einen Workaround gefunden - statt in Harmony auf die +- Tasten direkt einen MCE-Befehl zu legen (leider eben mit Autorepeat), lege ich dort jeweils eine Sequenz an mit dem jeweiligen Befehl. Dann werden die +- Tasten NICHT automatisch wiederholt.

Und vielleicht würde derselbe Workaround auch mein fakeroku-Problem losen - bislang noch nicht ausprobiert.

Daher hier mal meine Frage: Hat außer mir schonmal jemand versucht, mittels fakeroku die Wipptasten +- umzudefinieren? Wenn ja, sollte derselbe Fehler wie bei mir auftretetn - sprich' ungewünschte fakeroku-Events, sobald die Harmony für irgendeine Taste autorepeat macht (z.B. VolumeUp longpress).
Zum Reproduzieren: + oder - Taste der Wippe auf fakeroku-Befehl mappen, VolumeUp longpress - führt zur erwarteten, kontinuierlichen Lautstärke-Erhöhung, aber eben auch zu kontinuierlichen, unerwünschte fakeroku-Events von + oder -, obwohl gar nicht gedrückt.


Grüßle, Michael

MadMax-FHEM

Ich habe ALLE "Automatisierungstasten" auf fakeRoku laufen...
...also innerhalb von Actions...

Keine Probleme damit.

+- macht Leinwand rauf/runter
Licht-Tasten machen Licht an/aus (bzw.: toggle)
Die "Steckdosen"-Tasten schalten Steckdosen ;)

Harmony Elite...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

olwaldi

Danke für Deine Rückmeldung. Dann scheint die Ursache für meine Probleme irgendwie mit der Kombination der FHEM Module zu tun zu haben. Oder aber mein Hub ist irgendwann mal durcheinander gekommen.

Probleme habe ich auch nur mit den fakeroku-Funktionen, die auf +- liegen sollten. Wohlgemerkt, shortpress auf +- hat immer prima funktioniert. Nur (nicht immer, aber sehr oft) sobald irgendein longpress mit Autorepeat ausgelöst wird, wird für jedes Repeat je ein + oder - Event ausgelöst. Selbst z. B. wenn ich im Devices Menü auf dem Touchscreen die PowerOff Taste für meinen TV gedrückt halte, gibt es kontinuierlich entweder + oder - Events, eben solange wie ich den Menüpunkt gedrückt halte.

Hingegen funktionieren die Wipptasten +- via Bluetooth MCE von der Harmony fälschlicherweise immer als Dauerfeuer (shortpress führt zu kontinuierlich gesendetet Tastendrücken) - nur Sequenzen auf +- tun wie erwartet, d. h shortpress macht nur dann genau einen Tastendruck.


Grüßle, Michael

fb-luke

Hi,

ich habe schon viel glückliche Erfahrungen mit dem FakeRoku modul gesammelt, stehe aber gerade vor einem Problem das ich nicht gelöst bekomme:
Da es sich um ein größeres aber privates Netzwerk mit mehreren unterschiedlichen APs etc handelt und ich mir bis dato die vlan Konfiguration ersparen wollte habe ich für gewisse Geräte eigene IP Bereiche. Ich weiß das double NAT nicht unbedingt der Weg der Wahl ist, aber grundsätzlich funktioniert das ja.
Eingerichtet hatte ich den FakeRoku noch mit vorheriger Netzwerk konfig, wo auch alles super funktionierte. Als attr ist fhemIP mit der IP des fhemservers angelegt, sonst nichts weiter.
Was ich nicht verstanden habe ist der nutzen der Port attrs. Ich hatte im gleichen Zeitraum der Netzwerk Umstellung auch das SSL umgestellt, und auch die Ports der Webinterfaces. Kann das vielleicht auch damit zusammenhängen?

Wenn nicht gäbe es ein Weg für mich die IP Problematik im modul anders zu lösen?


Vielen Dank und Viele Grüße

justme1968

ich habe dein problem nicht wirklich verstanden, aber fhem und der hub müssen im gleichen netz sein und Udo multicast muss funktionieren. d.h. weder vlans noch routing noch sonstige konstrukte die die broadcast domain aufteilen funktionieren.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

fb-luke

Zitat von: justme1968 am 06 Dezember 2021, 18:42:32
ich habe dein problem nicht wirklich verstanden, aber fhem und der hub müssen im gleichen netz sein und Udo multicast muss funktionieren. d.h. weder vlans noch routing noch sonstige konstrukte die die broadcast domain aufteilen funktionieren.

Hi,

danke für die schnelle Rückmeldung. Das Konstrukt bei mir ist eben das einige der WIFI Devices über ein google mesh netzwerk im Lan Hängen, aber auch Fritz WIFI läuft auf dem Hauptrouter für andere Anwendungen und aufgrund einer größeren räumlichen Trennung. Dadurch entsteht eben die double NAT Situation welche dann vermutlich die Ursache für die Probleme sein wird. Ich hatte gehofft das es vielleicht eine Lösung zB richtung vlan gibt mit der man diese Problematik irgendwie software seitig lösen könnte. Es werden leider gerade im IoT Bereich immer mehr Probleme die alle darauf zurückzuführen sind. Daher muss ich nochmal durchdenken wasich für andere Wege gehen könnte. Wenn also wer  ein Vorshclag hat, her damit, sonst hat mir deine antwort trotzdem weitergeholfen, also vielen Dank für den support.

Viele Grüße

olwaldi

Noch ein Nachtrag zu meiner ehemaligen Nutzung von fakeroku...

Ich bin bei OSMC (ein Kodi für Raspi) auf das raspi-Programm triggerhappy gestoßen, das Tasten-Events mithört und gewünschte Programme starten kann. Das funktioniert prima für meinen Anwendungsfall, siehe letzten Beitrag in https://discourse.osmc.tv/t/howto-start-stop-kodi-with-your-remote-headless-mode/79951

Grüßle, Michael

olwaldi

Und noch ein Nachtrag: Da mein FireTV nur via Bluetooth (ohne adb Tricks) steuerbar ist, stört das meine anderweitige Bluetooth-Nutzung. Daher habe ich's jetzt zusätzlich mit IR über einen TSOP am Raspi versucht. Klappt, ist aber softwareseitig leider kein plug&play (siehe https://discourse.osmc.tv/t/cant-get-ir-working-using-harmony-mce-keyboard/92017).

Grüßle, Michael