Hauptmenü

ESP8266 Milight Hub

Begonnen von lufi, 07 August 2017, 09:12:02

Vorheriges Thema - Nächstes Thema

lufi

Hallo,

nachdem mir im Unterforum Beleuchtung gesagt wurde, dass ich falsch bin ;-) Möchte ich es hier nochmal versuchen.

Ich würde gerne das folgende Projekt verwenden: https://github.com/sidoh/esp8266_milight_hub
Der Vorteil für mich liegt darin, dass auch die Änderungen, die mit der Fernbedienung durchgeführt werden, an Fhem zurück gemeldet werden.

Ich habe natürlich auch versucht diese Bridge einmal zu nutzen: https://forum.fhem.de/index.php?topic=58742.0
Aber da weder die kompletten Quellen noch die Librarys gut zugänglich sind, habe ich mich für das erste Projekt entschieden.

Jetzt aber zu meiner Frage.
Wie bei mehreren Lösungen mittlerweile üblich, werden dabei JSON Daten über MQTT übermittelt.
Leider ist es aber auch so das die commands ebenfalls als JSON übermittelt werden müssen.
An dieser Stelle scheitere ich leider mit meinem FHEM Wissen.

Gibt es eine Möglichkeit z.B. eine solche Zeichenkette also command über MQTT zu senden ?

{"device_id":65096,"device_type":"rgbw","group_id":1,"brightness":122,"state":"ON"}

Wie müsste ich das anstellen ?

Danke und Gruß

LuFi

lufi

Ist die Frage wieder Falsch oder unvollständig oder ist das derzeit nicht lösbar ?

Beta-User

Hallo lufi,

ich hänge mich hier mal dran, weil ich auch schon länger an einem "Rückweg" für Milights interessiert bin und mit Interesse wahrgenommen habe, dass man mit dem Ansatz von Sidoh zum einen recht einfach bestimmte -vorhandene - Fernbedienungen simulieren kann und das auch die neueren Codes zu verarbeiten scheint. Interessantes Projekt also. Allerdings wollte ich dafür nicht auch noch MQTT bemühen, zumal das auch die Bridge aus dem anderen Thread kann.

Das Problem scheint mir, dass die Einbindung in FHEM mit dieser Bridge anders als bisher laufen dürfte (irgendwas anderes als wifilight.pm bzw. Milight(bridge).pm), oder? Und eine der beiden Lösungen nutzen vermutlich alle hier bereits. Die Kunst dürfte also darin liegen, irgendwie aus den rückgelieferten Infos (könnte auch KeyValueProtokoll statt MQTT sein) wieder sinnvolle, den einzelnen wifilight/milight-Devices zuordenbare Infos zu machen. Da wäre es vermutlich einfacher, für KVP ein kleines Modul zu schreiben.

Oder nutzt Du eines der beiden Module zur Einbindung der Bridge bzw. der Devices?

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

lufi

#3
Ich habe mir mal erlaubt, dass MQTT_DEVICE Modul anzupassen.
Es gibt einen sendJson schalter der bewirkt, dass im format {"$command":"$value"} gesendet wird.

Bei mir sieht das Device jetzt wie folgt aus:

defmod MILIGHT MQTT_DEVICE
attr MILIGHT DbLogExclude .*
attr MILIGHT IODev mqtt
attr MILIGHT publishSet_brightness milight/0xFE48/rgbw/1
attr MILIGHT publishSet_command set_white level_up level_down next_mode previous_mode temperature_up temperature_down milight/0xFE48/rgbw/1
attr MILIGHT publishSet_hue milight/0xFE48/rgbw/1
attr MILIGHT publishSet_level milight/0xFE48/rgbw/1
attr MILIGHT publishSet_state ON OFF milight/0xFE48/rgbw/1
attr MILIGHT publishSet_status ON OFF milight/0xFE48/rgbw/1
attr MILIGHT room zz_TEST
attr MILIGHT sendJson 1
attr MILIGHT stateFormat state
attr MILIGHT subscribeReading_update milight/updates/0xFE48/rgbw/1
attr MILIGHT verbose 5
attr MILIGHT webCmd status:brightness:hue:command set_white
attr MILIGHT widgetOverride state hue:colorpicker,HUE,0,1,359 brightness:colorpicker,BRI,0,1,255


