Neuer Adapter:::milight-smart-light
-
Hallo Chris,
deswegen ja auch mein Hinweis auf den Szenen-Adapter.
Grüsse
Carsten
-
Hallo nochmal. Ich habe nun eine Szene erstellt, mit den Datenpunkten on, off und brightness und diese im Cloudadapter eingetragen. Ein und Ausschalten funktioniert nun über den echo dot problemlos. Das einstellen der Helligkeit allerdings nicht. Auch wüsste ich nicht wie ich so die Farbe des angeschlossenen LED Bandes ändern sollte.
Könntest du mir hier vll ein Bsp. geben?
Vielen Dank und gute Nacht,
Chris
-
Hallo,
Ist es möglich den Adapter für MiLight auch in Abhängigkeit der MAC Adresse (nicht nur IP) zu definieren?
Grund:
Ich betreibe eine simulierte MiLight-Bridge über esp8266. Hier kann man mehrere Bridges parallel (mit je 4 Zonen) betreiben. Habe so 2 Bridges stabil im Betrieb. Die Original-Bridges werden nicht benötigt.
Leider differenziert man die einzelnen Bridges dann mit einer selbst def. MAC Adresse. Die IP ist für alle aber gleich. Ich kann diese zwar über die Rest-API steuern oder über FB.Switch, möchte aber über io.broker die Ansteuerung zu ALEXA umsetzen.
Wäre super, wenn dies möglich ist.
Gruß
Smoker
-
Das geht leider nicht, da zur Kommunikation mit den Bridges ein UDP-Socket auf die IP und den Port gebunden wird. So ist das auch in dem Node.js Package von mwittig, dass die Milight-Basis des Adapters bildet, umgesetzt.
-
Das geht leider nicht, da zur Kommunikation mit den Bridges ein UDP-Socket auf die IP und den Port gebunden wird. So ist das auch in dem Node.js Package von mwittig, dass die Milight-Basis des Adapters bildet, umgesetzt. `
Danke für die Rückinfo.
Ein Tipp wie ichs eventuell doch hinbekomme?
Gruß
-
Leider erzeugt der Adapter keine Datenpunkte, obwohl in der Konfiguration die iBox2 gefunden wird (einen system.adapter.milight-smart-light gibt es schon, der auch alive und connected meldet).
Ich habe über das Web-Interface der iBox2 den Port des TCP-Servers auf 5987 gesetzt und auch so in der Konfiguration eingetragen.
Woran kann es nun noch liegen, was muss ich prüfen?
-
Folgende Punkte kannst Du mal überprüfen:
1. Hast Du node.js und Adapter Admin in der minimal erforderlichen Version installiert?
2. Hast Du die angelegte(n) Zone(n) auch aktiviert (Haken bei aktiv gesetzt)?
Wenn das alles nicht hilft:
3. Installiere einmal die aktuelle GitHub-Version des Adapters.
-
Danke für Deine Unterstützung. Du hast 3 Optionen genannt, an denen es liegen konnte und der Fehler lag an Option … 4
Im Ernst: Wenn man - wie ich - bei den Zonen-Namen nichts einträgt, werden auch keine Datenpunkte angelegt.
Erst als ich zu meinem RP1 noch einen zusätzlichen iobroker-Host aufgesetzt hatte, um auszuschließen, dass das auf einem RP1 nicht mehr direkt unterstützte node-Paket die Ursache ist, kam ich drauf und konnte das Problem auch reproduzieren.
Vorschlag: Wenn kein Zonen-Namen eingetragen, die Zone aber aktiviert ist, sollte entweder im Konfig-Dialog ein Hinweis erscheinen oder man nimmt als Namen für den Datenpunkt etwas entsprechendes ("Zone 1..5") als Default-Wert.
Dein Adapter funktioniert bei mir mit diesem "https://www.amazon.de/LIGHTEU%C2%AE-Controller-Wireless-Downlight-Kompatibel/dp/B073WVLH3F/ref=sr_1_1?ie=UTF8&qid=1514901774&sr=8-1&keywords=ibox2" und jenem "https://www.amazon.de/LIGHTEU-Kompatibel-Foodlights-Tracklights-Dekoration/dp/B01NANQ1D2/ref=sr_1_4?ie=UTF8&qid=1514901923&sr=8-4&keywords=ibox+controller" Controller.
Danke. Toller Job.
-
Danke für den Vorschlag. Ich habe unter die Tabelle (Reiter: Zonen) einen entsprechenden Hinweis für Pflichtfelder aufgenommen. Die Möglichkeit auch unvollständige Zonen (ohne Anlage im Objektbaum) speichern zu können hatte ich damals extra eingebaut. Die aktualisierte Version ist jetzt über GitHub installierbar und ab morgen auch über das Latest-Repository.
-
Der Adapter verhält sich in meiner Umgebung reproduzierbar seltsam nach einem Neustart. Zunächst stehen alle Werte auf "NULL". Versuche ich sie im Objektbaum zu ändern (z.B. onoff = true), dann wird zwar der Wert akzeptiert (z.B. das Licht eingeschaltet), aber im Objektbaum wird weiterhin "NULL" angezeigt. Das gilt auch für die anderen Properties.
Das Verhalten ist ärgerlich, da damit eine Steuerung über Scripte zunächst versagt.
Aber nun: Wenn ich einmalig das Web-Interface aus der Adapter-Instanz aufrufe, dann werden die Werte bei Veränderung auch im Objektbaum initialisiert und abrufbar. Danach laufen auch die Scripte wieder wie erwartet - leider nur bis zu einem Adapter-Neustart.
Mein Verdacht: Der Adapter geht nicht korrekt mit dem Initialisierungszustand "NULL" um. Die Steuerelemente des Web-Interface benutzen wohl eine andere Art und Weise, ihre Werte im Objektbaum zu aktualisieren und können so mit "NULL" umgehen.
-
Der Initialisierungszustand des Adapters ist so wie von Dir beschrieben, d.h. die Datenpunkte off= true, on=false und onoff=false. Alle anderen Datenpunkte haben den initialen Wert null.
Warum ist das so?
Das Milight-System erlaubt nicht das Abfragen des letzten Farbwertes, Effectmode, etc. und ist auch nicht rückkanalfähig. Wenn Du also den Adapter erstmalig instanzierst oder neu startest und dann als erstes den DP:on=true setzt wird die Bulb / der Strip auf den letzten im Controller (bei Strips) / der Bulb gespeicherten Farbwert (kann auch weiß sein) gesetzt, ohne dass dieser dem Adpater durch die iBox "irgendwie" mitgeiteilt (rückgemeldet) wird (den gleichen Effekt hast Du auch wenn Du die Milightfernbedienung verwendest -> bekommt der Adapter auch nicht mit, deswegen nutzte ich zum schalten ausserhalb von ioBroker auch gerne die App) und die korrespondierenden Datenpunkte im Objetbaum gesetzt werden. Das ändert sich erst, wenn Du (wie von Dir auch schon richtig festgestellt) über einen der Datenpunkte die Steuerung vornimmst (z.B. über die App, über VIS, direkt über den Admin im Objektbaum, einem eigenen Script, einer Szene oder via node-red). In Deinen eigenen Scripts hast Du immer die Möglichkeit den DP-Wert auf null zu testen, dann weisst Du auch ob dieser schon einmal nach der Initialisierung gesetzt wurde.
-
Tja, das trifft es leider nicht ganz. Hier die reproduzierbaren Steps im Objektbaum mit diesem "https://www.amazon.de/LIGHTEU%C2%AE-Controller-Wireless-Downlight-Kompatibel/dp/B073WVLH3F/ref=sr_1_1?ie=UTF8&qid=1514901774&sr=8-1&keywords=ibox2" Controller (steuert Light-Strips):
- 1. Adapter neu starten -> Zustand aller Objekt-Eigenschaften: NULL
- 2. Zustand: onoff = NULL -> Setzen: onoff = true -> Licht schaltet ein -> Zustand: onoff = true
- 3. Zustand: brightness = NULL -> Setzen: brightness = 80 -> Licht wird entsprechend hell -> Zustand: brightness = NULL
Das bedeutet, egal ob händisch im Objektbaum oder per Skript, nicht-logische Werte (brightness, hue, saturation) bleiben auch nach einem Setzen (um das initiale Abfrage geht es mir gar nicht) im uninitialisierten Zustand.
Rufe ich nun das Webinterface auf und klicke mir auf einen Farbwert, dann erscheinen die entsprechende Werte im Objektbaum, unabhängig vom Init-Zustand.
Für mich bedeutet das, dass ich nach einem Adapter-Neustart zunächst in das Webinterface gehen muss, bevor die Milight-Scripte korrekt arbeiten können. Irgendetwas scheint also beim Setzen über das Web-Interface anders zu laufen. Kannst Du mir da etwas weiter helfen?
Vielen Dank schonmal.
Edit: Mein anderer "https://www.amazon.de/LIGHTEU-Kompatibel-Foodlights-Tracklights-Dekoration/dp/B01NANQ1D2/ref=sr_1_4?ie=UTF8&qid=1514901923&sr=8-4&keywords=ibox+controller" Controller zeigt dieses Verhalten nicht, d.h. uninitialisierte Werte (für z.B. Brightness) werden durch das Setzen korrekt im Objektbaum angezeigt. Ist da an der Art der Implentierung für die beiden Adapter etwas unterschiedlich (beide Controller verwenden API V6 und die Firmware V1.0.08)?
BTW, das ist für mich wirklich keine große Sache und meine Problemmeldung soll Deine Arbeit in keiner Weise weniger würdigen.
-
Danke für Deine Rückmeldung. Es gibt eine neue Version 0.1.6 (via GitHub sofort, via latest-Repository ab morgen). Ich habe noch einen Bug in der Funktion rgbToHsv(r,g,b) gefunden, wodurch es zu dem unterschiedlichen Verhalten kam.
Meine Erläuterungen vom 05.01.2018, 15:35 bleiben davon unberührt. Noch einmal zur Verdeutlichung:
-
Adapter wird initialisiert -> DP:on=false, DP:onoff=false, DP:off=true, alle anderen DP=null.
-
Du änderst DP:brightness auf 10% -> Bulb oder Strip ändern ihren Helligkeitswert so wie gewünscht, aber DP:rgb=#1a1a1a (bei V6) oder DP:rgb=#1a0000 (bei V4/legacy). Dies entspricht einem sehr dunkelen Farbton und mit Sicherheit nicht der Farbe Deiner Bulb / Deines Strip. Dies liegt daran, dass der Adapter nach der Initialisierung/dem Neustart den aktuellen Farbwert der iBox/des Milight-Controllers nicht kennt und den Initialisierungswert null im DP:rgb als #000000 (schwarz) interpretiert. Wenn Du dann den DP:brightness auf 10% setzt entspricht dies eben #1a1a1a (V6) oder #1a0000 (V4), also fast immer noch schwarz. Dies liegt daran, dass der Adapter so von mir programmiert wurde, dass die DP rgb, hue,brightness und saturation immer synchron sind. Das habe ich deswegen so implementiert, damit in VIS (oder z.B. auch in der App) die mit den DP korrespondierenden Widgets immer synchron laufen. Wenn Du z.B. in VIS einen Schieberegler mit DP:brightness verbindest, dann wird auch direkt z.B. der farbtastic Colorpicker aktualisiert und umgekehrt. Diesen Effekt hast Du ja auch schon festgestellt, indem Du in der App einen Farbwert gewählt hast. Danach waren die DP rgb, brightness, saturation und hue im Objektbaum des Admin alle gesetzt.
-
-
Gut, wie erwartet hat die neue Version 01.6. nichts am diskutierten Problem geändert und ich kann leider mit der von Dir eingebauten, für mich als Anwender intransparenten Logik nicht warm werden. Okay, Du bist der Autor und allen anderen steht es frei, Deine Arbeit zu nutzen … oder es zu lassen. Oder miteinander zu diskutieren.
Was stört mich? Nun ich setze per Script den Brightness-Wert, um einen Fade-In/Fade-Out-Effekt zu erzielen. Mit dem initialen NULL-Wert komme ich zurecht und auch das Script inkrementiert - im Objektbaum gut sichtbar - brav den Brightness-Wert von 0-100% beim Fade-In, um zum Schluss wieder auf NULL zu stehen.
Das sieht wie ein klassischer Fehler aus - zumindest für mich.Aber vielleicht hilft es schon, wenn Du kurz erläuterst, wie man den von Dir als synchron bezeichneten Zustand initial herstellt. Welche Werte von rgb, hue, brightness und saturation müssen dafür angefasst werden? Wäre es u.U. sinnvoll, Presets als DP (so wie in der Milight-Phone-App) bereitzustellen und eines davon als Default/Init zu definieren?
-
Installiere den Adapter noch einmal neu (vorher die Instanzen löschen). Die neue Version sollte Dein "Problem" eigentlich beheben, d.h. wenn Du den DP:brightness setzt, hat dieser auch bestand und fällt nicht mehr auf null zurück.
Synchron bedeutet nur, dass der aktuelle rgb-Farbwert (nachdem er einmal gesetzt wurde -> mit den bekannten Möglichkeiten) auch immer dazu führt, das der korrespondierende HSV-Wert (H == DP:hue, S==DP:saturation, V==DP:brightness) passend gesetzt wird. Wenn Du den DP:rgb in Deinem Script auf irgendeinen Farbwert (#rrggbb) setzt (kannst Du auch "händisch" über den Objektbaum im Admin ausprobieren), hast Du auch automatisch die DP: hue, saturation und brightness richtig gesetzt (nichts anderes macht auch die App, wenn Du über einen Colorpicker eine Farbe auswählst).
-
Hallo,
Ist es möglich den Adapter für MiLight auch in Abhängigkeit der MAC Adresse (nicht nur IP) zu definieren?
Grund:
Ich betreibe eine simulierte MiLight-Bridge über esp8266. Hier kann man mehrere Bridges parallel (mit je 4 Zonen) betreiben. Habe so 2 Bridges stabil im Betrieb. Die Original-Bridges werden nicht benötigt.
Leider differenziert man die einzelnen Bridges dann mit einer selbst def. MAC Adresse. Die IP ist für alle aber gleich. Ich kann diese zwar über die Rest-API steuern oder über FB.Switch, möchte aber über io.broker die Ansteuerung zu ALEXA umsetzen.
Wäre super, wenn dies möglich ist.
Gruß
Smoker `
Geht das nicht mit Routen und iptables?
-
Hallo,
Ist es möglich den Adapter für MiLight auch in Abhängigkeit der MAC Adresse (nicht nur IP) zu definieren?
Grund:
Ich betreibe eine simulierte MiLight-Bridge über esp8266. Hier kann man mehrere Bridges parallel (mit je 4 Zonen) betreiben. Habe so 2 Bridges stabil im Betrieb. Die Original-Bridges werden nicht benötigt.
Leider differenziert man die einzelnen Bridges dann mit einer selbst def. MAC Adresse. Die IP ist für alle aber gleich. Ich kann diese zwar über die Rest-API steuern oder über FB.Switch, möchte aber über io.broker die Ansteuerung zu ALEXA umsetzen.
Wäre super, wenn dies möglich ist.
Gruß
Smoker `
Geht das nicht mit Routen und iptables? `
Die Fragestellung hatte nichts mit Routen oder iptables zu tun. Ganz andere Baustelle.
-
Hallo auch,
habe den Standartport für Version 6 stehen und bekomme diesen Fehler:
milight-smart-light.0 2018-01-19 21:40:59.953 error on:stateChange:mslcommandsV6->Port should be > 0 and < 65536 milight-smart-light.0 2018-01-19 21:40:59.952 error on:stateChange:mslcommandsV6->Port should be > 0 and < 65536 milight-smart-light.0 2018-01-19 21:40:59.951 error on:stateChange:mslcommandsV6->Port should be > 0 and < 65536Woran könnte das liegen?
-
Hallo, ich habe es jetzt geschafft meine RGBW und RGBW+CCT Milights an eine IBox2 und einem Ibox Nachtlicht anzulernen und im Iobroker so eizutragen, dass die Datenpunkte richtig erzeugt werden und funktionieren.
Ich habe es auch geschafft, die SmartGeräte im CLoudadapter anzulegen. Ich habe dazu den CLoudadaopter auf 3.0 aktualisiert, da ich mit niedrigeren Versionen immer Probleme hatte, die ich leider nicht mehr benennen kann.
Um die Milights dort richtig einzubinden bin ich den umständlichen Weg gegangen im RAW Modus zu den einzelnen DPs die gesteuert werden sollen immer den Smartname "händisch" einzutragen:
z.B.:
"smartName": {
"de": "Leselampe",
"smartType": "LIGHT",
"byON": "-"
}
Farb-, Dim-, und Ab/Aus Befehle werden jetzt auch korrekt von Alexa übermittelt und ausgeführt.
Leider werden die Leuchten aber beim Befehl "ALexa Licht Weiß" auf ROT geschaltet. Der Hue Datenpunkt kriegt dann den Wert 0.
Meine Frage ist, wie schaffe ich es das die Leuchten dann auch wirklich Weiß leuchten. Also so als wenn ich den WhiteMode Datenpunkt Button drücke. Bzw. das byON auch für den WhiteMode Button funktioniert, so das die Lampen beim Einschalten immer weiß leuchten. Zur Zeit bleiben sie ja in ihrem letzten Zustand.
Und ist es möglich, dass vielleicht sogar ein Befehl zur Farbtemperatur Wirkung zeigt (eher nicht so wichtig!)
Welche Datenpunkte sind überhaupt für Alexa notwendig? Ich hab jetzt einfach ein paar per Trial und Error eingefügt.
Und wo kann ich mal herausfinden wie Alexa und der Cloudadapter eigentlich genau zusammenarbeiten. Mir ist es ein Rätzel wie ALexa die Werte übermittelt und wie sie in die OBjekte kommen.
Und warum muss man die Smartnames zu jeder Lampe bei mehreren DPs händisch eintragen? Ist das so gewollt oder gibt es da einen besseren Weg?
Eine RGB+CCT Leselampe hat schon einmal bei "ALexa Licht weiß" tatsächlich auf weiß geschaltet. Ich konnte aber nicht rausfinden warum nur diese eine sich so verhielt. Und leider wurde sie dann beim umbenennen der Zone gelöscht. Ich meine ich hatte bei ihr nur color.hue, level.dimmer. white.temperatur und den on/off Switch eingebunden.
Aber nach nochmaligem anlegen schaltet auch sie jetzt auf rot statt weiß.
Ein weiteres Phonemen, welches ich nicht verstehe ist, das einige Lampen die Farbe Magenta "kennen" aber z.B. bei der RGBW+CCT Lampe sagt Alexa mir: "Ich konnte Lampe Magenta nicht finden!"?
Wäre für jede Hilfe sehr dankbar. Bin schon seit Tagen am rumprobieren und recherchieren. Komme aber nicht richtig weiter. LG Andreas
5285_cloud.png -
Hallo Andreas,
super das Du dich mit dem Thema Milight schon so intensiv beschäftigt hast. So wie Du vorgegangen bist hast Du auch schon fast alles richtig gemacht. Ich nehme Deine Frage jetzt mal zum Anlaß und erkläre etwas ausführlicher "from the scratch" die Einrichtung, weil ich denke, dass auch noch einige andere User Interesse haben könnten. Also fangen wir mal an:
(1) Folgende Adapter-Versionen müssen installiert sein:
a) milight-smart-light: v 0.1.8 (-> aus dem Latest-Repository)
b) cloud: Version v 2.4.4 (-> aus dem Latest-Repository)
(2) Folgende zwei Dateien im cloud-Adapter austauschen: [Stand 24.01.: Nicht mehr erforderlich. Bitte Cloud-Adapter aus dem online-Repository installieren, nicht aus dem Latest-Repository!]
a) admin/actions.js und ersetzen durch: https://raw.githubusercontent.com/Wolfs … actions.js
b) lib/alexaSmartHomeV2.js und ersetzen durch: https://raw.githubusercontent.com/Wolfs … tHomeV2.js
Hintergrund: der cloud-Adapter hat noch zwei drei kleinere Fehler im Umgang mit der Lichtsteuerung, die durch den user WolfspiritM auf GitHub gefixt wurden, aber von Bluefox noch nicht übernommen wurden, da er das Ganze mit Sicherheit erst noch kritisch prüfen wird. Bei mir läuft mit dem milight-smart-light-Adapter aber alles super stabil, so dass ich den Dateiaustausch ruhigen Gewissens, aber natürlich ohne Garantie, empfehlen kann. Trotzdem solltest Du aber vor dem Austausch der Dateien eine Sicherungskopie des iobroker-Verzeichnisses machen, damit Du im Fall der Fälle alles wieder schnell auf den alten Stand bringen kannst. In einer der nächsten cloud-Versionen sind dann die Änderungen von WolfspiritM sicherlich enthalten. Wenn Du die Dateien ausgetauscht hast klappt dann auch ein "wärmer" und "kälter" stellen des weissen Lichtes ohne Probleme.
(3) Anlegen der benötigten Funktionen und Räume im Admin unter Aufzählungen und dann enum.functions und enum.rooms.
(4) Anlegen einer Zone im Admin von milight-smart-light. Hier am Beispiel einer iBox2 und eines Strip vom Typ RGB + CWWW im Raum Büro (enum.rooms.büro) mit der Funktion Licht (enum.functions.licht) und den zugehörigen Datenpunkten (states)
Hier hat es eine Änderung beim DP:whiteTemperature gegeben (Unit ist jetzt nicht mehr % (0 - 100), sonder K (2700K bis 6500K).(5) Im Admin des cloud-Adapters sollte unter Smart Geräte jetzt folgender Eintrag automatisch erscheinen (wenn nicht cloud-Adapter einmal neu starten):
Hier sind jetzt alle dem cloud-Adapter als "sinnvoll" erscheinende Datenpunkte auf Grund des Automatismus via enum.functions und enum.rooms (s.a. Reiter "Smart-Aufzählungen" im cloud-Admin -> Büro und Licht sind ausgewählt) übernommen worden. Es werden aber nicht alle Datenpunkte benötigt und auch die Grundeinstellungen der dann verbleibenden Datenpunkte müssen noch angepasst werden, daher(6) Anpassung des Smart Gerätes "Büro Licht" wie folgt:
Hierbei ganz wichtig: nur den Datenpunkt:Color RGB verwenden und nicht noch zusätzlich DP: Saturation und DP:Color HUE. Dies ist nur spezifisch für meinen Adapter (milight-smart-light) und liegt an der internen Implementierung.So das sollte es auch schon gewesen sein. Jetzt sind eigentlich alle Alexa-Befehle im Zusammenhang mit der Lichtsteuerung möglich. Hierzu auch noch einmal die folgenden Links anschauen:
a) https://www.amazon.de/gp/help/customer/ … =202134360
Die Farbliste ist nicht abschließend. Alexa versteht noch viel mehr Farben. Einfach selbst probieren.
b)https://www.amazon.de/gp/help/customer/ … =201749260
(Hier findest Du einige grundsätzliche Befehle)
Letzter Hinweis: bei strips oder bulbs mit weissem Licht führt eine Alexa Ansage "Alexa schalte Bürolicht auf weiss" noch bei einigen Typen zu einem Rotton. Dies liegt daran, dass der milight-Farbkreis die Farbe weiss nicht kennt. Hier muss explizit eine Umschaltung über den DP:whiteMode (geht nicht bei allen Milight-Bulbs) oder den DP: whiteTemperature erfolgen. Dies liegt also nicht an der Konfiguration des cloud-Adapters, sondern am milight-smart-light-Adapter. In einer der nächsten Versionen implementiere ich dafür eine Lösung.
Grüße
Carsten
