Milight via MQTT (war: Modul für Sidoh-Bridge, jetzt: MQTT2)

[TomLee]

Was das Abdimmen vor dem Ausschalten angeht: Das sollte auch via MQTT gehen (in den off-JSON reinbasteln), teste ich bei Gelegenheit mal, dann kommt es in die templates  .

Brauch immer etwas länger  ,bin da gestern Abend nicht drauf gekommen. Gerade ausprobiert, funzt auch. Bei Tageslicht getestet 

Code Auswählen Erweitern

off milight/0x8D56/rgbw/1 {"brightness":"0","status":"OFF"}

[Beta-User]

Danke für's testen!

Jetzt stellt sich die Frage, wie damit umzugehen ist... Ich habe z.B. diese Option noch nie vermisst, weil meine Bulbs alle hinter einem (Hardware-) Schalter hängen, und es ziemlich WAF-förderlich ist, dass die mit dem lezten brightness-Wert (>0) angehen, wenn man sie per Schalter anmacht (und ggf. vorher kurz via Schalter vom Netz nimmt, wenn sie vorher per Funkbefehl aus waren). Ist zwar weder optimal und vermutlich auch nicht die Mehrheit, die das so hat, aber auch nicht völlig exotisch.

Meine Tendenz: neuen setter hinzufügen, der den brightness-0+off-JSON sendet + einen comment, dass man das bei Bedarf ja umbenennen kann und den Ausgangs-off-Befehl löschen?


@hermannj:
Wir können den Fading-Teil gerne hier besprechen oder auch auslagern.
Prinzipiell fände ich es auch ok, wenn WifiLight als "Enddevice" verwendet würde, das macht es uU. etwas einfacher. Allerdings würde ich dann anregen, das ganze ggf. gleich so zu gestalten, dass MQTT2-Devices als 100% oder 255-er brightness gehen UND eine Option da wäre, Hardware direkt anzusprechen, die Zeitoptionen kennt bzw. "hardwareseitig" unterstützt. Ich denke da v.a. die zigbee-Geräte, bei denen ich allerdings nicht weiß, ob die Bulbs das autonom können oder der zigbee2mqtt-Dienst das analog WifiLight steuert.

[Heimweh]

Guten Morgen,

finde es super dass ihr die Sache angehen wollt!!! Ich kann Euch leider nur anbieten beim testen zu helfen....
Ich habe ca. 10 Milights daheim....

Jörg, Du schaltest Deine Bulps stromlos? Hattest Du da noch nie Probleme wegen unbeabsichtigtem an- oder abmelden der Bulp?
Deine "Tendenz" finde ich gut!

[Beta-User]

Hatte ich nicht "irgendwo" (=überall!) darauf hingewiesen, dass MiLight ganz allg. nicht so das Gelbe vom Ei ist ?

Diskussion um das Schalter-Thema z.B. hier: https://forum.fhem.de/index.php/topic,58742.msg502252.html#msg502252

Da ich a) das Problem kenne und b) (jedenfalls bisher) keine Transitions einsetze (und c) den Eindruck habe, dass die Dinger nur einen beschränkten Speicher haben und auch WLAN-Fetzen als Pairing-Befehle mißverstehen können), halten sich die effektiven Probleme mit Fehl-Pairings in Grenzen und sind dann auch schnell wieder korrigiert...

Kurz: Neu kaufen würde ich das Zeug nicht mehr, sondern mein Geld tendenziell auf zigbee (@ConBee-Stick, nicht zigbee2mqtt) "verwetten" (das mag jetzt den einen oder anderen überraschen, weil ich via den attrTemplates beides (milight und zigbee2mqtt) so supporte, dass es ggf. attraktiv erscheint, das zu nutzen. Technisch halte ich das aber für falsch, und für zigbee fände ich es super, wenn wir (u.a. für) die CC253x-e ein zweistufiges Modul zur direkten seriellen Einbindung der zigbee-Welt generieren könnten (vielleicht sogar unter Nutzung von HUEDevice als Client); aber leider ist mein Perl zu schlecht und Kauflösungen (ConBee/RaspBee, HUEBridge ...) scheinbar zu attraktiv/gut supportet...).

Gruß, Beta-User

[Heimweh]

Doch Du hattest es erwähnt... Klar gibt's bessere Systeme - aber Preis / Leistung passt einfach bei den Milights.
Ich habe, seit ich die Bulps immer am Netz lasse auch seit Monaten keine Probleme mehr... Und erst letzte Woche
sind nochmal 2 Controller dazugekommen....

Auf HUE werde ich sicher nicht umsteigen, auch wenn die mega gut sind - der Preis ist in meinen Augen absolut überzogen... Und mit den anderen Systemen habe ich mich
noch nicht beschäftigt...

Danke für Deinen Support!

[herrmannj]

Hatte ich nicht "irgendwo" (=überall!) darauf hingewiesen, dass MiLight ganz allg. nicht so das Gelbe vom Ei ist  ?

ja, ist so Die sind auch bei mir schon mal komplett rausgeflogen, mittlerweile habe ich wieder einige der ganz neuen Generation. Hauptsächlich weil das die einzigen sind für die ich vernünftige Wandschalter finde: siehst du hier . Die Lampen selber hängen an 230V Dauer.

Zu den Transitions: @Beta-user ja so ungefähr würde ich mir das vorstellen.

Eine naive Umsetzung würde einfach die Zeit (bsp 3000ms) durch die Schritte (255?) teilen und dann jeweils per Timer einen Befehl absetzen. Aber: bei vielen Lampen ist der Anstieg der Helligkeit nicht linear, eine Eigenheit des menschlichen Auges. Spricht, bei 0..255 ist halbe Helligkeit nicht bei 127. Das muss man einplanen, auch mathematisch nicht trivial (Beispiel 100..200, nur ein Ausschnitt der Kurve). Wenn man dann noch Farbe, Sättigung und Farbtemp dazu denkt wird das beliebig kompliziert.

