NEWS
-
Das hat nichts mit dem JS-Controller zu tun, eher damit dass du wahrscheinlich den Upload des Adapters vergessen hast.
Hmm ich dachte ich hätte das schon gemacht, aber ich habe den "upload" jetzt auf jeden Fall ausgeführt. Ich werde berichten, wie sich der Adapter in den nächsten Tagen verhält.Die Fehlermeldung jetzt kam jedenfalls davon, dass ich diese Whitelist implementiert habe. Wenn man den Upload gemacht hat, wird aus der index.html per default eine leere Liste gezogen und es kann eigentlich nicht sein, dass es .length nicht gibt.
Hoffe er läuft jetzt zumindest an. ;)
-
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
-
Im Reiter Adapter auf Expertenmodus, dann im Adapter Harmony die Kachel aufklappen und auf das upload-Icon (unten rechts??) klicken
Gruß
Rainer
-
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
-
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.
-
Ich hatte gehofft, dass die neue Version nun auch bei mir läuft. Leider nicht. :cry:
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.
Support us
319
Online32.6k
Users82.3k
Topics1.3m
Posts