(WIP) MiLight-Remote als input-Gadget für MPD, HUEDevice usw.

Begonnen von Beta-User, 05 September 2019, 12:08:10

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

MiLight als Leuchtmittel sind eigentlich nicht mehr zeitgemäß, aber neulich bin ich über eine Fernbedienung gestolpert, die mein Interesse geweckt hat: FUT089.

Gibts für um die 10 Euro in der Bucht, Optik ist ganz ok. Sie kann 8 MiLight-Gruppen steuern, was effektiv 9 Kanäle ergibt, dabei auf jedem Kanal getrennte Regelmöglichkeiten für an/aus, Helligkeit, HUE, RGB und 4 weitere Tasten. Das ist schon deutlich mehr, als ich bisher bei irgend einer anderen (halbwegs erschwinglichen) Fernbedienung gesehen habe (IR mal außen vor, MiLight funkt auf 2.4GHz und geht damit auch halbwegs durch Decken und Wände).

Hat zwar im Kern weniger mit "Automatisierung" zu tun, aber folgende Ideen waren mir eben durch den Kopf gegangen, als ich das gesehen habe:
1. Könnte ich meinen MPD damit steuern - irgendwie ist es reichlich umständlich, jedesmal das Handy rauszukramen (oder zu suchen oder gar zum Verstärker zu dackeln...), wenn man - warum auch immer - Steuerungsbedarf z.B. bei der Lautstärke hat;
2. Habe ich jüngst ein paar tradfri und tint-Leuchten verbaut bzw. beschafft (zigbee, früher eingebunden via zigbee2mqtt, jetzt als HUEDevice über einen Conbee II). Die sind m.E. den MiLights technisch um Welten voraus. Nur leider gibt es keine bezahlbaren mehrkanaligen Fernbedienungen für die (?) und ein Teil der Leuchtmittel wird erst mal MiLight bleiben - allerdings sind mir die Tasten auf den "alten" Fernbedienungen ausgegangen, die kannten nur 4 Gruppen, und die tint wären die 5. Gruppe...
3. Da gab es auch noch ein paar Rollläden bzw. Jalousien!?! Vielleicht kann so eine FB da hilfreich sein, v.a. auch für die Lamellendrehung...?
4. ...man kann nie wissen....

Von daher dachte ich, die gut 10 Euro sind eigentlich einen Versuch wert ::) . Nachdem das ganze jetzt erste Formen angenommen hat, wollte ich euch den Code nicht vorenthalten, vielleicht hat der eine oder andere einen Nutzen davon oder mehr oder weniger clevere Ideen, was man damit noch tun kann. Gerne dürfen hier auch fertige Codeschnipsel rein, wenn jemand solche hat. Insgesamt ist es vermutlich so, dass man die Reaktionscodes ohne weiteres auch für andere Fernbedienungen nutzen könnte.

Bisher erkennbare Haken:
- Um den Kanal umzuschalten, muß man immer erst auf "on" gehen, und es gibt keine Anzeige, auf welchem Kanal die steht. Das bedeutet, dass man den "ersten" "on"-Befehl bei der Auswertung von Events ggf. anders behandeln muß.
Für das Anzeigethema gäbe es Abhilfe: FUT090 - 99 Kanäle mit Kanalanzeige - aktuell ca. 22 Euro... Hab' mir auch davon eine kommen lassen, fürchte aber, dass das Ding eher eine geringere Akzeptanz bei anderen Bewohnern haben wird als die FUT089, es ist mMn. leichter, einen bestimmten Ort auf einer FB mit einer Reaktion in der Realität zu verbinden als erst mal eine anonyme Ziffer einzugeben.
- Das Ding verwendet das neuere V6-Protokoll, man kann also nicht "alte" V5-Leuchtmittel einfach so direkt verknüpfen;
- Bei HUE kommt gerne am Ende der Wert "181". Muß man wohl per Software rauswerfen;
- Man braucht ein funktionierendes FHEM (aber das läuft nach meinen bisherigen Erfahrungen so stabil, dass ich mir dazu nicht die große Sorgen mache) und ein laufendes WLAN, da als Empfangsgerät ein Eigenbau-Gerät auf ESP8266-Basis benötigt wird.
Die Hardware und Einbindung in FHEM via MQTT (über die MQTT2-Familie) ist in dem Thread beschrieben, in dem ich den folgenden Beitrag (v.a. zur Steuerung des MPD) geschrieben hatte:

Zitat von: Beta-User am 01 September 2019, 09:08:17
[...]
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)}

Fragen zur MQTT(2)-Seite also bitte in dem anderen Thread, nicht hier.

EDIT: Zwischenzeitlich werden nur noch die "updates" ausgewertet, die readingList sieht also jetzt typischerweise so aus:
defmod MiLight_RC1_0 MQTT2_DEVICE milight_0xABCD_0
attr MiLight_RC1_0 readingList milight/updates/0xABCD/fut089/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/fut089/0:.* {}

[/EDIT]

Anbei mal meine aktuelle myUtils-Datei mit dem aktualisierten Code (wg. "doppeltem" on); für den MPD nutze ich zwischenzeitlich nicht mehr Kanal 8, sondern 0 - da sind die on/off-Tasten einfach größer, und mangels direkter Verknüpfung mit den Bulbs ist es "wurscht", wenn der "all"-Kanal (0) anders genutzt wird ;) .

Darin enthalten ist auch eine indirekte Verknüpfung der "neuen", via V6-Protokoll empfangenen Codes mit dem alten V5-Protokoll (milight_FUT_to_RGBW("<Zieldevice-Name>",$EVENT)). Könnte sein, dass in der beigefügten Fassung auch schon HUEDevice-Geräte gesteuert werden können, aber da muß ich erst noch was umbauen. Der Standort des IO hat sich geändert, von dort sind die verbauten tradfri nicht direkt zu erreichen, und die tint liegen grad im Keller, bis ich entschieden habe, wo ich ggf. einen zigbee-Router benötige/zweckmäßigerweise einbaue...

Viel Spaß damit, und wie im Titel angedeutet: es ist Work In Progress und bei weitem noch nicht fertig  ::) .

Gruß, Beta-User

EDIT2:
Update der myUtils anbei, jetzt kann man damit unsere Deckenbeleuchtung im Wohnzimmer recht komfortabel steuern - die hat 4 Zonen.

EDIT3:Update der myUtils anbei, jetzt kann man damit auch FGR-223 im Venetian Mode (Jalousien) steuern. Der saturation-slider ist für die Lamellenstellung zuständig.

EDIT 4a:
mpd-Code erweitert, damit auch der AVR mit gesteuert werden kann;
alle Routinen geben jetzt auch ungenutzte Code aus, so dass weitere Aktionen abgeleitet werden können.

EDIT4: #Download-Zahlen ca. 17
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

So, am WE war ausgiebiges "Spielen" angesagt.

Zwischenstand:

       
  • die Basisfunktionen meines MPD lassen sich steuern (über Kanal 0, damit die on/off-Tasten besser zugänglich sind)
  • 2 MiLight-Bulbs mit V5-Protokoll gehen vollständig (indirekt) mit der V6-remote zu steuern
  • derselbe Code kann genutzt werden, um dimmbare HUEDevice's zu steuern (Farbe/Farbtemp: geht (Farbe: eventuell) noch nicht, weiß noch nicht, ob ich Farbtemperatur überhaupt brauche)
  • Die Deckenlichter im Wohnzimmer (2*2 on/off Kanäle) belegen eine Steuerungsebene (in der Praxis: zwei ZWave switches), derzeit genutzt: 6 Tasten dieser Ebene. Mal schauen, ob ich da noch Szenen auf die verbleibenden 3 Slider legen will - mind. die Hellighkeits- und Saturation-Slider scheinen ziemlich exakt zu funktionieren, da sollten je 5 "virtuelle" Tasten möglich sein...
  • und zu guter letzt: Zwei Rolläden (CUL_HM) und eine Jalousie (ZWave FGR-223, incl. Lamellenstallung 8) ) folgen auch der FB.
Einziges "Manko": Man muß teilweise die (on) Tasten (gewollt!) doppelt drücken, damit nicht das Aktivieren einer Belegungsebene gleich eventuell unbeabsichtigte Folgen in der Realität hat.

Soweit also erst mal: volle Zufriedenheit 8) , coole Sache. Auch die Reichweite ist für meine Zwecke völlig ausreichend (vergleichbar mit der WLAN-Ausleuchtung).

Update der codes ist im Anhang des ersten Post, da ist auch etwas cref drin mit Beispielen für notify-Definitionen.

Bis dahin erst mal,

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

rakete123

