HomeStatusDisplay (ESP8266, MQTT, WS2812B)

Begonnen von Joker, 12 März 2017, 23:48:10

Vorheriges Thema - Nächstes Thema

Pfriemler

Zitat von: Joker am 31 August 2018, 09:58:19
1. ... und dann eben über die Topics "/light/kitchen" oder "/window/kitchen" bestimmen kann was man eigentlich meint.
2. ... Aber was mit der Gruppierung möglich ist, ist dass man z.B. mit dem Topic "/light/+" alle Lichter ansprechen kann.
3. ... Ja, also im Prinzip ist die Philosophie von dem ct-Projekt anders ... "setze led 5 auf hellblau" ... / In meiner Variante ... "fenster küche wurde geöffnet" ... Hat beides sicher seine Vor- und Nachteile.
4. Was ich charmant am Code von der ct finde, ist dass es mit mehreren Tasks umgesetzt wurde. Damit muss ich mich mal beschäftigen, das macht das ganze übersichtlicher.
5. ... nicht beliebige Farb- bzw. Helligkeitswerte setzen ... Was wäre denn der Anwendungsfall für dieses dimmen... ?

zu 1. Klingt erst mal sinnvoll. Aber aus FHEM ist es praktischer, die Geräte mehr oder weniger direkt zu mappen, und da heißen sie sowieso unterschiedlich. Das zusätzliche topic stört aber auch nicht - wenn ich etwa ein Notify auf alle meine "FK_.*" = Fensterkontakte baue, kann ich - wenn meine Kontakte in FHEM genauso wie in HomeStatusDisplay heißen - das 1:1 übermitteln - und auch "window/" davor schreiben. Anders sieht das aus, wenn ich die Regex für das Notify weiter fassen könnte, um etwa auch alle Lampen und den Alarmanlagenzustand zu erfassen - dafür bräuchte ich dann jeweils ein weiteres Notify, wenn ich nicht noch zusätzliche if-Schachteln da einbauen will. Geht aber auch.
Und wenn man diese neuere MQTT_Bridge einbaut (habe da erst kurz was quergelesen), hinterlegt man bei den Devices ohnehin den zu übermittelnden MQTT-Topic.

zu 2. die Sache mag attraktiv klingen, aber warum sollte ich alle Anzeigelampen einer Gruppe auf einmal in einen besondren Zustand bringen wollen? Und für eine andere Sache sehe ich wiederum keine Anwendung hier. Mag sein, dass man aus FHEM mit diesem Topic eine Reihe Geräte schalten kann (etwa alles Licht aus oder so), aber die Anzeigelampen sollten sich doch bitte nach dem echten Status der Geräte richten, dafür braucht es eh andere Mechanismen. Alternativ könnte man den Topic auch direkt bei der Gerätedefinition in HomeStatusDisplay anfügen. Dann wäre man vor allem flexibler in der Namensgebung, denn - ehrlich  gesagt - sind mir die vier Kategorien deutlich zu wenig. Ich sende manches im light-topic, was gar kein light-topic ist (etwa den Füllgrad der Tonnen, den Schaltzustand der Steckdosen oder Temperaturwarnungen). Und wenn man die Topics dort variabler ablegen kann, kann man sie doch trotzdem mit Wildcards bedienen.

zu 3. ich sagte schon, was mir da besser gefällt :-)
zu 4. War mir neu, klingt interessant. Derzeit krieg ich das Scheißding gar nicht kompiliert. Liegt aber wohl an meiner Unordnung hier auf dem Rechner. Meine verschiedenen Projekte brauchen leider recht verschiedene Versionen der Libs.

zu 5. Unterscheidung von "Warn-" und "alles ok"-Meldungen. Meine Schaltsteckdosen haben in FHEM etwa ein hellgrünes "AN" und ein dunkelgraues "AUS" - und ein dunkelrotes "HELP", wenn es ein Problem gibt (etwa wenn die Tasmotasteckdosen offline sind). So würde ich die Alarmanlage auch im Ruhezustand als eine dunkle dezente Farbe melden ("alles ok") - das hat einen anderen informatorischen Wert als wenn die LED ganz aus ist. Um alles glimmende muss ich mich dann nicht kümmern, alles helle erfordert Aufmerksamkeit. Das springt auch optisch intuitiver. Jetzt hilft die Unterscheidung zwischen statisch und blinkend/blitzend ja schon auf diesem Gebiet ziemlich weiter. Nur ist Blinken lieber mein Ding, wenn es wirklich dringend ist.
Mir würde dabei reichen, wenn ich zu jeder Farbe im Colormapping einfach noch eine Helligkeit hinterlegen kann.

