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

Ok, also immer noch eher schlecht brauchbar, trotz updates in der firmware... Dann muß es auch (noch) nicht in ein template :( .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Heimweh

Ich hatte leider wenig Zeit bisher, werde es mal noch mit anderen Milight Typen probieren. Das Thema mit der Helligkeit und Alexa ist auch noch offen... Muss ich auch mal weiter treiben...

Gesendet von meinem LYA-L29 mit Tapatalk

RaspberryPi, 8 x Intertechnosteckdosen, ETA PU15 über HTTPMOD, Youless Eneergiemonitor, 8 x Technoline Funk Temperatur / Feuchtesensoren über jeeLink, Fritzbox Anbindung, Homematic Rolladen Aktoren, MAX Heizkörperventile + Cube, SONOFF S20, S26, POW, 4ch, OWD, Alexa-fhem, enOcean / Eltako,

Beta-User

Kurze Zwischeninfo: Habe die regexe jetzt (hoffentlich) so angepaßt, dass auch kürzere als 4-stellige hex-ID's keine Probleme mehr machen sollten, ist ab morgen früh/8:00 Uhr per update verfügbar.

[OT]
Bei den shelly's haben wir grade eine nette Diskussion, wie man mit Power-messenden Geräten sinnvoll umgehen kann, was Visualisierung und Steuerbarkeit angeht. Wenn's jemanden interessiert (auch wenn derjenige ggf. keine Shellys hat), die Beiträge sind ab hier zu finden. Das sollte sich nämlich recht einfach z.B. auf tasmota und zigbee2mqtt übertragen lassen ;) .
[/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Snocksman

#228
Irgendwie läuft bei mir gerade nichts mehr mit meinen Milights... Ich wollte gerade ein neues Milight Device in FHEM einrichten, aber dieses wurde nicht erkannt. Also habe ich erstmal alles was mit Milight zu tun hat aus der Config geschmissen und wollte alles mal neu erkennen lassen bzw. einrichten. Das hat damals super funktioniert, jetzt aber leider überhaupt nicht mehr.
Hier mal mein vorgehen:
- Beim ersten Tastendruck auf eine Milight Fernbedienung, wird der Milight-Hub in FHEM erkannt (drücke auf "Save Config")
- Ich gehe in das Hub-Device und wähle das Template "esp_milight_hub_bridge" aus (drücke auf "set" & "Save Config")
Nun sieht das Device in der FHEM-Config wie folgt aus:
define MQTT2_milight_hub_5916066 MQTT2_DEVICE milight_hub_5916066
setuuid MQTT2_milight_hub_5916066 5d965255-f33f-d11a-1b53-724ece91a77c5be4
attr MQTT2_milight_hub_5916066 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_5916066 autocreate 1
attr MQTT2_milight_hub_5916066 bridgeRegexp milight_hub_5916066:milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr MQTT2_milight_hub_5916066 devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr MQTT2_milight_hub_5916066 model esp_milight_hub_bridge
attr MQTT2_milight_hub_5916066 room MQTT2_DEVICE
attr MQTT2_milight_hub_5916066 setStateList on off
attr MQTT2_milight_hub_5916066 stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version

- Ich drücke nochmal eine Taste auf der Milight Fernbedienung und das Milight Device wird erkannt (drücke auf "Save Config")
So sieht das erkannte Device dann erstmal in der Config aus:
define MQTT2_milight_0x6A18_1 MQTT2_DEVICE milight_0x6A18_1
setuuid MQTT2_milight_0x6A18_1 5d9652b1-f33f-d11a-e668-3135dae0d0d335df
attr MQTT2_milight_0x6A18_1 IODev MQTT2_FHEM_Server
attr MQTT2_milight_0x6A18_1 readingList milight/updates/0x6A18/fut091/1:.* { json2nameValue($EVENT) }\
milight/states/0x6A18/fut091/1:.* { json2nameValue($EVENT) }
attr MQTT2_milight_0x6A18_1 room MQTT2_DEVICE

- Ich gehe in das neu erkannte Milight Device und wähle das pasende Template aus. Hier erscheint nun beim drücken auf "set" folgende Meldung: Error checking template regexp: Unmatched ( in regex; marked by <-- HERE in m/([^/]+)[/]( <-- HERE 0x[0-9a-fA-F]{1/ at (eval 1090) line 1.

Was läuft da schief ?!  :-\

Beta-User

Danke für's melden. Da ist ein Ersetzungsmechanismus in AttrTemplate drin, den ich übersehen hatte, sorry.

So sollte es gehen:
par:REMOTE_ID;HEX number representing a specific remote or bridge;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/](0x[0-9a-fA-F]{1\,4})[/].*:, ? $2 : undef }

Update kommt dann demnächst.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Snocksman


Snocksman

#231
So, hab gerade in FHEM ein Update gemacht und jetzt kann ich die Milights wieder wie gewohnt einbinden. Was mir allerdings noch komisch vorkommt ist, dass bei dem Milight_Hub Device kein DevStateicon angezeigt wird, sondern nur der Text "status Version: version"; laut Config sollte das ja anders sein.
Hier nochmal die Config des Milight_Hub Devices:
define MQTT2_milight_hub_5916066 MQTT2_DEVICE milight_hub_5916066
setuuid MQTT2_milight_hub_5916066 5d988380-f33f-d11a-2165-129e952ff04f3a94
attr MQTT2_milight_hub_5916066 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_5916066 autocreate 1
attr MQTT2_milight_hub_5916066 bridgeRegexp milight_hub_5916066:milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr MQTT2_milight_hub_5916066 devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr MQTT2_milight_hub_5916066 model esp_milight_hub_bridge
attr MQTT2_milight_hub_5916066 room MQTT2_DEVICE
attr MQTT2_milight_hub_5916066 setStateList on off
attr MQTT2_milight_hub_5916066 stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version

Muss ich bei dem stateFormat die IP der Bridge einfügen ?!   ???

Beta-User

Schön, dass das jetzt wieder reibungslos läuft.

Wenn die ip_address nicht aufgelöst wird, liegt das daran, dass entweder der Hub nicht neu gestartet wurde, LWT nicht konfiguriert oder eine ältere firmware drauf ist. Seit einigem Monaten gibt es diese Infos via LWT, näheres sollte bei den Praxisbeispielen zu finden sein.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Snocksman

Es lag an LWT, das war auf dem Hub noch nicht konfiguriert.

Snocksman

Mal eine Frage, ob jemand eine Idee hat, wie ich folgendes am besten umsetze...
Ich habe zwei Milight Fernbedienungen, die beide auf die gleiche Lampe angelert sind. In Fhem sind beide Fernbedienungen angelegt, aber eben jeweils als eine eigenständige "Lampe". Wenn ich die Physische Lampe nun an einer Fernbedienung ein- und an der anderen aus-schalte, habe ich in fhem eine Lampe die mir als "an" und eine die mir als "aus" dargestellt wird. Kann man diese Schaltzustände irgendwie kombinieren ? Klar, das irgendwie über zwei notifys zu basteln würde gehen, aber gehts auch irgendwie "eleganter" ?

herrmannj

Nur ein devices benutzen. Dort bei den attr die mqtt Channels beider remote. Nur Update, nicht Status.

Snocksman

Danke für den Tipp, hat funktioniert.

Dafür habe ich jetzt ein neues Problem: Ich habe gerade in FHEM ein Update gemacht und seitdem funktioniert nun der night_mode bei allen Milights nicht mehr. Wenn ich in ein Milight Device hinein gehe und dort "Nacht" auswähle und auf "set" klicke, bekomme ich folgende Fehlermeldung: Unknown argument night_mode, choose one of on off brightness command program mode dim off-till off-for-timer on-till-overnight blink on-for-timer intervals on-till off-till-overnight toggle attrTemplate

Beta-User

Das mit den "doppelten" Abonnements ist jetzt auch im Wiki ergänzt, falls nochmal jemand darüber stolpert. Ist aber mMn nicht auf updates begrenzt, gibt halt nur uU. doppelte Events, wenn man beides subscribed.

Was das mit dem night_mode angeht: Bitte ein RAW von dem ganzen Device, eigentlich sollte das über die diversen Attribute am Ende via setList nach command gemappt werden...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

herrmannj

Zitat von: Beta-User am 11 November 2019, 15:02:34
Das mit den "doppelten" Abonnements ist jetzt auch im Wiki ergänzt, falls nochmal jemand darüber stolpert. Ist aber mMn nicht auf updates begrenzt, gibt halt nur uU. doppelte Events, wenn man beides subscribed.
Wiki: great idea, Danke.

Update vs state: wenn man auch die states abonniert stimmt der Zustand in fhem nicht. "Nur updates" stellt sicher das fhem und die echte Lampe das gleiche sehen/machen.

Beta-User

 :) Das mit den doppelten readingList-Einträgen ist zwar auch Bestandteil der templates (die "0" wird in der Regel mit erfaßt), aber scheinbar erschließt sich der Zusammenhang nicht gleich.

Was "updates"/"states" angeht: das kommt vermutlich darauf an, wie man die settings auf dem Hub eingestellt hat.
Bei updates kommt nur die Differenz, bei states halt der ganze Satz (aber afaik auch vollständig). MMn. schadet es tendenziell nicht, beides reinzuschreiben (jedenfalls dann, wenn beides kommt). Je nachdem, ob man einen Eventhandler dran hängen hat, muß man halt darauf achten, dass man entweder einen der Zweige stilllegt (wie bei der FB-Lösung beschrieben) oder diesen kurzzeitig "taub" stellt, sonst hat man doppelte Events auf die Differenzsätze....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors