Milight Status abfragen

Begonnen von Sedonion, 08 Februar 2017, 10:37:51

Vorheriges Thema - Nächstes Thema

Sedonion

Hi Zusammen,

die Steuerung meiner Milights funktioniert soweit gut.
Problem:
Sie werden auch zusätzlich mit der Milight Fernbedienung geschaltet.
Dadurch stimmt der Status nicht; im fhem werden sie als off angezeigt obwohl sie an sind.
Kann ich den aktuellen Status irgendwie abfragen?

Gruß Marco
fhem auf HP Microserver Gen8 mit Openmedivault
- 4 Milight RGB Bulbs an Milight Wifi Controller
- MAX Cube mit 2 Heizkörperthermostaten und 2 Fenstersensoren
- VU+ Solo4k Enigma2
- Fritzbox mit Callmonitor

DeeSPe

Zitat von: Sedonion am 08 Februar 2017, 10:37:51
Kann ich den aktuellen Status irgendwie abfragen?

NEIN!

MiLight is halt keine vollwertige Lösung da der Rückkanal fehlt!
Es können nur dumm Befehle hingesendet werden.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Beta-User

Hallo Marco,

an sich hat Dan recht, ohne weiteres geht das nicht.

ABER: Hier hat schka17 eine ESP8266-basierte Lösung entwickelt, mit der FB-Befehle per MQTT rückgemeldet werden. (Soweit ich das bisher beurteilen kann, ist diese Brücke im übrigen deutlich besser als die orginalen Bridges! Ich nutze seit ca. einer Woche die 4-er Version ohne MQTT, da ich auch sonst kein MQTT nutze).

Was dann noch fehlen würde, wäre das Verknüpfen der (MQTT-) Rückmeldung mit einem konkreten Device. Seweit ersichtlich, hat das bisher noch keiner gemacht.

Im Hinterkopf hat sich bei mir eine Idee festgesetzt, wie man die Limitierung evtl. einfach umgehen könnte, nämlich, indem man (auch?) MySensors nutzt. Ist noch nicht ausgereift, aber im Kern geht es darum, statt einer Port-Kanal-Verknüpfung zur Identifikation der einzelnen Ziel-Leuchtmittel jede dieser Kombinationen als RGBW-Child zu definieren und dann darauf (nur) die relevanten Infos auszutauschen. So könnte man z.B. auch per "Custom"-Reading die FB-Kennung in FHEM hinterlegen und so die Fernbedienung(en) "klonen", also mit FHEM so tun, als käme der Befehl von der Fernbedienung und den ESP dazu motivieren, gleich auszusortieren, an welches Device er Änderungen rückmelden soll (bzw. für welche Devices bei der Bedienung von FB-Gruppen) .
Aber über erste Vorüberlegungen dazu bin ich eigentlich noch nicht rausgekommen, wenn jemand das plausibel findet, können wir uns aber gerne zusammentun.

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

Sedonion

Ok danke.
Dann macht ein toggle keinen Sinn.
Ich wollte mit einem Amazon Dash das Licht umschalten, nur wird das dann so nicht funktionieren.
Schade.

@Beta-User:
Alter Schwede. Ich konnte den Thread nur kurz überfliegen, aber für einen FISI, der Elektronik angeht als "Enduser" zu betrachten ist, sind das böhmische Dörfer :)
In der Entwicklung dessen wäre ich raus, aber gern bereit was zu testen.

Ich habe aktuell nur 4 Bulbs zu steuern, die auch nur in einer Group sind.
Idee: Könnte ich vielleicht mit einem Messgerät das fhem tauglich ist an einer Lampe den Verbrauch messen und anhand dessen erkennen ob die Lampe an ist oder aus?
Gibt es eine Empfehlung für einen Zwischenstecker der sowas leisten kann?
fhem auf HP Microserver Gen8 mit Openmedivault
- 4 Milight RGB Bulbs an Milight Wifi Controller
- MAX Cube mit 2 Heizkörperthermostaten und 2 Fenstersensoren
- VU+ Solo4k Enigma2
- Fritzbox mit Callmonitor

Beta-User

...bin eigentlich auch nur User, aber Not macht erfinderisch ;D.

Vielleicht noch einen Tip, vielleicht paßt das ja auch für den Amazon Dash:
Ich steuere meine Milights teilweise über einen Homematic-Taster, den ich mit einer sequence auswerte. Also ein Tastendruck=An, zwei Tastendrücke innerhalb von 1 sec=Aus, 3x=dimm 30%. Geht bestimmt auch mit dem Dash ;).

Das mit dem Zwischenstecker kommt mir nicht so top vor, weil das vermutlich unterhalb der Empfindlichkeit der Meßgeräte liegt: Habe mal am Anfang feststellen wollen, was so eine Bulb braucht (9W RGBW) und kam - mit einem ELV-Meßgerät auf 13,5W bei voller Helligkeit und ca. 6 W bei 70% (oder so).

Was den verlinkten Thread angeht: Wichtig ist eigentlich das Ergebnis: nimm einen ESP8266 (konkret z.B. einen Wemos D1 mini, einen 2.4GHz-(PA+LNA)-NRF und die Arduino-IDE und schon hast Du eine Bridge, die FHEM nicht ständig wegen fehlgeschlagener Ping-Versuche blockiert und dazu noch flott reagiert... Billiger als die Orginale ist sie auch noch, und die Reichweite größer 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

Sedonion

#5
Ich denk drüber nach.
Ich hab Respekt vor Bauteilen, Platinen etc. Trau ich mich nicht ran, sorry.

Habe aber mit der Original Bridge keine Probleme. Reagiert per FB odfer fhem sofort, die Android app nutze ich nicht mehr.
Ping Timeout lait fhem log kommt etwa 1x pro 1,5 Stunden vor, da hatte ich bisher auch kein Problem mit.
fhem auf HP Microserver Gen8 mit Openmedivault
- 4 Milight RGB Bulbs an Milight Wifi Controller
- MAX Cube mit 2 Heizkörperthermostaten und 2 Fenstersensoren
- VU+ Solo4k Enigma2
- Fritzbox mit Callmonitor

Beta-User

Das mit dem Respekt kann ich nachvollziehen, ich fand das auch lange seeehhhhr abgefahren...

Dann habe ich meine ersten Versuche mit den dusseligen ESP8266-01 gemacht, und auch das war ein Desaster :(. In die Richtung weitergemacht habe ich nur, weil a) die China-Arduinos so abartig billig sind und b) manche eQ3/ELV-Produkte so abartig teuer (Wetterstation). Dann hatte ich erste Erfolge mit MySensors und es hat auch noch Spaß gemacht ;D. Meine Lötereien sehen aber immer noch aus wie Sau...

Du kannst ja auch einfach mal Trockenübungen machen mit der Arduino-IDE, die ist im Verglich zu einer "vollwertigen" Entwicklungsumgebung noch halbwegs überschaubar. Und wenn Du den Code von schka17 compiliert bekommst, wäre auch die "Investition" in einen Wemos, einen NRF und einen Kondensator überschaubar (vorausgesetzt, Du hast Zugriff auf einen Lötkolben bzw. (besser) eine Lötstation): das sind zusammen weniger als 10 Euro.

Ich hatte vorher 4 bridges, da summiert sich das mit den timeouts...
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