Andererseits kann ich bei der c't-Variante dann allerdings auch ein freies Colormapping machen - Füllstandsanzeigen von rot über gelb nach grün in 100 Schritten etwa. Wenn da die Werte leicht fluktuieren, fällt das nicht so sehr auf wie ein hartes Umschalten an einer Triggergrenze (rot-gelb oder gelb-grün). Habe das Problem aktuell bei einer per Ultraschall überwachten Tonne. Da muss man dann erst eine Hysterese einbauen, damit es nicht dauert umschaltet... Könnte man ja auch einfach lösen, indem man einfach einen Farbskalenwert an die LED als Zahl schickt und damit das Mapping außer Kraft setzt.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker

Zitat von: Pfriemler am 31 August 2018, 14:28:05
zu 2. die Sache mag attraktiv klingen, aber warum sollte ich alle Anzeigelampen einer Gruppe auf einmal in einen besondren Zustand bringen wollen? Und für eine andere Sache sehe ich wiederum keine Anwendung hier. Mag sein, dass man aus FHEM mit diesem Topic eine Reihe Geräte schalten kann (etwa alles Licht aus oder so), aber die Anzeigelampen sollten sich doch bitte nach dem echten Status der Geräte richten, dafür braucht es eh andere Mechanismen.
Ja natürlich! So meinte ich das auch, schalten von Geräten, nicht mehrere Anzeigelampen in einen Zustand bringen.
Kann aber sein dass das nicht vollständig durchdacht ist, das Projekt habe ich ungefähr ne Woche nachdem ich das erste mal genauer gelesen habe was MQTT überhaupt ist gestartet  ;D

ZitatAlternativ könnte man den Topic auch direkt bei der Gerätedefinition in HomeStatusDisplay anfügen. Dann wäre man vor allem flexibler in der Namensgebung, denn - ehrlich  gesagt - sind mir die vier Kategorien deutlich zu wenig.
Ja könnte man natürlich machen- macht halt das auswerten der empfangenen Topics deutlich aufwändiger (jetzt weiß ich genau wieviele Ebenen ein relevantes Topic hat und welchen Aufbau es hat). Ich stimme aber zu, dass das die flexibelste Lösung wäre.

ZitatIch sende manches im light-topic, was gar kein light-topic ist (etwa den Füllgrad der Tonnen, den Schaltzustand der Steckdosen oder Temperaturwarnungen).
Die Alarm-Gruppe passt eigentlich für sehr vieles, gerade für irgendwelche Warnungen. Ich sende alles was nicht in eine andere Gruppe passt als Alarm.

