Logitech Harmony Hub

[p8yLb8KyjNiHWM]

Hallo,

versuche gerade einen Harmony Hub in FHEM einzubinden. FHEM ist frisch installiert - Debian - und über das FHEM-Repository installiert worden. Habe bisher nur 1-2 DECT200-Geräte von AVM drin.

Nachdem ich das Harmony-Device in FHEM hinzugefügt habe, hat es den Status "disconnect". Im Log steht:
2016.03.25 12:04:54 2: HarmonyHUB: http request failed: https://svcs.myharmony.com/CompositeSecurityServices/Security.svc/json/GetUserAuthToken: Can't connect(2) to https://svcs.myharmony.com:443: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Ein Problem mit dem SSL-Zertifikat von Harmony also. Mein Problem: Ich finde den Fehler nicht! Kennwort/User stimmt, Gerät entfernt+hinzugefügt, FHEM neu gestartet, div. JSON-Pakete geprüft - geht aber nicht.
Ich habe gelesen, dass ich iwo in JSON/dem Plugin https durch http ersetzen soll - allerdings keinen Hinweis darauf, WO das passieren soll.
Woran kann mein Problem liegen?

[rubbertail]

Hast ein update gemacht? Gab dazu nen anderen Thread - da ist was von Rudolf eingebaut worden.

[p8yLb8KyjNiHWM]

Hallo,

nein, kein Update gemacht - habe allerdings auch nichts konkretes zu diesem Update gefunden (ich vermute vom Harmony-Plugin?).
Hast du ggf. nähere Infos?

Danke dir!

[rubbertail]

Such mal nach SSL hier im Forum - bestimmte Verschlüsselungsarten sind inzwischen nicht mehr sicher, da gabs aber irgendeine Fehlaushandlung mit SSL-Servern, mit denen Fhem kommuniziert, daher kam der Fehler. Hat nix mit dem Harmony-Modul alleine zu tun, sondern mit dem gesamten SSL-Handling in Fhem. Daher: Update.

Wenns dich genauer interessiert:
https://forum.fhem.de/index.php/topic,48599.0.html

[p8yLb8KyjNiHWM]