Wenn mir jetzt noch jemand sagen kann, wie ich die Status Zeile vernünftig darstellen kann .........
Es wäre super, wenn ich ein on off als z.B. Glühbirne hätte oder ggf. mit Dimstufe(0-255) und Farbe.
Und das Kommando: "command set_white" als z.B. weißen Button.

**Definition nochmal aktualisiert wegen einem Fehler stats/status
Gruß

Lufi

lufi

Gibt es niemanden, der mir sagen kann, wie ich im webCmd z.B. ein Kommando ausführen kann ?

So etwa: "set milight set_white:hue ffffff"

Ich versuche schon die ganze Zeit aber irgendwie finde ich keinen weg .......

Gruß und Dank

LuFi

vdr.tuxnet

Hallo lufi

Zitat von: lufi am 01 September 2017, 08:25:28
Gibt es niemanden, der mir sagen kann, wie ich im webCmd z.B. ein Kommando ausführen kann ?

So etwa: "set milight set_white:hue ffffff"

Ich versuche schon die ganze Zeit aber irgendwie finde ich keinen weg .......

Gruß und Dank

LuFi

Besten Dank für deinen sendjson Patch, der hat mir extrem weiter geholfen,

meine Bedürfnisse werden jetzt komplett abgedeckt, eventuell hilft dir meine Definition weiter:

defmod milight_120_0x084D_1 MQTT_DEVICE
attr milight_120_0x084D_1 IODev Mosqitto
attr milight_120_0x084D_1 devStateIcon ON:on:OFF OFF:off:ON
attr milight_120_0x084D_1 eventMap on:ON off:OFF
attr milight_120_0x084D_1 group milight_0x084D
attr milight_120_0x084D_1 icon light_led
attr milight_120_0x084D_1 publishSet_brightness milight_120/0x84D/rgb_cct/1
attr milight_120_0x084D_1 publishSet_color_temp milight_120/0x84D/rgb_cct/1
attr milight_120_0x084D_1 publishSet_command set_white level_up level_down mode next_mode previous_mode temperature_up temperature_down milight_120/0x84D/rgb_cct/1
attr milight_120_0x084D_1 publishSet_hue milight_120/0x84D/rgb_cct/1
attr milight_120_0x084D_1 publishSet_kelvin milight_120/0x84D/rgb_cct/1
attr milight_120_0x084D_1 publishSet_level milight_120/0x84D/rgb_cct/1
attr milight_120_0x084D_1 publishSet_mode 0 1 2 3 4 5 6 7 8 milight_120/0x84D/rgb_cct/1
attr milight_120_0x084D_1 publishSet_saturation milight_120/0x84D/rgb_cct/1
attr milight_120_0x084D_1 publishSet_status OFF ON milight_120/0x84D/rgb_cct/1
attr milight_120_0x084D_1 room Licht,MQTT
attr milight_120_0x084D_1 sendJson 1
attr milight_120_0x084D_1 stateFormat status
attr milight_120_0x084D_1 subscribeReading_status milight_120/state/0x84D/rgb_cct/1
attr milight_120_0x084D_1 subscribeReading_update milight_120/update/0x84D/rgb_cct/1
attr milight_120_0x084D_1 userReadings hsv {ReadingsVal($name,'hue','0').','.ReadingsVal($name,'saturation','100').','.ReadingsVal($name,'brightness','255')}, rgb {ReadingsVal($name,'color_r','0').','.ReadingsVal($name,'color_g','0').','.ReadingsVal($name,'color_b','0')}
attr milight_120_0x084D_1 verbose 3
attr milight_120_0x084D_1 webCmd status:hsv:color_temp:color_temp 153:color_temp 262:color_temp 370:
attr milight_120_0x084D_1 widgetOverride hsv:colorpicker,HSV,hue,0,1,360,saturation,0,1,100,brightness,0,1,255 color_temp:colorpicker,CT,153,1,370 status:uzsuToggle,OFF,ON


defmod ej_milight_120_0x084D_1 expandJSON milight_120_0x084D_1.*.*:.*:.{.*}

Das kann alles bestimmt entschlackt, verbessert und optimiert werden, ich bin da aber nicht der Profi.

Beta-User

#6
Hallo zusammen und herzlichen Dank euch beiden für die Vorarbeit!

So langsam wird das was...