Hey Beta-User,

ich hab mir mittlerweile auch die Fernbedienung zugelegt und ein paar eigene Experimente gemacht. Vielen vielen dank für deine Arbeit hier.
Ich hab überlegt mittels des Farbrads meine HUE Lampen zu steuern. Aber sehe ich das richtig, das die Fernbedienung einen hue Wert von 0-360 sendet und Philips Hue 0-65xxx braucht?
Zwave: ZMEEUZB1 (Fibaro, Aeotec, diverse)
Zigbee: Conbee (HUE, Xiaomi, osram)
Homematic: HM-MOD-RPI-PCB + diverse HM-CC-RT-DN
Sonstiges: Harmony, Android, Netatmo, Jabber (talk2fhem)
https://resize2fs.de

Beta-User

#3
Ja, die FB liefert wohl was anderes als das, was HUEDevice benötigten (u.a. daher: WIP).

Da ich die FB woanders rumliegen habe wie am Verbauort der tint, habe ich bisher auch nicht verlieft, ob und wie man das umrechnen könnte; der Wert, den die FB liefert, scheint eher das zu sein, was bei Color.pm "HSV" heißt. Müßte man ggf. mal in den Code sehen, ob es da bereits Umrechnungsfunktionen gibt...

(Wie bereits an anderer Stelle angemerkt: wenn wir da sowas wie ein "typisches" und gut zu nutzendes Toolset zusammenbasteln können, liefere ich das gerne via contrib aus, im Hinblick auf PBP aktualisierte Fassung im Anhang.)
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

rakete123

Ok cool, ich drille mich da die nächste Tage mal rein. Lightscene will ich auch steuern mit der FB.
Zwave: ZMEEUZB1 (Fibaro, Aeotec, diverse)
Zigbee: Conbee (HUE, Xiaomi, osram)
Homematic: HM-MOD-RPI-PCB + diverse HM-CC-RT-DN
Sonstiges: Harmony, Android, Netatmo, Jabber (talk2fhem)
https://resize2fs.de

rakete123

Hi,

also ich habs jetzt bei mir erstmal mit einem DOIF gelöst. Zum Steuern einer HUE Color Lampe sieht das so aus:

DOELSEIF
([wz.remote.a4:state] eq "ON")
(set wz.licht.4 on)
DOELSEIF
([wz.remote.a4:state] eq "OFF")
(set wz.licht.4 off)
DOELSEIF
([wz.remote.a4:brightness])
(set wz.licht.4 bri $EVENT)
DOELSEIF
([wz.remote.a4:hue])
(set wz.licht.4 rgb {(Color::hsv2hex([$DEVICE:hue],[$DEVICE:saturation]/100,sprintf("%.2f",[$DEVICE:brightness]/255)))})
DOELSEIF
([wz.remote.a4:saturation])
(set wz.licht.4 sat {(int([$DEVICE:saturation]*2.54))})
DOELSEIF
([wz.remote.a4:command] eq "set_white")
(set wz.licht.4 rgb FCFEFF)


Klar, mit den restlichen Tasten könnte man auch noch mehr machen.
Zwave: ZMEEUZB1 (Fibaro, Aeotec, diverse)
Zigbee: Conbee (HUE, Xiaomi, osram)
Homematic: HM-MOD-RPI-PCB + diverse HM-CC-RT-DN
Sonstiges: Harmony, Android, Netatmo, Jabber (talk2fhem)
https://resize2fs.de

Beta-User

Hmm, ich pflege das ja gerne in die myUtils ein, aber kannst du mir verraten, was $DEVICE bei DOIF ist (ich nutze dieses Modul nicht und habe auch 0 Neigung, mich in diese Syntax einzudenken). Ist das das auslösende Device, also "wz.remote.a4"?
Vielleicht eine Frage:
Was ist die Motivation, den vorgeschlagenen Weg mit notify+myUtils _nicht_ zu nutzen?
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

rakete123

Genau $DEVICE is wz.remote.a4. Das DOIF ist noch nicht 100% optimal.

Ich nutze schon immer doif und habe, glaube ich, nur ein einziges notify irgendwo. myUtils habe ich noch nie benutzt. Deswegen bin mit DOIF unterwegs.

Schätze genau andersherum als bei dir ;)
Zwave: ZMEEUZB1 (Fibaro, Aeotec, diverse)
Zigbee: Conbee (HUE, Xiaomi, osram)
Homematic: HM-MOD-RPI-PCB + diverse HM-CC-RT-DN
Sonstiges: Harmony, Android, Netatmo, Jabber (talk2fhem)
https://resize2fs.de

Beta-User

Zitat von: rakete123 am 22 Mai 2020, 12:28:11
Schätze genau andersherum als bei dir ;)
...es ist nie zu spät...

(Ich hatte andersrum schon "das Vergnügen", und bin ehrlich froh, dass ich zwischenzeitlich so viel Perl "kann", dass ich auf den Einsatz dieses "Hilfsmittels" verzichten kann - ich habe versucht, die Syntax zu lernen, und bin immer wieder auf die Nase gefallen und hatte dann irgendwann auch keine Lust mehr, irgendwas in dieser überbordenden "Doku" zu suchen. Sei's drum...).

Im ersten Post hier also mal die ergänzte myUtils-Fassung. Da ist eine neue Funktion drin, milight_FUT_to_HUE, bei der kann man optional den Weiß-Wert mitgeben (und eigentlich sollte die auch mit nicht-HUE-Devices bzw. den genuinen MiLight-Bulbs "können").

Das notify dazu müßte in etwa so aussehen:
defmod n_MiLight_RC_WZ_A4 notify wz.remote.a4:(ON|OFF|(brightness|command|bulb_mode|hue|mode|saturation).*) { milight_FUT_to_HUE( 'wz.licht.4' , $EVENT , 'FCFEFF' )}

Im Unterschied zu deinem Code nimmt der myUtils-Code die "anderen Werte" für rgb (sat und bri) aus dem Zieldevice, was m.E. dann besser ist, wenn man nicht immer die FB nimmt, um daran irgendwas zu verstellen.

Bin mal gespann, ob sich die Zahl der notify bei dir nicht leicht erhöht... Wie du siehst, muß man nur wenige Stellen ändern, um dann (so der Code irgendwann fertig ist) im Prinzip beliebige Ziel-Bulbs anzusteuern. (Man kann bestimmt auch so ein universelles DOIF bauen, ich wüßte nur nicht, warum man das tun sollte...).
Die nächste Stufe wäre dann, direkt aus dem MQTT2_DEVICE heraus die Funktion aufrufen zu können... (Mal schauen, eigentlich ist das nicht die große Sache, und das wäre "richtig rund": Einfach die passende Funktion kennen, das Zieldevice angeben, ggf. "etwas" parametrieren, fertig die Laube...)
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 22 Mai 2020, 13:22:56
Die nächste Stufe wäre dann, direkt aus dem MQTT2_DEVICE heraus die Funktion aufrufen zu können...
...das Ergebnis sieht dann in etwa so aus:
defmod MiLight_RC_WZ MQTT2_DEVICE milight_0x5D47_0
attr MiLight_RC_WZ readingList milight/updates/0x5D47/fut089/0:.* { FHEM::attrT_MiLight_Utils::MPDcontrol('myMPD',$EVENT, 'Yamaha_Main') }\
milight/updates/0x5D47/fut089/1:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_links',$EVENT) }\
milight/updates/0x5D47/fut089/2:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_rechts',$EVENT) }\
milight/updates/0x5D47/fut089/3:.* { FHEM::attrT_MiLight_Utils::four_Lights_matrix($EVENT, 'Licht_WoZi_Vorn_Aussen', 'Licht_WoZi_Vorn_Mitte', 'Licht_WoZi_Hinten_Aussen', 'Licht_WoZi_Hinten_Mitte') }\
milight/updates/0x5D47/fut089/4:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Jalousie_WZ',$EVENT) }\
milight/updates/0x5D47/fut089/5:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSO',$EVENT) }\
milight/updates/0x5D47/fut089/6:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSW',$EVENT) }\
milight/updates/0x5D47/fut089/7:.* {}\
milight/updates/0x5D47/fut089/8:.* {}\
milight/states/0x5D47/fut089/[0-8]:.* {}
attr MiLight_RC_WZ stateFormat CommandSet


Im ersten Post die zugehörige neue myUtils - gleich im package-Format.

Die ausgeführten Kommandos bzw. Infos über empfangene, aber noch nicht zugewiesene JSON-Elemente finden sich in dem Reading "CommandSet".

So langsam ist das wohl aus dem [WIP]-Status raus... 8)
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