WifiLight und MQTT ?

[Bugs]

Hi zusammen,

ich hab mal nen EPS8266 Modul an so ne Billige RGB-Leiste mit IR Fernbedienung gehängt, also µC runter und 3 GPIOs vom ESP_Modul direkt an die Gates der MosFets ( und GND natürlich ).
Da meine DHT22 Sensorknoten am ESP8266 über MQTT ihre Werte schon an FHEM senden, wollt ich jetzt die RGB-Leiste mit einbinden.
Hat jemand schon mal so was in der Art versucht?
Für die käuflichen WLAN_LED_Kontroller bin ich über WifiLight gestolpert.
Aber das unterstützt wohl nur das direkte ansprechen über WLAN, könnte man dafür nicht noch sowas wie costum-light einfügen. Also die Möglichkeit den Output irgendwie mit nem MQTT-DEVICE verküpfen.
Oder geht sowas schon irgendwie?

Bugs

[herrmannj]

Hi,

warum mqtt ?

http://forum.fhem.de/index.php/topic,34464.0.html

vg
joerg

[Bugs]

Warum nicht Mqtt?
Ich find das Konzept dahinter schon sexy.
Direkt zum LED schicken ginge auch, aber die Leiste ist ja noch nicht das Letzte, was ich vor hab
Als nächstes will ich n kleines Touch-LCD an den ESP hängen. Dort kann dann die Temp und Feuchte des Raums angezeigt werden, die Soll_Temp verstellt werden und das Licht gesteuert werden. So ne Art Raumthermostat mit Extras für jeden Raum, parallel zum "Main-Terminal". Und da kann Mqtt seine Stärken voll ausspielen

Wenns schon n IoT Standart gibt, warum den nicht nehmen?

Bugs

Ps: den Link schau ich mir aber trotzdem mal an :-D

[herrmannj]

Hi,

ja passt. Mach doch beides. LEDs per LW12 (Emulation) bzw LD382 wenn Du RGBW brauchst.
Ist ein erwachsenes, getestetes System, einfach im handling, läuft !

Den Schalter musst Du ja "zurückführen", dafür nimmst Du MQTT. Der ESP kann doch zwei Verbindungen, passt perfekt. Den Schalter und das Display musst Du sowieso unabhängig von Wifilight aufsetzen.


vg
joerg

[Bugs]

Kann ich nachvollziehen, aber ab der 2ten Stelle ( die nicht primär FHEM ist ) die die LEDs Steuern soll macht Mqtt mehr Sinn!
Trotzdem danke für die Antworten

Bugs

[herrmannj]

Hi Bugs,

nicht fhem wäre mir jetzt nie in den Sinn gekommen

Wie muss eine Ansteuerung per MQTT denn aussehen ? Auf Netzwerkbasis.

EDITH:

oder vielleicht etwas anders formuliert:

Ich bin mit mqtt nicht vertraut. Mir ist ist bekannt das wir ein MQTT Modul haben und das es eine observer/subscripe pattern benutzt.

Um jetzt abzuschätzen ob möglich/ welcher Aufwand bräuchte ich eine Idee wie die Kommunikation abläuft und ob es Standards gibt wie RGB/RGBW/White sich melden.

Vmtl wird es sinnvoll sein das MQTT Modul für IO zu benutzen und Wifilight das RGB spezifische machen zu lassen. Fades, Farbkorrektur, DIM etc. Oder ?

vg
joerg

[Bugs]

Vmtl wird es sinnvoll sein das MQTT Modul für IO zu benutzen und Wifilight das RGB spezifische machen zu lassen. Fades, Farbkorrektur, DIM etc. Oder ?

Genau das meinte ich mit:

sowas wie costum-light einfügen. Also die Möglichkeit den Output irgendwie mit nem MQTT-DEVICE verküpfen.

Also statt den Output per TCP/IP direkt zu den einzelnen Lampen zu schicken,
wird er einfach an den mqtt Broker geschickt und die Lampe und wer auch immer subscriben sich auf das Topic
und bekommt die neuen Werte wenn sich sich geändert haben.

Bugs

[herrmannj]

Hi

wenn ich was einbauen soll brauch ich mehr Infos

Was, wohin, wie ist das Adressierungsschema ?

Wie muss denn spo eine MSG aussehen ?

vg
joerg

[Bugs]

Ich hab mal als Beispiel einen meiner Sensoren angehängt.
mit:

attr wz_sensor publishSet on off /ESP8266-10412373/led

wird on oder off an das Topic /ESP8266-10412373/led gesendet.

on/off kann aber auch die RGB Werte oder was auch immer aus WifiLight raus kommt sein.

Auf Sensorseite subscribte ich mich dann auf das Topic und bekomme dann ein Callback in dem ich den String dann zerlegen
und die LEDs schalten kann.

Bugs

[herrmannj]

Hi,

ja, einen RGB kann ich Dir geben. Innerhalb Wifilight gebe ich der bulb dann eine Ziel framerate mit. Da müsstest Du mal schauen wie viele RGB Werte pro Sekunde das System aus mqtt / Bandbreite / Sketch / Hardware so (pi mal Auge) verträgt. Vorschlag wären 50ms pro Wert.

Dann müssten wir nur mal rausbekommen wie wir das an das mqtt Modul übergeben.

Wenn Du gerade über Dein Design nachdenkst (planst;) ): mqtt-lesen ist für Wifilight kein Thema, sprich:

- wenn jemand anderes (ohne fhem) die Farbe verändert bekommt fhem das nicht mit.
- Richtiger Weg: mqtt Schalter (oder was auch immer) wird in fhem ausgewertet und fhem setzt die Farbe.

vg
joerg

[Bugs]

Warte warte noch ein bissl mit Coden

In FHEM würden die neuen Werte dann in
attr wz_sensor subscribeReading_hum  /ESP8266-10412373/led
auftauchen, so wie die Temperatur jetzt auch schon.

Aber bin noch in der Designphase und schau wies am einfachsten wäre.
Mit mqtt würde der Weg der Informationen ja nicht von FHEM kontrolliert.
FHEM ist dabei nur Sender/Empfänger verschiedener Topics, so wie alle anderen
mqtt Teilnehmer auch.

Bugs

[herrmannj]

Warte warte noch ein bissl mit Coden

alles gut. Designphase und so, iss mir klar Und mit dem coden, ich habe keine Langeweile. Die Aussagen mit "warte noch" siehst Du bald in anderem Licht :-P. Ne im Ernst, ist nicht so aufwendig.

Generell verstehe ich das jetzt so das ich ein Dummydevice in Wifilight einbaue. mqtt bedient sich per event/reading. Wifilight braucht also für mqtt kein IO. (richtig?)

Das mit dem attr habe ich noch nicht verstanden.  Woher weiß das mqtt modul denn welches reading es nehmen soll ? Oder verstehe ich das falsch ?

btw, RGB ist OK, wenn Du aber mal einen RGBW stripe hast wirds eng . Da müsstest Du dem ESP mehr code spendieren und den mit HSV füttern. Was von Wifilight aus geht.

Mit mqtt würde der Weg der Informationen ja nicht von FHEM kontrolliert.
FHEM ist dabei nur Sender/Empfänger verschiedener Topics, so wie alle anderen
mqtt Teilnehmer auch.

yepp. Um also die Farbe des Wifilight (mqtt-) device aktuell zu halten wenn jemand anderes die farbe setzt kann ich Dir eine Funktion einbauen. (zb update RGB, die könnte die represenation des device "nachziehen".)

Du müsstest dann (ausserhalb Wifilight) das abonnieren und bei Bedarf "update" auf dem Wifilight device aufrufen. Generell kein tiefes Thema aber Wifiligt muss wissen wo die bulb aktuell steht (Farbe, on, off) um bei bedarf einen Farbverlauf auch korrekt "von da aus" starten zu können. Hoffe Du verstehst.

vg
joerg

[Bugs]

Ok, ich werde schon mal die Aktualisierungsgeschwindigkeit über mqtt testen.
Ich habe mal Norbert@ntruchsess angeschrieben, ob er vielleicht n paar Ideen hat.
Ob's kein IODEV braucht weis ich noch nicht so genau.
Hab mir den Code von WifiLight noch nicht angeschaut ( hat mit Perl noch nix zu tun ).
Aber ich stell mir das so vor, es wird irgendwas nach dem EVA Prinzip sein?!
Also ein Bereich der sich um die Eingaben kümmert ( FHEM_Web oder MQTT ),
diese dann an verarbeitenden Teil übergibt ( Farbverlauf, RGB, HSV ?! )
und am Schluß die Ausgabe ( bei WifiLight wirds was mit TCP/IP direkt zur IP sein und dort die Unterscheidung der verschiedenen LED_Kontroller stattfinden ).

Und genau bei der Ausgabe könnte man ansetzen.
Ich denk ein IODEV MQTT wär da die richtige Schnittstelle.
Somit wär Hin- und Rückweg erschlagen.
Oder halt der Weg über ein MQTT_DEVICE, das die Kommunikation erledigt und über Events oder so mit WifiLight spricht...

Bugs

Ps: 170 Aufrufe und keiner weiter hat ne Meinung dazu? Kann ja sein, das mein Vorhaben so keinen Sinn macht :-P .

[Kuzl]

Hallo zusammen,

wie wärs mit diesem Modul? http://fhem.de/commandref.html#MQTT_BRIDGE
Das stellt eine Brücke zwischen den Readings von Wifilight und MQTT her. Damit müssten nur die Readings aktualisiert werden und das senden übernimmt MQTT_Bridge

[herrmannj]

hi Kuzl,

das ist vermutlich der richtige Weg

Leider kenne ich mich mit dem Modul nicht aus, die Frage ist ja wie genau ich von Wifilight aus das Setup der bridge programmatisch beeinflussen kann. Dem bridge Modul gegenüber muss ich mich ja als mqtt device ausgeben und da gibt es sicher Konventionen.

Aktuell möchte ich mir ein reverse engineering des mqtt Moduls dazu ersparen, wir haben ja genug know how hier im forum.

Es gib im übrigen eine  recht interessante Entwicklung.
user gloob hat hier http://forum.fhem.de/index.php/topic,37341.0.html den code für einen mysensors arduino so erweitert das die transitions im controller ablaufen. Kann noch keine queue und kein HSV-in, das ist aber vmtl einfach zu ergänzen.

Soweit ich sehe basiert das auf diesem code https://github.com/FastLED/FastLED.

Das müsste eigentlich auch auf die ESP skalierbar sein. Das wäre für mich ein guter Weg hin zum fhem-led-controller design, also vereinfacht Diy-LW12 mit kompletten Hardware Animationen. Da müsste man ein neues Protokoll erfinden um das auszuschöpfen.

Mal schauen wie es weiter geht

vg
joerg