Bastelprojekt WLAN RGB Controller für ca. 6€

[Pf@nne]

Moin,

ein compilierbarer Arbeitsstand der Library reicht doch, geht ja nur um die MQTT-Anbindung.
Momentan lässt sich der GitHub-Stand ja nicht compilieren.

Schönen Tag....

[mrpj]

Moin,

Ich vermute die Frage bezieht sich auf die Ausgabe. Wenn es um die Eingabe (also die API) geht reicht HSV, HSL oder RGB. Da muss (ich sage sogar sollte) kein Weiß extra sein weil alle drei Modelle die Farbe inklusive Weiß beschreiben. Was fehlt ist die Weißtemperatur weshalb ich für HSVK (HSLK, RGBK) plädiere. Erklärung folgt.

Mit der Frage wollte ich eher nochmal die Sinnhaftigkeit von 5 Kanälen (auf Hardware Seite) aufgreifen. In meinem Led Verständnis hat es Sinn gemacht, zusätzlich zu den 3 Grundfarben, weiß mit aufzunehmen, da sich dann auch Pastellfarben "besser" mischen lassen.

Jetzt wo ich mich mehr mit den Farbmodellen auseinander gesetzt habe, stelle ich die Sinnhaftigkeit von 2 weißkanälen in Frage. Denn wenn ich einen warmweißen Led Streifen habe, kann ich mit der Zugabe von blau die Farbtemperatur zu einem Kaltweiß verschieben - ohne einen Kaltweißen LED Streifen zu benötigen.
Macht es denn in der Ausgabe überhaupt noch Sinn, Kaltweiße und Warmweiße  LED Streifen gleichzeitig zu haben?

Das ganze macht nur Sinn, solange die Sättigung bei 100 ist. Sobald blau dazu kommt, wird die Gesammthelligkeit ja wieder angehoben.
Um das konstant zu halten, müsste man nun die Maximalgrenze der Helligkeit zu (R+B+G)/3 rechnen. Und damit wäre man bei dem HSI Model angekommen.

Das stimmt so nicht ganz.
Wenn die Sättging < 100 ist kommt zwar blau dazu - dafür werden ja Grün und Rot weniger.

Beispiel: HSV ist 0,80,100

Hue 0 ist 100% rot, V "wäre" rot mit 100%. - ABER - nur zu 80% gesättigt.

Bedeutet alle Kanäle (bei RGB) 20% (100-S) an. Der Farbanteil (hier rein rot) sind S = 80%.

Es kann sein, dass mir ein Berechnungsschritt fehlt, aber HSV(0,80,100) ergibt RGB(255, 51, 51).
Wenn ich nun die Helligkeit der LEDs den Wert 0 - 255 (ohne logarithmische Korrektur für den Moment) habe, würde R mit 255 leuchten, Grün mit 51, und Blau mit 51. Im Vergleich zu HSV(0,80,100) RGB(255,0,0). Hat sich also die "Gesamthelligkeit" die von 255 auf 307 erhöht.

Gehen wir mal auf Gelb - HSV(60,100,100). Grün und Rot mit 255 leuchten dann "voll", Blau leuchtet gar nicht. Gesamthelligkeit liegt diesmal bei 510. Wenn ich nun auf HSV(60, 80, 100) gehe, dann kommen noch 51 Anteile von Blau "dazu" - also liegen wir bei der Gesamthelligkeit bei 561.

Den Vorschlag den ich gemacht hab, die Berechnung auf 3 Sektoren zu verkleinern, macht nur Sinn, wenn man die Sättigung nicht verringert. Bsp Gelb: HSV(60,100,100) würde dann R mit 127.5 Anteilen und G mit 127.5 Anteilen "Helligkeit" ergeben. Gesamthelligkeit bei Maximal 255. Bei HSV(60,80,100) würde dann 51 Anteile Blau additiv beigemischt - 127.5+127.5+51 = 306. Also erhöhen wird die Gesamthelligkeit wieder.

Das ganze bezieht sich nur auf die Anteile, ohne Korrektur für die Helligkeitswahrnehmungskurve des Menschen.

ich habe gerade mal den verlinkten HSL Blogbeitrag überflogen und bin der Meinung das er das HSL Modell nicht richtig wiedergibt.