Anbei eine etwas überarbeitete Version des Device-Moduls (ist aber noch nicht intensiv getestet). Die wesentliche Änderung gg. dem alten Modul+expandJSON ist die, dass die empfangsseitige Auswertung  des JSON direkt im Modul erfolgt. Um nicht in Konflikt zu kommen mit dem "allgemeinen" MQTT-Device-Modul gab es einen neuen Namen dafür. Da die Bridge immer JSON auf den "generellen" Topics verwendet, ist das jetzt ohne Attribut hartvercoded.

Damit benötigt man insgesamt weniger Geräte und es ist auch kein Problem mehr, Änderungen, die für alle Kanäle einer empfangenen Fernbedienung gelten, auf diese umzusetzen (von Kanal /0 auf z.B. /4).

Ein Beispiel für eine RGBW-Leuchte ist in der commandref.

ToDo:
- Sidoh's code hat noch ein paar Schwachstellen (Bsp., direkt auf der Weboberfläche der Bridge: Lampe ist aus, es wird ein set_white gesendet, Status bleibt auf OFF.) Toll wäre auch, wenn man den Level in % erhalten würde.
- Ein farbiges Icon wäre toll - müßte/könnte man ggf. aus Milight/hue-code entlehnen, wie man den hue-Wert in RGB umrechnet...

Optional:
- Im Define gleich die MQTT-Basisangabe mitgeben, dann könnte man jedenfalls die Attribute automatisch vergeben, am besten gleich noch mit der Subscription auf den /0-Kanal
- Standardwerte für die cmd-attr mitgeben (analog Milight).
- update auf die aktuelle MQTT_DEVICE-Version, um ggf. nicht irgendwann abgehängt zu werden wg. Neuerungen des MQTT-Moduls. (Überhaupt wäre die Frage, ob es nicht da auch direkt möglich wäre, diese eindimensionale JSON-Geschichte einzubauen; ggf per Attribut ausschaltbar für die Fälle, in denen man wg. mehrdimensionaler Arrays dann die expandJSON-Lösung wirklich braucht).

Vielleicht kann da ja jemand helfen, der mehr Ahnung von Perl hat als ich (BTW: Ich übernehme KEINE GARANTIE, dass der Code keine unerwünschten Nebenwirkungen hat, Einsatz auf eigene Gefahr...).

Feedback: Gerne :) .

Gruß, Beta-User

EDIT: Anhang entfernt wg. neuer Version
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

privat58

Hallo,
leider stürzt mein fhem mit dem anlegen eines devises ab
define milightSofa3 MQTT_MILIGHT_DEVICE
Das könnte der dazu gehörige Fehler sein
Undefined subroutine &MQTT::MILIGHT::DEVICE::client_attr called at ./FHEM/10_MQTT_MILIGHT_DEVICE.pm line 211, <$fh> line 2855.
Bisher hatte ich meine milight mit MilightBrigde und MilightDevice genutz.

Beta-User

Hallo privat58,

Danke für die Rückmeldung und den Mut, das tut mir sehr leid, dass es gleich nicht geklappt hat :( .

Kannst du noch etwas Info liefern zum Umfeld, denn leider kann ich diesen Fehler bei mir so scheinbar nicht nachstellen?

Meine Perl-Version (perl -v): "This is perl 5, version 24, subversion 1 (v5.24.1) built for i686-linux-gnu-thread-multi-64int", System sonst: siehe Signatur.

version MQTT.* liefert hier:
Zitat00_MQTT.pm                16252 2018-02-23 21:32:59Z eisler
10_MQTT_MILIGHT_DEVICE.pm 14529 2017-06-17 14:46:58Z eisler

Weder bei einem "reload" mit der unten angepinnten Version noch nach einem "service fhem restart" kam es zu einem Absturz. Was allerdings auch bei mir wirklich Probleme macht, ist so ein Device wieder zu löschen. Das führt in der Tat dazu, dass FHEMWEB nicht mehr zu erreichen ist ??? ... Das scheint eine direkte Nebenwirkung der Umbenennung des Moduls zu sein (im Log steht dann "Undefined subroutine &MQTT::MILIGHT::Client_Undefine called at fhem.pl line 3546"), denn mit lufi's Version klappt das ohne Probleme. Und ein IO wird auch nicht automatisch zugeordnet (was aber nicht so dramatisch ist).

Scheint ein dickeres Brett zu sein, das da insgesamt zu bohren ist. Wird vermutlich dauern, bis mir was dazu einfällt, aber vielleicht hat ja sonst jemand eine Idee, wie gesagt, ich bin da nicht so tief in Perl drin...

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

privat58

Hallo, werde es mir morgen noch einmal anschauen. Bin unterwegs.
:-)