Zitatzu 5. Unterscheidung von "Warn-" und "alles ok"-Meldungen. Meine Schaltsteckdosen haben in FHEM etwa ein hellgrünes "AN" und ein dunkelgraues "AUS" - und ein dunkelrotes "HELP", wenn es ein Problem gibt (etwa wenn die Tasmotasteckdosen offline sind). So würde ich die Alarmanlage auch im Ruhezustand als eine dunkle dezente Farbe melden ("alles ok") - das hat einen anderen informatorischen Wert als wenn die LED ganz aus ist. Um alles glimmende muss ich mich dann nicht kümmern, alles helle erfordert Aufmerksamkeit. Das springt auch optisch intuitiver. Jetzt hilft die Unterscheidung zwischen statisch und blinkend/blitzend ja schon auf diesem Gebiet ziemlich weiter. Nur ist Blinken lieber mein Ding, wenn es wirklich dringend ist.
Mir würde dabei reichen, wenn ich zu jeder Farbe im Colormapping einfach noch eine Helligkeit hinterlegen kann.
Nun ja, also da kommen wir sehr in persönliche Vorlieben rein.
Ich habe es bei mir so, dass im Initialzustand - also keine Fenster offen, kein Licht an, kein Alarm - alle LEDs aus sind. Es ist meiner Meinung nach deutlich einfacher mit einem Blick zu erkennen ob gar keine LED an ist, oder ob eine LED hell oder dunkel ist - aber wie gesagt, das ist vermutlich Geschmackssache.
Der Vollständigkeit halber mal die Zusammenfassung wie ich es gedacht habe und nutze:
- LED aus: Das Gerät ist im "Grundzustand", also ein Zustand der z.B. der Normalfall sein sollte wenn man das Haus verlässt (Licht aus, Fenster zu...)
- LED an: Gerät ist nicht mehr im Grundzustand, aber erfordert normalerweise auch keine spezielle Beachtung (z.B. ein Licht ist an oder ein Fenster geöffnet, nur eine Information)
- LED blinkt: Gerät ist in einem Zustand, der "besonders" ist und ggf. beachtet werden sollte (z.B. Fenster ist seit mehr als einer halben Stunde geöffnet, Unwetterwarnung liegt vor etc.)
- LED flackert: Gerät ist in einem Zustand der sofortige Aufmerksamkeit erfordert (z.B. ein Wassermelder hat angeschlagen )
- zusätzlich habe ich fixe Farben für gleiche Informationen (z.B. Fenster geöffnet ist immer weiß, Fenster gekippt immer blau)
Damit kann man schon sehr viel Informationen darstellen und trotzdem noch schnell erfassen- dafür habe ich das Display eigentlich gemacht, schneller Überblick über den Gesamtzustand- für Detailinformation hat man ja immer noch eine Webvisualisierung- siehe auch nächster Punkt.

ZitatAndererseits kann ich bei der c't-Variante dann allerdings auch ein freies Colormapping machen - Füllstandsanzeigen von rot über gelb nach grün in 100 Schritten etwa. Wenn da die Werte leicht fluktuieren, fällt das nicht so sehr auf wie ein hartes Umschalten an einer Triggergrenze (rot-gelb oder gelb-grün).
Klar, machen kann man vieles. Aber ist eine LED dafür eine sinnvolle Anzeigemethode und bist du der Meinung du kannst 100 Schritte wirklich auseinanderhalten? Ich finde es da deutlich sinnvoller rot-gelb-grün zu verwenden um einen Überblick zu bekommen, und wenn man es genauer wissen will verwendet man ein vernünftiges Anzeigemedium (Browser mit Webvisu).

eldrik

Hi,

wurde hier bestimmt schon angesprochen, aber der Gerätename ist derzeit auf 25 Zeichen begrenzt.

Aufgefallen ist mir dies bei einem meiner Homematic Rollladenaktoren, der derzeit aus 29 Zeichen besteht.

Greetz
Eldrik

Pfriemler

25 für das Gerät, ohne Zusatztopic? Mappt man das nicht ohnehin zusätzlich irgendwie?
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

eldrik

Keine Ahnung, ich habe gestern nur ein wenig herumexperimentiert und da ist es mir aufgefallen, das die Zeichen in der Weboberfläche abgeschnitten werden.

Wie habt ihr denn bisher die Adressierung und Abbildung des Statusdisplays in Fhem gelöst?

Greetz
Eldrik

Pfriemler

Ich bin erst neu in MQTT. Ich schwanke noch: Den Status der Fenster und Türen könnte ich mit einem Notify publizieren (gleicher Name in FHEM und HSD, alle fangen mit "FK_" an), andererseits gibt es ja diesen MQTT-Bridge-Mechanismus, wo man das Topic als Attribut bei den Geräten hinterlegt und die ihren geänderten Status dann sozusagen selbst per MQTT publizieren. Ich werde aber die eine oder andere LED auch routinengesteuert nutzen.
Derzeit habe ich gerade mal 4 MQTT-Geräte und überlege damit noch jetzt zu MQTT2 zu wechseln, Akut fehlen mir Ruhe und Zeit, aber ich bin für Lösungen immer offen ...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Pfriemler

@Joker:Ein spätes Danke für Deine Antwort. Ich werde mich dann mit dem Alarm-Topic arrangieren und bin inzwischen auch auf "aus=alles gut" umgeschwenkt - seit ich das auf dem 16-LED-Homematic-Display geändert habe, gefällt es allen besser.
Zur LED und 100 Schritten: Nein, natürlich kann ich die nicht auseinanderhalten an der Farbe. Aber der grobe Füllstand (in diesem Fall einer Regentonne) ist an dieser Stelle ausreichend - und die Fluktuaton der Anzeige ohnehin im einstelligen Prozentbereich. Wenn ich den Füllstand klassifiziere (voll, halb, leer), benötige ich dafür Grenzen und Hysteresen, wenn bei Fluktuation um eine Grenze die Farbe nicht ständig springen soll. So wechselt die LED dann eben kaum sichtbar ihre Farbe - aber ob rot, orange, gelb, gelbgrün etc. sieht man doch sofort. In TabletUI wäre das ein Balkendiagramm oder eine Torte. Die löst man ohne zusätzlich Zahl auch nicht genauer auf.
Deswegen fände ich eine Farbkreisdefinition (mit von-bis-Grenzen) schon nett. Alternativ würde eine Bypass-Ansteuerung mit direkten Farbwerten reichen - der Sketch rechnet die definierten Farben doch sicher in RGB-Stufen um. Schickt man statt eines definierten Zustands (also "on", "off", usw) einfach einen sechstelligen Hexwert, dann sollte die LED in dieser Farbe leuchten und fertig.
Das Studium des Sketches steht schon auf der ToDo - wenn ich eine Idee zur Umsetzung habe, melde ich mich.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Joker

Zitat von: eldrik am 12 September 2018, 21:21:50
Aufgefallen ist mir dies bei einem meiner Homematic Rollladenaktoren, der derzeit aus 29 Zeichen besteht.

Ja, es ist so dass der Name begrenzt ist. Kannst du -interessehalber- mal so einen langen Namen posten? Ich war eigentlich der Meinung das 25 Zeichen locker ausreichen. Beschränken muss ich es an irgendeiner Stelle.

Zitat von: eldrik am 13 September 2018, 12:18:38
Wie habt ihr denn bisher die Adressierung und Abbildung des Statusdisplays in Fhem gelöst?

Zitat von: Pfriemler am 13 September 2018, 12:47:01
Ich bin erst neu in MQTT. Ich schwanke noch: Den Status der Fenster und Türen könnte ich mit einem Notify publizieren (gleicher Name in FHEM und HSD, alle fangen mit "FK_" an), andererseits gibt es ja diesen MQTT-Bridge-Mechanismus, wo man das Topic als Attribut bei den Geräten hinterlegt und die ihren geänderten Status dann sozusagen selbst per MQTT publizieren. Ich werde aber die eine oder andere LED auch routinengesteuert nutzen.

Meine Empfehlung -und ausschließliche Nutzung meinerseits- ist die Verwendung des MQTT Bridge Mechanismus. Meine Anwendungsfälle sind immer so, dass es zu den LEDs auf dem Display auch irgendein physikalisch vorhandenes Gerät gibt, welches in FHEM schon existiert. Die MQTT Bridge übernimmt die Umsetzung auf MQTT Topics.
Prinzipiell könnte man das ohne physikalisches Gerät genauso machen: Routinegesteuert einen Dummy setzen, und auf diesen Dummy eine MQTT Bridge aufsetzen.

Zitat von: Pfriemler am 13 September 2018, 13:00:19
Zur LED und 100 Schritten: Nein, natürlich kann ich die nicht auseinanderhalten an der Farbe. Aber der grobe Füllstand (in diesem Fall einer Regentonne) ist an dieser Stelle ausreichend - und die Fluktuaton der Anzeige ohnehin im einstelligen Prozentbereich. Wenn ich den Füllstand klassifiziere (voll, halb, leer), benötige ich dafür Grenzen und Hysteresen, wenn bei Fluktuation um eine Grenze die Farbe nicht ständig springen soll. So wechselt die LED dann eben kaum sichtbar ihre Farbe - aber ob rot, orange, gelb, gelbgrün etc. sieht man doch sofort
Ja, ich sehe den Anwendungsfall schon. Wenn du Ideen zur Umsetzung hast, melde dich gerne. Behilflich sein kann ich vermutlich schon, aber für eine komplette Umsetzung fehlt mir die Zeit.