Aus dem Blogbeitrag und der Diskussion hier nehme ich erstmal folgendes mit:
HSL ist ein Modell, bei dem zu voll gesättigten Farben noch weiß (luminance, lightness, intensity) hinzuaddiert wird. Dadurch kommt es dem Berechnungsmodell von RGB + W Leds "nahe" (zumindest im ersten Moment).

Da bei beiden Modellen die Berechnung von HS(I/V/L) zu RGB erfolgen muss um das mit LEDs wieder zu geben, macht es für die Berechnung keinen Unterschied

Die Umrechnung von HSI/V zu RGB gleicht nicht automatisch die Unterschiedlichen Helligkeiten (Lumen) von Mischfarben aus.
(theoretisch hat Gelb "dopppelt soviel" Lumen wie Rot oder Grün, da bei Gelb Rot und Grün komplett an sind) 

Inwiefern nehmen wir denn den Helligkeitsunterschied zwischen Gelb und Rot/Grün war? Ist die Korrektur aus dem Blogbeitrag Intensität/Helligkeit/Lichtausgabe von R+G+B = 1 nötig/hiflreich um einen "korrekten Farbraum" abzubilden

Wenn am Ausgang dann ist das ineffizient und führt bei der logarithmischen Korrektur sogar zu Fehler. (Die Farbe verändert sich bei einem fade über V).

Die logarithmische Korrektur sollte nur auf V und vor dem Mixer stattfinden.

Ich übernehme den Gedankengang von dir. Danke dir für das Rechenbeispiel/Rechenvorschlag

ein compilierbarer Arbeitsstand der Library reicht doch, geht ja nur um die MQTT-Anbindung.
Momentan lässt sich der GitHub-Stand ja nicht compilieren.

Nimm mal vorrübergehend das gist hier :
https://gist.github.com/patrickjahns/b86f264df084af338e43

[mrpj]

@Pfanne

Ich hab gesehen dass schon Code auf github gewandert ist. Ich hab kurz drüber geschaut und mir sind ein paar Sachen aufgefallen

Daher zwei Bitten an dich:
Bitte arbeite auf einer seperaten Branch und nicht am Master v.a. wenn es nur "testcode" ist. Jedes pull request mit einem veränderten Master wird schwierig zu pflegen v.a. wenn die Änderungen nicht nur Anpassungen sind - sondern auch das Grundgerüst verändern (WifiManager z.B.)

Ich möchte das Gerüst wie es gerade ist WifiManager, Arduino OTA beibehalten - vor allem auch aus dem Grund, das in der späteren Firmware keine festen Variablen (ssid, passwort, IP ) mehr vorhanden sind - sondern beim ersten Verbinden alles eingegeben wird.

WifiManager bietet hier ein gutes Grundgerüst
https://github.com/tzapu/WiFiManager#custom-parameters

Beispiel für mqtt parameter
https://github.com/tzapu/WiFiManager/blob/master/examples/AutoConnectWithFSParameters/AutoConnectWithFSParameters.ino

[Pf@nne]

Moin Patrick,

den Branch wollte ich aufmachen sobald die "esp_rgbww_firmware" compilierbar ist.
Momentan fehlt mir ja noch die RGBWW lib. Das Grundgerüst hätte ich auch so gelassen.
Bin momentan nur dabei meinen Sketch auszumisten und die MQTT-Grundkommunikation herzustellen.
Im zweiten Schritt werden dann die Zugangsdaten variabel.

Ich lege aber gleich mal einen neuen Branch an.....

EDIT:

Nimm mal vorrübergehend das gist hier :
https://gist.github.com/patrickjahns/b86f264df084af338e43

Hab ich eben erst gesehen....

EDIT:
#include "RGBWWLed.h" ich finde nur die *.cpp

[mrpj]

EDIT:
#include "RGBWWLed.h" ich finde nur die *.cpp

Runterscrollen

https://gist.github.com/patrickjahns/b86f264df084af338e43#file-rgbwwled-h

GIST ist nen ganz angenehmes pastebin - wenn man mal nur codefetzen oder einzelne Dateien zur Verfügung stellen möchte

[Pf@nne]

Runterscrollen

Hatte ich.....
GIST kannte ich noch nicht, daher bin ich davon ausgegangen, dass nur ein File angezeigt wird.....
Die Trennung zu *.h hab ich überscrollt.......

[herrmannj]

Hi mrpj

