[Aufruf] Logitech Harmony 1.0.0 GitHub Version
-
Er läuft
Aber das hatte er auch gestern Abend schon. Deswegen war ich ein wenig irritiert.
-
Moin!
Würde auch gerne testen da ich ebenfalls das Problem mit Google Home und Logitech habe. trotz Verbindung (Logitech LED grün) passiert häufiger einfach mal nix.
Kann mir jemand Dau-kompatibel sagen wie ich die Version vom git installiere?
Danke!
Mr.Lee
-
Kann mir jemand Dau-kompatibel sagen wie ich die Version vom git installiere? `
Analog hierzu:http://www.iobroker.net/docu/?page_id=5 … stallieren
Admin v3 Anleitung ist in der Mache
Gruß
Rainer
-
ok, per beliebig-pfad installiert…läuft...wie mache ich jetzt den upload?
Danke Euch!
Mr.Lee
-
Im Reiter Adapter auf Expertenmodus, dann im Adapter Harmony die Kachel aufklappen und auf das upload-Icon (unten rechts??) klicken
Gruß
Rainer
-
ok, der fehlte mir geistig…super!!!
Dann gehts jetzt vom Spielsystem aufs TestSystem!
VIELEN DANK!
-
Gibt nun eine 0.9.6, da die Dependencies geupdated wurden, musste intern auch etwas geändert werden.
Zusätzlich habe ich die Dependencies exakt auf die aktuell funktionierende Version festgelegt, da der Developer des Harmony Bibliothek wohl teilweise intern noch am umsortieren ist und somit die keine inkompatible Version installiert werden kann. Somit kann ich in Ruhe testen, bevor ich die Abhängigkeiten hoch schraube und es bei den Nutzern nicht läuft.
-
Super Sache, freue mich auf den PR.
Ich weiß nicht, ob du schon was am Life-Cycle verändert hast, meine letze Version hatte die Anwesenheit des Hubs ja über discovery gelöst. Das ist leider generell ein Problem, da es oft vorkommen kann, dass z. B. ein Router plötzlich Multicast Traffic filtert und der Hub somit nicht mehr gefunden wird (Multicast spam wirkt sich negativ auf WLAN aus). Ich wollte das immer anders lösen und discovery nicht mehr nutzen aber bin nie dazu gekommen.
So richtig sinnvoll ist discovery eigtl. nur um Hubs und deren IPs einmalig aufzuspüren, für alles andere ist es zu unzuverlässig. Und auch das funktioniert je nach Netzwerkkonfiguration nicht, obwohl der Hub ansonsten erreichbar wäre.
-
Ich weiß nicht, ob du schon was am Life-Cycle verändert hast, meine letze Version hatte die Anwesenheit des Hubs ja über discovery gelöst. Das ist leider generell ein Problem, da es oft vorkommen kann, dass z. B. ein Router plötzlich Multicast Traffic filtert und der Hub somit nicht mehr gefunden wird (Multicast spam wirkt sich negativ auf WLAN aus). Ich wollte das immer anders lösen und discovery nicht mehr nutzen aber bin nie dazu gekommen.
So richtig sinnvoll ist discovery eigtl. nur um Hubs und deren IPs einmalig aufzuspüren, für alles andere ist es zu unzuverlässig. Und auch das funktioniert je nach Netzwerkkonfiguration nicht, obwohl der Hub ansonsten erreichbar wäre. `
Hi,
ich habe an der Logik bislang nichts verändert, außer dass man eine Whitelist nutzen kann, wobei dass ja letzendlich auch nur davon abhält, dass sich der Adapter mit anderen Hubs nicht verbindet.
Ansonsten hat es sich auf das aktualisieren der Dependencies beschränkt + Nutzung von Javascript ES6. Welchen Ansatz hast du dir denn vorgestellt gehabt als Alternative zu Discovery? Ich habe mich bislang nur sehr oberflächlich in die Logik des Adapters rein gedacht.
beste Grüße
fox
-
Das ist wirklich schwierig und im Prinzip hilft nur Trial & Error. Vielleicht hilft ein regelmäßiger Ping, aber auch das garantiert nicht, dass die XMPP Verbindung noch aufgebaut ist.
Discovery -> Hub sendet regelmäßig Multicast Broadcasts ins Netzwerk, kommt eine gewisse weile keiner an, glaubt der Adapter, dass der Hub nicht mehr erreichbar ist. Das kann stimmen, muss es aber wie gesagt nicht.
Ping -> Ist der Hub pingbar? Das würde zumindest garantieren, dass er im Netzwerk und erreichbar ist. Allerdings sagt ein erfolgreicher Ping nichts darüber aus, ob eine XMPP Verbindung hergestellt werden kann bzw. ob eine vorher hergestellte Verbindung noch aktiv ist.
Ich weiß nicht, wie sich neuere Versionen des Hubs und der XMPP-Lib verhalten, beim erstellen der letzten Version war das größte Problem, dass der Hub die XMPP-Verbindung mehr oder weniger heimlich beendet hat während der Adapter davon nichts mitbekommen hat.
Was der Adapter bewerkstelligen können sollte:
Immer, wenn der/ein Hub im Netzwerk aktiv ist, sollt eine Verbindung aufgebaut werden. Disconnects der XMPP- und Netzwerkverbindung (Hub-Neustarts, Netzwerkunterbrechungen) sollten erkannt werden und möglichst schnell eine neue Verbindung aufgebaut werden.
-
Das ist wirklich schwierig und im Prinzip hilft nur Trial & Error. Vielleicht hilft ein regelmäßiger Ping, aber auch das garantiert nicht, dass die XMPP Verbindung noch aufgebaut ist.
Discovery -> Hub sendet regelmäßig Multicast Broadcasts ins Netzwerk, kommt eine gewisse weile keiner an, glaubt der Adapter, dass der Hub nicht mehr erreichbar ist. Das kann stimmen, muss es aber wie gesagt nicht.
Ping -> Ist der Hub pingbar? Das würde zumindest garantieren, dass er im Netzwerk und erreichbar ist. Allerdings sagt ein erfolgreicher Ping nichts darüber aus, ob eine XMPP Verbindung hergestellt werden kann bzw. ob eine vorher hergestellte Verbindung noch aktiv ist.
Ich weiß nicht, wie sich neuere Versionen des Hubs und der XMPP-Lib verhalten, beim erstellen der letzten Version war das größte Problem, dass der Hub die XMPP-Verbindung mehr oder weniger heimlich beendet hat während der Adapter davon nichts mitbekommen hat.
Was der Adapter bewerkstelligen können sollte:
Immer, wenn der/ein Hub im Netzwerk aktiv ist, sollt eine Verbindung aufgebaut werden. Disconnects der XMPP- und Netzwerkverbindung (Hub-Neustarts, Netzwerkunterbrechungen) sollten erkannt werden und möglichst schnell eine neue Verbindung aufgebaut werden. `
Schon mal danke für die Infos und Anregungen. Falls ich mal Zeit + Lust habe, werde ich etwas rumprobieren.
beste Grüße
fox
-
Update aus Github von 0.9.3 auf MacOS funktionierte reibungslos.
Danke fürs Entwickeln!
Pix
-
Auch gerade installiert und wird jetzt ausgiebig getestet.
Vielen Dank für deine Mühe!
-
Zumindest bei mir läuft die 0.9.6 seit ein paar Tagen absolut fehlerfrei und ohne eine einzige Logmeldung.
-
Hallo zusammen…..
Habe gerade das Update auf 0.96 gemacht. Werde das ganze mal beobachten und berichten wenn was nicht rund läuft.
Gruß Markus
Gesendet von unterwegs mit Tapatalk
-
Man kommt mittlerweile auch auf die 0.9.6, indem man den Adapter einfach von GitHub installiert über das Dropdown. Muss also nicht mehr extra von meinem Repo gezogen werden, da die Änderungen nun auch in pmant's Repo sind.
-
Genau, ich warte noch etwas ab und dann pushe ich es auch auf npm.
-
Ich hatte gehofft, dass die neue Version nun auch bei mir läuft. Leider nicht.
Mein ioBroker läuft auf einem Raspberry Pi der sowohl per LAN (192.168.1.0) als auch über WLAN (192.168.3.0) verbunden ist. Beide Netzwerke sind unterschiedliche VLANs. Man kann von VLAN 1 auf Geräte im VLAN 3 zugreifen, nicht jedoch umgekehrt. Mein Harmony-Hub hängt im VLAN 3 (192.168.3.0).
Leider findet der Adapter den Hub nicht, auch wenn ich dessen IP per Hand hinzufüge (und den Adapter danach neu starte). User und Passwort sind immer deaktiviert.
Kann man da was machen (außer den Hub in das andere VLAN zu hängen)?
-
Derzeit leider nicht. Müsste in etwa dieses Issue sein: https://github.com/Pmant/ioBroker.harmony/issues/20
Ich denke, das sollte selbst mit dem Discovery Modul möglich sein. Der Harmony Adapter ist bei mir nicht so hoch priorisiert, wenn mich die Langeweile überkommt, werde ich es mir gerne mal anschauen.
closed Add Manual discovery #20
-
Schade.
Wenn ich das Netzwerkkabel abhänge, der Raspi also nur über WLAN läuft, findet er den Hub. Doch wenn das Kabel wieder an ist, ist auch die Kommunikation wieder weg. Mir würde es reichen, wenn man die Netzwerkschnittstelle ('eth0' bzw. 'wlan0') auswählen könnte.