eldrik

#98
Zitat von: Joker am 13 September 2018, 14:48:20
Ja, es ist so dass der Name begrenzt ist. Kannst du -interessehalber- mal so einen langen Namen posten? Ich war eigentlich der Meinung das 25 Zeichen locker ausreichen. Beschränken muss ich es an irgendeiner Stelle.

Klar

CUL_HM_HM_LC_Bl1PBU_FM_298EDC

ist aber auch eine alte Autocreate Definition vom CUL_HM Modul wenn man heute den Rollladen definieren würde, dann kommt meine ich nur ein 8 Zeichen langer HM..... Name.

Zitat von: Joker am 13 September 2018, 14:48:20
Meine Empfehlung -und ausschließliche Nutzung meinerseits- ist die Verwendung des MQTT Bridge Mechanismus. Meine Anwendungsfälle sind immer so, dass es zu den LEDs auf dem Display auch irgendein physikalisch vorhandenes Gerät gibt, welches in FHEM schon existiert. Die MQTT Bridge übernimmt die Umsetzung auf MQTT Topics.
Prinzipiell könnte man das ohne physikalisches Gerät genauso machen: Routinegesteuert einen Dummy setzen, und auf diesen Dummy eine MQTT Bridge aufsetzen.

Ich habe mit der Bridge noch nicht wirklich gearbeitet aber in der Tat viele bis alle Geräte bereis in Fhem definiert, magst du vl. mal ein Codebeispiel liefern?

Edit: OK selbsterklärend funzt ;D

War es eigentlich beabsichtigt, dass man die LEDs nicht ausschalten kann? Im Code habe ich die Color None gefunden aber sie war in den betroffenen Dateien nicht weiter behandelt.

Ich habe heute als Versuch ein paar der Dateien entsprechend um die Farbe NONE erweitert und jetzt gehen die LEDs auch passend aus :)

Greetz
Eldrik

Joker

#99
Zitat von: eldrik am 13 September 2018, 16:20:29
War es eigentlich beabsichtigt, dass man die LEDs nicht ausschalten kann? Im Code habe ich die Color None gefunden aber sie war in den betroffenen Dateien nicht weiter behandelt.

Ich habe heute als Versuch ein paar der Dateien entsprechend um die Farbe NONE erweitert und jetzt gehen die LEDs auch passend aus :)
Aus gehen die LEDs dann, wenn auf einem definierten Topic eine undefinierte Message empfangen wird  :)
Also du hast beispielsweise definiert dass "fhem/status/light/kitchen on" eine Led auf blau schalten soll, dann wird bei Empfang einer Message "fhem/status/light/kitchen xx" (wobei xx irgendwas anderes als on ist) die LED ausgeschaltet.
Sollte so gehen.

Edit: Was die langen Namen angeht, man kann mit "rename" diese ja auch nachträglich umbenennen. Aufpassen muss man nur wenn die Namen in irgendeinem Stück Code verwendet werden, das wird natürlich nicht automatisch nachgezogen..

eldrik

Zitat von: Joker am 13 September 2018, 16:57:58
Aus gehen die LEDs dann, wenn auf einem definierten Topic eine undefinierte Message empfangen wird  :)
Also du hast beispielsweise definiert dass "fhem/status/light/kitchen on" eine Led auf blau schalten soll, dann wird bei Empfang einer Message "fhem/status/light/kitchen xx" (wobei xx irgendwas anderes als on ist) die LED ausgeschaltet.
Sollte so gehen.
Ah ok, darüber bin ich bisher nicht gestolpert bzw. hab es überlesen, dass das Verhalten so geplant ist. Ich finde es persönlich besser, direkt bei der Defintion von off, closed, locked etc. auswählen zu können, dass die LED ausgehen soll.

Zitat von: Joker am 13 September 2018, 16:57:58
Edit: Was die langen Namen angeht, man kann mit "rename" diese ja auch nachträglich umbenennen. Aufpassen muss man nur wenn die Namen in irgendeinem Stück Code verwendet werden, das wird natürlich nicht automatisch nachgezogen..