Des weiteren: im Beispiel oben (3000ms von 0 ..255) wäre ein Schritte (vereinfacht linear) 11.8ms. Alle 11.8ms einen "Helligkeitsschritt" senden: viele Lampen verkraften diese Menge Nachrichten nicht, der MQTT und auch die Bridge müssen die zeittreu "rausbringen". Dann kommt FHEM selber: nur das ich den nächsten Timer in 11.8ms bestelle bedeutet lange nicht das ich die bekomme. Je nach Umgebung blockieren andere Module. Regelmäßig im ms Bereich, ganz oft aber auch mal 100*X ms. Das muss auch beachtet werden.

Vielleicht sollte man erstmal langsam mit "nur Helligkeit" dimmen anfangen.

Vielleicht wäre es auch hilfreich wenn ich mir so eine bridge schnell mal hinstelle Gibt es da fertige Platinen ?

vg
Joerg

[Beta-User]

(Der "Schalter" ist hübsch, kannte ich noch nicht; das ganze dürfte aber meinem Umfeld zu fummelig sein (teilweise Hauptlicht...), also muß der seitherige Schalter da bleiben... Geht ja alles, für mich kein Problem.)

Platine: hexenmeisters MySensors-ESP-GW geht ohne weiteres afaik (es muß nur ein PIN in der Web-Konfiguration angepaßt werden), ich selbst nutze einen Eigenbau, aber auch mit MySensors-Verkabelung.

Dass das mit der Helligkeit bei den Dingern nicht trivial ist, war mir schon klar (ich habe mir einen HM-Tasten-Dimmer-Code gebastelt, der auch nicht ganz linear arbeitet, sondern "oben raus" größere Schrittweiten hat).

Am besten wäre immer noch, den ESP rechnen zu lassen, also C/C++-Code .

[DasQ]

Jörg, Du schaltest Deine Bulps stromlos? Hattest Du da noch nie Probleme wegen unbeabsichtigtem an- oder abmelden der Bulp?
Deine "Tendenz" finde ich gut!

bin zwar nicht jörg aber, wenn man arg viel hin und her schalten und das von mehreren seiten gleichzeitig (am wandschalter, auf der fernbedinung und in fhem), kann es vorkommen das die blubs ihr paring verliehren. aber dazu brauchts schon viel "gewalt".  (is mir im tagesbetrieb noch nicht vorgekommen)
hab die blubs hinter sonoff_touch und schalte die "gleichzeitig" per doif.

zu dem dimmen würde ich das nicht so komplex machen. zwei parameter, die auf sinnvolle werte beschränkt werden.
schrittweite= die anzahl schritte von 0-100 gemacht werden; z.b. 10.
zeit= die zeit die zwischen einem schritt vergehen soll.
ggf noch ein range= von 0-30 oder von 29 -51 oder oder oder

so "interpoliert" man ein dimmen. kann mir gut vorstellen das bei einer schrittweite von 5, bei einer zeit von 500-800ms, in einem range von 0-100 ein hübschen dimmeffekt erzeugt.

[herrmannj]

ich muss mir das mal in Ruhe anschauen

[cortmen]

Hallo zusammen,

kurze Frage:

Ich nutze einen MQTT2_FHEM_Server (global) - Autocreate(simple on)
Dieser verwaltet einige sonoff Devices

Jetzt möchte ich einige Milight(RGBW) per MQTT2 aufnehmen.

Wo bitte finde ich die ID (oder Name) der Sidoh-Bridge fürs anlegen?
Es ist doch nicht der Hostname  oder?

hier im wiki  Beispiel  - milight_hub_1370325

Code Auswählen Erweitern

defmod MQTT2_milight_hub_1370325 MQTT2_DEVICE milight_hub_1370325

Ich habe im Sidoh-Bridge(D1Mini+NRF24L01)  Webinterface mein pairing mit dem Lampen durchlaufen.
Alle Bulbs lassen sich sauber schalten.

Danke für eine Tipp.

[Beta-User]

Gute Frage; an sich verbirgt sich dahinter schon der Hostname, und die Zahl könnte eine Verbindungsidentifikation sein, weiß ich grade nicht mehr...

Hast du in der Bridge die MQTT-Einstellungen eingetragen? Und z.B. MQTT Client Status Topic auf "milight/LWT" (steht bei mir auf simple  EDIT: "Detail", habe grade auf 1.9.2 aktualisiert)? Dann sollte die Bridge automatisch angelegt werden.

[cortmen]

hi,

im MQTT MiLightHub

MQTT server
192.168.16.88:1884
MQTT topic pattern
milight/:device_id/:device_type/:group_id

MQTT update topic pattern
milight/updates/:hex_device_id/:device_type/:group_id

MQTT state topic pattern
milight/states/:hex_device_id/:device_type/:group_id

Beta-User magst eben Deine Parameter posten?
Danke!

[Beta-User]

...sehen fast so aus, allerdings mit einem hostnamen für den Server und Port 1883.

Welche firmwareversion hast du? (weil du LWT nicht angegeben hattest?)
Frühere Versionen (auch noch die 1.8-er firmware): Da meldet sich der Hub nur, wenn er FB-Signale empfängt oder an der Weboberfläche was geschaltet wird.

EDIT: hex...

[cortmen]

1.9.2

Was muss den genau bei
MQTT state topic pattern stehen?

Ich muss sonst morgen mal das MQTT howto der Sidoh-Bridge Bridge lesen.
Autocreate der Bridge hat schon einmal geklappt.

[DasQ]

Lass das hex bei device_id raus