NEWS
Test js-controller 0.15.1
-
Umsetzung hat geholfen. Spannend ist, ob Du eine Möglichkeit findest, die Zahl der max Events dynamisch ermitteln kannst? Evt. ist es interessant zu ermitteln, wie lange eine Subscription benötigt, um auf ein Event zu reagieren. Andererseits frage ich mich auch, ob wirklich so vile Events abgesetzt werden müssen. Beispielsweise treten bei dem unifi Adapter/genauso hue-Apdater häufig keine Änderungen auf. Wäre es nicht sinnvoll die Adapter-Entwickler zu animieren, die Zahl der Events auf die notwendigen zu beschränken? Dass dürfte das System insgesamt entlasten.
-
Hi Bluefox,
nur mal damit ichs verstehe. Für was steht denn dieser Wert? Denn ich konnte bisher zumindest keine negativen Erscheinungen feststellen. Und mein System haut wahrscheinlich ziemlich viele Events raus. Zumindest mehr, als der Browser (im selben Netz) unter dem Reiter Events flüssig darstellen kann.
Oder stehen diese Events für etwas anderes?
Vielleicht könnte man ja so etwas wie einen Eventzähler(Tacho?) in den Admin einbauen. So in der Art wie beim Log wenn ich dieses anhalte, nur eben dauernd. Als Pulsanzeige quasi.
Das wäre möglicherweise auch ein ziemlich guter Performancemesser für die unterschiedlichen Hardwareplattformen.
Bis 100 Transaktionen reicht ein Raspi.
Ab dann bis 500 wäre ein Raspi3 nötig.
und ab diesem Wert braucht es schnellere Prozessoren/mehr Ram etc.
Vielleicht ließe sich so eine ungefähre Kalkulation für den benötigten Rechner im Vorfeld einer Installation ermitteln.
Ist nur so ne Idee.
Gruß
Bernhard
-
Hallo Bernhard,
@Heinzelmaennchen:Das wäre möglicherweise auch ein ziemlich guter Performancemesser für die unterschiedlichen Hardwareplattformen. `
Ich verstehe leider nicht alles in diesem Thread, aber wenn das so ist, wie du es (nachvollziehbar) beschreibst, fände ich so eine Kennzahl wirklich brauchbar.Gruß
Rainer
-
Hi Bluefox,
nur mal damit ichs verstehe. Für was steht denn dieser Wert? Denn ich konnte bisher zumindest keine negativen Erscheinungen feststellen. Und mein System haut wahrscheinlich ziemlich viele Events raus. Zumindest mehr, als der Browser (im selben Netz) unter dem Reiter Events flüssig darstellen kann.
Oder stehen diese Events für etwas anderes?
Vielleicht könnte man ja so etwas wie einen Eventzähler(Tacho?) in den Admin einbauen. So in der Art wie beim Log wenn ich dieses anhalte, nur eben dauernd. Als Pulsanzeige quasi.
Das wäre möglicherweise auch ein ziemlich guter Performancemesser für die unterschiedlichen Hardwareplattformen.
Bis 100 Transaktionen reicht ein Raspi.
Ab dann bis 500 wäre ein Raspi3 nötig.
und ab diesem Wert braucht es schnellere Prozessoren/mehr Ram etc.
Vielleicht ließe sich so eine ungefähre Kalkulation für den benötigten Rechner im Vorfeld einer Installation ermitteln.
Ist nur so ne Idee.
Gruß
Bernhard `
Es geht um Browser. Wie viele events kann ein Browser verarbeiten.So ein Pulsmessung ist interessant. :D
-
Bei mir läuft der 15.3 ohne die Meldung. Wenn man sich die Ereignisse anschaut, dann ist der Philips Hue Adapter wirklich spitzenreiter.
@gst666
> zwei Adapter rund 70 LeuchtmittelHast du deine ganze Straße damit ausgestattet? :lol: :shock: -
Bei mir läuft der 15.3 ohne die Meldung. Wenn man sich die Ereignisse anschaut, dann ist der Philips Hue Adapter wirklich spitzenreiter. `
Leider funktioniert die Hue Api ja nur mit Polling, dabei werden dann alle paar Sekunden alle Leuchten abgerufen und die Datenkpunkte gespeichert. Möglicherweise ist es auch hier sinnvoll nur tatsächlich geänderte Datenpunkte auch zu schreiben, ich gucke mir das mal an sobald ich Zeit dazu habe. Es hilft natürlich auch die Polling-Abstände in den Adapteroptionen zu verlängern.
-
Bei mir läuft der 15.3 ohne die Meldung. Wenn man sich die Ereignisse anschaut, dann ist der Philips Hue Adapter wirklich spitzenreiter. `
Ich denke es ist sicherlich nicht spezifisch bzgl des Philips Hue Adapters. Ich wage auch mal einfach die These aufzustellen das es auch vmtl daran liegt das viele Adapter (wenn nicht sogar die meisten) PullAdapter sind. D.h. Sie holen regelmäßig ihre werte ab und melden die dann per adapter.setState() egal ob die werte sich geändert haben oder nicht. Und so kommt ws das eben z.b. Der Hue Adapter auf einmal recht viele state änderungen publisht und das macht dann hin/wieder recht hohe state peaks. Helfen würde hierbei IMHO wenn Bluefox dem adapter.setState() wie hier besprochen (http://forum.iobroker.net/viewtopic.php?f=24&t=4868) eine möglichkeit verpassen würde die werte nur zu setzen/publishen wenn sich die werte auch geändert haben. IMHO wäre es ggf auch testweise mal interessant per default die adapter.setState() funktion sich so verhalten zu lassen und nur adapter die eben nicht in regelmäßigen Abständen werte abholen sondern diese aktiv geliefert bekommen sollten setState dann mit einer force option aufrufen. iMHO sollte sich somit das state change augkommen radikal reduzieren lassen.
-
Leider funktioniert die Hue Api ja nur mit Polling, dabei werden dann alle paar Sekunden alle Leuchten abgerufen und die Datenkpunkte gespeichert. Möglicherweise ist es auch hier sinnvoll nur tatsächlich geänderte Datenpunkte auch zu schreiben, ich gucke mir das mal an sobald ich Zeit dazu habe. Es hilft natürlich auch die Polling-Abstände in den Adapteroptionen zu verlängern. `
Wenn du dir das anschaust dann magst du vielleicht mal einen Blick auf folgende Funktion werfen die ich von Bluefox erhalten/angepasst habe und die bis er ggf adapter.setState() angepasst hat so ein setState nur bei wertänderung implementiert:
https://github.com/jens-maus/ioBroker.u … in.js#L192
Funktioniert in meinem ioBroker.unifi adapter sehr gut.
-
Bei mir läuft der 15.3 ohne die Meldung. Wenn man sich die Ereignisse anschaut, dann ist der Philips Hue Adapter wirklich spitzenreiter. `
Ich denke es ist sicherlich nicht spezifisch bzgl des Philips Hue Adapters. Ich wage auch mal einfach die These aufzustellen das es auch vmtl daran liegt das viele Adapter (wenn nicht sogar die meisten) PullAdapter sind. D.h. Sie holen regelmäßig ihre werte ab und melden die dann per adapter.setState() egal ob die werte sich geändert haben oder nicht. Und so kommt ws das eben z.b. Der Hue Adapter auf einmal recht viele state änderungen publisht und das macht dann hin/wieder recht hohe state peaks. Helfen würde hierbei IMHO wenn Bluefox dem adapter.setState() wie hier besprochen (http://forum.iobroker.net/viewtopic.php?f=24&t=4868) eine möglichkeit verpassen würde die werte nur zu setzen/publishen wenn sich die werte auch geändert haben. IMHO wäre es ggf auch testweise mal interessant per default die adapter.setState() funktion sich so verhalten zu lassen und nur adapter die eben nicht in regelmäßigen Abständen werte abholen sondern diese aktiv geliefert bekommen sollten setState dann mit einer force option aufrufen. iMHO sollte sich somit das state change augkommen radikal reduzieren lassen. `
setStateIfChanged Funktion wird nicht besonders helfen, sogar die Sache verschlimmern.Man muss erst den Wert lesen und dann updaten. Das sind 2 requests über Netz. (Im iobroker läuft doch alles über sockets). Wenn man einfach schreibt, dann ist das nur ein request.
Natürlich danach bekommen history und Co und admin die Werte, aber besser ist natürlich im Adapter zu prüfen.
HueLampen sind vermutlich boolean, und wenn sogar dimmer, dann pro Wert 8 Bytes.
Wenn 100 Lampen sind es 800 Bytes. Ein Adapter braucht aber 20 MB Minimum. 1kb ist im Vergleich nichts.
-
Update auf 0.15.3 hat nicht funktioniert. ioBroker startet nicht mehr.
Fehlermeldung:
! ````
root@ubuntu1604server:/opt/iobroker# iobroker upgrade self
npm install iobroker.js-controller --production --prefix "/opt/iobroker" (System call)
module.js:327
throw err;
^
! Error: Cannot find module './lib/encoding'
at Function.Module._resolveFilename (module.js:325:15)
at Function.Module._load (module.js:276:25)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at loadModule (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io/node_modules/engine.io/node_modules/accepts/node_modules/negotiator/index.js:108:16)
at Negotiator.encodings (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io/node_modules/engine.io/node_modules/accepts/node_modules/negotiator/index.js:56:28)
at Accepts.encoding.Accepts.encodings (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io/node_modules/engine.io/node_modules/accepts/index.js:136:26)
at XHR.Polling.doWrite (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io/node_modules/engine.io/lib/transports/polling.js:301:36)
at XHR.Polling.write (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io/node_modules/engine.io/lib/transports/polling.js:266:8)
at /opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io/node_modules/engine.io/lib/transports/polling.js:251:10
root@ubuntu1604server:/opt/iobroker#npm 2.1.5.11 node 4.7.2 Ubuntu 16.04 [EDIT] Oben die Meldung bezog sich darauf, welche Meldung nach der "normalen" Update-Reihenfolge kam. Nach der Neuinstallation des js-controllers funktioniert es.npm install iobroker.js-controller
-
Da ich dort am besten alles testen kann habe ich mein Produktivsystem (nach einem Backup :lol: ) auf die git Version von js-controller, admin, vis und web geupdated.
Bisher läuft fast alles rund, keine Probleme beim Updaten (alles über shell) und beim Starten danach.
Eine Sache ist mir aber aufgefallen, ich kann aber nicht sagen ob es am Update liegt, weil ich es vorher nicht getestet habe:
Wenn ich Web/Vis mit https und auth absichere, kann ich nur noch mit dem Standard-Admin User auf die Views zugreifen. Ein zweiter User, welcher auch in der Admin-Gruppe ist, kann zwar edit.html nutzen, aber index.html bleibt bei "Lade Werte…" hängen. In der Browserkonsole kommt dies hier:
conn.js:266 2017-01-20T11:18:03.426Z Connected => authenticate conn.js:281 2017-01-20T11:18:03.561Z Authenticated: true vis.js:3202 Request 0 states.Mit dem Standard-Admin User:
conn.js:266 2017-01-20T11:20:29.266Z Connected => authenticate conn.js:281 2017-01-20T11:20:29.382Z Authenticated: true vis.js:3202 Request 0 states. vis.js:3219 Create inner vis object harmony.0.Wohnzimmer_Hub.TV.Exit vis.js:3219 Create inner vis object harmony.0.Wohnzimmer_Hub.TV.Return vis.js:3219 Create inner vis object harmony.0.Wohnzimmer_Hub.TV.Select [...] vis.js:2796 [1484911229917] Request 115 states. ```` `Bitte checken was für eine iobroker.socketio Version installiert. Sollte 1.7.4 sein.
/opt/iobroker/node_modules/iobroker.socketio
und
/opt/iobroker/node_modules/iobroker.web/node_modules/iobroker.socketio
-
Bitte checken was für eine iobroker.socketio Version installiert. Sollte 1.7.4 sein.
/opt/iobroker/node_modules/iobroker.socketio
und
/opt/iobroker/node_modules/iobroker.web/node_modules/iobroker.socketio `
Der Fix dafür war mein letzter Pull-Request:
Support us
752
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge