NEWS
-
Ja das sind die connected false Zeiten/Momente.
llerdings hatte ich vorher sehr häufig das Problem, dass der Adapter längere Zeit nicht funktioniert hat (z. B. nach dem MAX_CLIENTS=6 Error, falls du ihn auch öfter hattest) `
nein hatte ich nicht, ich habe nur bei der Fernbedienung oft, dass sie hakelig wird. und ich nahm an, dass der Hiub dann mit irgendetwas bewschäftigt (reconnect o.ä.) war.Besonders schlimm ist es wenn die Lautstärke dann noch lange immer lauter wird und man nicht darauf reagieren kann.
Gruß
Rainer
-
Ich hab ja eigentlich nie Probleme mit der Fernbedienung.. Nur halt mit dem Adapter. Ich hab das nun nicht geloggt, aber vorher hatte ich min. bei jedem 2. Mal dor rote Lampe dort, wenn ich die Instanzen geöffnet habe. Das hatte ich bisher nicht wieder
Gesendet von meinem F5121 mit Tapatalk
-
Ich hatte seit rund einem halben Jahr keine Probleme mehr mit dem Adapter (original). Ob es einen Zusammenhang gibt oder nicht…seit dem Update des JS-controller auf 1.5.3 sind die Probleme wieder da. Eine Verbindung zum Hub ist erst nach einem Restart des ioBroker wieder möglich. Ein Neustart des Adapters alleine bring nichts.
Seit gestern habe ich v0.9.5 installiert und auch hier:
host.iobroker 2018-09-18 08:09:11.622 info Restart adapter system.adapter.harmony.0 because enabled host.iobroker 2018-09-18 08:09:11.622 error instance system.adapter.harmony.0 terminated with code 0 (OK) host.iobroker 2018-09-18 08:09:11.622 error Caught by controller[0]: at endReadableNT (_stream_readable.js:978:12) host.iobroker 2018-09-18 08:09:11.622 error Caught by controller[0]: at Socket.emit (events.js:185:7) host.iobroker 2018-09-18 08:09:11.622 error Caught by controller[0]: at emitNone (events.js:91:20) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at Socket.socket.on (/opt/iobroker/node_modules/@harmonyhub/discover/dist/responseCollector.js:39:22) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at ResponseCollector.emit (events.js:188:7) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at emitOne (events.js:96:13) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at Explorer.handleResponse (/opt/iobroker/node_modules/@harmonyhub/discover/dist/explorer.js:69:18) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at Explorer.emit (events.js:188:7) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at emitOne (events.js:96:13) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at Explorer.discover.on.hub (/opt/iobroker/node_modules/iobroker.harmony/harmony.js:193:36) host.iobroker 2018-09-18 08:09:11.620 error Caught by controller[0]: TypeError: Cannot read property 'length' of undefined harmony.0 2018-09-18 08:09:10.336 info searching for Harmony Hubs... harmony.0 2018-09-18 08:09:10.335 info starting. Version 0.9.5 in /opt/iobroker/node_modules/iobroker.harmony, node: v6.14.4 host.iobroker 2018-09-18 08:09:09.092 info instance system.adapter.harmony.0 started with pid 24461 -
Ich hatte seit rund einem halben Jahr keine Probleme mehr mit dem Adapter (original). Ob es einen Zusammenhang gibt oder nicht…seit dem Update des JS-controller auf 1.5.3 sind die Probleme wieder da. Eine Verbindung zum Hub ist erst nach einem Restart des ioBroker wieder möglich. Ein Neustart des Adapters alleine bring nichts.
Seit gestern habe ich v0.9.5 installiert und auch hier:
!
host.iobroker 2018-09-18 08:09:11.622 info Restart adapter system.adapter.harmony.0 because enabled host.iobroker 2018-09-18 08:09:11.622 error instance system.adapter.harmony.0 terminated with code 0 (OK) host.iobroker 2018-09-18 08:09:11.622 error Caught by controller[0]: at endReadableNT (_stream_readable.js:978:12) host.iobroker 2018-09-18 08:09:11.622 error Caught by controller[0]: at Socket.emit (events.js:185:7) host.iobroker 2018-09-18 08:09:11.622 error Caught by controller[0]: at emitNone (events.js:91:20) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at Socket.socket.on (/opt/iobroker/node_modules/@harmonyhub/discover/dist/responseCollector.js:39:22) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at ResponseCollector.emit (events.js:188:7) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at emitOne (events.js:96:13) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at Explorer.handleResponse (/opt/iobroker/node_modules/@harmonyhub/discover/dist/explorer.js:69:18) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at Explorer.emit (events.js:188:7) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at emitOne (events.js:96:13) host.iobroker 2018-09-18 08:09:11.621 error Caught by controller[0]: at Explorer.discover.on.hub (/opt/iobroker/node_modules/iobroker.harmony/harmony.js:193:36) host.iobroker 2018-09-18 08:09:11.620 error Caught by controller[0]: TypeError: Cannot read property 'length' of undefined harmony.0 2018-09-18 08:09:10.336 info searching for Harmony Hubs... harmony.0 2018-09-18 08:09:10.335 info starting. Version 0.9.5 in /opt/iobroker/node_modules/iobroker.harmony, node: v6.14.4 host.iobroker 2018-09-18 08:09:09.092 info instance system.adapter.harmony.0 started with pid 24461`Das hat nichts mit dem JS-Controller zu tun, eher damit dass du wahrscheinlich den Upload des Adapters vergessen hast.
-
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. -
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
Support us
766
Online32.4k
Users81.5k
Topics1.3m
Posts