Ja mit rename kann man bestehende Definition umbennen, ich bin jetzt deinem Tipp mit der Bridge gefolgt und hab mir entsprechende Bridges angelegt  :)

Greetz
Eldrik

Joker

Zitat von: eldrik am 14 September 2018, 07:04:44
Ah ok, darüber bin ich bisher nicht gestolpert bzw. hab es überlesen, dass das Verhalten so geplant ist. Ich finde es persönlich besser, direkt bei der Defintion von off, closed, locked etc. auswählen zu können, dass die LED ausgehen soll.
Am Anfang war die Implementierung so dass man das angeben musste. Ich habe dann nur festgestellt, dass ich dadurch quasi die doppelte Anzahl an Einträgen in der Konfiguration hatte - da man ja dann für jede LED die irgendwann eingeschaltet wird, auch den Trigger für aus angeben muss.
Aber was soll dann passieren, wenn eine unbekannte Nachricht auf das Topic kommt? Aus meiner Sicht muss man die LED dann auch ausschalten, da der Status ja dann nicht mehr dem Status entspricht, bei dem eingeschaltet werden soll. Also habe ich es dann so gemacht, dass JEDE unbekannte Nachricht die LED ausschaltet.

NorbertW

Hallo Joker,

dank der guten Anleitung konnte ich dein Projekt erfolgreich nachbauen und problemlos in FHEM integrieren.
Ein großes Lob auch für die super Software!

Wenn man jetzt noch Taster an die freien GPIOs anschließen könnte, deren Status dann mittels MQTT-Message an den Broker gesendet würden, wäre das Projekt perfekt.
Könntest du dir vorstellen dieses Feature in deine Software einzubauen?

Viele Grüße
Norbert
FHEM6.2 auf RPI3+ unter Buster
HM-MOD-RPI(Dis-WM55,LC-SW1-BA-PCB,LC-SW4-PCB,MOD-Em-8,MOD-Re-8,OU-CM-PCB,OU-LED16,
PB-2-WM55,SCI-3-FM,SEC-MDIR,SEC-SC,SEC-SCo,SEC-SD,SEN-MDIR-SM,SWI-3-FM,Sen-MDIR-O)
Yamaha RX-V475 & BD-S473,yaVDR,SamsungTV UE40D5700RS,Medion IRadio P85017,Milight RGBW2,
DS1820,BME280

burgi110

Hallo, ich bin ein  Neuling.

Ich habe es geschaft die Sw auf einen Wemos zu flashen.

Aber ich schaffe es nicht aus Fhem Infos an das Display zu senden:

hier meine Konfig:

MQTT_BRIDGE

defmod MQTT_194 MQTT_BRIDGE Sonoff_194
attr MQTT_194 DbLogExclude .*
attr MQTT_194 IODev myBroker
attr MQTT_194 comment xxx
attr MQTT_194 publish-topic-base /fhem/status/Light/Sonoff_194/
attr MQTT_194 publishReading_POWER1 /fhem/status/Sonoff_194/POWER1
attr MQTT_194 publishReading_state /fhem/status/Sonoff_194/state
attr MQTT_194 publishReading_status /fhem/status/Sonoff_194/status
attr MQTT_194 publishState /fhem/status/light/Sonoff_194
attr MQTT_194 retain 1
attr MQTT_194 room Display


HomeStatusDisplayV0.6_dev:
Status topic :fhem/status/#

Device Mapping:
7   Sonoff_194   Light   7


Was mache ich falsch


wenn ich das hier aus mosquitto absetze :
mosquitto_pub -d -t fhem/cmd/statusdisplay/test -m 1  (2 3 4 5)
kann ich die Farben des Displays schalten.


Joker

Hi
also wenn du im Device Mapping das Gerät "Sonoff_194" genannt hast vom Typ "Light", dann muss das Topic das ans Display gehen muss so heißen:

fhem/status/light/Sonoff_194 mit entsprechender Payload wie im Color Mapping definiert (Color Mapping ist notwendig, hast du eins definiert?).

Sende mal diese Message mit mosquitto, das sollte dann gehen. Dann musst du noch dafür sorgen dass dein Gerät auch entsprechend das Topic sendet  :)