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

Begonnen von Beta-User, 12 April 2018, 23:23:41

Vorheriges Thema - Nächstes Thema

Beta-User

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

Zusammenfassung findet sich hier: 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 (sidoh) etwas speziell ist, kommt vermutlich eine Integration der Anpassungen für die Zusammensetzung der Sendemessages als JSON nicht wie hier diskutiert in Frage.

Anbei daher ein erster Entwurf der Weiterentwicklung des von @lufi erstmals hier vorgestellten 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 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 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!!!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tomcat089

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
RaspiPi v4, Funkmodule: nanoCUL a-culfw 433, nanoCUL a-culfw 866, 2 broadlink, 10 HM-LC-BL1PBU-FM, 4 HM-CC-RT-DN, 2 HM-OU-CM-PCB,2 HM-ES-PMSW1-PL, 2 HM-PB-6-WM55,2 HM-SEC-SIR-WM,4 HM-SEC-SD-2, 4 HM-CC-RT-DN,2 MAX ShutterContact, 2 EnOcean TCM_ESP3_1, 1 nano jeelink, 1 KLF200, 5 Somfy IO, 1 panStick

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JackKilby

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


Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tomcat089

Bzgl. des Mitschnitts des Traffics zu einer CCT. Was benötigst Du genau und wie kann ich Dir die Daten liefern?
Gruß Joachim
RaspiPi v4, Funkmodule: nanoCUL a-culfw 433, nanoCUL a-culfw 866, 2 broadlink, 10 HM-LC-BL1PBU-FM, 4 HM-CC-RT-DN, 2 HM-OU-CM-PCB,2 HM-ES-PMSW1-PL, 2 HM-PB-6-WM55,2 HM-SEC-SIR-WM,4 HM-SEC-SD-2, 4 HM-CC-RT-DN,2 MAX ShutterContact, 2 EnOcean TCM_ESP3_1, 1 nano jeelink, 1 KLF200, 5 Somfy IO, 1 panStick

Beta-User

#6
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)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

RangeMethod

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

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

RangeMethod

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

Beta-User

#10
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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

RangeMethod

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


Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

RangeMethod

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.