Ich habe gesehen beim Milight Device gibt es auch pair und unpair
Nur zur Klarstellung, ich habe NICHT einen speziellen pair oder unpair-Befehl ausgewählt!
Es handelte sich um eine schlichte empirische Beobachtung unter folgenden Rahmenbedingungen:
Steuerung über FHEM über aktuelle MilightBridge und MilightDevice. Das MilightDevice hat u.A. folgendes attribut:
webCmd on:off:dim:hue:night:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00 deleteattr Klicke ich dort nach dem physischen Anschalten auf die Fläche für ganz hell (rgb ffffff), hatte ich bei der einen getesteten Milight-Bulb (9W =LEDTYPE RGBW) das Ergebnis, dass die sich zuverlässig paired und unpaired. Als readings habe ich:
hsv 0,0,40 2016-10-10 21:02:45
hue 0 2016-10-10 21:02:45
previousState 0,0,100 2016-10-10 21:02:45
rgb 666666 2016-10-10 21:02:45 Meine weiteren Annahmen und Beobachtungen:
- die Bridge selbst kennt keine Dauer für irgendeinen Klick (anders als die FB), daher läge es nahe, dass die Länge des Sendebefehls kein originäres Kriterium ist (und möglicherweise auch nicht die Zahl der Widerholungen).
- Die FB's schalten bei längerem Druck um vom reinen An/Aus auf "Maximal hell, Modus weiss" (im Normalbetrieb, wenn die Bulb schon länger Spannung hat). Das deckt sich mit der Beobachtung von Karl beim sniffen, dass der Code wechselt.
Wie gesagt, singuläre Beobachtung, inwieweit das zur Theorie (und zur Doku bzw. zu anderen Device-Typen) passt, ist eine andere Sache, und ich habe auch nicht untersucht, wie das das Duo MilightDevice/MilightBridge intern in Kommandos an die Bridge umsetzt.
Ein unpair löst *alle* pairings. Will sagen ein unpair mit fb löst auch gleich alle gepairten bridges..
Wieder was gelernt;
Es gibt die FB's ja in mehreren Fassungen. Ich habe hier welche, die 4xRGB steuern können, also einen Einzel- und Gruppenmodus haben. Ist das nur so, wenn man den "Hauptschalter" oben nimmt, oder auch, wenn man "unten" auf "on" bleibt? (Ich wollte das nicht unbedingt testen, das gibt sonst lange Gesichter
)
Der Aspekt ist nicht so lustig, es gab zwar hier bisher keine ernsthaften Probleme, aber vielleicht sieht jemand eine Möglichkeit, zumindest zu verhindern, dass über FHEM solche Befehle unbeabsichtigt versendet werden...
