[Solved] Harmony-Hub findet fakeRoku nicht mehr

Begonnen von thorwin, 14 April 2017, 17:04:03

Vorheriges Thema - Nächstes Thema

thorwin

Moin,

[Lösung ganz unten]

ich habe mein FHEM gestern und heute neu aufgesetzt, weil es viele Änderungen in den Netzen gab und weil das meine "Anfänger-Installation" war bei der vieles noch suboptimal konfiguriert war. Seitdem klappt die Verbindung zwischen meinem Harmony-Hub und dem fakeRoku-Device nicht mehr, so dass ich meine HM-Steckdosen nicht mehr über die Harmony-FB fernbedienen kann. Für mich persönlich lästig (man hat ja andFHEM), für $SWMBO eine absolute Katastrophe.

Folgendes Setup: Der Harmony-Hub ist im WLAN, der FHEM-Server (5.8 auf debian jessie auf APU2) hängt mit einem Interface im selben Netz. Die beiden können sich wunderbar sehen, das Harmony-Device reported einwandfrei seine Readings und lässt sich auch via FHEM steuern. Nur das Hinzufügen eines fakeRoku klappt nicht. Ich habe es schon mit und ohne reusePort versucht, hatte den FHEM zum Test auch schon im WLAN hängen um Probleme auf Switch oder AP-Seite auszuschließen (sowohl an meinen Ubiquity-AccessPoints wie auch direkt an der Fritz!Box). In den FHEM-Logs sehe ich ausser "ssdp responder started/stopped" und "listener started/stopped" keine Einträge vom fakeRoku, mit tcpdump kann ich nachvollziehen, dass zumindest die Requests ankommen:


root@sauron:~# tcpdump -i eth0.19 -v -n udp port 1900
tcpdump: listening on eth0.19, link-type EN10MB (Ethernet), capture size 262144 bytes
17:01:44.251299 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 122)
    172.19.16.1.39237 > 239.255.255.250.1900: UDP, length 94
17:01:44.453334 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 149)
    172.19.16.1.39237 > 239.255.255.250.1900: UDP, length 121
17:01:44.558406 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 171)
    172.19.16.1.39237 > 239.255.255.250.1900: UDP, length 143
17:01:45.286392 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 122)
    172.19.16.1.39237 > 239.255.255.250.1900: UDP, length 94
17:01:45.390338 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 149)
    172.19.16.1.39237 > 239.255.255.250.1900: UDP, length 121
17:01:45.494396 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 171)
    172.19.16.1.39237 > 239.255.255.250.1900: UDP, length 143


Offensichtlich antwortet das Modul aber nicht  >:( Hat hier evtl. noch jemand eine Idee, wo ich suchen könnte? Die fakeRoku-Version ist
# $Id: 37_fakeRoku.pm 13780 2017-03-23 13:25:41Z justme1968 $

EDIT: So, jetzt geht's wieder. Falls da nochmal jemand drüber stolpert: Ich musste das Interface des FHEM-Servers in dem auch der Harmony-Hub hängt, als native VLAN (also ungetagged) konfigurieren, mit einem getaggeten VLAN hat es nicht funktioniert. Umkonfiguriert, WLAN-Geräte suchen, Roku 3 gefunden  :D Bleibt die Frage, ob das an meinen Switches liegt (Netgear Prosafe) oder doch in der Natur der Dinge....

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.