FHEM Forum

EDIT:
Werde das Modul voraussichtlich nicht weiterentwickeln und stattdessen MQTT2 verwenden.
Hinweise zur Verwendung der Bridge mit MQTT2 (-Server und -Device) sind weiter unten ab hier (https://forum.fhem.de/index.php/topic,86932.msg831918.html#msg831918) zu finden.

Zusammenfassung findet sich hier: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Milight-Bridge (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Milight-Bridge)
Vorab sei nochmals darauf hingewiesen, dass dies keine Werbung für die Milight-Hardware an sich sein soll, sondern lediglich eine Hilfestellung für diejenigen, die derartige Hardware bereits haben... Wer mehr Infos dazu sucht, kann ja rund um diesen Beitrag schmökern:

Zitat von: herrmannj am 11 Oktober 2016, 11:36:18
Ja korrekt. Milight sollte immer am netz sein. Ansonsten ist frust vorprogrammiert

Vg
Joerg

Dazu kommt, dass kein Rückkanal vorhanden ist, man also nie sicher wissen kann, ob ein Sendebefehl auch bei allen Lampen angekommen ist. Selbst werde ich zukünftig eher Richtung Zigbee (HUE, Tradfri u.a.) gehen, wenn ich irgendwann Bulbs ersetzen muß.
/EDIT


Hallo zusammen,

nachdem es so zu sein scheint, dass die MQTT-Schnittstelle der Milight-Bridge von Chris Mullins (https://github.com/sidoh/esp8266_milight_hub) (sidoh) etwas speziell ist, kommt vermutlich eine Integration der Anpassungen für die Zusammensetzung der Sendemessages als JSON nicht wie hier diskutiert (https://forum.fhem.de/index.php/topic,86270.0.html) in Frage.

Anbei daher ein erster Entwurf der Weiterentwicklung des von @lufi erstmals hier vorgestellten (https://forum.fhem.de/index.php/topic,75144.0.html) Milight-MQTT-Moduls.

Neben der sendeseitigen Erstellung der JSON-Kommandos übernimmt das Modul auch direkt das Dekodieren der JSON-Rückmeldungen, man benötigt also nicht extra expandJSON.

Vorteil ggf. der HTTPMOD-Lösung, die hier (https://forum.fhem.de/index.php/topic,84979.0.html) vorgestellt wurde:
Die Rückmeldungen bei Schaltvorgängen über Fernbedienungen oder die Bridge selbst erfolgen direkt und müssen nicht gepollt werden (die Bridge ermöglicht aber auch eine websocket-Uterstützung).
Vorteil der Bridge an sich: Es kann praktisch eine unbegrenzte Anzahl von "Fernbedienungen" definiert werden, so dass Gruppenschaltungsszenarien recht einfach und vielseitig denkbar sind. Es könnte z.B. eine zentrale Fernbedienung definiert werden, über die sich alle bulbs mit einem Befehl an- oder ausschalten lassen, einzelne Stockwerke lassen sich auf einem Kanal zusammenfassen usw.. Allerdings scheint die Zahl der FB's begrenzt zu sein, an die eine bulb angelernt werden kann.

Ansonsten werden eine ganze Reihe von - zu den vorgeschlagenen Grundeinstellungen der Bridge passenden - Attributen gesetzt und es gibt auch ein dynamisches DevStateIcon (das aber leider noch nicht sinnvolle Farben zeigt).

Jedenfalls mit meinen Bulbs und LED-Kontrollern (alles RGBW-Modelle, die ehemals auf V4-Bridges gehört haben) scheint das zu passen, für CCT-Varianten kenne ich die passenden Einstellungen leider nicht, kann das aber gerne bei Bedarf nachpflegen.

Da die Bridge unmittelbar auch Fernbedienungscodes auswertet, kann eine entsprechende FB auch als reines input-Device genutzt werden (meine werden (bislang) leider nicht alle erkannt - die 1-kanaligen funktionieren nicht).

Beispiel für das Anlegen:
define Milightbeispiel MQTT_MILIGHTDEVICE 0xAB12 2 rgbw myMQTT


Danach sollte sich eine Bulb über einen on-Befehl anlernen lassen und dann auch steuern. Wer hat, sollte/kann natürlich auch eine FB benutzen, wobei der Status dann (weitestgehend) passen sollte, auch wenn z.B. die Bulb über die Gruppenfunktion der FB oder der Bridge geschaltet wird.

Es müssen in der Bridge neben der Einrichtung für MQTT allgemein noch teilweise weitere Infos ausgewählt werden, die per JSON jeweils gesendet werden sollen (insbes. level).

Was noch nicht paßt:
- Icon-Farbe (wer weiß, wie man aus den Angaben der Brigde einen verwertbaren RGB-Wert macht: Bitte melden...)
- Status bei Wechseln von/nach Nacht-Modus (über set_white, bislang eine Einschränkung der Firmware, ich hoffe auf einen baldigen update).
- CCT-Geräte (s.o.)

So ganz fertig ist es wie gesagt noch nicht, aber grundsätzlich verwendbar schon (für RGBW-Devices, für die anderen müssen ggf. eigene Anpassungen an den Attributen erfolgen). Konstruktive Beiträge sind bei Interesse willkommen.

EDIT: Anmerkungen zu Milight allgemein
Auch wenn hier eine Option zur besseren Snychronisation des wahren Zustands eines Milight-Leuchtmittels (bulb) angeboten wird, soll erwähnt werden, dass die Milight-Technologie auch Nachteile hat:
- Der Funkverkehr zwischen der Bridge und der bulb ist unverschlüsselt (ähnlich wie z.B. bei IT-Komponenten)
- Es gibt keinen Rückkanal, über den das Leuchtmittel melden könnte, ob ein Befehl auch tatsächlich angekommen ist (ebenfalls wie bei IT)
- Kurz nach dem Einschalten der Spannung befinden sich die bulb kurz im Programmiermodus und wird ggf. an jede Fernbedienung angelernt, die zu diesem Zeitpunkt irgendeinen Befehl sendet. Beispiel: Es könnte ein unbeabsichtigtes Pairing an eine Bridge des Nachbarn erfolgen, der gerade einen Sonnenuntergang simuliert und viele Befehle sendet. Die bulbs sind daher nur sehr bedingt für einen Einsatz hinter Schaltern zu empfehlen.
Eine etwas umfassendere Diskussion hierzu ist um diesen Beitrag hier herum (https://forum.fhem.de/index.php/topic,58742.msg502252.html#msg502252) zu finden.

Gruß, Beta-User

EDIT: Anbei noch eine aktualisierte Version mit den hoffentlich korrekten Angaben für rgb_cct-Geräte.
Weiterer Hinweis: Bitte ggf. darauf achten, dass sendeseitig ein Kondensator für den nRF wichtig ist ;)

EDIT 2: Bitte beachten, dass die Moduldateien nur noch aus historischen Gründen hier angehängt sind. Nutzt man die neue Einbindung via MQTT2_(SERVER|CLIENT)+MQTT2_DEVICE, benötigt man diese nicht! Sie werden auch nicht weiterentwickelt!!!

Hallo Beta-User
finde ich super, daß Du Dir die Arbeit gemacht hast. Funktioniert ausgezeichnet mit der sidoh-Firmware. Der einzige kleine Schönheitsfehler ist die fehlende Unterstützung der RGB-CCT devices. Ich habe versucht in den Attributen etwas "herumzupfuschen", aber leider ohne Erfolg. Du hattest angeboten, das noch einzubringen. Ist das noch aktuell?
Gruß Joachim

Hi Joachim,

Danke für das Interesse, kann ich gerne machen, im Moment habe ich allerdings eine "kleine" andere Baustelle und scheinbar funktioniert das mit dem JSON-Expandieren auch (nicht?) mehr, da muß ich also eh' ran.
Für die CCT-Sache benötige ich aber in jedem Fall Rückmeldung, wie das "eigentlich" aussehen soll. Kannst du mal einen Mitschnitt des Traffics zu einer CCT liefern?
Gruß, Beta-User

Hallo zusammen, nach dem ich bisher immer nur gelesen habe hier mal ein Lösungsvorschlag wie ich das mit cct LED-Streifen gelöst habe. Die cct-LED-Streifen werden bei mir unter RGB+CCT gesteuert. Das MQTT-Modul ist wie folgt eingerichtet:

MQTT topic pattern:
milight/:device_id/:device_type/:group_id

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

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

Das Modul installieren wie beschrieben und ein Device neu anlegen:
define Milightbeispiel MQTT_MILIGHTDEVICE 0x0815 2 rgb_cct myMQTT

neues publish anlegen:
attr Milightbeispiel publishSet_color_temp milight/0x0815/rgb_cct/2

webCmd ändern in:
level:color_temp:command

und widgetOverride ändern in:
command:uzsuSelectRadio,Weiss,Nacht color_temp:colorpicker,CT,153,1,370 level:colorpicker,BRI,0,1,100

Bei mir läuft die Milight Bridge auf dem ESP8266. Bei den subscribeReading_* Kanälen darauf achten das milight/state/... steht und bei update milight/update/... sowohl unter der MQTT-Weboberfläche des Milight-Hub als auch in fhem, dann werden auch die Werte in FHEM aktualisiert.

Danke für die Info bzgl. der richtigen Einstellungen für cct_rgb, baue ich bei Gelegenheit automatisiert ein.

Das mit der fehlenden Auswertung der FB ist bei mir auch so, das hat mal funktioniert... Schaue es mir an, wird aber etwas dauern. Über Zuarbeit an der Stelle würde ich mich sehr freuen, das kann eigentlich nichts größeres sein.

Gruß, Beta-User

Bzgl. des Mitschnitts des Traffics zu einer CCT. Was benötigst Du genau und wie kann ich Dir die Daten liefern?
Gruß Joachim

Vorab erst mal anbei eine Version, die die Attribute auf Basis der Angaben von JackKilby für die cct_rgb-Variante richtig setzen sollte.

Mit "Mitschnitt" meinte ich den Traffic, den Schaltbefehle von der FB für die Bulb auslösen, z.B. von
mosquitto_sub -h <Server-IP> -d -t milight/updates/+/+/+

Aber wie gesagt, der Teil der Auswertung von FB-Signalen funktioniert im Moment bei mir auch nicht (mehr), und ich weiß noch nicht, wann ich dazu komme, das näher anzusehen...

@JackKilby: Bie dir klappt das, oder ist das eine Fehlinterpretation? Wenn ja: Welche Modulversion von MQTT hast du im Einsatz?

Gruß, Beta-User

EDIT: Anhang gelöscht (siehe jetzt 1. Beitrag)

Hallo,
Vielen Dank für die Mühe die du dir gemacht hast.
Leider hab ich irgendeinen Wurm drin, bei meinem mqtt Broker will
Einfach kein json ankommen.

Mach ich irgendwas falsch?

Viele Grüße
Sebastian

P.S. Evtl. hat es was mit dem OS zu tun. Hab ein Raspberry PI 3 mit Stretch und einer Fresh Install von FHEM.
Hab auch das CPAN Modul nachistalliert. Leider aber ohne Erfolg.

Hallo,

kann ich im Moment nicht sagen, und auch für ausgiebige Tests fehlt mir leider grade die Zeit.

Welche der beiden Versionen nutzt du? Ich habe eben die Ausgangsversion aus April getestet und damit ein neues Device angelegt. Das ging, und die Befehle werden auch sauber an den Broker gegeben.

Bei der letzten Fassung wurden auch bei mir die publish- und set-Readings irgendwie verschluckt, da scheint was verbogen zu sein.

Vorschlag: die Alte nutzen und ggf. die Readings anlegen bzw. ändern wie von JackKilby dargestellt, dann sollte es eigentlich gehen. Um den Rest kann ich mich leider erst wieder in einigen Wochen kümmern.

Gruß,

Beta-User

Hallo Beta-User,

Danke für deine Antwort und deinen Test  :D

Ich benutze derzeit die letzte von dir gepostete Version.
Wo kann ich denn die alte finden? Dann teste ich das natürlich aus.

Viele Grüße
Sebastian

Zitat von: RangeMethod am 29 Juli 2018, 22:42:26
Wo kann ich denn die alte finden? Dann teste ich das natürlich aus.

Wie bei solchen Post allg. üblich: im ersten Post des Threads ;) .

Danke ebenso für das Interesse an der Lösung hier...

Du kannst auch die beigefügte Version gerne testen (Dateiname muß dann aber ohne den Zusatz sein), da ist gg. der Ausgangsversion nur das Anlegen der readings ergänzt; ist aber komplett ungetestet, kann auch schiefgehen...

Gruß,

Beta-User

EDIT: Anhang nach update in ersten Post übernommen

Zitat von: RangeMethod am 29 Juli 2018, 17:11:29
P.S. Evtl. hat es was mit dem OS zu tun. Hab ein Raspberry PI 3 mit Stretch und einer Fresh Install von FHEM.
Hab auch das CPAN Modul nachistalliert. Leider aber ohne Erfolg.

Sorry, das sehe ich erst jetzt, die Änderung war nach meiner Antwort.

FHEM und Mosquitto laufen bei mir auch unter einem aktuellen Debian stretch. Wenn das alles "frisch" ist, solltest du sowohl das OS wie auch FHEM erst mal updaten (kommt bei letzterem auch etwas darauf an, wie du es installtiert hattest).

Grundsätzlich muß erst mal die Kommunikation zwischen Broker und der Bridge klappen, da klinke ich mich z.B. vom Laptop aus mit mosquitto_sub ein, um das zu prüfen (FB-Codes oder direkte Bedienung in der Web-Oberfläche des ESP). Dann sollte die Kommunikation zwischen Broker und dem zentralen 00_MQTT.pm-Device erwiesenermaßen klappen, vorher macht es wenig Sinn, nach weiteren Problemen zu suchen.
Dazugibt es im Wiki eigentlich eine ganz ordentliche Einführung.

Nochmal vielen Dank.

Ich hab jetzt dein neues Modul importiert.
Jetzt bekomme ich auch Messages auf meinem Broker. Zur Kontrolle verwende ich MQTT.fx
ich hab auch eine kleine Anpassung am Modul gemacht, da wurde {"state":ON} anstatt {"state":"ON"} geschickt.

War in Zeile 173.

Leider scheint aber mein Milight Hub das jetzt nicht abzugreifen.
Wenn ich allerdings am Hub schalte, gehen die Befehle ebenfalls an den Broker.

Viele Grüße
Sebastian

Das ist schon mal gut, dass da Messages an den Broker gehen, dann müßte das eigentlich auch eine Kleinigkeit sein, dem Hub das vollends beizubiegen.

Was ON vs. "ON" angeht: Ich weiß grade nicht mehr so genau, welche Variante jetzt wirklich richtig war, aber eine hat nicht mit allen Versionen des Hub funktioniert. Da ich das Ausgangsmodul gestern nochmal getestet habe (ohne "") gehe ich davon aus, dass das die richtige Variante ist, die jetzt grade im Code war. Für andere Befehle war das egal - ziemlich irritierend, zumal der Hub das anders zurückmeldet, soweit ich mich erinnere...

Ansonsten bitte nochmal verifizieren, ob die Pfade zusammenpassen, da haben kleine Abweichungen große Effekte.

Also ich hab jetzt mal nochmal meine Konfiguration überprüft und tatsächlich einen Fehler in den Topics auf HUB Seite gefunden.
Es hat am Ende beim TOPIC Pattern das _id nach Group gefehlt, hab nur nicht bis ganz nach rechts gescrollt  :-[ :o

Jetzt funktionieren zumindest die RGBW Geräte ohne Probleme. Bei einem RGB_CCT Device bekomme ich derzeit keinen ColorModus.
Farben einstellen mit Set hue xxx geht, aber nicht via webcmd.

Viele Grüße
Sebastian

P.S. im Modul selbst ist an zwei Stellen noch cct_rgb anstatt rgb_cct eingetragen.
ich denke deswegen funktionierte am Anfang auch das setzen der richtigen attr nicht.
jetzt hat er sie aber so gesetzt wie ein paar Posts drüber geschrieben.

Danke für die Rückmeldung, sorry für den "Dreher" bei rgb_cct.

Habe das jetzt in den ersten Post des threads übernommen, dort dann aber weiter mit {"state":ON}.

Muß ich mir bei Gelegenheit anschauen, was denn jetzt im Ergebnis besser ist...

Hab jetzt meine rbg_cct Streifen mit folgenden attr am laufen:

widget override

command:uzsuSelectRadio,Weiss,Nacht hue:colorpicker,HUE,0,1,359 color_temp:colorpicker,CT,153,1,357 level:colorpicker,BRI,0,1,100

webCmd
level:hue:color_temp:command

Viele Grüße
Sebastian

Danke, habe das als Standard in den Code im ersten Beitrag übernommen :) .

Hallo Beta_User,

Ich hab heute mal ein Toggle getestet, das einschalten funktioniert darüber, das ausschalten leider nicht.
Ist das normalerweise im Modul eingebaut oder per attr zu setzen?

Vielen Dank und Viele Grüße
Sebastian

Soweit mir bekannt, wird toggle im Moment nicht unterstützt (set-extensions wäre aber eine gute Idee...).

Allerdings kann das Icon zum Ein- und Ausschalten genutzt werden (sollte zumindest).

Werde aber wenn, dann erst später mal dazu kommen, das in Angriff zu nehmen, ist völliges Neuland für mich *grins*

Das ist schade, ich wollte es in einem notify verwenden um bei einem klick eines buttons den status zu togglen.
Falls ich doch unterstützen kann sag bescheid.

Viele Grüße
Sebastian

Hallo zusammen,

nachdem ich gestern meine ersten Gehversuche mit den neuen MQTT2-Modulen von Rudi gemacht habe, hier die Vorwarnung:

Ich werde vermutlich die Milights@sidoh-briodge auf MQTT2 umstellen und daher selbst das Modul hier mittelfristig nicht mehr nutzen und daher auch nicht weiterentwickeln.
Zwar ist mir manches im Detail noch unklar, es scheint aber ungleich einfacher, die Konfiguration darüber zu machen.

Motivation:
- Generische Unterstützung, keine externe Serverkomponente (mosquitto uä.) erforderlich => sehr viel einsteigerfreundlicher, jeder der nur wenige MQTT-Komponenten wie z.B. die Bridge hat, kann sofort loslegen und sein FHEM unabhängig von externer Software halten :) . (Das ist keine Kritik an Mosquitto, der läuft wie eine 1; es sind nur sehr viel weniger Schritte, und alle innerhalb FHEM).
- kein Pflegeaufwand für ein eigenes Modul. Da MQTT2 von Rudi kommt, dürfte die langfristige Verfügbarkeit außer Frage stehen, von seiner ungleich größeren Kompetenz beim Lösen evtl. aufretender Probleme will ich garn nicht reden :) . Außerdem dürfte setExtensions schon eingebaut sein ;) .
- autocreate möglich, alle JSON-Readings werden direkt angelegt (ein Punkt, der vermutlich für mich ähnlich viel Aufwand bedeutet hätte wie der Wechsel zu MQTT2)

Erste Feststellungen:
- Alle Readings landen via autocreate in einem "Großdevice", bei MQTT2 scheint erst mal jede IP als eigener Client zu gelten. Das irritiert etwas im Zusammenhang mit einem Gerät wie der Bridge, die eigentlich nur ein IO für mehrere physische Geräte ist.
- Das Aufteilen in mehrere FHEM-Devices scheint aber kein Problem zu sein, man legt einfach für jede Bulb ein weiteres MQTT2_DEVICE an und kopiert den entsprechenden Subset aus dem Großdevice, dann werden - so jedenfalls mein erster Test - beide Geräte aktualisiert, wenn man über die Web-Schnittstelle der Bridge schaltet (für FB's müßte dasselbe gelten).
- Irritiert hat mich, dass da im Device irgendwie noch eine Nummer (der Verbindung?) mit drin ist, deren Herkunft mir nicht so klar ist (und vor allem, ob das Neustarts usw. überlebt...). Hätte erwartet, dass es nur mit einer IP-Angabe gehen sollte. Das dürfte aber klärbar sein.
- Schalten gelang mir noch nicht, da muß ich mich erst eindenken, wie das mit dem Zusammenbauen des JSON gehen soll. Wenn jemand Erfahrung oder eine Idee hat: her damit... (Eigentlich müßte auch das mit Bordmitteln - "{toJSON(??)}" - gehen; das sieht eigentlich auch kaum anders aus als die Sendefunktion im bisherigen Modul).

Ausblick:
Im Prinzip war das "alte" Modul nur eine Hilfestellung zum Anlegen passender Attribute, zum Zusammensetzen des Sendestrings als JSON und (bislang nur rudimentär) ein Hilfsmittel für devStateIcon.
Fazit: Das meiste kann man auch auf anderem Wege haben, wie geschildert sogar (viel?) einfacher als bisher...

Zu gegebener Zeit liefere ich auch gerne meine Erkenntnisse zu den passenden Vorgaben und ggf. Code für myUtils-Routinen für das dynamische Icon; da gibt es aber auch schon einiges in color.pm, ggf. fehlt nur ein passendes userreading für RGB (da liefert nach meinem Eindruck aber die Bridge für meine RGBW-Devices keine brauchbaren Infos...).

Wer in diese Richtung mitdenken/testen will: Willkommen!

Bei Gelegenheit wird es dazu dann einen separaten Thread geben.

Vorab schon mal Danke für euer Verständnis,

Beta-User

Nach etwas rumspielen mal ein kurzer Zwischenstand:

Klappt super mit MQTT2!

Die Raw-Definition einer RGBW-Lampe sieht beispielsweise so aus:
defmod MQTT2_Licht_Essen MQTT2_DEVICE
attr MQTT2_Licht_Essen IODev MQTT2_FHEM_Server
attr MQTT2_Licht_Essen eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/
attr MQTT2_Licht_Essen readingList milight_hub_1370325:milight/states/0xBE59/rgbw/0:.* { json2nameValue($EVENT) }\
milight_hub_1370325:milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT) }
attr MQTT2_Licht_Essen room MQTT2_DEVICE
attr MQTT2_Licht_Essen setList on {"milight/0xBE59/rgbw/1 " . toJSON({ 'status' => 'ON'})}\
off {"milight/0xBE59/rgbw/1 " . toJSON({ 'status' => 'OFF'})}\
level {"milight/0xBE59/rgbw/1 " . toJSON({ "$EVTPART0" => "$EVTPART1"})}\
hue {"milight/0xBE59/rgbw/1 " . toJSON({ "$EVTPART0" => "$EVTPART1"})}\
command {"milight/0xBE59/rgbw/1 " . toJSON({ "$EVTPART0" => "$EVTPART1"})}\
brightness {"milight/0xBE59/rgbw/1 " . toJSON({ "$EVTPART0" => "$EVTPART1"})}\

attr MQTT2_Licht_Essen webCmd level:hue:command
attr MQTT2_Licht_Essen widgetOverride state command:uzsuSelectRadio,Weiss,Nacht hue:colorpicker,HUE,0,1,359 level:colorpicker,BRI,0,1,100

setstate MQTT2_Licht_Essen on
setstate MQTT2_Licht_Essen 2018-09-01 17:02:52 brightness 224
setstate MQTT2_Licht_Essen 2018-09-01 17:02:52 bulb_mode color
setstate MQTT2_Licht_Essen 2018-09-01 17:02:52 color_b 0
setstate MQTT2_Licht_Essen 2018-09-01 17:02:52 color_g 255
setstate MQTT2_Licht_Essen 2018-09-01 17:02:52 color_r 4
setstate MQTT2_Licht_Essen 2018-09-01 17:02:52 hue 119
setstate MQTT2_Licht_Essen 2018-09-01 17:02:52 level 88
setstate MQTT2_Licht_Essen 2018-09-01 17:02:52 state ON


toggle funktioniert, von daher dürften auch die anderen SetExtensions (on-for... etc.) ohne weiteres gehen!

Hammer, und super einfach, hoffe, das Beispiel hilft auch anderen weiter, die im JSON-Format was versenden müssen (toJSON() wird genutzt).

Gibt vermutlich noch Verbesserungsmöglichkeiten, aber für's erste bin ich sehr zufrieden 8) .

Viel Spaß beim Umsetzen und schönes WE!

Beta-User

Coole Sache finde ich. Läuft auch ganz gut.
Aber wie bekommst du das Level ausgelesen? Bei mir bildet sich kein Reading.

Danke für dei Rückmeldung.

Hast du was auf der Bridge konfiguriert oder nutzt du den Standard? Im Web-Interface kann man angeben, was alles gesendet werden soll (braucht man vermutlich auch für RGB). Ich habe da vor längerem schon die entsprechenden Einstellungen gemacht, daher weiß ich im Moment nicht genau, was man alles angeben sollte.

Viel Spaß weiterhin!

(Und wenn jemand die notwendigen Schritte erklärt, um ein noch besseres DevStateIcon hinzubekommen, wäre mir das recht ;) ).

Gruß, Beta-User

Grade frisch MQTT2 aufgesetzt. autocreate ist an. Mehr nicht.
Ah... während des Schreibens noch mal probiert: In den Settings auf dem Milight Hub group_state_fields "Level" anhaken.
Passt. Sehr cool. Besser als den hub mit curl zu steuern.

Zitat von: projectsun am 10 September 2018, 23:25:08
Passt. Sehr cool. Besser als den hub mit curl zu steuern.

Stand nicht irgendwo, dass das echt super-Easy ist, wenn man erst mal weiß, wie man die Kommandos zusammenbaut ;) ?

Das HTTP-Gedöns fand ich im Vergleich auch eher suboptimal, daher der Aufwand mit dem angepaßten Modul. Ist aber klasse, dass es mit MQTT2 "einfach so" funktioniert!

Viel Freude weiterhin!

Zur Ergänzung noch:
Rudi hat freundlich darauf hingewiesen, dass man die Klimmzüge mit toJSON bei MQTT2 nicht benötigt.

Ein entsprechend abgespeckter Code ist daher jetzt hier zu finden: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Milight-Bridge

Hallo a alle, die schon erfolgreich mit dem MQTT2-Modul einen (Sidoh) Milight-Hub zum Lafen bekommen hben. Bei mir hat es initial einmal funktioniert - da hatte autocreate ein MQTT2_DEVICE milight_hub_7931473 angelegt und ich konnte dann für jede Milight-Lampe ein eigenes Device kreieren. Leider musste ich den Milight-Hub nochmal stromlos schalten. Danach konnte ich nur noch Lampen schalten, wenn mindestens eine an war. Ansonsten ging der milight_hub_7931473 immer auf OFF. Daher habe ich alles gelöscht und wollte nochmal von vorn anfangen. Also wieder den MQTT-Server neu definiert, auf autocreate geschaltet, rawEvents an und warten und nichts passiert.
Hier mal die Definition:

define MQTTServer MQTT2_SERVER 1883
attr MQTTServer autocreate 1
attr MQTTServer rawEvents 1
attr MQTTServer verbose 5

Der Port 1883 wird auch bedient:

netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:1883          0.0.0.0:*               LISTEN      15261/perl     


Um MQTT2 nutzen zu können, habe ich vor zwei Tagen FHEM auf die neueste Version geupdated. Ich hatte vorher schon zwei Sonoff-Tasmota-Geräte mit Mosquitto zu laufen wollte jetzt aber auf MQTT2 umsteigen, da es mehr Möglichkeiten einfacher zu realisieren bietet, zumindest, wenn man die Threads und Wikis liest.
Kann jemand von Euch weiterhelfen? Gibt es irgendwas bei den globale Attributen zu beachten?
Gruß Rainhard

Welche firmware-Version der Bridge hast du auf dem ESP?

Ich hatte neulich auch keinen Datenverkehr mehr zur Bridge; ein downgrade auf 1.7.x hat geholfen. Wenn das bei dir auch das Problem sein sollte, wäre ein issue dazu bei Sidoh angesagt...
Komme nur leider selbst grad nicht dazu.

Hab nachgeschaut: Es ist 1.8.3 (nodemcuv2). O.K:, habe jetzt ein Downgrade auf 1.7.1 gemacht, aber bisher keine Veränderung. Auch nachdem der MQTTServer neu angelegt wurde, ändert sich nichts. Es ist als ob gar keine Events empfagen werden. Als es einmal funktionierte, wurde auch vom MQTT2-Server ein weiteres Sub-Device automatisch angelegt, mit der IP-Adresse des Milight-Hubs. Aber jetzt passiert leider garnichts.
Muss erst noch ein MQTT2-Device angelegt werden? Wäre eigentlich unlogisch.
Gruß Rainhard

Wenn der Server auf autocreate steht und der IP-Bereich freigegeben ist, müsste ein MQTT2-DEVICE automatisch angelegt werden.
Mit "list MQTT2.*" kommt nichts ausser dem Server?
Kannst du mit einem Tool wie mosquitto_pub mal checken, ob da irgendwas von der Bridge kommt? (Man kann damit scheinbar jeden Broker "abhören", nicht nur Mosquitto.)

Wenn ich de MQTT2-Server wieder lösche und mosquitto starte, kann ich auch mit mosquitto_sub -d -v -t \# Daten vom MiLight-Hub empfangen:

Client mosqsub/22382-p2 received PUBLISH (d0, q0, r1, m0, 'milight/states/0x1/rgb_cct/1', ... (145 bytes))
milight/states/0x1/rgb_cct/1 {"state":"ON","status":"ON","hue":171,"saturation":100,"bulb_mode":"color","color":{"r":0,"g":255,"b":216},"device_id":1,"device_type":"rgb_cct"}
Client mosqsub/22382-p2 received PUBLISH (d0, q0, r0, m0, 'milight/updates/0x1/rgb_cct/1', ... (11 bytes))
milight/updates/0x1/rgb_cct/1 {"hue":216}
Client mosqsub/22382-p2 received PUBLISH (d0, q0, r0, m0, 'milight/states/0x1/rgb_cct/1', ... (130 bytes))
milight/states/0x1/rgb_cct/1 {"state":"ON","brightness":71,"level":28,"hue":216,"bulb_mode":"color","color":{"r":0,"g":102,"b":255},"device_id":1,"group_id":1}
Client mosqsub/22382-p2 sending PINGREQ
Client mosqsub/22382-p2 received PINGRESP

Es stimmt: Mit "list MQTT.*" kommt nichts außer dem Server.
Was meinst Du mit IP-Bereich freigegeben?

Hmmm, also die Bridge tut erst mal, was sie soll.

MQTT2_SERVER arbeitet mit "allowed" zusammen, der fhem-rechner und die Bridge müssen also im gleichen Subnet sein.

Mosquitto hättest du nicht installieren müssen, nur den Client (der dann auch auf fhem als Server lauschen kann).

Kann es sein, das Mosquitto noch lief und den Port belegt hatte? (Sollte im fhem-log zu sehen sein).

Und wieso hättest du mehrere MQTT2-Server? Das könnte auch das Problem gewesen sein...

FHEM-Rechner und der Milight-Hub sind im selben Netz: 192.168.178.0/24. Ein ping zum Hub vom FHEM funktioniert auch. Mosquitto hatte ich schon früher drauf, hatte ich nicht extra installiert. Den Mosquitto hatte ich vorher gestoppt, weil er ja auf demselben Port wie der MQTT2-Server lauscht. die Ausgabe von netstat -tulpn bezieht sich auf den MQTT2-Server.
Warum früher das autocreate funktioniert hatte und weitere Subs vom MQTT-Server angelegt wurden, weiß ich auch nicht. Jetzt ist jedenfalls der Status, dass nach Anlegen des Servers und dem Einschalten von autocreate nichts mehr weiter passiert.
Hier noch die RAW-Definition:
defmod MQTTServer MQTT2_SERVER 1883
attr MQTTServer autocreate 1
attr MQTTServer rawEvents 1
attr MQTTServer verbose 5

setstate MQTTServer 2018-10-21 21:51:59 nrclients 0

Irgendwas muss falsch sein?!

Sehr seltsam, das....

Die Bridge hast du nach dem Stoppen von Mosquitto neu gestartet?
PW/user ist nicht festgelegt bzw. passt?

Weitere Server werden btw. als temporäre Devices angelegt, wenn sich ein Client verbindet. Scheint ähnlich zu sein wie bei FHEMWEB.

Danke, Du hst mich auf die richtige Idee gebracht: Ich hatte ja die Ausgabe von netstat -tulpn geschrieben und da kann man erkennen, dass der MQTT-Server uber die localhost-Adresse lauscht. Du sagtest ganz richtig, dass der MQTT-Client im selben Netz hängen muss, was ja bedeuten würde, dass er lokal laufen müsste. Wenn man Events von überall bekommen möchte, muss man laut noch den Server global definieren:
define MQTTServer MQTT2_SERVER 1883 global
Jetzt sieht auch die RAW-Defnition anders aus:
defmod MQTTServer MQTT2_SERVER 1883 global
attr MQTTServer autocreate 1
attr MQTTServer rawEvents 1
attr MQTTServer verbose 5

setstate MQTTServer 2018-10-21 22:32:07 RETAIN {"milight/states/0x1/rgb_cct/1":"{\u0022state\u0022:\u0022ON\u0022,\u0022brightness\u0022:71,\u0022level\u0022:28,\u0022hue\u0022:272,\u0022bulb_mode\u0022:\u0022color\u0022,\u0022color\u0022:{\u0022r\u0022:135,\u0022g\u0022:0,\u0022b\u0022:255},\u0022device_id\u0022:1,\u0022group_id\u0022:1}"}
setstate MQTTServer 2018-10-21 22:32:00 nrclients 2

Im Bild kann man dann auch die erzeugten Devices erkennen.
Vielen Dank nochmal für die Unterstützung.
Gruß Rainhard

Danke für die Rückmeldung; das mit global hatte ich nicht mehr auf dem Schirm. Werde ich bei Gelegenheit mal im wiki nachtragen.
Zwei Dinge noch:
Das mit löschen und neu anlegen führt allg. häufiger zu Problemen als zu Lösungen.
Und könntest du mal testen, ob bei dir die aktuelle fw noch läuft (ggf. auch mit Mosquitto, dann einfach den Port am MQTT2-Server ändern).?

ok - werde ich mal testen, aber erst morgen früh. :-)

Guten Morgen, wie versprochen der Test:
Nach dem Update der Firmware auf dem Hub konnten die Lampen im FHEM weiter über den laufenden MQTT2-Server bedient werden. Mit Mosquitto läuft es auch:
root@p2:~# mosquitto_sub  -d -v -t \#
Client mosqsub/27824-p2 sending CONNECT
Client mosqsub/27824-p2 received CONNACK
Client mosqsub/27824-p2 sending SUBSCRIBE (Mid: 1, Topic: #, QoS: 0)
Client mosqsub/27824-p2 received SUBACK
Subscribed (mid: 1): 0
Client mosqsub/27824-p2 received PUBLISH (d0, q0, r1, m0, 'tele/Geschirrspueler/LWT', ... (7 bytes))
tele/Geschirrspueler/LWT offline
Client mosqsub/27824-p2 received PUBLISH (d0, q0, r1, m0, 'milight/states/0x1/rgb_cct/1', ... (130 bytes))
milight/states/0x1/rgb_cct/1 {"state":"ON","status":"ON","brightness":89,"level":35,"hue":124,"bulb_mode":"color","color":{"r":0,"g":255,"b":16},"device_id":1}
Client mosqsub/27824-p2 received PUBLISH (d0, q0, r1, m0, 'milight/states/0x1/rgbw/1', ... (130 bytes))
milight/states/0x1/rgbw/1 {"state":"ON","status":"ON","brightness":51,"level":20,"hue":62,"bulb_mode":"color","color":{"r":246,"g":255,"b":0},"device_id":1}
Client mosqsub/27824-p2 received PUBLISH (d0, q0, r1, m0, 'milight/states/0x364E/rgbw/1', ... (140 bytes))
milight/states/0x364E/rgbw/1 {"state":"ON","status":"ON","hue":18,"bulb_mode":"color","color":{"r":255,"g":76,"b":0},"device_id":13902,"group_id":1,"device_type":"rgbw"}

Wie man hier beim netstat sieht, lauscht mosquitto bereits auf allen Netzen, ist also schon global:
root@p2:~# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:1883            0.0.0.0:*               LISTEN      27592/mosquitto

Ich habe den kompletten MQTT2-Server nach dem Stoppen des Mosqitto neu angelegt und es funktioniert alles wie vorher, insbesondere hat autocreate alles richtig wieder angelegt.
Eine Kleinigkeit stört mich trotzdem noch: Wen ich die Farbe oder die Helligkeit ändere, verschwindet immer das Stae-Icon und es erscheint der Name des gerade bedienten Attributes, also entweder hue oder level oder command. Erste, wenn ich dann nohmal auf den Text klicke, kommt das Lampen-Icon wieder.
defmod Licht_Essen MQTT2_DEVICE
attr Licht_Essen IODev MQTTServer
attr Licht_Essen eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/
attr Licht_Essen readingList MQTT2_milight_hub_7931473:milight/states/0x0004/rgb_cct/4:.* { json2nameValue($EVENT) }
attr Licht_Essen room MQTT2_DEVICE
attr Licht_Essen setList on milight/0x1/rgb_cct/1 { "status" : "ON"}\
off milight/0x1/rgb_cct/1 { "status" : "OFF"}\
level milight/0x1/rgb_cct/1 { "$EVTPART0" : "$EVTPART1"}\
hue milight/0x1/rgb_cct/1 { "$EVTPART0" : "$EVTPART1"}\
command milight/0x1/rgb_cct/1 { "$EVTPART0" : "$EVTPART1"}\
brightness milight/0x/rgb_cct/1 { "$EVTPART0" : "$EVTPART1"}
attr Licht_Essen verbose 5
attr Licht_Essen webCmd level:hue:command
attr Licht_Essen widgetOverride state level:colorpicker,BRI,0,1,100 hue:colorpicker,HUE,0,1,359 command:uzsuSelectRadio,Weiss,Nacht

setstate Licht_Essen hue
setstate Licht_Essen 2018-10-22 07:32:05 state hue

Vielleicht weißt Du noch einen Rat?

SO sollte es aber eigentlich aussehen.

Danke für die Rückmeldung zur fw; bei mir wollte das neulich nicht, und dann hatte ich erst mal keine Gelegenheit für weitere Tests.

Was das icon angeht: hier oder im zigbee-Thread hatte ich code für ein devStateIcon gepostet. Hatte das nur kurz für die milights getestet, funktioniert aber m.E. auch dafür (braucht brightness mit Wert bis 255). (Oder ist das auch schon im wiki?)

Danke für den Tipp. Der passende Code und die Beschreibung sind schon im Wiki zu finden. Das probiere ich bei Gelegenheit mal aus.

erstmal riesen danke für die tips hier im forum,

aber ist das normal das der fader für farbe und helligkeit immer wieder auf 0 zurück springt?

und habt ihr mir nenn tipp für das wigdetOverride für "M" (mode für werkseitig programmierten leuchtmodi) und "S+" "S-" (speed) von der Mi-Light Fernbedienung?

Was die Slider angeht: bist du sicher, dass die Bridge alles via mqtt zurück meldet, was du brauchst? Sollte level und (vermutlich) hue sein.
Was das widget angeht: ich nutze diese Funktionen nicht, aber idR. ist es ausreichend, wenn die Info, die dazu von mqtt bei Nutzung der FB bzw. fer Web-Schnittstelle geliefert wird, auf den entsprechenden Kanal geschriebenen wird. Dann sollte es genügen, das in setList reinzubauen oder das ähnlich wie das mit den Weiss- und Nacht-Modi zu lösen.
Kann das aber leider grad nicht gut selbst testen, wenn Du nicht klarkommst, bitte ggf. nochmal später Nachnamen.

Edit: "autokorrektur" verbessert...

also in den readings vom MQTT2_milight_Hub kommt zumindest das an


2018-10-28 16:20:18 MQTT2_DEVICE MQTT2_milight_hub_10693013 ON
2018-10-28 16:20:18 MQTT2_DEVICE MQTT2_milight_hub_10693013 ON
2018-10-28 16:20:19 MQTT2_DEVICE MQTT2_milight_hub_10693013 OFF
2018-10-28 16:20:19 MQTT2_DEVICE MQTT2_milight_hub_10693013 OFF
2018-10-28 16:20:21 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 243
2018-10-28 16:20:21 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 254
2018-10-28 16:20:21 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 3
2018-10-28 16:20:21 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 59
2018-10-28 16:20:21 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 79
2018-10-28 16:20:21 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 93
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 138
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 184
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 226
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 250
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 267
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 275
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 289
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 306
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 322
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 0
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 21
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 110
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 131
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 148
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 169
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 185
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 200
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 251
2018-10-28 16:20:22 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 257
2018-10-28 16:20:23 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 306
2018-10-28 16:20:23 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 322
2018-10-28 16:20:23 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 23
2018-10-28 16:20:23 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 40
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 153
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 153
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 346
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 270
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 231
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 199
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 153
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 153
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 168
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 194
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 227
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 264
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 366
2018-10-28 16:20:24 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 153
2018-10-28 16:20:25 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 6
2018-10-28 16:20:25 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 10
2018-10-28 16:20:25 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 49
2018-10-28 16:20:25 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 100
2018-10-28 16:20:25 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 100
2018-10-28 16:20:25 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 54
2018-10-28 16:20:25 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 17
2018-10-28 16:20:25 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 0
2018-10-28 16:20:25 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 0
2018-10-28 16:20:26 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 255
2018-10-28 16:20:26 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 230
2018-10-28 16:20:26 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 20
2018-10-28 16:20:26 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 0
2018-10-28 16:20:26 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 0
2018-10-28 16:20:26 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 115
2018-10-28 16:20:26 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 209
2018-10-28 16:20:26 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 255
2018-10-28 16:20:27 MQTT2_DEVICE MQTT2_milight_hub_10693013 command: mode_speed_up
2018-10-28 16:20:28 MQTT2_DEVICE MQTT2_milight_hub_10693013 mode: 0
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 ON
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 217
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 bulb_mode: white
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 status: ON
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_b: 255
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_g: 255
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 level: 85
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 ON
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_r: 255
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 kelvin: 0
2018-10-28 16:20:30 MQTT2_DEVICE MQTT2_milight_hub_10693013 color_temp: 153
2018-10-28 16:20:32 MQTT2_DEVICE MQTT2_milight_hub_10693013 ON
2018-10-28 16:20:32 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 51
2018-10-28 16:20:32 MQTT2_DEVICE MQTT2_milight_hub_10693013 bulb_mode: color
2018-10-28 16:20:32 MQTT2_DEVICE MQTT2_milight_hub_10693013 ON
2018-10-28 16:20:32 MQTT2_DEVICE MQTT2_milight_hub_10693013 status: ON
2018-10-28 16:20:32 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 78
2018-10-28 16:20:32 MQTT2_DEVICE MQTT2_milight_hub_10693013 level: 20
2018-10-28 16:20:32 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 292
2018-10-28 16:20:33 MQTT2_DEVICE MQTT2_milight_hub_10693013 OFF
2018-10-28 16:20:33 MQTT2_DEVICE MQTT2_milight_hub_10693013 level: 20
2018-10-28 16:20:33 MQTT2_DEVICE MQTT2_milight_hub_10693013 saturation: 78
2018-10-28 16:20:33 MQTT2_DEVICE MQTT2_milight_hub_10693013 hue: 292
2018-10-28 16:20:33 MQTT2_DEVICE MQTT2_milight_hub_10693013 status: OFF
2018-10-28 16:20:33 MQTT2_DEVICE MQTT2_milight_hub_10693013 OFF
2018-10-28 16:20:33 MQTT2_DEVICE MQTT2_milight_hub_10693013 bulb_mode: color
2018-10-28 16:20:33 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 51
2018-10-28 16:20:54 MQTT2_DEVICE Licht_Wz_Deck level
2018-10-28 16:20:55 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 252
2018-10-28 16:20:55 MQTT2_SERVER MQTT2_Broker milight/update/0x5D02/rgb_cct/1:{"brightness":252}
2018-10-28 16:20:56 MQTT2_DEVICE Licht_Wz_Deck level
2018-10-28 16:20:56 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 252
2018-10-28 16:20:56 MQTT2_SERVER MQTT2_Broker milight/update/0x5D02/rgb_cct/1:{"brightness":252}
2018-10-28 16:20:57 MQTT2_DEVICE Licht_Wz_Deck level
2018-10-28 16:20:57 MQTT2_DEVICE MQTT2_milight_hub_10693013 brightness: 255
2018-10-28 16:20:57 MQTT2_SERVER MQTT2_Broker milight/update/0x5D02/rgb_cct/1:{"brightness":255}

Dann ergänze mal command mit mode_speed_up bzw. ...down ;) .

Hallo,
dieser thread hat mich veranlasst meine auch schon eingemottete Milight Bulb mal wieder auszupacken. Eine Sidoh Bridge war schnell zusammengesteckt und geflashtund siehe da: über die Weboberfläche lasst sich die Lampe auch wundervoll mit folgenden Einstellungen steuern:
Device Id:0x7FB3, Remote Type: RGBW Group:1. Im zweiten Step sollte das ganze über das MQTT2 Modul auch in FHEM. Mqtt Einstellungen in der Bridge gemacht. MQTT topic pattern:milight/command/0x7FB3/rgbw/1. MQTT update topic pattern:milight/updates/0x7FB3/rgbw/1. MQTT state topic pattern:milight/states/0x7FB3/rgbw/1 und da ich nur eine Lampe habe, direkt nach dem automatischen Anlegen eines Mqtt devices (milight_hub_15591310) die von mir angepassten Attribute eingetragen. Siehe da die Zustände der Lampe wurden, wenn vom Webinterface gesteuert wurde alle korrekt dargestellt. Leider kann ich die Lampe aus FHEM heraus nicht steuern. Ich habe mich auf die Suche nach etwaigen Fehlern in der Definition gemacht (Rechtschreibung,Syntax etc), es auch mit anderen Topic Bezeichnungen versucht, alles ohne Erfolg
Hier mal ein List des Gerätes:
Internals:
   CFGFN     
   CID        milight_hub_15591310
   DEF        milight_hub_15591310
   DEVICETOPIC MQTT2_milight_hub_15591310
   IODev      mq
   LASTInputDev mq
   MSGCNT     52
   NAME       MQTT2_milight_hub_15591310
   NR         24344
   STATE      off
   TYPE       MQTT2_DEVICE
   mq_MSGCNT  52
   mq_TIME    2018-10-28 17:10:25
   READINGS:
     2018-10-28 17:10:04   brightness      255
     2018-10-28 17:10:04   bulb_mode       white
     2018-10-28 17:10:04   color_b         255
     2018-10-28 17:10:04   color_g         255
     2018-10-28 17:10:04   color_r         255
     2018-10-28 17:10:04   command         set_white
     2018-10-28 17:10:04   device_id       32691
     2018-10-28 17:10:04   effect          white_mode
     2018-10-28 17:09:33   hue             192
     2018-10-28 17:10:04   level           100
     2018-10-28 17:10:25   state           OFF
     2018-10-28 17:10:04   status          ON
Attributes:
   IODev      mq
   eventMap   /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/
   readingList milight_hub_15591310:milight/updates/0x7FB3/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_15591310:milight/states/0x7FB3/rgbw/1:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    on milight/command/0x7FB3/rgbw/1 { "status" : "ON"}\
off milight/command/0x7FB3/rgbw/1 { "status" : "OFF"}\
level milight/command/0x7FB3/rgbw/1 { "$EVTPART0" : "$EVTPART1"}\
hue milight/command/0x7FB3/rgbw/1 { "$EVTPART0" : "$EVTPART1"}\
command milight/command/0x7FB3/rgbw/1 { "$EVTPART0" : "$EVTPART1"}\
brightness milight/command/0x7FB3/rgbw/1 { "$EVTPART0" : "$EVTPART1"}
   webCmd     level:hue:command
   widgetOverride state level:colorpicker,BRI,0,1,100 hue:colorpicker,HUE,0,1,359 command:uzsuSelectRadio,Weiss,Nacht
kann mir jemand einen Denkanstoss geben oder bin ich sonst irgendwie blid und habe Einstellungen vergessen?
Danke im Voraus
Thomas

Wenn du die einzelne Birne mit copy erstellt hast, versuche es mal mit reload des device-moduls oder fhem neu starten.

Fhem neugestartet, Raspi neugestartet, keine Veränderung. Das device wurde nachdem ich die Sidoh bridge eingerichtet, neugestartet und über die Weboberfläche bedient hatte, neu eingerichtet, da ich nur diese eine Lampe habe, habe ich einfach über die Raw definitions die fehlenden Atribute angepasst und angelegt. Ich hatte gedacht mich so ein bischen in Mqtt einzuarbeiten.
Gruß Thomas

kann es sein das du hub und device durcheinander gebracht hast?

bei mir schaut der hub so aus Internals:
   CID        milight_hub_10693013
   DEF        milight_hub_10693013
   DEVICETOPIC MQTT2_milight_hub_10693013
   IODev      MQTT2_Broker
   NAME       MQTT2_milight_hub_10693013
   NR         339
   STATE      ON
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-10-28 20:11:42   brightness      255
     2018-10-28 20:11:24   bulb_mode       color
     2018-10-28 20:11:17   color_b         255
     2018-10-28 20:11:17   color_g         255
     2018-10-28 20:11:17   color_r         255
     2018-10-28 20:11:38   color_temp      314
     2018-10-28 20:11:08   command         night_mode
     2018-10-28 20:11:08   device_id       23810
     2018-10-28 20:11:08   effect          night_mode
     2018-10-28 20:11:45   hue             112
     2018-10-28 20:11:17   kelvin          42
     2018-10-28 20:11:24   level           39
     2018-10-28 20:06:49   mode            0
     2018-10-28 20:11:24   saturation      24
     2018-10-28 20:11:34   state           ON
     2018-10-28 20:11:24   status          ON
Attributes:
   IODev      MQTT2_Broker
   readingList milight_hub_10693013:milight/update/0x248C/0x248C/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x248C/0x248C/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x248C/0x248C/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x248C/0x248C/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x248C/0x248C/rgbw/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x248C/0x248C/rgbw/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x248C/0x248C/rgbw/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x5D02/0x5D02/rgb_cct/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x5D02/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x5D02/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x5D02/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x5D02/0x5D02/rgb_cct/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x5D02/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x5D02/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x5D02/rgb_cct/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x5D02/rgb_cct/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x248C/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x248C/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x248C/rgb_cct/0:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x5D02/rgb_cct/4:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x5D02/rgb_cct/4:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x248C/rgb_cct/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x248C/rgb_cct/2:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/update/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }
milight_hub_10693013:milight/state/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }
   room       Wohnzimmer
   verbose    5


und die lampen (device) so

Internals:
   DEVICETOPIC Licht_Wz_Deck
   IODev      MQTT2_Broker
   IODevName  MQTT2_FHEM_Server
   NAME       Licht_Wz_Deck
   NR         345
   STATE      saturation
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-10-28 20:11:24   state           saturation
Attributes:
   IODev      MQTT2_FHEM_Server
   eventMap   /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/Mode:mode/UP:mode_speed_up/Down:mode_speed_down/
   icon       light_control
   readingList milight_hub_1370325:milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
milight_hub_1370325:milight/states/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT) }
   room       Wohnzimmer
   setList    on milight/0x5D02/rgb_cct/1 {"status":"ON"}
off milight/0x5D02/rgb_cct/1 {"status":"OFF"}
level:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
command milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
brightness milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
mode milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
mode_speed_up milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
mode_speed_down milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
saturation milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
   webCmd     command:hue
   widgetOverride command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down hue:colorpicker,HSV,hue,0,1,360,saturation,0,1,100,brightness,0,1,100

Hmmmm, bei nur einer bulb sollte es möglich sein, mit nur einem MQTT2_DEVICE-Gerät auszukommen.
Welche fw-Version läuft auf dem Hub? Ich hatte schon mal Probleme mit den 1.8.x-Versionen, da kam aber via mqtt in beide Richtungen nichts an. Ggf. mal 1.7 versuchen?

@DasQ:
Schön, dass das mit den Modes so geklappt hat!
Vorschlag noch: das könnte aus Command raus in ein eigenes select-Element (Vorschlag: Mode, Auswahl mode, up, down). Dazu müsste dann hinten in dem json-blob statt $EVTPART0 command hart drin stehen und wie bei weiß eine Übersetzung in die Langfassung vorgenommen werden.
Hoffe, das ist halbwegs verständlich...?

Ok, dann werde ich morgen mal versuchen eine 1.7x Version zu flashen und evtl. Bridge und device zu trennen. Das device  muss ich dann von Hand anlegen und die entsprechenden Attribute von der Bridge rüberkopieren, oder?

Ja; statt copy am einfachsten die raw-Definition des "Bridge"-Devices bearbeiten und dann als raw-Import ausführen.

Ok  danke, melde mich dann morgen.
Schönen Sonntag noch

@Beta-User zu dem Zeitpunkt von dem posting von vorhin wollte es noch nicht so,
aber jetzt.  ;) thx für deine Hilfe. Ich dachte mir schon, wie bist du auf das night_mode gekommen. Das taucht zwar beim zappen mit der Fernbedienung im FHEM mqtt2 log auf, aber das was ich suchte .... leider nicht.
Schluss letztendlich wars banal, bin durch Zufall auf die ,,Bulb commands" im https://github.com/sidoh/esp8266_milight_hub gestoßen. Und da wars dann
next_mode. Cycles to the next "disco mode".
previous_mode. Cycles to the previous disco mode.
Jetzt sollte es Möglich sein die komplette Fernbedienung nachzubauen, und wenn ich, ach ne ich werd im Laufe der nächsten Woche das komplette Template bereitstellen.
Internals:
   DEVICETOPIC Licht_Wz_Deck
   IODev      MQTT2_Broker
   IODevName  MQTT2_FHEM_Server
   NAME       Licht_Wz_Deck
   NR         345
   STATE      saturation
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-10-28 21:28:17   state           saturation
Attributes:
   IODev      MQTT2_FHEM_Server
   eventMap   /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
   icon       light_control
   readingList milight_hub_1370325:milight/update/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
milight_hub_1370325:milight/state/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT) }
   room       Wohnzimmer
   setList    on milight/0x5D02/rgb_cct/1 {"status":"ON"}
off milight/0x5D02/rgb_cct/1 {"status":"OFF"}
level:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
command milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
brightness milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
mode milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
mode_speed_up milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
mode_speed_down milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
saturation milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
   webCmd     command:hue
   widgetOverride command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down hue:colorpicker,HSV,hue,0,1,360,saturation,0,1,100,brightness,0,1,100


Und ach ja, das mit der faderstellung hab ich noch nicht rausgefunden, das ging mal, und dann plötzlich nimmer. Aber ich schraub da auch Zuviel rum. Vermutlich stimmt das vom esp kommende noch nicht richtig mit den readings

btw. Das FHEM Wiki ist streckenweise recht kryptisch geschrieben oder ich denk zu achteckig.

Danke für die Rückmeldung zum Disko-Mode, scheint so, als kämst du mit meinen kryptischen Infos soweit klar *grins*. Du darfst das gerne lesbarer oder einfacher nachvollziehbar schreiben bzw. Vorschläge machen, das ist tatsächlich erst mal ein auf die Schnelle entstandener write-up, bei dem ich auch noch nicht wußte, ob's über haupt jemanden interessiert...

Feel free!

Immer noch nicht zu 100% so wie ich es will, aber zur zeit wegen echtem männerschnupfen lahmgelegt

jetzt tun die schiebe regler das was sie sollen und auch simultan.

defmod Licht_Wz_all MQTT2_DEVICE
attr Licht_Wz_all IODev MQTT2_Broker
attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
attr Licht_Wz_all group Licht
attr Licht_Wz_all icon light_control
attr Licht_Wz_all readingList milight_hub_10693013:milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\

attr Licht_Wz_all room licht,Wohnzimmer
attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
level:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
command milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
brightness milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}
attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue
attr Licht_Wz_all webCmdLabel command\
:brightness:saturation\
:color_temp:hue
attr Licht_Wz_all widgetOverride command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down hue:colorpicker,HUE,0,1,359 color_temp:colorpicker,CT,153,1,357 brightness:colorpicker,BRI,0,1,100 saturation:colorpicker,BRI,0,1,100

setstate Licht_Wz_all brightness
setstate Licht_Wz_all 2018-11-08 20:34:51 brightness 15
setstate Licht_Wz_all 2018-11-08 20:32:56 color_temp 357
setstate Licht_Wz_all 2018-11-08 20:26:58 command night_mode
setstate Licht_Wz_all 2018-11-08 20:31:34 hue 172
setstate Licht_Wz_all 2018-11-08 20:26:38 mode 4
setstate Licht_Wz_all 2018-11-08 20:33:12 saturation 0
setstate Licht_Wz_all 2018-11-08 20:34:51 state brightness



Hallo auch von mir, wenn auch (leicht) verspätet :-[ die Rückmeldung, (siehe Antworten 48 - 54) das nun alles korrekt funktioniert. Das Problem saß , wie in 90% aller Fälle vor dem Computer ;). Man sollte schon in der Lage sein korrekt (die MQTT Topics) abzuschreiben und nicht irgendetwas hinein zu interpretieren was gar nicht da ist.
Nachdem ich die Topics einfach 1:1 aus dem Wiki der Sidoh-Bridge übernommen habe ging plötzlich alles.
Danke für eure Unterstützung

Danke für eure positiven Rückmeldungen.
@DasQ: warum die Titelangabenm? Die Spider sind doch eigentlich selbsterklärend...
Und auf widgetoverride kann man verzichten, wenn man es gleich in die setList packt.
Wenn du das noch optimieren könntest, würde ich es dann gerne ins wiki über nehmen, ist sicher hilfreich für die, die "das volle Programm" haben wollen ;) .

Thx für den tip ;) kommt umgehend auf die ToDo

Ich kämpf noch immer mehr mit mir selbst ... bin halt ein haptischer Mensch und muss meine Fehler hart begreifen  ::)

Im augenblick geht's mir mehr darum, zu begreifen warum ich an der fhem.cfg nicht editieren soll/darf.
Da zerhagelts mir regelmäßig die Funktionalität der slider oder gar mehr.

Und ich Fummel doch so gern an Text Dateien mit meim sublime. Bin am überlegen das ganze in ne Datenbank auszulagern, gesetzt den Fall die reagiert nicht so sensibel für die die textdatei.

Cfg-Editieren ist halt schlicht unnötig... Macht tendenziell nur Ärger und verhindert eine Syntax Prüfung, die man mit raw-Definitionen gratis bekommt. (Siehe Import von code sniplets im Wiki, da kann man dann Kate oder notepad++ nehmen, editieren und dann "alles auf einen Rutsch" machen.)

ConfigDB hat zusätzlich den Vorteil, dass man eine Versionierung gratis dazu bekommt. Man muss halt u.U. "anders suchen" - list statt Ctrl+f....
Dann warte ich mal, was kommt.

Sch... Autokorrektur am Handy!

Hab das alles mal ausprobiert... Funktioniert super!

Kann mir jemand sagen wie ich jetzt "von Hand" einen Befehl absetzen kann? Also wie ein "SET" Commando?

Edit: Ich meine nicht nur an und aus, sondern wie geht ein Befehl um z.B. Parameter wie Helligkeit usw. zu steuern?


Es dreht sich um folgendes Gerät:


Internals:
   DEVICETOPIC Spiegel
   IODev      MQTTServer
   LASTInputDev MQTTServer
   MQTTServer_MSGCNT 466
   MQTTServer_TIME 2018-11-17 23:35:14
   MSGCNT     466
   NAME       Spiegel
   NR         1580
   STATE      on
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-11-17 23:35:14   brightness      71
     2018-11-17 23:35:14   bulb_mode       white
     2018-11-17 23:35:14   color_b         255
     2018-11-17 23:35:14   color_g         255
     2018-11-17 23:35:14   color_r         255
     2018-11-17 23:35:14   color_temp      357
     2018-11-17 23:32:14   command         night_mode
     2018-11-17 23:29:31   device_id       12886
     2018-11-17 23:35:14   effect          white_mode
     2018-11-17 23:26:39   group_id        2
     2018-11-17 23:32:39   hue             270
     2018-11-17 23:35:14   level           28
     2018-11-17 23:28:12   mode            6
     2018-11-17 23:32:39   saturation      0
     2018-11-17 23:35:14   state           ON
     2018-11-17 23:35:14   status          ON
Attributes:
   IODev      MQTTServer
   eventMap   /on:on/off:off/ON:on/OFF:off/
   icon       light_control
   readingList milight_hub_317564:milight/0x3256/rgb_cct/2:.* { json2nameValue($EVENT) }
milight_hub_317564:milight/states/0x3256/rgb_cct/2:.* { json2nameValue($EVENT) }
milight_hub_317564:milight/states/0x3256/rgb_cct/2:.* { json2nameValue($EVENT) }
   room       MQTT
   setList    on milight/0x3256/rgb_cct/2 {"status":"ON"}\\
off milight/0x3256/rgb_cct/2 {"status":"OFF"}\\
level:colorpicker,BRI,0,1,100 milight/0x3256/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}\\
hue:colorpicker,HUE,0,1,359 milight/0x3256/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}\\
command milight/0x3256/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}\\
brightness milight/0x3256/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}\\
next_mode milight/0x3256/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}\\
mode_speed_up milight/0x3256/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}\\
mode_speed_down milight/0x3256/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}\\
saturation milight/0x3256/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}\\
color_temp milight/0x3256/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}
   verbose    5
   webCmd     command:brightness:saturation:color_temp
   webCmdLabel command:brightness:saturation:color_temp
   widgetOverride command:uzsuSelectRadio hue:colorpicker,HUE,0,1,359 color_temp:colorpicker,CT,153,1,357 brightness:colorpicker,BRI,0,1,255 saturation:colorpicker,BRI,0,1,100


Zitat von: Beta-User am 09 November 2018, 18:55:48
Danke für eure positiven Rückmeldungen.
@DasQ: warum die Titelangabenm?

Weil ich anders die 4 slider (noch) nicht sortiert bekomm. Bzw die Zeilenumbrüche so nutz. Aber du hast schon recht, igentlich doppelt gemoppelt.
Und den slider für die Farbsättigung hab ich eigentlich zweckentfremdet. Aber dafür hab ich schon einen Lösungsansatz im Wiki gefunden. Den aslider.

Ich Tanz gerade auf zuvielen Hochzeiten gleichzeitig. Gestern hab ich config und log auf mariaDB umgestellt. Zeitgleich Versuch ich den zahlreichen Bugs des ESPEasy für den ESP32 auf die Schliche zu kommen ... aber das ist nenn eigenes Ding mit nem Riesen bugreport.

Anbei mein aktuelles RAW Schnipsel. Ohne override

defmod Licht_Wz_all MQTT2_DEVICE
attr Licht_Wz_all IODev MQTT2_Broker
attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
attr Licht_Wz_all group Licht
attr Licht_Wz_all icon light_control
attr Licht_Wz_all readingList milight_hub_10693013:milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\

attr Licht_Wz_all room Wohnzimmer
attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
level milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
device_id milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
effect milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
commands milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}
attr Licht_Wz_all sortby 1
attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue
attr Licht_Wz_all webCmdLabel command\
:brightness:saturation\
:color_temp:hue


@DasQ: Danke für den Code, habe das jetzt mal so ins wiki gepackt. Könntest du noch einen Screenshot liefern?
Das muß jetzt noch mit Beispielen für "bridgeRegexp" versehen werden, aber dazu brauche ich auch etwas mehr Zeit - auch zu viele Hochzeiten... Feedback oder Mithilfe: gerne gesehen...



@Heimweh: Kannst du mal erläutern, um was es genau geht? Z.B.
set Spiegel level 33 müßte direkt in der Eingabezeile funktionieren.

Zitat@Heimweh: Kannst du mal erläutern, um was es genau geht? Z.B.

Code Auswählen Erweitern

set Spiegel level 33 müßte direkt in der Eingabezeile funktionieren.

Hallo Beta-User,

das hat geklappt. Danke. Ja genau darum ging es. Ich versuche gerade, dass mit Alexa zu vertütteln.
Also ich möchte mit "Alexa schalte den Spiegel auf 50%" die Helligkeit (set brightness 128) steuern, oder 100% (brightness 255). Habe
schon mit Lichtszenen gespielt, allerdings sind dann da die Werte fix.

Dazu kommt wenn ich sage "Spiegel aus", dann lässt sie sich nicht über einen neuen Helligkeitswert hochziehen sondern benötigt vorher wieder ein "Spiegel an"

Hat da schon jemand Erfahrung? Im Moment sagt Alexa das Gerät würde nicht unterstützt....

nochmals ein paar kleine änderungen und bereinigungen
:o is aber immer noch nicht so wie ich das eigentlich haben will. aber zuerst gehts mal ums verstehen und dann um`s hübsch

defmod Licht_Wz_all MQTT2_DEVICE
attr Licht_Wz_all IODev MQTT2_Broker
attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
attr Licht_Wz_all group Licht
attr Licht_Wz_all icon light_control
attr Licht_Wz_all readingList milight_hub_10693013:milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\

attr Licht_Wz_all room Wohnzimmer
attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode:select,0,1,2,3,4,5,6,7,8 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\

attr Licht_Wz_all sortby 1
attr Licht_Wz_all webCmd command:mode:brightness:saturation:color_temp:hue
attr Licht_Wz_all webCmdLabel command:mode\
:brightness:saturation\
:color_temp:hue

setstate Licht_Wz_all off
setstate Licht_Wz_all 2018-11-18 21:08:24 brightness 255
setstate Licht_Wz_all 2018-11-18 21:21:44 color_temp 314
setstate Licht_Wz_all 2018-11-18 21:20:51 command night_mode
setstate Licht_Wz_all 2018-11-18 21:11:13 hue 313
setstate Licht_Wz_all 2018-11-18 21:08:28 mode 4
setstate Licht_Wz_all 2018-11-18 21:11:13 saturation 85
setstate Licht_Wz_all 2018-11-18 22:44:49 state OFF



Zitat von: Heimweh am 19 November 2018, 09:25:11
Hat da schon jemand Erfahrung? Im Moment sagt Alexa das Gerät würde nicht unterstützt....

Na ja, ich würde annehmen, dass das geht, jedenfalls wenn man dann ausdrücklich eine "on" zur brightness in den json packt.Siehe zigbee-Beispiel im Wiki (muß ggf. geringfügig angepaßt werden):brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/Kueche_Durchgang_A2/set {"state":"on","$EVTPART0":"$EVTPART1"}

Zitat von: Beta-User am 19 November 2018, 11:44:22
Na ja, ich würde annehmen, dass das geht, jedenfalls wenn man dann ausdrücklich eine "on" zur brightness in den json packt.Siehe zigbee-Beispiel im Wiki (muß ggf. geringfügig angepaßt werden):

Code Auswählen Erweitern

brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/Kueche_Durchgang_A2/set {"state":"on","$EVTPART0":"$EVTPART1"}

Ok das muss ich testen. Jetzt habe ich es mal soweit das Alexa nicht mehr meckert wenn ich "Schalte Spiegel auf 50%" sage. Sie sagt ok,
aber es tut sich nichts. Denke mal es liegt am homebridgemapping, das habe ich noch nicht ganz verstanden. So sieht es derzeit aus:


homebridgeMapping Brightness=Spiegel:brightness


Habe einen Beitrag gefunden wo von einem pct reading und ein Kommando die Rede ist... Leider steck ich noch nicht so tief
drin in der Materie....

So, nachdem ich die letzte Zeit etwas mit den neuen template-Funktionalitäten rumgespielt habe, anbei ein "erster Wurf" zu dem Thema im Milight-Kontext.

Wäre schön, wenn die Mutigen unter Euch da mittesten (und vor allem verbessern) würden!

- Datei nach ...FHEM/lib/AttrTemplate kopieren (Rechte richtig setzen)
- { AttrTemplate_Initialize() } ausführen

Für Mutige: Das bridge-Template über das heutige Bridge-Device anwenden.
Für weniger Mutige: bei aktiviertem Autocreate am Server-Device irgendeine Phantasie-Lampe über das Webinterfache des ESP schalten, das dann angelegte Gerät mit dem bridge-template konfigurieren.

Danach sollten alle Schaltvorgänge mit einer bisher unbekannten ID zu einem neuen Gerät führen, leider nur zu einem für alle 5 Endnummern. Im Moment gehe ich davon aus, dass  es das einfachste wäre, das template für dieses erste Gerät dann so zu bauen, dass man erst eine Art Basisstruktur bekommt (5 Geräte), und auf die dann wieder jeweils das passende weitere Einzeltemplate anwendet.

Wunsch wäre, getestete Rückmeldungen zu bekommen von allen Varianten. Wer eigene templates anlegen will, einfach die Datei editieren und nach der Änderung dann wieder "{ AttrTemplate_Initialize() }" ausführen. Geht nur beim Bridge-Gerät nicht sooo gut, da die readingList gelöscht wird und daher nicht mehr ausgewertet werden kann.

Als Bulb steht im Moment nur die rgbw-Variante drin, wobei tendenziell mehr Anzeige- und Steuerungselemente drin sind wie man eigentlich braucht. Motto: löschen, was nicht gewünscht/benötigt wird ist für den normalen User einfacher, als was dazu zu machen...

Im Ergebnis kann das dann gerne Eingang finden in das allgemeine mqtt2.template.

Wie gesagt: Feedback ist willkommen, das läuft auch nach meinem Eindruck noch nicht in allen Belangen ganz rund...

Viel Freude damit,

Beta-User

EDIT: template entfernt (=>svn)

Hallo,

ich versuche schon seit einiger Zeit ein Homebridge mapping für meine Lampen hinzubekommen.
Vielleicht kann mir ja jemand einen Tipp geben. 
Es funktioniert leider nur an/aus und der Farbwechsel über HomeKit .
Ich habe MiLight RGBW, RGB-CCT und CCT Bulbs und Stripes im Einsatz.
In FHEM funktioniert soweit alles.
Hat es von euch jemand erfolgreich geschafft, die Lampen über HomeKit zu steuern

Gr. Ollo

@all:

Habe die templates eben mit dem Zusatz "experimental" für alle ins svn geschoben. Feedback dazu (betr. den MiLight-Teil) gerne in diesem Thread.

Gruß, Beta-User

@Ollo65:
Wenn sich hier niemand findet, der das beantworten kann: schau mal in den wifilight-Thread, vielleicht gibt's da was.

Kurzer update noch:

Mindestens die templates für die Bridge und RGBW-Devices sind jetzt funktional im svn enthalten (und damit ab morgen per update verteilt).

Anwendung ist hier beschrieben: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Milight-Bridge

Die "max-featured-Bulb" in den templates (X_01x_esp_milight_hub_max_features_bulb) ist nicht weiter auf Funktionalität getestet.

Feedback ist wie immer willkommen, gerne nehme ich template-Vorschläge für andere Leuchtmitteltypen oder Erweiterungen der max-features-Variante entgegen, wäre nett, wenn ihr dabei das hier (https://forum.fhem.de/index.php/topic,94495.msg872201.html#msg872201) beachtet.

Viel Freude damit,

Beta-User

so, lang hats gedauert, jetzt mal wieder was von der front  ;D :D

Hab mir heut mal die Templates für X_01_esp_milight_hub_bridge A_02_tasmota_2channel_split und X_01x_esp_milight_hub_max_features_bulb getestet.

Zum einen Vielen Dank für deine mühen.

Zum andern etwas konstruktive Kritik, ein paar Bugs und anregungen.

also zum einen denk ich ist in den templates für die milightlampen in den setList, die unterste zeile falsch ....
(falsche adresse und ohne funktion)
dim:uzsuSelectRadio,Up,Down milight/0xBE59/rgbw/1 {"command":"level_$EVTPART1"}

dim gibts nicht, dafür aber brightness.
ein (hex)Colorpicker für die Farbsättigung(saturation) ist auch eher sinnbefreit. also meine Milights erwarten einen wert von 0-100 und ich hab das mit dem brightness regler gelöst.

dann ergeben sich im webCmd(Label)einige ungereimtheiten auf die ich garnicht näher eingehen will, das ding ist einfach total zerhagelt  ;D ::)
Bilder sprechen ja bekanntlich mehr als tausend worte, daher anbei ein paar screeshots. (das ergebniss aus dem template sollte der erste screenshot sein, das zweite meine änderung)

ich mach des jetzt einfacher, ich poste zuerst das ergebniss des templates, und darunter meine verschlimmbesserung.

das ergebniss aus dein templates
template milightlampen
defmod MQTT2_milight_0x5D02_4 MQTT2_DEVICE milight_0x5D02_4
attr MQTT2_milight_0x5D02_4 IODev MQTT2_Broker
attr MQTT2_milight_0x5D02_4 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_milight_0x5D02_4 eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Faster/mode_speed_down:Slower/level_up:Up/level_down:Down/
attr MQTT2_milight_0x5D02_4 group Licht
attr MQTT2_milight_0x5D02_4 icon light_control
attr MQTT2_milight_0x5D02_4 model X_01x_esp_milight_hub_max_features_bulb
attr MQTT2_milight_0x5D02_4 readingList milight/states/0x5D02/rgb_cct/4:.* { json2nameValue($EVENT) }\
   milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
   milight/updates/0x5D02/rgb_cct/4:.* { json2nameValue($EVENT) }\
   milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
attr MQTT2_milight_0x5D02_4 room Unsorted
attr MQTT2_milight_0x5D02_4 setList on milight/0x5D02/rgb_cct/4 {"status":"ON"}\
   off milight/0x5D02/rgb_cct/4 {"status":"OFF"}\
   brightness:colorpicker,BRI,0,15,255 milight/0x5D02/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}\
   hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}\
   color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}\
   saturation:colorpicker,sat,0,1,255 milight/0x5D02/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}\
   command:uzsuSelectRadio,Weiss,Nacht milight/0x5D02/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}\
   program:uzsuSelectRadio,Mode,Faster,Slower milight/0x5D02/rgb_cct/4 {"command":"$EVTPART1"}\
   dim:uzsuSelectRadio,Up,Down milight/0xBE59/rgbw/1 {"command":"level_$EVTPART1"}
attr MQTT2_milight_0x5D02_4 userReadings rgb {sprintf("%02X%02X%02X", ReadingsVal($name,"color_r",255), ReadingsVal($name,"color_g",255), ReadingsVal($name,"color_b",255))}
attr MQTT2_milight_0x5D02_4 verbose 0
attr MQTT2_milight_0x5D02_4 webCmd on:off:brightness:hue:color_temp:saturation:dim:command:program
attr MQTT2_milight_0x5D02_4 webCmdLabel on:off:brightness:hue\
   :color_temp:saturation\
   :dim:command:program

setstate MQTT2_milight_0x5D02_4 2018-12-28 16:07:40 associatedWith milight_hub




meine änderung
defmod LichtWzMiAll MQTT2_DEVICE milight_0x5D02_3
attr LichtWzMiAll IODev MQTT2_Broker
attr LichtWzMiAll devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr LichtWzMiAll eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Faster/mode_speed_down:Slower/level_up:Up/level_down:Down/
attr LichtWzMiAll group Licht
attr LichtWzMiAll icon light_control
attr LichtWzMiAll model X_01x_esp_milight_hub_max_features_bulb
attr LichtWzMiAll readingList milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
attr LichtWzMiAll room Wohnzimmer
attr LichtWzMiAll setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
brightness:colorpicker,BRI,0,15,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
program:uzsuSelectRadio,Mode,Faster,Slower milight/0x5D02/rgb_cct/0 {"command":"$EVTPART1"}\
mode:select,0,1,2,3,4,5,6,7,8 milight/0x5D02/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}
attr LichtWzMiAll verbose 5
attr LichtWzMiAll webCmd brightness:command:hue:program:color_temp:mode:saturation
attr LichtWzMiAll webCmdLabel brightness:command\
:hue:program\
:color_temp:mode\
:saturation

setstate LichtWzMiAll saturation
setstate LichtWzMiAll 2018-12-28 21:28:38 brightness 255
setstate LichtWzMiAll 2018-12-28 21:28:36 color_temp 348
setstate LichtWzMiAll 2018-12-28 16:42:29 command night_mode
setstate LichtWzMiAll 2018-12-28 21:28:29 hue 0
setstate LichtWzMiAll 2018-12-28 16:42:35 mode 4
setstate LichtWzMiAll 2018-12-28 20:51:38 rgb FFFFFF
setstate LichtWzMiAll 2018-12-28 21:28:40 saturation 0
setstate LichtWzMiAll 2018-12-28 21:28:40 state saturation



dann zu den MQTT2 problemen.

dann hab ich was ganz eigenartiges, und früher äusserte sich das nur so, das eine funktion (color_temp), in einer Milightgruppe die Nr1 (gelesen 0=all, 1=Lampe1, 2=Lampe2), immer wenn ich die verstellte zurück sprang.
Jetzt allerdings, stellts mir bei 2 genauso die farbtemperatur um und bei 1 hüpft der "hue" dazwischen und stellt auf colormode. sprich für einen kurzen augenblick verändert color_temp (wie gewohnt in eine Weiße farbtemperatur und bruchteile später stellt wie von geisterhand hue wieder auf bunt zurück.

sieht man auch im log
018-12-28 21:41:49 at Time_Update Next: 21:41:59
2018-12-28 21:41:49 MQTT2_DEVICE milight_hub 1_hue: 99
2018-12-28 21:41:49 MQTT2_DEVICE LichtWzMiDecke hue: 99
2018-12-28 21:41:49 MQTT2_SERVER MQTT2_Broker milight/updates/0x5D02/rgb_cct/1:{"hue":99}
2018-12-28 21:41:49 MQTT2_DEVICE milight_hub 1_hue: 99
2018-12-28 21:41:49 MQTT2_DEVICE milight_hub 1_saturation: 100
2018-12-28 21:41:49 MQTT2_DEVICE milight_hub 1_brightness: 255
2018-12-28 21:41:49 MQTT2_DEVICE milight_hub 1_state: ON
2018-12-28 21:41:49 MQTT2_DEVICE milight_hub 1_level: 100
2018-12-28 21:41:49 MQTT2_DEVICE milight_hub 1_bulb_mode: color
2018-12-28 21:41:49 MQTT2_DEVICE milight_hub 1_status: ON
2018-12-28 21:41:49 MQTT2_SERVER MQTT2_Broker milight/states/0x5D02/rgb_cct/1:{"state":"ON","status":"ON","brightness":255,"level":100,"hue":99,"saturation":100,"color":{},"bulb_mode":"color"}
2018-12-28 21:41:59 at Time_Update Next: 21:42:09
2018-12-28 21:41:59 MQTT2_DEVICE LichtWzMiDecke color_temp
2018-12-28 21:42:00 MQTT2_DEVICE milight_hub 1_color_temp: 337
2018-12-28 21:42:00 MQTT2_DEVICE LichtWzMiDecke color_temp: 337
2018-12-28 21:42:00 MQTT2_SERVER MQTT2_Broker milight/updates/0x5D02/rgb_cct/1:{"color_temp":337}
2018-12-28 21:42:01 MQTT2_DEVICE LichtWzMiDecke hue: 99
2018-12-28 21:42:01 MQTT2_DEVICE milight_hub 1_hue: 99
2018-12-28 21:42:01 MQTT2_SERVER MQTT2_Broker milight/updates/0x5D02/rgb_cct/1:{"hue":99}
2018-12-28 21:42:01 MQTT2_DEVICE milight_hub 1_bulb_mode: color
2018-12-28 21:42:01 MQTT2_DEVICE milight_hub 1_status: ON
2018-12-28 21:42:01 MQTT2_DEVICE milight_hub 1_hue: 99
2018-12-28 21:42:01 MQTT2_DEVICE milight_hub 1_saturation: 100
2018-12-28 21:42:01 MQTT2_DEVICE milight_hub 1_brightness: 255
2018-12-28 21:42:01 MQTT2_DEVICE milight_hub 1_state: ON
2018-12-28 21:42:01 MQTT2_DEVICE milight_hub 1_level: 100
2018-12-28 21:42:01 MQTT2_SERVER MQTT2_Broker milight/states/0x5D02/rgb_cct/1:{"state":"ON","status":"ON","brightness":255,"level":100,"hue":99,"saturation":100,"color":{},"bulb_mode":"color"}
2018-12-28 21:42:04 MQTT2_DEVICE LichtWzMiDecke color_temp
2018-12-28 21:42:04 MQTT2_DEVICE milight_hub 1_color_temp: 301
2018-12-28 21:42:04 MQTT2_DEVICE LichtWzMiDecke color_temp: 301
2018-12-28 21:42:05 MQTT2_SERVER MQTT2_Broker milight/updates/0x5D02/rgb_cct/1:{"color_temp":301}
2018-12-28 21:42:05 MQTT2_DEVICE milight_hub 1_hue: 99
2018-12-28 21:42:05 MQTT2_DEVICE LichtWzMiDecke hue: 99
2018-12-28 21:42:05 MQTT2_SERVER MQTT2_Broker milight/updates/0x5D02/rgb_cct/1:{"hue":99}
2018-12-28 21:42:05 MQTT2_DEVICE milight_hub 1_saturation: 100
2018-12-28 21:42:05 MQTT2_DEVICE milight_hub 1_brightness: 255
2018-12-28 21:42:05 MQTT2_DEVICE milight_hub 1_hue: 99
2018-12-28 21:42:05 MQTT2_DEVICE milight_hub 1_state: ON
2018-12-28 21:42:05 MQTT2_DEVICE milight_hub 1_level: 100
2018-12-28 21:42:05 MQTT2_DEVICE milight_hub 1_status: ON
2018-12-28 21:42:05 MQTT2_DEVICE milight_hub 1_bulb_mode: color
2018-12-28 21:42:05 MQTT2_SERVER MQTT2_Broker milight/states/0x5D02/rgb_cct/1:{"state":"ON","status":"ON","brightness":255,"level":100,"hue":99,"saturation":100,"color":{},"bulb_mode":"color"}
2018-12-28 21:42:06 MQTT2_DEVICE LichtWzMiDecke color_temp
2018-12-28 21:42:07 MQTT2_DEVICE milight_hub 1_color_temp: 327
2018-12-28 21:42:07 MQTT2_DEVICE LichtWzMiDecke color_temp: 327
2018-12-28 21:42:07 MQTT2_SERVER MQTT2_Broker milight/updates/0x5D02/rgb_cct/1:{"color_temp":327}
2018-12-28 21:42:07 MQTT2_DEVICE LichtWzMiDecke hue: 99
2018-12-28 21:42:07 MQTT2_DEVICE milight_hub 1_hue: 99
2018-12-28 21:42:07 MQTT2_SERVER MQTT2_Broker milight/updates/0x5D02/rgb_cct/1:{"hue":99}
2018-12-28 21:42:07 MQTT2_DEVICE milight_hub 1_bulb_mode: color
2018-12-28 21:42:07 MQTT2_DEVICE milight_hub 1_status: ON
2018-12-28 21:42:07 MQTT2_DEVICE milight_hub 1_saturation: 100
2018-12-28 21:42:07 MQTT2_DEVICE milight_hub 1_hue: 99
2018-12-28 21:42:07 MQTT2_DEVICE milight_hub 1_brightness: 255
2018-12-28 21:42:07 MQTT2_DEVICE milight_hub 1_level: 100
2018-12-28 21:42:07 MQTT2_DEVICE milight_hub 1_state: ON
2018-12-28 21:42:07 MQTT2_SERVER MQTT2_Broker milight/states/0x5D02/rgb_cct/1:{"state":"ON","status":"ON","brightness":255,"level":100,"hue":99,"saturation":100,"color":{},"bulb_mode":"color"}
2018-12-28 21:42:09 dummy Time_FP 2018-12-28 21:42

hab den fehler jetzt wieder an nenn punkt eingegrenzt und minimiert, dass ich mir einfach nicht erklären kann woher dieses verhalten kommt. und zwar funktionieren jetzt bis auf eine einzige lampe (gruppe2)alles das was es soll. nur eben bei dieser einen lampe, sobald ich an der "color_temp" dreh, erfolgt direkt im anschluss ein verstellen des "hue"(farbwechsel) auf immer wieder den einen falschen wert. ("hue:120") und das wie gesagt ohne was dazu zu tun.
das publish kommt vom fhem mqtt2 server ... woher auch immer

siehe device log
2018-12-28_22:47:14 LichtWzMiWand hue: 346
2018-12-28_22:47:14 LichtWzMiWand brightness: 245
2018-12-28_22:47:15 LichtWzMiWand hue: 3
2018-12-28_22:47:17 LichtWzMiWand color_temp: 290
2018-12-29_03:53:47 LichtWzMiWand hue: 229
2018-12-29_03:53:48 LichtWzMiWand hue: 14
2018-12-29_03:53:49 LichtWzMiWand off
2018-12-29_03:53:52 LichtWzMiWand on
2018-12-29_04:03:27 LichtWzMiWand on
2018-12-29_04:03:28 LichtWzMiWand on
2018-12-29_04:09:38 LichtWzMiWand off
2018-12-29_14:19:59 LichtWzMiWand on
2018-12-29_14:20:04 LichtWzMiWand brightness: 255
2018-12-29_14:20:12 LichtWzMiWand color_temp
2018-12-29_14:20:13 LichtWzMiWand color_temp: 196
2018-12-29_14:20:14 LichtWzMiWand hue: 120
2018-12-29_14:20:25 LichtWzMiWand color_temp: 335
2018-12-29_14:20:49 LichtWzMiWand hue: 174
2018-12-29_14:23:36 LichtWzMiWand color_temp: 290
2018-12-29_14:23:36 LichtWzMiWand hue: 120
2018-12-29_14:24:56 LichtWzMiWand color_temp: 316
2018-12-29_14:24:58 LichtWzMiWand color_temp: 340
2018-12-29_14:26:15 LichtWzMiWand brightness
2018-12-29_14:26:16 LichtWzMiWand brightness: 0
2018-12-29_14:26:19 LichtWzMiWand brightness: 255
2018-12-29_14:26:19 LichtWzMiWand hue
2018-12-29_14:26:20 LichtWzMiWand hue: 359
2018-12-29_14:26:22 LichtWzMiWand hue: 0
2018-12-29_14:26:23 LichtWzMiWand color_temp
2018-12-29_14:26:24 LichtWzMiWand color_temp: 153
2018-12-29_14:26:25 LichtWzMiWand hue: 120
2018-12-29_14:26:27 LichtWzMiWand saturation
2018-12-29_14:26:27 LichtWzMiWand saturation: 0
2018-12-29_14:26:29 LichtWzMiWand hue
2018-12-29_14:26:30 LichtWzMiWand hue: 0
2018-12-29_14:26:30 LichtWzMiWand color_temp
2018-12-29_14:26:31 LichtWzMiWand color_temp: 311
2018-12-29_14:26:32 LichtWzMiWand hue: 120
2018-12-29_14:26:44 LichtWzMiWand hue
2018-12-29_14:26:45 LichtWzMiWand hue: 0
2018-12-29_14:26:48 LichtWzMiWand saturation
2018-12-29_14:26:49 LichtWzMiWand saturation: 18
2018-12-29_14:26:51 LichtWzMiWand saturation: 0
2018-12-29_14:26:51 LichtWzMiWand color_temp
2018-12-29_14:26:52 LichtWzMiWand color_temp: 242
2018-12-29_14:26:53 LichtWzMiWand hue: 120
2018-12-29_14:27:15 LichtWzMiWand mode
2018-12-29_14:27:16 LichtWzMiWand mode: 4
2018-12-29_14:27:19 LichtWzMiWand color_temp
2018-12-29_14:27:20 LichtWzMiWand color_temp: 309
2018-12-29_14:28:40 LichtWzMiWand color_temp: 322
2018-12-29_14:28:43 LichtWzMiWand hue
2018-12-29_14:28:43 LichtWzMiWand hue: 0
2018-12-29_14:28:44 LichtWzMiWand color_temp
2018-12-29_14:28:45 LichtWzMiWand color_temp: 201
2018-12-29_14:28:45 LichtWzMiWand hue: 120


2018.12.29 14:28:29 5: PUBLISH: (0)(21)ESP_Garagentor/uptime64d04h47m
2018.12.29 14:28:29 4: MQTT2_Broker_192.168.1.160_50066 ESP_Garagentor PUBLISH ESP_Garagentor/uptime:64d04h47m
2018.12.29 14:28:29 5: MQTT2_Broker: dispatch autocreate:ESP_Garagentor:ESP_Garagentor/uptime:64d04h47m
2018.12.29 14:28:30 5: PINGREQ:
2018.12.29 14:28:30 4: MQTT2_Broker_192.168.1.160_50066 ESP_Garagentor PINGREQ
2018.12.29 14:28:30 5: MQTT2_Broker: PUBLISH milight/0x5D02/rgb_cct/1 {"color_temp":"278"}
2018.12.29 14:28:30 5: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 => milight/0x5D02/rgb_cct/1:{"color_temp":"278"}
2018.12.29 14:28:31 5: PUBLISH: (0) milight/updates/0x5D02/rgb_cct/1{"color_temp":279}
2018.12.29 14:28:31 4: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/1:{"color_temp":279}
2018.12.29 14:28:31 5: MQTT2_Broker: dispatch autocreate:milight_hub_10693013:milight/updates/0x5D02/rgb_cct/1:{"color_temp":279}
2018.12.29 14:28:31 4: MQTT2_DEVICE_Parse: LichtWzMiDecke milight/updates/0x5D02/rgb_cct/1 => { json2nameValue($EVENT) }
2018.12.29 14:28:31 5: PINGREQ:
2018.12.29 14:28:31 4: MQTT2_Broker_192.168.1.171_1153 SonOff_KiGr PINGREQ
2018.12.29 14:28:32 5: PINGREQ:
2018.12.29 14:28:32 4: MQTT2_Broker_192.168.1.161_50078 ESP_Kuechenuhr PINGREQ
2018.12.29 14:28:33 5: PINGREQ:
2018.12.29 14:28:33 4: MQTT2_Broker_192.168.1.164_49230 ESP-IR PINGREQ
2018.12.29 14:28:33 5: MQTT2_Broker: PUBLISH milight/0x5D02/rgb_cct/1 {"color_temp":"278"}
2018.12.29 14:28:33 5: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 => milight/0x5D02/rgb_cct/1:{"color_temp":"278"}
2018.12.29 14:28:34 5: PUBLISH: (0) milight/updates/0x5D02/rgb_cct/1{"color_temp":279}
2018.12.29 14:28:34 4: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/1:{"color_temp":279}
2018.12.29 14:28:34 5: MQTT2_Broker: dispatch autocreate:milight_hub_10693013:milight/updates/0x5D02/rgb_cct/1:{"color_temp":279}
2018.12.29 14:28:34 4: MQTT2_DEVICE_Parse: LichtWzMiDecke milight/updates/0x5D02/rgb_cct/1 => { json2nameValue($EVENT) }
2018.12.29 14:28:34 5: MQTT2_Broker: PUBLISH milight/0x5D02/rgb_cct/1 {"color_temp":"340"}
2018.12.29 14:28:34 5: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 => milight/0x5D02/rgb_cct/1:{"color_temp":"340"}
2018.12.29 14:28:35 5: PUBLISH: (0) milight/updates/0x5D02/rgb_cct/1{"color_temp":340}
2018.12.29 14:28:35 4: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/1:{"color_temp":340}
2018.12.29 14:28:35 5: MQTT2_Broker: dispatch autocreate:milight_hub_10693013:milight/updates/0x5D02/rgb_cct/1:{"color_temp":340}
2018.12.29 14:28:35 4: MQTT2_DEVICE_Parse: LichtWzMiDecke milight/updates/0x5D02/rgb_cct/1 => { json2nameValue($EVENT) }
2018.12.29 14:28:36 5: MQTT2_Broker: PUBLISH milight/0x5D02/rgb_cct/1 {"color_temp":"259"}
2018.12.29 14:28:36 5: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 => milight/0x5D02/rgb_cct/1:{"color_temp":"259"}
2018.12.29 14:28:37 5: PINGREQ:
2018.12.29 14:28:37 4: MQTT2_Broker_192.168.1.162_49593 ESP_5Vrelais PINGREQ
2018.12.29 14:28:37 5: PUBLISH: (0) milight/updates/0x5D02/rgb_cct/1{"color_temp":259}
2018.12.29 14:28:37 4: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/1:{"color_temp":259}
2018.12.29 14:28:37 5: MQTT2_Broker: dispatch autocreate:milight_hub_10693013:milight/updates/0x5D02/rgb_cct/1:{"color_temp":259}
2018.12.29 14:28:37 4: MQTT2_DEVICE_Parse: LichtWzMiDecke milight/updates/0x5D02/rgb_cct/1 => { json2nameValue($EVENT) }
2018.12.29 14:28:39 5: PINGREQ:
2018.12.29 14:28:39 4: MQTT2_Broker_192.168.1.170_29472 SonOff_Wz PINGREQ
2018.12.29 14:28:39 5: MQTT2_Broker: PUBLISH milight/0x5D02/rgb_cct/2 {"color_temp":"323"}
2018.12.29 14:28:39 5: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 => milight/0x5D02/rgb_cct/2:{"color_temp":"323"}
2018.12.29 14:28:40 5: PUBLISH: (0) milight/updates/0x5D02/rgb_cct/2{"color_temp":322}
2018.12.29 14:28:40 4: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/2:{"color_temp":322}
2018.12.29 14:28:40 5: MQTT2_Broker: dispatch autocreate:milight_hub_10693013:milight/updates/0x5D02/rgb_cct/2:{"color_temp":322}
2018.12.29 14:28:40 4: MQTT2_DEVICE_Parse: LichtWzMiWand milight/updates/0x5D02/rgb_cct/2 => { json2nameValue($EVENT) }
2018.12.29 14:28:40 5: PINGREQ:
2018.12.29 14:28:40 4: MQTT2_Broker_192.168.1.160_50066 ESP_Garagentor PINGREQ
2018.12.29 14:28:41 5: PUBLISH: (0) milight/updates/0x5D02/rgb_cct/2{"hue":120}
2018.12.29 14:28:41 4: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/2:{"hue":120}
2018.12.29 14:28:41 5: MQTT2_Broker: dispatch autocreate:milight_hub_10693013:milight/updates/0x5D02/rgb_cct/2:{"hue":120}
2018.12.29 14:28:41 4: MQTT2_DEVICE_Parse: LichtWzMiWand milight/updates/0x5D02/rgb_cct/2 => { json2nameValue($EVENT) }
2018.12.29 14:28:41 5: PINGREQ:
2018.12.29 14:28:41 4: MQTT2_Broker_192.168.1.171_1153 SonOff_KiGr PINGREQ
2018.12.29 14:28:42 5: PINGREQ:
2018.12.29 14:28:42 4: MQTT2_Broker_192.168.1.161_50078 ESP_Kuechenuhr PINGREQ
2018.12.29 14:28:43 5: MQTT2_Broker: PUBLISH milight/0x5D02/rgb_cct/2 {"hue":"0"}
2018.12.29 14:28:43 5: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 => milight/0x5D02/rgb_cct/2:{"hue":"0"}
2018.12.29 14:28:43 5: PINGREQ:
2018.12.29 14:28:43 4: MQTT2_Broker_192.168.1.164_49230 ESP-IR PINGREQ
2018.12.29 14:28:43 5: PUBLISH: (0) milight/updates/0x5D02/rgb_cct/2{"hue":0}
2018.12.29 14:28:43 4: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/2:{"hue":0}
2018.12.29 14:28:43 5: MQTT2_Broker: dispatch autocreate:milight_hub_10693013:milight/updates/0x5D02/rgb_cct/2:{"hue":0}
2018.12.29 14:28:43 4: MQTT2_DEVICE_Parse: LichtWzMiWand milight/updates/0x5D02/rgb_cct/2 => { json2nameValue($EVENT) }
2018.12.29 14:28:44 5: MQTT2_Broker: PUBLISH milight/0x5D02/rgb_cct/2 {"color_temp":"201"}
2018.12.29 14:28:44 5: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 => milight/0x5D02/rgb_cct/2:{"color_temp":"201"}
2018.12.29 14:28:45 5: PUBLISH: (0) milight/updates/0x5D02/rgb_cct/2{"color_temp":201}
2018.12.29 14:28:45 4: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/2:{"color_temp":201}
2018.12.29 14:28:45 5: MQTT2_Broker: dispatch autocreate:milight_hub_10693013:milight/updates/0x5D02/rgb_cct/2:{"color_temp":201}
2018.12.29 14:28:45 4: MQTT2_DEVICE_Parse: LichtWzMiWand milight/updates/0x5D02/rgb_cct/2 => { json2nameValue($EVENT) }
2018.12.29 14:28:45 5: PUBLISH: (0) milight/updates/0x5D02/rgb_cct/2{"hue":120}
2018.12.29 14:28:45 4: MQTT2_Broker_192.168.1.163_19224 milight-hub-10693013 PUBLISH milight/updates/0x5D02/rgb_cct/2:{"hue":120}
2018.12.29 14:28:45 5: MQTT2_Broker: dispatch autocreate:milight_hub_10693013:milight/updates/0x5D02/rgb_cct/2:{"hue":120}
2018.12.29 14:28:45 4: MQTT2_DEVICE_Parse: LichtWzMiWand milight/updates/0x5D02/rgb_cct/2 => { json2nameValue($EVENT) }

das eigenartige ist, ich hab bis auf updates nicht wiklich was daran geändert. bis auf eben nun diesen test mit den templates um es eigentlich fehlerfreier hinzubekommen, aber mit dem ergebniss das es zum gleichen verhalten führte.  :P ???

dann hab ich ja um die templates zu nutzen, die alten devices gelöscht. bei den milight hats mir aber nur die gruppen 1-4 angelegt. die gruppe 0 für all hat es nicht angelegt. die hab ich dann kurzerhand kopiert und geändert.

Hmmm,
vorab mal Danke für's Testen und die umfangreiche Rückmeldung. Dass vor allem das "max-featured"  bei weitem noch nicht fertig ist, ist klar (habe ich hoffentlich auch deutlich genug beim template und v.a. im Wiki geäußert?). Da steht auch, dass man erst die "0" anlegen muß, weil es sonst nach dem Anlegen der anderen und anwenden des templates nicht mehr geht.

Bin durch Deine Hinweise noch nicht ganz durch, aber vorab schon mal ein paar Anmerkungen:
- dim: Ist schon klar, dass das nicht unterstützt wird ::) , aber {"command":"level_up"} usw. verstehen manche Typen wohl (deine cct-Devices?) ;) . Das hatte ich mqtt-technisch mal hingepfriemelt (daher auch der undynamische Pfad), allerdings dann nicht in der funtionierenden Fassung im template verwurstelt (meine RGBW's verstehend das eh' nicht)... Damit das klappt, müßte aber entweder die eventMap angepaßt werden (kürzer) oder in der setList das "level_" raus.
Also die Zeile lautet m.E. korrekterweise so:
dim:uzsuSelectRadio,Up,Down BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"command":"$EVTPART1"}
Vielleicht magst du das mal testen?

- Das "Springen" kommt vielleicht zum Teil auch daher, dass FHEM nicht den Ziel-Wert in das Reading schreibt, sondern per default alle Sendekommandos in den state. Es gibt ein neues Attribut "setStateList", das aber in den templates insgesamt noch nicht verarbeitet ist (bei meiner zigbee-Bridge wäre das "on off").
Allerdings erklärt das nicht, warum da irgendeine Wechselwirkung zwischen den verschiedenen Kanälen zu beobachten ist.

- Dann hat Rudi json2nameValue() erweitert; ob daraus Handlungsbedarf für die Sidoh-Bridge folgt, habe ich noch nicht getestet bzw. darüber noch nicht sinniert.

Allg. war es bei der max-featured auch nicht das Ziel, eine "schöne" Darstellung zu erreichen, sondern eher eine vollständige, zum "Abspecken"; daher sind auch die label usw. drin. Wenn da aber nur "::\::..." stände, wäre es auch nichts, weil dann keiner mehr versteht, wie was zusammengehört. Andererseits braucht man das (?), um die mehrzeilige Darstellung zu erreichen.

Hoffe, das hilft in Teilen weiter?

So,
habe eben mal noch ein update der templates hochgeladen. Dabei ein neues rgb_cct reingebastelt und das max-featured etwas geändert, testen wäre nett.

Hallo, eine Frage an die Spezialisten. Ich haben hier 2 Milight Schalter FUT087 einkanalig und versuche diese
über MQTT mit Milighthub in Fhem abzugreifen. Die Device Id`s habe ich mit dem Sniffer rausbekommen. Wenn ich
jetzt den ersten Schalter im MQTT konfiguriere klappt das Darstellen mit autocreate in FHEM gut. Ich kann die Statusänderung sehen.
Was mache ich jetzt mit meinen 2 ten Schalter?
Wenn ich den betätige ändert sich der Status auch obwohl der eine andere Id hat. Ich verstehe noch nicht ganz wie ich das machen soll.
Vieleicht kann mir jemand helfen. Danke im vorraus gruß Lucca

MQTT Sever: 192.168.178.40:45992


Schalter1:

milight/:3682/:FUT089_B8/:1

milight/updates/:3682/:FUT089_B8/:1

milight/states/:3682/:FUT089_B8/:1



Schalter2:

milight/:3698/:FUT089_B8/:1

milight/updates/:3698/:FUT089_B8/:1

milight/states/:3698/:FUT089_B8/:1

Zitat von: lucca111 am 30 Dezember 2018, 14:55:18
Hallo, eine Frage an die Spezialisten. Ich haben hier 2 Milight Schalter FUT087 einkanalig und versuche diese
über MQTT mit Milighthub in Fhem abzugreifen.

Hast du auf den ersten mal das "Bridge"-template angewendet?

Dann sollten nach dem drücken auf jede der beiden Fernbedienungen noch zwei Devices via autocreate angelegt werden. Ansonsten ist es "normal", dass alle Readings in einem Device landen.

---

Ansonsten habe ich eben noch eine Aktualisierung der templates ins svn geschoben. Da ist ein rgbw-Gruppen-Erstellungs-template drin :) .

Viel Spaß damit.

kannst du mal ein screenshot von dem milighthub machen ? siehe beispiel screenshot

Ansonsten habe ich eben noch eine Aktualisierung der templates ins svn geschoben. Da ist ein rgbw-Gruppen-Erstellungs-template drin :) .



Danke für deine Hilfe. Wo finde ich das svn bin halt noch nicht so firm hier.  :-\

Bis morgen warten, und dann Update machen

Zitat von: lucca111 am 30 Dezember 2018, 17:55:56
Danke für deine Hilfe. Wo finde ich das svn bin halt noch nicht so firm hier.  :-\

Gerne geschehen; die template-Modifikation hat aber nichts mit deinem Problem zu tun.

Vermutlich hat DasQ bereits den entscheidenden Hinweis gegeben: Die Einstellungen, die du im Web-IF des GW scheinbar drinne hast, klingen komisch: bei den topics usw. sind eigentlich keine speziellen Einstellungen zu machen, das kann bei den Standardwerten bleiben.
Wenn was anzupassen ist, dann die zu sendenen Infos (zu finden in den "Group state fields" bei den MQTT-settings).

@DasQ: konntest du testen?
(man kann das auch von hier (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template) runterladen und z.B. mit einem Editor über das vorhandene klatschen).
Bei mir sieht das max featured so eigentlich ganz nett aus, aber ich kann's mit dem Dimmen halt nicht testen:
attr milight_test_1 webCmdLabel :\
   ::Dimmen\
   ::\
   ::Programm\
   ::Modus

Ja aber was schreibe ich den als Standard rein beim Mqtt im Gateway?
MQTT topic pattern: ???
MQTT update topic pattern ???
MQTT state topic pattern ???

Einfach nur so??
MQTT topic pattern:

milight/:device_id/:device_type/:group_id

MQTT update topic pattern:

milight/update/:hex_device_id/:device_id/:device_type/:group_id

MQTT state topic pattern:

milight/state/:hex_device_id/:device_id/:device_type/:group_id

Hallo zusammen,

ich bin bislang schon mehr als begeistert von dem Modul und dass damit die Milights mal wieder besser in FHEM integriertwerden können !!! Danke schonmal für die tolle Arbeit !!! Was ich noch an Templates gut finden würde, ist ein minimalistisches Template für z.B. CCT-Controller ohne RGB.

Zitat von: Snocksman am 30 Dezember 2018, 19:15:35
Hallo zusammen,

ich bin bislang schon mehr als begeistert von dem Modul und dass damit die Milights mal wieder besser in FHEM integriertwerden können !!! Danke schonmal für die tolle Arbeit !!! Was ich noch an Templates gut finden würde, ist ein minimalistisches Template für z.B. CCT-Controller ohne RGB.

Danke für die Rückmeldung :D .

Hast du zufällig ein passendes list?
Kannst gerne Rückmeldung zu dem folgenden ungetesteten Versuch hier geben (in template-Datei irgendwo einfügen, { AttrTemplate_Initialize() } ausführen):
#cct-only-bulb
name:X_01a_esp_milight_hub_cct_only_bulb
filter:TYPE=MQTT2_DEVICE
desc:For use with X_01_esp_milight_hub_bridge <br>NOTE: Development state is experimental! <br>simple CCT device
par:BASE_ID;BASE_ID typically is milight;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*ates/.*:, ? $1 : undef }
par:GROUP_ID;number from 0 to 4 representing one of the channels of an original bridge or remote;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/][^/]+[/][^/]+[/]([0-4]):, ? $1 : undef }
par:REMOTE_ID;HEX number representing a specific remote or bridge;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/](0x....)[/].*:, ? $2 : undef }
par:BULB_TYPE;rgbw, cct, rgb_cct, rgb, fut089, ;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/][^/]+[/][^/]+[/]([^/]+)[/].*:, ? $1 : undef }
deletereading DEVICE .*_.*
attr DEVICE icon light_control
attr DEVICE eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Faster/mode_speed_down:Slower/level_up:Up/level_down:Down/
attr DEVICE devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr DEVICE readingList BASE_ID/states/REMOTE_ID/BULB_TYPE/GROUP_ID:.* { json2nameValue($EVENT) }\
   BASE_ID/states/REMOTE_ID/BULB_TYPE/0:.* { json2nameValue($EVENT) }\
   BASE_ID/updates/REMOTE_ID/BULB_TYPE/GROUP_ID:.* { json2nameValue($EVENT) }\
   BASE_ID/updates/REMOTE_ID/BULB_TYPE/0:.* { json2nameValue($EVENT) }
attr DEVICE setList\
   on BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"status":"ON"}\
   off BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"status":"OFF"}\
   brightness:colorpicker,BRI,0,15,255 BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"$EVTPART0":"$EVTPART1"}\
   command:uzsuSelectRadio,Weiss,Nacht BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"$EVTPART0":"$EVTPART1"}\
   program:uzsuSelectRadio,Mode,Faster,Slower BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"command":"$EVTPART1"}\
   mode:select,0,1,2,3,4,5,6,7,8 BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"$EVTPART0":"$EVTPART1"}\
   dim:uzsuSelectRadio,Up,Down BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"command":"$EVTPART1"}
attr DEVICE webCmd brightness:dim
attr DEVICE webCmdLabel brightness:dim
attr DEVICE setStateList on off
attr DEVICE model X_01a_esp_milight_hub_cct_only_bulb

@lucca111
Ich fahre das im Moment mit folgenden Einstellungen (und hoffe, dass das Standard ist, kann aber nicht ausschließen, dass dem nicht so ist....):

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

Zitat von: Beta-User am 30 Dezember 2018, 18:27:28
@DasQ: konntest du testen?

wenn mir nix dawischen kommt mach ich morgen nen test.


@Snocksman hast du meine antwort bekommen? ich seh leider bei mir nix im postausgang, der war standartmässig deaktiviert.

@DasQ: Hab ich bekommen (Danke dafür !). Nach nem ersten Test wurde das Device leider gar nicht mehr angezeigt (warum auch immer)...  ???  Muss ich morgen nochmal in Ruhe probieren. Bin auch mal auf die neuen Templates gespannt.

Hallo nochmal,
ich habe es jetzt geschafft das über autocreate ein MQTT2_Device angelegt wird. Die beiden Schalter werden nach betätigen in der  Readinglist automatisch eingetragen.

readingList
milight_hub_7365307:milight/update/0x3698/0x3698/fut089/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
milight_hub_7365307:milight/state/0x3698/0x3698/fut089/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
milight_hub_7365307:milight/update/0x3682/0x3682/fut089/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
milight_hub_7365307:milight/state/0x3682/0x3682/fut089/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }

Unter Readings sehe ich aber nur folgendes:

Readings
1_brightness 150 2018-12-31 12:47:30
1_color_b 255 2018-12-31 12:47:30
1_color_g 25 2018-12-31 12:47:30
1_color_r 255 2018-12-31 12:47:30
1_command night_mode 2018-12-31 12:47:27
1_state OFF 2018-12-31 12:47:30

Egal welchen Schalter ich betätige die Readings werden geupdatet.
Wie stelle ich es an das ich beide Schalter auseinander halten kann?
Ich habe auch schon versucht per Hand 2 Devices zu erstellen scheitere aber jedesmal jämmerlich.
Gruß Lucca

So nach x-mal probieren (restart + Device über die fhemconfig anlegen,löschen, rumprobieren usw.) sehe ich unter den
Reading jetzt 2 Devices:

Readings
1_brightness 150 2018-12-31 12:47:30
1_color_b 255 2018-12-31 12:47:30
1_color_g 25 2018-12-31 12:47:30
1_color_r 255 2018-12-31 12:47:30
1_command night_mode 2018-12-31 12:47:27
1_state OFF 2018-12-31 12:47:30
2_brightness 150 2018-12-31 12:47:55
2_color_b 255 2018-12-31 12:47:55
2_color_g 25 2018-12-31 12:47:55
2_color_r 255 2018-12-31 12:47:55
2_command night_mode 2018-12-31 12:47:55
2_state ON 2018-12-31 12:47:55

jetzt noch die Readiglist manuell angepasst ("$EVENT, '2_") und es wird Schalter1 und 2 unterschiedlich nach einen Neustart ausgewertet.

readingList
milight_hub_7365307:milight/update/0x3698/0x3698/fut089/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
milight_hub_7365307:milight/state/0x3698/0x3698/fut089/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
milight_hub_7365307:milight/update/0x3682/0x3682/fut089/1:.* { json2nameValue($EVENT, '2_', $JSONMAP) }
milight_hub_7365307:milight/state/0x3682/0x3682/fut089/1:.* { json2nameValue($EVENT, '2_', $JSONMAP) }

genau kann ich jetzt nicht erklären wie das jetzt funktioniert hat.
Jetzt mach ich mich mal daran 2 Schalter zu erstellen die mit den Daten arbeiten können.
Bin über jede Unterstützung dafür dankbar.   :)

Brauch mal bitte Hilfe. Warum funktioniert das notify nicht ??

define MQTT2_milight_hub_7365307 MQTT2_DEVICE milight_hub_7365307
attr MQTT2_milight_hub_7365307 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_7365307 readingList milight_hub_7365307:milight/update/0x3698/0x3698/fut089/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }\
milight_hub_7365307:milight/state/0x3698/0x3698/fut089/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }\
milight_hub_7365307:milight/update/0x3682/0x3682/fut089/1:.* { json2nameValue($EVENT, '2_', $JSONMAP) }\
milight_hub_7365307:milight/state/0x3682/0x3682/fut089/1:.* { json2nameValue($EVENT, '2_', $JSONMAP) }
attr MQTT2_milight_hub_7365307 room MQTT2_DEVIC


define act_on_MiSwitch1 notify MQTT2_milight_hub_7365307  {\
    if(ReadingsVal("MQTT2_milight_hub_7365307", "1_state", "") eq "ON") { fhem("set HUEDevice2 dim 100;;");; }\
    elsif(ReadingsVal("MQTT2_milight_hub_7365307", "1_state", "") eq "OFF") { fhem("set HUEDevice2 dim 0;;");; }\
   }


gruß lucca

@Beta-User: Das neue Template für RGB-CCT Bulbs sieht super aus und funktioniert soweit.
Was mir nur aufgefallen ist:
- Ist es Absicht, dass die Werte bei Color_Temp von 153-370 gehen ?!
- Nach erstellen eines neuen Devices und festlegen des AttrTemplates am besten alle Slider einmal bewegen und ein shutdown restart machen, sonst springen die Slider immer wieder zurück auf 0. Nach dem restart ist das scheinbar kein Problem mehr.
- Warum auch immer wird bei mir aktuell der Wert für Brightness (wenn ich mir der Fernbedienung schalte) in FHEM nicht aktualisiert. Saturation und hue aktualisiert sich...
- Ist es möglich, das devStateIcon anzupassen, damit immer die aktuell gewählte Farbe angezeigt wird ? Bei mir ist das Icon weiß und bei 100% brightness färbt es sich orange.

Das ungetestete Template für CCT-only Bulbs passt für mich ganz genau und funktioniert auch. Für User, die einen Kaltweiß/Warmweiß Stripe an dem Controller betreiben müsste die color_Temp noch in das Template... Aber ich bin glücklich so, wie es ist.

@Snocksman:
Danke für's Testen. Habe eben eine leicht modifizierte Version (mit etwas mehr Optionen, kann man ja löschen) hochgeladen.
Die Temperaturwerte wurden mir hier zugerufen, nehme aber an, das ist valide. Wenn (evtl. je nach Bulb-Typ) andere Werte passen, kann ich das gerne in die Templates einfließen lassen (und/oder ins wiki).
Wenn Brightness vom ESP nicht übertragen wird, aktualisiert sich auch der Wert in FHEM nicht, am einfachsten ggf. mit mosquitto_sub oder den internen Optionen des MQTT2_SERVERs mitlesen, was auf dem MQTT-Server so ankommt.

Ob es einen Neustart braucht, weiß ich nicht mehr; kann sein, dass ein schlichtes Neuladen der Seite reicht.

@lucca111
Das sieht mir im ersten Moment nach einer klassichen notify-Frage aus, "vermutlich" paßt der Auslöser nicht. Bitte dazu am einfachsten mal im Wiki den notify-Artikel lesen, und ggf. dann einen neuen Thread dazu anfangen - diesen dann gerne hier verlinken, ist ja eine interessante Art, die FB zu nutzen.
Bitte dabei code zukünftig schöne verpacken (code-Tags ;) ).
Was ich allgemein überlegen würde:
- 3 input-devices anlegen (Bridge und je eines pro FB, JSON dabei ohne Prefix auspacken, siehe Praxisbeispiele im Wiki).
- Damit hast du eigentlich schon ein Format, das z.B. für zigbee2mqtt bereits weitestgehend passen würde (Einbindung der zu steuernden Devices?)
- Evtl böte es sich an, statt einzelner notify die Generic-Bridge zu verwenden und dann "nur" bei dem eigentlichen Ziel-Device die Ansteuerung über die MQTT-Infos zu machen.
Das klingt jetzt evtl. etwas kompliziert, aber da bekommst du bestimmt Hilfe auch von anderen, wenn du auch etwas rumspielst. So wie ich das verstanden habe, baut die Generic-Bridge eine eigenen Event-Handler auf, der dann im Zieldevice "das Richtige" tun kann. Dann hättest du aber "alles beieinander".
(Ich habe hier auch zwei zigbee2mqtt-Devices in "Milight-Nähe", die ich evtl. zum Teil mit den anderen steuern will, da könnte das auch passen - die Idee ist jedenfalls klasse!; es ist nur hier m.E. etwas "speziell"....)

Gruß, Beta-User

Hallo nochmal,

ich habe meine Milight-Schalter FUT087 jetzt folgendermaßen in FHEM mit MQTT2 erfolgreich einbinden können.
Ein Schalter habe ich da für meine Milight Warm-Weiss Küchen-Stripes und den anderen für eine Hue Warm-Weiss Lampe verwendet.

Nach dem automatische Create des MQTT2_milight_hub musste ich z.B. bei { json2nameValue($EVENT, '3_', $JSONMAP) }\ die "3" manuell setzen. Es wurde automatisch immer mit "1_" angelegt und somit haben die Readings nicht gestimmt. Also beim anlegen nochmal kontrollieren sonnst werden 2 oder mehr Geräte über ein Event angesprochen.

Natürlich kann man jetzt damit so gut wie alles in Fhem schalten. Ich habe die Schalter übrigens für günstige 7,- Euro beim China-Händler bekommen. Vielen dank nochmal für eure Unterstützung, ich bin begeistert von euren Forschergeist ::)

#########################################################################################
#                                                                                       #
#                                  MQTT2_MILIGHT-HUB                                    #
#                                                                                       #
#########################################################################################

define MQTT2_milight_hub_7365307 MQTT2_DEVICE milight_hub_7365307
attr MQTT2_milight_hub_7365307 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_7365307 readingList milight_hub_7365307:milight/update/0x3698/0x3698/fut089/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }\
milight_hub_7365307:milight/state/0x3698/0x3698/fut089/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }\
milight_hub_7365307:milight/update/0x3682/0x3682/fut089/1:.* { json2nameValue($EVENT, '2_', $JSONMAP) }\
milight_hub_7365307:milight/state/0x3682/0x3682/fut089/1:.* { json2nameValue($EVENT, '2_', $JSONMAP) }\
milight_hub_7365307:milight/update/0xC99/0xC99/rgbw/1:.* { json2nameValue($EVENT, '3_', $JSONMAP) }\
milight_hub_7365307:milight/state/0xC99/0xC99/rgbw/1:.* { json2nameValue($EVENT, '3_', $JSONMAP) }
attr MQTT2_milight_hub_7365307 room MI

#########################################################################################
#                                                                                       #
#                                MQTT2_MILIGHT-Switch1  FUT087                          #
#                                                                                       #
#########################################################################################

define act_on_MiSwitch1 notify MQTT2_milight_hub_7365307:1_brightness:.*|MQTT2_milight_hub_7365307:1_state:.* {\
if($EVENT eq "1_state: ON") { fhem("set Ki.Spots on");;;; }\
elsif($EVENT eq "1_state: OFF") { fhem("set Ki.Spots off");;;; }\
elsif($EVENT ne "1_state: ON" || $EVENT ne "1_state: OFF") {fhem("set Ki.Spots brightness $EVTPART1");;;; }\
}
attr act_on_MiSwitch1 room MI

#########################################################################################
#                                                                                       #
#                               MQTT2_MILIGHT-Switch2   FUT087                          #
#                                                                                       #
#########################################################################################

define act_on_MiSwitch2 notify MQTT2_milight_hub_7365307:2_brightness:.*|MQTT2_milight_hub_7365307:2_state:.* {\
if($EVENT eq "2_state: ON") { fhem("set HUEDevice1 toggle");;;; }\
elsif($EVENT eq "2_state: OFF") { fhem("set HUEDevice1 toggle");;;; }\
elsif($EVENT ne "2_state: ON" || $EVENT ne "2_state: OFF") {fhem("set HUEDevice1 bri $EVTPART1");;;; }\
}
attr act_on_MiSwitch2 room MI

#########################################################################################
#                                                                                       #
#                        MQTT2_MILIGHT-DEVICE-Kitchen-Spots  FUT038                     #
#                                                                                       #
#########################################################################################

define Ki.Spots MQTT2_DEVICE milight_0xc99_1
attr Ki.Spots IODev MQTT2_Broker
attr Ki.Spots devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr Ki.Spots eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Faster/mode_speed_down:Slower/level_up:Up/level_down:Down/
attr Ki.Spots group Licht
attr Ki.Spots icon light_control
attr Ki.Spots model X_01_esp_milight_hub_rgbw_bulb
attr Ki.Spots readingList milight/updates/0xc99/rgbw/1:.* { json2nameValue($EVENT) }\
milight/states/0xc99/rgbw/1:.* { json2nameValue($EVENT) }
attr Ki.Spots room MI
attr Ki.Spots setList on milight/0xc99/rgbw/1 {"status":"ON"}\
off milight/0xc99/rgbw/1 {"status":"OFF"}\
brightness:colorpicker,BRI,0,1,255 milight/0xc99/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht milight/0xc99/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
program:uzsuSelectRadio,Mode,Faster,Slower milight/0xc99/rgbw/1 {"command":"$EVTPART1"}\
mode:select,0,1,2,3,4,5,6,7,8 milight/0xc99/rgbw/1 {"$EVTPART0":"$EVTPART1"}
attr Ki.Spots verbose 5
attr Ki.Spots webCmd brightness:command:program:mode
attr Ki.Spots webCmdLabel Dim\
:Command\
:Program\
:Mode
attr Ki.Spots widgetOverride command:uzsuSelectRadio,Weiss,Nacht brightness:colorpicker,BRI,0,1,255


@lucca111,
schön, dass es jetzt klappt, aber warum hast du nicht wie vorgeschlagen das Bridge-template auf das "
MQTT2_milight_hub_7365307"-Device angewendet?

Das würde nach meinem Geschmack die Sache sehr vereinfachen, weil dann für jeden Kanal ein eigenes Device bereitsteht bzw. erstellt wird....

Ansonsten müßte es möglich sein, das ganze mit MQTT_GENERIC_BRIDGE zu lösen, also in etwa so: an der Milight-Fernbedienung die publish-Angaben so eintragen, dass diese mit den stopic-Angaben am HUE-Device zusammenpassen. Dann müßte sich das ohne notify usw. schalten lassen.

Verstehe ich nicht ganz hab das jetzt mal probiert komme aber nicht so richtig klar.
Habs nach Wiki gemacht!

1. Hub erstellen lassen mit autocreate
2.  template X_01_esp_milight_hub_bridge angewendet.
3.  nochmals das Leuchtmittel geschaltet  erstellt autocreate ein weiteres Device ???
     Klappt bei mir nicht, es wird nur im Hub zusätzlich als Device mit eingetragen
Sieht dann alles so aus wie in meinem vorigen Beitrag:

Wo finde ich dieMQTT_GENERIC_BRIDGE?

gruß lucca

Hmm,
also irgendwas ist bei Schritt 2 schiefgegangen oder du hast danach was gemacht, was nicht paßt. Sonst gäbe es da jetzt ein model-Attribut...

Würde auf nicht gespeichert vor Restart tippen ;) .
Und noch was: Editiere nicht in der cfg rum! Geht alles über die Web-Oberfläche und ist weniger fehleranfällig...

Gibt es eigentlich irgend eine Möglichkeit, für die Milight Devices voreingestellte Farben als webCmds anzulegen  (siehe Screenshot) ?

Zitat von: Snocksman am 31 Januar 2019, 19:16:13
Gibt es eigentlich irgend eine Möglichkeit, für die Milight Devices voreingestellte Farben als webCmds anzulegen  (siehe Screenshot) ?

Müßte schon gehen. Ansatzpunkt: https://wiki.fhem.de/wiki/Color#RGB_Farbe

Allerdings müßte dann entweder ein hue-Wert übergeben werden oder der RGB gesplittet, wenn die bridge das so braucht (?). (Vermutlich etwas komplexeren) Code dazu gäbe es dann eventuell bei dem template für die RGBW-Shellys (das wäre mein 2. Startpunkt).

Reicht dir das als Richtungsangabe? 

Ich hab mich mal Probiert, es aber nicht wirklich hinbekommen...  :-\
Ich habe mir jetzt einen Dummy angelegt und einige Notifys, welche dann bei Klick auf eine Farbe des Dummys die Werte hue, brightness & saturation des Milight Devices ändern. Wenn das jemand besser lösen konnte, bitte mal posten wie.
Dabei ist mir aber mal aufgefallen, dass der brightness Wert des angelegten Milight Devices nur in 15er Schritten änderbar ist (BRI,0,15,255)... Hat das einen Hintergrund ? Akzeptiert die Bridge nur 15er Schritte ?

Warum das mit der Schrittweite so ist, kann ich nicht genau sagen. Vermutlich hängt das aber damit zusammen, das in kleineren schritten auch viel mehr Ereignisse erzeugt werden, beim verstellen.

Mach mal eins, aktivier dir im milighthub die sniffing logausgabe.
Dann schnappst dir deine Fernbedienung und schaust dir dann live im log die Werte die die Fb sendet an.
In FHEM simulierst du dann nur noch diese Werte. Das was.

Wenn jetzt deine Fernbedienung und deine Lampen andere Werte, als die im FHEM Template nutzt, änderte die auf deine Umgebung ab.

Hab mal mit den beiden angegebenen Quellen ein wenig rumexperimentiert ;) .
Das scheint soweit grundsätzlich zu funktionieren, ist aber nicht vollständig ausgetestet oder aufgehübscht:
defmod milight_0xBE59_0 MQTT2_DEVICE milight_0xBE59_0
attr milight_0xBE59_0 IODev MQTT2_FHEM_Server
attr milight_0xBE59_0 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr milight_0xBE59_0 eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/
attr milight_0xBE59_0 group Licht
attr milight_0xBE59_0 icon light_control
attr milight_0xBE59_0 model X_01a_esp_milight_hub_make_rgbw_group
attr milight_0xBE59_0 readingList milight/states/0xBE59/rgbw/0:.* { json2nameValue($EVENT) }\
   milight/updates/0xBE59/rgbw/0:.* { json2nameValue($EVENT) }
attr milight_0xBE59_0 room MQTT2_DEVICE
attr milight_0xBE59_0 setList on milight/0xBE59/rgbw/0 {"status":"ON"}\
   off milight/0xBE59/rgbw/0_ID {"status":"OFF"}\
   brightness:colorpicker,BRI,0,15,255 milight/0xBE59/rgbw/0 {"$EVTPART0":"$EVTPART1"}\
   hue:colorpicker,HUE,0,1,359 milight/0xBE59/rgbw/0 {"$EVTPART0":"$EVTPART1"}\
   command:uzsuSelectRadio,Weiss,Nacht milight/0xBE59/rgbw/0 {"$EVTPART0":"$EVTPART1"}\
   helligkeit:colorpicker,BRI,0,15,255 {}\
rgb:colorpicker,RGB {my $helligkeit = ReadingsNum("milight_0xBE59_0","helligkeit","255");; $EVTPART1=~/(..)(..)(..)/;; "milight/0xBE59/rgbw/0 {\"status\":\"ON\",\"brightness\":\"".$helligkeit."\",\"color\":{\"r\":".hex($1).",\"g\":".hex($2).",\"b\":".hex($3)."}}"}
attr milight_0xBE59_0 setStateList on off
attr milight_0xBE59_0 webCmd brightness:hue:command:helligkeit:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffffff:on:off

Damit hat man die Option, über das Reading "helligkeit" eine Voreinstellung vorzunehmen, die dann allerdings erst greift, wenn man den RGB-Colorpicker oder die direkten Farbauswahlfelder verwendet (leider ging $name nicht, daher ist der Device-Name hartcodiert...).

Das mit den 15-er Schritten ist völlig willkürlich, da kann auch 1 stehen. Die derzeitige Voreistellung beruht auf meinen persönlichen Vorlieben; ich brauche schlicht nicht mehr. Es gibt auch nicht mehr Events, die zu verarbeiten wären, sondern immer nur eines, sobald man den Slider losläßt.

Moin Moin,

beschäftige mich jetzt seit ein paar Abenden mit dem MQTT2 Server und Milight Hub von Sidho, aber ich komme da jetzt einfach nicht weiter und bräuchte Hilfe.

Hier meine Hub config:
MQTT server 10.0.0.10:1883
MQTT topic pattern milight/:device_id/:device_type/:group_id/
MQTT update topic pattern milight/update/:hex_device_id/:device_id/:device_type/:group_id/
MQTT state topic pattern milight/state/:hex_device_id/:device_id/:device_type/:group_id/

In Fhem den MQTT2 Server/Broker definiert:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global

Danach wird der Server angelegt und sieht so aus:

Internals
CFGFN
DEF      1883 global
FD         15
FUUID    5c9d0603-f33f-2da0-c46f-a6d2afff9c69bc9e
NAME     MQTT2_FHEM_Server
NR         434
PORT     1883
STATE    Initialized
TYPE      MQTT2_SERVER

Readings
nrclients 1               2019-03-28 18:36:06
state      Initialized   2019-03-28 18:36:03

Nun weise ich dem Server das autocreate complex und verbose 5(damit man was sehen kann) zu.
Zusätzlich schiebe ich das ganze noch in den room MQTT2_SERVER.

Schon jetzt sehe im log dass, das Hub den Server anpingt.

2019.03.28 18:48:21 5: PINGREQ: (192)(0)
2019.03.28 18:48:21 4: MQTT2_FHEM_Server_10.0.0.37_49157 milight-hub-2412749 PINGREQ

Unter MQTT2_SERVER bei Everything taucht dann auf einmal ein neuer Server auf:

DeviceOverview
MQTT2_FHEM_Server_10.0.0.37_49157       Connected

Internals
BUF
FD                 21
NAME            MQTT2_FHEM_Server_10.0.0.37_49157
NR                438
PEER             10.0.0.37
PORT             49157
SNAME          MQTT2_FHEM_Server
SSL           
STATE           Connected
TEMPORARY  1
TYPE             MQTT2_SERVER
WBCallback
cflags            2
cid                milight-hub-2412749
keepalive      15
lastMsgTime 1553795571.65018
protoNum     4
protoTxt       MQTT

Readings
state            Connected   2019-03-28 18:36:06

Attributes
room            hidden      deleteattr

Wenn ich nun im WEBIF vom Hub meinen gepaarten Einbaustrahler einschalte, passiert folgendes im Log:
2019.03.28 18:59:17 5: PUBLISH: 08(0)'milight/update/0xABCD/0xABCD/rgb_cct/1/{"state":"OFF"}
2019.03.28 18:59:17 4: MQTT2_FHEM_Server_10.0.0.37_49157 milight-hub-2412749 PUBLISH milight/update/0xABCD/0xABCD/rgb_cct/1/:{"state":"OFF"}
2019.03.28 18:59:17 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000milight_hub_2412749\000milight/update/0xABCD/0xABCD/rgb_cct/1/\000{"state":"OFF"}
2019.03.28 18:59:18 2: autocreate: define MQTT2_milight_hub_2412749 MQTT2_DEVICE milight_hub_2412749
2019.03.28 18:59:18 2: autocreate: define FileLog_MQTT2_milight_hub_2412749 FileLog ./log/MQTT2_milight_hub_2412749-%Y.log MQTT2_milight_hub_2412749
2019.03.28 18:59:18 5: PUBLISH: 1(159)(1)(0)&milight/state/0xABCD/0xABCD/rgb_cct/1/{"state":"OFF","status":"OFF","color":{"r":255,"g":255,"b":255},"device_id":43981,"group_id":1,"device_type":"rgb_cct"}
2019.03.28 18:59:18 4: MQTT2_FHEM_Server_10.0.0.37_49157 milight-hub-2412749 PUBLISH milight/state/0xABCD/0xABCD/rgb_cct/1/:{"state":"OFF","status":"OFF","color":{"r":255,"g":255,"b":255},"device_id":43981,"group_id":1,"device_type":"rgb_cct"}
2019.03.28 18:59:18 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000milight_hub_2412749\000milight/state/0xABCD/0xABCD/rgb_cct/1/\000{"state":"OFF","status":"OFF","color":{"r":255,"g":255,"b":255},"device_id":43981,"group_id":1,"device_type":"rgb_cct"}

und es wurde ein MQTT2_DEVICE inkl. FileLog angelegt:
DeviceOverview
MQTT2_milight_hub_2412749     ???


Internals
CFGFN
CID                  milight_hub_2412749
DEF                milight_hub_2412749
DEVICETOPIC   MQTT2_milight_hub_2412749
FUUID             5c9d0b76-f33f-2da0-5745-1993d44fa1e6d7c7
IODev             MQTT2_FHEM_Server
NAME              MQTT2_milight_hub_2412749
NR                  488
STATE             ???
TYPE               MQTT2_DEVICE

Readings
1_color_b               255            2019-03-28 18:59:18
1_color_g               255            2019-03-28 18:59:18
1_color_r                255           2019-03-28 18:59:18
1_device_id            43981        2019-03-28 18:59:18
1_device_type        rgb_cct       2019-03-28 18:59:18
1_group_id            1                2019-03-28 18:59:18
1_state                  OFF            2019-03-28 18:59:18
1_status                OFF            2019-03-28 18:59:18

Attributes
IODev           MQTT2_FHEM_Server      deleteattr
readingList    milight_hub_2412749:milight/update/0xABCD/0xABCD/rgb_cct/1/:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
                    milight_hub_2412749:milight/state/0xABCD/0xABCD/rgb_cct/1/:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
deleteattr
room           MQTT2_DEVICE               deleteattr

Diesem Device / Hub weise ich dann das attrTemplate X_01_esp_milight_hub_bridge zu.

Hier erscheint dann ein POPUP welches mir mitteilt:
Replace
BASE_ID: with the BASE_ID typically is milight

BASE_ID ersetzte ich dann mit 0xABCD

Danach soll laut WIKI beim erneuten schalten ein weiteres Device angelegt werden, welches dann die BULB oder eben meinen Einbaustrahler wiederspiegelt und ich diesen dann entsprechend konfigurieren kann. Leider passiert dies aber nicht. Die Readings bei der angelegten Bridge ändern sich alle korrekt wenn ich am Hub über das WEBIF Änderungen der Farbe, Helligkeit etc durchführe. Würde gerne in der Lage sein über Fhem das ganze zu steuern und vielleicht ist es ja nur eine Kleinigkeit die ich falsch verstehe oder umgesetzt habe.

Freue mich auf eure Antworten.

Gruß

Sebastian

Fast richtig.

1. Complex ist hier nicht nötig, besser simple wählen. (Und so gesprächig braucht das ganze auch nicht zu sein)
2. BASE_ID ist tatsächlich "milight", nicht eine Bulb-ID (muß mir die regex in dem template mal ansehen)

Am einfachsten den Server auf simple umstellen und das Bridge-Gerät nochmal löschen, anlegen lassen und dann "milight" an der betreffenden Stelle einfügen, dann sollte es klappen.

Dass du ein weiteres temporäres Server-Gerät hast, ist normal, das werden ggf. noch mehr (für jeden Client eines).

Ich sehe mir das bei Gelegenheit mal an, es gab einige Verbesserungen, die Rudi da jüngst an verschiedenen Stellen reingebaut hat. Bin noch nicht dazu gekommen, die im Wiki und den templates vollst. zu verarbeiten. (Es darf sich gerne auch jemand anderes versuchen...)

Moin,

vielen dank für dein Feedback. Hab das Hub gelöscht, verbose beim Server auf 1 gestellt autocreate auf simple.

Einmal ON im WEBIF des Hubs, dann das Template zugewiesen und die BASE_ID als milight eingetragen. Danach alles fein gespeichert. Nun ein paar mal ON/OFF und Farbe etc im WEBIF vom Hub verändert und  dann die Fhem Seite aktualisiert.

Das Ergebnis siehst du im Anhang. Was ich feststellen konnte ist, das Beim State oben jetzt ein Lampen Symbol anstelle der drei ??? aufgetaucht ist.
Aber das wars auch schon, es ist kein Weiteres Device angelegt worden.

Log sieht wie folgt aus:

2019.03.29 20:53:25 2: autocreate: define MQTT2_milight_hub_2412749 MQTT2_DEVICE milight_hub_2412749
2019.03.29 20:53:25 2: autocreate: define FileLog_MQTT2_milight_hub_2412749 FileLog ./log/MQTT2_milight_hub_2412749-%Y.log MQTT2_milight_hub_2412749

Wie erstelle ich den jetzt meinen Strahler/Bulb? Habe es so verstanden das nach erstellen des hubs und zuweisen der template beim nächsten schalten die Lampen erzeugt werden. Oder müssen diese von Hand mit den Daten der Readings erstellt werden?

Vielen Dank im Voraus.

P.S: Tauche gerne tiefer in die Materie ein, und unterstütze auch gerne.

Hi,

lösch mal das

Zitatmilight_hub_2412749:milight/state/0xABCD/0xABCD/rgb_cct/1/:.* { json2nameValue($EVENT) }

aus dem readinglist der Bridge und schalte die Lampe erneut. Bin der Meinung das daraufhin das erwartete Device erstellt wird.

Gruß

Thomas

Moin,

habe ich gerade gelöscht, nach einmal schalten stand es wieder drin.

Klappt damit also nicht.

:-(

Moin,

könntest du im template-file das betreffende template suchen und so ändern:

name:X_01_esp_milight_hub_bridge
filter:TYPE=MQTT2_DEVICE
desc:use this with Chris Mullins ESP-Milight-Hub. for further details visit https://github.com/sidoh/esp8266_milight_hub <br>#recommended structure of the topic pattern milight/:device_id/:device_type/:group_id as set in the settings section in the bridge's web interface.
par:BASE_ID;BASE_ID typically is milight;{ AttrVal("DEVICE","readingList","") =~ m,[^:]+:?([^/]+)[/].*at[^/]+[/].*:, ? $1 : undef }
attr DEVICE bridgeRegexp BASE_ID/stat[^/]+[/]/(0x....)/.*/([0-4])?.*:.* "milight_$1_$2"
attr DEVICE autocreate 1
attr DEVICE setStateList on off
attr DEVICE model X_01_esp_milight_hub_bridge
Danach bitte { AttrTemplate_Initialize() } ausführen und von vorne beginnen, also das device nochmal löschen?

Du hattest keine Änderungen hinsichtlich der zu übertragenden Daten vorgenommen in der sidoh-firmware, oder?
(Im Prinzip sollte es genügen, "states" in der bridgeRegexp zu ändern, aber es wäre toll, wenn wir das gleich so hinbekämen, dass es paßt...)

Nach dem löschen musst FHEM Neustarten.
Danach schaltest deine Lampen per Fernbedienung.
Einmal ,,alle" und dann deine verwendeten Gruppen. (Die ein.- und Ausschalter auf deiner Fernbedienung oben und unten)

Moin Moin,
so viel Feedback, danke erstmal dafür.

Werde das heute Abend mal alles ganz in Ruhe testen.

Baue zur Zeit die neuen Fenster in unserem Sanierungsobjekt ein.
Von da her komme ich zum spielen immer nur Abends.

@DasQ, habe keine Fernbedienung, nur das Originale V6 und das Sidoh Hub.

Firmware habe ich im Sidoh Hub übrigens nicht angefasst.

Vielen Dank und bis heute Abend.

Gruß Sebastian

Guten Morgen,

hab es gestern Abend nicht mehr hinbekommen, war feucht fröhlich bei uns :-)

Habe das Device gelöscht... mqtt2.template unter /opt/fhem/FHEM/lib/AttrTemplate angepasst!

Danach { AttrTemplate_Initialize() } ausgeführt und fhem neu gestartet.
Nun im WEBIF vom Hub ALL eingeschaltet. Jetzt dem erstellten Device das Template zugewiesen.

Dann nur ON/OFF im WEBIF vom Hub für Gruppe 1.

Resultat anbei. Leider wurden keine neuen Devices angelegt. :-(


Gruß Sebastian

Edit: Hier nochmal meine Hub Settings
MQTT server
10.0.0.10:1883
MQTT topic pattern
milight/:device_id/:device_type/:group_id/
MQTT update topic pattern
milight/update/:hex_device_id/:device_id/:device_type/:group_id/
MQTT state topic pattern
milight/state/:hex_device_id/:device_id/:device_type/:group_id/

Hmmm,
also nach dem Wiki ist das update pattern in den Beispielen mit "s", das sollte aber egal sein.

Würde jetzt mal mit dem an den Start gehen.
milight/[^/]*at[^/]+[/](0x....)/.*/([0-4])?.*:.* "milight_$1_$2"Leider funktioniert irgendwie die Kommunikation zwischen der Bridge und FHEM grade bei mir nicht, ich habe eben die Versionen 1.9.0-dev9 (d1_mini) und -11 mal getestet, bekomme aber im Moment damit gar keine updates via MQTT...

Bei mir sind keine "/" am Ende der topic pattern, falls das was zu Sache beträgt.

also bei mir ist in der milighthub config nur einmal die deviceid drin (sollte zwar nix ausmachen aber der ordnung wegen doppelt und somit unnötig)

Zitat
MQTT server
10.0.0.10:1883
MQTT topic pattern
milight/:device_id/:device_type/:group_id/
MQTT update topic pattern
milight/update/:device_id/:device_type/:group_id/
MQTT state topic pattern
milight/state/:device_id/:device_type/:group_id/

und hier mal meine raw definition
die funktioniert bei mir, ich habe aber mehrere gruppen und fernbedienungen am laufen.

defmod Milight_hub MQTT2_DEVICE milight_hub_10693013
attr Milight_hub IODev MQTT2_Broker
attr Milight_hub autocreate 1
attr Milight_hub bridgeRegexp milight_hub_10693013:milight/states/(0x....)/.*/([0-4])?.*:.* "milight_$1_$2"
attr Milight_hub event-on-change-reading .*
attr Milight_hub model X_01_esp_milight_hub_bridge
attr Milight_hub readingList milight_hub_10693013:milight/updates/0x248C/rgb_cct/0:.* { json2nameValue($EVENT, '0_', $JSONMAP) }\
milight_hub_10693013:milight/updates/0x248C/rgb_cct/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }\
milight_hub_10693013:milight/updates/0x248C/rgb_cct/2:.* { json2nameValue($EVENT, '2_', $JSONMAP) }\
milight_hub_10693013:milight/updates/0x248C/rgb_cct/3:.* { json2nameValue($EVENT, '3_', $JSONMAP) }\
milight_hub_10693013:milight/updates/0x248C/rgb_cct/4:.* { json2nameValue($EVENT, '4_', $JSONMAP) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT, '0_', $JSONMAP) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/2:.* { json2nameValue($EVENT, '2_', $JSONMAP) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT, '3_', $JSONMAP) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/4:.* { json2nameValue($EVENT, '4_', $JSONMAP) }
attr Milight_hub room Hausgang
attr Milight_hub setStateList on off

setstate Milight_hub OFF
setstate Milight_hub 2019-03-28 06:19:02 0_brightness 240
setstate Milight_hub 2019-03-26 21:12:09 0_color_temp 324
setstate Milight_hub 2019-03-28 06:13:44 0_command night_mode
setstate Milight_hub 2019-03-28 00:41:38 0_hue 237
setstate Milight_hub 2019-03-01 18:57:47 0_mode 0
setstate Milight_hub 2019-03-28 20:36:25 0_saturation 0
setstate Milight_hub 2019-03-30 23:32:19 0_state OFF
setstate Milight_hub 2019-03-09 22:35:57 1_brightness 99
setstate Milight_hub 2019-03-26 21:11:44 1_color_temp 153
setstate Milight_hub 2019-03-30 22:44:43 1_command night_mode
setstate Milight_hub 2019-03-09 05:58:03 1_hue 49
setstate Milight_hub 2019-02-28 19:27:25 1_mode 0
setstate Milight_hub 2019-03-28 21:33:05 1_saturation 5
setstate Milight_hub 2019-03-30 22:44:43 1_state OFF
setstate Milight_hub 2019-03-29 06:00:53 2_brightness 56
setstate Milight_hub 2019-03-28 01:01:04 2_color_temp 316
setstate Milight_hub 2019-03-29 03:24:30 2_command night_mode
setstate Milight_hub 2019-03-29 03:30:19 2_hue 200
setstate Milight_hub 2019-02-28 17:41:14 2_mode 1
setstate Milight_hub 2019-03-28 20:36:13 2_saturation 94
setstate Milight_hub 2019-03-30 11:17:38 2_state OFF
setstate Milight_hub 2019-03-08 15:20:15 3_brightness 222
setstate Milight_hub 2019-03-08 15:20:15 3_color_temp 166
setstate Milight_hub 2019-02-14 03:50:34 3_command night_mode
setstate Milight_hub 2019-03-08 15:20:15 3_hue 95
setstate Milight_hub 2019-01-26 19:16:53 3_saturation 63
setstate Milight_hub 2019-02-28 17:40:31 3_state OFF
setstate Milight_hub 2019-03-07 18:30:11 4_brightness 0
setstate Milight_hub 2019-02-23 17:39:34 4_color_temp 153
setstate Milight_hub 2019-02-07 08:44:01 4_command night_mode
setstate Milight_hub 2019-03-07 18:30:15 4_hue 199
setstate Milight_hub 2019-02-07 08:53:58 4_saturation 9
setstate Milight_hub 2019-03-07 18:30:12 4_state ON
setstate Milight_hub 2019-01-05 11:59:27 saturation 21
setstate Milight_hub 2019-01-05 12:00:44 state OFF


Moin, komme gerade von der Baustelle und werde alle Anregungen gleich ausprobieren.

@DasQ readings erhalte ich ja auch ohne Ende, auch von den einzelnen Kanälen.

Wie sieht denn jetzt aber eine Fernbedienung im Fhem aus? Das ist ja mein Problem.
Das Hub im Fhem registriert jede Änderung die ich im WEBIF des Hubs vornehme, muss jetzt ja
auch irgendwie ein Device haben welches meine Gruppe darstellt und ich damit dann die
Gruppenteilnehmer steuern kann.

Gruß Sebastian

hast du mal unter MQTT2_DEVICE geschaut?

Zitat von: Beta-User am 31 März 2019, 13:54:33
Hmmm,
also nach dem Wiki ist das update pattern in den Beispielen mit "s", das sollte aber egal sein.

Würde jetzt mal mit dem an den Start gehen.

Code Auswählen Erweitern

milight/[^/]*at[^/]+[/](0x....)/.*/([0-4])?.*:.* "milight_$1_$2"Leider funktioniert irgendwie die Kommunikation zwischen der Bridge und FHEM grade bei mir nicht, ich habe eben die Versionen 1.9.0-dev9 (d1_mini) und -11 mal getestet, bekomme aber im Moment damit gar keine updates via MQTT...

Juhu,

jetzt wurde ein weiteres Device erstellt. Hab dem dann direkt mal gesagt das es ein rgb_cct bulb ist und siehe da es geht. kann jetzt über Fhem die Lampe steuern!

So, jetzt muss ich mich aber erstmal bedanken. Super Support 👍
Jetzt möchte ich aber auch wissen was ich da gemacht habe damit
es klappt. @Beta-User, warum geht es mit deiner Änderung bei mir und bei euch ohne diese Änderung?

Habe vorhin mal versucht das ganze in die Homebridge zu bekommen was leider nicht klappt. Ist da noch zuarbeit nötig?

Vielleicht mal zum eigentlichen Vorhaben.

Möchte die Milights FUT065 in die Bäder einbauen. Geschaltet werden Sie mit einem KNX Schaltaktor über einen MDT Glastaster Smart 2. Jetzt möchte ich dann aber die Farben auch ändern können, dazu soll dann über KNX der Farbwert vom Taster an Fhem via knxd und von dort dann über den mqtt Server an das Hub und schließlich zur Lampe. Natürlich soll das ganze auch die gute Siri können. Ein / Aus müsste allerdings gesperrt werden oder als knx Befehl umgemapped werden. Da sonst da sonst ja der Schaltaktor geschaltet ist und die Lampe selber aber aus ist.

Hoffe Ihr konntet mir folgen und habt vielleicht ein paar Anregungen.

Vielen Dank schon mal.

Gruß Sebastian

[OTon]
zu homebridge hast den raum "homekit" erstellt?
am gerät selbst, brauchts noch die attribute "genericDeviceType", den Room und "siriName"
die weitere zuordnung machst dann am besten über "eve" (app)
[OToff]

dann zu deim "zweiten OT problem"
klar, das kannst du so alles auch machen. die komplexität erfordert aber ne ganze stange mehr informationen.
ich habs leider aus faulheit noch nicht geschafft die milights über siri weiter zu steueern als nur an und aus zu schalten oder stimmungen zu ändern. aber man muss sich im klaren sein, dass die sprach steuerung nur bedingt mit der sehr feinen manuellen steuerung vergleichen kann.

ich schalt mit sonoff touch t1 2gang die lampen quasi immer doppelt. einmal hart mit dem internen relais und danach per funk die blub`s.

das ganze geht per notify und/oder DOIF

[OT]@Sebastian J:
Meine einleitenden kritischen Anmerkungen im ersten Beitrag hier zu MiLight an sich hast du wahrgenommen? (Nimm lieber zigbee-Material!)[/OT]

Zitat von: Sebastian J am 01 April 2019, 22:53:21
Jetzt möchte ich aber auch wissen was ich da gemacht habe damit
es klappt. @Beta-User, warum geht es mit deiner Änderung bei mir und bei euch ohne diese Änderung?

Die meisten hier dürften "schon länger" (ggf. seit der "Modul"-Fassung) dabei sein und nutzen daher eventuell etwas andere Einstellungen für die Topic-Struktur als den heutigen default, den sidoh vorsieht. Eventuell hast du auch was geändert (die "/" am Ende finden sich jedenfalls nicht im Wiki von sidoh).

Da du den Unterschied selbst nicht siehst, wäre meine Empfehlung, dich mal mit regex zu beschäftigen, das ist eigentlich im ganzen FHEM-Umfeld sehr hilfreich, z.B. mit http://regex101.com/ oder https://regexone.com/.
Das template ist ziemlich am Anfang aller templates entstanden auf Basis meiner topic-Struktur, und die nutzt eben "updates" und "states" =".*ates"
Zwischenzeitlich habe ich damit etwas mehr Erfahrung, also heißt das jetzt "mind. ein Zeichen, aber kein /, dann 'at', zuletzt wieder mind. ein Zeichen, aber kein /"...

Kommt bei Gelegenheit via update.

Hallo zusammen,

da Sidoh in dem aktuellen release candidate wieder ein paar nette features eingebaut hat und Rudi bei den SetExtension, gab's einen update des Bridge-Templates und der rgbw-Birne.
Insbesondere ist ein farbiges devStateIcon mit Anzeige laufender Timer eingebaut, siehe https://forum.fhem.de/index.php/topic,99957.0.html.

Wenn jemand das für die anderen (getestet) liefert, bau' ich's gerne auch in die anderen templates vollends ein :) .

Wie immer viel Spaß damit...

so weiter im text.

hab ich versucht und bekomms nicht hin.
an meiner milight remote sind ja 4 gruppen und 2 davon nutz ich nicht. bei diesen zwei habe ich versucht das neue template zu testen.
also erstmal device gelöscht, neu angelegt und dann das template "model X_01_esp_milight_hub_rgbw_bulb" wie in deinem beispiel zugewiesen.

Zitat von: Beta-User am 26 April 2019, 09:34:20

Für "nur Farbe" wäre das so:

Code Auswählen Erweitern

attr Licht_Spuele devStateIcon {zigbee2mqtt_devStateIcon255($name,'hex')}

Das ganze sollte auch mit "einfachen" on/off"-Geräten funktionieren, die gar kein RGB-Reading haben:

Code Auswählen Erweitern

attr Beispielgeraet devStateIcon {zigbee2mqtt_devStateIcon255($name,'',1)}

dann das,
attr Licht_Spuele devStateIcon {zigbee2mqtt_devStateIcon255($name,"hex",1)}
auf ohne ",1" geändert, wobei bei mir hex in gänsefüsschen stand also "hex" (hab ich auch zu testzwecken auf ' geändert).
aber leider ändert sich da keine farbeam icon. helligkeit wird angezeigt.

defmod MQTT2_milight_0x5D02_3 MQTT2_DEVICE milight_0x5D02_3
attr MQTT2_milight_0x5D02_3 IODev MQTT2_Broker
attr MQTT2_milight_0x5D02_3 devStateIcon {zigbee2mqtt_devStateIcon255($name,'hex')}
attr MQTT2_milight_0x5D02_3 eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/
attr MQTT2_milight_0x5D02_3 icon light_control
attr MQTT2_milight_0x5D02_3 model X_01_esp_milight_hub_rgbw_bulb
attr MQTT2_milight_0x5D02_3 readingList milight/states/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }\
  milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
  milight/updates/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }\
  milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
attr MQTT2_milight_0x5D02_3 room MQTT2_DEVICE
attr MQTT2_milight_0x5D02_3 setExtensionsEvent 1
attr MQTT2_milight_0x5D02_3 setList on milight/0x5D02/rgb_cct/3 {"status":"ON"}\
  off milight/0x5D02/rgb_cct/3 {"status":"OFF"}\
  brightness:colorpicker,BRI,0,15,255 milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}\
  hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}\
  command:uzsuSelectRadio,Weiss,Nacht milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}
attr MQTT2_milight_0x5D02_3 setStateList on off
attr MQTT2_milight_0x5D02_3 userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
attr MQTT2_milight_0x5D02_3 webCmd brightness:hue:command

setstate MQTT2_milight_0x5D02_3 ON
setstate MQTT2_milight_0x5D02_3 2019-05-04 10:38:33 associatedWith Milight_hub
setstate MQTT2_milight_0x5D02_3 2019-05-04 10:41:05 brightness 194
setstate MQTT2_milight_0x5D02_3 2019-05-04 10:41:05 device_id 23810
setstate MQTT2_milight_0x5D02_3 2019-05-04 10:41:05 device_type rgb_cct
setstate MQTT2_milight_0x5D02_3 2019-05-04 10:41:05 group_id 3
setstate MQTT2_milight_0x5D02_3 2019-05-04 10:41:05 hue 246
setstate MQTT2_milight_0x5D02_3 2019-05-04 10:41:05 saturation 73
setstate MQTT2_milight_0x5D02_3 2019-05-04 10:41:05 state ON


Internals:
   CFGFN     
   CID        milight_0x5D02_3
   DEF        milight_0x5D02_3
   DEVICETOPIC MQTT2_milight_0x5D02_3
   FUUID      5ccd4f89-f33f-9f3d-43f1-6362210055ce8582
   IODev      MQTT2_Broker
   LASTInputDev MQTT2_Broker
   MQTT2_Broker_MSGCNT 33
   MQTT2_Broker_TIME 2019-05-04 10:48:38
   MSGCNT     33
   NAME       MQTT2_milight_0x5D02_3
   NR         2085
   STATE      ON
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-05-04 10:38:33   associatedWith  Milight_hub
     2019-05-04 10:48:37   brightness      150
     2019-05-04 10:48:37   device_id       23810
     2019-05-04 10:48:37   device_type     rgb_cct
     2019-05-04 10:48:37   group_id        3
     2019-05-04 10:48:37   hue             244
     2019-05-04 10:48:37   saturation      73
     2019-05-04 10:48:37   state           ON
Attributes:
   IODev      MQTT2_Broker
   devStateIcon {zigbee2mqtt_devStateIcon255($name,'hex')}
   eventMap   /set_white:Weiss/night_mode:Nacht/white_mode:white/
   icon       light_control
   model      X_01_esp_milight_hub_rgbw_bulb
   readingList milight/states/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }
  milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
  milight/updates/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }
  milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setExtensionsEvent 1
   setList    on milight/0x5D02/rgb_cct/3 {"status":"ON"}
  off milight/0x5D02/rgb_cct/3 {"status":"OFF"}
  brightness:colorpicker,BRI,0,15,255 milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}
  hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}
  command:uzsuSelectRadio,Weiss,Nacht milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}
   setStateList on off
   userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
   webCmd     brightness:hue:command


wo ist mein denkfehler :o



***[edit] denkfehler gefunden.

du hast RGB werte als reading ... ich nicht.
da muss man wohl noch das hier umstricken.
attr Licht_Spuele userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}

Zum Umwandeln in "hex": Es gibt in Color.pm ein paar Funktionen, um Werte zwischen den Farbräumen zu wandeln. Vielleicht findest du da das passende.
(Ich habe einfach das Senden der Farben im hub aktiviert...)

Zitat von: Beta-User am 04 Mai 2019, 11:29:19
(Ich habe einfach das Senden der Farben im hub aktiviert...)

das wars

defmod MQTT2_milight_0x5D02_3 MQTT2_DEVICE milight_0x5D02_3
attr MQTT2_milight_0x5D02_3 IODev MQTT2_Broker
attr MQTT2_milight_0x5D02_3 devStateIcon {zigbee2mqtt_devStateIcon255($name,'hex',1)}
attr MQTT2_milight_0x5D02_3 eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/
attr MQTT2_milight_0x5D02_3 icon light_control
attr MQTT2_milight_0x5D02_3 model X_01_esp_milight_hub_rgbw_bulb
attr MQTT2_milight_0x5D02_3 readingList milight/states/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }\
  milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
  milight/updates/0x5D02/rgb_cct/3:.* { json2nameValue($EVENT) }\
  milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }
attr MQTT2_milight_0x5D02_3 room MQTT2_DEVICE
attr MQTT2_milight_0x5D02_3 setExtensionsEvent 1
attr MQTT2_milight_0x5D02_3 setList on milight/0x5D02/rgb_cct/3 {"status":"ON"}\
  off milight/0x5D02/rgb_cct/3 {"status":"OFF"}\
  brightness:colorpicker,BRI,0,15,255 milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}\
  hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}\
  color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}\
  saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}\
  command:uzsuSelectRadio,Weiss,Nacht milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}\
  program:uzsuSelectRadio,Mode,Faster,Slower milight/0x5D02/rgb_cct/3 {"command":"$EVTPART1"}\
  mode:select,0,1,2,3,4,5,6,7,8 milight/0x5D02/rgb_cct/3 {"$EVTPART0":"$EVTPART1"}\
  dim:uzsuSelectRadio,Up,Down milight/0x5D02/rgb_cct/3 {"command":"$EVTPART1"}
attr MQTT2_milight_0x5D02_3 setStateList on off
attr MQTT2_milight_0x5D02_3 userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
attr MQTT2_milight_0x5D02_3 webCmd on:off:brightness:dim:hue:command:color_temp:program:saturation:mode
attr MQTT2_milight_0x5D02_3 webCmdLabel An:Aus\
  :Helligkeit:Dimmen\
  :HUE:Command\
  :Farb-Temp:Programm\
  :Sättigung:Modus

setstate MQTT2_milight_0x5D02_3 ON
setstate MQTT2_milight_0x5D02_3 2019-05-04 10:38:33 associatedWith Milight_hub
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 brightness 150
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 color_b 255
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 color_g 145
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 color_r 194
setstate MQTT2_milight_0x5D02_3 2019-05-04 10:58:30 color_temp 281
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 device_id 23810
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 device_type rgb_cct
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 group_id 3
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 hex C291FF
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 hue 267
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:21 mode 0
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 saturation 43
setstate MQTT2_milight_0x5D02_3 2019-05-04 12:16:25 state ON



Zitat von: DasQ am 04 Mai 2019, 12:17:32
das wars

Schön, dass das geklappt hat!

Dann könnte ich das als Basis für das "full-featured" nehmen, oder?
(Und im Wiki den Hinweis einfügen, dass man das Senden der Farben aktivieren sollte...)

Moin,

auch nach Monaten und zwischenzeitlich auch auf einer neuen Installation ist es mir bisher nicht gelungen meinen Milight-Bulb problemlos einzubinden wie es mit WifiLight bisher möglich ist. Nur manchmal reagiert der Bulb sofort meist aber erst bei mehrfachem ausführen des on Befehls, ist er erst mal an lassen sich auch alle anderen Befehle i.d.R. ausführen (klappt aber auch nicht immer). Bin da nichts so in der Materie drin aber in der Bridge sehe ich wenn ich die Möglichkeit des sniffen nutze das die vom MQTT2-Device gesendeten RGBW-Pakete immer einmal ankommen, zum Vergleich die RGBW-Pakete des WifiLight-Device dagegen immer drei mal. Das wäre für mich eine mögliche Ursache des Problems.

Hat mir jemand einen Tip wie ich das in den Griff bekommen kann und scheinbar nur ich diese Probleme habe ?

defmod MQTT2_Mi_Wecklicht MQTT2_DEVICE milight_0x8D56_1
attr MQTT2_Mi_Wecklicht IODev MQTT2_Server
attr MQTT2_Mi_Wecklicht devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_Mi_Wecklicht eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Faster/mode_speed_down:Slower/level_up:Up/level_down:Down/
attr MQTT2_Mi_Wecklicht group Wohnzimmer
attr MQTT2_Mi_Wecklicht icon light_control
attr MQTT2_Mi_Wecklicht model X_01_esp_milight_hub_rgbw_bulb
attr MQTT2_Mi_Wecklicht readingList milight/states/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }\
  milight/states/0x8D56/rgbw/0:.* { json2nameValue($EVENT) }\
  milight/updates/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }\
  milight/updates/0x8D56/rgbw/0:.* { json2nameValue($EVENT) }
attr MQTT2_Mi_Wecklicht room MQTT2_DEVICE
attr MQTT2_Mi_Wecklicht setList on milight/0x8D56/rgbw/1 {"status":"ON"}\
off milight/0x8D56/rgbw/1 {"status":"OFF"}\
brightness:colorpicker,BRI,0,15,255 milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}
attr MQTT2_Mi_Wecklicht setStateList on off
attr MQTT2_Mi_Wecklicht webCmd brightness:hue:command:on
attr MQTT2_Mi_Wecklicht webCmdLabel An:Aus\
  :Helligkeit:Dimmen\
  :HUE:Command\
  :Farb-Temp:Programm\
  :Sättigung:Modus

setstate MQTT2_Mi_Wecklicht on
setstate MQTT2_Mi_Wecklicht 2019-05-05 09:20:09 brightness 255
setstate MQTT2_Mi_Wecklicht 2019-04-07 23:16:22 command set_white
setstate MQTT2_Mi_Wecklicht 2019-05-05 09:20:09 hue 120
setstate MQTT2_Mi_Wecklicht 2019-05-05 08:56:28 state ON



Gruß

Thomas

kurze zwischenfragen, wie ist denn deine örtliche gegebenheit? wie weit ist empfänger und sender auseinander?
ist ein Wlan Accesspoint im einsatz? und wenn ja wo steht der?

Die örtliche Gegebenheit ist die gleiche wie mit Wifilight  ;D. damit funzt alles ohne Probleme seit Umstellung auf die Sidoh-Bridge (rd. 1 1/2 Jahre jetzt) , 5 m durch zwei Wände zum AP der per Lan versorgt wird.

Hmm, wenn die identische Hardware ("gleichzeitig") verwendet wird, würde ich mal darauf tippen, dass wifilight ggf. per UDP gleich einige Repeats anstößt (hermannj fragen?).

Es gibt im Hub ein setting für Radio mit der Wiederholrate. Ich habe das glaube ich auch etwas hochgedreht, weiß aber nicht mehr, welcher der Parameter es war.

Danke für die Rückmeldungen.

Das erste was ich gemacht habe war Packet repeat minimum -das default auf 3 steht und naheliegend war das mal zu ändern- mal auf 5 zu ändern. Keine Auswirkung, die Pakete werden genauso wiederholt wie vorher bei WifiLight (3x) und bei dem MQTT2-Device (1x).

Dann Packet repeats von default 10 testweise auf 20.  :) sieht vielversprechend aus. Beim sniffen in der Bridge sieht man aber auch hier keine Änderung zu vorher WifiLight (3x) und bei dem MQTT2-Device (1x).

Seltsam das die Einstellungen bei beiden Änderungen nicht beim sniffen zu sehen sind da steht ja schließlich Traffic sniffed (sent and received).

Glücklich bin ich auf jedenfall jetzt schon, zufrieden aber erst wenn wie immer heute Abend und in Zukunft das Dekolicht mal endlich zuverlässig über MQTT2 eingeschaltet wird und die Wifilight-Definition eventuell mal endlich Geschichte wird   :P


edit:

nur mal so auch mit einem update von 1.8.5 (d1_mini) auf 1.8.8 (d1_mini) sieht man die vorgenommen Einstellungen zu den Wiederholungen nicht beim sniffen bei WifiLight wie auch MQTT2-DEVICE, vlt. versteh ich da auch was falsch, wie auch immer
mit Packet repeats 20 siehts erstmal super aus.

also ich war auch erst der meinung du würfelst da was durcheinander.

also mal grundsätzlich: Mqtt ist netzwerkseitig ein Protokoll. das hat mal rein garnix mit dem 2,4ghz band des NRF zu tun.

Wenn du also im MilightHub auf Sniffen klickst, Sniffst du die 2,4ghz funksignale. Nicht aber den Netzwerktraffic oder gar Mqtt.

Wenn jetzt Fhem via Mqtt ein Signal an den Milighthub triggert, löst das wiederum im Milighthub eine funktion aus die wiederum Per funk an die Blubs sendet. (ich hoff ich habe es halbwechs vernünftig und fehlerfrei laienhaft erklärt).

Da funk immer so ne "oneway" geschichte (broadcast-call) ist, also einer sprich und hofft drauf das jemand zuhört. wird eben so widerholungstechnik angewand und signale einfach mehrfach gesendet. Dieses mehrfachsenden der fernbedinung dürfte aber daher kommen das die tasten "prellen", sprich du schafst es garnicht so schnell von der taste runter zu kommen das sie einfach mehrfach gedrückt wird.

die ganze milightgeschichte hat viele ecken und kanten, aber dafür ist sie billig.  ;)

  :) :) :)

Mein Dekolicht wurde heute Abend geschalten.

Allerdings schon mit einem Packet repeats Wert von 14 den ich heute Nachmittag rein aus Interesse durch ausprobieren als Minimum bei mir festgestellt habe.

Ich habe vor der MQTT2 Lösung meine Milights mit einer selbstgebastelten Milight Bridge gesteuert. Da gab es einen Syntax,
wenn ich mich recht entsinne


set LEDBeleuchtungFernseher RGB A6007A 5


damit ist dann die Milight innerhalb von 5 Sekunden hochgedimmt. Geht das mit der SIDOH/MQTT2 Lösung auch?
Ich finde den Effekt sehr viel angenehmer als wenn die LEDs "paff" alle schlagartig angehen...

Zitat von: Heimweh am 06 Juni 2019, 10:27:57
[...]damit ist dann die Milight innerhalb von 5 Sekunden hochgedimmt. Geht das mit der SIDOH/MQTT2 Lösung auch?
Ich finde den Effekt sehr viel angenehmer als wenn die LEDs "paff" alle schlagartig angehen...

Im Prinzip: Jein....

Full story:
- Die Bridge kann das (noch) nicht verwalten, siehe https://github.com/sidoh/esp8266_milight_hub/issues/113, da müßte sich also jemand dran machen, dafür einen patch zu liefern. Kurz: Alle Kommandos werden direkt rausgesandt, wie sie ankommen.
- Bisher hast du vermutlich dafür WiFiLight genutzt. Das verwaltet die Transitions intern, sendet also (via UDP) jeweils den nächsten step auf dem Weg zum Ziel. Das kannst du (im Prinzip) auch weiter parallel nutzen, die per UDP angewiesenen Befehle sollten auch wieder auf dem MQTT-Weg als Info in den MQTT2-Devices landen.

- Die andere Option ist, dafür selbst den Perl-Code zu schreiben und das z.B. in ein weiteres setList-Element reinzupacken. Als Bausteine würden sich anbieten:
-- der vorhandene Code aus WiFiLight (ich nehme an, der Autor würde dabei unterstützen, das generischer verfügbar zu machen;
-- alternativ: Es gibt diverse "Sonnenaufgangs-Farbverlaufs-Threads", aus denen man sich bedienen kann
Ergebnis => eigene myUtils (wäre mein Vorschlag)

-- A_15_shellybulb: Da ist ein Beispiel, wie man über die setList Perl-Code aufrufen kann.

Insgesamt ist das aber m.E. ein Thema, das man von hier auslagern könnte. Wenn, sollte man das so lösen, dass das Ergebnis z.B. auch mit den Shelly-RGB-Bulbs (und/oder tasmota) "kann".

Ja Du hast recht, Wifilight konnte das und hat das dimmen "intern" übernommen.

Wenn ich so darüber nachdenke, ich bin von Wifilight auf sie Sidoh Lösung umgestiegen weil ich das CCT Protokoll gebraucht habe.
Und vermutlich, würde ich jetzt Wifilight verwenden zusätzlich zu Deiner Template Lösung - würde das keine saubere Lösung sein. Und auch nur für das alte Protokoll von Milight.

Danke für Deine Ansätze, ich beschäftige mich mal weiter mit diesem Thema.

Hallo Beta-User,

ich stehe erneut vor einer Frage... Ich habe mit meinen Milights nun eine Lichtszene erstellt.

Der Befehl um eine Lampe einzuschalten wird klein geschrieben, also so:


set Lampe on


Im State steht das on dann aber gross geschrieben, also "ON". Wenn ich nun alle Lampen so einstelle wie ich es in einer Szene gerne hätte,
dann gibt es dort mit "SAVE" die Möglichkeit, den eingestellten Zustand der Lampen einzulesen und als Szene abzuspeichern.
Dummerweise zieht das Lichtszenen Modul aber den State als "ON" und nicht als "on" (eigentlich ja auch logisch), ABER
wenn ich nun Szenen wechseln will, sendet er den Befehl auch (wie abgespeichert) in gross - also "set Lampe ON" - und damit
kommt die Milight nicht klar, ich bekomme ein unknown Argument.

Ich habe nun das Attribut "setlist" angepasst, also das große "ON" auf "on" geändert, nur zeigt sich keine Wirkung.
Was muss ich anpassen damit alles klein geschrieben ist?

Hier noch das list der Lampe:


Internals:
   CID        milight_0x15B1_2
   DEF        milight_0x15B1_2
   DEVICETOPIC MQTT2_milight_0x15B1_2
   FUUID      5cf6b120-f33f-55ed-97a1-d4277d4f57a2b4b3
   IODev      MQTTServer
   NAME       MQTT2_milight_0x15B1_2
   NR         559
   STATE      OFF
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-06-04 17:57:52   associatedWith  MQTT2_milight_hub_317564
     2019-06-07 12:16:23   brightness      214
     2019-06-07 12:16:23   bulb_mode       color
     2019-06-06 20:21:18   color_b         255
     2019-06-06 20:21:18   color_g         255
     2019-06-07 12:16:23   color_r         0
     2019-06-06 21:10:46   command         night_mode
     2019-06-06 20:21:18   device_id       5553
     2019-06-06 20:21:18   effect          night_mode
     2019-06-07 12:16:23   hex             00FFFF
     2019-06-07 12:16:23   hue             126
     2019-06-07 12:16:23   level           84
     2019-06-06 20:20:45   mode            0
     2019-06-07 12:16:23   state           OFF
     2019-06-07 12:16:23   status          OFF
Attributes:
   IODev      MQTTServer
   alexaName  Fernsehbeleuchtung
   alias      Milight_TV
   devStateIcon {zigbee2mqtt_devStateIcon255($name,"hex",1)}
   eventMap   /set_white:Weiss/night_mode:Nacht/white_mode:white/
   genericDeviceType light
   homebridgeMapping Brightness=brightness::brightness,minValue=0,maxValue=100,max=255
   icon       light_control
   lightSceneParamsToSave brightness,hue,state
   model      X_01_esp_milight_hub_rgbw_bulb
   readingList milight/states/0x15B1/rgbw/2:.* { json2nameValue($EVENT) }
  milight/states/0x15B1/rgbw/0:.* { json2nameValue($EVENT) }
  milight/updates/0x15B1/rgbw/2:.* { json2nameValue($EVENT) }
  milight/updates/0x15B1/rgbw/0:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE,alexa
   setExtensionsEvent 1
   setList    on milight/0x15B1/rgbw/2 {"status":"on"}
  off milight/0x15B1/rgbw/2 {"status":"off"}
  brightness:colorpicker,BRI,0,15,255 milight/0x15B1/rgbw/2 {"$EVTPART0":"$EVTPART1"}
  hue:colorpicker,HUE,0,1,359 milight/0x15B1/rgbw/2 {"$EVTPART0":"$EVTPART1"}
  command:uzsuSelectRadio,Weiss,Nacht milight/0x15B1/rgbw/2 {"$EVTPART0":"$EVTPART1"}
   setStateList on off
   userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
   userattr   lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
   webCmd     brightness:hue:command



Hmmm, also:

Mit lightscene habe ich noch keine Erfahrung, kann daher erst mal nur etwas "graue Theorie" liefern in der Hoffnung, dass du damit klarkommst...

M.E. gibt es zwei Ansatzpunkte, die wir selber in der Hand haben.
Zum einen könnten wir versuchen, "state" zu manipulieren. Dafür gibt es zum einen eventMap (in etwa so: { 'ON'=>'on','OFF'=>'off'}). Kann sein, dass diese Art "Kosmetik" schon reicht. Etwas tiefergreifend wäre, das mit einem userreadings-Eintrag zu machen, der auf state.(ON|OFF) triggert und dann lc (vermutlich von $EVTPART1) zurückliefert.

Oder eben sendeseitig (was durch obige eventMap ggf. auch abgefangen wird), indem man weitere Einträge mit ON und OFF zur setList hinzufügt.

Die dritte Option wäre, sidoh zu überreden, die on/off-Zustände konfigurierbar zu machen (wie bei Tasmota), damit wir dort auf Kleinschreibung umstellen können :) . Das wäre das einfachste...

Danke Dir!

eventMap hat nicht geklappt, aber dafür Setlist erweitern. Ich hatte jetzt nicht viel Zeit zum testen aber ich kann
mit


set lampe on


UND


set lampe ON


einschalten... Die Lichtszene ist eine tolle Sache, btw. Erstmal ein schönes WE und Danke!

Hallo Beta-User,

ich bin immer noch am tüfteln. Gestern habe ich mein Bett mit 2 Bewegungsmeldern ausgestattet, die ein LED Band (Milight Controller) ansteuern sollen. Auch hier habe ich
das gleiche "Problem" wie mit der Alexa Steuerung:

Wenn ich z.B. volle Helligkeit angesteuert habe und die Milight abschalte, bleibt die Helligkeit ja im Device gespeichert. Bei einem weiterem "On" Befehl" geht die Milight auf die
zuvor eingestellte Helligkeit (in meinem Beispiel) von 100%.
Wenn ich aber nun, sei es durch die Bewegungsmelder oder die Alexa, die Milights nur mit z.B. 20% einschalten will - geht das ja nicht. Ich müsste erst einen on Befehl senden (Milight geht auf 100%) und dann die Brightness auf 20% reduzieren richtig? Das ist in meinem Fall nicht erwünscht, ich würde gerne gleich mit 20% einschalten.
Ich habe auch schon überlegt, die Milights nicht auszuschalten, sondern auf 0% zu dimmen, und sie dann auf 20% hochziehen - nur sind die Milights bei 0% Brightness nicht aus sondern leuchten
ganz schwach....


Hast Du mir vielleicht einen Gedankenanstoß?

Mobile Kurzfassung: den on-Befehl mit in den brightness-json packen?

Hat mich auch interessiert, funzt. DANKE

brightness:colorpicker,BRI,0,15,255 milight/0x8D56/rgbw/1 {"status":"ON","$EVTPART0":"$EVTPART1"}

Zitat von: TomLee am 22 Juni 2019, 15:08:58
Hat mich auch interessiert, funzt. DANKE

Code Auswählen Erweitern

brightness:colorpicker,BRI,0,15,255 milight/0x8D56/rgbw/1 {"status":"ON","$EVTPART0":"$EVTPART1"}

Dank zurück für's "übersetzen".

Habe eben ein update ins svn geschubst, in der das via comment erläutert ist. Gibt natärlich wie immer viele Optionen, z.B. auch ein eigenes setList-Element mit einem fixen brightness-Wert usw..

Danke :) Funzt bei mir auch, allerding mit einem kurzem "flash" beim einschalten. Ich habe mit Brightness 255 abgeschaltet, und
dann mit dem Beispiel von TomLee mit Brightness 30 eingeschaltet. Die Lampe wollte schon auf volle Helligkeit und ist dann schnell runter auf 30.

Im Prinzip schon ein sehr guter Ansatz, aber ich befürchte dieser Blitz reicht um meine Frau aufzuwecken...

Jörg, was meintest Du mit eigenen setlist-Elementen?

Oh ja, das geht gar nicht. Hat ich am Tag nicht gesehen, die Leuchte ist auch noch in einer Milchglaskugel.

Hardwaremäßig scheint es ja nicht anders möglich - aber vielleicht würde es funktionieren die Milights vor dem ausschalten auf 0% zu dimmen und dann abzuschalten,
und beim einschalten wieder "on" und "brightness XXX"?

Ich habe mal den Autor vom Wifilight Modul gefragt ob man den Code für rauf und runterdimmen nicht extrahieren kann
(wenn ich mich recht erinnere ging das da, also "on" und auf die gewünschte Helligkeit fahren),
aber das ist wohl der komplizierteste Teil des Moduls und nicht so einfach - und würde sowieso meine Fähigkeiten überschreiten....

Zu dem dim-on-Thema: Auch mit einer Fernbedienung muß man erst einschalten, bevor die Bulbs auf andere Befehle hören. Ergo wird man wohl den "flash" nur durch Dimmen vor dem Ausschalten vermeiden können.

Was das zusätzliche setList-Element angeht, hier zwei Beispiele:
...
brightness:colorpicker,BRI,0,15,255 milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}
brightness_on:colorpicker,BRI,0,15,255 milight/0x8D56/rgbw/1 {"status":"ON","brightness":"$EVTPART1"}
brightness_35:colorpicker,BRI,0,15,255 milight/0x8D56/rgbw/1 {"status":"ON","brightness":"35"}...

Gruß, Beta-User

Zitat von: Heimweh am 22 Juni 2019, 22:59:11
Ich habe mal den Autor vom Wifilight Modul gefragt ob man den Code für rauf und runterdimmen nicht extrahieren kann
(wenn ich mich recht erinnere ging das da, also "on" und auf die gewünschte Helligkeit fahren),
aber das ist wohl der komplizierteste Teil des Moduls und nicht so einfach - und würde sowieso meine Fähigkeiten überschreiten....

Moin, ja - lese hier mit.

Zum Blitz:) In WifiLight mach ich das tatsächlich so, beim Ausschalten gleichzeitig Helligkeit 0 setzen. Ist der einzige Weg das Blitzen zu vermeiden. Wobei ich auch "on" und "off" direkt auf Helligkeitsbefehle umsetze. Für die Bulb, besser deren Stromverbrauch, war es zumindest bei allen die ich gemessen habe so das "off" und "Helligkeit 0" identisch sind. Macht auch Sinn: der Empfänger muss in beiden Zuständen "zuhören", der PWM ist in beiden Fällen aus. ...

Zum Dimmen:) ich möchte auch auf die Sidoh brigde gehen, hätte also a: ein Interesse und würde b: auch das schreiben des Dim codes übernehmen.

Ist aber in der Tat alles andere als trivial, daher nichts für morgen. Ich kann gern erklären was genau "nicht trivial" daran ist, möchte aber den thread hier nicht dafür kapern.

vg
joerg

Dann mal Willkommen an Bord!

Wenn du C kannst und man den Code leicht von Perl nach C übertragen könnte: Sidoh hat schon lange einen issue offen und ist nach meinem Eindruck sehr offen für Anregungen. Dann würde die Bridge die Arbeit selbst erledigen..?!?

---

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 :) .

ZitatWas 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  :P

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

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.

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!

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

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!

ZitatHatte 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 (https://www.amazon.de/Touchscreen-Controller-Angetrieben-Batterien-Scheinwerfer/dp/B07BVTQRNN/ref=asc_df_B07BVTQRNN/?tag=googshopde-21&linkCode=df0&hvadid=309937280096&hvpos=1o4&hvnetw=g&hvrand=6423268577129447575&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9043467&hvtargid=pla-474401850679&psc=1&th=1&psc=1&tag=&ref=&adgrpid=61415687893&hvpone=&hvptwo=&hvadid=309937280096&hvpos=1o4&hvnetw=g&hvrand=6423268577129447575&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9043467&hvtargid=pla-474401850679) . 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

(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 :) .

Zitat von: Heimweh am 24 Juni 2019, 08:08:03
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.

ich muss mir das mal in Ruhe anschauen

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
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.

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.

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!

...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...

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.

Lass das hex bei device_id raus ;)

MQTT Client Status Topic steht bei mir auf "milight/LWT" + Detailed (habe das eben auch im Wiki nachgetragen).

@DasQ: Danke für den Hinweis zu "hex".... war wohl doch einfach heiß gestern ::)

 :)Erstmal Danke für die Tipps:

Ist die ESP-Bridge so richtig eingebunden?

Internals:
   CID        milight_hub_3406671
   DEF        milight_hub_3406671
   DEVICETOPIC MQTT2_milight_hub_3406671
   FUUID      5d1628c2-f33f-0190-6a3f-923e07d1a28808a6
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 4
   MQTT2_FHEM_Server_TIME 2019-06-28 16:57:53
   MSGCNT     4
   NAME       MQTT2_milight_hub_3406671
   NR         605
   STATE      <a href="http://192.168.0.85" target="_blank">
connected
</a>Version:
1.9.2
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-06-28 16:57:53   firmware        milight-hub
     2019-06-28 16:57:53   ip_address      192.168.0.85
     2019-06-28 16:57:53   reset_reason    Software/System restart
     2019-06-28 16:57:53   status          connected
     2019-06-28 16:57:53   version         1.9.2
Attributes:
   IODev      MQTT2_FHEM_Server
   autocreate 1
   bridgeRegexp milight_hub_3406671:milight/[^/]*at[^/]+/(0x....)/.*/([0-4])?.*:.* "milight_$1_$2"
   devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
   model      X_01_esp_milight_hub_bridge
   readingList milight_hub_3406671:milight/LWT:.* { json2nameValue($EVENT) }
   room       MQTT
   setStateList on off
   stateFormat <a href="http://192.168.0.85" target="_blank">
status
</a>Version:
version


Hier noch einmal ein screen der MQTT Einträge der ESP Bridge

also ich hab da nur das was ich wirklich brauche angehakt. plus den farbwert in HEX damit man das DevStateIcon farblich an die aktuelle farbe anpassen kann.

kannst ja mal einfach ausprobieren, welche readings sich beim betätigen den MilightFernbedienung in FHEM ändern und dann nur diese im hub aktivieren.

solltest mehrere arten an milights haben, sollten alle für alle betrieben lampen benötigten werte aktiviert sein.

 :)@DasQ

Die FB reagiert auf keine Lampe mehr.
Allerdings werden Devices angelegt.

Ich drücke sonst immer (-)  oder (0)
Muss ich die FB neu anlernen ?

wer meine rechtschreibfehler findet, oder nachmacht, oder gefundene nachgemachte verfälscht, wird mit ziebelsuppe, nicht unter 2 teller bestraft.
Klingt lecker, werde mich bemühen...

@TE:
Also zum einen wäre ich dankbar, wenn ich da - ausgehend von einem "nackigen" setting - verwertbare Infos bekäme, was man denn alles an vom Hub zu sendenen Infos (wirklich nur) braucht; dann trage ich das gerne im Wiki nach...

Dann: Am einfachsten ist das ganze, wenn man die Bulbs (verwende ich als Synonym für die Leuchtmittel (-Gruppe)) an eine FB anlernt und via dem Hub deren Code (FB-ID) snifft. Dann gilt nämlich die einfache Regel: ein Kanal = eine Bulb. Man kann das auch anders machen (insbesondere eine virtuelle FB im Hub anlegen und damit (zusätzlich) die Bulb pairen), aber dann hat man mehrere virtuelle Geräte (nur in FHEM bzw. Hub/ESP existent), die wenig mit der Realität zu tun haben oder diese irgendwie doppeln, was verwirrend sein kann (und scheinbar impliziert, dass man einen Eventhandler (notify) benötigt, um das zusammenzuführen). Da besser die einzelnen Reading-List-Einträge aus dem FB-Device zum Hub-FB-Device hinzufügen, dann ist der Device-Zustand und der Bulb-Zustand konsistent.

(Mei, ist das kompliziert zu beschreiben...)

 :)
Danke für die Hilfe, alles passt jetzt.
;D

Hallo zusammen,

ich bekomme das bei mir irgendwie nicht so recht zum laufen.
Ich habe, wie im MQTT-Wiki (bei Milight) die Brdige angelegt. Die Bridge selbst wird auch automatisch angelegt. Danach das Template zugewiesen und erneut einen der Lampen geschaltet. In meinem Fall wird dann nicht, wie im Wiki beschrieben, ein neues MQTT-Device erzeugt, sondern im Bridge-Device werden die Readings entsprechend erweitert.

Wenn ich den Befehl aus diesem Beitrag (Seite 1) eintrage, dann stürzt FHEM augenblicklich ab mit folgender Fehlermeldung

Befehl von der 1. Seite auf mein System angepasst:
define Milightbeispiel MQTT_MILIGHTDEVICE 0x1 1 rgbw dev_mqtt2_server

Fehlermeldung

2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_UNSUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_PINGREQ redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_IDENTIFIER_REJECTED redefined at FHEM/lib/Net                                                                                                                                                /MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBREC redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_SUBSCRIBE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44                                                                                                                                                .
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_PINGRESP redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_UNACCEPTABLE_PROTOCOL_VERSION redefined at FH                                                                                                                                                EM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_ACCEPTED redefined at FHEM/lib/Net/MQTT/Constants.pm                                                                                                                                                 line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_DISCONNECT redefined at FHEM/lib/Net/MQTT/Constants.pm line 4                                                                                                                                                4.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBCOMP redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_QOS_EXACTLY_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm                                                                                                                                                 line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_QOS_AT_MOST_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm                                                                                                                                                 line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_SERVER_UNAVAILABLE redefined at FHEM/lib/Net/                                                                                                                                                MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_QOS_AT_LEAST_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm                                                                                                                                                 line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBREL redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_BAD_USER_NAME_OR_PASSWORD redefined at FHEM/l                                                                                                                                                ib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBLISH redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_SUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_UNSUBSCRIBE redefined at FHEM/lib/Net/MQTT/Constants.pm line                                                                                                                                                 44.
2019.07.24 13:38:35 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_NOT_AUTHORIZED redefined at FHEM/lib/Net/MQTT                                                                                                                                                /Constants.pm line 44.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Define redefined at ./FHEM/00_MQTT.pm line 106.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Undef redefined at ./FHEM/00_MQTT.pm line 135.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Delete redefined at ./FHEM/00_MQTT.pm line 141.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Shutdown redefined at ./FHEM/00_MQTT.pm line 148.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine onConnect redefined at ./FHEM/00_MQTT.pm line 156.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine onDisconnect redefined at ./FHEM/00_MQTT.pm line 163.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine onTimeout redefined at ./FHEM/00_MQTT.pm line 170.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine isConnected redefined at ./FHEM/00_MQTT.pm line 179.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine process_event redefined at ./FHEM/00_MQTT.pm line 186.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Set redefined at ./FHEM/00_MQTT.pm line 207.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine parseParams redefined at ./FHEM/00_MQTT.pm line 254.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine parsePublishCmdStr redefined at ./FHEM/00_MQTT.pm line 341.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine parsePublishCmd redefined at ./FHEM/00_MQTT.pm line 350.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Notify redefined at ./FHEM/00_MQTT.pm line 392.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Attr redefined at ./FHEM/00_MQTT.pm line 400.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Start redefined at ./FHEM/00_MQTT.pm line 433.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Stop redefined at ./FHEM/00_MQTT.pm line 450.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Ready redefined at ./FHEM/00_MQTT.pm line 464.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Rename redefined at ./FHEM/00_MQTT.pm line 469.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Init redefined at ./FHEM/00_MQTT.pm line 479.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Timer redefined at ./FHEM/00_MQTT.pm line 488.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Read redefined at ./FHEM/00_MQTT.pm line 501.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine send_connect redefined at ./FHEM/00_MQTT.pm line 647.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine send_publish redefined at ./FHEM/00_MQTT.pm line 660.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine send_subscribe redefined at ./FHEM/00_MQTT.pm line 672.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine send_unsubscribe redefined at ./FHEM/00_MQTT.pm line 679.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine send_ping redefined at ./FHEM/00_MQTT.pm line 686.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine send_disconnect redefined at ./FHEM/00_MQTT.pm line 690.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine send_message redefined at ./FHEM/00_MQTT.pm line 697.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine topic_to_regexp redefined at ./FHEM/00_MQTT.pm line 712.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine client_subscribe_topic redefined at ./FHEM/00_MQTT.pm line 723.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine client_unsubscribe_topic redefined at ./FHEM/00_MQTT.pm line 742.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Client_Define redefined at ./FHEM/00_MQTT.pm line 759.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine Client_Undefine redefined at ./FHEM/00_MQTT.pm line 778.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine client_attr redefined at ./FHEM/00_MQTT.pm line 783.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine notify_client_connected redefined at ./FHEM/00_MQTT.pm line 897.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine notify_client_disconnected redefined at ./FHEM/00_MQTT.pm line 902.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine notify_client_connection_timeout redefined at ./FHEM/00_MQTT.pm line 907.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine client_start redefined at ./FHEM/00_MQTT.pm line 912.
2019.07.24 13:38:35 1: PERL WARNING: Subroutine client_stop redefined at ./FHEM/00_MQTT.pm line 944.
Undefined subroutine &MQTT::MILIGHTDEVICE::client_attr called at ./FHEM/10_MQTT_MILIGHTDEVICE.pm line 284.


Hat jemand ne Idee, woran das liegen kann und/oder hängt das vielleicht miteinander zusammen?

Viele Grüße
Patrick

Das sieht mir so aus, als würdest du da neue und alte Welt mischen wollen, und das geht leider schief...

Konkret: Entweder du verwendest MQTT2_SERVER als IO, dann darfst du daran KEIN MQTT_MILIGHTDEVICE horchen lassen, sondern "mußt" alles mit MQTT2_DEVICE abbilden (was ich zwischenzeitlich dringlich empfehlen würde und auch die Methode ist, die aktuell im Wiki steht mit den attrTemplates und allem).
Oder du bleibst in der "alten Welt" mit "MQTT" (00_MQTT.pm) als IO...

Steht denn nicht im ersten Beitrag deutlich genug, dass das "for historical reasons only" überhaupt noch vorgehalten wird, und man das jetzt bitte anders machen sollte (wenn man überhaupt auf das MiLight-Pferd setzen will, na ja...).

Ach sorry, da habe ich mich beim rumprobieren und hin und her testen wohl etwas verzettelt.

Also von vorn.
Ich habe die milight Komponenten schon länger im Einsatz und möchte daher auch vorerst Weiterhin damit leben. Die Nachteile sind für mich zur Zeit noch verschmerzbar.

Da bei mir alles (Sonoff, Shelly, milight,...) mit MQTT2_SERVER läuft, möchte ich dabei natürlich bleiben.

Ich hatte mich an das Wiki https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Milight-Bridge (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Milight-Bridge) gehalten. Habe sogar nochmal den bestehenden Bridge device gelöscht und per autocreate neu anlegen lassen.
Der Part

ZitatEinzelne Leuchtmittel
Wird nun nochmals das oben verwendete Leuchtmittel geschaltet, erstellt autocreate ein weiteres Device:

Zeigt bei mir allerdings ein anderes Verhalten wie in meinem vorhergehenden Post beschrieben.

OK, dann nochmal von vorne:

Du hast jetzt also das attrTemplate für die Milight-Bridge angewendet, aber dennoch landet alles weiter in der readingList in diesem Device und wird nicht vereinzelt?

Dann solltest du mal ein list (bzw. besser: eine RAW-Definition) von dem Teil zeigen. Vermutlich stimmt dann was mit den MQTT-Einstellungen nicht (dann vielleicht auch vorab bitte hier mal etwas in den jüngeren Beiträgen hier rumlesen, das Thema hatten wir immer mal wieder, wäre nicht schlecht, wenn wir mal einen Knopf mit einer "jugfräulichen" Bridge dran bekäme, wie das denn sinnvollerweise konkret ausschaut mit den Topics und den ausgewählten Sendedaten ;D ).

Ich bin gerade parallel dabei, den Thread von vorne komplett durchzulesen.

ZitatDu hast jetzt also das attrTemplate für die Milight-Bridge angewendet, aber dennoch landet alles weiter in der readingList in diesem Device und wird nicht vereinzelt?

Richtig

Hier mein Bridge device:

define MQTT2_milight_hub_4527858 MQTT2_DEVICE milight_hub_4527858
attr MQTT2_milight_hub_4527858 IODev dev_mqtt2_server
attr MQTT2_milight_hub_4527858 autocreate 1
attr MQTT2_milight_hub_4527858 bridgeRegexp milight_hub_4527858:miligth/[^/]*at[^/]+/(0x....)/.*/([0-4])?.*:.* "milight_$1_$2"
attr MQTT2_milight_hub_4527858 devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr MQTT2_milight_hub_4527858 model X_01_esp_milight_hub_bridge
attr MQTT2_milight_hub_4527858 readingList milight_hub_4527858:milight/LWT:.* { json2nameValue($EVENT) }
milight_hub_4527858:miligth/update/0x1/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_4527858:milight/states/0x1/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_4527858:miligth/update/0x3/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_4527858:miligth/update/0x4/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_4527858:miligth/update/0x2/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_4527858:miligth/update/0x1/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_4527858:miligth/update/0x5/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_4527858:milight/states/0x5/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_4527858:miligth/update/0x6/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_4527858:milight/states/0x6/rgb_cct/1:.* { json2nameValue($EVENT) }
milight_hub_4527858:milight-hub/LWT:.* { json2nameValue($EVENT) }
attr MQTT2_milight_hub_4527858 room %Type
attr MQTT2_milight_hub_4527858 setStateList on off
attr MQTT2_milight_hub_4527858 stateFormat <a href="http://ip_address" target="_blank">
status
</a>Version:
version


Und hier der Mqtt2-Device:
define dev_mqtt2_server MQTT2_SERVER 1883 global
attr dev_mqtt2_server autocreate 1
attr dev_mqtt2_server rawEvents 1

Ich kam aber jetzt leider noch nicht dazu, dass gegen die Vorgaben zu checken  ::) :-\

fällt dir was auf?

Zitatmilight_hub_4527858:miligth/update/0x1/rgbw/1:.* { json2nameValue($EVENT) }

Mach' mal "milight" als Präfix in den Hub, und irgendwie ist mir auch nicht klar, warum deine FB-Signale scheinbar nur eine Stelle haben und nicht 4 wie üblich ;) .
(also "0x1" statt "0x12EF")

Da ist also wie vermutet irgendwas faul auf dem Hub...

OMG  ::) ::) ::)

Das da miligth statt milight steht ist mir so gar nicht aufgefallen... Kein Wunder, dass dann das Template nicht greift.
Ich bin gerade unterwegs, werde mir das dann später direkt mal anschauen.

Danke für den Hinweis. Meine Güte, manchmal ist man echt blind. Oder es ist die Hitze  ;D

im zweifelsfall nach zu wilden löschorgien das ganze von vor und ganz wichtig zwischenzeitlich fhem mal neustarten

...das mit dem Neustart sollte nicht mehr notwendig sein, da hatte Rudi ca. im Feb. was geändert.

ABER: das Problem war/ist nicht die Schreibweise "miligth", sondern die gekürzte Übertragung der Fernbedienungs-ID...
Die Schreibweise irritiert nur, wird aber sauber auf die bridgeRegexp übertagen ;) .

Danke für den Hinweis. Ich habe nun mal einen Device im Milight-Webinterface mit den vorgebenen 4 Stellen (0xAAA1) per hand eingetragen und siehe da, das Template tut, was es soll.

Danke für die Lösung des Problems  :D

Zitat von: herrmannj am 24 Juni 2019, 09:53:37
Zu den Transitions: @Beta-user ja so ungefähr würde ich mir das vorstellen.

Kleiner Hinweis dazu: Es gibt eine neue dev-Version, die das angeblich kann...

https://github.com/sidoh/esp8266_milight_hub/issues/113
https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.10.0-dev.8

Die verfügbare Anleitung ist ziemlich kurz...:

ZitatYou toss a {"transition":15} into your command, and it'll transition from known state to what you've provided

K.A., ob das nur on->off und umgekehr betrifft oder noch mehr damit machbar ist...

Hab's noch nicht getestet (und weiß auch noch nicht, ob ich das will, da meine MiLights hinter Schaltern sitzen...), sondern nur gestern meinem Hub mal wieder ein update verpaßt, nachdem auch eine FB mit 8 Kanälen aus China angekommen war (muß den bridgeRegexp im template bei Gelegenheit anpassen...).

Wenn das also jemand transitions testen und "vertemplaten" mag?

Hallo Beta-User.

ich habe meine Bridge gestern auch mal geupdatet. Ich kann nicht genau sagen ob es damit zusammenhängt, vor ein paar Wochen noch liessen sich meine Milights
über Alexa steuern, dass geht jetzt zum Teil nicht mehr.
Aus meinem Verständnis raus, fehlt "Alexa" die Rückmeldung von MQTT ob die Lampen an oder aus sind. Ist aber wohl eher ein Thema für den Alexa Tread.

Was die Dokumentation für die Transition angeht - hier steht eine ganze Menge. Ich will mir das mal anschauen aber vorher muss erstmal alles wieder zu funktionieren wie davor

https://sidoh.github.io/esp8266_milight_hub/branches/1.10.0-rc.1/#tag/Device-Control/paths/~1gateways~1%7Bdevice-id%7D~1%7Bremote-type%7D~1%7Bgroup-id%7D/put (https://sidoh.github.io/esp8266_milight_hub/branches/1.10.0-rc.1/#tag/Device-Control/paths/~1gateways~1%7Bdevice-id%7D~1%7Bremote-type%7D~1%7Bgroup-id%7D/put)

Also ganz ehrlich, die Bridge läuft seit einigen Updates nicht mehr ordentlich.

Ich werd mir mal sein Quelltext genauer anschaun und ggf was eigenes baun.

Zitat von: DasQ am 12 August 2019, 10:20:29
Also ganz ehrlich, die Bridge läuft seit einigen Updates nicht mehr ordentlich.

Hmm. Ich habe einige Updates übersprungen, kann dazu nichts sagen. Trotz allem ist die Sidoh Bridge aus meiner Sicht noch die beste Lösung
wenn man alte Milights (RGB) und neue (+CCT) verwendet.

Über fhem funktioniert alles wunderbar. Nach wie vor - aber mit Alexa geht's nicht mehr richtig. Zumindest zum Teil. Daher denke ich es hat mit
der Rückmeldung an Alexa zu tun (Alexa App Schalter toggelt) - die Rückmeldung von MQTT an Alexa - ob die Lampe bereits an ist oder nicht. Das
denke ich ist das Problem.

Ich hatte schon mal Theater weil der State mal groß und mal klein geschrieben war... Mal gucken...

Zitat von: DasQ am 12 August 2019, 10:20:29
Also ganz ehrlich, die Bridge läuft seit einigen Updates nicht mehr ordentlich.

Ich werd mir mal sein Quelltext genauer anschaun und ggf was eigenes baun.

Hmmm, ich fand die letzten Änderungen tendenziell hilfreich, allerdings scheint das mit dem Faden ggf. erst mal experimentell gewesen zu sein (aber die release notes bis einschl. 1.10.0-rc.4 lesen sich ganz gut).

Was alexa angeht, dürfte es mit dem Schreibweisen ein Thema geben, das sollte ggf. mit einer eventMap (vom device her) zu lösen sein. Kann dazu aber wenig beitragen, ich nutze keine Sprachsteuerung...

Interessant fnde ich v.a., dass seit neuestem auch HEX-Werte für RGB geliefert werden können, damit muß ich aber auch erst mal noch spielen...

Zitat von: Beta-User am 26 August 2019, 10:20:32
Hmmm, ich fand die letzten Änderungen tendenziell hilfreich, allerdings scheint das mit dem Faden ggf. erst mal experimentell gewesen zu sein (aber die release notes bis einschl. 1.10.0-rc.4 lesen sich ganz gut).

Ich habe damit ein bisschen rumgespielt - es aber noch nicht hinbekommen. Sidoh hatte geschrieben die Befehle aus dieser Anleitung (s.u.) seien 1:1 auch in MQTT nutzbar:

https://sidoh.github.io/esp8266_milight_hub/branches/1.10.0-rc.1/#tag/Device-Control/paths/~1gateways~1%7Bdevice-id%7D~1%7Bremote-type%7D~1%7Bgroup-id%7D/put (https://sidoh.github.io/esp8266_milight_hub/branches/1.10.0-rc.1/#tag/Device-Control/paths/~1gateways~1%7Bdevice-id%7D~1%7Bremote-type%7D~1%7Bgroup-id%7D/put)

mit dem Befehl: "transition": 2.0

@Beta-User - ich habe die set Befehle aus Deinen Templates als Beispiel für die MQTT Befehle genommen -
müssen denn die Anführungzeichen sein bei "on"  "status":"on"? Weil Sidoh geschrieben hat der Transition Befehl muss so aussehen: "transition": 2.0
Gibt es eine Art Terminalprogramm um Befehle z.B. vom PC aus an die Bridge zu schicken? Das wäre sehr hilfreich beim "rumspielen"....

Zitat von: Heimweh am 27 August 2019, 08:27:13
müssen denn die Anführungzeichen sein bei "on" 

Code Auswählen Erweitern

"status":"on"? Weil Sidoh geschrieben hat der Transition Befehl muss so aussehen:

Code Auswählen Erweitern

"transition": 2.0
Gibt es eine Art Terminalprogramm um Befehle z.B. vom PC aus an die Bridge zu schicken? Das wäre sehr hilfreich beim "rumspielen"....

Kann sein, dass man die auch weglassen kann... Was ich häufiger feststellen durfte: Viele MQTT-Clients (nicht nur diese Bridge) sind scheinbar recht tolerant gegen solche Formatierungsfragen und häufig auch, was Groß- und Kleinschriebung angeht (für Befehle). Ist mir erst gestern wieder aufgefallen, als ich kurz durch das template-file gesehen habe :D . Allerdings bin ich mir nicht sicher, ob die im "comment" angegebene Form wirklich paßt, das ist "auf die Schnelle" da reingekommen und nicht vollständig ausgetestet bzw. da kann sich auch auf der bridge-Seite noch was geändert haben ::) .

Als Terminalprogramm kannst du z.B. mosquitto_pub verwenden, siehe z.B. http://www.steves-internet-guide.com/mosquitto_pub-sub-clients/. Einfacher (ohne Terminal) geht es aber m.E., wenn du die Publish-Option nutzt, die sowohl MQTT2_SERVER wie ...CLIENT bieten ;) .

Einen wunderschönen guten Morgen,

@Beta-User - dankschön! Ich konnte mit Deiner Hilfe wieder etwas dazu lernen.

Ich habe gestern nochmal mit dem Transition Befehl rumgespielt und es klappt nun mit folgendem Set-Befehl:
(aus der Setlist einer meiner Milights)

dimup milight/0x15B1/rgbw/1 {"status":"on","transition":2}

Das Leuchtmittel dimmt also in 2 Sekunden hoch - man kann auch noch die "Ziel" Brightness dazu angeben. Hat das von Euch auch schon jemand
versucht? Mir ist aufgefallen, das hoch- und runterdimmen ist sehr "ruckelig" bzw. die Stufen sind sehr grob, also kein smoothes dimmen.
Ich frage weil ich ausschließen möchte dass meine Hardware evtl. zu langsam ist oder es an den Leuchtmitteln liegt. Auch eine Erhöhung der Zeit
brachte nicht wirklich Verbesserung.

Das ist bei milight so.

In wifilight betreibe ich einen hohen Aufwand damit das halbwegs passt und sidoh hat das nur ganz rudimentär implementiert. Da lauern auch noch andere Fallen.

Die sidoh Bridge läuft mMn sehr stabil und schön. Wenn Transitions wirklich ein must have ist solltest du andere Leuchtmittel nehmen. Ansonsten verzichte drauf und oder erwarte nicht die gleiche Funktion wie bei anderen die das native unterstützen.

Zitat von: herrmannj am 30 August 2019, 10:45:21
In wifilight betreibe ich einen hohen Aufwand damit das halbwegs passt und sidoh hat das nur ganz rudimentär implementiert. Da lauern auch noch andere Fallen.

Vorab mal Danke für die allgemeine Einschätzung der firmware, es gibt zwar hin und wieder kleinere Problemchen, v.a. mit neueren Funktionen, aber im großen und ganzen ist das echt super, was Chris da macht. (Grade kommt es mir z.B. so vor, als wäre das rückgelieferte hex-Ergebnis nicht immer konsistent...). Aber in der Regel ist er sehr aufgeschlossen für Verbesserungsvorschläge und Codebeiträge, jedenfalls soweit ich das beurteilen kann.

Da jetzt die Transition-Funktionalität "an sich" angeht: ich habe leider keine Vorstellung, ob das eine Riesensache wäre, den vorhandenen Perl-Code "auszuschlachten" und nach C zu portieren, um die rudimentäre Lösung zu verbessern. Hast du da eine Idee (ggf. auch, wie man iterativ vorgehen könnte)?

Absolut, bin ein Fan von dem was sidoh macht!

Transitions und portieren: ja klar  ;), aber der Aufwand steht imho in keinem Verhältnis zum Ergebnis. Echt, mittlerweile gibt es so viele Leuchtmittel die das native machen.

Milights haben ihre Vorteile: funktionieren unabhängig vom WLAN, es gibt Wandschalter und Fernbedienung. Transitions können sie nicht, fin.

Hmmm. Ja ich bin absolut verwöhnt vom Wifilightmodul... Aber ich kann auch damit leben wenns nicht dimmt. Die Leuchtmittel gehen ja nicht
schlagartig an und aus, sondern eher weich. Das passt so!

In der Theorie müsste/könnte sogar WifiLight und Sidoh gleichzeitig gehen weil Sidoh ja auch die bridge emuliert. (?) Halt nur die alten weil WifiLight die neuen nicht kann..

Zitat von: herrmannj am 30 August 2019, 16:43:07
In der Theorie müsste/könnte sogar WifiLight und Sidoh gleichzeitig gehen weil Sidoh ja auch die bridge emuliert. (?)

Ja, das kann man dort unter settings->UDP einstellen (ähnlich für die andere Firmware aus dem "Eigentlich wollte ich ...."-Thread, für die du die Option eingebaut hattest, den UDP-Port angeben zu können ;) ).

ZitatHalt nur die alten weil WifiLight die neuen nicht kann..

Bin nicht mal sicher, ob mit dieser firmware nicht sogar die Option bestünde, V6-Protokoll via UDP steuerbar zu machen. Es wäre ggf. mal einen Test wert, ob das auf der UDP-Ebene überhaupt was anderes ist (ich habe leider keine V6 Geräte, sonst würde ich die Frage direkt beantworten...). (Gab es überhaupt sonst ein (kaufbares) WiFi-Gerät, das als UDP-Fernbedienung für die neuen Protokoll-Versionen fungiert hat?)

....mal was anderes  :) :

Neulich hatte ich ja den Gedanken, man könnte die MiLight-Fernbedienungen ja eigentlich ganz gut als Input-Device für alles mögliche nutzen - 8 (bzw. 9) Modi/Kanäle mit je 9 Tasten - drei davon eindeutig als "Level" bzw. Farbeingaben nutzbar ist ja schließlich was...
Da jetzt die Lieferung aus China schon eine ganze Zeit darauf wartet, dass in die Richtung tatsächlich was passiert, anbei mal mein "erster Wurf" zur Steuerung meines MPD. (Der hat ganz schön Last auf meinem Server erzeugt, bis ich ihm verboten habe, die Datenbank zu lesen....).

So kann ich jetzt neben Lautstärke und play/pause/stop auch den consumer-Modus umstellen (geht mit der von mir genutzten Handy-App nicht) und (das war wichtig!) den replay_gain_modus.

Das ist ganz ohne  template, ungenutzt sind noch hue und color_temp - da habe ich noch nicht die durchschlagende Idee... ::)

RAW-Definitionen bzw. der myUtils-Code:
defmod MiLight_RC1_8 MQTT2_DEVICE milight_0xABCD_8
attr MiLight_RC1_8 readingList milight/updates/0xABCD/fut089/8:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/fut089/8:.* { json2nameValue($EVENT) }

defmod n_MiLight_RC1_8 notify MiLight_RC1_8:(ON|OFF|(brightness|command|bulb_mode).*) {milight_to_MPD("myMPD",$EVENT)}


sub milight_to_MPD($$) {
  my ($name,$Event) = @_;
  return "" if ReadingsVal($name,"presence","absent") eq "absent";
  if($Event =~ /OFF|ON/) {
    my $command = (ReadingsVal($name,"state","play") eq "pause" and $Event =~ /OFF/) ? "stop" : ReadingsVal($name,"state","play") ne "stop" ? "pause" : "play";
    CommandSet(undef, "$name $command");
  } elsif ($Event =~ /brightness/)  {
    my ($reading,$value) = split (/ /,$Event);
    my $volume = int (round ($value/2,55));
    CommandSet(undef, "$name volume $volume");
  } elsif ($Event =~ /mode_speed_down/)  {
    CommandSet(undef, "$name previous");

  } elsif ($Event =~ /mode_speed_up/)  {
    CommandSet(undef, "$name next");

  } elsif ($Event =~ /scene/)  {
    my $gainmode = CommandSet(undef, "$name mpdCMD replay_gain_status") =~ /album/ ? "auto" : "album";
   
    CommandSet(undef, "$name mpdCMD replay_gain_mode $gainmode");
     
  } elsif ($Event =~ /bulb_mode.*white/)  {
    my $consumer = CommandSet(undef, "$name mpdCMD status") =~ /consume. 0/ ? "1" : "0";
    CommandSet(undef, "$name mpdCMD consume $consumer");

  } else {

  } 
}


Bei Gelegenheit versuche ich mich mal daran, eine HUE-Bulb mit einem anderen Kanal zu steuern...

Hallo Beta-User,

ich versuche gerade nachzuvollziehen bzw. zu verstehen wieso meine Milights (wenn Sie z.B. in rot auf 30% Helligkeit laufen) bei einem Farbwechsel über "Alexa schalte XY blau" auf 100% Helligkeit gehen wenn sie nach blau umschalten. Ich weiss Du hast keine Alexa - aber mal ganz grundsätzlich eine Frage:

brightness:colorpicker,BRI,0,15,255 milight/0x15B1/rgbw/1 {"$EVTPART0":"$EVTPART1"}

Das ist aus einem Deiner Templates - und Du übergibst damit den Wert brightness - dass $EVTPART1 ist der Wert der brightness - dann müsste das $EVTPART0 der Befehl "brightness" sein richtig?
Und das verstehe ich nicht. Kommt das so aus dem Colorpicker? Wie "füllt" sich die Variable "$EVTPART0"?

Zitat von: Heimweh am 02 September 2019, 14:15:34
dann müsste das $EVTPART0 der Befehl "brightness" sein richtig?

Und das verstehe ich nicht. Kommt das so aus dem Colorpicker? Wie "füllt" sich die Variable "$EVTPART0"?

Nein, aus dem Colorpicker kommt nur der Wert ($EVTPART1), das $EVTPART0 kommt aus der ersten Angabe der Zeile. Hieße das
Helligkeit:colorpicker,BRI,0,15,255 milight/0x15B1/rgbw/1 {"$EVTPART0":"$EVTPART1"} würde "Helligkeit" zurückgeliefert usw. (was aber dann die Bridge nicht kennen würde).
(Zum Verständnis: die Option, da $EVTPARTx nutzen zu können, hatte Rudi dankenswerterweise eingebaut, um solche Widgets nutzen zu können, v.a. also $EVTPART1 abzugreifen. "Eigentlich" war das nicht dazu gedacht, auch $EVTPART0 zu übergeben, aber weil es funktionierte und Schreibfehleroptionen minimiert, findet sich jetzt eben die Variable und nicht der eigentlich feste Text im template... Das hat also keine tiefere Bedeutung ;D .)

Zu deinem eigentlichen Problem:
Um rauszufinden, wer da wie beteiligt ist, solltest du mal nachsehen, was von welcher Seite an MQTT-Messages ausgetauscht wird (z.B. mit RAW-Events am MQTT2_SERVER). Ich würde annehmen, dass Alexa für dieses Verhalten verantwortlich ist und einen 100%-Befehl "dazudichtet"...

Aha :) Danke für die ausführliche Erklärung! Das macht es jetzt für mich plausibel.

Ich dachte dass sich die Alexa möglicherweise an der Setlist der Templates bedient.... Dann geht die Suche in eine andere Richtung!

Vielen Dank dass Du Dir für meine Anfänger Fragen immer so viel Zeit nimmst!

Gesendet von meinem LYA-L29 mit Tapatalk

Zitat von: Heimweh am 02 September 2019, 15:38:16
Ich dachte dass sich die Alexa möglicherweise an der Setlist der Templates bedient.... Dann geht die Suche in eine andere Richtung!

Hmm, meine Erläuterung zur setList schließt  das aber nicht aus; es ist m.E. sogar ziemlich wahrscheinlich, dass genau das der Fall ist: Jedes (Geräte-) Modul muß ja z.B. FHEMWEB sagen, welche "Setter" es gibt. Das kann nicht nur FHEMWEB, sondern jedes beliebige andere Modul auch auswerten und dann z.B. im ersten Angang eben davon ausgehen, dass ein Gerät, das on/off und brightness kennt, eine dimmbare Leuchte ist. Mit dim oder level könnte es noch ein shutter-Device sein, da wird es dann beim Erraten schon weniger eindeutig...
Was das andere Modul dann jeweils daraus macht, steht auf einem anderen Blatt, ebenso, dass manche Device-Typen zwischen dem Einschaltlevel und den Einschaltbefehl ziemlich klar trennen (afaik mindestens Hue und ZWave), manche dimmen vorher runter, bevor sie FHEM ausschalten lassen, was dann ebenfalls "korrigiert" werden muß.

Mal schauen, was deine MQTT-Analyse zeigt.

Zitat von: Heimweh am 02 September 2019, 15:38:16
Vielen Dank dass Du Dir für meine Anfänger Fragen immer so viel Zeit nimmst!

:) Gerne!

Hi,

Alexa dichtet einen 100% Befehl dazu, das sieht man im Alexa-Log.

Mit Licht hab ich es aber nicht so und nie richtig mit beschäftigt.

Hier mal ein Auszug während die Lampe an ist und auf 30 Prozent gestellt wird, dann auf Rot:

[2019-9-2 4:34:59 PM] >>>> [srv] {"directive":{"header":{"namespace":"Alexa.BrightnessController","name":"SetBrightness","payloadVersion":"3","messageId":"cac4f3b4-6407-4845-b994-4630e47ff8e8","correlationToken":"AAAAAAAAAQD8wgCX0kEZAc9DM6Vw32cLDAIAAAAAAACKEiRaC3cLNvn/IflL37VD2P8H6cLKVOBU31IWL9/D0hPLZgBntZs6OvZR/bzmxgmdMRsw2U8b+TEWHflbrNmQ3Ke4b/SGC8H/YHUnN7Vw5IqCop+Z4Zl0/IumXOCsZbguqf7fUldj1irgN/46+rc3thYQgOaSmZ1+bo6KznzZH5zwvDfC0y31t2tMnkTQWOA7Fjn0F/o9z1T4uczBpv9Mq9BEPV8iZ+pd0Sr772p83BgLP/ZnM7+mpJo/2Pmn7g7EKsqsVYL9r/u5TOdIOCWC61CySkulbM2T+IXCK56hnoGctxzonG3lfr3NzsdG3CC2nsOfYRbkhn+12YYhhbZksnzec6hODNkbFyaaDGOptiIP9jWkFO1eyEdKifJDX0vXKmx5o9IVaxy2CtpuNF8xa/IreAcjyDrC7eERlI0yTLyYclYOa+hmXkY+zIPJUgpCFQUkw985fchblatORiL0NtSBzUwkpBbY0oclp0CafFy+OF1MzGewVn8jsKi1xl63px7vysKU/N5WUNiXU+S7FMnEDoTan4L+z+0JDRD557MKtbzypDd/+PQlzpK1DrRKvhRywrHiQnRmu6Y8wZCcoIbKeQc1pSp+uHcWhTH6ypOqSMeoThA1D3F0haXXsaM5eDbNbWtNNZBnhjOjpQwns28676mdSAxovgcYUbNiN2c63VMGovYLtuer9w=="},"endpoint":{"scope":{"type":"BearerToken","token":"Atza|IwEBIFRJu9DGNHSpvmxs5cCybV3xbDlTr6sjpBX29B4PxOuMeXc-ug0ufiSABBYejhIou81j2j--bFuyQW7sbf9hv7FwPlLURzsLibqQ16hXH83wlrIZo5oVuqcxSRXZySvzAEd2uYIUt6luyCJxabRcDndq7L4Phtpw4C4wJLe1H3HyDyOqf8GQaLM5BzXVICz359yPrNVIrvW2MF7qOaKSOa_n6mAvUBJT2gnaG7TefYW7O4Pzz-THeAX4rG1jJxm9V6rVQNEA5OZg5F5xwAQpdCWChWcWBEsuC94ao6TmZZcL-YdENC6EVRRPyRAvZDFXFukBgtXTIHuYztau7A5L1oxczKQ0bIEo0h4Bv-UrA_C0iWrLh9c8KnXgZUrA2-n-6FFyioyBZipTJ3JgSn2wiWSX21g0dj77Fky3WUkB_FlIP5WXbAxZh3hppUEGXKpK_30L0U9zhQnrNp7KvQ7mXgsx9g6ECzm-XiZtV2ZjZEcQtnWkP4M07TvWJFRFeVlJY3U"},"endpointId":"5ca22186-f33f-78f5-f311-f4eb49cbf00f7ebb","cookie":{"fuuid":"5ca22186-f33f-78f5-f311-f4eb49cbf00f7ebb","device":"MQTT2_Mi_Wecklicht"}},"payload":{"brightness":30}}}
[2019-9-2 4:34:59 PM] accepted new token
[2019-9-2 4:34:59 PM] [FHEM]     caching: Brightness: 255 (as string; from '255')
[2019-9-2 4:34:59 PM] [FHEM] MQTT2_Mi_Wecklicht: executing set cmd for Brightness with value 30
[2019-9-2 4:34:59 PM] [FHEM]   executing: http://192.168.188.26:8083/fhem?cmd=set%20MQTT2_Mi_Wecklicht%20brightness%2077&XHR=1
[2019-9-2 4:34:59 PM] <<<< [srv] {"context":{"properties":[{"namespace":"Alexa.BrightnessController","name":"brightness","value":30,"timeOfSample":"2019-09-02T14:34:59.730Z","uncertaintyInMilliseconds":500}]},"event":{"header":{"namespace":"Alexa","name":"Response","payloadVersion":"3","messageId":"8bc0c02a-23ac-4c98-b0b1-98acc4ffb0f0","correlationToken":"AAAAAAAAAQD8wgCX0kEZAc9DM6Vw32cLDAIAAAAAAACKEiRaC3cLNvn/IflL37VD2P8H6cLKVOBU31IWL9/D0hPLZgBntZs6OvZR/bzmxgmdMRsw2U8b+TEWHflbrNmQ3Ke4b/SGC8H/YHUnN7Vw5IqCop+Z4Zl0/IumXOCsZbguqf7fUldj1irgN/46+rc3thYQgOaSmZ1+bo6KznzZH5zwvDfC0y31t2tMnkTQWOA7Fjn0F/o9z1T4uczBpv9Mq9BEPV8iZ+pd0Sr772p83BgLP/ZnM7+mpJo/2Pmn7g7EKsqsVYL9r/u5TOdIOCWC61CySkulbM2T+IXCK56hnoGctxzonG3lfr3NzsdG3CC2nsOfYRbkhn+12YYhhbZksnzec6hODNkbFyaaDGOptiIP9jWkFO1eyEdKifJDX0vXKmx5o9IVaxy2CtpuNF8xa/IreAcjyDrC7eERlI0yTLyYclYOa+hmXkY+zIPJUgpCFQUkw985fchblatORiL0NtSBzUwkpBbY0oclp0CafFy+OF1MzGewVn8jsKi1xl63px7vysKU/N5WUNiXU+S7FMnEDoTan4L+z+0JDRD557MKtbzypDd/+PQlzpK1DrRKvhRywrHiQnRmu6Y8wZCcoIbKeQc1pSp+uHcWhTH6ypOqSMeoThA1D3F0haXXsaM5eDbNbWtNNZBnhjOjpQwns28676mdSAxovgcYUbNiN2c63VMGovYLtuer9w=="},"endpoint":{"scope":{"type":"BearerToken","token":"Atza|IwEBIFRJu9DGNHSpvmxs5cCybV3xbDlTr6sjpBX29B4PxOuMeXc-ug0ufiSABBYejhIou81j2j--bFuyQW7sbf9hv7FwPlLURzsLibqQ16hXH83wlrIZo5oVuqcxSRXZySvzAEd2uYIUt6luyCJxabRcDndq7L4Phtpw4C4wJLe1H3HyDyOqf8GQaLM5BzXVICz359yPrNVIrvW2MF7qOaKSOa_n6mAvUBJT2gnaG7TefYW7O4Pzz-THeAX4rG1jJxm9V6rVQNEA5OZg5F5xwAQpdCWChWcWBEsuC94ao6TmZZcL-YdENC6EVRRPyRAvZDFXFukBgtXTIHuYztau7A5L1oxczKQ0bIEo0h4Bv-UrA_C0iWrLh9c8KnXgZUrA2-n-6FFyioyBZipTJ3JgSn2wiWSX21g0dj77Fky3WUkB_FlIP5WXbAxZh3hppUEGXKpK_30L0U9zhQnrNp7KvQ7mXgsx9g6ECzm-XiZtV2ZjZEcQtnWkP4M07TvWJFRFeVlJY3U"},"endpointId":"5ca22186-f33f-78f5-f311-f4eb49cbf00f7ebb"},"payload":{}}}
  2019-09-02 16:34:59 caching: MQTT2_Mi_Wecklicht-brightness: set 77
[2019-9-2 4:34:59 PM] [FHEM]     caching: Brightness: set 77 (as string; from 'set 77')
  2019-09-02 16:35:00 caching: MQTT2_Mi_Wecklicht-brightness: 82
[2019-9-2 4:35:00 PM] [FHEM]     caching: Brightness: 82 (as string; from '82')
[2019-9-2 4:35:17 PM] >>>> [srv] {"directive":{"header":{"namespace":"Alexa.ColorController","name":"SetColor","payloadVersion":"3","messageId":"4183552a-9826-4f24-9cc7-85c40665ffb5","correlationToken":"AAAAAAAAAQD8wgCX0kEZAc9DM6Vw32cLDAIAAAAAAACOMKJYWemkBNGLKJ/A+dcyC4QnoDkYaYqBEQ+KtcAQNzy5t00ioroZ/iGl2JxR0oGDmi6PBTSOTMz+ausBSnHEDw8cWh+06L0EiCNcJJTwH4uZBdqCKBKmrgPGV+m7NP5lyzqsus+et5nQLjSAoj6ZxIEM+yDwxccG6t5k7gKv+znNKnbqjh30gE3LzJ1jxKg+hM1hhWkDVDaYRurQVq/FtoN3wbBEHh5NcOkTyGDyYq1K5y1sDlleGxCoaL1nf8KNTCP31N0LfWvKZ+7CICufpXUj560IATi/o/dz07CKEVMWRIjWAtSajGE1pewlBd3v8WpgH8vIh2sN6+QkoGn+ryWZcgHkdrfn5egsgngPaVTT868wtCodChhdxPoGDay4Ogcg+bKHE/cyXptrgKkMt0b6OFOkIl/B/v/hLJ1IQtMU19HDRNrFkwO0AKv4WWodjCDIKgKac0Jn5kbXh1VqjFV8RC/JhbwL6B80NVTd7NfsOSC+CaSUHsTlSZTKRrA5zapAHEobhnQVVhPkUx4u7COdQQLqZv/dkib9ckhrMs6tEzSxjYwoGHDa6R01QEOBZfykTfh9nCOc8PpKbRZRjTWccjEmTU0D2b8rkPkcgRkh+GizHj9//POkNMsMEmS69mSK1zLgR2geZ2Z8/ouQCpksr5Y4rjSB8ctbhWuoSAvbxZdayuHJR4oW+Q=="},"endpoint":{"scope":{"type":"BearerToken","token":"Atza|IwEBIFRJu9DGNHSpvmxs5cCybV3xbDlTr6sjpBX29B4PxOuMeXc-ug0ufiSABBYejhIou81j2j--bFuyQW7sbf9hv7FwPlLURzsLibqQ16hXH83wlrIZo5oVuqcxSRXZySvzAEd2uYIUt6luyCJxabRcDndq7L4Phtpw4C4wJLe1H3HyDyOqf8GQaLM5BzXVICz359yPrNVIrvW2MF7qOaKSOa_n6mAvUBJT2gnaG7TefYW7O4Pzz-THeAX4rG1jJxm9V6rVQNEA5OZg5F5xwAQpdCWChWcWBEsuC94ao6TmZZcL-YdENC6EVRRPyRAvZDFXFukBgtXTIHuYztau7A5L1oxczKQ0bIEo0h4Bv-UrA_C0iWrLh9c8KnXgZUrA2-n-6FFyioyBZipTJ3JgSn2wiWSX21g0dj77Fky3WUkB_FlIP5WXbAxZh3hppUEGXKpK_30L0U9zhQnrNp7KvQ7mXgsx9g6ECzm-XiZtV2ZjZEcQtnWkP4M07TvWJFRFeVlJY3U"},"endpointId":"5ca22186-f33f-78f5-f311-f4eb49cbf00f7ebb","cookie":{"fuuid":"5ca22186-f33f-78f5-f311-f4eb49cbf00f7ebb","device":"MQTT2_Mi_Wecklicht"}},"payload":{"color":{"hue":0,"saturation":1,"brightness":1}}}}
[2019-9-2 4:35:18 PM] accepted new token
[2019-9-2 4:35:18 PM] [FHEM] MQTT2_Mi_Wecklicht: executing set cmd for Hue with value 0
[2019-9-2 4:35:18 PM] [FHEM]   executing: http://192.168.188.26:8083/fhem?cmd=set%20MQTT2_Mi_Wecklicht%20hue%200&XHR=1
[2019-9-2 4:35:18 PM] [FHEM] MQTT2_Mi_Wecklicht: executing set cmd for Brightness with value 100
[2019-9-2 4:35:18 PM] [FHEM]   executing: http://192.168.188.26:8083/fhem?cmd=set%20MQTT2_Mi_Wecklicht%20brightness%20255&XHR=1
[2019-9-2 4:35:18 PM] <<<< [srv] {"context":{"properties":[{"namespace":"Alexa.ColorController","name":"color","value":{"hue":0,"saturation":1,"brightness":1},"timeOfSample":"2019-09-02T14:35:18.368Z","uncertaintyInMilliseconds":500}]},"event":{"header":{"namespace":"Alexa","name":"Response","payloadVersion":"3","messageId":"1cb53e54-6730-4bfb-8578-af1abac18b29","correlationToken":"AAAAAAAAAQD8wgCX0kEZAc9DM6Vw32cLDAIAAAAAAACOMKJYWemkBNGLKJ/A+dcyC4QnoDkYaYqBEQ+KtcAQNzy5t00ioroZ/iGl2JxR0oGDmi6PBTSOTMz+ausBSnHEDw8cWh+06L0EiCNcJJTwH4uZBdqCKBKmrgPGV+m7NP5lyzqsus+et5nQLjSAoj6ZxIEM+yDwxccG6t5k7gKv+znNKnbqjh30gE3LzJ1jxKg+hM1hhWkDVDaYRurQVq/FtoN3wbBEHh5NcOkTyGDyYq1K5y1sDlleGxCoaL1nf8KNTCP31N0LfWvKZ+7CICufpXUj560IATi/o/dz07CKEVMWRIjWAtSajGE1pewlBd3v8WpgH8vIh2sN6+QkoGn+ryWZcgHkdrfn5egsgngPaVTT868wtCodChhdxPoGDay4Ogcg+bKHE/cyXptrgKkMt0b6OFOkIl/B/v/hLJ1IQtMU19HDRNrFkwO0AKv4WWodjCDIKgKac0Jn5kbXh1VqjFV8RC/JhbwL6B80NVTd7NfsOSC+CaSUHsTlSZTKRrA5zapAHEobhnQVVhPkUx4u7COdQQLqZv/dkib9ckhrMs6tEzSxjYwoGHDa6R01QEOBZfykTfh9nCOc8PpKbRZRjTWccjEmTU0D2b8rkPkcgRkh+GizHj9//POkNMsMEmS69mSK1zLgR2geZ2Z8/ouQCpksr5Y4rjSB8ctbhWuoSAvbxZdayuHJR4oW+Q=="},"endpoint":{"scope":{"type":"BearerToken","token":"Atza|IwEBIFRJu9DGNHSpvmxs5cCybV3xbDlTr6sjpBX29B4PxOuMeXc-ug0ufiSABBYejhIou81j2j--bFuyQW7sbf9hv7FwPlLURzsLibqQ16hXH83wlrIZo5oVuqcxSRXZySvzAEd2uYIUt6luyCJxabRcDndq7L4Phtpw4C4wJLe1H3HyDyOqf8GQaLM5BzXVICz359yPrNVIrvW2MF7qOaKSOa_n6mAvUBJT2gnaG7TefYW7O4Pzz-THeAX4rG1jJxm9V6rVQNEA5OZg5F5xwAQpdCWChWcWBEsuC94ao6TmZZcL-YdENC6EVRRPyRAvZDFXFukBgtXTIHuYztau7A5L1oxczKQ0bIEo0h4Bv-UrA_C0iWrLh9c8KnXgZUrA2-n-6FFyioyBZipTJ3JgSn2wiWSX21g0dj77Fky3WUkB_FlIP5WXbAxZh3hppUEGXKpK_30L0U9zhQnrNp7KvQ7mXgsx9g6ECzm-XiZtV2ZjZEcQtnWkP4M07TvWJFRFeVlJY3U"},"endpointId":"5ca22186-f33f-78f5-f311-f4eb49cbf00f7ebb"},"payload":{}}}
  2019-09-02 16:35:18 caching: MQTT2_Mi_Wecklicht-hue: set 0
[2019-9-2 4:35:18 PM] [FHEM]     caching: Hue: set 0 (as string; from 'set 0')
  2019-09-02 16:35:18 caching: MQTT2_Mi_Wecklicht-brightness: set 255
[2019-9-2 4:35:18 PM] [FHEM]     caching: Brightness: set 255 (as string; from 'set 255')
  2019-09-02 16:35:18 caching: MQTT2_Mi_Wecklicht-hue: 0
[2019-9-2 4:35:18 PM] [FHEM]     caching: Hue: 0 (as string; from '0')
  2019-09-02 16:35:18 caching: MQTT2_Mi_Wecklicht-brightness: 255
[2019-9-2 4:35:18 PM] [FHEM]     caching: Brightness: 255 (as string; from '255')

Gruß

Thomas

Zitat von: TomLee am 02 September 2019, 16:46:19
Alexa dichtet einen 100% Befehl dazu, das sieht man im Alexa-Log.

Danke für die Info, qed...

@Heimweh: Das scheint ein allgemeines Alexa-Thema zu sein und sollte ggf. separat vertieft werden - wenn nicht grade zufällig hier jemand direkt die Info hat, wie man dieses Verhalten ändern kann (ich würde eine kleine Wette anbieten, dass das irgendwie zu konfigurieren geht...).

Wenn's was größeres ist: Eine abschließende Rückmeldung, ob und wie sich das ausschalten läßt, wäre ggf. hilfreich, dann bau' ich das ins Wiki ein (vorausgesetzt, ich habe eine zündende Idee, wie es am besten zu machen ist, das betrifft ja andere via MQTT(2) anzusteuernde Leuchtmittel wie zigbee2mqtt-tint, shellybulb & Co genauso... :( ).

Guten Morgen Thomas, guten Morgen Jörg

ich hatte leider wenig Zeit, aber konnte auch feststellen dass Alexa ein "set brighntess 255" dazudichtet. Hmmm. Mal sehen ob ich was rausbekomme.

Zitat von: Beta-User am 01 September 2019, 09:08:17
....mal was anderes  :) :

Zur Info: Es gibt einen neuen Thread zur "Fremdnutzung" der Remotes:
https://forum.fhem.de/index.php/topic,103493.msg972085.html#msg972085

Bitte Fragen, Anmerkungen zu diesem Themenkomplex daher ab sofort dort anbringen :) .

Hi,

ich verzweifel grade etwas mit dem MQTT2. Bisher habe ich nur MQTT mit Mosquitto genutzt aber damit habe ich den hub überhaupt nicht einbinden können.

Nun probiere ich halt mal MQTT2 aus und es läuft auf einem anderen Port. Das Device milight_hub wird mir auch angelegt. Ich stelle das Template ein und es sieht soweit gut aus. Wenn ich nun aber das Licht (ich habe nur ein CCT Controller) schalte wird nicht etwa ein neues Device angelegt wie im Wiki beschrieben sondern einfach die JSON readings dem hub device hinzugefügt. Die readings entsprechen dann meiner lampe aber ich kann dort auch nichts schalten. Stelle ich dort dann halt mal auf das template für die cct bulb passiert einfach gar nichts.


Grüße
Dirk

Also: Du hast einen MQTT2_SERVER definiert mit einem anderen Port, da schickt der hub seine Daten hin. Soweit so gut.

Was das brige-Device angeht: Wenn das nicht "sortiert", liegt das evtl. daran, dass entweder die Einstellungen auf dem Hub nicht passen oder die bridgeRegexp auf deinen Bedarf anzupassen ist. Aber wenn das im ersten Schritt schon nicht passt, ist es eigentlich kein Wunder, dass alles weitere auch nicht geht (die regexe sind ähnlich, damit kann dann eigentlich auch die setList nicht sauber zusammengebaut werden...).

Daher bitte ein list von dem Device, in dem die Infos derzeit landen ;) . (und möglichst Info, was via MQTT kam, ist aber erst mal nicht so dringend).

Also hier ist das List direkt nach dem autocreate:

Internals:
   CFGFN     
   CID        milight_hub_11117376
   DEF        milight_hub_11117376
   DEVICETOPIC MQTT2_milight_hub_11117376
   FUUID      5d8c76ce-f33f-c2c3-00d1-afd3ef5bbbbfbfca
   IODev      MQTT2
   NAME       MQTT2_milight_hub_11117376
   NR         1032
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-09-26 10:29:02   firmware        milight-hub
     2019-09-26 10:29:02   ip_address      192.168.11.34
     2019-09-26 10:29:02   reset_reason    Software/System restart
     2019-09-26 10:29:02   status          connected
     2019-09-26 10:29:02   version         1.10.3
Attributes:
   DbLogExclude .*
   IODev      MQTT2
   readingList milight_hub_11117376:milight/LWT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE

Nun das template gesetzt:

Internals:
   CFGFN     
   CID        milight_hub_11117376
   DEF        milight_hub_11117376
   DEVICETOPIC MQTT2_milight_hub_11117376
   FUUID      5d8c76ce-f33f-c2c3-00d1-afd3ef5bbbbfbfca
   IODev      MQTT2
   NAME       MQTT2_milight_hub_11117376
   NR         1032
   STATE      <a href="http://ip_address" target="_blank">
status
</a>Version:
version
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
Attributes:
   DbLogExclude .*
   IODev      MQTT2
   autocreate 1
   bridgeRegexp milight/[^/]*at[^/]+/(0x....)/.*/([0-8])?.*:.* "milight_$1_$2"
   devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
   model      esp_milight_hub_bridge
   room       MQTT2_DEVICE
   setStateList on off
   stateFormat <a href="http://ip_address" target="_blank">
status
</a>Version:
version


Und nun mal die Lampe geschaltet:

Internals:
   CFGFN     
   CID        milight_hub_11117376
   DEF        milight_hub_11117376
   DEVICETOPIC MQTT2_milight_hub_11117376
   FUUID      5d8c76ce-f33f-c2c3-00d1-afd3ef5bbbbfbfca
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_MSGCNT 2
   MQTT2_TIME 2019-09-26 10:42:19
   MSGCNT     2
   NAME       MQTT2_milight_hub_11117376
   NR         1032
   STATE      <a href="http://ip_address" target="_blank">
status
</a>Version:
version
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-09-26 10:42:19   brightness      128
     2019-09-26 10:42:19   bulb_mode       white
     2019-09-26 10:42:19   color_b         255
     2019-09-26 10:42:19   color_g         255
     2019-09-26 10:42:19   color_r         255
     2019-09-26 10:42:19   color_temp      370
     2019-09-26 10:42:19   state           OFF
Attributes:
   DbLogExclude .*
   IODev      MQTT2
   autocreate 1
   bridgeRegexp milight/[^/]*at[^/]+/(0x....)/.*/([0-8])?.*:.* "milight_$1_$2"
   devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
   model      esp_milight_hub_bridge
   readingList milight_hub_11117376:milight/updates/0xF29/cct/1:.* { json2nameValue($EVENT) }
milight_hub_11117376:milight/states/0xF29/cct/1:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setStateList on off
   stateFormat <a href="http://ip_address" target="_blank">
status
</a>Version:
version

Du siehst er fügt einfach die Readings dem Hub Device zu.

OK; das Problem ist, dass die ID "zu kurz" ist, das template erwartet 4 hex-Stellen (hatten wir neulich schon mal, muß ich ggf. mal umstellen...)

Bitte statt (0x....) das hier in dei brigeRegexp einfügen: (0x[0-9a-fA-F]+)

Ah ok, danke. Es werden aber auch nach dem setzen des Templates im Hub Device keine Readings mehr erstellt. Siehst du evtl auch woran das liegt? Ohne das Template passen die Readings ja.

An dem list kann ich auf die Schnelle nichts sehen. Aber z.B. die IP usw. werden nur bei einem (re-) connect übertragen, da mußt du z.B. den Hub neu starten.

Sonst mal suchen, ob sich ein anderes device diesen topic "gekrallt" hat (gibt es einen Abnehmer, wird die Kette an der Stelle unterbrochen, die bridgeRegex bewirkt dann nichts mehr).

Ja klar.... Passt nun bei dem Hub. Das Light Device wurde nun auch erstellt, allerdings kann ich da nichts schalten, die readings passen aber. Woran könnte das liegen? Ich dachte mit dem Template wird alles relativ plug&play eingerichtet.

Internals:
   CFGFN     
   CID        milight_0xF29_1
   DEF        milight_0xF29_1
   DEVICETOPIC MQTT2_milight_0xF29_1
   FUUID      5d8c839f-f33f-c2c3-2651-4a25d4f255ab4cef
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_MSGCNT 2
   MQTT2_TIME 2019-09-26 11:23:45
   MSGCNT     2
   NAME       MQTT2_milight_0xF29_1
   NR         1418
   STATE      OFF
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-09-26 11:23:44   associatedWith  MQTT2_milight_hub_11117376
     2019-09-26 11:23:45   brightness      128
     2019-09-26 11:23:45   bulb_mode       white
     2019-09-26 11:23:45   color_b         255
     2019-09-26 11:23:45   color_g         255
     2019-09-26 11:23:45   color_r         255
     2019-09-26 11:23:45   color_temp      370
     2019-09-26 11:23:45   state           OFF
Attributes:
   DbLogExclude .*
   IODev      MQTT2
   readingList milight/updates/0xF29/cct/1:.* { json2nameValue($EVENT) }
milight/states/0xF29/cct/1:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE

Aber ist schon mal ziemlich schick mit MQTT2 :)

Du mußt dann wieder ein (anderes) template auf das "Bulb-Device" anwenden ;) . Damit erstellst du dann die setList (kann aber sein, dass das Schwierigkeiten gibt, weil auch dieses template von 4-er-hex ausgeht).

Das ist ja das eigenartige. Egal welches Template ich auf das Light Device anwende er erstellt nur die Reading List und sonst keine weiteren Attribute.

Ähm, eigentlich sollte da ein Dialogfeld kommen (weil die readingList nicht sauber analysiert werden kann)... Wenn du das "Wegklickst", passiert gar nichts.

Oder hast du da die Werte manuelle eingetragen?

Ich bekomme nur die Aufforderung eine Remote_ID einzugeben was ich mit der Device_ID 0x0F29 angebe.

Ich habe nun eben auch mal alles manuell definiert. Aber ich kann es nicht steuern :(

Internals:
   CFGFN     
   CID        milight_0x0F29_1
   DEF        milight_0x0F29_1
   DEVICETOPIC KuDeckeLicht
   FUUID      5d8c839f-f33f-c2c3-2651-4a25d4f255ab4cef
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_MSGCNT 33
   MQTT2_TIME 2019-09-26 13:16:33
   MSGCNT     33
   NAME       KuDeckeLicht
   NR         1418
   STATE      set_on
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-09-26 12:00:07   associatedWith  MQTT2_milight_hub_11117376
     2019-09-26 13:16:33   brightness      128
     2019-09-26 13:16:33   bulb_mode       white
     2019-09-26 13:16:33   color_b         255
     2019-09-26 13:16:33   color_g         255
     2019-09-26 13:16:33   color_r         255
     2019-09-26 13:16:33   color_temp      370
     2019-09-26 13:16:29   command         brightness_down
     2019-09-26 13:15:55   dim             set level_down
     2019-09-26 13:16:43   state           set_on
Attributes:
   DbLogExclude .*
   IODev      MQTT2
   comment    To switch device also on when changing brightness, change payload pattern to {"status":"ON","$EVTPART0":"$EVTPART1"} or add a new element to setList, similar to brightness, e.g.brightness_on and change payload pattern as described.
attr DEVICE model esp_milight_hub_cct_only_bulb
   devStateIcon {zigbee2mqtt_devStateIcon255($name)}
   eventMap   /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Faster/mode_speed_down:Slower/level_up:Up/level_down:Down/
   genericDeviceType light
   group      Licht
   icon       light_control
   model      esp_milight_hub_cct_only_bulb
   readingList milight/updates/0xF29/cct/1:.* { json2nameValue($EVENT) }
milight/updates/0xF29/cct/0:.* { json2nameValue($EVENT) }
milight/states/0xF29/cct/1:.* { json2nameValue($EVENT) }
milight/states/0xF29/cct/0:.* { json2nameValue($EVENT) }
   room       Küche,alexa
   setList    on milight/0xF29/1/cct/1 {"status":"ON"}
off milight/0xF29/1/cct/1 {"status":"OFF"}
brightness:colorpicker,BRI,0,15,255 milight/0xF29/1/cct/1 {"$EVTPART0":"$EVTPART1"}
command:uzsuSelectRadio,Weiss,Nacht milight/0xF29/1/cct/1 {"$EVTPART0":"$EVTPART1"}
program:uzsuSelectRadio,Mode,Faster,Slower milight/0xF29/1/cct/1 {"command":"$EVTPART1"}
mode:select,0,1,2,3,4,5,6,7,8 milight/0xF29/1/cct/1 {"$EVTPART0":"$EVTPART1"}
dim:uzsuSelectRadio,Up,Down milight/0xF29/1/cct/1 {"command":"$EVTPART1"}
   setStateList on off
   webCmd     brightness:dim:command:program:mode
   webCmdLabel :dim
:::

Alles was ich über den Hub direkt einstelle kommt aber zuverlässig in FHEM an.

Da ist jeweils ein "/1" zu viel in der setList, oder?

Sollte m.E. jeweils so sein:
...0xF29/cct/...

Oh... ja hast natürlich recht :)

Jetzt läuft es auch. Aber wie gesagt alles nur auf dem manuellen Weg. Aber solange das läuft ist alles gut :)

Zitat von: Dersch am 26 September 2019, 13:47:05
Jetzt läuft es auch. Aber wie gesagt alles nur auf dem manuellen Weg. Aber solange das läuft ist alles gut :)

;D jammern auf hohem Niveau, oder ;D ;D ;D ?

Ich passe die Templates mal bei Gelegenheit an, mich wundert nur, woher diese "Inflation" an "zu kurzen" ID's kommt? Ist das eine Fernbedienung oder was erfundenes?

Zitat von: Dersch am 26 September 2019, 11:35:55
Aber ist schon mal ziemlich schick mit MQTT2 :)

Thx. War vom ersten Moment an von den Socken, als ich diese Devices mit MQTT2_DEVICE genutzt habe (statt meiner eigenen "na ja" - Modulversuche (die im Übrigen stark an der XiaomiMQTTDevice-Lösung orientiert waren, die eigentlich auch nur intern Attribute für alle möglichen Devices verwaltet, soweit ich mich entsinne...)).
Und was Rudi da zwischenzeitlich dazugebastelt hat, um das "einfach" zu machen, ist auch phänomenal :) .

Kann ich eine MilightBridge V3/ V4 mit MQTT/ MQTT2 nutzen ?

Zitat von: Ingo298 am 26 September 2019, 14:23:38
Kann ich eine MilightBridge V3/ V4 mit MQTT/ MQTT2 nutzen ?

No, man braucht dazu passende hardware und die firmware von hier: https://github.com/sidoh/esp8266_milight_hub/releases

Verkabelung usw. ist einfach, ist eigentlich ein nettes Einsteigerprojekt, wenn man mal was mit einen Microcontroller gemacht haben will (am besten: ein geschieldetes "2.300m" (?) -nRF24-Modul verwenden)

Zitat von: Beta-User am 26 September 2019, 14:14:02
;D jammern auf hohem Niveau, oder ;D ;D ;D ?

Ich passe die Templates mal bei Gelegenheit an, mich wundert nur, woher diese "Inflation" an "zu kurzen" ID's kommt? Ist das eine Fernbedienung oder was erfundenes?

nee das ist keine FB. Das ist einfach der CCT Controller.

Leider funktioniert der night_mode überhaupt nicht und ich blicke nicht woran das liegt. Er meint auch Unknown argument night_mode, choose one of on off brightness command program mode dim on-for-timer on-till-overnight off-for-timer intervals off-till toggle blink off-till-overnight on-till attrTemplate wenn ich set Nacht ausführe. Aber es müsste ja eh im MQTT Telegramm command night_mode heißen. Irgendwie durchschaue ich das MQTT mit dem Milight Hub noch nicht so richtig. Das ist so gar nicht das MQTT welches ich kenne :)

 ;D .

Nee, das mit night_mode usw. ist eigentlich "normales" "Dummy-Gefrickel", das hat mit MQTT (im Prinzip) nichts zu tun ;D :P .

Da müssen schlicht die ganzen Attribute zur Darstellung zusammenpassen, einschl. eventMap (das macht aus "Nacht" "night_mode") usw..
Aber auf die Schnelle tue ich mir da auch schwer, das zu rekonstruieren, was für was ist und wie die Zusammenhänge im einzelnen sind ;D .

Will auch nicht ausschließen, dass da noch Optimierungsbedarf besteht, ich habe keine cct-Devices (abgesehen von der Fernbedienung, die ich für andere Zwecke mißbrauche...), und kann/konnte daher nicht testen, sondern nur übernehmen, was mir zugerufen worden ist.

Bei mir gibt es mit CCTs genauso flüssig wie mit den RGBs. Kein Unterschied. Also was das anlegen nach dem Wiki Eintrag angeht....  Ich teste das heute Abend Mal mit dem Nightmode

Gesendet von meinem LYA-L29 mit Tapatalk

Thx. Habe eben auch nochmal das rgbw-template mit dem cct verglichen. Müßte eigentlich passen, wenn man es so macht, wie im template ??? .

(Aber richtig: den Wiki-Betrag habe ich dahingehend schon lange nicht mehr auf Aktualität geprüft. Andererseits sind das sind schon "ewig" praktisch unveränderte Dinge. Müßte daher "eigentlich" gehen.)

---

Übrigens: Habe vorhing beim Verlinken gesehen, dass firmware V 1.10.3 draußen ist. Da wurde nochmal was an dem transition-Thema gemacht. Wenn da jemand was Beisteuern mag (soft-on, z.B.), wäre das nett. Habe grade andere Baustellen, als das auszutesten, was ich selbst nicht nutze ;D .

Ich nutze die 1.10.3 ... In meinem Beitrag von 30.08 hatte ich es ja bereits berichtet - die Transition ist sehr sehr grob aufgelöst. Der Effekt wird eher wie ein Wackelkontakt als ein dimmen....

Gesendet von meinem LYA-L29 mit Tapatalk

Ok, also immer noch eher schlecht brauchbar, trotz updates in der firmware... Dann muß es auch (noch) nicht in ein template :( .

Ich hatte leider wenig Zeit bisher, werde es mal noch mit anderen Milight Typen probieren. Das Thema mit der Helligkeit und Alexa ist auch noch offen... Muss ich auch mal weiter treiben...

Gesendet von meinem LYA-L29 mit Tapatalk

Kurze Zwischeninfo: Habe die regexe jetzt (hoffentlich) so angepaßt, dass auch kürzere als 4-stellige hex-ID's keine Probleme mehr machen sollten, ist ab morgen früh/8:00 Uhr per update verfügbar.

[OT]
Bei den shelly's haben wir grade eine nette Diskussion, wie man mit Power-messenden Geräten sinnvoll umgehen kann, was Visualisierung und Steuerbarkeit angeht. Wenn's jemanden interessiert (auch wenn derjenige ggf. keine Shellys hat), die Beiträge sind ab hier (https://forum.fhem.de/index.php/topic,94060.msg977865.html#msg977865) zu finden. Das sollte sich nämlich recht einfach z.B. auf tasmota und zigbee2mqtt übertragen lassen ;) .
[/OT]

Irgendwie läuft bei mir gerade nichts mehr mit meinen Milights... Ich wollte gerade ein neues Milight Device in FHEM einrichten, aber dieses wurde nicht erkannt. Also habe ich erstmal alles was mit Milight zu tun hat aus der Config geschmissen und wollte alles mal neu erkennen lassen bzw. einrichten. Das hat damals super funktioniert, jetzt aber leider überhaupt nicht mehr.
Hier mal mein vorgehen:
- Beim ersten Tastendruck auf eine Milight Fernbedienung, wird der Milight-Hub in FHEM erkannt (drücke auf "Save Config")
- Ich gehe in das Hub-Device und wähle das Template "esp_milight_hub_bridge" aus (drücke auf "set" & "Save Config")
Nun sieht das Device in der FHEM-Config wie folgt aus:
define MQTT2_milight_hub_5916066 MQTT2_DEVICE milight_hub_5916066
setuuid MQTT2_milight_hub_5916066 5d965255-f33f-d11a-1b53-724ece91a77c5be4
attr MQTT2_milight_hub_5916066 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_5916066 autocreate 1
attr MQTT2_milight_hub_5916066 bridgeRegexp milight_hub_5916066:milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr MQTT2_milight_hub_5916066 devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr MQTT2_milight_hub_5916066 model esp_milight_hub_bridge
attr MQTT2_milight_hub_5916066 room MQTT2_DEVICE
attr MQTT2_milight_hub_5916066 setStateList on off
attr MQTT2_milight_hub_5916066 stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version

- Ich drücke nochmal eine Taste auf der Milight Fernbedienung und das Milight Device wird erkannt (drücke auf "Save Config")
So sieht das erkannte Device dann erstmal in der Config aus:
define MQTT2_milight_0x6A18_1 MQTT2_DEVICE milight_0x6A18_1
setuuid MQTT2_milight_0x6A18_1 5d9652b1-f33f-d11a-e668-3135dae0d0d335df
attr MQTT2_milight_0x6A18_1 IODev MQTT2_FHEM_Server
attr MQTT2_milight_0x6A18_1 readingList milight/updates/0x6A18/fut091/1:.* { json2nameValue($EVENT) }\
milight/states/0x6A18/fut091/1:.* { json2nameValue($EVENT) }
attr MQTT2_milight_0x6A18_1 room MQTT2_DEVICE

- Ich gehe in das neu erkannte Milight Device und wähle das pasende Template aus. Hier erscheint nun beim drücken auf "set" folgende Meldung: Error checking template regexp: Unmatched ( in regex; marked by <-- HERE in m/([^/]+)[/]( <-- HERE 0x[0-9a-fA-F]{1/ at (eval 1090) line 1.

Was läuft da schief ?!  :-\

Danke für's melden. Da ist ein Ersetzungsmechanismus in AttrTemplate drin, den ich übersehen hatte, sorry.

So sollte es gehen:
par:REMOTE_ID;HEX number representing a specific remote or bridge;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/](0x[0-9a-fA-F]{1\,4})[/].*:, ? $2 : undef }

Update kommt dann demnächst.

Super, danke ! Ich werds dann testen.

So, hab gerade in FHEM ein Update gemacht und jetzt kann ich die Milights wieder wie gewohnt einbinden. Was mir allerdings noch komisch vorkommt ist, dass bei dem Milight_Hub Device kein DevStateicon angezeigt wird, sondern nur der Text "status Version: version"; laut Config sollte das ja anders sein.
Hier nochmal die Config des Milight_Hub Devices:
define MQTT2_milight_hub_5916066 MQTT2_DEVICE milight_hub_5916066
setuuid MQTT2_milight_hub_5916066 5d988380-f33f-d11a-2165-129e952ff04f3a94
attr MQTT2_milight_hub_5916066 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_5916066 autocreate 1
attr MQTT2_milight_hub_5916066 bridgeRegexp milight_hub_5916066:milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr MQTT2_milight_hub_5916066 devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr MQTT2_milight_hub_5916066 model esp_milight_hub_bridge
attr MQTT2_milight_hub_5916066 room MQTT2_DEVICE
attr MQTT2_milight_hub_5916066 setStateList on off
attr MQTT2_milight_hub_5916066 stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version

Muss ich bei dem stateFormat die IP der Bridge einfügen ?!   ???

Schön, dass das jetzt wieder reibungslos läuft.

Wenn die ip_address nicht aufgelöst wird, liegt das daran, dass entweder der Hub nicht neu gestartet wurde, LWT nicht konfiguriert oder eine ältere firmware drauf ist. Seit einigem Monaten gibt es diese Infos via LWT, näheres sollte bei den Praxisbeispielen zu finden sein.

Es lag an LWT, das war auf dem Hub noch nicht konfiguriert.

Mal eine Frage, ob jemand eine Idee hat, wie ich folgendes am besten umsetze...
Ich habe zwei Milight Fernbedienungen, die beide auf die gleiche Lampe angelert sind. In Fhem sind beide Fernbedienungen angelegt, aber eben jeweils als eine eigenständige "Lampe". Wenn ich die Physische Lampe nun an einer Fernbedienung ein- und an der anderen aus-schalte, habe ich in fhem eine Lampe die mir als "an" und eine die mir als "aus" dargestellt wird. Kann man diese Schaltzustände irgendwie kombinieren ? Klar, das irgendwie über zwei notifys zu basteln würde gehen, aber gehts auch irgendwie "eleganter" ?

Nur ein devices benutzen. Dort bei den attr die mqtt Channels beider remote. Nur Update, nicht Status.

Danke für den Tipp, hat funktioniert.

Dafür habe ich jetzt ein neues Problem: Ich habe gerade in FHEM ein Update gemacht und seitdem funktioniert nun der night_mode bei allen Milights nicht mehr. Wenn ich in ein Milight Device hinein gehe und dort "Nacht" auswähle und auf "set" klicke, bekomme ich folgende Fehlermeldung: Unknown argument night_mode, choose one of on off brightness command program mode dim off-till off-for-timer on-till-overnight blink on-for-timer intervals on-till off-till-overnight toggle attrTemplate

Das mit den "doppelten" Abonnements ist jetzt auch im Wiki ergänzt, falls nochmal jemand darüber stolpert. Ist aber mMn nicht auf updates begrenzt, gibt halt nur uU. doppelte Events, wenn man beides subscribed.

Was das mit dem night_mode angeht: Bitte ein RAW von dem ganzen Device, eigentlich sollte das über die diversen Attribute am Ende via setList nach command gemappt werden...

Zitat von: Beta-User am 11 November 2019, 15:02:34
Das mit den "doppelten" Abonnements ist jetzt auch im Wiki ergänzt, falls nochmal jemand darüber stolpert. Ist aber mMn nicht auf updates begrenzt, gibt halt nur uU. doppelte Events, wenn man beides subscribed.

Wiki: great idea, Danke.

Update vs state: wenn man auch die states abonniert stimmt der Zustand in fhem nicht. "Nur updates" stellt sicher das fhem und die echte Lampe das gleiche sehen/machen.

 :) Das mit den doppelten readingList-Einträgen ist zwar auch Bestandteil der templates (die "0" wird in der Regel mit erfaßt), aber scheinbar erschließt sich der Zusammenhang nicht gleich.

Was "updates"/"states" angeht: das kommt vermutlich darauf an, wie man die settings auf dem Hub eingestellt hat.
Bei updates kommt nur die Differenz, bei states halt der ganze Satz (aber afaik auch vollständig). MMn. schadet es tendenziell nicht, beides reinzuschreiben (jedenfalls dann, wenn beides kommt). Je nachdem, ob man einen Eventhandler dran hängen hat, muß man halt darauf achten, dass man entweder einen der Zweige stilllegt (wie bei der FB-Lösung beschrieben) oder diesen kurzzeitig "taub" stellt, sonst hat man doppelte Events auf die Differenzsätze....

Hier mal die Config des Milight-Hubs und des Milight-Device... Ich glaube aber nicht, dass es an der Config selbst liegt. Ich habe mal ein bisschen rumprobiert und habe folgendes Verhalten festgestellt:
Ich lösche das Milight-Device aus der Config, speichere und mache einen shutdown, restart. Dann spiele ich die Config wieder zurück und mache wieder einen sutdown, restart. Jetzt funktioniert der night_mode. Warte ich jetzt ein wenig, bis das Milight-Device readings vom Milight-Hub empfängt, funktioniert der night_mode danach nicht mehr.  :o

Milight-Hub:
define MQTT2_milight_hub_5916066 MQTT2_DEVICE milight_hub_5916066
setuuid MQTT2_milight_hub_5916066 5dc879ba-f33f-d11a-720f-26a15adcc81099c9
attr MQTT2_milight_hub_5916066 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_5916066 autocreate 1
attr MQTT2_milight_hub_5916066 bridgeRegexp milight_hub_5916066:milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr MQTT2_milight_hub_5916066 devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr MQTT2_milight_hub_5916066 model esp_milight_hub_bridge
attr MQTT2_milight_hub_5916066 readingList milight_hub_5916066::.* { json2nameValue($EVENT) }\
milight_hub_5916066:milight/LWT:.* { json2nameValue($EVENT) }
attr MQTT2_milight_hub_5916066 room IO-Devices
attr MQTT2_milight_hub_5916066 setStateList on off
attr MQTT2_milight_hub_5916066 stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version
define FileLog_MQTT2_milight_hub_5916066 FileLog ./log/MQTT2_milight_hub_5916066-%Y.log MQTT2_milight_hub_5916066
setuuid FileLog_MQTT2_milight_hub_5916066 5dc879ba-f33f-d11a-0d96-cb095e33d03ca72c
attr FileLog_MQTT2_milight_hub_5916066 logtype text
attr FileLog_MQTT2_milight_hub_5916066 room Logs


Milight-Device:
define Treppe_Licht MQTT2_DEVICE milight_0x137A_1
setuuid Treppe_Licht 5dc87a58-f33f-d11a-e728-551fe171a65ba82b
attr Treppe_Licht IODev MQTT2_FHEM_Server
attr Treppe_Licht alexaName Treppenlicht
attr Treppe_Licht comment To switch device also on when changing brightness, change payload pattern to {"status":"ON","$EVTPART0":"$EVTPART1"} or add a new element to setList, similar to brightness, e.g.brightness_on and change payload pattern as described.
attr Treppe_Licht devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr Treppe_Licht eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Faster/mode_speed_down:Slower/level_up:Up/level_down:Down/
attr Treppe_Licht genericDeviceType light
attr Treppe_Licht icon light_control
attr Treppe_Licht model esp_milight_hub_cct_only_bulb
attr Treppe_Licht readingList milight/states/0x137A/fut091/1:.* { json2nameValue($EVENT) }\
  milight/states/0x137A/fut091/0:.* { json2nameValue($EVENT) }\
  milight/updates/0x137A/fut091/1:.* { json2nameValue($EVENT) }\
  milight/updates/0x137A/fut091/0:.* { json2nameValue($EVENT) }\
  milight/updates/0x1940/fut091/1:.* { json2nameValue($EVENT) }\
  milight/updates/0x1940/fut091/0:.* { json2nameValue($EVENT) }
attr Treppe_Licht room Alexa,Flur
attr Treppe_Licht setList on:noArg milight/0x137A/fut091/1 {"status":"ON"}\
  off:noArg milight/0x137A/fut091/1 {"status":"OFF"}\
  brightness:colorpicker,BRI,0,15,255 milight/0x137A/fut091/1 {"$EVTPART0":"$EVTPART1"}\
  command:uzsuSelectRadio,Weiss,Nacht milight/0x137A/fut091/1 {"$EVTPART0":"$EVTPART1"}\
  program:uzsuSelectRadio,Mode,Faster,Slower milight/0x137A/fut091/1 {"command":"$EVTPART1"}\
  mode:select,0,1,2,3,4,5,6,7,8 milight/0x137A/fut091/1 {"$EVTPART0":"$EVTPART1"}\
  dim:uzsuSelectRadio,Up,Down milight/0x137A/fut091/1 {"command":"$EVTPART1"}
attr Treppe_Licht setStateList on off
attr Treppe_Licht webCmd brightness:dim:command:program:mode
attr Treppe_Licht webCmdLabel :dim\
  :::
define FileLog_Treppe_Licht FileLog ./log/Treppe_Licht-%Y.log Treppe_Licht
setuuid FileLog_Treppe_Licht 5dc87a58-f33f-d11a-c358-2c2acee45a57d89b
attr FileLog_Treppe_Licht logtype text
attr FileLog_Treppe_Licht room Logs


Hmm, eventuell kommt das auch von der Hub-Seite?

Ist das die letzte Version? (1.10.4?)

Kannst du mal den MQTT-Verkehr abhören? Kann mir kaum vorstellen, dass der Empfang von Daten die Sendeseite im MQTT2_DEVICE-Modul verbiegt...
(Wenn FHEM erwartungsgemäß sendet und alles aktuell ist, wäre es mMn. Zeit für einen PR im sidoh-github-Repo).

Ich habe gerade noch mal ein bisschen rumprobiert... Die Funktionen der Gruppe Command wie night_mode, white usw. verlieren immer wieder ihre Funktion. Drückt man nun einen Button der Gruppe Program (z.B. set_faster) funktioniert die Gruppe Command für einen Tastendruck auf z.B. night_mode wieder, danach aber auch wieder nicht mehr.

Version der Bridge ist aktuell 1.10.4, davor hatte ich die 1.10.3 drauf, da hatte ich aber das gleiche Problem. Wenn es einfach nicht funktionieren würde, könnte ich mir ein Problem der Bridge vorstellen, aber dann wäre die Fehlermeldung von FHEM komisch (Unknown argument....)

Edit: Was immer funktioniert ist: set Treppe_Licht command Nacht    ...kann es sein, dass es bei den CCT_Only Controllern keine Kommandos wie Mode, faster, slower gibt und daher die Probleme auftreten ???

Weiß auch nicht recht; habe den Eindruck, es muß halt einfach eine Änderung zum bestehenden Zustand sein; von den ganzen Kommandos nutze ich effektiv eigentlich sowieso nur den "Weiß"-Befehl, und tendenziell ziehe ich grade sowieso das meiste nach ZigBee um...

Hallo,
ich habe seit ein paar Tagen einen milight hub und ich kriege den nicht in FHEM eingebunden.
Heute habe ich beim Hub die Version 1.10.5. eingespielt und FHEM aktualisiere ich auch regelmaessig.
Mit der Weboberflaeche des Hubs kann ich bereits ein paar Lampen steuern.
Beim Hub habe ich in den Settings fuer MQTT Server die IP Adresse des Raspberrys angegeben auf dem FHEM laeuft und unter MQTT Client Status Topic milight/LWT
In FHEM habe ich Server angelegt - der sieht so aus :
defmod MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server autocreate simple
attr MQTT2_FHEM_Server room Wohnzimmer

setstate MQTT2_FHEM_Server 2019-11-17 21:38:55 RETAIN {"_milight":"{\u0022status\u0022:\u0022connected\u0022,\u0022firmware\u0022:\u0022milight-hub\u0022,\u0022version\u0022:\u00221.10.4\u0022,\u0022ip_address\u0022:\u0022192.168.20.26\u0022,\u0022reset_reason\u0022:\u0022Power on\u0022}","_milight/LWT_":"{\u0022status\u0022:\u0022connected\u0022,\u0022firmware\u0022:\u0022milight-hub\u0022,\u0022version\u0022:\u00221.10.4\u0022,\u0022ip_address\u0022:\u0022192.168.20.26\u0022,\u0022reset_reason\u0022:\u0022Power on\u0022}","milight/LWT":"{\u0022status\u0022:\u0022connected\u0022,\u0022firmware\u0022:\u0022milight-hub\u0022,\u0022version\u0022:\u00221.10.5\u0022,\u0022ip_address\u0022:\u0022192.168.20.26\u0022,\u0022reset_reason\u0022:\u0022Software/System restart\u0022}"}
setstate MQTT2_FHEM_Server 2019-11-17 21:38:55 nrclients 1
setstate MQTT2_FHEM_Server 2019-11-17 21:31:20 state Initialized

Wenn ich dann ueber den Hub schalte wird ein MQTT2 Device angelegt. Ich das Template esp_milight_hub_bridge angewendet und beim Dialog, der dann aufgeht ganz hinten milight statt der BASE_ID eingegeben. Dann Save Config.

Soweit so gut. Wenn ich jetzt weiter rumklickt am Hub passiert leider gar nichts mehr. Es sollten nach meinem Verstaendnis weitere Devices angelegt werden auf die ich dann das passende Template anwenden kann. Ich hab das ganze schon ein paar mal durchgespielt. Raspberry neu gestartet, Hub neu gestartet, andere Kanaele am Hub getestet ...

Das angelegte Device nach dem Template anwenden sieht so aus.
Internals:
   CID        milight_hub_4843955
   DEF        milight_hub_4843955
   DEVICETOPIC MQTT2_milight_hub_4843955
   FUUID      5dd1ad35-f33f-3eb3-6ea0-c152e0f0019fcd85
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 3
   MQTT2_FHEM_Server_TIME 2019-11-17 21:38:55
   MSGCNT     3
   NAME       MQTT2_milight_hub_4843955
   NR         592
   STATE      <a href="http://192.168.20.26" target="_blank">
connected
</a>Version:
1.10.5
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-11-17 21:38:55   firmware        milight-hub
     2019-11-17 21:38:55   ip_address      192.168.20.26
     2019-11-17 21:38:55   reset_reason    Software/System restart
     2019-11-17 21:38:55   status          connected
     2019-11-17 21:38:55   version         1.10.5
Attributes:
   IODev      MQTT2_FHEM_Server
   autocreate 1
   bridgeRegexp milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
   devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
   model      esp_milight_hub_bridge
   readingList milight_hub_4843955:milight/LWT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setStateList on off
   stateFormat <a href="http://ip_address" target="_blank">
status
</a>Version:
version


Es wird noch ein Device automatisch angelegt MQTT2_FHEM_Server_192.168.20.26_49156 mit dem Status connected und ein bisschen config
milight/LWT:{"status":"disconnected_unclean","firmware":"milight-hub","version":"1.10.5","ip_address":"192.168.20.26","reset_reason":"Software/System restart"}

Was mache ich vielleicht falsch ? Habe ich was nicht richtig verstanden ? Hat jemand eine Idee ?
Viele Gruesse quakosekiki

Welche Einstellungen hast du denn für state und update-Topics auf dem Hub? (Scheint, dass da jetzt neuerdings (?) nichts mehr drin steht; dann wie hier (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#cite_note-12) aufgeführt vergeben...).

Ansonsten: Relevant sind nur MQTT2_DEVICE-Geräte, die temporären Server-Instanzen sind normal und (für den User) nicht von Bedeutung.

Da habe ich nichts weiter eingestellt - habe mich auch erst gewundert, dass da so viele leere Felder sind - gucke ich mir nochmal an morgen Abend - danke fuer die schnelle Antwort !

Moin,
ich hab wieder ein bisschen probiert - und ich bin weiter gekommen :-)
die Config auf dem Hub uebernommen :
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
MQTT Client Status Topic: milight/LWT
username, password und HomeAssistant MQTT Discovery Prefix sind leer
status, brightness, hue, color, mode, color_temp, bulb_mode, computed_color, hex_color habe ich gesetzt als group state fields.
Alle Devices geloescht und FHEM neu gestartet. In der Milight Hub Weboberflaeche etwas geschaltet und es wird ein Device erzeugt. Das Template esp_milight_hub_bridge ausgewaehlt und set geklickt - es passiert nicht viel. Das einfach nochmal gemacht und dann fragt er im Popup auch, dass ich DEVIE_ID mit milight ersetzen soll - danach hab ich ein Device, das so aussieht, wie sonst auch.
Dann save und neustart und wieder etwas geschaltet - und es wird wieder ein device erzeugt - super - das ging vorher noch nicht. Da dann das template esp_milight_rgbw_bulb angewendet und es wird ein schoenes Control dazu erzeugt.
Wieder save und Neustart.
Nur leider passiert nichts, wenn ich im Control rumklicke. Ich habe beim Milight Hub das Sniffing eingestellt - da wird auch nichts angezeigt, also wird auch nichts  gesendet. Scheint also noch an der Kommunikation von FHEM zum Hub zu liegen.
Im Log ifindet sich das hier :
2019.11.20 20:25:19 2: autocreate: define MQTT2_milight_0x74B_3 MQTT2_DEVICE milight_0x74B_3 MQTT2_FHEM_Server
2019.11.20 20:25:19 2: autocreate: define FileLog_MQTT2_milight_0x74B_3 FileLog ./log/MQTT2_milight_0x74B_3-%Y.log MQTT2_milight_0x74B_3
2019.11.20 20:26:09 2: autocreate: define MQTT2_milight_0x74B_2 MQTT2_DEVICE milight_0x74B_2 MQTT2_FHEM_Server
2019.11.20 20:26:09 2: autocreate: define FileLog_MQTT2_milight_0x74B_2 FileLog ./log/MQTT2_milight_0x74B_2-%Y.log MQTT2_milight_0x74B_2
Im Log vom Device steht :
2019-11-20_20:40:40 MQTT2_milight_0x74B_2 attrTemplate esp_milight_hub_rgbw_bulb
2019-11-20_20:40:50 MQTT2_milight_0x74B_2 set_off
2019-11-20_20:40:52 MQTT2_milight_0x74B_2 set_on
Und im Log vom Hub :
2019-11-20_20:39:12 MQTT2_milight_hub_4843955 attrTemplate esp_milight_hub_bridge
2019-11-20_20:39:51 MQTT2_milight_hub_4843955 status: connected
2019-11-20_20:39:51 MQTT2_milight_hub_4843955 ip_address: 192.168.20.26
2019-11-20_20:39:51 MQTT2_milight_hub_4843955 firmware: milight-hub
2019-11-20_20:39:51 MQTT2_milight_hub_4843955 version: 1.10.5
2019-11-20_20:39:51 MQTT2_milight_hub_4843955 reset_reason: Software/System restart
Auch einen anderen Kanal im Hub und das rgbw_cct Template getestet oder nur einmal das set template beim Hub durchgefuehrt - das gleiche. Ich poste mal noch die beiden erzeugten Devices. Hab ich noch was falsch gemacht ?

IODev

MQTT2_FHEM_Server

deleteattr
autocreate

1

deleteattr
bridgeRegexp

milight_hub_4843955:milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"

deleteattr
devStateIcon

connected:10px-kreis-gruen disconnected.*:10px-kreis-rot

deleteattr
model

esp_milight_hub_bridge

deleteattr
readingList

milight_hub_4843955:milight/LWT:.* { json2nameValue($EVENT) }

deleteattr
room

MQTT2_DEVICE

deleteattr
setStateList

on off

deleteattr
stateFormat


<a href="http://ip_address" target="_blank">
status
</a>Version:
versionIODev

MQTT2_FHEM_Server

deleteattr
comment

To switch device also on when changing brightness, change payload pattern to {"status":"ON","$EVTPART0":"$EVTPART1"} or add a new element to setList, similar to brightness, e.g.brightness_on and change payload pattern as described.

deleteattr
devStateIcon

{zigbee2mqtt_devStateIcon255($name,"hex",1)}

deleteattr
eventMap

/set_white:Weiss/night_mode:Nacht/white_mode:white/

deleteattr
icon

light_control

deleteattr
model

esp_milight_hub_rgbw_bulb

deleteattr
readingList


milight/states/0x74B/rgb_cct/2:.* { json2nameValue($EVENT) }
  milight/states/0x74B/rgb_cct/0:.* { json2nameValue($EVENT) }
  milight/updates/0x74B/rgb_cct/2:.* { json2nameValue($EVENT) }
  milight/updates/0x74B/rgb_cct/0:.* { json2nameValue($EVENT) }


deleteattr
room

MQTT2_DEVICE

deleteattr
setExtensionsEvent

1

deleteattr
setList


on:noArg milight/0x74B/rgb_cct/2 {"status":"ON"}
  off:noArg milight/0x74B/rgb_cct/2 {"status":"OFF"}
  brightness:colorpicker,BRI,0,15,255 milight/0x74B/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}
  hue:colorpicker,HUE,0,1,359 milight/0x74B/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}
  command:uzsuSelectRadio,Weiss,Nacht milight/0x74B/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}


deleteattr
setStateList

on off

deleteattr
userReadings

hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}

deleteattr
webCmd

brightness:hue:command

Versuch's mal mit

ZitatMQTT topic pattern : milight/:hex_device_id/:device_type/:group_id

(Dein Post ist übrigens nicht besonders gut zu lesen, etwas mehr Formatierung wäre noch möglich, und v.a. nimm "RAW"-Code zum posten (für MQTT2_DEVICE => https://wiki.fhem.de/wiki/Raw_definition), oder sonst - für andere Module - den output von "list")

Sorry fuer die Formatierung und danke fuer den Tip.

Also das Topic umkonfiguriert, alles geloescht und wieder neu angelegt.
Was mir aufgefallen ist - wenn ich im Webinterface des Milight Hubs an- oder ausschalte, wird das im State vom Device in FHEM auch angezeigt.

Aber wenn ich in FHEM schalte, passiert nichts und im Sniffer des Hubs taucht auch nichts auf.

Das Device sieht jetzt so aus (als Raw Output) :
defmod MQTT2_milight_0x74B_2 MQTT2_DEVICE milight_0x74B_2
attr MQTT2_milight_0x74B_2 IODev MQTT2_FHEM_Server
attr MQTT2_milight_0x74B_2 comment To switch device also on when changing brightness, change payload pattern to {"status":"ON","$EVTPART0":"$EVTPART1"} or add a new element to setList, similar to brightness, e.g.brightness_on and change payload pattern as described.
attr MQTT2_milight_0x74B_2 devStateIcon {zigbee2mqtt_devStateIcon255($name,"hex",1)}
attr MQTT2_milight_0x74B_2 eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/
attr MQTT2_milight_0x74B_2 icon light_control
attr MQTT2_milight_0x74B_2 model esp_milight_hub_rgbw_bulb
attr MQTT2_milight_0x74B_2 readingList milight/states/0x74B/rgb_cct/2:.* { json2nameValue($EVENT) }\
  milight/states/0x74B/rgb_cct/0:.* { json2nameValue($EVENT) }\
  milight/updates/0x74B/rgb_cct/2:.* { json2nameValue($EVENT) }\
  milight/updates/0x74B/rgb_cct/0:.* { json2nameValue($EVENT) }
attr MQTT2_milight_0x74B_2 room MQTT2_DEVICE
attr MQTT2_milight_0x74B_2 setExtensionsEvent 1
attr MQTT2_milight_0x74B_2 setList on:noArg milight/0x74B/rgb_cct/2 {"status":"ON"}\
  off:noArg milight/0x74B/rgb_cct/2 {"status":"OFF"}\
  brightness:colorpicker,BRI,0,15,255 milight/0x74B/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}\
  hue:colorpicker,HUE,0,1,359 milight/0x74B/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}\
  command:uzsuSelectRadio,Weiss,Nacht milight/0x74B/rgb_cct/2 {"$EVTPART0":"$EVTPART1"}
attr MQTT2_milight_0x74B_2 setStateList on off
attr MQTT2_milight_0x74B_2 userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
attr MQTT2_milight_0x74B_2 verbose 5
attr MQTT2_milight_0x74B_2 webCmd brightness:hue:command

setstate MQTT2_milight_0x74B_2 set_off
setstate MQTT2_milight_0x74B_2 2019-11-20 23:14:20 associatedWith MQTT2_milight_hub_4843955
setstate MQTT2_milight_0x74B_2 2019-11-20 23:18:42 brightness 255
setstate MQTT2_milight_0x74B_2 2019-11-20 23:18:42 bulb_mode white
setstate MQTT2_milight_0x74B_2 2019-11-20 23:18:42 color_b 255
setstate MQTT2_milight_0x74B_2 2019-11-20 23:18:42 color_g 255
setstate MQTT2_milight_0x74B_2 2019-11-20 23:18:42 color_r 255
setstate MQTT2_milight_0x74B_2 2019-11-20 23:18:42 color_temp 153
setstate MQTT2_milight_0x74B_2 2019-11-20 23:18:42 hex FFFFFF
setstate MQTT2_milight_0x74B_2 2019-11-20 23:18:42 hue 0
setstate MQTT2_milight_0x74B_2 2019-11-20 23:18:48 state set_off
setstate MQTT2_milight_0x74B_2 2019-11-20 23:18:42 status ON



Ich habe mal verbose auf 5 gestellt im Device - dann finden sich im allgemeinen Log noch solche Eintraege - aber auch daraus bin ich nicht so richtig schlau geworden :

2019.11.20 23:18:42 4: MQTT2_DEVICE_Parse: MQTT2_milight_0x74B_2 milight/states/0x74B/rgb_cct/2 => { json2nameValue($EVENT) }

Noch eine andere Idee vielleicht ? Ich wuerde mich wirklich freuen, wenn ich den Hub mit FHEM ans Laufen kriegen wuerde ...

Imo sind Kommunikationsprobleme zum HUB auf der WLAN-Ebene die wahrscheinlichste Ursache. Hast du >20 WLAN-Geräte und eine Fritzbox?

Evtl. bricht auch die Spannungsversorgung weg, aber da das funktioniert, wenn du das auf dem Web-IF machst, ist das nicht eben wahrscheinlich.

Ansonsten könnte es noch mit der Länge der ID zusammenhängen. Ich nutze grundsätzlich 4-stellige, deine hat nur drei (sollte dem Vernehmen nach aber gehen).
Sonst bin ich ziemlich ratlos, bei mir scheint soweit alles zu laufen (1.10.5), aber mit den durchgängigen ":device_id"-Vorgaben wie im Wiki vermerkt, nicht mit "hex". Sollte aber keinen Unterschied machen, aber evtl. hat die firmware da einen Hau...

Hi,
ich habe einige WLAN Geraete - aber auf verschiedene SSIDs aufgeteilt. In diesem WLAN sind <10 Geraete und der Raspberry steht im gleichen VLAN. Die Hardware ist von Unifi (Switch, AP, Router).
Ich habe auch Geraete mit 4 stelligen IDs neu angelegt und die getestet - kein Unterschied. Die Dreistelligen sind die, die ich von der vorhandenen Fernsteuerung uebernommen hatte.
Vorher hatte ich das schon mit der 1.10.4 getestet - vielleicht versuche ich mal eine noch aeltere Version fuer den Hub zu finden - vielleicht gibt es da noch andere Default Eintraege in der Config, die mir fehlen.
Das mit der Stromversorgung hatte ich auch schon gelesen - ich teste einfach nochmal eine andere.
Wo kann ich vielleicht noch suchen um das zu debuggen ? Ich wuerde als naechstes mal beim MQQT Server debug auf 5 setzen, dann muesste ich alle Messages mitlesen koennen ...
Viele Gruesse quakosekiki

Hi,
ich habe noch etwas weiter getestet - vom PC aus mit einem Client (mqttfx) messages mitgelesen und abgeschickt - da funktioniert alles - ganz schoen um zu sehen, was da so passiert.
Jetzt habe ich im milight Hub alle Eintraege mit 3 stelligen IDs geloescht. Und im FHEM auch alles geloescht. Dann geht es :-) !! Genauso wie beschrieben.
Vielen Dank fuer die Hilfe und Gruesse quakosekiki

Zitat von: Heimweh am 26 September 2019, 17:01:51
Ich nutze die 1.10.3 ... In meinem Beitrag von 30.08 hatte ich es ja bereits berichtet - die Transition ist sehr sehr grob aufgelöst. Der Effekt wird eher wie ein Wackelkontakt als ein dimmen....

Gesendet von meinem LYA-L29 mit Tapatalk

Hallo Beta-User,

ich war jetzt lange mit anderen Dingen beschäftigt, aber da ich gerade krank geschrieben bin konnte ich mich nochmal mit dem Thema "Transition" (auf und abdimmen) befassen.
Ich habe das mit einer Milight RGB+CCT - wenn man die Zeit mit 3 Sekunden aufwärts wählt, sieht es garnicht schlecht aus.

Falls es irgendjemand interessiert, muss man bei Atribut setlist den Befehl "transition" mit einbauen:


on:noArg milight/0x3256/rgb_cct/4 {"status":"ON","transition":3}
off:noArg milight/0x3256/rgb_cct/4 {"status":"OFF","transition":3}


das ganze Gerät:


Internals:
   CID        milight_0x3256_4
   DEF        milight_0x3256_4
   DEVICETOPIC MQTT2_milight_0x3256_4
   FUUID      5cf6b263-f33f-55ed-7a6d-93b454a890c11f7d
   IODev      MQTTServer
   LASTInputDev MQTTServer
   MQTTServer_MSGCNT 1410
   MQTTServer_TIME 2020-02-05 20:08:17
   MSGCNT     1410
   NAME       MQTT2_milight_0x3256_4
   NR         484
   STATE      off
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2020-02-05 19:32:01   OFF             set
     2020-02-05 20:08:17   brightness      0
     2020-02-05 20:08:17   bulb_mode       color
     2020-02-05 19:55:36   color_b         255
     2020-02-05 19:55:36   color_g         255
     2020-02-05 20:08:17   color_r         255
     2020-02-05 19:55:36   color_temp      366
     2020-02-05 19:53:05   command         set set_white
     2020-02-05 19:55:36   device_id       12886
     2020-02-05 19:45:59   dim             set level_up
     2020-02-05 19:43:41   dimdown         set
     2020-02-05 19:43:24   dimup           set
     2020-02-05 19:55:36   effect          white_mode
     2020-02-05 20:08:17   hue             356
     2020-02-05 20:08:17   level           0
     2020-02-05 20:08:17   saturation      94
     2020-02-05 20:08:17   state           OFF
     2020-02-05 20:08:17   status          OFF
Attributes:
   IODev      MQTTServer
   alias      3er Milight
   comment    To switch device also on when changing brightness, change payload pattern to {"status":"ON","$EVTPART0":"$EVTPART1"} or add a new element to setList, similar to brightness, e.g.brightness_on and change payload pattern as described.
   devStateIcon {zigbee2mqtt_devStateIcon255($name)}
   eventMap   /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Faster/mode_speed_down:Slower/level_up:Up/level_down:Down/
   icon       light_control
   model      esp_milight_hub_rgb_cct_bulb
   readingList milight/states/0x3256/rgb_cct/4:.* { json2nameValue($EVENT) }
  milight/states/0x3256/rgb_cct/0:.* { json2nameValue($EVENT) }
  milight/updates/0x3256/rgb_cct/4:.* { json2nameValue($EVENT) }
  milight/updates/0x3256/rgb_cct/0:.* { json2nameValue($EVENT) }
   room       Test
   setList    on:noArg milight/0x3256/rgb_cct/4 {"status":"ON"}
  off:noArg milight/0x3256/rgb_cct/4 {"status":"OFF"}
  dimup:noArg milight/0x3256/rgb_cct/4 {"status":"ON","transition":3}
  dimdown:noArg milight/0x3256/rgb_cct/4 {"status":"OFF","transition":3}
  brightness:colorpicker,BRI,0,15,255 milight/0x3256/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}
  hue:colorpicker,HUE,0,1,359 milight/0x3256/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}
  color_temp:colorpicker,CT,153,1,370 milight/0x3256/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}
  saturation:colorpicker,BRI,0,1,100 milight/0x3256/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}
  command:uzsuSelectRadio,Weiss,Nacht milight/0x3256/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}
  program:uzsuSelectRadio,Mode,Faster,Slower milight/0x3256/rgb_cct/4 {"command":"$EVTPART1"}
  mode:select,0,1,2,3,4,5,6,7,8 milight/0x3256/rgb_cct/4 {"$EVTPART0":"$EVTPART1"}
  dim:uzsuSelectRadio,Up,Down milight/0x3256/rgb_cct/4 {"command":"$EVTPART1"}
   setStateList on off dimup dimdown
   webCmd     brightness:dim:hue:command:color_temp:program:saturation:mode
   webCmdLabel brightness:dim
  :hue:command
  :color_temp:program
  :saturation:mode


Danke für die Rückmeldung, vermutlich kommt das einfach dynamisiert als Beispiel in die RGBW-Variante rein:
  on:noArg BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"status":"ON"}\
  on_transition:slider,3,10,3600 BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"status":"ON","transition":$EVTPART1}\
  off:noArg BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"status":"OFF"}\
  off_transition:slider,3,10,3600 BASE_ID/REMOTE_ID/BULB_TYPE/GROUP_ID {"status":"OFF","transition":$EVTPART1}\


Wo kann man so ein Milight-Hub käuflich erwerben??

Ist eigentlich ein Selberbau-Projekt (und als solches auch eher einfach, ein ESP8266 (mit ausreichend verfügbaren PINs), ein nRF24-Modul (am besten das 2.300m-Modell), ein paar Kabel und ein Kondensator, that's it...).

Manchmal gibt es hier im Marktplatz aber auch fertig gelötete MySensors (WLAN-) Gateways. Das kann man direkt verwenden, wenn man den einen PIN umkonfiguriert.

Hallo zusammen,

ich bin jetzt auch Besitzer Bridge. Einbindung in Fhem hat auch soweit alles geklappt sodass
ich die Leuchtmittel schalten kann. Was jedoch nicht so richtig klappen möchte ist:
1. das Licht (RGBW-Streifen an FUT038 Controller) aus Fhem heraus auf Weiß stellen (über die WebUI des Milight-Hub ohne probleme)
2. anbindung an ALEXA, Gerät wird anglegt und kann teilweise geschaltet werden, es wird jedoch in der Alexa-App angezeigt "Gerät reagiert nicht"
3. die Farbe (color_r, color_g, color_b) wird scheinbar nicht übertragen somit auch kein hex bzw. farbliches devStateIcon

Brocker
defmod myBroker MQTT2_SERVER 1883 global
attr myBroker DbLogExclude .*
attr myBroker autocreate simple
attr myBroker rawEvents 1
attr myBroker room 99_0 Geraete
attr myBroker verbose 3

setstate myBroker 2020-02-27 15:25:43 RETAIN {"milight/LWT":"{\u0022status\u0022:\u0022connected\u0022,\u0022firmware\u0022:\u0022milight-hub\u0022,\u0022version\u0022:\u00221.10.5\u0022,\u0022ip_address\u0022:\u0022192.168.2.46\u0022,\u0022reset_reason\u0022:\u0022Software/System restart\u0022}","milight/states/0xE002/rgbw/1":"{\u0022status\u0022:\u0022OFF\u0022,\u0022brightness\u0022:255,\u0022hue\u0022:309,\u0022color\u0022:\u0022#FF00D8\u0022,\u0022bulb_mode\u0022:\u0022color\u0022}","milight/states/0xE003/rgb/0":"{\u0022state\u0022:\u0022OFF\u0022,\u0022status\u0022:\u0022OFF\u0022,\u0022bulb_mode\u0022:\u0022color\u0022,\u0022color\u0022:{\u0022r\u0022:255,\u0022g\u0022:0,\u0022b\u0022:0}}","milight/states/0xE004/rgb_cct/1":"{\u0022status\u0022:\u0022ON\u0022,\u0022color\u0022:\u0022#B2FF00\u0022}","milight/states/0xE005/fut089/1":"{\u0022status\u0022:\u0022ON\u0022,\u0022color\u0022:{\u0022r\u0022:255,\u0022g\u0022:255,\u0022b\u0022:255}}","milight/states/0xE005/rgb_cct/1":"{\u0022status\u0022:\u0022ON\u0022,\u0022color\u0022:{\u0022r\u0022:255,\u0022g\u0022:255,\u0022b\u0022:255}}","milight/states/0xE006/rgbw/1":"{\u0022status\u0022:\u0022ON\u0022,\u0022color\u0022:{\u0022r\u0022:255,\u0022g\u0022:255,\u0022b\u0022:255}}"}
setstate myBroker 2020-02-27 15:25:43 nrclients 1
setstate myBroker 2020-02-26 20:42:22 state Initialized

Milight-HUB
defmod MQTT2_milight_hub_7990748 MQTT2_DEVICE milight_hub_7990748
attr MQTT2_milight_hub_7990748 DbLogExclude .*
attr MQTT2_milight_hub_7990748 IODev myBroker
attr MQTT2_milight_hub_7990748 autocreate 1
attr MQTT2_milight_hub_7990748 bridgeRegexp milight_hub_7990748:milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr MQTT2_milight_hub_7990748 devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr MQTT2_milight_hub_7990748 model esp_milight_hub_bridge
attr MQTT2_milight_hub_7990748 readingList milight_hub_7990748:milight/LWT:.* { json2nameValue($EVENT) }
attr MQTT2_milight_hub_7990748 room MQTT2_DEVICE
attr MQTT2_milight_hub_7990748 setStateList on off
attr MQTT2_milight_hub_7990748 stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version

setstate MQTT2_milight_hub_7990748 <a href="http://192.168.2.46" target="_blank">\
connected\
</a>Version: \
1.10.5
setstate MQTT2_milight_hub_7990748 2020-02-27 15:25:43 firmware milight-hub
setstate MQTT2_milight_hub_7990748 2020-02-27 15:25:43 ip_address 192.168.2.46
setstate MQTT2_milight_hub_7990748 2020-02-27 15:25:43 reset_reason Software/System restart
setstate MQTT2_milight_hub_7990748 2020-02-27 15:25:43 status connected
setstate MQTT2_milight_hub_7990748 2020-02-27 15:25:43 version 1.10.5

Milight Device
defmod LED_Essen MQTT2_DEVICE milight_0xE002_1
attr LED_Essen DbLogExclude .*
attr LED_Essen IODev myBroker
attr LED_Essen comment To switch device also on when changing brightness, change payload pattern to {"status":"ON","$EVTPART0":"$EVTPART1"} or add a new element to setList, similar to brightness, e.g.brightness_on and change payload pattern as described.
attr LED_Essen devStateIcon {zigbee2mqtt_devStateIcon255($name,"hex",1)}
attr LED_Essen eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white
attr LED_Essen genericDeviceType light
attr LED_Essen homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
attr LED_Essen icon light_control
attr LED_Essen model esp_milight_hub_rgbw_bulb
attr LED_Essen readingList milight/states/0xE002/rgbw/1:.* { json2nameValue($EVENT) }\
  milight/states/0xE002/rgbw/0:.* { json2nameValue($EVENT) }\
  milight/updates/0xE002/rgbw/1:.* { json2nameValue($EVENT) }\
  milight/updates/0xE002/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0xE002/rgb_cct/1:.* { json2nameValue($EVENT) }\
milight/states/0xE002/rgb_cct/1:.* { json2nameValue($EVENT) }
attr LED_Essen room 00_4 Essen,Homekit,MQTT2_DEVICE
attr LED_Essen setExtensionsEvent 1
attr LED_Essen setList on:noArg milight/0xE002/rgbw/1 {"status":"ON"}\
  on_transition:slider,3,10,3600 milight/0xE002/rgbw/1 {"status":"ON","transition":$EVTPART1}\
  off:noArg milight/0xE002/rgbw/1 {"status":"OFF"}\
  off_transition:slider,3,10,3600 milight/0xE002/rgbw/1 {"status":"OFF","transition":$EVTPART1}\
  brightness:colorpicker,BRI,0,15,255 milight/0xE002/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
  hue:colorpicker,HUE,0,1,359 milight/0xE002/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
  command:uzsuSelectRadio,Weiss,Nacht milight/0xE002/rgbw/1 {"$EVTPART0":"$EVTPART1"}
attr LED_Essen setStateList on off
attr LED_Essen userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
attr LED_Essen webCmd brightness:hue:command

setstate LED_Essen OFF
setstate LED_Essen 2020-02-26 22:14:16 associatedWith MQTT2_milight_hub_7990748
setstate LED_Essen 2020-02-27 12:35:44 brightness 255
setstate LED_Essen 2020-02-27 12:35:44 bulb_mode color
setstate LED_Essen 2020-02-27 12:35:44 color #FF00D8
setstate LED_Essen 2020-02-27 06:43:01 color_b 255
setstate LED_Essen 2020-02-27 06:43:01 color_g 255
setstate LED_Essen 2020-02-27 06:43:01 color_r 255
setstate LED_Essen 2020-02-26 22:59:23 command set_white
setstate LED_Essen 2020-02-26 22:12:59 group_id 1
setstate LED_Essen 2020-02-27 06:43:01 hex FFFFFF
setstate LED_Essen 2020-02-27 12:35:44 hue 309
setstate LED_Essen 2020-02-26 21:10:20 on_transition set 3
setstate LED_Essen 2020-02-27 12:35:44 state OFF
setstate LED_Essen 2020-02-27 12:35:44 status OFF

kann jemand hier weiterhelfen ??

Mit freundlichen Grüßen
Ingo

Hmm, schau mal als erstes in den Einstellungen des Hub, was alles via MQTT übertragen wird, da scheint die "color-Variante mit Einzelkanälen" nicht mit dabei zu sein (oder es hat sich mal wieder was geändert).

Wiederholtes Weiß-Stellen klappt auch bei mir nicht, da muß was ein anderes Kommando dazwischen sein.

Zu Alexa kann ich wenig sagen, aber die Beschreibung "teilweise" ist so unspezifisch, dass damit vermutlich auch sonst niemand was anfangen kann (bitte konkret nennen, was geht, und was nicht).

(die cct-Einträge sind irritierend, die kommen vermutlich von einer "Nicht-Umstellung" bei Schaltungen über den Hub her, oder?)

Hallo
Bei mir sieht es in der Bridge so aus

ZitatMQTT topic pattern:milight/:hex_device_id/:device_type/:group_id

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

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

ZitatMQTT Client Status Topic: milight/LWT

Einiges habe ich bereits hinbekommen
zu 3. wenn ich im MQTT die Group state fields hex_color deaktiviere wird color_r, color_g, color_b übertragen
zu 2. alle Geräte nochmal gelöscht neu angelegt geht auch, sowie ich z.B. sage "Alexa, stelle licht essen weiß"
geht es nicht mehr (Gerät reagiert nicht) erst wenn ich irgend eine Farbe wieder auswähle geht es wieder

MfG Ingo


Hier die einstellung in MQTT

@Beta-User

Hatte mich vor längerer Zeit damit beschäftigt, aber nicht wirklich weiter gekommen.

Welche Einstellungen bei den Packet-Wiederholungen würdest du vornehmen/empfehlen, wenn die Leuchte ab und an nicht direkt an geht ?

Es liegt definitiv nicht am Abstand Leuchte->Gateway, das Gateway war schon Monate direkt unter der Lampe (Deckenmontage) in einer Steckdose Bodennähe (30cm), aktuell in ca. 5 Metern Entfernung hinter einer Couch, das Problem tritt nicht oft aber immer wieder mal auf.

Gruß

Thomas

Schwierig...

Ich steuere relativ wenig aktiv vom Hub aus, das meiste ist Empfangen (FB-Funktionalität)...

Hier mal meine Einstellungen, ist aber vor dem genannten Hintergrund nicht wirklich optimiert:
{[deleted],"ce_pin":4,"csn_pin":15,"reset_pin":0,"led_pin":-2,"radio_interface_type":"nRF24","packet_repeats":50,"http_repeat_factor":1,"auto_restart_period":0,[deleted],"mqtt_topic_pattern":"milight/:device_id/:device_type/:group_id","mqtt_update_topic_pattern":"milight/updates/:device_id/:device_type/:group_id","mqtt_state_topic_pattern":"milight/states/:device_id/:device_type/:group_id","mqtt_client_status_topic":"milight/LWT","simple_mqtt_client_status":false,"discovery_port":48899,"listen_repeats":3,"state_flush_interval":10000,"mqtt_state_rate_limit":500,"mqtt_debounce_delay":500,"packet_repeat_throttle_sensitivity":0,"packet_repeat_throttle_threshold":200,"packet_repeat_minimum":3,"enable_automatic_mode_switching":false,"led_mode_wifi_config":"Fast toggle","led_mode_wifi_failed":"On","led_mode_operating":"Slow blip","led_mode_packet":"Flicker","led_mode_packet_count":3,"hostname":"milight-hub","rf24_power_level":"MAX","rf24_listen_channel":"LOW","wifi_static_ip":"","wifi_static_ip_gateway":"","wifi_static_ip_netmask":"","packet_repeats_per_loop":10,"home_assistant_discovery_prefix":"","wifi_mode":"n","default_transition_period":500,"rf24_channels":["LOW","MID","HIGH"],"device_ids":[],"gateway_configs":[],"group_state_fields":["state","brightness","saturation","mode","color_temp","bulb_mode","computed_color"],"group_id_aliases":{}}

Mit meinem "Projekt", so viel wie möglich auf MQTT umzubauen, war heute eine Altlast dran.

Habe hier seit langem drei Milight RGBW Leuchtmittel in einer Lampe.
Dazu habe ich eine Fernbedienung, mit der kann ich die Leuchtmittel auch steuern.
Bridge hatte ich mal.

Jetzt habe ich mir heute einen Milight Hub zusammen gebaut.
Mit dem Sniffer konnte ich auch ganz schnell die Adresse der FB heraus finden.
Habe dann noch alle drei Leuchtmittel einzeln gepaired.

In fhem wurde mir eine Device (der Hub) angelegt, wie im Wiki beschrieben.
Habe dann das esp_milight_hub_bridge Template angewandt.

So weit, so gut, ich sehe die Änderungen über die FB in fhem.

Leider kommen aber keine neuen Devices für die Leuchtmittel, sondern die readingList im Hub wurde erweitert.
Nun kann ich natürlich nichts schalten.

Der Hub:
Internals:
   CFGFN     
   CID        milight_hub_704684
   DEF        milight_hub_704684
   DEVICETOPIC MQTT2_milight_hub_704684
   FUUID      5fa98b54-f33f-5738-a24b-339fbae58a2056e3
   IODev      myBroker
   LASTInputDev myBroker
   MSGCNT     23
   NAME       MQTT2_milight_hub_704684
   NR         23006
   STATE      <a href="http://ip_address" target="_blank">
status
</a>Version:
version
   TYPE       MQTT2_DEVICE
   myBroker_MSGCNT 23
   myBroker_TIME 2020-11-09 20:05:20
   READINGS:
     2020-11-09 19:33:39   attrTemplateVersion 20200701
     2020-11-09 20:05:05   brightness      255
     2020-11-09 20:06:02   bulb_mode       white
     2020-11-09 20:06:02   color_b         255
     2020-11-09 20:06:02   color_g         255
     2020-11-09 20:06:02   color_r         255
     2020-11-09 20:06:07   command         set_white
     2020-11-09 20:05:20   hue             117
     2020-11-09 20:05:20   state           ON
Attributes:
   IODev      myBroker
   alias      Milight Hub
   autocreate 1
   bridgeRegexp milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
   devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
   group      Zentrale
   icon       mqtt
   model      esp_milight_hub_bridge
   readingList milight/LWT:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/updates/0xEE6D/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/states/0xEE6D/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/updates/0x1/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/states/0x1/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/updates/0x2/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/states/0x2/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/updates/0x3/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/states/0x3/rgbw/1:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/updates/0x2/rgbw/0:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/states/0x2/rgbw/0:.* { json2nameValue($EVENT) }
milight_hub_704684:pattern_milight/updates/0xEE6D/rgbw/0:.* { json2nameValue($EVENT) }
   room       Zentrale
   setStateList on off
   stateFormat <a href="http://ip_address" target="_blank">
status
</a>Version:
version

Die 0xEE6D ist die Fernbedienung, die 0x1 bis 3 sind die Leuchtmittel.

Was mache ich falsch?

Dein bridgeRegexp Attribut passt nicht auf die empfangenen Topics.
Man muss es so anpassen, dass aus jedem topic der richtige "Geraetidentifizierer" extrahiert wird.
Z.Bsp.:
pattern_milight.*0x(.+)/rgbw/(.+):.* "milight_$1_$2"

Danke Rudi!

Genau das war es.

Ich hab da mal ne Frage... Ich habe vor dem Milight-Hub über MQTT seinerzeit das Wifilight Modul genutzt. Hiermit war es möglich, bestimmte "vordefinierte" Farben per webCmd zu setzen.

Das sah configmäßig dann so aus:

attr LED-Controller webCmd Aus:dim:Ein:RGB:RGB ffffff:RGB FF0000:RGB FFFF00:RGB 00FF00:RGB 00FFFF:RGB 0000FF:RGB FF00FF:RGB ED8E00:RGB 56DB2E:RGB ED6002:RGB 753612:RGB 61A4AB:RGB 76ADA6:RGB 111461:RGB 4D1B46:RGB E3280B:RGB 46187A:RGB 9E5058:RGB 5E395C:RGB 4D330B


Ist sowas auch mit den Milight-Hub Devices möglich und wenn ja, wie ?

Geht genauso.
webCmd einrichten und gut. So mache ich das auch.

Na ganz so einfach scheint das leider nicht zu sein... wenn ich im webCmd einfach z.B. RGB ffffff hinzufüge und dann auf das webCmd drauf klicke, bekomme ich die Meldung: Unknown argument RGB. Choose one of...... Das webCmd wird auch nicht richtig dargestellt. Anstelle der Farbbubble steht dort ausgeschrieben RGB ffffff

Ich denke mal, das liegt auch daran, dass für das MQTT Device auch HUE anstatt RGB genutzt wird, oder ?  ???


hue:colorpicker,HUE,0,1,359 milight/0x647/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}


Wäre aber cool, wenn du mir da auf die sprünge helfen könntest. Vielleicht pastest du einfach mal ein Device hier rein, bei dem du diese Farbbubbles nutzt, dann kann ich ja mal mit meinem vergleichen.

Hast du auch das richtige Template ausgewählt?

Ich habe esp_milight_hub_rgb_cct_bulb ausgewählt.

Wenn ich der setList einen Eintrag für RBG hinzufüge, bekomme ich die Farbbuble im webCmd richtig angezeigt; Allerdings kann ich damit trotzdem die Farbe der Milight Bulb nicht umschalten...

Hier einmal der Eintrag in meiner setList:

  RGB:colorpicker,RGB,0,6.25,100 milight/0x647/rgb_cct/1 {"$EVTPART0":"$EVTPART1"}


Ich vermute mal, dass ich damit noch irgendwas falsch gemacht habe...

Hmm, die Bridge ist eigentlich nicht wirklich "gut", was RGB in "FHEM-typischem" Format angeht. Das dürfte der Grund gewesen sein, warum hier ausschließlich hue auftaucht.

Siehe https://github.com/sidoh/esp8266_milight_hub/blob/master/docs/openapi.yaml

Die Anforderung umzusetzen könnte eventuell klappen, wenn man hex_color verwendet:

Zitat* `hex_color` - same as `color` except in hex color (e.g., `#FF0000` for red).

Würde mal folgendes ins Rennen schicken:
RGB:colorpicker,RGB,0,6.25,100 milight/0x647/rgb_cct/1 {"hex_color":"#$EVTPART1"}
(Wobei mir RGB in Großschreibung nicht behagt und ggf. die Rückmeldung nicht zum versendeten Inhalt paßt => jsonMap verwenden/anpassen... Will sagen: Wenn man das anfassen will, muss man "richtig modernisieren", die MiLight-Geschichte gehört zum "Urschlamm" aus der Zeit vor vielen Erweiterungen bei MQTT2_DEVICE/json2nameValue(). Ich nehme gerne eure Vorschläge entgegen... ;) )

Macht es einen wirklichen Unterschied, ob RGB oder rgb (außer der Optik) ? Ich habs jetzt mal klein geschrieben...

also in der setList:

rgb:colorpicker,RGB,0,6.25,100 milight/0x647/rgb_cct/1 {"hex_color":"#$EVTPART1"}


und im webCmd dann:

rgb ff0000


Ich bekomme dann im webCmd auch eine rote Bubble angezeigt, aber wenn ich drauf klicke reagiert die Lampe nicht.
Muss ich in dem Milight Hub unter Group State Fields dann auch hex_color aktivieren...? (Probert hab ichs mal, hat aber nichts gebracht...)
Kann ich mir eigentlich irgendwie anzeigen lassen, was FHEM dann wirklich an den Milight-Hub schickt ? ...Also um mal sicherzustellen, dass die MQTT Message an den Hub auch passt...

@Mitch: Wenn es bei dir funktioniert, wäre es wirklich cool, wenn du dein Device hier mal reinpasten könntest.

 ::) Ich kann dir die Frage nicht abschließend beantorten, ob rgb-Kleinschreibung einen wirklichen Vorteil bringt. Das generelle Thema bei allen settern ist Folgendes: einige externe Anbindungen (angefangen bei Sprachsteuerung wie alexa) holen sich die vorhandenen setter und "mappen" in ihren "Sprachraum", was sie (er-) kennen. Was nicht bekannt ist, muss man selbst anlegen... (u.A. deswegen ist es nicht ganz unwichtig, welcher der modes bei einem Heizungsgerät denn jetzt "mode" heißt...)
Da in mqtt2.template für rgb-Geräte bisher (jedenfalls soweit ich das auf die Schnelle gesehen habe) die Kleinschreibung verwendet wurde, gehe ich einfach mal von der Unterstellung aus, das sei eben unproblematisch, und von der "großen Schwester" weiß ich es nicht ;D ...

Was den MQTT-Verkehr angeht, kann man entweder rawEvents am IO (+Event-Monitor) passend einstellen, oder eben ein externes Tool wie mosquitto_sub darauf ansetzen.

Wenn es "richtig" versendet wird, müßte die Bridge das auch auswerten, die "fields" dienen afaik nur dazu, was gewünschtes (z.B. als Information über Fernbedienungsaktionen) rauszuschicken (kann aber sein, dass das sinnvoll ist, um "den Informationskreis" zu schließen).

Ich habs hinbekommen !  8)

Ich habe im Milight-Hub nochmal das Feld x_color unter Group State Fields aktiviert und dann die Lampe auf eine andere Farbe eingestellt. Dabei ist mir aufgefallen, das FHEM per MQTT gar nicht x_color, sondern nur color als reading zurückgeliefert bekommt. Also in der setList von x_color auf color geändert und siehe da, es geht !!!

Ich habe es geschafft die "esp8266_milight_hub_bridge" zum Laufen zu bringen. Einer mit 4 Zonen funktioniert. Da ich jedoch noch mehr Zonen möchte, habe ich versucht, einen zweiten zu integrieren. Leider funktioniert das bei mir nicht. Ich kann zwar zwei anlegen, aber sie schalten beide immer gleichzeitig.

Was habe ich den falsch gemacht? Ich würde mich über Hilfe freuen.

Gruss KNET

Na ja, vermutlich (...list fehlen (!)...) verwendest du dieselben Topics...?

Aber warum überhaupt einen 2. Hub? Du kannst praktisch beliebig viele "Remote-ID's" mit nur einem Hub simulieren (und damit mehr Zonen steuern als in einem typischen Ein- oder Mehrfamilienhaus erforderlich) - die Frage ist dann nur, ob die Funkreichweite des Hub ausreicht, um alle Bulbs zu erreichen.

Hallo Bata-User

Danke für deine Antwort. Ich habe das auch Bemerkt mit den Topics. Ich habe die jetzt nummeriert mit einer _1 und _2 erweitert.

Anscheinend habe nicht ganz verstanden, wie die "esp8266_milight_hub_bridge" funktioniert.

Ich habe die Lampe auf dem Hub_1 auf die Zone 1 angelernt. Ich musste jedoch feststellen, dass wenn ich im WEB-GUI vom Hub_2 die Zone 1 einschalte, die Lampe vom Hup_1 Zone 1 angeht. Also Hub_1 und Hub_2 machen im WEB-GUI immer dasselbe. Das verstehe ich nicht ganz. Wie funktioniert den das ganze? Ich bin davon ausgegangen, dass beim "Pair" die Lampe sich im Hub in die Zone ausgewählte Zone einträgt.

Wie kann ich den beliebige "Remote-IDs" machen? Ich gehe davon aus, dass "Remote-IDs" Lampen sind, oder? Mir würde ein vorerst ein Hub reichen von der Distanz.

Gruss KNET

Zitat von: Beta-User am 18 Februar 2021, 09:49:00
...list fehlen (!)...

Du solltest dir die Topics genauer ansehen, und mit der etwas diffusen Beschreibung kann ich wenig anfangen.

Bei https://github.com/sidoh/esp8266_milight_hub#use-it gibt es einen screenshot vom Web-Interface. Du kannst statt "0x1111" alles mögliche (4 HEX-Stellen) eingeben und musst dann eben die passende "remote type" links einstellen, was genau, hängt von deinen Leuchtmitteln ab.

Und die "Lampen" machen bei MiLight gar nichts auf dem Hub, das sind schlicht "dumme Empfänger". Wer auch immer das passende Signal sendet, den aktzeptieren die.

Hallo Beta-User

Jetzt habe ich es begriffen, wie ich die Sidoh Bridge einrichten muss. Jetzt funktioniert es so wie es soll.

Danke für die Hilfe

@Jörg

Falls es dir in dem at aufgefallen sein sollte, folgende Änderungen hab ich dazu in meinem Milight-Device vorgenommen:

Zitatdefmod MQTT2_Mi_Wecklicht MQTT2_DEVICE milight
attr MQTT2_Mi_Wecklicht userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr MQTT2_Mi_Wecklicht IODev MQTT2_Server
attr MQTT2_Mi_Wecklicht alexaName jupiter
attr MQTT2_Mi_Wecklicht comment To switch device also on when changing brightness, change payload pattern to {"status":"ON","$EVTPART0":"$EVTPART1"} or add a new element to setList, similar to brightness, e.g.brightness_on and change payload pattern as described.
attr MQTT2_Mi_Wecklicht devStateIcon {zigbee2mqtt_devStateIcon255($name,"hex",1)}
attr MQTT2_Mi_Wecklicht eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/
attr MQTT2_Mi_Wecklicht genericDeviceType light
attr MQTT2_Mi_Wecklicht group Wohnzimmer
attr MQTT2_Mi_Wecklicht homebridgeMapping On=state,valueOn=ON,valueOff=OFF\
Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true\
Hue=hue,factor=0.0054,cmd=hue
attr MQTT2_Mi_Wecklicht icon light_control
attr MQTT2_Mi_Wecklicht jsonMap color:rgb
attr MQTT2_Mi_Wecklicht model esp_milight_hub_rgbw_bulb
attr MQTT2_Mi_Wecklicht readingList milight/states/0x8D56/rgbw/1:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP);;$ret->{state}=lc($ret->{state});; return $ret }\
milight/updates/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }]
milight/LWT:.* { json2nameValue($EVENT) }
attr MQTT2_Mi_Wecklicht room Deko,MQTT2_DEVICE,Privat->OG->Wohnzimmer
attr MQTT2_Mi_Wecklicht setExtensionsEvent 1
attr MQTT2_Mi_Wecklicht setList on:noArg milight/0x8D56/rgbw/1 {"status":"ON"}\
on_transition:slider,3,10,3600 milight/0x8D56/rgbw/1 {"status":"ON","transition":$EVTPART1}\
off:noArg milight/0x8D56/rgbw/1 {"status":"OFF"}\
off_transition:slider,3,10,3600 milight/0x8D56/rgbw/1 {"status":"OFF","transition":$EVTPART1}\
brightness:colorpicker,BRI,0,15,255 milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,358 milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}\
sun:noArg milight/0x8D56/rgbw/1 {"status":"ON","level":"1","hue":"25","brightness":128,"transition":600}\
color_temp:colorpicker,CT,153,1,370 milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}\\
saturation:colorpicker,BRI,0,1,100 milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}\\
command:uzsuSelectRadio,Weiss,Nacht milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}\\
program:uzsuSelectRadio,Mode,Faster,Slower milight/0x8D56/rgbw/1 {"command":"$EVTPART1"}\\
mode:select,0,1,2,3,4,5,6,7,8 milight/0x8D56/rgbw/1 {"$EVTPART0":"$EVTPART1"}\\
dim:uzsuSelectRadio,Up,Down milight/0x8D56/rgbw/1 {"command":"$EVTPART1"}\
b:colorpicker,BRI,0,15,255 {my $v=ReadingsNum('MQTT2_Mi_Wecklicht','color_g','5');;qq(milight/0x8D56/rgbw/1 {"brightness":200,"transition": $v})}\
rgb:colorpicker,RGB {"milight/0x8D56/rgbw/1 ".zigbee2mqtt_RGB2JSON($EVTPART1)}\
modeToggle:noArg {ReadingsVal($NAME, 'status', 'flip' ) eq 'ON' ? return fhem("set OG_Echo_Wohnzimmer speak bla;;sleep 4;;set OG_Echo_Wohnzimmer speak bli") : return fhem("set OG_Echo_Wohnzimmer speak bla;;sleep 4;;set OG_Echo_Wohnzimmer speak bli");;}\
modeToggle:noArg {return 'milight/0x8D56/rgbw/1 {"status":"ON"}';;fhem("set OG_Echo_Wohnzimmer speak bli");;}
attr MQTT2_Mi_Wecklicht setStateList on off sun
attr MQTT2_Mi_Wecklicht userReadings hex:color_r.* {Color::rgb2hex(ReadingsVal($name,"color_r",255),ReadingsVal($name,"color_g",255),ReadingsVal($name,"color_b",255))}, hue:bulb_mode.*white {"0"}
attr MQTT2_Mi_Wecklicht verbose 2
attr MQTT2_Mi_Wecklicht webCmd brightness:hue:command
attr MQTT2_Mi_Wecklicht webCmdLabel Helligkeit\
:Farbe\
:Modus\
:
setstate MQTT2_Mi_Wecklicht off
setstate MQTT2_Mi_Wecklicht 2022-09-13 12:03:19 brightness 51
setstate MQTT2_Mi_Wecklicht 2022-09-13 12:03:19 bulb_mode color
setstate MQTT2_Mi_Wecklicht 2022-09-13 12:03:19 device_id 36182
setstate MQTT2_Mi_Wecklicht 2022-09-12 17:42:09 firmware milight-hub
setstate MQTT2_Mi_Wecklicht 2022-09-13 12:03:19 hue 71
setstate MQTT2_Mi_Wecklicht 2022-09-12 17:42:09 ip_address 192.168.188.35
setstate MQTT2_Mi_Wecklicht 2022-09-12 17:42:09 reset_reason Software/System restart
setstate MQTT2_Mi_Wecklicht 2022-09-13 12:03:19 rgb #D0FF00
setstate MQTT2_Mi_Wecklicht 2022-09-13 12:03:19 state off
setstate MQTT2_Mi_Wecklicht 2022-09-12 17:42:09 status connected
setstate MQTT2_Mi_Wecklicht 2022-09-12 17:42:09 version 1.10.8

Ich hab keine Ahnung ob das mit dem rgb-Wert so korrekt umgesetzt ist (das liegt schon etwas länger zurück als ich mich damit ungern beschäftigte und das kam raus), aber das setzen eines "rgb"-Wert passt, auch wenn ein anderer Wert zurückkommt (dem müsste man noch die Raute abzwacken, das der setter die Farbe auch anzeigt ).

Wie man sieht ist das Template auch noch nicht auf devicetopic umgestellt.

Ach und milight/LWT:.* { json2nameValue($EVENT) } hab ich ergänzt das kommt im Template gar nicht vor ?

Ergänzend, zum Verständnis mit dem rgb:

SENT
milight/0x8D56/rgbw/1
{"status":"ON"}
milight_hub_523894
milight/updates/0x8D56/rgbw/1
{"state":"ON"}
milight_hub_523894
milight/states/0x8D56/rgbw/1
{"state":"ON","brightness":51,"hue":71,"color":"#D0FF00","bulb_mode":"color","device_id":36182}
SENT
milight/0x8D56/rgbw/1
{"color":{"b":255,"g":60,"r":46},"transition":1}
milight_hub_523894
milight/updates/0x8D56/rgbw/1
{"hue":72}
milight_hub_523894
milight/states/0x8D56/rgbw/1
{"state":"ON","brightness":51,"hue":72,"color":"#CBFF00","bulb_mode":"color","device_id":36182}
milight_hub_523894
milight/updates/0x8D56/rgbw/1
{"hue":122}
milight_hub_523894
milight/states/0x8D56/rgbw/1
{"state":"ON","brightness":51,"hue":121,"color":null,"bulb_mode":"color","device_id":36182}

Gibt bei Gelegenheit ein update zu dem rgbw, habe mich mit dieser Sache schon ewig nicht mehr beschäftigt, zumal die meisten MiLight-Bulbs zwischenzeitlich getauscht sind.

Das sollte dann das mit rgb und Kleinschreibung im Griff haben.
devicetopic war mir jetzt zu viel (geht ja auch so und ist sowieso kaum veränderlich, dazu sind es mehrere Zweige, die in der readingList eine Rolle spielen.

LWT ist beim ESP, und da gehört es mAn. auch hin.

Kann ja auch nix dafür das die Bulb seit fast sieben Jahren nicht das Zeitliche segnet, die die ich hier jemandem zwischendurch abgekauft hatte war nach nem halben Jahr defekt.

Danke.

Ach klar, da war schon noch ein ?, wieso und weshalb das sein kann und wo denn der Pfad landet, ich hab gestern/heute irgendwie nicht mehr an die Bridge gedacht, schäm.

Danke, nochmal, für das update.

Klappt soweit, auch das entfernen des ersten Zeichen vom rgb-Wert mit sprintf.

Hast du das mit der Funktion zigbee2mqtt_RGB2JSON jetzt einfach so übernommen ? Ist das so überhaupt korrekt, da hätt ich gerne noch ne Rückmeldung, ich bin da kein bisschen mehr drin in dem Thema, hab was im Kopf, müsste aber auch erst nochmal nachschauen was die genau macht ?

Ich hatte es in der kurzen Zeit (die letzte halbe Stunde seit dem update) dass das set xxxxxx im Reading rgb stehen bleibt, das war vorher mein ich auch schon so, ab und an kommt nix zurück ? Ich weiss es nicht, mir reichts wie es ist, beschäftige mich nicht mit.

zigbee2mqtt_RGB2JSON() sah plausibel aus, das könnte funktionieren (ist in 10_MQTT2_DEVICE.pm enthalten), aber nachdem der Vorschlag kam, war ich einfach davon ausgegangen, dass es (sendeseitig) getestet ist ::) .

Das mit rgb (bzw. hex) ist einfach "halblebig", mAn. ist für die (Farb-) Ansteuerung der MiLight-Bulbs sinnvollerweise hue zu verwenden. Soweit ich mich entsinne, kommt dazu auch praktisch immer eine Rückmeldung...