das mit der Helligkeit hatte ich falsch verstanden. Du addierst die Kanäle.

Den Vorschlag den ich gemacht hab, die Berechnung auf 3 Sektoren zu verkleinern, macht nur Sinn, wenn man die Sättigung nicht verringert. Bsp Gelb: HSV(60,100,100) würde dann R mit 127.5 Anteilen und G mit 127.5 Anteilen "Helligkeit" ergeben. Gesamthelligkeit bei Maximal 255. Bei HSV(60,80,100) würde dann 51 Anteile Blau additiv beigemischt - 127.5+127.5+51 = 306. Also erhöhen wird die Gesamthelligkeit wieder.

Wenn man das zu Ende denkt wirds gefährlich: Weiß ist (in RGB) 255,255,255. Das müsste man dann ja auch dritteln

Inwiefern nehmen wir denn den Helligkeitsunterschied zwischen Gelb und Rot/Grün war? Ist die Korrektur aus dem Blogbeitrag Intensität/Helligkeit/Lichtausgabe von R+G+B = 1 nötig/hiflreich um einen "korrekten Farbraum" abzubilden

Meiner Erfahrung nach ein ganz klares NEIN.

Weil: das menschliche Auge ist extrem tolerant wenn es um die Helligkeitsunterschiede geht. Die Pupille geht einfach weiter zu und gleicht das aus - man merkt da einfach nichts von. Das ist ja auch der Grund warum die logarithmische Korrektur bei V-Fades notwendig ist damit die schön aussehen.

In der Praxis stehen dem ja auch noch ganz andere "Probleme" gegenüber. Die Helligkeit der einzelnen Farben innerhalb eines strips sind ja auch extrem unterschiedlich. Ich habe mal exemplarisch (aus ebay) folgende Daten gefunden (nur Beispiel)

Rot:                 101 LUX                       437 LUX    (4,30 x heller)
Grün:               249 LUX                       608 LUX    (2,44 x heller)
Blau:               183  LUX                      610 LUX    (3,33 x heller)
Weiß:              489  LUX                    1598 LUX    (3,27x heller)

Die müsste man ja jetzt auch noch "leveln". Die erste Spalte sind Standard LEDs (was auch immer). Bedeutet aber das man weiß nur mit max 20% ansteuern dürfte und zusätzlich müsste man das bei Mischfarben weiter runter fahren.

Alles Quatsch - da kommt irgendwann nix brauchbares (meint Lichtmenge) mehr raus.

Die Farbkorrektur ist wichtig (das merkt das Auge sofort)!. Die Helligkeit darf man (aus converter Sicht) in weiten Grenzen einfach durchwinken - soll ja auch hell werden

Jetzt wo ich mich mehr mit den Farbmodellen auseinander gesetzt habe, stelle ich die Sinnhaftigkeit von 2 weißkanälen in Frage. Denn wenn ich einen warmweißen Led Streifen habe, kann ich mit der Zugabe von blau die Farbtemperatur zu einem Kaltweiß verschieben - ohne einen Kaltweißen LED Streifen zu benötigen.
Macht es denn in der Ausgabe überhaupt noch Sinn, Kaltweiße und Warmweiße  LED Streifen gleichzeitig zu haben? 

Vorschlag: mach das doch konfigurierbar.

Am Ausgang des Mixers/Converter kommt doch sowieso RGB oder mit gleichem Aufwand RGBW raus.

Wenn der User einen RGB Stripe verwendet einfach Weiß auf alle Kanäle addieren.
Wenn der User einen zusätzlichen White Channel verwendet passt sowieso.

Der Weiß Channel mus ja sowieso speziell mit den Kelvins behandelt werden. Bei WW/CW ist das am einfachsten - einfach zwischen den beiden gewichten.

Die anderen beiden Varianten sind etwas komplexer zu berechnen. Schieb es auf der roadmap nach hinten  Ist doch erst mal genug zu tun.

Allerdings solltest Du bei den Fades/Transitions neben HSV die Kelvins als vierten Wert schon mit einplanen. Dann wird auch ein fade von cw nach ww in 20Sec möglich. Das greift aber erst nach dem Mixer.

vg
joerg

[Pf@nne]

Die GIST-Version passt noch nicht wirklich zu dem GitHub-Sketch...

