NEWS
Neuer Adapter:::milight-smart-light
-
@darthbully Dann mal zur Erläuterung: die Werte in Deinen screenshots sind alle richtig. #404040 ist ein Grauwert, also ein nicht so helles Weiß. Die whiteTemperature ist die Farbtemperatur für Weiß und hat keinen Einfluß auf den RGB-Wert. Sie wirkt sich aber natürlich dann aus, wenn Du eine Saturation größer 0% wählst, dann wird eben warmweiß bis kaltweiß (je nach whiteTemperature-Wert) dazugemischt . Der Adapter berücksichtigt immer die Abhängigkeiten zwischen RGB und HSV (hue, saturation, brightness). Also saturation=0% und brightness=100% ist immer rgb=ffffff, also maximales Weiss. Je nach whiteTemperature ist das dann irgendwas zwischen warmweiß (2700K) und kaltweiß (6500K). Wenn Du die brightness dann runtersetzt und die saturation weiterhin 0% ist, entspricht das einem rgb-Grauton (z.B. #404040). Der gleiche Zusammenhang zwischen RGB und HSV gilt natürlich auch für jede andere Farbe (das kannst Du gut im Objektbaum beobachten, wenn Du einen der genannten Werte änderst.) #000000 entspricht schwarz und damt wird die Bulb / der Strip off gesetzt, d.h. die brightness wird 0%. Wenn Du dann wieder anschaltest, wird der letzt rgb-Wert wieder gesetzt. Das Ganze habe ich so implementiert, damit die Abhängigkeiten zwischen RGB und HSV sich immer in den states des Objektbaums (auch on, off, onoff) wiederspiegeln. Dadurch werden z.B. auch alle vis-Elemente immer synchron gehalten, wenn Du z.B. einen Slider für brightness, saturation, etc. nutzt. Der vis-colorpicker kann dadurch auch genutzt werden, da dieser auch die Auswahl aller Weiß- bis Grautöne zuläßt. Änderst Du also z.B. mit dem vis-colorpicker den rgb-Wert, werden alle anderen Elemente für hue, saturation, brightness, (on, off, onoff) entsprechend aktualisiert.
-
@carsten04 sagte in Neuer Adapter:::milight-smart-light:
Alle die den Fehler "Server resources are not available!" beim laden der App hatten, bitte den Adapter noch einmal neu via Github installieren (vorher sauber deinstallieren). Es müsste dann eigentlich funktionieren. Bitte hier Rückmeldung geben, damit ich danach eine neue Version in das latest Repository einstellen kann.
Auf keinen Fall diese Version ins Repo tun. Ich weiß noch nicht genau bei welcher Aktion, aber der Adapter reißt die admin-Instanz zu Boden. Admin Web "antwortet" nicht mehr und im Log werden Fehler geworfen:
2019-02-17 19:41:12.990 - ESC[32minfoESC[39m: host.fuchs-virt instance system.adapter.admin.0 started with pid 2001 2019-02-17 19:41:13.991 - ESC[32minfoESC[39m: admin.0 starting. Version 3.5.10 in /home/iobroker/node_modules/iobroker.admin, node: v8.15.0 2019-02-17 19:41:14.013 - ESC[32minfoESC[39m: admin.0 requesting all states 2019-02-17 19:41:14.015 - ESC[32minfoESC[39m: admin.0 requesting all objects 2019-02-17 19:41:14.015 - ESC[32minfoESC[39m: admin.0 Request actual repository... 2019-02-17 19:41:15.095 - ESC[32minfoESC[39m: admin.0 received all states 2019-02-17 19:41:16.149 - ESC[32minfoESC[39m: admin.0 received all objects 2019-02-17 19:41:16.290 - ESC[32minfoESC[39m: admin.0 http server listening on port 8081 2019-02-17 19:41:16.291 - ESC[32minfoESC[39m: admin.0 Use link "http://localhost:8081" to configure. 2019-02-17 19:41:16.408 - ESC[32minfoESC[39m: host.fuchs-virt Update repository "default" under "http://download.iobroker.net/sources-dist.json" 2019-02-17 19:41:17.929 - ESC[31merrorESC[39m: admin.0 uncaught exception: updateConnectedInfo is not defined 2019-02-17 19:41:17.929 - ESC[31merrorESC[39m: admin.0 ReferenceError: updateConnectedInfo is not defined at Socket.<anonymous> (/home/iobroker/node_modules/iobroker.admin/lib/socket.js:555:70) at emitOne (events.js:116:13) at Socket.emit (events.js:211:7) at /home/iobroker/node_modules/iobroker.admin/node_modules/socket.io/lib/socket.js:503:12 at _combinedTickCallback (internal/process/next_tick.js:132:7) at process._tickCallback (internal/process/next_tick.js:181:9) 2019-02-17 19:41:17.930 - ESC[32minfoESC[39m: admin.0 terminating http server on port 8081 2019-02-17 19:41:18.131 - ESC[32minfoESC[39m: admin.0 Repository received successfully. 2019-02-17 19:41:18.177 - ESC[31merrorESC[39m: Caught by controller[0]: ReferenceError: updateConnectedInfo is not defined 2019-02-17 19:41:18.177 - ESC[31merrorESC[39m: Caught by controller[0]: at Socket.<anonymous> (/home/iobroker/node_modules/iobroker.admin/lib/socket.js:555:70) 2019-02-17 19:41:18.178 - ESC[31merrorESC[39m: Caught by controller[0]: at emitOne (events.js:116:13) 2019-02-17 19:41:18.178 - ESC[31merrorESC[39m: Caught by controller[0]: at Socket.emit (events.js:211:7) 2019-02-17 19:41:18.178 - ESC[31merrorESC[39m: Caught by controller[0]: at /home/iobroker/node_modules/iobroker.admin/node_modules/socket.io/lib/socket.js:503:12 2019-02-17 19:41:18.178 - ESC[31merrorESC[39m: Caught by controller[0]: at _combinedTickCallback (internal/process/next_tick.js:132:7) 2019-02-17 19:41:18.178 - ESC[31merrorESC[39m: Caught by controller[0]: at process._tickCallback (internal/process/next_tick.js:181:9) 2019-02-17 19:41:18.178 - ESC[31merrorESC[39m: host.fuchs-virt instance system.adapter.admin.0 terminated with code 0 (OK) 2019-02-17 19:41:18.178 - ESC[32minfoESC[39m: host.fuchs-virt Restart adapter system.adapter.admin.0 because enabled 2019-02-17 19:41:48.188 - ESC[32minfoESC[39m: host.fuchs-virt instance system.adapter.admin.0 started with pid 2034
Ich denke, ich deinstalliere den Adapter mal schleunigst wieder.
-
@cactus-online Das hat nichts mit meinem Adapter zu tun. Ich habe jetzt gerade extra noch einmal via Github bei mir auf der Produktionsumgebung installiert. Läuft tadellos durch und App funktioniert sofort.
-
@carsten04 sagte in Neuer Adapter:::milight-smart-light:
@cactus-online Das hat nichts mit meinem Adapter zu tun. Ich habe jetzt gerade extra noch einmal via Github bei mir auf der Produktionsumgebung installiert. Läuft tadellos durch und App funktioniert sofort.
Dann weiß ich auch nicht. Adapter deinstalliert-> Admin ist wieder da und die Fehler im Log sind weg.
-
@cactus-online Mhmm . . . eigentlich kann das nicht sein. Du nutzt ja noch den js-controller v1.4.2, richtig? Da läuft jeder Adapter (auch der Admin) immer in einem eigenen Prozess. Was nutzt Du denn für eine HW (wieviel RAM?) und wieviele Adapter laufen denn bei Dir? Kommen die Fehlermeldungen sofort nach Beendigung der Installation, oder erst nach speichern der Instanz?
-
@carsten04
Vielen Dank für deine sehr umfangreiche Erläuterung. Jedoch kann ich nicht mein Problem darin erkennen.
Es geht ja darum, dass ich den FUT039 Treiber verwende, welcher 5in1 Dioden steuert. Sprich RGB WW KW
Deiner Erläuterung entnehme ich, dass Du das Warmweiß durch RGB und Sättigung erzeugst. Das ist aber bei 5in1 Stripes nicht notwendig, da diese ja bereits Kaltweiß (ca. 6500K) und Warmweiße (ca. 2700K) Dioden verbaut haben. Dein Adapter scheint aber ab der Version 0.2.0 Werte für WhiteMode (m.E. 6500K) vorzugeben.Testest Du ebenfalls mit RGB WW KW Stripes? Diese müssen ja nicht zwangsweise 5in1 sein. Ich habe das nun auch am selben Treiber (FUT039 http://futlight.com/productdetails.aspx?id=113&typeid=146) mit getrennten LEDs probiert. Dort verhält es es sich genauso.
Änderungen (Brightness udgl.) führen immer dazu, dass Kaltweiß aktiviert wird. Das war in der Version 0.1.9 nicht so.
Dort wurde immer der letzte Wert den der Treiber eingestellt hatte (und das unabhängig von was der eingestellt wurde) wieder aktiviert.
Soll heißen, wenn ich an der Fernbedienung FUT092 http://futlight.com/productdetails.aspx?id=161&typeid=143
oder der B4
http://futlight.com/productdetails.aspx?id=261&typeid=143
was eingestellt habe, dann war das wieder aktiv, wenn ich per Skript onoff auf true gestellt habe. Das ist nun definitiv nicht mehr der Fall.Das einzige was in der Version 0.1.9 nicht funktioniert hat, war das einstellen der Warm/Kaltweiß-Werte über Siri. Zwar konnte ich alle möglichen Farben einstellen auch die Sättigung konnte ich rauf runter beten nur nicht auf Weiß zurückschalten. Da hat Siri die Sättigung hochgezogen und somit den letzten Farbwert "ausgebleicht" was dann sehr helles rot oder sehr helles blau oder sehr helles grün war.
Umstellen auf die Weiß-Töne ging dann nur per Fernbedienung.Liebe Grüße
Chris -
@carsten04 sagte in Neuer Adapter:::milight-smart-light:
@cactus-online Mhmm . . . eigentlich kann das nicht sein. Du nutzt ja noch den js-controller v1.4.2, richtig? Da läuft jeder Adapter (auch der Admin) immer in einem eigenen Prozess. Was nutzt Du denn für eine HW (wieviel RAM?) und wieviele Adapter laufen denn bei Dir? Kommen die Fehlermeldungen sofort nach Beendigung der Installation, oder erst nach speichern der Instanz?
Ich konnte es weiter eingrenzen. Das Problem tritt auf, wenn ich die App (mslfe-ibr) im Browser aufrufe.
2019-02-17 21:41:33.103 - error: admin.0 uncaught exception: updateConnectedInfo is not defined 2019-02-17 21:41:33.103 - error: admin.0 ReferenceError: updateConnectedInfo is not defined at Socket.<anonymous> (/home/iobroker/node_modules/iobroker.admin/lib/socket.js:555:70) at emitOne (events.js:116:13) at Socket.emit (events.js:211:7) at /home/iobroker/node_modules/iobroker.admin/node_modules/socket.io/lib/socket.js:503:12 at _combinedTickCallback (internal/process/next_tick.js:132:7) at process._tickCallback (internal/process/next_tick.js:181:9) 2019-02-17 21:41:33.107 - info: admin.0 terminating http server on port 8081 2019-02-17 21:41:33.111 - info: admin.0 terminating 2019-02-17 21:41:33.130 - error: Caught by controller[0]: ReferenceError: updateConnectedInfo is not defined 2019-02-17 21:41:33.131 - error: Caught by controller[0]: at Socket.<anonymous> (/home/iobroker/node_modules/iobroker.admin/lib/socket.js:555:70) 2019-02-17 21:41:33.131 - error: Caught by controller[0]: at emitOne (events.js:116:13) 2019-02-17 21:41:33.131 - error: Caught by controller[0]: at Socket.emit (events.js:211:7) 2019-02-17 21:41:33.131 - error: Caught by controller[0]: at /home/iobroker/node_modules/iobroker.admin/node_modules/socket.io/lib/socket.js:503:12 2019-02-17 21:41:33.131 - error: Caught by controller[0]: at _combinedTickCallback (internal/process/next_tick.js:132:7) 2019-02-17 21:41:33.131 - error: Caught by controller[0]: at process._tickCallback (internal/process/next_tick.js:181:9) 2019-02-17 21:41:33.131 - error: host.fuchs-virt instance system.adapter.admin.0 terminated with code 0 (OK) 2019-02-17 21:41:33.133 - info: host.fuchs-virt Restart adapter system.adapter.admin.0 because enabled
Schließe ich den Tab fängt sich der Admin wieder.
2019-02-17 21:42:03.146 - info: host.fuchs-virt instance system.adapter.admin.0 started with pid 7841 2019-02-17 21:42:04.154 - info: admin.0 starting. Version 3.5.10 in /home/iobroker/node_modules/iobroker.admin, node: v8.15.0 2019-02-17 21:42:04.177 - info: admin.0 requesting all states 2019-02-17 21:42:04.179 - info: admin.0 requesting all objects 2019-02-17 21:42:04.180 - info: admin.0 Request actual repository... 2019-02-17 21:42:05.366 - info: admin.0 received all states 2019-02-17 21:42:06.458 - info: admin.0 received all objects 2019-02-17 21:42:06.604 - info: admin.0 http server listening on port 8081 2019-02-17 21:42:06.604 - info: admin.0 Use link "http://localhost:8081" to configure. 2019-02-17 21:42:06.747 - info: host.fuchs-virt Update repository "default" under "http://download.iobroker.net/sources-dist.json" 2019-02-17 21:42:07.406 - info: admin.0 Repository received successfully.
Der controller ist v 1.2.4
iobroker version 1.4.2
Es sind zur Zeit 18 Adapter aktiv:
iobroker list adapters | wc -l 18
Es ist eine Linux-VM, der Speicher sollte nicht das Problem sein.
free gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 2047988 851044 526800 8440 670144 994508 Auslagerungsspeicher: 499708 0 499708 cat /proc/meminfo MemTotal: 2047988 kB MemFree: 541656 kB MemAvailable: 1009268 kB Buffers: 100304 kB Cached: 465200 kB SwapCached: 0 kB ...
VG,
TF
-
@cactus-online Danke für Deinen Input. Nutzt Du einen eigenen socketio Adapter, oder den Internen des web Adapters? Hast Du egal ob beim socketio Adaper oder web Adapter das nur websocket Kästchen deaktiviert (sollte so sein)?
-
@carsten04 sagte in Neuer Adapter:::milight-smart-light:
@cactus-online Danke für Deinen Input. Nutzt Du einen eigenen socketio Adapter, oder den Internen des web Adapters? Hast Du egal ob beim socketio Adaper oder web Adapter das nur websocket Kästchen deaktiviert (sollte so sein)?
Nein. ich habe keinen socket.io Adapter und wenn ich die integrierten Websockets im Web Adapter deaktiviere ändert sich das Verhalten in Bezug auf den Admin Adapter nicht, allerdings funktioniert dann (erwartungsgemäß) vis nicht mehr. Nur Websockets im Web Adapter ist nicht aktiviert.
-
@carsten04 sagte in Neuer Adapter:::milight-smart-light:
Alle die den Fehler "Server resources are not available!" beim laden der App hatten, bitte den Adapter noch einmal neu via Github installieren (vorher sauber deinstallieren). Es müsste dann eigentlich funktionieren. Bitte hier Rückmeldung geben, damit ich danach eine neue Version in das latest Repository einstellen kann.
Mit der neuen github Version läuft jetzt auch die App. Danke!
-
@RichieXX Was für einen Server verwendest Du? Windows/Linux Raspi/x86 ?
-
@cactus-online
Das ist ein ubuntu 18.04 x86 in einer VM auf einem QNAP NAS. -
@darthbully sagte in Neuer Adapter:::milight-smart-light:
@carsten04
Vielen Dank für deine sehr umfangreiche Erläuterung. Jedoch kann ich nicht mein Problem darin erkennen.
Es geht ja darum, dass ich den FUT039 Treiber verwende, welcher 5in1 Dioden steuert. Sprich RGB WW KW
Deiner Erläuterung entnehme ich, dass Du das Warmweiß durch RGB und Sättigung erzeugst. Das ist aber bei 5in1 Stripes nicht notwendig, da diese ja bereits Kaltweiß (ca. 6500K) und Warmweiße (ca. 2700K) Dioden verbaut haben.Nein das ist nicht richtig (Zusammenhang warmweiß und Sättigung). Ich habe nur versucht zu erklären wie das Zusammenspiel von rgb, hsv und whiteTemperature ist. Diese Zusammenhänge sollten prinzipiell klar sein, denn dann werden auch viele Verhaltensweisen das Adapters verständlich.
Dein Adapter scheint aber ab der Version 0.2.0 Werte für WhiteMode (m.E. 6500K) vorzugeben
Für den whiteMode stimmte das bisher und kommt aus dem dem Adapter zu Grunde liegenden Modul node-milight-promise von mwittig. Ich habe jetzt folgende Änderungen implementiert:
a) whiteMode setzt die whiteTemperature immer auf 2700K und die Helligkeit auf brightness
b) whiteTemperature setzt die Temperatur immer auf den ausgewählten Wert und schaltet das weisse Licht mit der Helligkeit brightness ein. Du brauchst den whiteMode also eigentlich nicht mehr.
Wenn Du das probieren möchtest, dann musst Du via Github noch einmal neu installieren.Testest Du ebenfalls mit RGB WW KW Stripes? Diese müssen ja nicht zwangsweise 5in1 sein. Ich habe das nun auch am selben Treiber (FUT039 http://futlight.com/productdetails.aspx?id=113&typeid=146) mit getrennten LEDs probiert. Dort verhält es es sich genauso.
Änderungen (Brightness udgl.) führen immer dazu, dass Kaltweiß aktiviert wird. Das war in der Version 0.1.9 nicht so.
Dort wurde immer der letzte Wert den der Treiber eingestellt hatte (und das unabhängig von was der eingestellt wurde) wieder aktiviert.
Soll heißen, wenn ich an der Fernbedienung FUT092 http://futlight.com/productdetails.aspx?id=161&typeid=143
oder der B4
http://futlight.com/productdetails.aspx?id=261&typeid=143
was eingestellt habe, dann war das wieder aktiv, wenn ich per Skript onoff auf true gestellt habe. Das ist nun definitiv nicht mehr der Fall.Das ist richtig, ist aber auch so gewollt. Hintergrund ist, dass immer die Werte für rgb, hue, brightness und saturation innerhalb des Adapters stimmig sein sollen. Wenn Du sozusagen von ausserhalb mit einer Milight Fernbedienung einen Wert setzt kriegt das der Adapter ja nicht mit und wenn Du dann wieder mit dem Adapter z.B. einschaltest, schaut der Adapter nach dem ihm zuletzt bekannten Farbwert und setzt diesen wieder (d.h. rgb, brightness, hue und saturation). Das ist halt das Problem des fehlenden "Rückkanals" der Milight-Produkte (und auch vieler Anderer) im Gegensatz zu z.B. den Homematic Sensoren und Aktoren.
Das einzige was in der Version 0.1.9 nicht funktioniert hat, war das einstellen der Warm/Kaltweiß-Werte über Siri. Zwar konnte ich alle möglichen Farben einstellen auch die Sättigung konnte ich rauf runter beten nur nicht auf Weiß zurückschalten. Da hat Siri die Sättigung hochgezogen und somit den letzten Farbwert "ausgebleicht" was dann sehr helles rot oder sehr helles blau oder sehr helles grün war.
Umstellen auf die Weiß-Töne ging dann nur per Fernbedienung.Liebe Grüße
Chris -
Hallo
Habe die gleiche Hardware und die selben Probleme wie in post 24.
Bekomme es nicht hin die LEDs ans laufen zu kriegen.
Egal mit welchem der beiden Adapter.
Hat jemand einen Rat für mich.
Wer mehr Infos braucht kann sich gerne melden -
Bei mir läuft alles allerdings merkt sich der Controller anscheinend keine Einstellungen mehr jedesmal wenn ich anschalte leuchten die Leds weiß obwohl vorher ein Farbprogramm lief. 0.2.1
-
@Camuri Es wird bei on immer auf den letzten rgb-Wert geschaltet.
-
Ich klink mich auch wieder einmal hier ein. Ultrabook war ausser Gefecht, darum länger nichts gemacht am iobroker.
Bei mir verhält sich der Adapter in der neusten Version gleich wie bei @CAMURI und @DARTHBULLY .
Wenn ich den "whiteTemperature" Wert per ioBroker auf z.b. 2700K setzte, dann OFF schalte und und wieder ON schalte ist das Licht Kaltweiss (~6500K) der Wert wird aber weiterhin als 2700K angezeigt.Ist das bei dir nicht so @carsten04 ?
Wohlverstanden: Ich mache alles per ioBroker, die Android App starte ich eigentlich nie, die ist sowas von schlecht. Fernbedienung habe ich gar keine
Der Server für die App läuft bei mir mittlerweile, jedoch wird keine Box zum auswählen angezeigt.
Danke dass du dir hier soviel Zeit nimmst um allen zu Antworten und den Adapter zu verbessern!
-
@tripper Hast Du via Github noch einmal neu installiert? Im whiteMode sind jetzt die 2700K Standard.
-
@carsten04 Ja, das hatte ich. Bin aber wieder zurück auf Version 0.1.9
whiteMode nutze ich im Normalfall gar nicht.
Soweit ich verstanden habe braucht's den auch nicht wirklich, ich nutze hauptsächlich "on", "off" oder "on/off". Darum frage ich mich auch wieso dann an der Farbtemperatur etwas geändert wird ohne das ich willUnd logischerweise müsste dann ja auch der "whiteTemperature" Wert verändert werden, wird er aber NIE ! Mit den neuen Versionen bleibt der immer so wie ich ihn gesetzt habe auf 2700. Aber meine Lampe leuchtet halt trotzdem mit 6500K
Hab mal eine Testumgebung installiert, ich werde ab jetzt dort Versuche mit den neuen Versionen machen. Meine Mitbewohner haben keine Freude wenn das Licht nicht wie gewohnt läuft
-
Seltsam, auf der Testumgebung die ich unter Windows eingerichtet habe läuft alles wie gewünscht inkl. App Server
Entweder funkt da etwas dazwischen auf meiner produktiven Installation oder Linux will nicht bei mir. Dabei hatte ich vor 2 Wochen extra alles komplett neu aufgesetzt und praktisch von null angefangen auf meinem OrangePi