Beta-User

#10
So, anbei mal wieder ein Zwischenstand:

Anbei eine überarbeitete Version des sendJson-Attribut-Vorschlags von lufi. Das ist im Prinzip das aktuelle MQTT-Device aus dem svn, enthält aber eben zusätzlich die sendJSON-Option, allerdings geringfügig anders als im originalen Code. Das gehört als 10_MQTT_DEVICE.pm ins Modulverzeichnis. Damit sollte es "eigentlich" vollständig kompatibel sein zu normalen MQTT-Devices, und auch vorbereitet darauf, dass man uU. den JSON anders zusammenbaut (den Teil habe ich aber nicht getestet, kann auch ein falscher Gedanke sein und meine Perl-Kenntnisse kann man eigentlich nicht als solche bezeichnen - daher wieder keine Gewähr...).

@lufi: Vielleicht kannst du den Thread verschieben nach MQTT, oder ich mache ggf. einen neuen Thread dort auf. Wenn das grundsätzlich so funktioniert ohne Nebenwirkungen funktioniert, könnte man das in den allg. MQTT-Zweig aufnehmen.

Der Rückweg über expandJSON sollte ja eigentlich generisch auch mit einem Device für alle Milights funktionieren, aber da hakt es bei mir noch etwas. Wenn das zu frickelig wird, würde ich dann nochmal den Versuch wagen, einen Milight-spezifischen fork auf Basis des aktuellen MQTT-Modulstands zu machen, aber eigentlich wäre der generische Ansatz besser.

Anbei auch noch eine aktuelle Definition mit Attributen, zumindest habe ich schon mal unterschiedliche Icons für an und aus, mit denen man direkt schalten kann (Farbe ist nur zum Testen, und die dynamische Brightness-Geschichte wäre natürlich auch was schönes):

defmod MQTT_MILIGHT_TEST1 MQTT_DEVICE
attr MQTT_MILIGHT_TEST1 IODev myMQTT
attr MQTT_MILIGHT_TEST1 devStateIcon ON:light_light_dim_50@#0ABF01:off OFF:light_light_dim_00:on
attr MQTT_MILIGHT_TEST1 eventMap /set_white:Weiss/ /night_mode:Nacht/ /white_mode:white/ /status ON:on/ /status OFF:off/
attr MQTT_MILIGHT_TEST1 icon light_control
attr MQTT_MILIGHT_TEST1 publishSet_brightness milight/0x63C2/rgbw/4
attr MQTT_MILIGHT_TEST1 publishSet_command set_white level_up level_down next_mode previous_mode temperature_up temperature_down milight/0x63C2/rgbw/4
attr MQTT_MILIGHT_TEST1 publishSet_hue milight/0x63C2/rgbw/4
attr MQTT_MILIGHT_TEST1 publishSet_level milight/0x63C2/rgbw/4
attr MQTT_MILIGHT_TEST1 publishSet_state ON OFF milight/0x63C2/rgbw/4
attr MQTT_MILIGHT_TEST1 publishSet_status ON OFF milight/0x63C2/rgbw/4
attr MQTT_MILIGHT_TEST1 sendJson 1
attr MQTT_MILIGHT_TEST1 stateFormat status
attr MQTT_MILIGHT_TEST1 subscribeReading_status milight/state/0x63C2/rgbw/4
attr MQTT_MILIGHT_TEST1 subscribeReading_update milight/updates/0x63C2/rgbw/4,milight/updates/0x63C2/rgbw/0
attr MQTT_MILIGHT_TEST1 verbose 3
attr MQTT_MILIGHT_TEST1 webCmd brightness:hue:command
attr MQTT_MILIGHT_TEST1 widgetOverride command:uzsuSelectRadio,Weiss,Nacht hue:colorpicker,HUE,0,1,359 brightness:colorpicker,BRI,0,1,255 status:uzsuToggle,OFF,ON


Gruß, Beta-User

EDIT: Anhang entfernt wg. neuer Version
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: Beta-User am 26 März 2018, 21:56:41
@lufi: Vielleicht kannst du den Thread verschieben nach MQTT, oder ich mache ggf. einen neuen Thread dort auf.

Da es m.E. sinvoll ist, das Thema unter MQTT zu behandeln, gibt es hier einen neuen Thread dazu mit einer aktualisierten Fassung als eigenständiges Modul.

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