C:\Users\Admin\Documents\Arduino\libraries\RGBWWLed\RGBWWLed.h:137:1: warning: narrowing conversion of '516' from 'int' to 'const unsigned char' inside { } [-Wnarrowing]

davon hab ich reichlich.....

Ist ja auch erstmal nicht so wichtig.....mach dir keinen Stress.
Ich baue mal ein MQTT-Grundgerüst um per MQTT z.B. HSVColor(HUE,SAT,VAL) zu senden und dann die entsprechenden Routinen anzustoßen.
Das können wir dann einfach in dein Gerüst integrieren.

Gruß
Pf@nne

[Pf@nne]

Moin,

ich habe basicMQTT in deinen Sketch implementiert, läuft soweit stabil.

Code Auswählen Erweitern

LastIPOktet/API/HSVColor 200,200,200,50,50
Steuert jetzt die PWM-Ausgabe an. Wobei "LastIPOktet" das letzte Oktet der vom DHCP zugewiesenen IP ist.

Wenn ihr die API-Struktur endgültig festgelegt habt, kann ich gerne nachbessen.

Ich hoffe, das hilft euch weiter........

EDIT:
Der WEB-Server läuft auch.

Code Auswählen Erweitern

http://192.168.1.43/rgbww?r=1000&g=1000&b=1000&ww=1000&cw=1000

Hast du OTA schon getestet oder bisher nur eingebunden?

[mrpj]

Guten Abend zu später Stunde,

ich hab heute mal mich um das updated des Board Layouts gekümmert
- 0805 SMD Wiederstände (statt 0603)
- ADC mit Spannungsteiler angebunden
- Unter dem ESP8266 mehr "Platz" geschaffen (kann - muss aber nicht, mit dem Empfang helfen)
- Leiterbahnen eine Ecke kleiner gemacht

https://github.com/patrickjahns/esp_rgbww_controller/tree/v1.1

bzw. als exportieres Bild
https://github.com/patrickjahns/esp_rgbww_controller/blob/v1.1/pictures/rgbww-full.png

Werde das neue Layout dann für die Bestellung vorschlagen....

Auch hab ich vorhin mal nach neuen Quellen (nicht China) für die FETs geschaut - ärgere mich gerade mit dem Verkäufer auf Aliexpress herum. Ich hätte nicht gedacht, das es Sinn machen würde, Transistoren/FETs zu fälschen, aber scheinbar ist das wohl nicht so selten was man im Internet liest....


Was ich auch noch herausgefunden hab - mit 470uF Elko und Spannungsüberwachung alle 10ms gibt es eine Chance den letzten Wert zu speichern, aber noch gering. Ich werde mal weitere Kapazitäten die Tage testen. Das Problem ist , im Normalfall braucht der ESP nur 20-30 mA (gute Signalstärke, kein aktiver Traffic) - kann aber bis zu 250mA (schlechtes Signal, aktiv) verbrauchen. Den ersten Fall kann man mit 470 bzw 1000uF lange genug Puffern - den zweiten Fall nicht. Somit wird das Speichern bei Strom Weg (Lichtschalter aus) schwierig.

Die alternative mit regelmäßigem Speichern wiedersagt mir. Bei 5000-10000 Schreibzyklen bevor der Eeprom hops geht, und bei ca 10-100 Befehle pro Tag kommt man dann nur auf eine Lebenszeit zwischen  500 - 1000 Tage. Mir persönlich zu wenig. Aber mir reicht es, wenn der ESP dauerhaft Strom hat und ich ihn per Handy/Tablet/Bluetooth Taster ein/auschalten kann. Brauch keinen regulären Lichtschalter an der Wand

das mit der Helligkeit hatte ich falsch verstanden. Du addierst die Kanäle.
Wenn man das zu Ende denkt wirds gefährlich: Weiß ist (in RGB) 255,255,255. Das müsste man dann ja auch dritteln

Das ist ja genau das was in dem Beitrag zu HSI gemacht wird - im Grunde ist es logisch - aber nur sofern die Lichtausbeute aller Farben gleich wäre. Aber dazu hast du ja mehr oben schon geschrieben.

Weil: das menschliche Auge ist extrem tolerant wenn es um die Helligkeitsunterschiede geht. Die Pupille geht einfach weiter zu und gleicht das aus - man merkt da einfach nichts von. Das ist ja auch der Grund warum die logarithmische Korrektur bei V-Fades notwendig ist damit die schön aussehen.

