Autor Thema: Milight via MQTT (war: Modul für Sidoh-Bridge, jetzt: MQTT2)  (Gelesen 25198 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8538
  • eigentlich eher user wie "developer"
Antw:Milight via MQTT (Modul für Sidoh-Bridge)
« Antwort #15 am: 31 Juli 2018, 08:39:42 »
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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline RangeMethod

  • New Member
  • *
  • Beiträge: 12
Antw:Milight via MQTT (Modul für Sidoh-Bridge)
« Antwort #16 am: 31 Juli 2018, 16:09:51 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8538
  • eigentlich eher user wie "developer"
Antw:Milight via MQTT (Modul für Sidoh-Bridge)
« Antwort #17 am: 31 Juli 2018, 16:15:06 »
Danke, habe das als Standard in den Code im ersten Beitrag übernommen :) .
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline RangeMethod

  • New Member
  • *
  • Beiträge: 12
Antw:Milight via MQTT (Modul für Sidoh-Bridge)
« Antwort #18 am: 02 August 2018, 10:27:21 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8538
  • eigentlich eher user wie "developer"
Antw:Milight via MQTT (Modul für Sidoh-Bridge)
« Antwort #19 am: 02 August 2018, 18:11:42 »
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*
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline RangeMethod

  • New Member
  • *
  • Beiträge: 12
Antw:Milight via MQTT (Modul für Sidoh-Bridge)
« Antwort #20 am: 11 August 2018, 22:46:18 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8538
  • eigentlich eher user wie "developer"
Antw:Milight via MQTT (Modul für Sidoh-Bridge)
« Antwort #21 am: 31 August 2018, 09:47:13 »
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
« Letzte Änderung: 31 August 2018, 09:49:43 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8538
  • eigentlich eher user wie "developer"
Antw:Milight via MQTT (Modul für Sidoh-Bridge)
« Antwort #22 am: 01 September 2018, 17:11:14 »
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
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}
Informativ Informativ x 1 Liste anzeigen

Offline projectsun

  • Jr. Member
  • **
  • Beiträge: 52
Antw:Milight via MQTT (war: Modul für Sidoh-Bridge, jetzt: MQTT2)
« Antwort #23 am: 10 September 2018, 23:04:03 »
Coole Sache finde ich. Läuft auch ganz gut.
Aber wie bekommst du das Level ausgelesen? Bei mir bildet sich kein Reading.
Zentrale Ubuntu, Rpi B+ mit Busware 868 CUL ser2net, Rpi 2 an Aquarium mit DS18B20, und S0Counter, Rpi 3 mit nanoCUL 433 und 868 ser2net, 7x Revolt NC-5462, 1x miniCUL WLAN, 3x IT-1000, 6x ELRO AB440, KS300, EM1000-HSM, EM1000-WZ, FHT80B, 5x FHT8v2, 20x Nodemcu mit Sensoren, 6x Echo, Sonos

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8538
  • eigentlich eher user wie "developer"
Antw:Milight via MQTT (war: Modul für Sidoh-Bridge, jetzt: MQTT2)
« Antwort #24 am: 10 September 2018, 23:13:15 »
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

Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline projectsun

  • Jr. Member
  • **
  • Beiträge: 52
Antw:Milight via MQTT (war: Modul für Sidoh-Bridge, jetzt: MQTT2)
« Antwort #25 am: 10 September 2018, 23:25:08 »
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.
« Letzte Änderung: 10 September 2018, 23:28:20 von projectsun »
Zentrale Ubuntu, Rpi B+ mit Busware 868 CUL ser2net, Rpi 2 an Aquarium mit DS18B20, und S0Counter, Rpi 3 mit nanoCUL 433 und 868 ser2net, 7x Revolt NC-5462, 1x miniCUL WLAN, 3x IT-1000, 6x ELRO AB440, KS300, EM1000-HSM, EM1000-WZ, FHT80B, 5x FHT8v2, 20x Nodemcu mit Sensoren, 6x Echo, Sonos

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8538
  • eigentlich eher user wie "developer"
Antw:Milight via MQTT (war: Modul für Sidoh-Bridge, jetzt: MQTT2)
« Antwort #26 am: 10 September 2018, 23:49:41 »
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!
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8538
  • eigentlich eher user wie "developer"
Antw:Milight via MQTT (war: Modul für Sidoh-Bridge, jetzt: MQTT2)
« Antwort #27 am: 05 Oktober 2018, 15:40:19 »
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
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline krakel

  • New Member
  • *
  • Beiträge: 17
Antw:Milight via MQTT (war: Modul für Sidoh-Bridge, jetzt: MQTT2)
« Antwort #28 am: 21 Oktober 2018, 18:09:52 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8538
  • eigentlich eher user wie "developer"
Antw:Milight via MQTT (war: Modul für Sidoh-Bridge, jetzt: MQTT2)
« Antwort #29 am: 21 Oktober 2018, 18:38:37 »
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}