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

[krakel]

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

[Beta-User]

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

[krakel]

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:

Code Auswählen Erweitern

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?

[Beta-User]

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

[krakel]

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:

Code Auswählen Erweitern

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?!

[Beta-User]

Sehr seltsam, das....

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

[Beta-User]

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

[krakel]

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:

Code Auswählen Erweitern

define MQTTServer MQTT2_SERVER 1883 global
Jetzt sieht auch die RAW-Defnition anders aus:

Code Auswählen Erweitern

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

[Beta-User]

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

[krakel]

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

[krakel]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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?

[krakel]

SO sollte es aber eigentlich aussehen.

[Beta-User]

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?)

[krakel]

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

[DasQ]

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?