(....)
Alles Quatsch - da kommt irgendwann nix brauchbares (meint Lichtmenge) mehr raus.

Die Farbkorrektur ist wichtig (das merkt das Auge sofort)!. Die Helligkeit darf man (aus converter Sicht) in weiten Grenzen einfach durchwinken - soll ja auch hell werden

Ich glaube da hast du den Nagel auf den Kopf getroffen - es soll hell werden (und auch schön aussehen ). Danke dir für den ganzen Input! Die Erfahrung ist gerade beim herumexperimentieren und das "richtige" ausloten sehr hilfreich!

Vorschlag: mach das doch konfigurierbar.

Am Ausgang des Mixers/Converter kommt doch sowieso RGB oder mit gleichem Aufwand RGBW raus.

Wenn der User einen RGB Stripe verwendet einfach Weiß auf alle Kanäle addieren.
Wenn der User einen zusätzlichen White Channel verwendet passt sowieso.

Der Weiß Channel mus ja sowieso speziell mit den Kelvins behandelt werden. Bei WW/CW ist das am einfachsten - einfach zwischen den beiden gewichten.

Ist die Mischung von 50% WarmWhite und 50% ColdWhite dann ein neutrales Weiss, oder muss man dort einen anderen Algorithmus ansetzen?

Ich hatte mal nen Artikel von einem Hersteller gefunden. Da drinnen ging es um die Fertigungstoleranz und damit entstehende Verschiebung der Farbtemperatur - mit der "richtigen" Auswahl der einzelnen Chips soll man wohl die Farbtemperatur wieder mitteln können.

Die anderen beiden Varianten sind etwas komplexer zu berechnen. Schieb es auf der roadmap nach hinten  Ist doch erst mal genug zu tun.

Das stimmt - gerade geht es darum Prioritäten zu setzen und ein vernünftiges Grundgerüst zu etablieren. Sobald die Library ne gute Struktur hat, ist es auch einfach das ganze zu erweitern (auch von anderen Leuten).

Allerdings solltest Du bei den Fades/Transitions neben HSV die Kelvins als vierten Wert schon mit einplanen. Dann wird auch ein fade von cw nach ww in 20Sec möglich. Das greift aber erst nach dem Mixer.

Danke für den Hinweis - kommt mit auf die ToDo Liste

Die GIST-Version passt noch nicht wirklich zu dem GitHub-Sketch...davon hab ich reichlich.....

Seltsam, bei mir kommt der Fehler nicht - ich schaus mir dann mal an

Code Auswählen Erweitern

LastIPOktet/API/HSVColor 200,200,200,50,50
Steuert jetzt die PWM-Ausgabe an. Wobei "LastIPOktet" das letzte Oktet der vom DHCP zugewiesenen IP ist.

Wenn ihr die API-Struktur endgültig festgelegt habt, kann ich gerne nachbessen.

Ich hoffe, das hilft euch weiter........

Danke dir für die Mühe - ich schau es mir mal an. IP Configuration und ähnliches würde ich dann auch in das WifiManager Portal / Settings Webseite mit einbauen.

Eine Frage zu PubSub - welche Latenz hat MQTT?

EDIT:
Der WEB-Server läuft auch.

Code Auswählen Erweitern

http://192.168.1.43/rgbww?r=1000&g=1000&b=1000&ww=1000&cw=1000

Beachte dass der MaxWert 1023 ist, da wir 10bit PWM Signal haben

Hast du OTA schon getestet oder bisher nur eingebunden?

Ich nutze im Moment eigentlich nur OTA (ca. 40mal). Es hat ohne Probleme funktioniert - ich musste bisher nur 3mal manuel Flashen, da ich beim herumexperimentieren durch meinen Code den ESP blockiert hatte, so dass der Webserver nicht mehr erreichbar war. (ADCREAD + Delay(10) blocken den Webserver scheinbar)

Aber es gibt eine Einschränkung - im Moment habe ich das nur auf den ESPs mit 4MB Flash getestet (1MB Spiffs). Eventuell ist es nötig den Code zu optimieren, damit er später auch auf kleinere FlashChips passt

[herrmannj]

Ist die Mischung von 50% WarmWhite und 50% ColdWhite dann ein neutrales Weiss, oder muss man dort einen anderen Algorithmus ansetzen?