Hm. Von was genau ein Update? Vom Host oder von FHEM?
Das "Problem" ist, dass ich das Ding vorgestern frisch aufgesetzt habe (Debian und FHEM via Repository installiert (aktuell 5.7). Sollte da dieser Fehler garnicht auftreten, oder meintet ihr ein Update von etwas anderem?

[klaymen]

Hallo zusammen,

Ich bin in Sachen FHEM ganz neu und darauf gestossen, als ich für mein - ebenfalls neues - Raspberry 3 und meine (alte  ) Harmony Ultimate eine Lösung suchte. Den ganzen Thread habe ich noch nicht gelesen, ich bin erst bei Seite 8 - ich hoffe, meine Frage (weiter unten) taucht da nicht schon irgendwo auf.

Vorher habe ich aber eventuell auch eine Lösung, da auch ich dieses SSL Problem hatte. Das Problem war bei mir nicht SSL selber oder der Modus, sondern das Überprüfen des Zertifikates. Ich konnte das bei mir so lösen, dass ich direkt den start_ssl Call der Funktion HttpUtils_Connect2 in  /opt/fhem/FHEM/HttpUtils.pm editierte:

Originalinhalt:

Code Auswählen Erweitern


      IO::Socket::SSL->start_SSL($hash->{conn}, {
          Timeout     => $hash->{timeout},
          SSL_version => $sslVersion,
          %{$hash->{sslargs}}
        }) || undef $hash->{conn};


Geändert in:

Code Auswählen Erweitern


      IO::Socket::SSL->start_SSL($hash->{conn}, {
          Timeout     => $hash->{timeout},
          SSL_version => $sslVersion,
          SSL_verify_mode   => 0,
          %{$hash->{sslargs}}
        }) || undef $hash->{conn};


Auf diese Weise verifiziert er das SSL Zertifikat nicht mehr. Leider fand ich keine Möglichkeit, das ohne Ändern des Sources direkt vorzunehmen, vielleicht kann man das ja irgendwann mal ermöglichen? Also ein ziemlicher Hack, aber mir ist das lieber als nossl, da dort ja das Passwort im Klartext aufs Internet geht. Besser wäre natürlich, wenn man die CA der myharmony Seite einbinden könnte. Naja, auf jeden Fall funktioniert das bei mir jetzt so.

Meine Frage ist aber eine Andere: auf dem Raspberry lasse ich OSMC laufen, und würde die Harmony gerne als Fernbedienung dafür nutzen. Natürlich geht das auch über Smartphone, was aber suboptimal ist (vor allem wegem Screenlock, den man immer vorher deaktivieren muss). Es gibt ja auch Module, um aus FHEM Kodi anzusprechen. Mein Problem ist jedoch, dass man offenbar die eigentlichen Tastendrücke nicht aus der Harmony auslesen kann, nur die grundsätzlichen Aktivitäten. Dazu scheint im Moment Infrarot oder Bluetooth notwendig zu sein, ich habe aber keine zusätzliche Hardware, und einen IR-Stick anzuschliessen, wenns nicht notwendig ist, finde ich schade. Allerdings hat das Raspberry 3 ja Bluetooth "on Board", also frage ich mich, ob man das nicht nutzen kann? Meine ersten (aber noch nicht tiefgreifenden) Versuche waren da nicht erfolgreich, aber vielleicht hat jemand Anderes das schon gemacht. Ich habe allerdings nicht Raspbian, sondern - wie gesagt - OSMC als Image (Version 16).

Danke im Voraus und Gratulation für das Harmony Modul - das, was ich bisher gesehen habe, läuft prima!

lg, Andreas

[klaymen]

Hallo nochmals,

Ich hoffe, ich mache mich jetzt nicht zum Dödel und verbreite was Uraltes als neue Erkenntnis... es geht um die Frage, ob die Harmony nicht Device Tasten über TCP versenden kann. Ich habe unter Anderem bei mir ein Roku 3, und dieses Teil wird eben nicht über IR angesprochen, kann aber durch die Logitech bedient werden. Ich nahm bisher an, dass dies über BT geht - aber Roku und Hub wurden ja nie gekoppelt. Also versuchte ich mal, beim Roku den Ethernet Stecker zu ziehen (ich habe kein WLAN). In der Tat funktioniert die Harmony dann nicht mehr.

Also ging ich in den Keller, holte einen alten Hub, und habe den Traffic beim Roku mitgeschnitten (auf dem Hub kann ich leider nicht, da das ja über WLAN geht). Und in der Tat sehe ich TCP Streams vom Hub zum Roku der Art:

Code Auswählen Erweitern


POST /keydown/Down HTTP/1.1
connection: keep-alive
accept-encoding: gzip, deflate
accept: /*
user-agent: LuaSocket 2.0.2
accept-language: en-us
te: trailers
host: 10.1.1.60

0

HTTP/1.1 200 OK
Server: Roku UPnP/1.0 MiniUPnPd/1.4
Content-Length: 0



Das ist für ein Down-Key. 10.0.0.60 ist die IP des Roku. Die unteren 3 Zeilen sind die Antwort des Roku (lasse ich i.F. weg). Das Ganze geht auf Port 8060. Kurz darauf kommt

Code Auswählen Erweitern


POST /keyup/Down HTTP/1.1
connection: keep-alive
accept-encoding: gzip, deflate
accept: /*
user-agent: LuaSocket 2.0.2
accept-language: en-us
te: trailers
host: 10.1.1.60

0

HTTP/1.1 200 OK
Server: Roku UPnP/1.0 MiniUPnPd/1.4
Content-Length: 0


Für "OK" kommt analog

Code Auswählen Erweitern


POST /keydown/Select HTTP/1.1
connection: keep-alive
accept-encoding: gzip, deflate
accept: /*
user-agent: LuaSocket 2.0.2
accept-language: en-us
te: trailers
host: 10.1.1.60

0


usw. D.h. die Tasten werden eindeutig via HTTP versendet - die Frage ist, wie man den Hub dazu bringt, das generell zu machen. Man könnte eventuell einen Sync dazu mitschneiden, ist aber wohl aufwendig.

Was aber wahrscheinlich machbar wäre, ist, ein Dummy Roku Gerät mit der IP des FHEM zu definieren, und da zumindest auf die Tasten, die Logitech für das Roku verwendet, zu reagieren? Die frage ist, ob FHEM mit diesen Angaben etwas anfangen kann.

lg Andreas

[justme1968]

das problem dabei ist das pairing des hub mit dem roku player oder jedem anderen tcp device. hierzu müsste man auf FHEM entweder ein discovery protokoll nachbauen oder sogar die komplette anmelde prozedur im portal des entsprechenden devices. hier ist in der regel nichts dokumentiert. das ganze hat auch nicht wirklich etwas mit dem harmony modul zu tun sondern man müsste eben ein fake xyz device implementieren.

auch könnte es probleme geben wenn die harmony nur genau ein solches device unterstützt. wie z.b. bei hue hub.

diese diskussion gab es schon mindestens zwei mal aber es hat noch niemand gemacht

inzwischen haben aber die plex leute entschieden das sie ihren player als fake roku player per harmony steuern lassen. d.h. es gibt eventuell quelltexte die man man anschauen könnte.

gruss
  andre

ps: ich habe gerade gefunden welches discovery protokoll verwendet wird... vielleicht geht es doch einfacher als gedacht.

[justme1968]

ich habe mal etwas gebastelt und kann die suche des hub nach netzwerkgeräten sehen. ich sehen auch diverse geräte in meinem netz die antworten.

aber: die nachricht die nach einem roku player sucht sehe ich nicht. und da ich keinen habe auch keine antwort.

kannst du mal mitschneiden was zwischen hub und roku beim pairen passiert?

d.h. was passiert wenn man in der harmony app nach neuen netzwerk geräten sucht und dann der roku player auftaucht.

gruss
  andre

alternativ: kann mir jemand einen roku player ausleihen ?

[klaymen]

Hallo Andre,

Ich habe gerade ein Pcap gezogen. Eine genaue Analyse mache ich noch, ich kann die das pcap auch schicken. Ich habe dazu zuerst beim Roku die IP Reservation auf 10.1.1.61 geändert.

Wenn ich nach IPs zwischen Roku und Hub filtere, sehe ich als Erstes einen ARP Request des Roku auf IP 10.1.1.189 (Hub), gefolgt von SSDP UDP von Roku zum Hub (Seriennummer und UUID habe ich anonymisiert):

Code Auswählen Erweitern


HTTP/1.1 200 OK
Cache-Control: max-age=3600
ST: upnp:rootdevice
USN: uuid:aaaaaaaa-aaaa-bbbb-cccc-dddddddddddd::upnp:rootdevice
Ext:
Server: Roku UPnP/1.0 MiniUPnPd/1.4
LOCATION: http://10.1.1.61:8060/

HTTP/1.1 200 OK
Cache-Control: max-age=3600
ST: roku:ecp
USN: uuid:roku:ecp:1GSxxxxxxxxx
Ext:
Server: Roku UPnP/1.0 MiniUPnPd/1.4
LOCATION: http://10.1.1.61:8060/

HTTP/1.1 200 OK
Cache-Control: max-age=3600
ST: urn:dial-multiscreen-org:service:dial:1
USN: uuid:aaaaaaaa-aaaa-bbbb-cccc-dddddddddddd::urn:dial-multiscreen-org:service:dial:1
Ext:
Server: Roku UPnP/1.0 MiniUPnPd/1.4
LOCATION: http://10.1.1.61:8060/dial/dd.xml


Ich sehe dann eine Connection Hub zu Roku:

Code Auswählen Erweitern


GET /dial/dd.xml HTTP/1.1
connection: keep-alive
content-length: 0
accept-language: en-us
user-agent: UDAP/2.0 Mozilla/5.0 (X11; Linux i686)
accept: /*
te: trailers
accept-encoding: gzip, deflate
host: 10.1.1.61

HTTP/1.1 200 OK
Server: Roku UPnP/1.0 MiniUPnPd/1.4
Content-Length: 1148
Cache-Control: no-cache
Content-Type: text/xml; charset="utf-8"
Application-URL: http://10.1.1.61:8060/dial

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:roku-com:device:player:1-0</deviceType>
<friendlyName>Roku 3 - 1GSxxxxxxxxx</friendlyName>
<manufacturer>Roku</manufacturer>
<manufacturerURL>http://www.roku.com/</manufacturerURL>
<modelDescription>Roku Streaming Player Network Media</modelDescription>
<modelName>Roku 3</modelName>
<modelNumber>4200X</modelNumber>
<modelURL>http://www.roku.com/</modelURL>
<serialNumber>1GSxxxxxxxxx</serialNumber>
<UDN>uuid:aaaaaaaa-aaaa-bbbb-cccc-dddddddddddd</UDN>
<serviceList>
<service>
<serviceType>urn:roku-com:service:ecp:1</serviceType>
<serviceId>urn:roku-com:serviceId:ecp1-0</serviceId>
<controlURL></controlURL>
<eventSubURL></eventSubURL>
<SCPDURL>ecp_SCPD.xml</SCPDURL>
</service>
<service>
<serviceType>urn:dial-multiscreen-org:service:dial:1</serviceType>
<serviceId>urn:dial-multiscreen-org:serviceId:dial1-0</serviceId>
<controlURL></controlURL>
<eventSubURL></eventSubURL>
<SCPDURL>dial_SCPD.xml</SCPDURL>
</service>
</serviceList>
</device>
</root>


Danach folgt wieder Hub auf Roku:

Code Auswählen Erweitern


GET / HTTP/1.1
connection: keep-alive
content-length: 0
accept-language: en-us
user-agent: UDAP/2.0 Mozilla/5.0 (X11; Linux i686)
accept: /*
te: trailers
accept-encoding: gzip, deflate
host: 10.1.1.61

HTTP/1.1 200 OK
Server: Roku UPnP/1.0 MiniUPnPd/1.4
Content-Length: 1148
Cache-Control: no-cache
Content-Type: text/xml; charset="utf-8"

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:roku-com:device:player:1-0</deviceType>
<friendlyName>Roku 3 - 1GSxxxxxxxxx</friendlyName>
<manufacturer>Roku</manufacturer>
<manufacturerURL>http://www.roku.com/</manufacturerURL>
<modelDescription>Roku Streaming Player Network Media</modelDescription>
<modelName>Roku 3</modelName>
<modelNumber>4200X</modelNumber>
<modelURL>http://www.roku.com/</modelURL>
<serialNumber>1GSxxxxxxxxx</serialNumber>
<UDN>uuid:aaaaaaaa-aaaa-bbbb-cccc-dddddddddddd</UDN>
<serviceList>
<service>
<serviceType>urn:roku-com:service:ecp:1</serviceType>
<serviceId>urn:roku-com:serviceId:ecp1-0</serviceId>
<controlURL></controlURL>
<eventSubURL></eventSubURL>
<SCPDURL>ecp_SCPD.xml</SCPDURL>
</service>
<service>
<serviceType>urn:dial-multiscreen-org:service:dial:1</serviceType>
<serviceId>urn:dial-multiscreen-org:serviceId:dial1-0</serviceId>
<controlURL></controlURL>
<eventSubURL></eventSubURL>
<SCPDURL>dial_SCPD.xml</SCPDURL>
</service>
</serviceList>
</device>
</root>


Und dann kommen die Keypresses wie gehabt.

Der Hub hat so also die neue IP des Roku gefunden (ohne neues Device zu konfiguieren). Offen ist bei mir noch die Frage, wie der erste ARP Request geschah, ob der Roku noch die IP des Hub gepuffert hatte (ich müsste die IP des Hubs auch ändern um das rauszufinden), ist wohl eine UPnP Sache, da kenne ich mich nicht so aus. Auch was beim Konfigurieren eines neuen Devices geschieht, muss ich noch testen, komme aber erst am Abend dazu.

Es müste also theoretisch möglich sein, über einen Python- oder Perl-Script eine beliebige Anzahl virtueller Rokus per UPnP anzumelden (dazu müssen je ein kleiner Webserver pro Device mitprogramiert werden), die können wahrscheinlich die IP teilen, einfach auf eigenen Ports, und dann diese per Harmony "finden" und deren Keys auf die eigenen Aktivitäten verteilen. Mehrere Devices, weil die Anzahl Buttons pro Device begrenzt ist (Ziffern hat Roku glaub ich keine). Der Script müsste dann die empfangenen Keys zu fhem weiterleiten. Wahrscheinlich könnte man das sogar als fhem Modul implementieren. Das Ganze ist natürlich schneller gesagt als getan, und etwas umständlich. Hmm ist aber glaub ich in etwa das, was du oben beschrieben hast (ich habe es heute morgen nur überflogen, da ich in Eile war).

lg Andreas

PS: Ich beobachte bei meinem Roku manchmal, dass er Keyup's zu verpassen scheint, dann kommt er in einen Keyrepeat-Loop, als ob man eine Taste ständig gedrückt hätte. Ich weiss allerdings nicht, ob der Hub verpasst, diese zu senden resp. zu emfpangen, oder der Roku deren Empfang übersieht. Das hat eine Konsequenz, ob man Autorepeats überhaupt untersützen will oder nicht. Ist eh immer ein bisschen heikel damit, ich bin nicht so Freund davon.

[justme1968]

vor der ssdp antwort des hub und vermutlich noch vor dem arp request müsste es diverse udp ssdp broadcastst vom hub geben. auf genau einen davon hat der player dann mit der obigen antwort reagiert.

welcher broadcast das genau ist wäre interessant. laut doku müsste es einer sein mit ST: roku:ecp. genau den sehe ich aber nicht sondern ein paar dutzend andere.

das ist der wichtige erste schritt damit ich weiß worauf ich antworten muss.

ich schicke dir nachher eine e-Mail für das pcap file.

gruss
andre

[justme1968]

dank der tatkräftigen hilfe von klaymen gibt es jetzt eine erste version: https://forum.fhem.de/index.php/topic,51619.msg432921.html#msg432921.

gruss
  andre

[SalvadoreXXL]

Hallo,

besteht die Möglichkeit eine Log-Funktion in das Modul einzubauen? Ich hatte gern die Aktivitäten meines Hubs protokolliert.

Danke

[justme1968]

bitte ?

[SalvadoreXXL]

Bei mir wird kein Log erstellt. Hab versucht das zu konfigurieren. Ist mit nicht gelungen. Hab auch nichts dazu in der Doku gefunden. Deswegen habe ich hier gefragt.