Hängt von den verwendeten stripes ab. Als Annäherung aber gut genug

Für RGB habe ich code. Das ist ein wenig tricky weil man nicht mit dem erhöhen von Werten arbeiten kann (Blau zb kann man nicht erhöhen wenn man schon auf #ffffff ist). Man muss also Blau verringern um ein wärmeres Weiß zu erhalten. Kälter geht über eine Verminderung von ROT und GRÜN im richtigen Verhältnis.

Die dritte Variante, also den RGB zu benutzen um einen rein weißen stripe zu "modifizieren" habe ich noch nicht getestet. Sollte aber gehen. Wenn das soweit ist würde ich auch contributen.

Im git sehe ich auch noch nicht so viel. Vielleicht hab ich aber auch falsch geschaut ...

Was mit aufgefallen ist das Du in der docu von RGBW und HSV sprichst. RGBW halte ich für "ungeeignet" weil RGB ja schon Weiß enthält und das extra W dann doppelt wäre.

vg
joerg

[Pf@nne]

Seltsam, bei mir kommt der Fehler nicht - ich schaus mir dann mal an

Welche Arduino- / ESP8266-Versonen und welches Board nutzt du?

Danke dir für die Mühe - ich schau es mir mal an. IP Configuration und ähnliches würde ich dann auch in das WifiManager Portal / Settings Webseite mit einbauen.

Ist der nächste Schritt.

Ich nutze im Moment eigentlich nur OTA (ca. 40mal). Es hat ohne Probleme funktioniert - ich musste bisher nur 3mal manuel Flashen, da ich beim herumexperimentieren durch meinen Code den ESP blockiert hatte, so dass der Webserver nicht mehr erreichbar war. (ADCREAD + Delay(10) blocken den Webserver scheinbar)

Nutz du den OTA-Upload über HTML oder über Arduino?
Update über HTML geht, über Arduino bekomme ich unter "Port" nicht den WIFI-Zugang angezeigt.
Den sehe ich erst ab Arduino 1.6.6, dann kann ich aber nicht mehr kompilieren, weil ein ESP.... Modul fehlen soll.

Eine Frage zu PubSub - welche Latenz hat MQTT?

Ich werde nachher mal eine Verbindungszeitmessung ESP->Broker->ESP implementieren.
Ist natürlich immer von der eigenen Netzwerkauslastung abhängig, daher werde ich die MQTT-Topics mal um die Zeitmessung mit MIN/MAX/NOW ergänzen. Die könnte dann ja jede Sekunde gemessen werden.

Zum MQTT-Testen nutze ich übrigens
http://tinyurl.com/mqtt-spy-download/mqtt-spy-0.5.0-beta-b4-jar-with-dependencies.jar
das macht echt Spaß!

Schönes WE.....

[mrpj]

Morgen,

Welche Arduino- / ESP8266-Versonen und welches Board nutzt du?

[/quote]
Zu Arduin/Esp
https://github.com/patrickjahns/esp_rgbww_firmware#compiling-yourself
Board ist ein esp8266-12e; Hat aber nicht viel Auszusagen, denn die 12/12e/12f sind meist von unterschiedlichen Herstellern und erst mit der CHIPID kann man herausfinden, was für ein FlashChip verbaut ist. Die ESP Library hat dafür Funktionen - ich gehe jetzt mal bei der Entwicklung von 4mb flash size aus.
Falls jemand einen anderen Chip nutzt, dann muss er es testen und kann dementsprechend Anpassungen vornehmen und in Git zur Verfügung stellen.

Nutz du den OTA-Upload über HTML oder über Arduino?
Update über HTML geht, über Arduino bekomme ich unter "Port" nicht den WIFI-Zugang angezeigt.

Ich habe nur WEB OTA eingestellt - aus Anwendungssicht ist es später einfacher nur eine vorkompilierte Firmware herunter zu laden und dann den Controller über den Browser upzudaten. Jede extra Software (Arduino IDE) ist für den Menschen der es einfach nutzen will, nur ein Hindernis. Es ist eventuell eine Überlegung Wert, in der Development Phase den direkten Upload zu aktivieren, aber ich finde es braucht es nicht. (Zum Programmieren und Testen ist eh die Serielle Schnittstelle verbunden)

Ich werde nachher mal eine Verbindungszeitmessung ESP->Broker->ESP implementieren.
Ist natürlich immer von der eigenen Netzwerkauslastung abhängig, daher werde ich die MQTT-Topics mal um die Zeitmessung mit MIN/MAX/NOW ergänzen. Die könnte dann ja jede Sekunde gemessen werden.

Danke dir für die Mühe - es wäre einfach gut zu Wissen, wieviel Latenz ein Befehl Standardmäßig hat. Und wie sehr belastet die MQTT Library den allgemeinen Betrieb.
Und ist es möglich via MQTT auch Controller zu Gruppieren (z.B. Wohnzimmer, Wohnzimmer Esstisch, Wohnzimmer Couch etc.) ?

Hängt von den verwendeten stripes ab. Als Annäherung aber gut genug

Wenn man eh schon soviele Einstellungen hat, kann man ja auch noch ein Regler für Neutralweiß einbauen

Für RGB habe ich code. Das ist ein wenig tricky weil man nicht mit dem erhöhen von Werten arbeiten kann (Blau zb kann man nicht erhöhen wenn man schon auf #ffffff ist). Man muss also Blau verringern um ein wärmeres Weiß zu erhalten. Kälter geht über eine Verminderung von ROT und GRÜN im richtigen Verhältnis.

Die dritte Variante, also den RGB zu benutzen um einen rein weißen stripe zu "modifizieren" habe ich noch nicht getestet. Sollte aber gehen. Wenn das soweit ist würde ich auch contributen.

Immer gerne

Im git sehe ich auch noch nicht so viel. Vielleicht hab ich aber auch falsch geschaut ...

Das stimmt - ich überarbeite den Code gerade noch um ein gutes Grundgerüst zu haben aus den Testcodes die ich bisher hatte.

Was mit aufgefallen ist das Du in der docu von RGBW und HSV sprichst. RGBW halte ich für "ungeeignet" weil RGB ja schon Weiß enthält und das extra W dann doppelt wäre.

Der Gedanke dahinter war es, die Farben direkt anzusteuern, ohne das der Controller dazwischen funkt. Vielleicht ist die Bezeichnung irreführend und es wäre besser das ganze in RGB (der Controller berechnet die Korrektur und Weiß) und rawRGB (der Controller übernimmt "dumm" die Werte) aufzusplitten?

[Pf@nne]

Zu Arduin/Esp
https://github.com/patrickjahns/esp_rgbww_firmware#compiling-yourself
Board ist ein esp8266-12e;

Ich meinte welche Arduino- / und Libraryversionen, ich nutze folgende:

• Arduino V1.6.5
• ESP8266 12e
• ESP8266 staging V2.1.0-rc2
•     Board Generic ESP8266 Module (4M/1M)
• WifiManager library 0.9 fixed encoding problems

Und ist es möglich via MQTT auch Controller zu Gruppieren (z.B. Wohnzimmer, Wohnzimmer Esstisch, Wohnzimmer Couch etc.) ?

Kennst du MQTT grundsätzlich?
Möglich ist da einiges, gruppieren, kannst du die Controller mit gemeinsamen subcribes (Abbos).
z.B. EG/Beleuchtung/Decke/ alle Controller die dieses Topic abboniert haben können jetzt auch auf dieses GruppenTopic reagieren.
Diese Topics müssten dann ja zur Laufzeit änderbar sein, was geht aber nicht unbedingt Not tut.
Ich würde die Gruppensteuerungen doch lieber im FHEM machen, das sollte doch die Zentrale werden.
Oder denkst du über autarke Controller nach?

Wenn Zeit hast.....ich weiß, wer hat die schon.....
wäre ein MQTT-TopicTree sinvoll, den könnte ich dir dann implementieren.
Je ein Tree für public und subscribe.

So in der Form:

Code Auswählen Erweitern


ChipID
   ├─API
   │    ├─HSVColor  [H,S,V,K,T,L]
   │    └─HSVColor  [H,S,V,K,H',S',V',K`,T,L]
   │   
   ├─WIFI
   │    ├─SSID  [SSID]
   │    ├─PASS  [PASS]

u.s.w.

[mrpj]

Ich meinte welche Arduino- / und Libraryversionen, ich nutze folgende:

• Arduino V1.6.5
• ESP8266 12e
• ESP8266 staging V2.1.0-rc2
•     Board Generic ESP8266 Module (4M/1M)
• WifiManager library 0.9 fixed encoding problems

Bis auf den IDE (1.6.7) und WifiManager (0.7) - offizielles update ist scheinbar noch nicht im Tree- ist alles gleich

Kennst du MQTT grundsätzlich?
Möglich ist da einiges, gruppieren, kannst du die Controller mit gemeinsamen subcribes (Abbos).
z.B. EG/Beleuchtung/Decke/ alle Controller die dieses Topic abboniert haben können jetzt auch auf dieses GruppenTopic reagieren.
Diese Topics müssten dann ja zur Laufzeit änderbar sein, was geht aber nicht unbedingt Not tut.
Ich würde die Gruppensteuerungen doch lieber im FHEM machen, das sollte doch die Zentrale werden.
Oder denkst du über autarke Controller nach?

Für mich ist MQTT ein PubSub "Protokoll", die genauen Spezifikationen und Implementierungen habe ich mir nicht angeschaut bisher. Daher auch die Fragen, inwiefern ist es mit dem esp möglich

Oder denkst du über autarke Controller nach?

Auch wenn wir hier im fhem forum sind, wäre es mir wichtig, die Firmware nicht speziell für FHEM zu schreiben, sondern eine möglichst allgemein brauchbare API zur Verfügung zu stellen.

Es gibt 2 Anwendungsszenarien
1) Einbindung von dem Controller in bestehende HomeAutomation (z.B. FHEM)
2) Nutzung des Controllers ohne einem Broker/Server z.b. direkt mit einem Smartphone/Tablet

Für das Protokoll wurden ja bisher 3 Vorschläge genannt
a) Nutzung von TCP/UDP Paketen mit einfachen bytecodes => Simpel, Effizient, Schnell, Flexibel, Geringe Latenz [Vorgeschlagen von Joerg]
b) Nutzung von MQTT => flexibel, (effizienz? geschwindigkeit? overhead? Latenz?) [Vorschlag von Pf@nne und ?]
c) Nutzung von webapi => flexibel, ziemlicher overhead, hohe Latenz(Arduino Webserver langsam) [Vorschlag von mr.pj]
(Interressantes zum Thema Latenzzeiten von Arduino Webserver, ESP SDK & MQTT gibt es hier zu lesen: https://github.com/internetofhomethings/ESP8266-MQTT-HTTP-Server)

Mein Fokus liegt gerade auf der Implementierung der LED Bibiliothek. Die finale Implementierung der Schnittstelle ESP <-> Controller (FHEM/Tablet) kommt für mich danach bzw. gebe ich das gerne weiter. Für mich ist es aber dennoch erstrebenswert Szenario 1 und 2 abdecken zu können und damit kein "locked in Syndrom" zu haben.

Wenn Zeit hast.....ich weiß, wer hat die schon.....
wäre ein MQTT-TopicTree sinvoll, den könnte ich dir dann implementieren.
Je ein Tree für public und subscribe.

So in der Form:

Code Auswählen Erweitern


ChipID
   ├─API
   │    ├─HSVColor  [H,S,V,K,T,L]
   │    └─HSVColor  [H,S,V,K,H',S',V',K`,T,L]
   │   
   ├─WIFI
   │    ├─SSID  [SSID]
   │    ├─PASS  [PASS]

u.s.w.

Ich würde den Vorschlag aufgreifen und genau andersherum dich bitten den Tree aufzubauen. Ich denke du bist in der MQTT Materie tiefer drinnen und besser vertraut was sinnvoll in einem Tree ist, und was nicht. Die Informationen zu Funktionalität vom Controller sind ja in den letzten Seiten (und auf Github) zu finden.

Nachtrag:
Warum ich auch auf die Latenz des Protokolls schauen möchte:
Wenn ich z.B. bei einem Fader auf dem Tablet runterfade, möchte ich ein möglichst direktes Feedback im Licht haben. Eine größere Verzögerung empfinde ich als unangenehm und schlecht zu bedienen.

Für das nachschauen eines Sensorwertes (z.B. Temperatur, Wasserstand etc.) ist eine höhere Latenz für mich nicht wild, aber bei etwas wie Licht (oder Lautstärke) ist es mir wichtig das so direkt wie möglich zu erleben.