FHEM Forum

Mit wenigen Teilen lässt sich ein WLAN Controller selbst bauen.

Benötigt teile:

Ein RGB Controller
http://www.ebay.de/itm/121577974533   ca. 1,60€
Leider gibt es da verschiedene Controller. Meiner war wohl auf 3x4A ausgelegt. Die mit 2A habe eine andere Ansteuerung (siehe Bilder von fh168 weiter unten)
Wer also nicht einen solchen hat, sollte das mit dem Umbau besser lassen oder wissen was er tut ;)

Die Fernbedienung und der IR Receiver werden nicht benötigt, da kann man sich dann etwas anderes mit basteln ;)

Ein Step Down Module
www.ebay.de/itm/111451599266  ca. 1€
Zur Versorgung des ESP 8266 mit 3.3v , wer mag kann sich natürlich auch etwas mit einem anderen Voltage Regulator bauen. Vielleicht hat jemand eine Idee gegen was man den 5v Regulator einfach austauschen könnte für 3.3v mit ca. 300ma .

Ein ESP 03
www.ebay.de/itm/111557111183


Einen Levelshifter und USB -> UART zum programmieren setze ich mal als vorhanden voraus.

Bild PWM-WLAN-A.jpg zeigt den original Controller:


1 = Flash Speicher
2 = Unbeschrifteter IC der die IR Signale verarbeitet un

Diese beiden ICs habe ich mit einem Gaslötkolben mit aufgesetzter Heißluftdüse vorsichtig abgelötet. Wer will kann auch einfach die 3 Leitungen zu den Mosfets einfach durchtrennen.


3 = Der IR Empfänger. Den habe ich uach ausgelötet.
4 = Ein Voltage Regulator auf 5v, geht wohl bis 70ma. Den habe ich mal drin gelassen, wird aber nicht benötigt.
5 = Dort habe von 3 Lötpunkten die Leiterbahnen durchtrennt. Nur den vierten der auf GND geht habe ich gelassen. Da kommt später ein Pinheader dran um es mit dem USB UART und dem Levelshifter zu programmieren.


Bild PWM-WLAN-A.jpg zeigt den fertigen Prototyp, der sicher kein Designpreis bekommt :)

1 und 2 sind mit den pins TXD und RXD verbunden:
https://www.robotics.org.za/index.php?route=product/product&product_id=1024

3 = 3.3v um dem Levelshifter  mit LV zu verorgen
4  = GND

Ich wiederhole noch mal:  bei den Lötpunkten 1-3 müssen unbedingt die Leiterbahnen getrennt werden, auch zwischen 2-3

5 = Der ausgang vom Step Down Module (auch mit  + Markiert)
6 = Das Poti um die Spannung des Step-Down moduls auf 3.3v einzustellen. Achtung! Das muss natürlich gemacht werden bevor der Ausgang angeschlossen wird.

7 = die Eingangspannung vom Netzteil

Die 3 Blauen Drähte die nach oben weggehen sind GPIO 12,13 und 14.  Und werden auf der anderen Seite angelötet (PWM-WLAN-A.jpg):

Und zum Schluss noch mal eine Übersicht mit Levelshifter (1)

Generellles zum ESP:

GPIO15 auf GND
CH_PD auf VCC

Zuerst muss auf dem ESP die nodemcu geflasht werden. Dazu muss pin GPIO0 beim einschalten auf GND sein.

Zum programmieren/uploaden der Skripte benutze ich ESPlorer , der unterstützt mehrere Dateien in TABs. Ich finde das Tool wesentlich besser als LUA-Uploader.


Die Reichweite der Keramikantenne ist allerdings bescheiden. -72db durch eine Stahlbetondecke ca. 5m luftlinie. Da sind andere wohl etwas besser. Aber da wo ich Ihn betreiben will, ist das für mich kein Problem.


EDIT:

Ich habe die Scripte angehängt.

Zu beachten ist folgendes:
In der init.lua müsst ihr die run() manuell aufrufen bei jedem start. Oder Ihr macht den Kommentar bei -- run() raus. Ich habe ihn aber drin gelassen, denn wenn man einen Fehler macht, passiert es sehr schnell, das der ESP resetet wird und dann bei einem Automatischen Start in einer Endlosschleife bootet. Das ist mir ein paar mal passiert. Meistens schafft man es dann nicht die Ausführung von init.lua zu verhindern. Dann hilft nur noch neu flashen. Sehr ärgerlich.
Aber wenn alles funktioniert könnt Ihr natürlich in der Init run() automatisch ausführen.

Beim Upoaden solltet Ihr ein automatisches "dofile" abschalten. Sonst wird evtl. das erste hochgeladene File ausgeführt. Da die anderen Files aber noch fehlen gibt es einen Fehler der zu einem Reboot des ESP führen kann und dann die anderen Files nicht mehr hochgeladen werden.

Falls ihr die GPIOS in anderer Reihenfolge gelötet habt, dann könnt ihr das in der RGBController.lua ändern:

local Red   = 6
local Green = 5
local Blue  = 7

Der Controller ist steuerbar mit WifiLight:

define Licht_EG_Stufen WifiLight RGB LW12:192.168.0.245

Und vergesst nicht nach dem flashen mit nodemcu erstmal die Wlan Verbindung einmalig einzurichten:

wifi.setmode(wifi.STATION)
wifi.sta.config ( "WIFI_SSID" , "PASSWORD" )


Viel Spass damit.

Super Samsi!

Ich bin dabei und bastel es nach!
Vielleicht schreibe ich auch bald mal drüber.


LG
/robin

Hey Samsi,

cool, bin gespannt auf deine weiteren Ergebnisse.

Mfg, machnetz

@Samsi
Produktiver Beitrag zum Thema ESP8266. Das gefällt mir! Ich bin schon auf den NodeMcu Code gespannt.

Zitat von: Samsi am 28 Februar 2015, 13:16:07
Die Reichweite der Keramikantenne ist allerdings bescheiden. -72db durch eine Stahlbetondecke ca. 5m luftlinie.

Die Kupferfläche dahinter schirmt die Keramikantenne ab.

Habe oben die Skripte angehängt!

Kennt nicht jemand einen Spannungsregler mit 3.3v und 300ma dem man den Verbauten WS78L05 (http://www.datasheet-pdf.com/datasheetdownload.php?id=718113 (http://www.datasheet-pdf.com/datasheetdownload.php?id=718113)) einfach ersetzen könnte? Das würde alles noch etwas einfacher machen ;)

L4931 von ST, hab aber das Pinout nicht mehr im Kopf.

Hallo,

ich sitze schon den ganzen Tag am esp8266 - 12 (!).
nodeMCU Software habe ich geflashed bekommen
mit den LuaLoader komme ich dann auch auf drauf (9600 Baud)

Frage:
muss ich den GP00 noch gegen Masse legen (flash)?

Es gibt ja einige Dateien, init.lua, controller.lua usw. Lade ich nacheinander hoch? Oder lege ich ein verzeichnis fest, die der lualoader automatisch zieht?

ich habe am esp8266-12 keine gpios 5,6,7 kann ich auch andere nehmen? Ich hatte 4,5 und 16 genommen und das in der Controller.lua geändert. Danach hatte er Probleme mit der baudrate gehabt.. ich vermute ich habe den baustein gekillt. Ich kam mit 9600 baud noch drauf, flashen ging auch noch, aber wenn ich aus dem Flashmodus GPI00 wieder von der Masse genommen habe, wurde der Baustein heiß. Ich habe jetzt einen neuen genommen

Werden beim Upload der lua Dateien die Daten dauerhaft gespeichert?

Hardware: Mein Baustein von Mömax sieht komplett anders aus, die beiden Maikäfer sind zwar auch da, die habe ich rausgelötet. die RGB Kabel habe ich einem 3-beinigem Chip (sieht aus wie ein Transistor) angelötet. Jeweils das Bein, welches zum Maikäfer ging.

robin

Hi,

GPIO0 muss nur beim Flashen auf GND

Die GPIOs sind 12,13 und 14 und die gibt es auch beim ESP 12:
http://l0l.org.uk/2014/12/esp8266-modules-hardware-guide-gotta-catch-em-all/

Die werden nur von nodemcu über andere Indizes angesprochen:
https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en#new_gpio_map

Zitat
Es gibt ja einige Dateien, init.lua, controller.lua usw. Lade ich nacheinander hoch? Oder lege ich ein verzeichnis fest, die der lualoader automatisch zieht?

Einfach nacheinander hochladen. Reihenfolge ist egal, weil die eh erst mit run() gestartet werden. Die bleiben auch dauerhaft gespeichert.
Es gibt befehle 'List' beim Luauploader, 'cat' bei ESPLorer der zeigt alle Dateien auf dem ESP an.

ZitatHardware: Mein Baustein von Mömax sieht komplett anders aus, die beiden Maikäfer sind zwar auch da, die habe ich rausgelötet. die RGB Kabel habe ich einem 3-beinigem Chip (sieht aus wie ein Transistor) angelötet. Jeweils das Bein, welches zum Maikäfer ging.

Ein Bild wäre nicht schlecht, auch was du wo angelötet hast.


PS:wenn du den noch mal mit nodemcu flashen konntest verstehe ich nicht warum er beim entfernen von GPIO0 heiss werden sollte.

bild ist hochgeladen, r g b kabel (links) gehen in die gpios rein, rechts rgb zum stripe

heisst das, wenn ich auf dem baustein gpio 4, 5 und 16 stehen habe, brauche ich das genauso in der controller.lua da eintragen?


fhem2015.03.01 14:43:11 2: InfoPanel PanelFlur: command 'trash' no longer supported.
2015.03.01 14:43:47 3: Licht_EG_Stufen low level cmd queue send ERROR cc2333, qlen 1 (reconnect giving up)
2015.03.01 14:43:47 3: Licht_EG_Stufen RGB LW12 set on (0, 0, 100) 0
2015.03.01 14:43:47 1: PERL WARNING: Use of uninitialized value $hueFrom in concatenation (.) or string at ./FHEM/32_WifiLight.pm line 2269.
2015.03.01 14:43:47 1: PERL WARNING: Use of uninitialized value $satFrom in concatenation (.) or string at ./FHEM/32_WifiLight.pm line 2269.
2015.03.01 14:43:47 1: PERL WARNING: Use of uninitialized value $valFrom in concatenation (.) or string at ./FHEM/32_WifiLight.pm line 2269.
2015.03.01 14:43:47 1: PERL WARNING: Use of uninitialized value $hueFrom in concatenation (.) or string at ./FHEM/32_WifiLight.pm line 2272.
2015.03.01 14:43:47 1: PERL WARNING: Use of uninitialized value $satFrom in concatenation (.) or string at ./FHEM/32_WifiLight.pm line 2272.
2015.03.01 14:43:47 1: PERL WARNING: Use of uninitialized value $valFrom in concatenation (.) or string at ./FHEM/32_WifiLight.pm line 2272.
2015.03.01 14:43:47 3: Licht_EG_Stufen set HSV 0, 0, 100 with ramp: 0, flags:
2015.03.01 14:43:48 3: Licht_EG_Stufen low level cmd queue send ERROR 56ffbf40aa, qlen 2 (reconnect giving up)
2015.03.01 14:43:52 3: Licht_EG_Stufen RGB LW12 set off 0
2015.03.01 14:43:52 3: Licht_EG_Stufen RGB LW12 dim 0 0
2015.03.01 14:43:52 3: Licht_EG_Stufen set HSV 0, 0, 0 with ramp: 0, flags:
2015.03.01 14:43:52 3: Licht_EG_Stufen low level cmd queue send ERROR 56000000aa, qlen 1 (reconnect giving up)
2015.03.01 14:43:55 3: Licht_EG_Stufen low level cmd queue send ERROR cc2333, qlen 1 (reconnect giving up)
2015.03.01 14:43:55 3: Licht_EG_Stufen RGB LW12 set on (0, 0, 100) 0
2015.03.01 14:43:55 3: Licht_EG_Stufen set HSV 0, 0, 100 with ramp: 0, flags:
2015.03.01 14:43:55 3: Licht_EG_Stufen low level cmd queue send ERROR 56ffbf40aa, qlen 2 (reconnect giving up)

nach run() im lualoader steht : myNode.lua:1: attempt to call field 'compile' (a nil value)

Ok, werde ich mir heute Abend mal genauer ansehen, aber auf den ersten blick würde ich sagen, das müsste so auch gehen.

Zitatheisst das, wenn ich auf dem baustein gpio 4, 5 und 16 stehen habe, brauche ich das genauso in der controller.lua da eintragen?

Nein. Schau noch mal in die Tabelle:
Ich habe GPIO12,13 und 15 verbunden und laut Tabelle:

https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en#new_gpio_map

Muss dann in der Controller.lua stehen
6,
7,
5

ZitatmyNode.lua:1: attempt to call field 'compile' (a nil value)

Also bei ESPlorer heist das Commando auch File List und das Ergebnis:

init.lua size: 54
telnet.lua size: 596
RGBController.lua size: 677
myNode.lua size: 1087
telnet.lc size: 900
RGBController.lc size: 796

wobei die .lc Dateien durch das node.compile erstellt wird, also frühestens nach dem ersten run().
Aber Durch File List solltest Du erst mal prüfen ob die .lua Dateien auch hochgeladen sind.
Die Filegröße wird bei Dir anders sein, weil meine Dateien schon Code für den Bewegungsmelder enthalten.

ZitatPERL WARNING: Use of uninitialized value $hueFrom in concatenation (.) or string at ./FHEM/32_WifiLight.pm line 2269.

Dazu kann ich nichts sagen, vielleicht lädst du mal das neuste Wifilight.pm aus dem SVN

Meldet sich der ESP auch mit der gleichen Version:

NodeMCU 0.9.5 build 20150213

Die wifilight Warnung ist ok. Beim ersten Start gibt es kein from ...


Vg
Jörg

@ fh168
Sorry, der controller scheint nicht zu gehen. Ich hatte noch einen weiteren und aufgemacht sah der so aus wie Deiner. Leider steht auf den kleinen Transistoren nicht viel drauf außer A6.
Ich habe versucht die mit 3.3v anzusteuern, aber dabei sind die wohl kaputt gegangen. Jedenfalls leuchten die bei mir nur noch dauerhaft.

Ich würde von dem Controller erst mal abraten, und auch von den den ich oben bei EBAY verlinkt habe. Der ist nämlich auch nur für 3x2 A aber der den ich ni meinen Bilder verwendet habe hat 3x4A.
Mal sehen ob ich den noch irgendwo auf Ebay finde.

Schluchz, kaputt...
ich habe es mittlerweile hinbekommen, auf dem Chip zu speichern aber immer nur eine datei und dann mit dofile zu starten.
wenn ich die Telnet.lua hochlade, kann reagiert fhem auch drauf und die übergebenen parameter werden in dem lualoader angezeigt.
es ändert sich aber nicht die farbe der stripes.
um später was draus zu lernen...  man uploaded den ganzen schwung von lua-dateien und sagt dann dofile? Oder lädt man die sich einzeln hoch und sagt dann jedesmal dofile?
edit: jetzt läufts... dofile (init.lua) und dann im textfeld run()
nur die LEDS ändern sich nicht :-(

fürs protokoll.. wenn von fhem eine anfrage kommt sieht es dann im lualoader so aus:
> = node.heap()
17360
>
dofile(init.lua)  Sonntag, 1. März 2015  19:42:05

dofile("init.lua")
> run()
Try to open socket ...
> Wifi connected. My IP:
192.168.178.48 255.255.255.0 192.168.178.1
Socket running at : 5577
connect
Received Command:
86 0 0 0 170
disconnect
connect
Received Command:
86 0 0 0 170
connect
Received Command:
204 35 51
disconnect
connect
Received Command:
86 255 191 64 170
disconnect
disconnect

also das dofile musst Du eigentlich gar nicht machen. Ich habe das abgeschaltet, das er das automatisch ausführt.

ich bin noch am forschen!
bei mir scheints zu klappen!
ich habe mir die tabelle nochmal reingezogen. jetzt hatte ich gerade noch eine fliegende verdrahtung aber die leds haben reagiert!

Ich drück Dir die Daumen ;), aber sei vorsichtig. Ich weis nicht was Q1-Q3 für Bauteile sind. Jedenfalls mein 2. Controller sieht so ähnlich aus wie Deiner und den hab ich wohl zerlegt.

ne klappt, an und aus. nur die farben stimmen nicht
rot 2 -> gpio 4
grün 1 -> gpio5
blau 6 -> gpio 12

jetzt habe ich einfach mal im texteditor die werte geändert und einfach rübergebeamt. ich hoffe der hat die alte rgbcontroller.lua überschrieben

die 3 kabel habe ich jetzt am esp8266 festgelötet.

rot ergibt ein violett, gelb ein weiß und grün ein mint.

nach dem fhem-ein und ausschalten wird grundsätzlich ffffff übergeben (weiß). Er speichert nicht den letzten farbwert.

hm.. ist das ein software oder hardwareproblem?

Zitatne klappt, an und aus. nur die farben stimmen nicht

Super, freut mich.  (Ich frag mich nur, wie ich gerade meinen 2. Controller zerschossen habe, den wollte ich eigentlich auch noch WifI umbauen. Naja, ich werde mir einfach ein Paar Mosfets mit einer Zusatzplatine löten. Bei dem Controller ist ja genug platz, weil die andere Seite ja komplett unbestückt ist.

Zitatnach dem fhem-ein und ausschalten wird grundsätzlich ffffff übergeben (weiß). Er speichert nicht den letzten farbwert.

Also Du meinst bei einem Shutdown-Restart von FHEM?
Weil wenn du den Controller stromlos machst und der ESP neu bootet, dann setze ich den DutyCycle auf 0 also aus: pwm.setup(Red,200,0)
Wenn der Stripe also an ist, wenn du den Controller neu Startest, dann ist vielleicht die Logic bei dem Controller umgedreht. Sprich wenn der GPIO HIGH ist = LED aus.



EDIT: Also ich habe mal meinen Controller auf FF0000 eigestellt und dann FHEM neu gestartet. da hat er auch FF0000 gesendet. Wenn Du vorher FFFFFF hattest, und dann neu startest, dann wird das wohl auch so von FHEM gesendet.

so, ich habe alles in der kleinen Box reinbekommen

was machen wir jetzt mit den Farben? Ist das Kunst oder bleibt das so?

wie bekommt man das hin , das man nicht wieder run() auf der Lua konsole starten muss?  die -- von run() im init.lua wegnehmen und neu flashen?

Zitatwas machen wir jetzt mit den Farben? Ist das Kunst oder bleibt das so?

Also erst mal solltest Du folgendes testen:

Bei FFFFFF sollte es weiss sein und  bei 000000  aus.

Wenn das so ist, musst du nur in der RGBController die Zuordnungen ändern.
Am besten setzt Du die Farbe dann auf FF0000 wenn es dann grün leuchtet, dann musst Du Grün und Rot vertauschen. WEnn es blau leuchtet, vertauschst Du Rot und Blau und wenn es Rot leuchtet vertauschst Du Grün und Blau.

local Red   = 6
local Green = 5
local Blue  = 7

Also so:
local Red   = 5
local Green = 6

Zitat
das man nicht wieder run() auf der Lua konsole starten muss?

ja, -- entfernen in der init, dann wird dort run() ausgeführt.
Dann die init.lua Datei neu auf den ESP speichern und restart. Neu Flashen musst du nicht.

autostart klappt jetzt -- entfernt.

mit der beleuchtung ist es schwieriger.. habe ich genauso gemacht.
wenn ich Rot haben möchte... also FF0000  gibt es immer noch einen kleinen Blauanteil und das rot ist nicht "knallig" rot
Auch bei grün.. da leuchtet die Grüne LED aber nicht richtig kräftig.. da ist noch ein Blau- und Rotanteil mit dabei. Das sieht man, wenn man es dimmt.
scheint also an der Software zu liegen.

Was passiert bei FFFFFF? Da müssten alle an sein und in der Konsole müsste stehen

86   255   191   64   170



und bei 000000 (als aus) müsste da stehen:

86   0   0   0   170



und bei rot (FF0000) sollte in der Konsole
86   255   0   0   170
Stehen

@  fh168

Wifilight hat eine Farbkalibrierung, schau Dir mal die Wifilight attribute an:

colorCast = Farbkalibrierung (setz auf 0,0,0,0,0,0 für neutral )
whitepoint = Weißabgleich ( 1,1,1 für neutral )

Zuerst gamma so einstellen das der Helligkeitsanstieg linear aussieht

vg
jörg

@hermannj:
aber bei FF0000 müssten die anderen beiden Farben aus sein, denn bei mir ist das so bei der Standardeinstellung des LW12. Denn er sendet ja:

86   255   0   0   170

Deshalb fh168, schicke doch bitte mal was Du von FHEM gesendet bekommst bei FF0000.

@samsi

nur zur Info:
die Farbkalibrierung ist zum Ausgleich verschiedener stripes und kann bei entsprechenden Einstellungen dafür sorgen das Du wifilight sagst

set RGB FF0000

und je nach angewandter Farbkalibrierung könnte in Richtung Controller zB FF1900 rausgehen

Die Attribute oben sind die neutral Werte - sonst je nach stripe (controller, pwm, mosfet etc) ..

vg
jörg

@hermannj
Ja, das hab ich schon verstanden. Aber als ich mein LW12 Device angelegt habe, habe ich ja keine Änderung gemacht und bekomme bei FF0000  auch FF0000 gesendet.  Folglich müssten auch bei ihm die beiden anderen Farben aus sein, es sei denn er hätte das LW12 anders angelegt. Deswegen würde ich gerne von ihm wissen, was tatsächlich ankommt. Wenn nämlich bei Ihm FF0000 ankommt und die LEDs nicht aus sind, liegt es an der Hardware.

genau die Werte kommen bei mir auch rüber

Zitat von: Samsi am 01 März 2015, 22:14:24
Was passiert bei FFFFFF? Da müssten alle an sein und in der Konsole müsste stehen

86   255   191   64   170



und bei 000000 (als aus) müsste da stehen:

86   0   0   0   170



und bei rot (FF0000) sollte in der Konsole
86   255   0   0   170
Stehen

ok, und wenn

86   0   0   0   170

kommt, ist dann alles aus? Oder leuchten die dann noch ein bisschen?

colorcast war gut... 6 mal die 0 und grün ist wirklich grün
blau hat einen rotanteil
gelb ffff00 ist aber weiß

alles aus

Zitat von: Samsi am 01 März 2015, 22:31:11
ok, und wenn

86   0   0   0   170

kommt, ist dann alles aus? Oder leuchten die dann noch ein bisschen?

DAnn dürfte bei Dir bei

FF0000

wenn

86   255   0   0   170

angezeigt wird

auch nur ROT (255) leuchten und die anderen beiden müssten aus sein. Wenn das nicht so ist, stimmt etwas nicht.

blau ist noch an, sieht also nach pink aus
grün ist jetzt nach colorcast optimal  00ff00  rot und blau ist komplett aus

gelb ffff00 hat einen blauanteil mit drin und einen leichten rotanteil

Zitat von: Samsi am 01 März 2015, 22:36:07
DAnn dürfte bei Dir bei

FF0000

wenn

86   255   0   0   170

angezeigt wird

auch nur ROT (255) leuchten und die anderen beiden müssten aus sein. Wenn das nicht so ist, stimmt etwas nicht.

Klar, weil bei FF0000 (rot) bei Dir immer blau mitleuchtet. Sende mal blau (0000FF) und schuae ob auch immer rot mit leuchtet.
Im output müsste dann stehen:
86   0   0   255   170

ich stelle gerade fest, das bei nur rot und nur blau sich nichts ändert, ich vermute doch ein hardwareproblem

ich denke auch. Vermutlich sind die Leitungen für rot und blau leicht kurz geschlossen.

Oder die GPIOs die Du verwendest haben irgendeine Besonderheit. Welche benutzt Du jetzt?

Zitat von: Samsi am 01 März 2015, 22:48:28
ich denke auch. Vermutlich sind die Leitungen für rot und blau leicht kurz geschlossen.

Oder die GPIOs die Du verwendest haben irgendeine Besonderheit. Welche benutzt Du jetzt?

gpio 4,5,12

und was steht in der RGBController ?

2 1 6

problem gelöst!
heisskleber wieder entfernt und nochmal alles nachgegangen.. jetzt klappts!
super Danke!
jetzt wieder alles zusammenkleben...

Heiskleber? Ich würd es mal mit löten versuchen  ;D

ja ne is klar... die Kabel sind schon verlötet, aber ich fixiere das Ganze nochmal. und da ist Heisskleber ideal.
Klappt!

Gratuliere.

Ich habe übrigens gerade das hier gelesen:

http://forum.fhem.de/index.php/topic,13890.msg93007.html#msg93007

Vielleicht schaust Du mal bei Deinen Transistoren, nicht das die zu Heiss werden, weil die jetzt auch nur mit 3.3v angesteuert werden.

Bei mir werden die gar nicht mal warm, aber ich hab es aber nur mit 1,5A getestet (ca. 5m Stripe mit 30 5050 LEDs/Meter)    und ausgelegt war es auf 12 A.

Deins ist aber nur auf 6A ausgelegt. Würde ich also mal beobachten.

EDIT:
Ok hab gerade die Bilder gesehen, Du wirst es sehen wenn der Heisskleber schmilzt ;););)

ich habe nur 1,5 m mit einem uralt Computer-Netzteil dran. Dürfte also klappen.
Die 5m Rolle kam noch von dem Mömax-Deal von vor ein paar Wochen. Das ganze Set hab ich für 8,75 Euro inkl. Netzteil bekommen.
Von Esp8266-12 und den Spannungsreglern habe ich hier noch eine ganze Menge rumliegen. Die ganze Aktion war praktisch Resteverwertung.
Ebenfalls wollte ich mal wissen, wie man dieses LUA flashed und was man damit machen kann.

Mein nächstes Projekt ist auf einem kleinen OLED Display per WLAN über Fhem Infos drauf zu zeigen, oder einen Text frei definierbar auf dem Display zu machen, wie hier auf dem Video angedeutet. Da habe ich es hardcodiert und ohne WLAN geflashed: http://blog.moneybag.de/fhem-cul-433-mhz-oder-868-mhz-im-selbstbau/

Robin

Aber halten wir mal fest:
Die Dinger von eBay dürften doch dann funktionieren, ich meine wenn man gut löten kann :-)

Robin

Hallo,

ja im Prinzip schon, aber da es ja so viele Unterschiedliche Controller gibt, ist das schon ein bisschen Roulette. Deswegen habe ich die Kaufempfehlung oben mal entfernt.

Aber Trotzdem wer mag kann es ja probieren. 1,60€ sind ja nicht die Welt.

Was ist mit Deinem anderen ESP? Ist der Definitiv defekt?

Ich habe mal den "Leidensweg" des Zusammenbaus in einem Blog-Beitrag von mir beschrieben.

http://blog.moneybag.de/fhem-smd-rgb-led-stripes-mit-esp-8266-12-ueber-wlan-steuern/

Viel Spaß beim Lesen.

Bin gerade dabei das ganze nachzubauen! Huu, basteln mit Strom! Gefährliche Sache!

Leider muss man wohl die Originalverbindungen vom Transistor/Mosfet zur IR-Fernbedienungscontroller kappen, sonst gibts elektrische Rückschläge. Beides kann man also nicht verwenden.
Da noch ein paar GPIOs frei sind will ich da noch einen DS18S20 oder DHT11 unterbringen um die Raumtemperatur gleich mitzumessen. Da könnte der Speichelplatz langsam knapp werden. Auf einen Versuch kommts an.
Ist natürlich alles nicht HM-konform und gegen den Strich, aber egal. Ein echt süßes Experiment.

Zitat von: Rev. Prom. Magersuppe am 10 März 2015, 19:58:38
Leider muss man wohl die Originalverbindungen vom Transistor/Mosfet zur IR-Fernbedienungscontroller kappen, sonst gibts elektrische Rückschläge. Beides kann man also nicht verwenden.

Ich will deshalb versuchen auf einem attiny85 SoftwareSerial und IRMP zum laufen zu bringen und so die IR Signale zum ESP und per WLAN zu FHEM zu schicken.

Zitat von: Rev. Prom. Magersuppe am 10 März 2015, 19:58:38
Da noch ein paar GPIOs frei sind will ich da noch einen DS18S20 oder DHT11 unterbringen um die Raumtemperatur gleich mitzumessen. Da könnte der Speichelplatz langsam knapp werden.

Das sollte doch eigentlich kein Problem sein.

Hi,

ZitatIch will deshalb versuchen auf einem attiny85 SoftwareSerial und IRMP zum laufen zu bringen und so die IR Signale zum ESP und per WLAN zu FHEM zu schicken.

Ich habe leider iA keine ausreichende Zeit um mich am HW basteln zu beteiligen (würde aber gern finde Projekt super. Kommt noch :)) Der Gedanke mit dem "zurück an fhem" kam mir auch. Dein Projekt würde sich mMn echt gut eignen um zB bestehende RGB Kerzen (meine GöGa hat so 'n Partylight Zeugsen - fragt nicht ...) in fhem einzubinden. Nur als Beispiel.

Da müsste ich aber auch bestehende Schalter integrieren. FB mit Farbauswahl wären da top.

Wifilight selber hat eine Architektur die das so nicht hergibt - ich könnte mir aber gut vorstellen da was zu drehen. Ideal wäre wenn der controller dazu die Rückmeldungen auf einen dedizierten port gibt den fhem dazu öffnen. Das Protokoll müssten wir "erfinden", ideal wäre wenn das erweiterbar wäre.

Interessant ? Vorschläge || Ideen ?

vg
jörg

Also was ich derzeit schon in Software gemacht habe ist, das ich zusätzlich zur Steuerung über WifiLight eine Connection von FHEM aus mit ECMD öffne. Das läuft bei mir auch schon sehr gut und seit 7 Tagen stabil. Ich habe nämlich an den ESP noch einen PIR Sensor HC-SR 501 angeschlossen. Der sendet dann über ECMD ein Reading an FHEM und FHEM schaltet dann perr WifiLight den selbstgebauten RGB Controller ein oder aus ;)

Dasselbe will ich auch mit dem IR Signal machen.
Allerdings will ich das umbauen von ECMD auf MQTT weil ich glaube das das noch besser geeignet ist. Ein Änderung an WifiLight wäre dann gar nicht nötig weil ich einfach dann ein set wifilight RGB 00FF00 mache wenn ich auf die grüne Taste drücke.
Außerdem kann man dann der IR sensor Sensor dann noch mit anderen Fernbedienungen ganz ander sachen mit FHEM steuern.


Momentan bastel ich aber gerade an einer Erweiterung für meinen Gaszähler der, nachdem ich die WLAN Verbindung auf 40% erhöht habe, nun auch seit Wochen den Zählerstand synchron anzeigt.
Die Erweiterung nimmt über Pin 2 per Interrupt das LED-Signal eines Stromzählers und errechnet daraus den Momentanen Stromverbrauch und Zählerstand. Hab heute den ersten Test gemacht und einen Heizlüfter der laut Zwischensteckermessgerät 1545W verbraucht, hat beim Stromzähler den gemessenen Wert um 1580W erhöht. Wobei ich nicht weiss ob die Differenz nicht eher vom Zwischensteckermessgerät kommt ;)

stimmt. simpel und effizient.

vg
jörg

... nur mal so als Frage an die Praktiker: theoretisch könnte man doch jeweils einen STP16NF06 an den PWM out setzen? Soweit ich sehe auch ohne schnick-schnack.

vg
jörg

Ich habe es mal testweise mit einem AOD472 welche ich massenhaft auf einem alten Motherboard hatte über einen 10K Widerstand probiert, das funktioniert auch (ob auf Dauer weiss ich allerdings nicht, das Datenblatt sieht aber ganz gut aus so weit ich es verstehe).

Alternativ kannst Du aber auch die IRLR024N  über 27 ohm anschließen wie hier (ich denke mal    ext23 weiß was er tut  ;)):

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

Nabend,

ich verstehe den ganzen Thread nicht so ganz, wozu zerlegt man denn diese IR RGB Steuerung wenn man nur die MOSFETS braucht ;-) Aber gut, geht ja um den Spass hier ;-)

Dieses WLAN Board was ihr da benutzt, was gibt das aus, 3,3V oder 5V auf den PWM Ausgängen? Danach richtet sich der MOSFET und der Vorwiderstand. Wenn 5V raus kommen gehen so gut wie alle MOSFETs oder ich sag mal lieber ein Großteil. Der Vorwiderstand ist wichtig, auch wegen EMV. Bei einem MOSFET entstehen nur Ströme durch das "Umladen" und die können sehr hoch sein was wiederum das WLAN Board oder den µC den ihr benutzt zerstören kann. Also da ein bissel aufpassen. Ansonsten ins Datenblatt schauen und immer sicherstellen das bei 3,3V bzw. 5V der MOSFET komplett durchgeschaltet ist. Ansonsten stirbt der je nach Last dann den Hitzetot.

Wenn es um 3,3V geht und höhere Leistungen getrieben werden sollen brummt der "IRF3708" ganz gut. Kost aber auch recht viel.

Gruß
Daniel

Nabend,

...3,3V. Ich hab hier "abgespickt": https://learn.adafruit.com/rgb-led-strips/usage. Ich hätte verschiedene "Projekte" wo ich das system von Samsi gut vorstellen kann, da gehts aber jeweils nur um wenige Watt (max 20 eher 10 oder vlt sogar weit drunter). In dem adafruit link arbeiten die ohne Vorwiederstand-  wovon Du Daniel aber ab rätst. Ein Vorwiederstand macht den Kohl ja auch nicht fett, von daher passt das ...

vg
jörg

Hi,

Zitatich verstehe den ganzen Thread nicht so ganz, wozu zerlegt man denn diese IR RGB Steuerung wenn man nur die MOSFETS braucht ;-) Aber gut, geht ja um den Spass hier ;-)

Also, das RGB Modul kostet nur 1,50€  inkl. Versand und hat im Prinzip die Mosfets, eine Strombuchse und das Kabel zum anschließen des RGB Bands und eine kleines Gehäuse schon dabei udn schön aufgelötet ;)  Und mit dem IR Sensor und der IR Fernbedienung kann man dann noch was anderes basteln.

ZitatAnsonsten ins Datenblatt schauen und immer sicherstellen das bei 3,3V bzw. 5V der MOSFET komplett durchgeschaltet ist. Ansonsten stirbt der je nach Last dann den Hitzetot.

Die WLAN haben  3.3v level. Das hatte ich bei Dir im Panstamp thread auch schon gelesen, aber mir ist nicht klar, woran ich das im Datenblatt erkennen kann?  So gut kenne ich mich da auch nicht aus. Also habe ich einfach mal ca. 5m  RGB (36W) angeschlossen und die wurden über längeren Zeitraum nicht mal lauwarm bei verschiedenen Dimmstufen.

Bei dem RGB Controller waren vor den Mossfets 10K Widerstände, deshalb hab ich die auch mal so bei dem AOD472 verwendet (ohne genau zu wissen was ich da tue ;). Die habe ich aber noch nicht mit 36W Stripes getestet sondern nur mal die aus dem RGB Controller.

Grüße

Ja den irlb8721 kann man auch noch empfehlen. Der hat ein sehr kleines Vgs bei maximal 2,35V, also der schaltet bei 3,3V auf jeden Fall sauber durch.

Mit dem Widerstand, wie gesagt, zum einen (was viele nicht wissen) ist das ein EMV Problem, was vermutlich aber vielen Hupe ist.
zum Anderen sollte man sich die Kapazitäten beim Umladen aus dem Datenblatt ziehen und dann kann man sich das durchrechnen was da für ein Strom fließt und wenn dieser über 20mA liegt, wird es bei den meisten µC in die Hose gehen.

Es gibt viele die sich eignen, da sollte man wirklich das Datenblatt studieren. Es ist halt immer so, dass einige schwer zu bekommen sind. Nicht selten sind es genau die, die man gerade haben möchte ;-)

/Daniel

Zitat von: Samsi am 21 März 2015, 22:01:31
Die WLAN haben  3.3v level. Das hatte ich bei Dir im Panstamp thread auch schon gelesen, aber mir ist nicht klar, woran ich das im Datenblatt erkennen kann?

Da Google mal nach, das hängt von unterschiedlichen Faktoren ab. Da findest du viel bei Google. Vgs threshold, Diagramme und Static Drain-to-Source On-Resistance etc. Da muss man sich mal 4 Seiten anschauen bis man es selber für sich verstanden hat.

Btw. wenn einer noch eine FB von diesen standard Controllern über hat, ich könnte noch eine gebrauchen. Eine meiner FB hat nämlich ein Ausfall in einer Reihe... Und ich glaube die funktionieren alle untereinander, kommt ehe alles aus derselben China Schmiede.

Gruß
Daniel

Hallo,

es ist etwas Glücksspiel um wirklich 4A-Steuerelemente zu bekommen, zumindest liest sich das so. Welche Teile würde man benötigen um es selber auf einem Steckbrett (Lochrasterplatine) zu bauen? Ob das für 6 Euro zu bewerkstelligen ist, ist erstmal zweitrangig.

- 3 Transistoren (Je Farbkanal)
- das Wlan-Modul ES8266
- Step-Down-Modul
- Buchse für das Netzteil
- Kondensator
- Widerstände

UART, Netzteil und LED-Stripe ist klar, gehören aber nicht primär zur Steuerung.

Hab ich was übersehen? Könnte jemand mit einen Schaltplan und ggf. Spezifikationen für die Bauteile weiterhelfen? Wäre ein nettest Bastelprojekt.

Vielen Dank!

Zitates ist etwas Glücksspiel um wirklich 4A-Steuerelemente zu bekommen, zumindest liest sich das so

fh168 hat es auch mit dem 2A RGB modul hinbekommen. Ich habe da meins irgendwie gehimmelt. Ich vermute aber, das ich irgendwie einen Fehler gemacht hatte, ich sehe nämlich auch keinen Grund warum es nicht auch mit dem 2A modul gehen sollte.

Du könntest aber auch die MosFets und Widerstände nehmen wie hier in dem Projekt:

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

Genauso könntest Du auch die Spannungsversorgung für 3.3v von dem Projekt nehmen, wenn Du es ohnehin auf Lochraster aufbauen willst.

Ich hab das nur mit dem Step Down Modul gemacht, weil ich es recht klein haben wollte, damit alles in das kleine Gehäuse passt.

Hey Leute,
Hab hier bisher immer nur mitgelesen und nie wirklich was beigetragen. Deswegen will ich jetzt auch mal was zurückgeben. :)

Ich weiß nicht ob zwischendurch schon Mal jemand auf die Idee kam, aber mit einem ESP8266, WS2812 LED's und kleinen Modifikationen in Samsis Code lassen sich recht günstig(ca.5€ je nach Anzahl der WS2812 LED's) LED Lampen bauen die sich dann  über FHEM ansteuern lassen.
Das praktische ist, dass man mit dem ESP8266 direkt(also ohne zwischengeschaltete Arduino o.ä.) die WS2812 LED's ansteuern kann. Eigentlich sind die LED's für 5V Pegel ausgelegt aber anscheinend so tolerant, dass man sie auch mit dem 3,3V Pegeln des ESP8266 ansteuern kann. Für die, die WS2812 LED's noch nicht kennen: Das sind LED's die sich einzeln über ein 1Wire-Interface ansteuern lassen. Das heißt wenn man sie als LED Streifen zusammenschaltet(Wie es sie auch meistens zu kaufen gibt) kann man die Helligkeit und Farbe jeder einzelnen LED individuell steuern.
Ich steuere hier aber jede LED immer mit der gleichen Farbe an.


Hardware:
Ich habe einen Eagle Schaltplan und Layout angehängt.
Die Maße der Platine sind ausreichend klein um den ESP samt LED in einem ausgehölten E27 Glühbirnenkörper(Wie das geht findet man bei Google raus oder guckt zum Beispiel hier: http://www.fraumau.de/gluhbirnen-vase/. Schutzbrille nicht vergessen!) verschwinden zu lassen. Am Sockel guckt dann nur noch der Anschluss für den USB/Uart-Adapter und die Stromleitung raus.(Siehe Fotos)
Um die 3,3V für den ESP bereitzustellen braucht man noch einen Spannungsregler und zwei Kondensatoren.
Auf der Platine gibt es drei Anschlüsse:

SV1(Programmieranschluss):
SV4.Pin1: Anschluss zum USB/UartAdapter RX
SV4.Pin2: GND Zum programmieren muss GND auch mit dem GND eures Programmieradapters verbunden werden
SV4.Pin3: GPIO0 vom ESP8622. Falls ihr gezwungen seid NodeMCU neu zu programmieren müsst ihr diesen Pin auf GND legen
SV4.Pin4: Anschluss zum USB/UartAdapter TX

SV1(Anschluss an die LED's):
SV1.Pin1: +5V
SV1.Pin2: kommt von ESP8266.GPIO2 und soll an DI der ersten WS2812 LED
SV1.Pin3: GND

X2(Stromversorgung):
Die Pins sind hier leider nicht beschriftet. Man kann es aber auf dem Bild Schaltplan leicht erkennen. GND ist der Anschluss der auch mit SV4.Pin2 verbunden ist. +5V ist der Anschluss der mit SV1.Pin1 verbunden ist.

Beispiel-Einkaufsliste zur eigenen 5€ FHEM WLAN-Lampe:
Spannungsregler: zum Beispiel: ,,MCP 1702-3302" bei Reichelt.de (Beim verlöten auf der Platine muss man mit den Beinchen etwas tricksen, da die Beinchen nicht optimal zum Rastermaß passen.)
Kondensatoren: zum Beispiel: ,,TANTAL 1,0/35" bei Reichelt.de
Pfostenbuchse: zum Beispiel: ,,BL 1X20W 2,54" von Reichelt.de(Ist eine 20polige aber lässt sich mit einem handelsüblichen Seitenschneider ganz einfach auf die entsprechende Länge kürzen.)
ESP8266: am besten ESP8266-01 von Ebay (Warum die Version 01: Dieser hat nur zwei GPIO Pins. Wir brauchen aber auch nur einen um die LED's anzusteuern. Deswegen kann man ruhig die günstigste Version nehmen.)
LED: WS2812 von Ebay. Die 5mm Version(PL9823-F5) ließ sich bei mir NICHT direkt über den ESP8266 ansteuern. Anscheinend ist dieser nicht so tolerant.
Netzteil: Hier braucht mein ein Netzteil dass der Anzahl der LED's angepasst ist. Jede LED braucht im Maximalfall ca. 60mA. Bei einem LED Streifen mit 50 LEDs braucht man also ein Netzteil mit 50*0,06A=3A. Dazu würde ich aber noch 500mA draufschlagen. Einmal braucht der ESP8266 ja auch noch ein wenig Strom und manche Netzteile mögen es auch nicht die ganze Zeit am Leistungslimit betrieben zu werden. Im oben genannten Beispiel würde ich also ein Netzteil mit 3,5A sprich 17,5W bei 5V empfehlen. Mehr geht natürlich immer. Allerdings steigt dann auch der Verbrauch im StandBy.

Software:
Ich habe den modifizierten Code von Samsi angehängt.(Ich hoffe das ist okay?)
Die einzigen Änderungen die ich gemacht habe sind in der RGBController.setRGB() Funktion um die WS2812 anstatt der PWM anzusteuern und in der telnet.startServer() Funktion um anzuzeigen ob die Lampe sich ordnungsgemäß mit dem WLAN verbunden hat.
Die Lampe leuchtet nach dem einstecken erst Rot. Nur wenn sie sich erfolgreich mit dem vorher konfigurierten WLAN verbunden hat leuchtet sie kurz Grün und geht dann aus. Ab diesem Zeitpunkt kann sie genauso wie das Original von Samsi verwendet werden.
In der init.lua habe ich außerdem die Auskommentierung von run() entfernt, da der Code(bei mir zumindest) Problemlos läuft.

EDIT:
Fhem:
Ich habe die Lampe bei mir mit folgenden Befehlen integriert:
define KugelWLANpeWZ WifiLight RGB LW12:192.168.3.57
attr KugelWLANpeWZ webCmd RGB
attr KugelWLANpeWZ widgetOverride RGB:colorpicker,RGB
attr KugelWLANpeWZ icon light_light

Infos dazu gibt es auch auf der Modul-info-seite: http://www.fhemwiki.de/wiki/WifiLight

Um das Modul zu installieren habe ich es mir Manuell auf der entwicklerseite runtergeladen und in den modulordner kopiert. Per update-befehl ließ es sich nicht installieren.
Ich habe das ganze bisher in mehrere Versionen aufgebaut(Siehe Fotos). Einmal in einem Glühbirnenkörper einer ehemaligen 200W Lampe(direkt an ein 5V Netzteil angeschlossen) und nochmal in einer Ikea-Kugellampe. Dazu habe ich den Sockel einer alten Energiesparlampe geöffnet und die Kontakte an ein 5V Netzteil angeschlossen. Das ganze lässt sich dann wie gehabt in den Glühlampensockel einschrauben und wieder in der Kugellampe verstecken.(Wenn ihr das auch machen wollt und nicht vom Fach seid, lässt euch zumindest bei dem Anschluss des Netzteils an den Sockel helfen. Dort liegt Netzspannung an und die kann tödlich sein wenn nicht alles ordentlich angeschlossen und isoliert wurde.)
Außerdem habe ich auch noch eine Retro-Lichterkette aus mehreren ausgehölten Glühbirnenkörpern gebaut.

Gerade arbeite ich noch an einer Version, die sich über Batterien betreiben lässt. Wenn ich damit Fortschritte gemacht hab poste ich das hier auch nochmal.

Was vllt. noch eine ganz coole Modifikation des WifiLight-Moduls wäre, wäre wenn man die Farbe und Helligkeit von jeder einzelnen WS2812 LED einstellen könnte(und nicht alle auf einmal).
Dann ließe sich das Ganze auch sehr gut dazu ,,missbrauchen" um ein Status-Display aufzubauen. So wie zum Beispiel das Homematic ,,HM-OU-LED16".

So. ich hoffe ich hab nix vergessen. Würde mich freuen Feedback zu bekommen, wenn sich jemand die Mühe macht das nachzubauen.

Hallo Fabeulous,

schöne Umsetzung!

Zum ESP8266: wie viel Speicher (ROM/RAM) ist eigentlich mit dem sketch noch verfügbar ? Wenn da noch genügend frei ist könnte man vielleicht darüber nachdenken die transitions im ESP ablaufen zu lassen. Wenn Du eine Idee hast wie man die Einzelansteuerung der WS2812 auf der fhem Seite lösen kann wäre das gut.

vg
jörg

Hallo Jörg,

Danke :)

Also zum Speicher sagt der ESP folgendes:
,,----------------------------
RGBController.lc : 568 bytes
RGBController.lua : 401 bytes
init.lua        : 101 bytes
myNode.lua      : 481 bytes
telnet.lc       : 1228 bytes
telnet.lua      : 777 bytes
----------------------------
Total file(s)   : 6
Total size      : 3556 bytes

> r,u,t=file.fsinfo() print("Total : "..t.." bytes\r\nUsed  : "..u.." bytes\r\nRemain: "..r.." bytes\r\n") r=nil u=nil t=nil
Total : 68021 bytes
Used  : 5773 bytes
Remain: 62248 bytes"

von den insgesamt fast 70 KB Speicher sind also noch 62 KB frei. Ich weiß nicht wie aufwendig das programmiertechnisch ist aber man hat auf jeden Fall noch etwas Platz.

Also ich hatte schon überlegt, dass ganze etwas improvisiert zu lösen indem man jede LED virtuell als einzelne Lampe betreibt die dann über wifilight angesprochen wird. Allerdings müsste man dann für jede LED ein Socket öffnen und das ganze würde meiner Meinung nach sowieso spätestens bei einem LED Streifen mit 50 LED's ziemlich ,,unelegant".
Ich hab mich noch nicht wirklich in das wifilight Modul eingearbeitet. Wenn ich es aber richtig verstanden habe(laut Code im ESP8266) sendet das Modul erst ein Steuerbyte dann drei Bytes mit den Helligkeitswerten für Rot, Grün und Blau und dann nochmal ein Steuerbyte.
Ich fände es am einfachsten, wenn man zu den drei Farb-Bytes einfach noch ein Byte sendet mit dem dann die entsprechende LED angesteuert wird. Dann könnte man 255 LED's einzeln ansteuern.
(Mehr macht glaube ich auch nicht unbedingt Sinn, da die 255 LED's im Extremfall dann schon fast 16A aufnehmen.)
Vllt. könnte man einen Wert des ,,Steuerungsbytes" noch reservieren um damit alle LED's gleichzeitig zu steuern. So braucht man bei einer Änderung des kompletten LED Streifens mit beispielsweise 100 LED's nur vier anstatt 400 Byte übertragen.

Ich stelle mir den Datenframe also so vor:
SteuerungszeichenAnfang|AngesprocheneLED|Rot|Grün|Blau|SteuerungszeichenEnde

Wobei ich dann zum Beispiel den Wert 255 des Bytes ,,AngesprocheneLED" dazu reservieren würde die Helligkeit aller angeschlossenen LED's auf einmal zu setzen.


Ich hab mich mit der Programmierung der Module noch keine Erfahrung und wäre dankbar, wenn jemand das Umsetzen würde. Falls sich jemand die Mühe macht die notwendigen Modifikationen im Modul umzusetzen würde ich mich auch um die Anpassungen im Code des ESP kümmern.

Lg
Fabian

Hi Fabian

62k frei sind eine Menge. Wie aufwendig ist es die colortransitions im Controller laufen zu lassen? Sehr. Ist praktisch ein port der Sachen die jetzt im Modul gemacht werden ... Im Ergebnis laufen die dann aber ganz flüssig und unabhängig von fhem. Wäre schon mal ein Projekt.

Bei der einzelansteuerung ist das Protokoll nicht so dass Problem. Bei 50 leds bekommst du dann halt in fhem 50x readings, 50 einzelne farbregler. Ganz zu schweigen davon das dann so Sachen wie bewegliche farbverlaufe noch gar nicht eingeplant sind.

Vg
Joerg

Hallo,
neben dem freien Speicher muss man auch auf den "Heap" achten, node.heap() gibt darüber Auskunft. Je nachdem wieviele Variablen da benötigt werden geht das leider schnell zu Ende.

Köntest du vielleicht noch deine Integration in FHEM posten? Ich versuche das ganze aktuell mit MySensor aufzubauen und scheitere an dem Senden der Daten von FHEM zum Arduino.

Hi Gloob,

wird über Wifilight auf Basis des LW12 abgebildet (RGB)

Auf Controllerseite:

TCP 5577
Protokoll : 0x56, $r, $g, $b, 0xAA   ( 5 Bytes )

vg
joerg

@gloob:
Ich habe meinen ersten Post editiert und meine integration in FHEM eingetragen. Unter dem Softwarebereich ist der edit.

@Bapt. Reverend Magersuppe:
Danke für den Tipp. Werde ich bei geegenheit machen und auch hier posten. Momentan ist es bei mir zeitlich etwas eng zum basteln.

@All:
Ich tendiere dazu die Batteriebetriebsache zu lassen. Im niedrigsten Energiesparmodus in dem der ESP noch die WLAN-verbindung aufrecht hält verbaucht er ca. 20mA. Da hält die Batterie leider nicht lange. Bzw. nur so lange, dass ich dann doch lieber ein Kabel lege. :/

Zitat von: Fabeulous am 08 Juni 2015, 22:08:29
@Bapt. Reverend Magersuppe:
Danke für den Tipp. Werde ich bei geegenheit machen und auch hier posten. Momentan ist es bei mir zeitlich etwas eng zum basteln.

Hallo!
Ich experimentiere auch grad eifrig herum. Das mit dem LUA macht richtig Spaß! Leider stösst man da sehr schnell an die Speichergrenzen wenn man mehr als ein paar GPIOs an/aus zu schalten. Hoffe da tut sich in den nächsten Monaten noch was diesbezüglich von den Entwicklern.

Zusätzlich schaue ich mir gerade das Arduino-ESP-Paket an, das ist natürlich komplizierter. Aber mehr Freiheit im Speicher. Hat den Nachteil das man jedesmal kompilieren muss und dann im Flashmodus den ESP neu fleshen muss. Rapid-Protortyping geht flotter mit dem LUA.

Zitat von: Bapt. Reverend Magersuppe am 09 Juni 2015, 20:17:04
Das mit dem LUA macht richtig Spaß! Leider stösst man da sehr schnell an die Speichergrenzen wenn man mehr als ein paar GPIOs an/aus zu schalten ... Rapid-Protortyping geht flotter mit dem LUA.

Hallo Reverend,

bei mir ist es so, dass lua-Skripte, die am Tag vorher funktioniert haben, nicht mehr funktionieren bzw. nur teilweise. Wie ist Deine Erfahrung damit? Wie lädst Du die Skripte hoch? Mit dem Esplorer?
Ich denke, ich flashe die NodeMCU Firmware einfach noch mal drauf (quasi als Reset) und probiere es nochmal ...

Danke + Gruß

PeMue

Zitat von: PeMue am 09 Juni 2015, 22:09:23
Hallo Reverend,

bei mir ist es so, dass lua-Skripte, die am Tag vorher funktioniert haben, nicht mehr funktionieren bzw. nur teilweise. Wie ist Deine Erfahrung damit? Wie lädst Du die Skripte hoch? Mit dem Esplorer?
PeMue

Hallo PeMue!
ich hatte testweise  mal ein Blinker-Skript mit einer LED und einem kleinen Relais laufen und gleichzeitig noch das ds18b20-Webskript.  Anfangs hing sich das auch mal auf. Ich habe dann einen fetten Elko als Stütze in die Stromversorgung gehängt. Die meisten Hänger scheinen an der Spannungstabilität zu liegen. Das müsste man mal checken. Als Versorgung nehme ich ein simples 5V-Netzteil und ein Breadboard-3.3V Adapter.
Da lief es dann tagelang problemlos bis mir gesagt wurde Mach das blöde Klicken mal aus :-)

Hallo Samsi.

Ich bin gerade dabei mich mit Deinem tollen Projekt auseinanderzusetzen. Bauelemente sind schon da.  :)

Im ersten Artikel schreibst Du:

ZitatUnd vergesst nicht nach dem flashen mit nodemcu erstmal die Wlan Verbindung einmalig einzurichten:

wifi.setmode(wifi.STATION)
wifi.sta.config ( "WIFI_SSID" , "PASSWORD" )

Wo genau muß ich muss ich das eintragen? Ich meine nicht die SSID und Passwd das ist klar sondern in welcher Software. ESPlorer oder wo?

Hi,

ja im Esplorer kann man Befehle direkt ausführen (einmalig). Damit setzt Du dauerhaft die WLAN Verbindung.

Danke.

So. Das Projekt ist auch bei mir erfolgreich umgesetzt.  ;D

Eine Frage ist noch offen geblieben. Wenn ich eine feste IP in die init.lua eintrage startet zwar der ESP, meldet seine feste IP und wartet danach auf ein Connect. Aber nach ca 10 Sekunden startet er einfach neu. Mit Dynamischer IP habe ich dagegen keine Probleme. Muss ich noch etwas beachten wenn ich eine Feste IP verwende. Nicht Netzwerktechnisch sondern beim ESP und Nodemcu.

Auch ich habe das Projekt umgesetzt, die ESP-Variante mit WS2812 Leds. Allerdings mit der kleinen Änderung (Hardware+Software), dass meine Leds an GPIO 2 liegen.

Vielen dank an Samsi und an Fabeulous, dass ihr eure Arbeit mit uns teilt.

Ich habe zwar noch ein Problem, dass die erste Led immer grün leuchtet, aber das liegt vermutlich an meiner Hardware (pull-up Widerstand).
Der nächste Schritt ist die feste IP, da muss ich mich noch reinlesen, wie ich das definiere.

Zwei Anmerkungen habe ich noch:
In der Anleitung von Fabeulous steht "kommt von ESP8266.GPIO2 und soll an DI der ersten WS2812 LED".
Im Schaltplan und in der Software hast du aber GPIO 0 verwendet.

Zusätzlich ist mit in den Lua-Skripten aufgefallen, dass die Farbe für eine unterschiedliche Anzahl an Leds gesetzt wird:
einmal 27 Leds  und einmal 36 Leds, ist aber nur für längere Led-Strips wichtig

Hallo zusammen,
ich habe das Teil auch nachgebaut genial einfach msste mich nur erst mit nodemcu anfreunden.
Was müsste ich ändern um RGBW anzusteuern?
Gruß
Matthias

Hallo zusammen,

das Projekt hier ist super - ich möchte das ganze noch einen Schritt weiter gehen und selber mit dem esp8266 + eigenes PCB Layout Controller aufbauen.

Hab auch schon einige Projekte gefunden auf denen ich das ganze basieren möchte:
China RGBWW controller für ca 12euro
http://chaozlabs.blogspot.de/2015/08/esp8266-in-wild-wifi-led-controller-hack.html?m=1

Light Dimmer
https://hackaday.io/project/5646-5-wifi-led-dimmer-w-esp8266

RGB Wifi controller:
http://www.esp8266color.com/hardware/

Die Idee von mir ist es, das RGB Projekt noch um 2 Weitere PWM Kanäle zu erweitern für Warme und Kaltweiße LED Leisten.
Durch die Verwendung von IRLZ44N  Mosfets  kann dann auch deutlich mehr Last (LED-Leisten) geschaltet werden als bei den ganzen IR Ebay Controllern.

Gibt es neben den 5 PWM Kanälen noch etwas, was sinnvoll zu ergänze wäre für fhem?

Ich habe schon ein grobes Board entworfen, werde es später auf Github hochladen - Input ist gerne gesehen :-).
Sobald es fertig ist, werde ich die Bauteile in China bestellen und dann aufbauen. Werde dann da auch nochmal berichten...

Im Moment habe ich mit der Bestellung von 10 Platinen aus China ausgerechnet, dass ich für RGB+WW Controller auch auf ca 5-6 Euro komme. (Fehlt dann noch ein Gehäuse, aber Lasercutter/3d Drucker aus nem FabLab sollte hier abhilfe schaffen können ;-))

Die Software von hier sollte dann auch mit ein paar Modifikation verwendbar sein. Ich fände es auch spannend Szenen/Modi direkt auf den Controller zu packen (z.b. sowas wie Sonnenaufgang, Sonnenuntergang, Moodlight) so dass weniger Netzwerkverkehr entsteht?
Was meint ihr dazu?

Also so ein Controller würde mich brennend interessieren insbesondere wegen der höheren Leistung.
Allerdings muss die Software dann auch FHEM compatibel sein ...
Interessant sind auch Effekte die, nach auslösen, unabhängig von FHEM laufen.
Ich habe vor meine Wohnzimmerbeleuchtung auf LED-Stripes umzustellen ... das sind dann so ca. 10 Meter.
Wichtig wäre mir das man auch einen LAN-Adapter anstöpseln kann ... WLAN ist nicht so zuverlässig.

Freut mich das Interresse vorhanden ist - die Software sollte kein größeres Problem darstellen. Entweder man implementiert ein vorhandenes Protokoll (zb LD316) oder aber entwickelt ein neues was in wifilight integriert werden kann.

Hardware ist die Limitierung mit wlan durch den esp8266 einfach gegeben - er ist durch seine Bauweise und integriertes wlan spannend, da dadurch die kosten niedrig bleiben. (Pro Board werden es ca 6euro + Gehäusekosten.) Wenn schon was (hardware) fertiges gerade gewünscht ist, sind die H801Wifi Module zu empfehlen:
http://www.aliexpress.com/item/RGBWW-LED-Strip-Light-WiFi-Controller-Dimmer-Android-WLAN-Control-1-Port-Control-200-Lights-Output/32502007408.html?spm=2114.01020208.3.180.H9mmea&ws_ab_test=searchweb201556_6_79_78_77_80,searchweb201644_5,searchweb201560_9

Die Software darauf ist austauschbar, ansonsten ist alles schon fertig verlötet. 12 Euro sind schonmal günstiger als 25 ;-). Aber 6 Euro selber basteln schlagen das auch nochmal  ;D

Zitat von: mrpj am 21 November 2015, 23:25:02
Die Software darauf ist austauschbar, ansonsten ist alles schon fertig verlötet. 12 Euro sind schonmal günstiger als 25 ;-). Aber 6 Euro selber basteln schlagen das auch nochmal  ;D

Kleiner Hinweis, da es aktuell einen Coupon gibt: Preis - Coupon von $2.

MfG

Hi,

mal so zum Verständnis:

Die hier vorgestellten RGB Controller zerhacken den Strom und dimmen damit die LEDs auf den Stripes?

Mit konstantem Strom hat das nichts zu tun, oder? Über PWM einen variablen aber konstanten Strom zu erzeugen wäre zu gefährlich?

Kann man eigentlich einen Farbwert vorgeben, damit die LED´s nach dem Starten (booten) eingeschaltet sind?
Leider merkt sich der esp den zuletzt eingestellten Wert nicht.

Bei einem LD382 (ca. 25 Euro) geht das.
Sollte doch aber mittels eeprom auch machbar sein.
Ich weis allerdings nicht ob der ESP8266 einen hat.

Zitat von: AxelSchweiss am 22 November 2015, 12:32:58
Ich weis allerdings nicht ob der ESP8266 einen hat.

Hat er. Meines wissens 4k.

Zitat von: SpenZerX am 22 November 2015, 08:49:39
Hi,

mal so zum Verständnis:

Die hier vorgestellten RGB Controller zerhacken den Strom und dimmen damit die LEDs auf den Stripes?

Mit konstantem Strom hat das nichts zu tun, oder? Über PWM einen variablen aber konstanten Strom zu erzeugen wäre zu gefährlich?

Kurz erläutert: PWM - PulsWeitenModulation
PWM zerhackt weder Strom noch Spannung. In dem Fall hier wird die anliegend Versorgung zeitlich eingeteilt. Das bedeutet, statt dauerhaft die Versorgung anliegen zu haben, wird diese in ein Zeitfenster eingeteilt z.B. 1s und noch eine Frequenz (z.b. 1000HZ) - das bedeutet dass in dieser Sekunde die Versorgung 1000mal ein/ausgeschaltet werden kann.
Die Helligkeit wird dann dadurch geregelt dass z.B. die Versorgung nur 10% , 20%, 30% der Zeit anliegt. Die Spannung bleibt dabei konstant, in der Zeit wo der Strom "fließt" ist dieser auch konstant. Nur die absolute Leistung sinkt (ist ja auch klar, da z.B. 100mA nur X ms Sekunden fließen)

Ich hoffe die kurzerläuterung ist verständlich, bischen ausführlicher ist das ganze hier beschrieben:
https://www.mikrocontroller.net/articles/Pulsweitenmodulation
https://de.wikipedia.org/wiki/Pulsweitenmodulation

@matthias und axel
soweit ich das sehe, gibt es einen eeprom (sonst würde auch jedesmal das wlan passwort vergessen werden). Es ist nur die Frage wie dieser angesteuert wird.
Ich denke Softwaretechnisch wäre es sicherlich spannend, den letzten Wert sich zu merken (und/oder einen standardwert per command festlegen zu können). Ich mach mir da dann nur sorgen was den duty cycle angeht. Wie oft kann das eeprom beschrieben werden bevor es den geist aufgibt

-------------------

Ich hab mir gerade Gedanken zu Software gemacht
- Steuerung der einzelnen Farbwerte + WarmWhite  + ColdWhite ( 0-255 )
- Vorprogrammierung von verschiedenen Szenen (Sunrise, Sunset, Disko, Farbwechsel, Moodlight)
- Farbwechsel - Helligkeit,Dauer einstellen?
- Speicherung von default, letzter Einstellung?
- Statusabfrage (an/aus , welche Farbmischung etc.)

Was auch spannend zu kontrollieren wäre, wären szenen zu übergeben. Z.B. fade von R 0 auf R245 in 45sekunden etc? Jemand sowas ähnliches schon probiert?

Zitat von: mrpj am 22 November 2015, 13:38:37
Kurz erläutert: PWM - PulsWeitenModulation
PWM zerhackt weder Strom noch Spannung. In dem Fall hier wird die anliegend Versorgung zeitlich eingeteilt. Das bedeutet, statt dauerhaft die Versorgung anliegen zu haben, wird diese in ein Zeitfenster eingeteilt z.B. 1s und noch eine Frequenz (z.b. 1000HZ) - das bedeutet dass in dieser Sekunde die Versorgung 1000mal ein/ausgeschaltet werden kann.
Die Helligkeit wird dann dadurch geregelt dass z.B. die Versorgung nur 10% , 20%, 30% der Zeit anliegt. Die Spannung bleibt dabei konstant, in der Zeit wo der Strom "fließt" ist dieser auch konstant. Nur die absolute Leistung sinkt (ist ja auch klar, da z.B. 100mA nur X ms Sekunden fließen)

Ja das ist im großen und ganzen schon klar. Aber viel Licht wird man mit dem Konzept nicht machen können. Deshalb müsste man wohl 2 Arten von RGB Controllern entwerfen. Also einer für Stripes und einer für COB-RGB-Leds, oder?

Ich verstehe deine Aussage/Frage nicht - PWM wird schon seit geraumer Zeit für das dimmen von LEDs (egal ob COB oder "normale") genutzt....

Wozu sollen nun andere Controller entwickelt werden müssen?

Zitat von: mrpj am 22 November 2015, 13:38:37
soweit ich das sehe, gibt es einen eeprom (sonst würde auch jedesmal das wlan passwort vergessen werden).

Du könntest auch einen WLAN Konfigurationsassistenten in den Quellcode implementieren.

Danke dir für den CodeSchnipsel - die Idee ware es genau das zu tun. So dass sich die Module ähnlich den mi-light etc verhalten.


Der esp8266 hat scheinbar 4k eeprom mit ca. 100000 10 000 Schreibzyklen. Wenn man den letzten Status vor dem ausschalten nicht nur für nen paar Wochen speicher möchte, gilt es hier etwas trickreicehr vorzugehen.

Am besten man nutzt den ADC des esp8266 um den Spannungsabfall vor dem auschalten zu erkennen. Das würde bedeuten das man dem Board auf jedenfall noch einen Elko mit genug kapazität spendieren sollte so dass der esp lange genug an ist um den spannungsabfall zu bemerken.


Wie behandelt denn die hier vorgestellte Software das bisher - wird da etwas gespeichert?


Edit:
Ich habe heute Abend noch ein bischen queer gelesen zum esp8266 und eeprom/spiff Dateisystemen. Spannend was es so kann, aber meine Befürchtung mit den begrenzten Schreibzyklen ist vorhanden. Nach etwas rechnen und am Layout herumdoktoren hab ich es noch nicht geschafft einen groß genugen Pufferelko auf dem 5x5cm Board unterzubringen.

Den letzten Zustand könnte man auch auf dem Server speichern - nur wie schnell bootet der esp8266 und kann den server pollen? Wäre doof wenn man 20sekunden erstmal Dunkelheit hat. Andernfalls ist bei mir nicht das Problem gegeben, dass ich die Lampen per Lichtschalter an/aus schalten muss... Wird ja alles über Fernbedienung gesteuert - daher frage ich mich ob das so notwendig ist bei dem lowcost Projekt

Also mir würde es reichen wenn ich einen Farbwert vorgeben könnte. Ich möchte dir Teile immer komplett vom Strom trennen und dann ist es besser wenn sie nach dem einschalten in irgendeiner definierten Farbe leuchten.

Eigentlich würde es doch ausreichen wenn man einen Default Zustand einstellen kann.
Wenn der Controller dann bootet geht er in genau den Zustand.
Dadurch würde man die Schreibzyklen auf ein Minimum reduzieren.

Ich hab leider rausgefunden dass der Flash nur 10 000 Zyklen gesichert mitmachen soll - danach wirds knapp. Jetzt ist natürlich die Frage ob es wie bei den meisten AVRs nur sehr sehr niedrig angesetzt wird (AVRs mit 100k Zyklen schaffen teilweise bis zu 600k) oder es doch so niedrig ist.

Wenn es bei dem Vorschlag mit dem Standardwert bleiben soll, dann ist das relativ einfach zu realisieren. (Und macht die Schaltung um 50cent bis 1 Euro günstiger - je nachdem wie groß der Elko sonst hätte sein sollen).

Ich warte gerade noch auf einige Bauteile und würde dann noch testen bevor ich ein fertiges Design auf Github stelle

Zitat von: mrpj am 21 November 2015, 23:25:02
Freut mich das Interresse vorhanden ist - die Software sollte kein größeres Problem darstellen. Entweder man implementiert ein vorhandenes Protokoll (zb LD316) oder aber entwickelt ein neues was in wifilight integriert werden kann.

Hallo,

dieser Thread ist nach meinem Geschmack. Ich habe die ganze Zeit etwas in diese Richtung gesucht und bin jetzt erst mal beim LD382 gelandet. Da ich zu Beginn direkt den Weiß-Kanal *etwas* mit zu viel Ampere überstrapaziert habe, liegt jetzt ein Exemplar zum Testen hier. Mein Eindruck ist, dass auch der LD382 neu programmiert werden kann. Er hat ein RX und TX Pad auf dem PCB, über welche ich auch schon die Eigenschaften des Chips (STC15L2K16S2) auslesen konnte. Mangels funktionierender IDE konnte ich bisher noch keine weiteren Tests durchführen.
Falls jetzt was in Richtung eigene Firmware geplant ist, würde ich für eine möglichst übergreifende Protokoll-Lösung plädieren, die sowohl für den H801 (esp8266) implementierbar ist, als auch für weitere MCUs, so dass alles zentral über Wifilight steuerbar ist. Hierzu sollte auch gerne die Möglichkeit von Effekten auf dem Controller ins Auge gefasst werden.

Beste Grüße
Christian

Nachtrag:
Der STC15L2K16S2 lässt sich problemlos programmieren. Ein Großteil der Arbeit findet aber auf der WLAN Platine statt, welche einen eigenen MCU hat. Hier muss man schauen was geht. Es handelt sich um ein HF-LPT200 Modul. Datenblätter sind verfügbar.

Hallo Christian,

freut mich dass es da auch so gut geklappt hat. Wegen dem Protokoll - da bräuchte es mal eine Skizze - ich kenne mich mit fhem zu wenig aus um ein sinnvolles Protokoll zu entwerfen. (Im Grunde ist fhem für das was ich die Controller brauche auch overkill)


Bei mir gibt es einen Fortschritt - hab nun mal den Prototypen von Board fertig gelayouted. Es ist leider nun 5x5cm Breit geworden - aber dafür hat es 5 Kanäle (RGB WW CW) und die Leitbahnen sind für die Stromstärke angepasst. (12V Zuleitung sind ca 6mm, die einzelnen Leiterbahnen bei den FETs ca 3,5mm). Damit sollte es möglich sein 4-5A pro Kanal zu schalten. Kritisch wird es nur wenn alle 5 Kanäle mit 5A gefahren werden - da sollten 12V direkt vom Netzteil abgegriffen werden... Massefläche "sollte" ausreichend sein um die Ströme abzuhaben.

Wenn mal jemand drüber schauen will , bild ist im Anhang, freu mich sehr über Kommentare.

Anmerkung: Es muss wahrscheinlich noch nen 0,1 uf Kondensator neben den Elko. (Warum der Elko? In vielen Diskussionen soll der esp oftmals random resets haben - die Vermutung liegt nahe dass es an einer nicht stabilisierten Stromversorgung liegt und das möchte ich damit ausgleichen. ) 2. eventuell in Version2 nutze ich den ADC um bei Stromweg den letzten Stand der Lampe zu speichern... Leider musste ich rausfinden, dass die esp8266 eproms meist nur 10 000 zyklen vertragen :(


Nachtrag:
Simulation ist drüber gelaufen - passt soweit alles - sofern keine Aufschreie kommen werde ich spätestens am Freitag die Boards und Bauteile aus China bestellen (10 Stück - brauch davon 4-5, wäre jemand anderes an den anderen interressiert? Bauteile inklusive sind das ca 6 Euro pro Modul)

Gibt es die Platine (und Schaltplan) auch als Eagle? Editiert sich einfacher.

Gruß PeMue

Zitat von: mrpj am 01 Dezember 2015, 14:28:33
Simulation ist drüber gelaufen - passt soweit alles - sofern keine Aufschreie kommen werde ich spätestens am Freitag die Boards und Bauteile aus China bestellen (10 Stück - brauch davon 4-5, wäre jemand anderes an den anderen interressiert? Bauteile inklusive sind das ca 6 Euro pro Modul)

Ich hätte schon Interesse an einem Modul. *anmeld* :)

Zitat von: mrpj am 01 Dezember 2015, 14:28:33

Nachtrag:
Simulation ist drüber gelaufen - passt soweit alles - sofern keine Aufschreie kommen werde ich spätestens am Freitag die Boards und Bauteile aus China bestellen (10 Stück - brauch davon 4-5, wäre jemand anderes an den anderen interressiert? Bauteile inklusive sind das ca 6 Euro pro Modul)

Ich würde auch eine nehmen. :)

Zitat von: mrpj am 01 Dezember 2015, 14:28:33

Nachtrag:
Simulation ist drüber gelaufen - passt soweit alles - sofern keine Aufschreie kommen werde ich spätestens am Freitag die Boards und Bauteile aus China bestellen (10 Stück - brauch davon 4-5, wäre jemand anderes an den anderen interressiert? Bauteile inklusive sind das ca 6 Euro pro Modul)

Ich würde auch eine nehmen. :)

Für mich bitte auch ein Modul  ... falls dann noch welche übrig sind nehme ich auch gerne zwei.

Auch. Oder mehr. Protokoll kann ich vmtl beisteuern.

Danke und vg
Joerg

Ich würde mich auch in die Schlange der Interessenten einreihen.

Interesse hätte ich auch, wie sähe denn die Liste der für den Aufbau benötigten Artikel aus?

Greetz
Eldrik

Will auch ... schon mal vielen Dank für den Aufwand!

Versuch macht kluch!
Ich tät auch eins nehmen.

Ich würde 2 nehmen.
Gruß Matthias

Hallo,
auch ich hätte Interesse an 2 Stück!

Gruß
Stefan

Eins würde ich auch nehmen

Schaff' schon mal Platz in der Wohnung.
Die Sendung wird wohl doch etwas grösser als erwartet. ;D

Vielleicht bekommst Du sogar Mengenrabatt... 8)

ich würde auch zwei nehmen :-)

Zitat von: mrpj am 01 Dezember 2015, 14:28:33
Bei mir gibt es einen Fortschritt - hab nun mal den Prototypen von Board fertig gelayouted. Es ist leider nun 5x5cm Breit geworden - aber dafür hat es 5 Kanäle (RGB WW CW) und die Leiterbahnen sind für die Stromstärke angepasst. (12V Zuleitung sind ca 6mm, die einzelnen Leiterbahnen bei den FETs ca 3,5mm). Damit sollte es möglich sein 4-5A pro Kanal zu schalten. Kritisch wird es nur wenn alle 5 Kanäle mit 5A gefahren werden - da sollten 12V direkt vom Netzteil abgegriffen werden... Massefläche "sollte" ausreichend sein um die Ströme abzuhaben.

Wenn mal jemand drüber schauen will , bild ist im Anhang, freu mich sehr über Kommentare.

Nachtrag:
Simulation ist drüber gelaufen - passt soweit alles - sofern keine Aufschreie kommen werde ich spätestens am Freitag die Boards und Bauteile aus China bestellen (10 Stück - brauch davon 4-5, wäre jemand anderes an den anderen interressiert? Bauteile inklusive sind das ca 6 Euro pro Modul)

OK, dann ohne Eagle:
- ich würde das Bauteil über GPIO15 anders anbinden (thermisch symmetrisch, d.h. links und rechts gleicher Leiterbahnquerschnitt)
- dito für R4
- dito für CH_PD
- IN+ schöner machen  ;)
- IN- statt 90° zweimal 45°
- Anbindung CW linker Pin ist etwas "unorthodox", würde ich anders machen
- C1 ist zu dicht am Platinenrand, nach rechts verschieben
Welchen Leiterbahnabstand nimmt Du? Ich würde min. 0.15 mm nehmen (Design Rule). Ggf. mit den Regeln von dfrobot.com testen (die von ITead sind etwas "laxer").
Die Versionsnummer würde ich in v1.0 ändern und ggf. im Kupfer machen.
Gibt es ein Gehäuse dazu?

Melde auch mal Interesse an einem Board an (gerne aus späterer Lieferung).

Gruß PeMue

Edit1: Am PC noch mal die Schreibfehler korrigiert, am Tablet ist das echt *******  >:(
Edit2: Interesse auf folgende Lieferung angepasst.

Hallo Robin,

der Winter wird lang. ;)
Da muss man für neue Tüfteleien vorsorgen...

Wollen wir mal hoffen, das der Winter nicht so lang wird. Ich fahre nicht so gern im Schnee zur Arbeit.
Aber ich freue mich schon auf neue Basteleien. Das LCD-Stripe vom ersten Post läuft bei mir immer noch super stabil. Ich bastel gerade an den NodeMCUs rum :-).

Robin

Hallo,

würde auch gerne 2 nehmen.

Danke und Grüße

Jörg

Würde wohl auch welche nehmen

Hätte auch Interesse an einigen Stück!
2 mindestens.

Ich würde auch 2 nehmen!

Gesendet von meinem HTC One_M8 mit Tapatalk

Hallo,

Ich würde mich auch direct für 3 Platinen anmelden.

Vielen Dank
Stefan

Ich würde auch 3 nehmen


Sent from my iPad using Tapatalk

Freu mich gerade dass so viele Leute Interresse haben sich selber die Controller zu basteln. Bin gerade etwas überrumpelt dass gleich so viele eine Platine wollen. Im Moment hatte ich eher gedacht meine nicht benötigten Platinen weiter zu geben (wenn alles getestet wurde und sicher funktioniert  ;) ). Aber wenn so viel Interresse ist, kann man sicherlich auch eine Sammelbestellung danach aufgeben.

Der Haken ist einfach, es wird eine Gewisse Zeit dauern - Die PCBs und Bauteile kommen aus China und da sind schonmal ca 30-40 Tage Lieferzeit drinnen. Ich gehe davon aus das ich alles erst im neuen Jahr bekomme. Erst dann kann ich die Platinen und Schaltung in echt testen - mache mir da noch etwas Sorgen dass die FETs (IRLZ44N) auch wirklich komplett bei 3.3V schalten. Laut Datenblatt sollte es so sein, aber man weiss ja nie  ;)

Lange Rede kurzer Sinn - für mein Bauchgefühl ist es mir lieber eine echte Sammelbestellung zu machen, wenn ich das Board real testen konnte. Wer gerne das Risiko eingehen möchte auch schon davor ein kleines Bastelprojekt zu haben, für den kann ich sicherlich die Bauteile mitbestellen.  :D

Zitat von: PeMue am 02 Dezember 2015, 20:21:11
OK, dann ohne Eagle:
- ich würde das Bauteil über GPIO15 anders anbinden (thermisch symmetrisch, d.h. links und rechts gleicher Leiterbahnquerschnitt)
- dito für R4
- dito für CH_PD
- IN+ schöner machen  ;)
- IN- statt 90° zweimal 45°
- Anbindung CW linker Pin ist etwas "unorthodox", würde ich anders machen
- C1 ist zu dicht am Platinenrand, nach rechts verschieben

Vielen Dank dir für die Hinweise
Tut mir Leid dass ich gerade erst so spät darauf antworten kann - musste die Schaltung nochmal zeichnen (die Eagle Dateien waren auf nem Rechner bei mir an der Arbeit und ich hatte vergessen die auf einen USB Stick mitzunehmen  :-\).
Im Anhang sind die neuen Eagle Dateien + Bilder - deine Anmerkungen sind soweit umgesetzt.

Zitat von: PeMue am 02 Dezember 2015, 20:21:11
Welchen Leiterbahnabstand nimmt Du? Ich würde min. 0.15 mm nehmen (Design Rule). Ggf. mit den Regeln von dfrobot.com testen (die von ITead sind etwas "laxer").

Im Moment ist es noch auf 6mil eingestellt. Da ich bei dirtypcb die Platinen herstellen lassen, sollte es nach deren Regeln gehen - hab zur Sicherheit auch die von dfrobot angewendet und passt soweit alles. (Bis auf das die Polygon Linien zu schmal sein sollen  :o)

Zitat von: PeMue am 02 Dezember 2015, 20:21:11
Die Versionsnummer würde ich in v1.0 ändern und ggf. im Kupfer machen.

Versionsnummer ist geändert - Logo wollte ich auf dem Silkscreen drucken lassen

Zitat von: PeMue am 02 Dezember 2015, 20:21:11
Gibt es ein Gehäuse dazu?

Ich hatte vor mal den Lasercutter in dem FabLab hier um die Ecke zu testen - dachte mir da an eine einfache Box mit passenden Aussparrungen und Lüftungsschlitzen. Das ganze geht mit Acryl (teurer) oder 4mm MDF. Sobald ich ne Zeichnung davon hab, lad ichs gerne hoch



Irgendjemand hatte noch nach der Auflistung der Bauteile gefragt, finden den Post gerade blos nicht mehr. Aber hier dennoch mal die benötigten Bauteile

• 1x ESP8266, ESP-12 format
• 1x XM1584 Power converter
• 5x IRLZ44N Mosfet (logic level gate threshold)
• 8x 10k resistors, 0603 format
• 1x 470 µF Elko RM 3.5 mm
• 1x 5,08mm 2pin terminal block
• 1x 5,08mm 3pin terminal block
• 1x 5,08mm 4pin terminal block
• 1x 2,54mm 4pin header
• 1x Micro SMD Tact Switch 2 pin 3*6*2.5 mm 

Alles zusammen nicht viel, je nachdem bei welchem Händler auf aliexpress man bestellt komm ich gerade auf ca. 6Euro pro Board

---

Nachtrag:
Ich habe die Dateien aus dem Beitrag entfernt und auf github verschoben.
Repository ist hier zu finden: https://github.com/patrickjahns/esp_rgbww_controller

Lässt sich anstatt des ESP-12 auch ein ESP-07 verwenden?
Der Vorteil wäre das es noch einen Antennenanschluss gibt für besseren Empfang.
Pinkompatibel scheinen sie zu sein.

An sich sollte es kein Problem sein - von den Dimensionen ist der ESP-07 etwas kürzer, aber die Pinouts sollten auf der gleichen Höhe sein (Sofern sich die Hersteller daran halten...)
Ich finde den 12er "praktischer" - viel mehr Antennenfläche ist in einem Laptop auch nicht drin ;-)

Hallo ,

Bitte vormerken,
ich würde gerne auch zwei haben wollen.
Ruhig auch aus einer späteren Produktion.

Gruß

ThomasW

Also, um etwas für dein Bauchgefühl zu tun, würde ich zwar das Risiko eingehen, aber dann auf 1 Stück reduzieren.
So ein Bastelprojekt nebenbei ist immer nicht verkehrt. ;-)

Zitat von: herrmannj am 02 Dezember 2015, 00:12:26
Auch. Oder mehr. Protokoll kann ich vmtl beisteuern.

Danke und vg
Joerg

Hi @all,

Thema Protokoll:

derr Ausgang im thread war je eine MCU die den ld382 emuliert.

Im Kern war das pragmattisch und gut. Im next level sehe ich aber weitere Schritte: Beim ld382 ist es ja so das die Farbüberrgänge in wifilight gemacht werden und dann jeweils als einzelner Farbwert an den controller gehen.

Wenn wir eine eigene fw schreiben sollten die aber imho im controller abegarbeitet werden. Sprich, der controller bekommt gesagt: fade von rot nach blau und dann macht er das unabhängig vom fhem timing und viel flüssiger.

Farbraum würde ich auf HSVK erweitern (sprich HSV plus Weißtemperatur.)

Animationen (automatische Farbwechsel) im controller macht wifilight genau deshalb nicht weil die in jedem controller anders (oder ganrnicht) sind. Da stelle ich mir vor das fhem bei controller anfragt "was kannst Du?" - derf controller liefert eine Liste zurück und dann kann man die starten. So kann man zB auch "Kerzenflackern" ummstzen.

Heist: spezielles "wifilight". Die ganzen Transitions wandern aus dem modul in den controller. Wifilight hat im verlauf der Evolution ja viel drin (Farbkorrektur, Weißabgleich) was es mNn auch so sehr selten Home LED Controllern gibt. Da kann man viel know-how direkt übernehmen.

Andere/mehr Ideen ?

vg
Jörg

Die Ideen dazu finde ich spannend, hab ein paar Fragen dazu:

- der esp scheint ab und an Pakete zu verlieren - wie handhaben wir das? Muss er ein ACK senden wenn das kommand angekommen ist?
- Thema Weiss und Farbtemperatur - Ich habe ja 2Weißkanäle vorgesehen - für WW,CW leds - wie kann man daraus etwas berechnen?
- Speicherplatz/RAM/Heap - da der ESP auf wenige KB begrenzt ist, müssen wir mal schauen, wieviel an vordefinierten Farbübergängen machbar ist. Hier sollten wir uns zunächst auf die wichtigsten Beschränken. Welche sind das? (Sonnenaufgang, Sonnenuntergang ???)
- Wie stellst du dir die Farbkorrektur/Weißabgleich vor? Werden die Settings im Wifilight eingestellt und der ESP kriegt es zugeschickt, oder wird es von fhem weiterhin gehandhabt


Das ganze ist gerade noch sehr Abstrackt - das wichtigste beim Protokoll für mich ist das Protokoll selbst, nicht die Funktionen.
Soll es UDP werden? Oder tcp? - Protokoll als RPC? Was ist hier passend?
(Ich denke ein webservice mit einem simplen rpc Protokoll ist am flexibelsten)

Nochmal einen Schritt weiter, auf welcher Basis wollen wir die Firmware entwickeln? Lua mit NodeMCU , oder C via Arduino IDE ?
Gibt es eine webserver Implementation die non-blocking bei einem request ist? (Da PWM bei beidem Softwareseitig gelöst ist, muss der request handler nicht blockierend sein, sonst flackerts bei jedem request....)

@herrmannj

Kannst du eventuell auf der Basis von deinem Wissen aus dem Wifilight Modul eine Skizze für die API/Protokoll erstellen? Also praktisch eine API Dokuementation mit den einzelnen Befehlen schreiben?

---

Zum Thema bestellen:
Wie oben geschrieben möchte ich hier (noch) keine Sammelbestellung starten. Ich bestell jetzt 10 Testboards aus China mit allen Bauteilen dafür. Sobald die Sachen angekommen sind frag ich nochmal nach wer gerade eins möchte zum testen. Sobald etwas Feedback vorhanden ist kann danach eine Sammelbestellung (in einem eigenen Thread dafür) gestarte werden. Übersichtshalber wäre es schön wenn wir dann hier bei der Diskussion von Hardware und Software bleiben  ;)

Zitat von: mrpj am 04 Dezember 2015, 11:25:36
- der esp scheint ab und an Pakete zu verlieren - wie handhaben wir das? Muss er ein ACK senden wenn das kommand angekommen ist?

ja, würde ich so machen wollen.
a: udp verliert halt Pakete, daher tcp
b: das modul würde ich so halten wollen das auch Funkstrecken gehen (rfm69, 2401 etc). Ist für battery device imho angenehmer.

Zitat
- Thema Weiss und Farbtemperatur - Ich habe ja 2Weißkanäle vorgesehen - für WW,CW leds - wie kann man daraus etwas berechnen?

Wird in Wifilight so gemacht. Zuerst wird der Farbanteil und der Wießanteil getrennt (Saturation). Dann wird die Farbkorrektur auf den Farbanteil angewendet und (derzeit bei RGB) der Weißabgleich durchgeführt. Hier muss man dann nur zwischen CW und WW Channel gewichten um die richtigen Kelvin zu bekommen.

Zitat
- Speicherplatz/RAM/Heap - da der ESP auf wenige KB begrenzt ist, müssen wir mal schauen, wieviel an vordefinierten Farbübergängen machbar ist. Hier sollten wir uns zunächst auf die wichtigsten Beschränken. Welche sind das? (Sonnenaufgang, Sonnenuntergang ???)

Ja, erstmall mit einigen anfangen und dann weiter sehen. Das mit dem Speicher sehe ich nicht so kritisch, da werden ja nur Vektoren hinterlegt.

Zitat
- Wie stellst du dir die Farbkorrektur/Weißabgleich vor? Werden die Settings im Wifilight eingestellt und der ESP kriegt es zugeschickt, oder wird es von fhem weiterhin gehandhabt

Yepp, hier kann man eben viel Wissen aus wifilight transferieren. Der Abgleich muss im Controller gemacht werden weil er ja auf jeden einzelnen Farbwert abgebildet werden muss.

Nach so als Anhang: die Transitions werden in wifilight gradgenau berechnet. Bei einem 8bit PWM erwischt man dmit aber bei voller Helligkeit nicht die komplette Range des PWM. (3 Farben * 2^8 * 2 = 1536 vs 360°). Bei einem 12bit PWM sogar mehr. Das kann man ebenfalls nur im controller abbilden.

Zitat
Das ganze ist gerade noch sehr Abstrackt - das wichtigste beim Protokoll für mich ist das Protokoll selbst, nicht die Funktionen.
Soll es UDP werden? Oder tcp? - Protokoll als RPC? Was ist hier passend?
(Ich denke ein webservice mit einem simplen rpc Protokoll ist am flexibelsten)

Ich würde auf TCP mit einfachen bytesequenzen setzen. Das skaliert imho am meisten. Einen Webserver würde ich nicht unbedingt sehen. Vielleicht für die config, aber braucht man imho nicht unbedingt (geht auch locker über telnet).

Zitat
Nochmal einen Schritt weiter, auf welcher Basis wollen wir die Firmware entwickeln? Lua mit NodeMCU , oder C via Arduino IDE ?
Gibt es eine webserver Implementation die non-blocking bei einem request ist? (Da PWM bei beidem Softwareseitig gelöst ist, muss der request handler nicht blockierend sein, sonst flackerts bei jedem request....)

Ich würde C setzen, dann geht das auch gleich für Arduinos. Gibt übrigens eine gut lib (fastLED) dafür.

Zitat
@herrmannj

Kannst du eventuell auf der Basis von deinem Wissen aus dem Wifilight Modul eine Skizze für die API/Protokoll erstellen? Also praktisch eine API Dokuementation mit den einzelnen Befehlen schreiben?

Gute Idee. Ersmal so als draft, und Grundlage für Ideenaustausch.
vg
joerg

Danke dir für die Antworten.

Zitat von: herrmannj am 04 Dezember 2015, 11:56:02
Nach so als Anhang: die Transitions werden in wifilight gradgenau berechnet. Bei einem 8bit PWM erwischt man dmit aber bei voller Helligkeit nicht die komplette Range des PWM. (3 Farben * 2^8 * 2 = 1536 vs 360°). Bei einem 12bit PWM sogar mehr. Das kann man ebenfalls nur im controller abbilden.

Ja die Auflösug bei dem PWM des ESP ist da größer - soweit ich es gesehen habe sind es 10bit PWM Kanäle. Einen Haken gibt es jedoch, auch wenn theoretisch mehr Abstufungen möglich sind, so ist die Leuchtstärke von den LEDs nicht linear mit dem PWM Kanälen dimmbar, sondern folgt einer anderen Kurve. Da wäre es sinnvoll eventuell bei den 360grad zu bleiben und eine Umrechnungstabelle zu entwerfen um einen besseren Übergang zu erziehlen?

Leider habe ich bisher von HSV/HSL noch wenig Ahnung

Zitat von: herrmannj am 04 Dezember 2015, 11:56:02
Ich würde auf TCP mit einfachen bytesequenzen setzen. Das skaliert imho am meisten. Einen Webserver würde ich nicht unbedingt sehen. Vielleicht für die config, aber braucht man imho nicht unbedingt (geht auch locker über telnet).Ich würde C setzen, dann geht das auch gleich für Arduinos. Gibt übrigens eine gut lib (fastLED) dafür.

Ich bin mir bei TCP bytesequenzen noch nicht ganz sicher - hab jetzt nochmal bischen quer gelesen und mir erscheint die "webservice" variante schon auch sinnvoll (json-rpc) oder eine message queue variante wie auch bei openhab? Wie siehst du das?

Einen kleinen webserver fände ich zum einfachen setup schon sinnvoll. Der esp kann ja auch als AP agieren. Frei nach dem Motto, wenn kein bekanntes Netzwerk erreichbar ist nach X Sekunden dann mache einen AP auf so dass der eigentliche Router/Ap eingestellt werden kann....

Ich schau mir mal fastLED an - je weniger man selber machen muss umso besser.
Da kommt mir auch der Gedanke, ob es nicht Sinn macht die gemeinsamen Komponenten (PWM, Transitions etc.) in eine eigenen lib zu packen und dann nur noch den Gerätespezifischen Code (esp, arduino) darüber zu packen? Somit kann es auch für andere Komponente (RF, Arduinos etc.) genutzt werden

Ich hab mir jetzt fastLED angeschaut - wenn ich nicht ganz falsch bin, ist es für andere LEDs gedacht und nicht für RGBWW Stripes geeignet? Vielleicht habe ich auch etwas falsch interpretiert....

Was mir noch zur Software kam: Es wäre sehr angenehm, wenn sich die Module direkt über Wifi updaten lassen. Somit muss man nur einmal am Anfang nen FTDi Kabel anschließen und dann ist gut.

Hier auch noch ne schöne idee: kann die hue Livingcolours ersetzen:

http://www.amazon.de/gp/product/B00B545UVE?ref_=gb1h_img_c-4_3647_b81dd0f4 (http://www.amazon.de/gp/product/B00B545UVE?ref_=gb1h_img_c-4_3647_b81dd0f4)

Hi,

geht langsam weiter (Zeitmangel)

Die Funktionen zum faden habe ich rudimentär im Test (very early stage!!!).

Der converter rechnet mit der bitweite des PWM und rein integer basiert, also fix.

Erste Funktionen zur Farbkorrektur sind drin. Dies ist notwendig weil die (RGB) LED erstens pro Kanal (und Typ) einen unterschiedlichen Wirkungsgrad haben und zweitens das setup (Vorwiderstand) ja von der Schaltung abhängig ist. Das hat noch nichts mit Weißabgleich oder CW/WW zu tun. Sondern: Gelb zb ist per Definition ja ROT ung GRÜN zu gleichen Anteilen. Da im Normalfall Grün an der LED heller ist bekommt man bei einer 1:1 Mischung von R und G ein Grün mit Gelbstich. Das muss eben korrigiert werden.

Ich schaue als nächstes mal die Gammakorrektur an. Da weiß ich noch nicht genau wie ich das auf dem MC umsetze. In Wifilight gibt es dafür eine lookup table.

Hier sehe ich drei Möglichkeiten die ich untersuche:

- lookup table im progmem. Vorteil: kostet kein RAM / Nachteil: muss zur compile time passend zum pwm und zum setup erstellt werden
- lookup table im ram. Vorteil: kann zur Laufzeit erstellt und angepasst werden / Nachteil: recht groß: 1024 32bit Wörter beim ESP
- on.the-fly Berechnung (integer). Da weiß ich noch nicht wie

Wenn jemand eine elegante Möglichkeit (gern auch Näherungsweise) kennt wie man das mit Integer Math lösen kann, gerne her damit :)


vg
joerg

Klingt doch soweit schonmal gut  :)

Hast du den Code eventuell schon auf github oder ähnlichem das man sich das mal anschauen kann?

Zu deinem Problem - sowie ich das gesehen habe, unterstützt der esp auch das filesystem spiffs.... Somit kann man die table dort auch indirekt als hashtable ablegen. Kommt jezt natürlich darauf an wie schnell der Zugriff erfolgen soll - aber als alternative vielleicht ne Idee

bisher nur lokal.

Wenn man so rechnet:

out = in^3 / pwm_size^2
out += (in-out)/32

stimmen die Werte mit +/- 1 mit diesen https://learn.adafruit.com/led-tricks-gamma-correction/the-quick-fix überein. Das geht ohne probleme Integer (32bit bei 10bit pwm) - damit on-the-fly.

Bei RGB zu Weiß Mischung mit Weißabgleich ist das erste bit natürlich bei R auch zuerst sichtbar - das liegt im System. Bei einer separaten white LED würde die ja angesteuert ..

Also, geht doch voran.

vg
joerg

Wie ist denn der momentane Stand der Dinge?
Gibt's was neues zu berichten?

Zu dem Thema etwas interessantes von Chinesen: http://forum.fhem.de/index.php/topic,46688.msg384273.html#msg384273
Wie blöd da auch klingt, das wäre bei praktisch fast gleichem Preis eine bessere Option :(

Zitat von: hexenmeister am 03 Januar 2016, 23:35:22
Zu dem Thema etwas interessantes von Chinesen: http://forum.fhem.de/index.php/topic,46688.msg384273.html#msg384273
Wie blöd da auch klingt, das wäre bei praktisch fast gleichem Preis eine bessere Option :(

Das ist nichts neues - wurde von mir schon genannt:
http://forum.fhem.de/index.php/topic,34464.msg362961.html#msg362961

Aber auch da muss Hand angelegt werden, wenn man eine eigene Software drauf haben möchte (pins zum flashen)

Dann kommt noch hinzu, dass ich den teilen auch bei hohen Belastungen nicht trauen würde - am Anfang haben diese Module nicht mehr als 2A (pro Kanal) vertragen, angeblich mittlerweile 4A (pro Kanal). Bezweifel ich sehr wegen der Leiterbahnbreite

Fazit: Bessere Option zum modden eines IR-Moduls wahrscheinlich, bessere Option zu eigenem PCB und Bauteile sehe ich nicht wirklich. Daher habe ich damals auch ein PCB entworfen statt die Module zu nehmen

Zitat von: RappaSan am 03 Januar 2016, 14:03:14
Wie ist denn der momentane Stand der Dinge?
Gibt's was neues zu berichten?

Ich warte auf Bauteile und die PCBs. Ein Teil ist da, der andere fehlt noch

Wie es mit der Software aussieht weiss ich leider nicht? Any news?

Moin, Moin,

ZitatWie es mit der Software aussieht weiss ich leider nicht? Any news?

Dauert noch weil andere Projekt vorher anstehen.

Sorry vg
joerg

Ist es möglich dass du mir den bisherigen Code frei gibst - dann kann ich die Tage vielleicht noch ein paar Zeilen weiter programmieren und es (wenn der Rest von mir ankommt) gleich mal testen?

Kurzes update:
- PCBs sind angekommen
- die meisten Bauteile sind angekommen (es ist eine Packung der 2er Klemmen und die 3er Klemmen nicht angekommen - obwohl alles gleichzeitig bestellt  ;D)

Das erste Board wurde schonmal zum testen aufgebaut - eventuell komm ich noch dazu heute/morgen eine erste Firmware zu flashen.
Wenn ich es in den nächsten Tagen ins FabLab schaffe, lass ich auchmal ein Probe Gehäuse lasern

Eine Software ist noch nicht geschrieben - jede Hilfe ist hier gerne gesehen ;-)

1) Allgemeine Funktionen:

• Protokoll für die Kommuniation entwerfen
• RGB+WW PWM Fader
• Farbübergänge (fade von farbe x zu y, Sonnenaufgang etc.)

2) Esp spezifisch:

• WifiManager (startet AP wenn nicht mit einem Router/AP verbindbar)
• ConfigurationsManager (IP, DefaultFarbe, ??)
• OTA Funktion

Als Firmware Basis greife ich auf den Arduino IDE zurück - habe bisher mehr Erfahrung mit AVRs und C gesammelt und somit kann für 1) eine C library entworfen / genommen werden die dann auch auf anderen Mikrocontrollern einsetzbar ist

Edit:
Für v1.1 kommen mir auch schon Ideen:
- Anordnung der FETs ändern um die möglicherweise flach legen zu können
- alternativ andere FETs mit gleichen Eigenschaften nehmen die an sich flach montiert werden
- Prog Schnittstelle nur zum anlöten für die erste firmware - weitere updates nur noch per OTA

Moin,

Ich bin gerade dabei etwas ähnliches (Keller-Sensor) auf ESP8266-Basis zu programmieren.
Meine Wünsche bzgl. Konfiguration sind mit Deinen Vorstellungen vergleichbar.

Habe als Basis für meine Programmierung auf die Vorarbeit von Andreas Kriwanek zurückgegriffen.

http://www.kriwanek.de/homeautomation/esp8266-chip/532-konfiguration-der-esp8266-geraete-ueber-http.html (http://www.kriwanek.de/homeautomation/esp8266-chip/532-konfiguration-der-esp8266-geraete-ueber-http.html)

Sein Beispiel bringt bis auf OTA alles mit und erste Tests waren erfolgreich.

Als Protokoll nutze ich MQTT, damit sollte auch die Verwendung von verfügbaren FHEM-Modulen wie z.B. ColorPicker verwendbar sein.


Gruss

Andreas

Hallo Andreas,

danke dir für den Link - ich habe auch für mich noch eine gute Library gefunden:

https://github.com/tzapu/WiFiManager

OTA lässt sich mit den Standardfunktionen der Arduino Lib implementieren.

Für die RGB (WW, CW) Ansteuerung brauche ich noch etwas mehr Unterstützung.
Ich finde gerade keine vernünftigen Algorithmen mit denen man die Farbtemperatur von WW+CW genauer bestimmen könnte.
Auch bin ich mir unsicher, wie die Konvertierung von HSV/HSI zu RGBW (welches Weiß?) machbar ist.


Ich sehe auch, dass MQTT eine gute alternative zu bytestrings bietet - damit wäre der Controller auch mit anderen Lösungen außerhalb von fhem einfach zu verbinden

So ein Teil brauche ich später auch.... ;D

Habe momentan aber zu viele Baustellen um unterstützen zu können.
In jedem Fall würde ich für eine MQTT-ANBINDUNG pledieren!

http://forum.fhem.de/index.php/topic,46022.0.html (http://forum.fhem.de/index.php/topic,46022.0.html)
http://www.s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/113-mqtt-basic-esp8266-mqtt-example (http://www.s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/113-mqtt-basic-esp8266-mqtt-example)

Moin,

Den WiFiManager hatte ich testweise auch genutzt. Habe dann aber den Sketch von Andreas Kriwanek als Basis genutzt, da eben auch EEPROM-Anbindung, Webserver, und MQTT recht übersichtlich implementiert ist.

Habe den Webserver und EEPROM-Bereich jetzt für meine rund 12 Sensoren angepasst.

MQTT läuft, FHEM-Anbindung läuft.

Jetzt kommen noch ein paar Sicherheitsfeatures wie Passwortschutz für Web-Zugriff, Passwortschutz für MQTT und ein paar weitere Kleinigkeiten als auch ein Code-Review.

Schätze mal nächstes WE als Beta vorzeigbar.

Hier ein Beispiel-Sketch um HSV und HSL-Daten zu verarbeiten.

http://www.jerome-bernard.com/blog/2013/01/12/rgb-led-strip-controlled-by-an-arduino/ (http://www.jerome-bernard.com/blog/2013/01/12/rgb-led-strip-controlled-by-an-arduino/)


Da auf meiner Agenda ebenfalls LED-Stripe Anbindung steht würde ich im Rahmen meiner Möglichkeiten unterstützen.


Gruss

Andreas

bei den HSV Routinen geht noch was:

das normalisieren der RGB Values ist suboptimal, man verliert viel Gesamthelligkeit.
Besser: die Korrektur in den Segmenten der HSV converters. 0,120,240 konstant. Für Gelb (60°) dann negativ korrigieren auf bspw 33°. Die genauen Werte sind für jede LED spezifisch.

Der HSV converter geht rein integer, float ist nicht notwendig.

Erst danach (HSV zu RGB) Weiß aus RGB rausrechnen (= min(R,G,B)). Dort dann ct (und stripe spezifische Weißkorrektur bei RGB stripe). Danach bei RGB-stripe wieder dazu addieren oder bei einzelnem white auf WW/CW spliten.

vg
joerg

So - ich hab mal noch etwas herumgespielt und bin ziemlich begeistert wie weit die ESP8266 Arduino Lib ist.
- WifiManager ist super einfach zu integrieren und mit einem Basis Konfigurationsportal zu erweitern
- WebUpdateHttpServer ist auch sehr einfach einzubinden für einfache updates via Browser

Zum Thema Farbraum berechnen habe ich noch folgenden Link gefunden:
http://blog.saikoled.com/post/44677718712/how-to-convert-from-hsi-to-rgb-white

Hier wird vorgeschlagen den HSI Farbraum zu nutzen - irgendwie klingt das ziemlich plausibel. Beim herumspielen mit nem Farbpaletten konvertierer (http://colorizer.org/) fande ich HSI (HSL) "logisch". Sprich je pastellartiger die Farbe werden sollte, desto mehr weiss wird beigemischt. Je purer die Farbe werden sollte, desto weniger weiss ist dabei.

Zitat von: herrmannj am 30 Januar 2016, 23:48:04
Erst danach (HSV zu RGB) Weiß aus RGB rausrechnen (= min(R,G,B)). Dort dann ct (und stripe spezifische Weißkorrektur bei RGB stripe). Danach bei RGB-stripe wieder dazu addieren oder bei einzelnem white auf WW/CW spliten.

Ich hinke da bei deiner vorgehensweise etwas hinterher - hast du eine konkrete Formel (oder Codeschnippsel) ? Dann kann ich es vielleicht eher nachvollziehen und selber durchrechnen zum implementieren

Zitat von: AndreasHH am 30 Januar 2016, 23:25:24
Moin,

Den WiFiManager hatte ich testweise auch genutzt. Habe dann aber den Sketch von Andreas Kriwanek als Basis genutzt, da eben auch EEPROM-Anbindung, Webserver, und MQTT recht übersichtlich implementiert ist.

Sicherlich nicht verkehrt - ich greife nur persönlich sehr gerne auf vorhandene libraries zurück - habe die Erfahrung gemacht, dass oftmals die Communities bei solchen Projekten sinnvolle Funktionen hinzufügen bzw. Fehlerquellen eliminieren die einem so direkt nicht aufgefallen wären.

Zitat von: AndreasHH am 30 Januar 2016, 23:25:24
Jetzt kommen noch ein paar Sicherheitsfeatures wie Passwortschutz für Web-Zugriff, Passwortschutz für MQTT und ein paar weitere Kleinigkeiten als auch ein Code-Review.

Die Sicherheitsfeatures fände ich sehr spannend - habe da auch schonmal dran gedacht - vielleicht in einer späteren Firmware Version, sofern die LED Treiber sauber funktionieren

Zitat von: AndreasHH am 30 Januar 2016, 23:25:24
Hier ein Beispiel-Sketch um HSV und HSL-Daten zu verarbeiten.

http://www.jerome-bernard.com/blog/2013/01/12/rgb-led-strip-controlled-by-an-arduino/ (http://www.jerome-bernard.com/blog/2013/01/12/rgb-led-strip-controlled-by-an-arduino/)

HSV zu RGB ist ja soweit "kein Problem" - gibt es massig Codeschnippsel für und sehr gute libraries. Wo es schwieriger wird, ist wenn noch weiss (hier dann noch Warm White und Cold White stripes) dazu kommt.

Moin,

ZitatSicherlich nicht verkehrt - ich greife nur persönlich sehr gerne auf vorhandene libraries zurück - habe die Erfahrung gemacht, dass oftmals die Communities bei solchen Projekten sinnvolle Funktionen hinzufügen bzw. Fehlerquellen eliminieren die einem so direkt nicht aufgefallen wären.

Du hast damit völlig recht, achte bei meiner Auswahl von libraries etc. ebenfalls darauf.

Der Beispiel-Code von Andreas Kriwanek nutzt ausschliesslich die "Standard" - Arduino-Libraries.

Beim WiFi-Manager bin ich mir dessen nicht ganz so sicher.


Wie wäre es mit Arbeitsteilung ?

Du konzentrierst Dich auf die Ansteuerung (Programmierung) der LEDs und die Hardware und ich kümmere mich um den "Rest", egal ob nun der WiFiManager oder mein Vorschlag den Zuschlag bekommt.


Evt. ist ja auch hermannj dabei und unterstützt bei der Programmierung des LED-Bereiches. 


Gruss

Andreas

Ich hab mir das FHEM WifiLight Modul mal etwas genauer angeschaut - so langsam verstehe ich auch was herrmannj in Worten beschrieben hat.
Noch ein paar Gedanken dazu:
Es gibt 4 Kombinationen RGB, RGBWW, RGBCW, oder RGB WW+CW; je nachdem müssten die Farbe anders berechnet werden
- ich denke hier ist der Vorschlag von hermannj gut - wenn weiss vorhanden ist, es rauszurechnen und dann mit ww/cw oder ww+cw hinzuzuaddieren
- Dadurch dass noch extra weisskanäle vorhanden sind brauchen wir wahrscheinlich noch eine Helligkeitskorrektur damit das weiss nicht zu stark/hell wird

Die Einstellungen die ich hieraus ableite sind:
- wie wird der Controller betrieben  (RGB, RGBWW, RGBCW, RGB WW+CW)
- Helligkeitskorrektur (für weisskanäle)
- Farbtemperatur von CW / WW definieren
- Farbkorrektur

Ich denke es ist sinnvoll diese Einstellungen auf dem Controller zu hinterlegen - was meint ihr?

Was für mich noch komplett offen bleibt:
Wie verhalten sich die Farbtemperaturen 2er Lichtquellen - wenn ich nun weiß mit 2700K und weiß mit 5000K habe?
Macht es denn eigentlich Sinn Warmweiße und Kaltweiße Led Streifen gleichzeitig zu benutzen, wenn RGB Leds vorhanden sind? (Mit dem addieren von RGB Farben müsste man ja die Farbtemperatur verschieben können)

Zitat von: AndreasHH am 31 Januar 2016, 02:38:55
Der Beispiel-Code von Andreas Kriwanek nutzt ausschliesslich die "Standard" - Arduino-Libraries.

Beim WiFi-Manager bin ich mir dessen nicht ganz so sicher.

Der Wifi-Manager nutzt nur die Standard Libraries aus dem Arduino esp8266 board. Ich bin echt sehr positiv von dem WifiManager überrascht - auch das es möglich ist bei dem Configurationsportal relativ einfach eigene Variablen zu definieren (z.B. den mqtt broker))

Im Anhang ist der TestSketch den ich verwendet habe - wenige Zeilen durch die es einfach möglich war den WifiManager zu booten bzw. die Firmware dann über nen Browser upzudaten. War gestern nur eine Spielerei  ;)

Zitat von: AndreasHH am 31 Januar 2016, 02:38:55
Wie wäre es mit Arbeitsteilung ?

Du konzentrierst Dich auf die Ansteuerung (Programmierung) der LEDs und die Hardware und ich kümmere mich um den "Rest", egal ob nun der WiFiManager oder mein Vorschlag den Zuschlag bekommt.

Sehr gerne - im Moment ist mein Verständnis von MQTT und FHEM sehr eingeschränkt.
Für das Protokoll/Funktionen dachte ich an folgendes:

- An/Aus/An mit Farbe x (hsv)
- Farbwechsel zu Farbe x (hsv) in Zeit t
- Status (An/Aus, Farbe?)
- Lese/Schreibe Konfiguration (evtl. zusätzlich via WebPortal, wenn man nicht zur Ansteuerung der Leds Wifilight/Fhem nutzt )

---

Nachtrag:

Zum Thema Kombination von Farbtemperaturen habe ich folgendes gefunden (Ab Seite 21 ganz interressant)
http://www.cree.com/~/media/Files/Cree/LED-Components-and-Modules/XLamp/XLamp-Application-Notes/LED_color_mixing.pdf

Auch interressant
http://apps1.eere.energy.gov/buildings/publications/pdfs/ssl/led-color-characteristics-factsheet.pdf

Um weiss zu mischen muss man scheinbar von der Ausgangstemperatur auf den CIE Farbraum umrechnen und dann kann man berechnen welche Farbtemperatur von 2 Quellen entsteht.

Beim Flux (Lichtstärke) bin ich mir nicht so ganz sicher wie man das bei den LED Stripes angeben/annehmen soll - Ideen?

ZitatEvt. ist ja auch hermannj dabei und unterstützt bei der Programmierung des LED-Bereiches.

Yepp, sehr gern. Bin an dem Projekt sehr interessiert. Durch WifiLight bin ich da auch sehr nahe dran. WifiLight macht genau das, aber eben auf fhem Seite. Mir fehlt aktuell die Zeit um das durch zu programmieren. Wenn ich mit Know How helfen darf -> sehr gern!.

ZitatBeim herumspielen mit nem Farbpaletten konvertierer (http://colorizer.org/) fande ich HSI (HSL) "logisch". Sprich je pastellartiger die Farbe werden sollte, desto mehr weiss wird beigemischt. Je purer die Farbe werden sollte, desto weniger weiss ist dabei.

Das gilt genauso für HSV und eigentlich hat sich HSV in dem Bereich auch durchgesetzt. Die Unterschiede zwischen den beiden sind im übrigen graduell. Schau mal hier http://fhem.de/commandref_DE.html#WifiLight_Farbkreis

Zitat
Zitat von: herrmannj am Gestern um 23:48:04

ZitatErst danach (HSV zu RGB) Weiß aus RGB rausrechnen (= min(R,G,B)). Dort dann ct (und stripe spezifische Weißkorrektur bei RGB stripe). Danach bei RGB-stripe wieder dazu addieren oder bei einzelnem white auf WW/CW spliten.

Ich hinke da bei deiner vorgehensweise etwas hinterher - hast du eine konkrete Formel (oder Codeschnippsel) ? Dann kann ich es vielleicht eher nachvollziehen und selber durchrechnen zum implementieren

Gern. Lass mich vorher kurz ausholen:

Folgende Funktionalität braucht es gesamt:

Die Helligkeit über alles muss logarithmisch korrigiert werden. Das macht man am besten zu erst auf dem V Kanal (HSV)
Die gesättigten (Misch-) Farben müssen korrigiert werden. Das geht am besten im HSV->RGB Konverter.
Weiß muss angepasst werden. Das Funktioniert am besten am Schluss. Dort kann man das "ausleiten" und auf WW/CW umrechnen. Das war Deine Frage, ich komm gleich dazu.

Der Konverter HSV->RGB ist eine Kernkomponente. Empfehlung, nimm ihn NICHT aus einer LIB. Das folgende Bild ist ccc von Wikipedia:
(https://upload.wikimedia.org/wikipedia/commons/5/5d/HSV-RGB-comparison.svg)
Wenn Du Dir den Bereich 0°-60° (ROT->GELB) anschaust siehst Du das ROT auf 100% bleibt und GRÜN linear von 0% bis 100% ansteigt. Das gilt analog dann für die anderen 5 Segmente. Eine Primärfarbe ist 0°, eine 100° und die dritte steigt oder fällt.

Jetzt muss man sich den PWM anschauen. Beim ESP hat er 10bit. Ergo hat jedes der 6 Segmente eine "Breite" von 2^PWM. Die Gesamte "Breite" sind also 6*2^PWM (das entspricht 360°).

Auf FW Ebene arbeitet der Converter am effizientesten wenn man ihm in der Metrik (also der PWM Weite) des mc arbeiten läßt. (Arduino = 6*2^8 / ESP =  6*2^10). Deshalb benötigt man eben auch kein float.

Korrektur gesättigter Farben: (ich habs in der Wifilight cmdref eigentlich gut erklärt, daher nur in kurz hier)
Nimm mal 60° (GELB). Da soll ROT und GRÜN gleich stark leuchten. Machts aber nicht - die grüne LED ist meist viel heller. Also darf 60° nicht aus 100% ROT und 100% GRÜN gemischt werden sondern vielleicht 100° ROT und 60° GRÜN.

Das geht am effizientesten indem man (siehe bild) den Bereich von 0° bis 60° (immer in der Metrik des mc) "verlängert" und den Bereich danach um den gleichen Betrag "verkürzt". Anders ausgedrückt. ROT bleibt länger auf 100% und GRÜN steigt weniger steil an.

Jetzt zum Weiß:
Wenn ich einen RGB Wert habe (der ja am Ausgang des HSV2RGB rauskommt) dann ist der Anteil weißen Lichtes genau die kleinste einzelne Primärfarbe.

Beispiel (Wertebereich 0..100 zur Einfachheit):
RGB:  50,80,100.
Rot 50 ist die kleinste Zahl. Also besteht diese Mischfarbe zu 50% aus Weiß. Raus rechnen aus ALLEN Kanälen macht RGB 0,30,50 PLUS 50 Weiß.

Das kann jetzt einzeln weiterverarbeitet werden.

vg
joerg

Nchtrag: rein technisch fällt Weiß schon vorher raus: im HSV2GB nimmt man den Anteil S (HSV) ja schon raus und addiert ihn am Ausgang wieder dazu.

Beispiel:

bei HSV 0,50,100 leuchten alle Kanäle mit 50% (wegen S=50). Am Ausgang eines HSV2RGB nach obigem Beispiel würde man auf die 3 RGB Kanäle 50% aufaddieren. Das würde man in der Praxis bei HSV2RGBW also schon dort aus-leiten. Das Beispiel im vorherigen Post zeigt die Theorie dahinter

vg
joerg

Danke dir für die Ausführung - das hat wirklich sehr geholfen und ich blicke auch was du meinst - ich schreib kurz meine Gedanken dazu auf um zu verstehen ob das die richtige Richtung ist.

Zitat von: herrmannj am 31 Januar 2016, 12:37:25
Die Helligkeit über alles muss logarithmisch korrigiert werden. Das macht man am besten zu erst auf dem V Kanal (HSV)

Hier gibt es "nur" den Wertebereich von 0 - 100 oder soll dies auch den 10bit vom PWM entsprechen?

Zitat von: herrmannj am 31 Januar 2016, 12:37:25
Auf FW Ebene arbeitet der Converter am effizientesten wenn man ihm in der Metrik (also der PWM Weite) des mc arbeiten läßt. (Arduino = 6*2^8 / ESP =  6*2^10). Deshalb benötigt man eben auch kein float.

Also haben wir statt 360 einen Wertebereich von 0 - ((6*2^10)-1)
- für die Integration und das sparen von float Berechnung auf dem MC ist es dann auch besser diesen Wertebereich im Protokoll direkt zu übertragen - richtig?

Zitat von: herrmannj am 31 Januar 2016, 12:37:25
Das geht am effizientesten indem man (siehe bild) den Bereich von 0° bis 60° (immer in der Metrik des mc) "verlängert" und den Bereich danach um den gleichen Betrag "verkürzt". Anders ausgedrückt. ROT bleibt länger auf 100% und GRÜN steigt weniger steil an.

Also dementsprechend eine LookUp Table (oder Berechnung) die für den eigentlich INT Wert ( 0 - ((6*2^10)-1) ) einen "verschobenen" intwert im zurück gibt

---

Nachtrag:
Ich hab mir das noch etwas durch den Kopf gehen lassen, warum benutzen wird die Metrik des MC PWMs 8bit/10bit?
Wir haben ja für 10bit/8bit keinen linearen Anstieg sondern logarithmisch. Das Versuchen wir ja nun mit der Verschiebung auszugleichen - welchen Vorteil haben 1024 Werte gegenüber den 255 hier? Ist es so merklich bei Leds?

Zitat

ZitatDie Helligkeit über alles muss logarithmisch korrigiert werden. Das macht man am besten zu erst auf dem V Kanal (HSV)

Hier gibt es "nur" den Wertebereich von 0 - 100 oder soll dies auch den 10bit vom PWM entsprechen?

Ich schlage vor das am "Eingang" einmalig von 0..100 auf die Metrik des mc umzurechnen und alles weitere (die transitions) dann in der Metrik des mc zu berechnen. Am Eingang 0.100 weil das ja der HSV Norm entspricht. Wenn danach in mc umgerechnet wird ist die fw portabel für verschiedene mc.

Zitat- für die Integration und das sparen von float Berechnung auf dem MC ist es dann auch besser diesen Wertebereich im Protokoll direkt zu übertragen - richtig?

Ich denke das ist unabhängig. Im Protokoll würde ich 0..360 lassen (siehe oben)

ZitatAlso dementsprechend eine LookUp Table (oder Berechnung) die für den eigentlich INT Wert ( 0 - ((6*2^10)-1) ) einen "verschobenen" intwert im zurück gibt

loopkup mach ich das in WifiLight weil ja viele verschiedene Controller unterstützt werden. In der fw würde ich das direkt in den HSV converter nehmen weil dann weichere Übergänge möglich sind. Unten mach ich ein Beispiel.

ZitatIch hab mir das noch etwas durch den Kopf gehen lassen, warum benutzen wird die Metrik des MC PWMs 8bit/10bit?
Wir haben ja für 10bit/8bit keinen linearen Anstieg sondern logarithmisch. Das Versuchen wir ja nun mit der Verschiebung auszugleichen - welchen Vorteil haben 1024 Werte gegenüber den 255 hier? Ist es so merklich bei Leds?

Das sind zwei verschiedene Sachen.

* Die logarithmische Korrektur der gesamten Helligkeit ist erforderlich weil der Seheindruck des Menschen so ist.
* Die Korrektur der gesättigten Farben ist erforderlich weil der Wirkungsgrad der einzelnen LEDs unterschiedlich ist. Also 100% Rot ergibt weniger Lumen als 100% Grün.

Natürlich kann man auch alles in 255 (8bit) rechnen. Dem converter und dem mc ist es in Bezug auf die Geschwindigkeit aber egal - also kann man auch gleich in der PWM Weite rechnen. Richtig ist das die logarithmische Korrektur den maximalen Bereich verringert. Aus 8bit werden dann noch ~170 (plus minus) Werte.

Der Vorschlag zum converter: ich rechne am Beispiel mit 8 bit. Die Berechnungen sind bei 10 oder 12 bit die gleichen - nur die Konstanten ändern sich.

Bezogen auf die obige Grafik ist ein Vollkreis (max Helligkeit) also 255 * 6 = 1530. Am "Eingang" also einmalig Dreissatz. 180° = 765.

Die 1530 bestehen aus 6 Segmenten. Im ersten Segment ist ROT bei 100% (=255), Blau 0% und Grün kann aus einem Dreissatz berechnet werden (erst Multiplizieren dann Dividieren um kein float zu benötigen).

Würde man jedes Segment gleich berechnen hätte das erste Segment den Bereich von 0..255, das zweite den Bereich 256..511.

Im ersten steigt Grün linear an, im zweiten wird Rot vermindert.

Die Farbkorrektur setzt jetzt so an:
Das erste Segment bekommt (zum Beispiel) den Bereich 0..350, das zweite 351..511.  Im ersten Segment steigt Grün jetzt (Dreisatz) linear an, erreicht aber erst bei 350 den Wert 255.

Beispiel: am Eingang steht jetzt Gelb -> 60°.
60*1530/360 ergibt in device Metric 255.
Im converter liegt der Bereich im ersten Segment (0..350) daher wird Grün berechnet: 255*255/350 = 185. (overflowgefahr beim multiplizieren beachten)

Ein 60° Eingang (Gelb) wird also, bereits farb-korrigiert, zu RGB 255,185,0. Das ist das gewünschte Ergebnis. ROT soll zu 100% leuchten, Grün aber weniger weil die grüne LED ja von sich aus heller ist. Im Ergebnis kommt jetzt also GELB raus.

Wenn das Gelb noch einen Grünstich hat muss man Grün verringern indem man das erste Segment vergrößern (zB 0..370) und das zweite im gleichen Zugang verkleinern (371..511). (Ergebnis wäre  so 255*255/370 = 175  -> RGB 255,175,0 -> Grünanteil bei GELB weiter verringert.)

Das funktioniert ohne lookup und mit 16- oder 32bit (ke nach PWM) Arithmetik.

Die logarithmische Korrektur der Gesamthelligkeit funktioniert über eine lookup am schnellsten.

vg
joerg

Hallo Joerg,

ich danke dir für deine Geduld und ausführlichen Erklärungen!

Den Abend habe ich über die Punkte nochmal etwas nachgedacht, mit der Hand berechnet und testcode geschrieben.
Ein paar Fragen sind dabei aufgekommen/geblieben

Zitat von: herrmannj am 31 Januar 2016, 17:09:31
* Die Korrektur der gesättigten Farben ist erforderlich weil der Wirkungsgrad der einzelnen LEDs unterschiedlich ist. Also 100% Rot ergibt weniger Lumen als 100% Grün.

Soweit verständlich - auch mit deinem Rechenbeispiel. Dazu aber die Frage: wäre es nicht konsequenter, die maximalen Werte von Rot/Grün/Blau zu beschränken? So dass die Lumen äquivalent sind um Helligkeitsunterschiede zu vermeiden?
z.B. Rot maximal 90%, Grün maximal 65%, BLAU maximal 100%

Zitat von: herrmannj am 31 Januar 2016, 17:09:31
Richtig ist das die logarithmische Korrektur den maximalen Bereich verringert. Aus 8bit werden dann noch ~170 (plus minus) Werte.

Wenn es um die Sättigung geht wollte ich mir es ersparen 1024 Werte im progmem zu speicher, ich denke 256 würden auch reichen. Andere Ideen um die lookup table nicht unnötig groß werden zu lassen? Ich habe grob in Erinnerung das du eine Formel zur Berechnung hattest?

Zitat von: herrmannj am 31 Januar 2016, 17:09:31
Die Farbkorrektur setzt jetzt so an:
Das erste Segment bekommt (zum Beispiel) den Bereich 0..350, das zweite 351..511.  Im ersten Segment steigt Grün jetzt (Dreisatz) linear an, erreicht aber erst bei 350 den Wert 255.

Beispiel: am Eingang steht jetzt Gelb -> 60°.
60*1530/360 ergibt in device Metric 255.
Im converter liegt der Bereich im ersten Segment (0..350) daher wird Grün berechnet: 255*255/350 = 185. (overflowgefahr beim multiplizieren beachten)

Ein 60° Eingang (Gelb) wird also, bereits farb-korrigiert, zu RGB 255,185,0. Das ist das gewünschte Ergebnis. ROT soll zu 100% leuchten, Grün aber weniger weil die grüne LED ja von sich aus heller ist. Im Ergebnis kommt jetzt also GELB raus.

Wenn das Gelb noch einen Grünstich hat muss man Grün verringern indem man das erste Segment vergrößern (zB 0..370) und das zweite im gleichen Zugang verkleinern (371..511). (Ergebnis wäre  so 255*255/370 = 175  -> RGB 255,175,0 -> Grünanteil bei GELB weiter verringert.)

Das Beispiel kann ich gut nachzollviehen - jetzt kommt die Frage aller Fragen, wie geht es im 2 Quadrant (60-120 Grad) weiter.

Das hier war mist:
Ich würde jetzt Grün weiterhin linear hochlaufen lassen....
Meine Berechnung wäre nun wie folgt:
Winkel in mc PWM Weite
85*1530/360 = 361;
Davon ziehe ich den Quadranten mal mc weite ab:
361 - (1*255) = 106;
Und Berechne den neuen Wert
106*255/(370-255) = 235

Falls dieser über 255 ist, dann wird er als 255 festgesetzt

Was für mich offen bleibt:
1) Wie gehe ich hier mit Rot um?
2) Wenn ich nun auch bei Rot eine verschiebung habe, wie berechne ich die dann mit ein? müsste ROT dann im 100% Bereich auch schon ab/zunehmen?

---

Nachtrag:

Wie ist es so schön - einfach mal ne Nacht drüber schlafen und es gibt neue Erkenntnisse  ;)
Ich versteh jetzt die Verschiebung von Gelb, Cyan und Magenta - der Maximalpunkt von der jeweiligen steigenden Farbe wird nach links/rechts verschoben.

Was ich noch nicht ganz verstehe: wird bei Rot, Grün, Blau der Minimalpunkt verschoben (weiter links/rechts) oder wird der Maximalpunkt nach links/rechts verschoben?

---

Nachtrag 2:
So nochmals bischen nachgedacht und nachgerechnet:
Statt 6 Abschnitte zu haben, macht es zur Berechnung Sinn nur 3 Abschnitt heranzuziehen. In jedem dieser 3 Abschnitte wird von einem Farbpärchen eine Farbe addiert bzw. weg genommen. Wenn wir jetzt diesen Prozess auf 120Grad statt auf 60Grad ausdehnen und die verschobenen Gradzahlen als Grundlage nehmen, dann lässt sich das einfach berechnen.

Beispiel
Rot/Grün
p = 256 (mc PWM-Weite)

Verschiebung von Gelb um 20Grad nach Rot
Korrigierter Wertebereich:
k1 = p+((20/60) *p) = 256+((20/60)*256) = 341

Grün nimmt von 0 - 120 Grad zu und wird so berechnet:
mcHue = Hue*(p*6)/360 = vereinfacht Hue*p/60


Grün = min((mcHue *p/ k1), p)
Beispiel bei  Hue = 60:
Grün = min((256 * 256/341), 256) = 192

Beispiel bei Hue = 90
Grün = min((384*256)/ 341, 256) = min(280, 256) = 256

Rot lässt sich wie folgt berechnen
Rot = min((2*p - mcHue)/k2, p)

Ich bin mir gerade nur nicht sicher wie effizient diese Berechnung ist?

Dann kommt noch eine andere Frage: wenn ich weniger Grün im Gelb habe, wie sollte die Verschiebung von Gelb in Grad aussehen:
z.B. -20grad oder +20grad. Bevor ich es anders herum wie in wifilight implementiere

---

Nachtrag 3

Ich bin mir gerade doch nicht sicher ob diese Implementierung mit der Verschiebung übereinstimmt.

Ich hab mir gerade nochmal die fastled Library Implementierung angeschaut und im Wiki dort auch noch was ganz spannendes gefunden:
https://github.com/FastLED/FastLED/wiki/FastLED-HSV-Colors

Moin,

wie es aussieht geht es vorran,

ich könnte gut etwas input brauchen um die Grundprogrammierung voran zu treiben.

Speziell Anforderungen an die Speicherung von Werten im EEPROM (Groesse, Variablen-Typ, Bezeichnung, Korrekturwerte etc.) ?

Wie stellt Ihr euch die Grundfunktionen der Web-Oberfläche vor?

Im 1. Schritt (Alpha-Version) würde ich mich gern auf die Grundfunktionen beschränken.
- Grundkonfiguration (WLAN, MQTT-Anbindung, WiFiLight etc. , Konfiguration RGB mit Korrekturwerten)
- Grundlegende Sicherheitsmechanismen (Authentifizierung sowohl für Webserver als auch für MQTT) jeweils optional.
- Speicherung des aktuellen Status im EEPROM (Spannung weg wg. Lichtschalter off etc., like HUE)

Gruss

Andreas

Hi Andreas,

ein Moin aus der Hansestadt zurück :)

bzgl fw ist mrpj im lead. Allerdings habe ich seine edits jetzt erst  gesehen. Besser neuen Beitrag, sonst sieht man das nicht.

FastLED ist mMn die beste lib. Leider auch relativ komplex. Ich hatte die mir mal angeschaut dann aber Abstand davon genommen weil ich annehme das eine Eigenentwicklung der benötigten Teile schneller wäre als Einarbeitung und Anpassung.

Der Rainbow mode macht Sinn (Gelb ist tatsächlich unfassbar schmal). Die Kehrseite ist das andere LEDs das typischerweise nicht so machen (Spektrum) und es daher zu Farb- Unterschieden kommt wenn man "normale" LEDs gleichzeitig und synchron ansteuert. Das wiederum ist durchaus gebräuchlich.

Farbkorrektur 6 vs 3 Segmente. Wenn Du nur 3 Korrekturpunkte nimmst (CMY) stimmen unter bestimmten Umständen die Primärfarben nicht mehr. Beispiel: Magenta und Gelb werden jeweils um -20° korrigiert. Dann ist das komplette Segment verschoben und auch ROT wird um -20° korrigiert - wird deutlich LILA. Deshalb verwende ich 6 Punkte und habe den Bereich auf +/- 29° begrenzt. Bei Gelb reichen -29 gerade eben (bei den Leuchtmitteln die ich in der Hand hatte) wenn GRÜN sehr viel heller ist als ROT. Man kann halt nur einen Tod sterben. Mehr als 29° geht nicht weil man sich die Punkte treffen (ROT + 30° und GELB -30° sind identisch).

Zitat- Grundkonfiguration (WLAN, MQTT-Anbindung, WiFiLight etc. , Konfiguration RGB mit Korrekturwerten)

WifiLight würde keinen Sinn mehr machen wenn der controller transitions etc selber kann. Dann bräuchte man nur noch die Oberfläche. Ich würde aber bei Bedarf gern ein dafür angepasstes Modul zur Verfügung stellen.

vg
joerg

Moin,

Zitatein Moin aus der Hansestadt zurück :)

Ich bin begeistert!
Ich mag kurze Wege.

Dann kann man ja evt. die Entwicklung dieses Projektes auch kombiniert voranbringen (Web, vor Ort)

Ich kann folgendes als Spielwiese anbieten:
- Haus mit rund 350qm Nutzfläche + Garten.
- Gästezimmer
- reaktivierte Elektronik-Ausstattung (lag rund 20 Jahre brach, teilweise aktualsiert)

Meine bisherigen Kenntnisse liegen in Webprogrammierung, SQL, FHEM seit 2010, Elektronik seit 1988.

Ich habe bisher allerdings null Schimmer im Bereich Programmierung von LED-Stripes im aktuellen Kontext. Dieses würde ich gerne Euch überlassen.

Daher meine Fragestellung bzgl. zu reservierender Werte im EEPROM-Bereich.

Vielleicht wäre ein persönliches Treffen (z.B. bei mir) zwecks Brainstorming und testing hilfreich.
Habe mir jetzt enstspr. MosFets bestellt um die Hardware abbilden zu können.

Habe aktuell unendlich viele Ideen bzgl. Steuerung, WEB-Oberfläche, etc., daher auch meine Anfrage nach zu berücksichtigen Einstellungen.

Gruss

Andreas

So jetzt wollte ich gerade meinen Post abschicken, dann ging das Forum nicht  ???

Erstmal ein Hallo in die Runde zurück - ich antworte mal Andreas und danach in nem seperatn Post noch Joerg

Zitat von: AndreasHH am 01 Februar 2016, 21:52:44
Speziell Anforderungen an die Speicherung von Werten im EEPROM (Groesse, Variablen-Typ, Bezeichnung, Korrekturwerte etc.) ?

Der esp8266 kann auf spiffs zurück greifen - die Konfiguration kann dann bequem per datei gespeichert werden (z.B. json).
Erspart das arbeiten mit eeprom. Die Lookup Tables für die Gamma Korrektur würde ich im progmem lassen.

Zitat von: AndreasHH am 01 Februar 2016, 21:52:44
Wie stellt Ihr euch die Grundfunktionen der Web-Oberfläche vor?

Die WifiManager lib bietet im Grunde alle Funktionen zur "Erste Konfigurations" Oberfläche an.
https://github.com/tzapu/WiFiManager (https://github.com/tzapu/WiFiManager)

Er ermöglicht es auch eigene Parameter für die Konfiguration zu definieren, siehe:
https://github.com/tzapu/WiFiManager#custom-parameters
Und als InoSketch
siehe Github (https://github.com/tzapu/WiFiManager/blob/master/examples/AutoConnectWithFSParameters/AutoConnectWithFSParameters.ino)

Mir persönlich reicht es für das Setup. Der esp8266 scannt nach APS, man connected sich und gibt dabei die Parameter für MQTT an.
Es ist scheinbar auch möglich, dem ganzen eine statische ip bzw. eine dns name zu verpassen. (Ist doch angenehm statt device IP, später nen DNS name nutzen zu können)

Zitat von: AndreasHH am 01 Februar 2016, 21:52:44
- Grundkonfiguration (WLAN, MQTT-Anbindung, WiFiLight etc. , Konfiguration RGB mit Korrekturwerten)

Grundkonfiguration wie oben beschrieben => WifiManager
Sobald der ESP ins heimnetz angebunden ist, finde ich es gut, wenn die Konfiguration via mqtt/fhem erfolgt.
Am wichtigsten wäre mir hier, wenn die Kommunikation (API) zw. FHEM/MQTT/ESP definiert wird bevor eine Implementierung erfolgt.
Zum Thema API/Kommunikation noch etwas weiter unten

Eventuell eine Webpage mit:

• Status (ip,dns,gateway,mqtt, ???)
• Einstelleung ändern (IP, DNS, Gateway, MQTT etc.)
• reset -> beim nächsten Start wieder das Konfigurationsportal vom WifiManager

Optional (mit wenig Priorität, da dies ja durch die wifilight/mqtt -> esp api geschehen soll)

• Konfiguration des Modus: RGB, RGB+Warm Weiss, RGB+Kalt Weiss, WarmWeiss + Kaltweiss, (RGB + WarmWeiss + KaltWeiss)
• Konfiguration von Weiss Farbtemperaturen
• Konfiguration von Farbkorrektur

Zitat von: AndreasHH am 01 Februar 2016, 21:52:44
- Grundlegende Sicherheitsmechanismen (Authentifizierung sowohl für Webserver als auch für MQTT) jeweils optional.

Wichtig zu sicher ist die OTA webseite des esp - damit nicht jemand unbefugt andere firmware aufspielen kann. Geht via der vorhanden Arduino ESP OTA Lib  (https://github.com/esp8266/Arduino/blob/master/doc/ota_updates/ota_updates.md#web-browser)

Bei MQTT kenne ich mich noch nicht aus - aber wenn es möglich ist die Kommunikation ohne größeren Aufwand (Rechenkosten) zu sichern, dann immer gerne. Aber SSL ist nicht möglich, somit sind eh jegliche Methoden umsonst, denn wenn jemand im Wlan ist, kann er die Pakete mitschneiden und Passwort/Token/Challenge für einen replay nutzen

Zitat von: AndreasHH am 01 Februar 2016, 21:52:44
- Speicherung des aktuellen Status im EEPROM (Spannung weg wg. Lichtschalter off etc., like HUE)

Den aktuellen Status nach jedem command zu speichern würde zu viel Schreibzyklen vom eprom/spiffs verbrauchen. Einziger sinnvoller Außweg ist es, festzustellen ob noch die Versorgungsspannung anliegt, bevor der esp ohne Strom ist. Aber im Moment ist der ADC des esp nicht verbunden. Lässt sich aber mit etwas draht und 2 Wiederstände noch nachmodden falls es wichtig ist.

Ansonsten gibt es 2 Möglichkeiten
-> Via Configuration eine Standard Einstellung setzen -> Da muss mal getestet werden wie der esp auf strom an/aus reagiert
-> Nach dem booten vom ESP und wenn er mit dem Wifi connected ist den letzten Wert vom Server abfragen




API/Kommunikation
Ich hatte bisher folgendes für die Kommunikation im Kopf - Erweiterungen/Vorschläge gerne Willkommen

HSVColor(H,S,V,K,T)
T in Sekunden gibt die Zeitspanne für den Übergang zur neuen Farbe an
Bei T=0 wird die Farbe sofort gesetzt
K = Farbtemperatur von Weiss
Der Controller nutzt als Anfangsfarbe die aktuelle Farbe

HSVColor(H,S,V,K,H',S',V',K',T)
Wie davor - nur diesmal fadet der MC von HSV zu H'S'V' über T (notwendig)

RGBColor(R,G,B,W,K, T)
RGBW Farbe , W Optional
T=0 kein Übergang, sondern Farbe direkt
Falls T>0, wird im MC der HSV Wert berechnet und dann der Übergang erzeugt

RGBColor(R,G,B,W,K,R',G',B',W',K,'T)
Wie zuvor beschrieben

effect(effectname)
Startet einen vordefinierten Effekt (z.B. Sonnenaufgang, Sonnenuntergang, Kaminfeuer, Disco, Farbwechsel)

cancleTransition
Unterbricht einen Farbwechsel/Effekt

setSettings
Einstellungen für die Farbkorrektur übertragen - welche das sind muss noch ergänzt werden

status
gibt die aktuellen StatusWerte zurück (Farbe)

info
gibt Informationen über Konfiguration etc. Preis


Ich überlege auch, den HSI Farbraum mit aufzunehmen - die Funktionen brauchen jeweils kaum noch mehr Platz, wenn ich die Berechnung noch auf 32/8bit Integer Mathematik umrechnen kann, dann hat es auch keine Performance einbußen

Zitat von: AndreasHH am 02 Februar 2016, 00:00:07
Dann kann man ja evt. die Entwicklung dieses Projektes auch kombiniert voranbringen (Web, vor Ort)

Ich nutze für gemeinsame Projekte immer gerne Github - dort lassen sich die ToDos/Informationen extrahiert in nem WikiSchreiben. Sobald vorzeigbarer/alpha Code vorhanden ist, schieb ich ihn mal hoch. Dann können wir auf unterschiedlichen Branches an der Firmware noch weiter arbeiten.

Generell würde ich hier gerne die LED Library getrennt vom ESP8266 Code halten. Änderungen können somit getrennt nachvollzogen werden

Zitat von: AndreasHH am 02 Februar 2016, 00:00:07
Habe mir jetzt enstspr. MosFets bestellt um die Hardware abbilden zu können.

Wie im Dezember angemerkt, habe ich 5 Platinen (inkl. aller Bauteile) über und geb die zum Selbstkostenpreis (zw. 6-8 Euro) gerne weiter. Leider fehlen noch die 3Pin Terminals und dann kann ichs gerne an interressierte rauschicken

Zitat von: AndreasHH am 02 Februar 2016, 00:00:07
Habe aktuell unendlich viele Ideen bzgl. Steuerung, WEB-Oberfläche, etc., daher auch meine Anfrage nach zu berücksichtigen Einstellungen.

Schreib doch mal alles auf - je mehr Input umso besser - auch gerne Kritik/Vorschläge/Wünsche

Hallo Joerg

Zitat von: herrmannj am 01 Februar 2016, 22:46:07
bzgl fw ist mrpj im lead. Allerdings habe ich seine edits jetzt erst  gesehen. Besser neuen Beitrag, sonst sieht man das nicht.

Ich gelobe Besserung  ::) ;)

Zitat von: herrmannj am 01 Februar 2016, 22:46:07
FastLED ist mMn die beste lib. Leider auch relativ komplex. Ich hatte die mir mal angeschaut dann aber Abstand davon genommen weil ich annehme das eine Eigenentwicklung der benötigten Teile schneller wäre als Einarbeitung und Anpassung.

Da hast du Recht - ich habe es mir nur angeschaut um unnötige doppelte Arbeit zu vermeiden.

Zitat von: herrmannj am 01 Februar 2016, 22:46:07
Der Rainbow mode macht Sinn (Gelb ist tatsächlich unfassbar schmal). Die Kehrseite ist das andere LEDs das typischerweise nicht so machen (Spektrum) und es daher zu Farb- Unterschieden kommt wenn man "normale" LEDs gleichzeitig und synchron ansteuert. Das wiederum ist durchaus gebräuchlich.

Was meinst du mit andere LEDs? Displays?

Zitat von: herrmannj am 01 Februar 2016, 22:46:07
Farbkorrektur 6 vs 3 Segmente. Wenn Du nur 3 Korrekturpunkte nimmst (CMY) stimmen unter bestimmten Umständen die Primärfarben nicht mehr. Beispiel: Magenta und Gelb werden jeweils um -20° korrigiert. Dann ist das komplette Segment verschoben und auch ROT wird um -20° korrigiert - wird deutlich LILA. Deshalb verwende ich 6 Punkte und habe den Bereich auf +/- 29° begrenzt. Bei Gelb reichen -29 gerade eben (bei den Leuchtmitteln die ich in der Hand hatte) wenn GRÜN sehr viel heller ist als ROT. Man kann halt nur einen Tod sterben. Mehr als 29° geht nicht weil man sich die Punkte treffen (ROT + 30° und GELB -30° sind identisch).

Ich musste später feststellen, dass die Idee mit den 3 Sektoren im Grunde dem HSV2RGB "spektrun" von Fastled entspricht Link (https://camo.githubusercontent.com/18d2bd686a7b587b382758b57575bdfd212e2ac6/68747470733a2f2f7261772e6769746875622e636f6d2f466173744c45442f466173744c45442f67682d70616765732f696d616765732f4853562d737065637472756d2d776974682d646573632e6a7067)
Mit einer Anpassung der Helligkeit der individuellen R,G,B Werte z.B. R=1, G=0.6, B=0.7 kann man ja auch auf gewissen Maße das ausgleichen.


Ich versuche aber immernoch die Berechnungen von dir zu verstehen. Ich habe mal in nem Bild 2 geraden eingezeichnet und würde gerne Wissen, welchen Werten die Steigung 1 bzw. 2 entspricht? 
(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45528;image)
Ist 1)  GELB +30° und 2) GELB -30°? Oder andersherum?

Wie verhält sich ROT bei +/- 29° - im 6 und 1 Quadrant ist es doch auf maximum - wie kann ich dort also den Rotanteil verschieben?
Eventuell kannst du mir ja kurz die Gerade von Rot und Grün bei jeweils ROT+/- 29° und GELB +/- 29° in einer Grafik skizzieren?

Auch von mir ein Moin!

wenn ich euch so zuhöre, dann freue ich mich schon auf das fertige Produkt!
Ich lese immer mit Spannung wie viele Möglichkeiten es gibt eine LED anzusteuern.... ;D
Habt ihr denn auch vor ein PCB zu erstellen?


Viel Erfolg weiterhin.....

Moin

Zitat von: Pf@nne am 02 Februar 2016, 06:07:27
Habt ihr denn auch vor ein PCB zu erstellen?

Schon geschehen  ;D
http://forum.fhem.de/index.php/topic,34464.msg368845.html#msg368845
bzw. auf Github die Dateien
https://github.com/patrickjahns/esp_rgbww_controller

Da der Ursprüngliche Thread nicht von mir war, sondern ich es nur gekapert hatte, ist es wahrscheinlich Untergegangen.
Ich werde die Woche nochmal einen seperate Thread aufmachen - eventuell in Kombination mit einer Sammelbestellung für weitere Platinen

Super, dann kann es ja gleich losgehen.....

Ich wäre auch an einer Sammelbestellung interessiert...... ;D

Ich auch

Gesendet von meinem GT-N7100 mit Tapatalk

Ich hätte Interesse an 3 bis 5 Platinen
Möchte mein Wohnzimmer fachgerecht "iluminieren"  8)

Zitat von: mrpj am 02 Februar 2016, 11:05:32
Ich werde die Woche nochmal einen seperate Thread aufmachen - eventuell in Kombination mit einer Sammelbestellung für weitere Platinen

;D solche Sätze sind hier immer sehr gerne gelesen.....der letzte hat eine mittelschwere Lawine ausgelöst....  ;D

Ich möchte auch diverse sachen illuminieren, bin daher schon jetzt begeistert....

Hi mrpj

für die API würde ich statt HSV HSVK empfehlen, zusätzlich die Kelvins für weiß.

Mein Zeichenkünste sind sichtlich noch ausbaufähig, doch so (in etwa  ;) ) sieht es aus wenn GELB um -29° korrigiert wird:
(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45572)

Die Rechnung sieht jetzt so aus wenn man 60° "reinkippt, der PWM eine Breite von von 8Bit hat:

Gesamter Farbkreis (0..360) in device umrechnen: 6 * 2^8  = 1536.
1° in entspricht in device: 1536 / 360 * 1 -> 4,266..
Sektor 1 (rot->gelb) ohne korrektur: 0..255

Jetzt korrigieren: (bei negativem Winkel den Sektor "verlängern"). Der Sektor ist nicht mehr 60° sonder 60°+29° = 89° lang.
89° entsprechen 1536 / 360 * 89 -> 379,733 "device Einheiten"
Umstellen (erst multiplizieren dann dividieren damit kein float benötigt wird):
89 * 1536 / 360 -> 379,733 -> als Integer 379.

Im(!) Converter wird jetzt alles von 0..379 als Sektor 1 betrachtet. ROT ist immer 100% und GRÜN steigt linear an.
Der Sektor 2 muss um den Betrag der bei 1 "zu viel" ist vermindert werden. Er "wäre" von 256..511 und ist jetzt von 380..511.

Jetzt zur Rechnung:

(input 60° umrechnen in device, siehe oben. Ergibt 255)

// input * 2^PWM / 360
deviceHue = input * 1536 / 360;

// Sektor finden:

if (deviceHue < 380) { // 0..380 ist der korrigierte erste Sektor
  siehe unten
  exit;
}
if (deviceHue < 512) { // 380..512 ist der korrigierte zweite Sektor
  siehe unten
  exit;
}
usw,

Der input wurde für 60° auf 255 berechnet. Ergo sind wir im ersten if - dem Sektor 1.

R = 2^PWM // ROT ist 100% im ersten Sektor
B = 0 // BLAU ist 0 im ersten Sektor.

Grün:
deviceHue 0 entspricht GRÜN 0
deviceHue 379 entspricht 100% -> 2^PWM -> 255

Dreisatz:
2^PWM / 379 * deviceHue -> 255 / 379 * 255 = 171.
Umstellen
deviceHue * 2^PWM / 379 -> 255 * 255 / 379 = 171

Für 60° mit Korrektur -29°:
R = 255
G = 171
B = 000

Lässt sich so geradlinig für jeden Sektor durchrechnen.

Passt ?

vg
joerg

Hallo zusammen,

Joerg danke dir für die Beschreibung - solangsam habe ich verstanden was verschoben wird bei der Korrektur die du anwendest.
Danke dir für das Bild - es hat mir geholfen beim verstehen, ich bin doch eben manchmal nen Mensch der sowas sehen/zeichnen muss.Dann gehts schnell mit dem verstehen ;-)

Ich war mir bei vollen Farben noch nicht ganz sicher - deshalb hab ich mal kurz blau -30Grad eingezeichnet.

Nach deinen Berechnungen erweitere ich nun den 4 Bereich und verkleinere den 5 Bereich richtig?
(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45578;image)


Nachdem ich mir gestern und heute noch einiges zu den Farbbereichen HSV\HSB, HSI, HSL(Lumosity), HSL(Lightness) angelesen habe, möchte ich noch einen genannten Einwand aufgreifen:

Gelb ist theoretisch doppelt so hell wie Grün und Rot (in diesem Modell). Ich bin mir gerade nicht sicher, wie man das in der Berechnung von dir korrigieren kann.
Mit den 3 Sektoren zum berechnen, könnte man das ausgleichen:
Gelb besteht dann aus 100% Farbwert Grün und 100% Farbwert Rot, Aber nur aus 50% Helligkeit Rot und 50% Helligkeit Grün
(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45576;image)

Eine Verschiebung der Farbbereiche ist wie du es vorgeschlagen hast immernoch möglich:

(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45580;image)

Hier hat Gelb mehr Rot und weniger Grün. An sich liegt der 50% Punkt im Wertebereich des 2 Quadranten, aber der erste Quadrant erstreckt sich dann von 0-90 Grad und der 2Quadrant von 91-120

Was hälst du von dieser Berechnung?

---

zum Thema Sammelbestellung:
Wenn es soweit ist, starte ich einen seperaten Thread mit allen Informationen über das Projekt und dort lässt sich das ganze getrennt organisieren.
Um die Übersichtlichkeit zu bewahren, bitte ich euch, diesen Thread nicht weiter für Sammelbestellungsanfragen zu nutzen. Bitte wartet bis es in einem getrennten Topic besprochen werden kann

Sieht jut aus.

Die Rechnung bei den Primärfarben ist wirklich genau gleich - da braucht man das aber nur eingeschränkt.

Zu der anderen Variante: ich hab da auch mal mit rumgespielt. Hat mich aber nicht ganz überzeugt. Aber ich ich bin da auch nicht das Maß aller Dinge - warum nicht. Die Berechnung ist ja im Prinzip die gleiche nur die Konstanten sind andere.

Vielleicht ist es eine gute Idee beide Varianten anzubieten und der user kann "sein" Modell wählen. Ich schätze den zusätzlichen Code auf einige dutzend Zeilen und Speicher ist bei den mc ja eigentlich kein Problem mehr.

Unter Umständen könntest Du auch das dritte Modell (die Faktoren auf R,G,B) mit anbieten - rechnerisch ist das ja einfachste der Modelle.

Im Übrigen ist das auch schon echt abgefahren. Mir ist kein Heim LED Controller bekannt der individuelle Farbkorrekturen anbietet (Eigentlich auch kein anderer. Aber ich kenn ja auch nich alle). Zusätzlich noch das Farbmix model zur Auswahl ist echt crazy shity stuff.  8)

Hat echt Potential das Projekt :)

vg
joerg

... dann könnte man evtl später auch "Rainbow" ergänzen wenn der Sommer um ist  ;D

Hallo Joerg,

ich bin dir echt dankbar für den Austausch über die Farbmodelle und Berechnungen!

Zitat von: herrmannj am 02 Februar 2016, 23:27:59
Vielleicht ist es eine gute Idee beide Varianten anzubieten und der user kann "sein" Modell wählen. Ich schätze den zusätzlichen Code auf einige dutzend Zeilen und Speicher ist bei den mc ja eigentlich kein Problem mehr.

Ja das sollte gar kein Problem sein, die Berechnung bei beidem ist ja im Grunde gleich, nur die Formal für die Gerade wird etwas anders berechnet.

Ich wollte eventuell auch noch als Berechnung HSI mit anbieten, der Blog Post von dieser LED Firma fand ich ganz spanned. Am Schluss kann dann ja jeder entscheiden, wie er es haben möchte.

Zitat von: herrmannj am 02 Februar 2016, 23:27:59
Unter Umständen könntest Du auch das dritte Modell (die Faktoren auf R,G,B) mit anbieten - rechnerisch ist das ja einfachste der Modelle.

Was meinst du mit 3ten Model? einfach nur RGB als Werte übermitteln?

Zitat von: herrmannj am 02 Februar 2016, 23:27:59
Im Übrigen ist das auch schon echt abgefahren. Mir ist kein Heim LED Controller bekannt der individuelle Farbkorrekturen anbietet (Eigentlich auch kein anderer. Aber ich kenn ja auch nich alle). Zusätzlich noch das Farbmix model zur Auswahl ist echt crazy shity stuff.  8)

Hat echt Potential das Projekt :)

Ich sag mal so - die fertigen Lösungen (Hue, Lightify) sind ja schon abgestimmt, da ist es nicht nötig (und Normalkunde möchte die Lampe in die Glühbirne eindrehen und dann direkt auf seinem smartphone mit einer app loslegen ohne große Konfiguration).
Spannend wäre es, wenn man den ESP zusammen mit LEDS und Trafo in E27 Fassungen verpacken kann (ähnlich den MiLights) - ich glaube das würde ne alternative sein können. (Aber: erstmal das Produkt entwerfen, Produktionsprozess planen und noch die ganzen Zertifizierungen bekommen - ich bleib dann doch lieber bei DIY ;-) )


Zum Projekt selbst:
- Ich habe mal einiges aufgeräumt und Code auf github geschoben
- Dokumentation (in Englisch) auf Github zu dem Projekt geschrieben

Links:
PCBs und Aufbauanleitung (https://github.com/patrickjahns/esp_rgbww_controller)
Firmware (https://github.com/patrickjahns/esp_rgbww_firmware) (Ist im Moment nur ein Demo Sketch, soll als Basis dienen falls schonmal jemand die Anbindung an FHEM anfangen möchte)
RGBWWLed Library - getrennte ESP Library  (https://github.com/patrickjahns/RGBWWLed)


Dafür habe ich gerade ein anderes Problem - der nette China Mann hat mir scheinbar kaputte/gefälschte MOSFETs geschickt. Ich hab gestern schön blöd geguckt als die LED Stripes nur leicht geleuchtet haben auf vollem PWM. Nach einigen Messen und hin und her bin ich den FETs auf die Schliche gekommen. Nach dem Datenblatt sollten die eigentlich ab 2.5V schon voll durschalten. Die 3.3v des ESP haben aber nicht gereicht - erst ab ca 4.2-4.5 volt schalten sie durch.

Die FETs aus der Apotheke (conrad) funktionieren einwandfrei - jetzt geht es daran eine neue günstige und zuverlässige Quelle für das Bauteil zu finden.   :'(  :'(  :'(

Hi

ZitatWas meinst du mit 3ten Model? einfach nur RGB als Werte übermitteln?

Ne - vorher alle auf gleiche Helligkeit bringen - also vor dem mixen mit einen Faktor x multiplizieren wie in der ersten lib.

Zitat
Ich sag mal so - die fertigen Lösungen (Hue, Lightify) sind ja schon abgestimmt, da ist es nicht nötig (und Normalkunde möchte die Lampe in die Glühbirne eindrehen und dann direkt auf seinem smartphone mit einer app loslegen ohne große Konfiguration).

Also bei den Hue weiß ichs nichht. Die ganzen anderen (milight, ld316, 382, lw12, sunricher etc) können das alle nicht. Die e27 Milight sind ja auch e27 ...

vg
joerg

Moin,

da ich gerade in der ESP/MQTT-ANBINDUNG drinn stecke.....
Würde es euch helfen, wenn ich euch ein ESP/MQTT-Grundgerüst zur Verfügung stelle?
Ihr bräuchte dann "nur" eure Routinen zu ergänzen.

Gruß
Pf@nne

Guten Abend/Nacht,

ich hab vorhin noch die Funktionen für HSV2RGB implementiert. Farbkorrektur ist auch schon möglich (hat mich nochmal einiges Gehirnschmalz spät am Abend gekostet  ;D). Funktioniert soweit prima - ich mach mich gerade mit Unittest schlau um mal die Fehlerrate des Algorithmus zu berechnen. Erste tests zeigten aber dass es im Rahmen von -/+ 2 (bei 10bit) ist.

Aus Spaß hab ich das auch schon auf den esp8266 geschoben und mal nen kleinen "Benchmark" drüber laufen lassen:
im Mittel 25us für die komplette Berechnung. Ich glaube das ist mehr als ausreichend - aber sicherlich geht da noch etwas Optimierung.

Am Wochenende geht es weiter mit der Library - auf dem Plan stehen transitions und die beiden anderen Farbkorrektur Modelle  :) :D

Solangsam wirds Zeit für die Anbindung an FHEM

Zitat von: herrmannj am 03 Februar 2016, 17:39:04
Die ganzen anderen (milight, ld316, 382, lw12, sunricher etc) können das alle nicht. Die e27 Milight sind ja auch e27 ...

Ich meinte ja das bei Hue/Lightify(Osram) es nicht notwendig sein sollte. Zumindest hoffe ich das bei dem Preis den man dafür zahlt ;-)

Bei den ganzen Selbstbau/LED (China) geschichten ist es schon was anderes...

Zitat von: Pf@nne am 03 Februar 2016, 18:05:22
da ich gerade in der ESP/MQTT-ANBINDUNG drinn stecke.....
Würde es euch helfen, wenn ich euch ein ESP/MQTT-Grundgerüst zur Verfügung stelle?
Ihr bräuchte dann "nur" eure Routinen zu ergänzen.

Immer gerne - wie davor geschrieben gibts den ersten sketch schon auf github:
https://github.com/patrickjahns/esp_rgbww_firmware
Erstell dir doch einen Fork von dem ganzen und los gehts  ;)
Wie ich mal etwas rumgeschaut habe, ist mir auch diese mqtt/pub-sub library in die Hände gekommen:
https://github.com/knolleary/pubsubclient

Ich weiss nicht inwiefern du die schon kennst bzw. das zu empfehlen ist.


Eine kurze Skizze zu Funktionen/Befehlen für die Anbindung:

http://forum.fhem.de/index.php?topic=34464.msg402346#msg402346
bzw auf Englisch in Github
https://github.com/patrickjahns/esp_rgbww_firmware#api-ideas


Wie die genaue Anbindung aussehen soll/kann, da würde ich Jörg nochmal heranziehen. Er kann sicherlich sagen, was Sinn macht im Bezug auf API & Anbindung. (Und sowie ich es verstanden habe, wollte er sich bereit erklären ja ein Modul bereit zu stellen  ::) )

Hallo zusammen,
wie sieht es eigentlich mit dem Layout aus könnte man nicht schon Platinen bestellen?
Oder sind noch Änderungen geplant?
Gruß
Matthias

Zitat von: mrpj am 04 Februar 2016, 01:01:26
Immer gerne - wie davor geschrieben gibts den ersten sketch schon auf github:
https://github.com/patrickjahns/esp_rgbww_firmware
Erstell dir doch einen Fork von dem ganzen und los gehts  ;)
Wie ich mal etwas rumgeschaut habe, ist mir auch diese mqtt/pub-sub library in die Hände gekommen:
https://github.com/knolleary/pubsubclient

Ich weiss nicht inwiefern du die schon kennst bzw. das zu empfehlen ist.

Ich nutze auch den Client vom Olleary die läuft mitlerweile recht stabil!
Ich setze mich am WE mal dran. Erstmal aber nur die MQTT-Anbindung.
Ich hab Leerlauf, bis die restlichen Röheren für den ReflowOfen da sind.... ::)

Gruß
Pf@nne

Wo finde ich die "RGBWWLed" Library?
Dein Repository ist leer....?

Hi,
ich lese hier seit einiger Zeit mit, ich bin begeistert .
Gibt es schon eine Liste für die Sammelbestellung?

Gesendet von meinem SM-G900F mit Tapatalk

Langer Tag, kurz noch bevor ich umfalle

Joerg ich habe nochmal über meine Idee hier nachgedacht:
(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45580;image)

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.

Somit kann ich gleich den HSI Algorithmus von hier übernehmen.
http://blog.saikoled.com/post/43693602826/why-every-led-light-should-be-using-hsi-colorspace


Eine wichtige Frage für mich
Macht es eigentlich Sinn überhaupt RGB und WarmWeiss und KaltWeiss , also alle 5 Kanäle direkt zu haben. Oder reichen eigentlich die RGB  und 1 WeissKanäle ?

Beim Entwurf vom PCB dachte ich mir, dass es eine gute Sache ist, 2 weißkanäle zu haben. Meinungen? Erfahrungswerte aus dem Alltag?

Zitat von: RaspII am 04 Februar 2016, 21:52:24
Gibt es schon eine Liste für die Sammelbestellung?

Nein und ich habe jetzt schon mehrmals darum gebeten, bitte in diesem Thread nicht immer wieder nach einer Sammelbestellung zu Fragen.
Es wird einen getrennten Beitrag dafür geben.
Bitte lasst mir doch auch die Zeit die Informationen zusammen zu schreiben, so dass es später für mich weniger Aufwand ist
(Und ich möchte heute Abend auch mal wieder ne Folge Blacklist anschauen, statt in Code oder dem FHEM Forum zu stecken ;-) )

Also Geduld haben und bis dahin Tee trinken. (Und auch gerne bei der Entwicklung der Software helfen!)

Zitat von: Pf@nne am 04 Februar 2016, 21:28:36
Wo finde ich die "RGBWWLed" Library?
Dein Repository ist leer....?

Die Library ist noch nicht hochgeladen - ich hatte gestern noch keine Zeit den Code noch etwas zu bereinigen. (Schnittstelle Library / hardware Code). Die bisherigen calls im Arduino Sketch werden wahrscheinlich rausfliegen und das management der Schnittstelle(PWM) durch die Library erfolgen. Wenn du den jetzigen Stand haben möchtest, schick ich ihn dir gerne zu


Mit diesen Worten Guten Nacht - ich bin ko

Hi

HSL und HSV sind unterschiedliche Möglichkeiten eine (Licht) Farbe zu beschreiben.

Wie aus HSV oder HSL dann RGB (oder RGBW, RGBWW ...) wird ist  davon unabhängig. Das überhaupt in RGB umgerechnet wird hängt ja nur damit zusammen das am Ende 3 Leds mit den Primärfarben hängen (die additiv mischen).

ZitatEine zweite für mich wichtige Frage:
Macht es eigentlich Sinn überhaupt RGB und WarmWeiss und KaltWeiss , also alle 5 Kanäle direkt zu haben. Oder reichen eigentlich die RGB  und 1 WeissKanäle ?

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.

ZitatDas 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%.

Wenn Du jetzt die Ausgabe auf einen reinen RGB Stripe machst rechnest Du Weiß (20%) danach auf alle Kanäle. Damit kommst Du nie über 100% und das passt bei beiden Mixer Modellen.

Alternativ (bei RGBW) wird Weiß auf die weißen LEDs gegeben und ROT leuchtet mit 80%.

Ich vermute das Du im Augenblick V gar nicht oder aber am Ausgang des Mixers berechnest. 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.

Im Mixer kannst Du die korrigierte Helligkeit direkt mit in Berechnung einfließen lassen. Für den Sektor 1 steigt GRÜn ja linear von 0 auf 2^PWM an. Anstelle der Konstante 2^PWM muss im realen Mixer eingesetzt werden 2^PWM * (V/100), wobei V hier ohne den vorher subtrahierten Weißanteil ist. Klingt kompliziert, daher mit Beispiel:

HSV 55,80,50:

step 1 (Weiß abziehen):
Farbanteil = V * 100 / S -> umgestellt -> S * V / 100 -> 80 * 50 / 100 = 40.

55° sind Sektor 1:
Rot ist 100% (von Farbanteil) = 40%. Anstelle von
ROT = 2^PWM
im entsprechenden if (oder select):
R = 2^PWM * 40 / 100

Die gleiche Ersetzung im Dreisatz für Grün.

Dann fallen aus dem (beiden) Converter die Werte als R,G,B (evtl plus W) gleich mit der richtigen Helligkeit raus.

Danach kommt dann nur noch die Farbtemperatur für Weiß.
Bei reinen RGB stripes das R und G gewichten. R runter nehmen ergibt kälter, B verringern ergibt wärmer.

Analog bei CW/WW stripes - zwischen den beiden einfach gewichten.

vg
Jörg

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

Erster deutscher Treffer zu den Unterschieden http://www.wisotop.de/hsv-und-hsl-farbmodell.shtml

Formell wird HSV so definiert wie ich den Mixer vorgeschlagen habe. Die Einwände (bei Y leuchten R und G) sind genauso klar. Daher ist das von Dir vorgeschlagene Modell (genauso wie "Rainbow" in der FastLED lib) mMn jeweils eine andere, von der Definition abweichende*, Art der HSV RGB Konvertierung. Bleibt trotzdem HSV. Mit HSL hat das nichts zu tun.

vg
joerg

Disclaimer
* "vom Standard abweichend" beinhaltet ausdrücklich keine Wertung der Eignung für den angestrebten Zweck (schönes Licht ;) )

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....

Moin,

Zitat von: herrmannj am 04 Februar 2016, 23:49:01
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?

Zitat
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.

Zitat von: herrmannj am 04 Februar 2016, 23:49:01
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.

Zitat
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

Zitat
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

Zitat von: Pf@nne am 05 Februar 2016, 06:01:46
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

@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

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:

ZitatNimm 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

Zitat von: Pf@nne am 05 Februar 2016, 16:42:46

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

Zitat von: mrpj am 05 Februar 2016, 17:14:08
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....... :-[ ;D

Hi mrpj

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

ZitatDen 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 ;)

ZitatInwiefern 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 ;)

Zitat
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  8) 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

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

ZitatC:\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

Moin,

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

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.
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?

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

Zitat von: herrmannj am 05 Februar 2016, 19:06:30
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.

Zitat von: herrmannj am 05 Februar 2016, 19:06:30
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!

Zitat von: herrmannj am 05 Februar 2016, 19:06:30
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.

Zitat von: herrmannj am 05 Februar 2016, 19:06:30

Die anderen beiden Varianten sind etwas komplexer zu berechnen. Schieb es auf der roadmap nach hinten  8) 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).

Zitat von: herrmannj am 05 Februar 2016, 19:06:30
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

Zitat von: Pf@nne am 05 Februar 2016, 19:11:27
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

Zitat von: Pf@nne am 05 Februar 2016, 23:15:27

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?

Zitat von: Pf@nne am 05 Februar 2016, 23:15:27
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

Zitat von: Pf@nne am 05 Februar 2016, 23:15:27
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

ZitatIst 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

Zitat von: mrpj am 06 Februar 2016, 01:18:47
Seltsam, bei mir kommt der Fehler nicht - ich schaus mir dann mal an

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

Zitat von: mrpj am 06 Februar 2016, 01:18:47
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.

Zitat von: mrpj am 06 Februar 2016, 01:18:47
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.

Zitat von: mrpj am 06 Februar 2016, 01:18:47
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 (http://tinyurl.com/mqtt-spy-download/mqtt-spy-0.5.0-beta-b4-jar-with-dependencies.jar)
das macht echt Spaß!

Schönes WE.....

Morgen,

Zitat von: Pf@nne am 06 Februar 2016, 10:19:02
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.

Zitat von: Pf@nne am 06 Februar 2016, 10:19:02
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)

Zitat von: Pf@nne am 06 Februar 2016, 10:19:02
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.) ?

Zitat von: herrmannj am 06 Februar 2016, 01:57:03
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 ;-)

Zitat von: herrmannj am 06 Februar 2016, 01:57:03
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

Zitat von: herrmannj am 06 Februar 2016, 01:57:03
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.

Zitat von: herrmannj am 06 Februar 2016, 01:57:03
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?

Zitat von: mrpj am 06 Februar 2016, 11:30:54
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

Zitat von: mrpj am 06 Februar 2016, 11:30:54
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..... ;D
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:

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.

Zitat von: Pf@nne am 06 Februar 2016, 13:56:27
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

Zitat von: Pf@nne am 06 Februar 2016, 13:56:27
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

Zitat von: Pf@nne am 06 Februar 2016, 13:56:27
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.

Zitat von: Pf@nne am 06 Februar 2016, 13:56:27
Wenn Zeit hast.....ich weiß, wer hat die schon..... ;D
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.

ZitatIch 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.

Ich mache mal einen Vorschlag......ich hoffe, ich schaffe das alles bevor meine Röhren da sind...  ;D

ZitatWarum 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.

Ich habe mal gemessen....
Demnach benötigt ein frame von z.B. FHEM über den Broker zum ESP im Schnitt 8 ms, abhänging vom Datenverkehr in meinen Netz.
(http://www.s6z.de/cms/images/content/test/Homeautomation/Hardware/ESP8266/TMP/MQTTquality.png)

Gemessen habe ich die Zeit die ein publish vom ESP braucht um am ESP als subcribe wieder anzukommen.

mich würde mal folgendes interessieren:

Ich habe vor einigen Monaten auch poc auf dem esp dazu gemacht. Ich habe damals aber keinen stabilen Betrieb von WLAN und PWM hin bekommen. Der esp hat immer wieder sporadisch rebootet. Da gab es dann auch Meldungen in der ESP Arduino group dazu.

Gelingt Dir (Euch) das stabil im Dauerbetrieb ?

vg
joerg

Mitlerweile ja, ich kenne diese sporadischen reboots auch, die sind aber mit der ESP 2.1 deutlich besser geworden.
Solltest du vielleicht noch mal wagen.... ;D

Edit:
Ich habe meine ESPs aber im Messbetrieb, da ist der ESP natürlich neu verbunden bevor ein neuer Messwert kommt.
Aber ich habe eine reconnect Überwachung drin, die sieht bisher ganz gut aus.

Zitat von: Pf@nne am 06 Februar 2016, 22:34:48
Ich mache mal einen Vorschlag......ich hoffe, ich schaffe das alles bevor meine Röhren da sind...  ;D

Was für Röhren ?  ;D

Zitat von: Pf@nne am 06 Februar 2016, 22:34:48
Ich habe mal gemessen....
Demnach benötigt ein frame von z.B. FHEM über den Broker zum ESP im Schnitt 8 ms, abhänging vom Datenverkehr in meinen Netz.

Gemessen habe ich die Zeit die ein publish vom ESP braucht um am ESP als subcribe wieder anzukommen.

Sieht doch gut aus - bedenken zu Latenz eingeschränkt.

Gibt es denn eine Lösung auch direkt ohne Broker/Server kommunizieren zu können?
Alternativ kann man ja immernoch ein udp/tcp Protokoll im Hinterkopf behalten - müssen halt mal schauen, wie stark wir den ESP mit webserver/mqtt/tcp server belasten

Zitat von: herrmannj am 06 Februar 2016, 22:42:15
Ich habe vor einigen Monaten auch poc auf dem esp dazu gemacht. Ich habe damals aber keinen stabilen Betrieb von WLAN und PWM hin bekommen. Der esp hat immer wieder sporadisch rebootet. Da gab es dann auch Meldungen in der ESP Arduino group dazu.

Gelingt Dir (Euch) das stabil im Dauerbetrieb ?

Ist mir bisher bei den fertigen Testplatinen nicht passiert - aber es sind Testplatinen - sprich ich teste im Moment den Code und die sind meist nicht mehr als 10-20 Minuten dauerhaft an. Ich werde morgen einfach mal nen ESP den ganzen Tag durchlaufen lassen und schauen ob er Ausfallerscheinungen zeigt. In den letzten Monaten hat sich aber in der ESP Arduino Library einiges getan - auch diverse fixes für PWM

Mal rein aus Interresse, lag es wirklich am Code, oder kann es sein, dass er zu wenig Pufferung hatte?

ZitatMal rein aus Interresse, lag es wirklich am Code, oder kann es sein, dass er zu wenig Pufferung hatte?

Ich sag mal so: großes und kleines c dran - dickes, definitiv sauberes Netzteil. Den Rest kann man nur raten.

Reicht ein aktuelles update der arduino-esp ide auf staging ?

Danke vg
joerg

Moin,

welche Version nutzt du denn? 1.6.5?
Bei mir hat der Sprung auf 2.x schon einiges an Stabilität gebracht...

Ich warte immer noch auf Infrarotelemente (Röhren) für meinen Reflow-Ofen.
Das ist eigentlich mein aktuelles Projekt.... ;D

MQTT ohne Broker geht nicht, da der MQTT-ESP - CLIENT ja fest per TCP am Broker hängt.
Wenn es einen MQTT-Broker per UDP gäbe dann würde das gehen......
Dann könnte man an den Client drann kommen.

Aber ein UDP - SERVER im ESP sollte jetzt ja auch kein großes Ding sein.
Das ist mit Sicherheit das Schnellste und Universellste was du machen kannst.
Meine vorherigen Steuerungen liefen alle per UDP.

Man muss nur damit leben, das mal was "verschütt" geht.
Ist im Heimnetzt aber wohl echt eine Ausnahme.

Zur Belastung, da muss man schauen, was das Hausnetzt da so alles verträgt.
Bei mir werden es nach aktuellem Stand einige ESPs werden.
Mit Licht, Sensoren  und Aktoren kommen da schnell 20 Stück zusammen.
Man muss schauen, ob dann nicht ein eigenes Netz für die Haustechnik notwendig wird.
Mal sehen....

ZitatMan muss nur damit leben, das mal was "verschütt" geht.
Ist im Heimnetzt aber wohl echt eine Ausnahme.

Hab ich auch mal gedacht und das dann gemessen. (Weil ich auch immer alles schnell udp gemacht habe ;) ). Die Fehlerrate kann aber durchaus im Bereich 0%-10% liegen. Und wenn's dumm läuft auch mehr..

vg
joerg

Servus,
(ich oute mich mal als Franke  ;))

Ich hab jetzt mal nen Test seit heute morgen am laufen - ein Controller ist die ganze Zeit mit PWM an - wird seit heute morgen mit ping requests noch zusätzlich "bombadiert". Mal sehen ob das schon zu einem reset führt im laufe des Tages.

Schritt 2 wäre dann, dem ESP die ganze Zeit verschiedene Kommandos zu schicken - (muss dann nur das teil in ein andere Zimmer verschieben, sonst bekomm ich wahrscheinlich einen epilleptischen Anfall)

Zitat von: Pf@nne am 07 Februar 2016, 07:47:45
Ich warte immer noch auf Infrarotelemente (Röhren) für meinen Reflow-Ofen.
Das ist eigentlich mein aktuelles Projekt.... ;D

Ja sehr cool - mich interressiert fast mehr, was du denn damit vor hast  ;) - ich werde mal deinen Thread dazu lesen

Zitat von: Pf@nne am 07 Februar 2016, 07:47:45
MQTT ohne Broker geht nicht, da der MQTT-ESP - CLIENT ja fest per TCP am Broker hängt.
Wenn es einen MQTT-Broker per UDP gäbe dann würde das gehen......
Dann könnte man an den Client drann kommen.

Aber ein UDP - SERVER im ESP sollte jetzt ja auch kein großes Ding sein.
Das ist mit Sicherheit das Schnellste und Universellste was du machen kannst.
Meine vorherigen Steuerungen liefen alle per UDP.

Naja alternativ geht auch eine low level Implementierung von einem TCP Server - damit spart man sich den Overhead vom Webserver. Die Anwendungen müssen dann halt doch etwas spezifischer programmiert werden  :-\

Zitat von: Pf@nne am 07 Februar 2016, 07:47:45
Zur Belastung, da muss man schauen, was das Hausnetzt da so alles verträgt.
Bei mir werden es nach aktuellem Stand einige ESPs werden.
Mit Licht, Sensoren  und Aktoren kommen da schnell 20 Stück zusammen.
Man muss schauen, ob dann nicht ein eigenes Netz für die Haustechnik notwendig wird.
Mal sehen....

Mit einem guten Router lassen sich ziemlich viele Geräte einbinden - die Teile die bei den meisten Menschen mit ihrem Anschluss dabei sind, sind großer mist (Das mangetafarbene T vorne Weg mit ihren speedlink routern  >:( >:()

Aber aus einer anderen perspektive macht ein getrenntes Netzwerk viel Sinn: Sicherheit
Wenn du zwei getrennte Netzwerke hast, kannst du alles was nicht im Haustechnik netz aktiv ist, raussperren. Die Kommunikation zwischen Hausnetz und Bedienelementen geschieht dann nur noch via einem Gateway - der Pakete nicht von einem ins andere Netz lässt. Aber ein Service auf dem Gateway (z.B. der MQTT Broker) ist dann die Schnittstelle. Wenn richtig konfiguriert, fallen viele Sorgen zum Thema Sicherheit weg.

Moin (ich oute mich mal als Hamburger),

Franke....So so, ich habe einen Kollegen aus Selb, der hat ein sehr langes uuuuu in Hambuuuurg..... ;D
Verträgt sich aber gurt mit den einheimischen hier........

Zitat von: mrpj am 07 Februar 2016, 13:14:52
Ja sehr cool - mich interressiert fast mehr, was du denn damit vor hast  ;) - ich werde mal deinen Thread dazu lesen

Ich bin dabei universelle Aktoren/Sensoren für die einzelnen Zimmer zu entwerfen.
Damit es klein werden soll ist SMD angesagt, damit es mehr oder weniger professionell wird wollte ich mir einen ReflowOfen bauen.

Generell ist ja ersmal die Hardware wichtig, Software kann dann immer noch angepasst werden.
Es wird sich Zeigen welcher Weg der beste ist.
Hängt auch immer mit den eigenen Vorlieben zusammen.....

Zitat von: mrpj am 07 Februar 2016, 13:14:52
Aber aus einer anderen perspektive macht ein getrenntes Netzwerk viel Sinn: Sicherheit

Sehe ich auch so, ist schon blöde wenn in 10 Jahren der frühreife Nachbarssohn (Nerd der zweiten Generation) auf der Straße steht und  hier drinnen alles durcheinander bring.


Zu deinem Projekt:
Ich habe jetzt auch auf Arduino 1.6.7 umgestellt und habe festgestellt, das ich einige Probleme mit meinem Code habe.
Z.B. müssen Funktionen in ausgelagerten *.ino files jetz vorher deklariert werden, das war mit 1.6.5 irgendwie noch nicht so.....
Auch deine Library läuft mit meinem Sketch nicht.
Ich muss dazu sagen, dass ich erst vor 3 Monaten mit c/c++ angefangen habe (wg. ESP und Arduino, echt klasse).   
Ich komme aus der Pascal und Basic Ecke.....

Daher würde ganz gerne jetzt ertmal einen frischen Sketch aufmachen mit WEB-IF für den ersten Start, OTA und MQTT Grundgerüst.
Das brauche ich für meine AKT/Sen sowieso. Im Nachgang könnte ich deinen bisherigen Sketch da gerne eintüddeln, der war ja nich so umfangreich.
Dann würde ich mich auch um einen Topic-Tree für die RGB-Module kümmern.

Grüße in den Süden...
Pf@nne

na wenn wir beim outing sind: auch Hamburch :)

Der reboots habe ich mindestens alle 20min gesehen, wenn (und das war Voraussetzung) der esp Wifi UND PWM gemacht hat. Jedes für sich war problemlos.

Da gab es wohl Probleme bei den ISR Routinen. Schön - dann scheint das beseitigt zu sein. Das hat mich "damals" (SIC) echt abgetörnt - freut mich also um so mehr.

vg
joerg

So ich hab mir mal heute Nachmittag die Zeit genommen und einen seperaten Thread mit allen Informationen (auch relevant zur Sammelbestellung) aufgemacht:
http://forum.fhem.de/index.php/topic,48918.0.html

Ich würde die Unterhaltung zur Software noch hier lassen, können aber auch gerne in den anderen Faden umziehen? Was meint ihr?

Zitat von: Pf@nne am 07 Februar 2016, 14:06:53
Zu deinem Projekt:
Ich habe jetzt auch auf Arduino 1.6.7 umgestellt und habe festgestellt, das ich einige Probleme mit meinem Code habe.
Z.B. müssen Funktionen in ausgelagerten *.ino files jetz vorher deklariert werden, das war mit 1.6.5 irgendwie noch nicht so.....
Auch deine Library läuft mit meinem Sketch nicht.

Seltsam - ich werde mir das dann mal genauer anschauen, sobald die LED Library auf nem guten Stand ist

Zitat von: Pf@nne am 07 Februar 2016, 14:06:53
Ich muss dazu sagen, dass ich erst vor 3 Monaten mit c/c++ angefangen habe (wg. ESP und Arduino, echt klasse).   
Ich komme aus der Pascal und Basic Ecke.....

Ich muss mich gerade erst wieder in c/c++ zurecht finden. In den letzten Monaten/Jahren habe ich bevorzugt mit Python & Javascript gearbeitet. Früher musste ich meine AVR Projekte in C schreiben - und im Studium haben wir C auch gebraucht.

Aber der Überfliege in c++ bin ich nicht ;-)

Zitat von: Pf@nne am 07 Februar 2016, 14:06:53
Daher würde ganz gerne jetzt ertmal einen frischen Sketch aufmachen mit WEB-IF für den ersten Start, OTA und MQTT Grundgerüst.
Das brauche ich für meine AKT/Sen sowieso. Im Nachgang könnte ich deinen bisherigen Sketch da gerne eintüddeln, der war ja nich so umfangreich.
Dann würde ich mich auch um einen Topic-Tree für die RGB-Module kümmern.

Da kannst du dir ruhig Zeit nehmen ;-)

Zitat von: herrmannj am 07 Februar 2016, 14:56:23
Der reboots habe ich mindestens alle 20min gesehen, wenn (und das war Voraussetzung) der esp Wifi UND PWM gemacht hat. Jedes für sich war problemlos.

Da gab es wohl Probleme bei den ISR Routinen. Schön - dann scheint das beseitigt zu sein. Das hat mich "damals" (SIC) echt abgetörnt - freut mich also um so mehr.

Also bei mir läuft der Test seit heute morgen ohne Probleme - denke mal das das Problem nicht mehr besteht - dafür soll es wohl andere Probleme geben (ab und an ein Flackern) - was ich bisher noch nicht nachvollziehen konnte

ZitatAlso bei mir läuft der Test seit heute morgen ohne Probleme - denke mal das das Problem nicht mehr besteht - dafür soll es wohl andere Probleme geben (ab und an ein Flackern) - was ich bisher noch nicht nachvollziehen konnte

Schön. manchmal muss einfach ein wenig warten.
Das Flackern kann ich mir vorstellen. Der esp macht das alles per soft PWM und teilt sich die IRQ mit ddem Wifi. Wird aber tolerierbar sein.

vg
joerg

Moin,

Soft PWM? Irgs....

Mit welcher Frequenz wird hier gearbeitet? Man muss ja immer ein gesundes Mittel finden zwischen dem was die Augen als Flackern wahrnehmen (Und vor allem das Gehirn wahrnimmt und stresst) und was den EMV Richtlinien gerecht wird. Viele Nutzen um die 200 Hz, solange man keine bewegten Objekte zu Hause hat geht das auch, aber fürs Gehirn ist es natürlich "Stress".

/Daniel

Moin

die arduino lib für den esp nutzt 1khz 10bit pwm als default - siehe https://github.com/esp8266/Arduino/blob/master/doc/reference.md#analog-output

Ist aber auch modifizierbar. Wie Joerg schon geschrieben hat, teilt sich der esp den timer für den adc mit wifi. Das macht aber bei mir im Testbetrieb hier nicht viel aus. Auch wenn ich den ESP mit ping requests/http Anfragen belastet habe, habe ich keine aussetzer und kein (merkliches) Flackern erlebt. (Ich hab aber auch nicht die Beleuchtung die ganze Zeit angestarrt, sondern als normale Zimmerbeleuchtung Abends angehabt)

Hi mrpj,

https://github.com/patrickjahns/esp_rgbww_controller/blob/v1.1/esp12_RGBWW.brd
beim Öffnen der Eagle *brd bekomme ich die Fehlermeldung:
Fehler:
Zeile 6, Spalte 41: Dies ist keine EAGLE-Datei.

Benutze Eagle free 7.2.0

Hmm,

seltsam - ich benutze leider die aktuelle 7.5 Version - werde es später mal mit einer 7.2 probieren.

Kannst du denn die *.sch öffnen?

Hallo,

mit Eagle v7.3 (voll) geht es.

Gruß PeMue

Zum PWM:

die Hardware mit MOSFETS direkt am GPIO hat schon was.
Sind das eigentlich FETs mit integriertem Treiber?

Wenn da noch Bedenken wegen der PWM bestehen...
was würde gegen einen I2C PWM Treiber sprechen?
Das wäre dann hardware PWM, da sollte dann nix mehr flackern.

OK Fehler gefunden. Habe auf Git Hub mit rechte Maus "save as" versucht den File runterzuladen. Wenn ich die Zip Funktion benutze geht es. Strange strange
Edit: Rechte Maustaste "save as" auf "Raw" geht auch.

Zitat von: Pf@nne am 08 Februar 2016, 17:35:34
Zum PWM:

die Hardware mit MOSFETS direkt am GPIO hat schon was.
Sind das eigentlich FETs mit integriertem Treiber?

Was verstehst du unter Treiber?

Die verwendeten Mosfets sind "Logic Level". Sprich sie schalten voll bei geringeren Spannungen durch.

Datenblatt IRLZ44N (http://www.irf.com/product-info/datasheets/data/irlz44n.pdf)

Zitat von: Pf@nne am 08 Februar 2016, 17:35:34
Wenn da noch Bedenken wegen der PWM bestehen...
was würde gegen einen I2C PWM Treiber sprechen?
Das wäre dann hardware PWM, da sollte dann nix mehr flackern.

Ich habe wie gesagt kein einziges Flackern bisher erkennen können. In diesem Github Issue (https://github.com/esp8266/Arduino/issues/836) wird davon berichtet. Es ist wohl ein Software Fehler und kommt bei kleinen Werten vor

Ich teste heute Abend mal kleine Werte und beanspruche das Wifi nochmals.

Zwischen Dezember/Januar wurden aber auch ein paar fixes zu PWM eingebaut
https://github.com/esp8266/Arduino/pull/1391

Meine Vermutung ist vielmehr, dass die Leute in dem issue zu pwm noch viel mehr Code auf dem ESP laufen haben, der einiges blockiert. Beim herumspielen hatte ich auch mal das ein oder andere delay(); in meinem Code und das hat auch einiges stocken lassen.

Nachtrag

Und es hat auch keiner seine Schaltung gepostet - sowas hängt auch von den Bauteilen die verwendet werden ab  ;)

ZitatIch habe wie gesagt kein einziges Flackern bisher erkennen können.

Kann ich bestätigen. Kein Flackern.

Ich hatte HSV2RGB und eine Kerzen-Flammen Simulation laufen.

vg
joerg

Heya,

so ich hab mal etwas getestet - ich kann flackern erzeugen - dazu muss ich aber wirklich den ESP belasten.
Einfachste Methode - OTA update mit dem integrierten Webserver  ;D 8) - aber das verwundert mich auch nicht - denn der webserver blockiert den esp ganz schön und nutzt gleichzeitig noch wifi.
Sowas kommt im normalgebrauch nicht vor

Noch eine Sache wie man den ESP auslasten kann: kontinuierlich den ADC auslesen - das blockiert auch "lange" (relativ gesehen).
Merklich wird es nur  im unteren Bereich des PWM  (0-5 von 1023).

Das mit dem ADC ist etwas unschön - macht die PowerFail Erkennung später schwieriger.... Mal sehen vielleicht lässt sich da ja auch noch einiges optimieren

Ich habe diesbezüglich eine Frage:

ZitatEinfache Konfiguration via Webbrowser

   
• Wenn der Controller zum ersten mal angeschaltet wird, startet er im AP Modus (SSID rgbww-***). Man kann sich dann mit dem Smartphone/Tablet/Laptop verbinden, die Zugangsdaten zum HomeWifi und weitere Optionen (IP etc.) eingeben und er startet neu und verbindet sich. (Bei einem Neustart sucht er automatisch nach dem gespeicherten WiFI, falls dies nicht gefunden wird, startet er wieder im Accesspoint Modus und man kann in z.B. rekonfigurieren)[/l][/l][/l][/l][/l][/l]

Finde ich auch Security Sicht supoptimal. Thema Hacking: Ist sende zum ESP ständige Deauths zum HomeWifi (und sorge für eine Reboot des ESP
[falls überhaupt notwendig]), schon kann ich mich darauf verbinden und die Daten (inkl. HomeWifi Zugangsdaten) auslesen?





PR ist raus :)  Jetzt muss ich den Thread mal durchlesen, welche kostengünstigen LED-Bänder dafür zu empfehlen sind...
[/list]

Zitat von: Hauswart am 09 Februar 2016, 09:08:30

Finde ich auch Security Sicht supoptimal. Thema Hacking: Ist sende zum ESP ständige Deauths zum HomeWifi (und sorge für eine Reboot des ESP
[falls überhaupt notwendig]), schon kann ich mich darauf verbinden und die Daten (inkl. HomeWifi Zugangsdaten) auslesen?

Spannendes Thema  :D

Diese bedenken kann ich nicht teilen, denn es gibt zu keinem Zeitpuntk die Möglichkeit das Passwort auszulesen. (Nur wenn du physischen Zugriff auf den Controller hast und den kompletten Controller ausliest).

Wenn der Controller sich nicht zum letzten gespeicherten Netzwerk verbinden kann, startet er nach einem timeout von ca. 120s das Konfigurationsportal im Accesspoint Modus. In dem Portal kann man sich nur mit neuen Zugangsdaten verbinden, aber keine Daten auslesen.

Es gibt in der WifiManager Bibliothek noch die Möglichkeit ein Passwort für den AccessPoint zu definieren. Der AP ist dann mit WPA2-PSK gesichert für das Konfigurationsportal zu definieren. Aus meiner Sicht nicht zwingend notwendig - bietet mMn keinen Vorteil/mehr Sicherheit



Es gibt die Möglichkeit einer Attacke:
1) Der Angreifer schafft es, dass der Controller neustartet und es in dem timeout nicht schafft mit dem hinterlegten Zugangsdaten bei einem Accesspoint anzumelden

2) Der Angreifer verschafft sich via BruteForce zugang zu dem Accesspoint (sehr unwahrscheinlich). Ist mit desem verbunden und wartet darauf bis man sich selbst verbindet um die Zugangsdaten für das Heimnetzwerk einzugeben
Der Angreifer lauscht nun in dem ungesicherten Wlan des ESP mit und warte darauf bis der Nutzer dort seine Zugangsdaten eingibt.

Lässt sich aber ganz einfach verhinden, indem man seinen Controller neustartet. Er verbindet sich dann automatisch mit den letzten gespeicherten Zugangsdaten. (Wenn in diesem Zeitraum der Angreifer den Router immernoch mit requests blockert, dürfte man das im allgemeinen Netzwerk auch bemerken)

Zitat von: mrpj am 09 Februar 2016, 10:11:36
Diese bedenken kann ich nicht teilen, denn es gibt zu keinem Zeitpuntk die Möglichkeit das Passwort auszulesen. (Nur wenn du physischen Zugriff auf den Controller hast und den kompletten Controller ausliest).

Okay, d.h. via Wlan kann ich nicht die FW auslesen? Auch wenn die OTA-Update zur Verfügung steht? Oder steht dies alles erst zur Verfügung, wenn ich einen neuen AP definiert habe? Sprich im default AP ist dies unterbunden?

Im Moment ist es die "Erstkonfiguration" allen anderem vorgeschaltet. (siehe setup() Bereich)

OTA geht im Moment auch nur, wenn der Controller mit einem Router/Accesspoint verbunden ist.
Auch bei der OTA Webseite lässt sich ein passwort vorschalten.

OTA ist auch nur eine Webseite mit einem Datei Upload Feld - es ist also eine Einbahnstraße

Danke für den Impuls wegen Sicherheit - ich denke es ist nochmals wichtig diesen Punkt als ToDo fest zu halten und bei der Implementierung zu berücksichtigen. Spätestens wenn v1 fertig ist, wäre ein überprüfen eine gute Idee.

Vielen Dank für deine Erläuterungen, dann muss ich mir nur noch überlegen, welche Bestellvariante ich bevorzuge und wie viele bzw. welche LED-Bänder ich mir anschaffe.... :D

Zitat von: mrpj am 08 Februar 2016, 10:50:32
die arduino lib für den esp nutzt 1khz 10bit pwm als default - siehe https://github.com/esp8266/Arduino/blob/master/doc/reference.md#analog-output

1kHz ist sehr gut, wenn er das sauber schafft bei 5 Kanälen gibt es da nichts zu meckern. Bei 1kHz sollte man aber EMV beachten, also Widerstände vor die MOSFETs in entsprechender Dimensionierung um die Flanken etwas abzuflachen.

Btw. ich hätte allgemein noch ein paar Feature Requests für die Software Entwicklung:

- SSL für die Kommunikation
- Eventuell WLAN via Radius
- IR Empfänger (Um normale IR Fernbedienungen weiter zu nutzen (WAF))
Da war noch was, aber das fällt mir gerade nicht ein.

Gibt es eigentlich das ganze auch als LAN Version?

Gruß
Daniel

Zitat von: Pf@nne am 08 Februar 2016, 17:35:34
Zum PWM:

die Hardware mit MOSFETS direkt am GPIO hat schon was.
Sind das eigentlich FETs mit integriertem Treiber?

Wenn da noch Bedenken wegen der PWM bestehen...
was würde gegen einen I2C PWM Treiber sprechen?
Das wäre dann hardware PWM, da sollte dann nix mehr flackern.

Direkt am GPIO? (Ich hab mir das schematic noch nicht angesehen) Da sollte aber auch ein Widerstand zwischen. Ich weiß ja nicht wie das C in den verwendeten MOSFETs so ist, aber da können beim Umladen recht hohe Ströme entstehen die ohne Vorwiderstand die GPIO Ports in die ewigen schicken kann...

Aber wenn der 1kHz sauber schafft, geht das auch per SoftPWM, ich denke das ist kein Problem.

/Daniel

Zitat von: ext23 am 09 Februar 2016, 11:24:22
Gibt es eigentlich das ganze auch als LAN Version?

An einer LAN Version hätte ich auch Interesse.
Eventuell lässt sich ja in die Software/ESP noch ein W5100 oder ein ENC28J60 anflanschen.
Dann würde z.B. wenn LAN einen Link bekommt das WLAN deaktiviert. So ist das bei vielen der günstigen WebCams.
WLAN ist eben nicht LAN wenn es um die Verfügbarkeit geht.
(Ich habe z.B.: tageszeit- und witterungsabhängig sporadische Aussetzer bei meinem Mediaplayer)

Zitat von: ext23 am 09 Februar 2016, 11:45:50
Direkt am GPIO? (Ich hab mir das schematic noch nicht angesehen) Da sollte aber auch ein Widerstand zwischen. Ich weiß ja nicht wie das C in den verwendeten MOSFETs so ist, aber da können beim Umladen recht hohe Ströme entstehen die ohne Vorwiderstand die GPIO Ports in die ewigen schicken kann...

Ich war der Meinung da schon was zu geschrieben zu haben, ist aber irgendwie verschwunden....???

Die verwendeten MOSFETs sind zwar LL (LogicLevel) aber die direkte Ansteuerung mit einem GPIO sehe ich da auch noch nicht.
Funktionieren tut das Ganze, die Frage ist bis zu welchem Strom.
Das Gate des FETs ist ein Kondensator, der GPIO muss diesen umladen. Von daher hast du recht, dass es hier zu Stromspitzen am GPIO kommen kann. Mit dem Widerstand wird der Umladestrom begrenzt, was aber auch die Zeitkonstante erhöht.
Das heißt, die Spannung am Gate ändert sich langsamer.
Die Verluste am FET (Wärme) zeigen sich im linearen Bereich, also immer beim Umladen.

Von daher gilt: Je schneller und Stromstärker die Ansteuerung (daher sollte man auch einen Treiber verwenden) , desto kleiner sind die Verluste (Wärme) beim Umladen des Gate-Kondensators. Je schneller die Umladung erfolgt desto größer wird aber auch das dU/dt bzw. dI/dt, was wiederum für die Störungen verantwortlich ist.

Im Gegenzug werden die Störungen bei langsamerer Umladung kleiner, dafür wird aber Wärmentwicklung größer.

Daher die Frage, wie viel Strom habt ihr bei dieser HW-Anschaltung schon getestet?
Bei 1m LED-Band passiert sicherlich erst mal nix. Bei mehreren Ampere dürfe die Wärmeentwicklung schon interessant werden.

EDIT:
Der Vorteil eines LL-MOSFETs liegt darin, dass er bereits bei kleinen Spannungen sein RDSon erreicht und somit die statischen Verluste klein hält. Daher sind die Dinger, mit direkter GPIO-Ansteuerung, zum Schalten (also mal ab und an EIN/AUS) sehr gut geeignet.
Bei der Ansteuerung über PWM mit 1000 Schaltungen/s müsste der maximal mögliche Strom ohne Kühlung sehr weit unter dem Datenblatt liegen. Ist nur die Frage wie weit drunter.......

Ich bin in der FET-Materie auch nicht mehr so tief drin, vielleicht kann sich da nochmal ein Spezi zu äußern.


Gruß
Pf@nne

 

Zitat von: AxelSchweiss am 09 Februar 2016, 11:59:31
An einer LAN Version hätte ich auch Interesse.
Eventuell lässt sich ja in die Software/ESP noch ein W5100 oder ein ENC28J60 anflanschen.
Dann würde z.B. wenn LAN einen Link bekommt das WLAN deaktiviert. So ist das bei vielen der günstigen WebCams.
WLAN ist eben nicht LAN wenn es um die Verfügbarkeit geht.
(Ich habe z.B.: tageszeit- und witterungsabhängig sporadische Aussetzer bei meinem Mediaplayer)

Sehe ich ganz genauso ;-) WLAN ist eine Krücke, und das noch nach Jahren, außerdem bin ich auch kein Freund der Strahlung ;-) Von der Sicherheit mal ganz zu schweigen.

Hi,
Ich antworte mal kurz

Zitat von: ext23 am 09 Februar 2016, 11:24:22
1kHz ist sehr gut, wenn er das sauber schafft bei 5 Kanälen gibt es da nichts zu meckern. Bei 1kHz sollte man aber EMV beachten, also Widerstände vor die MOSFETs in entsprechender Dimensionierung um die Flanken etwas abzuflachen.

1khz macht er ohne Probleme mit - ich hatte jetzt nur gestern bei meinem billig Netzteil Zuhause feststellen müssen, dass es bei 1khz das surren anfängt. Wenn wieder etwas mehr Zeit vorhanden ist, messe ich das nochmal mit vernünftigen Geräten.

Beim testen mit 200hz war das Netzteil ruhig.

Zitat von: ext23 am 09 Februar 2016, 11:24:22

Btw. ich hätte allgemein noch ein paar Feature Requests für die Software Entwicklung:

- SSL für die Kommunikation
- Eventuell WLAN via Radius

Diese Punkte schiebe ich weit hinten an und sehe ich mehr als ein NiceToHave an.
SSL: hängt von dem verwendeten (Web)server/MQTT Clienten ab.
Wlan und Radius direkt von dem SDK des Herstellers (espressif)

Zitat von: ext23 am 09 Februar 2016, 11:24:22

- IR Empfänger (Um normale IR Fernbedienungen weiter zu nutzen (WAF))

Bei einem Vorschlag wie mit den übrigen vorhanden IOs das ganze integriert werden kann, erweitere ich das Layout. (Insofern die Maße von 50x50mm nicht überschritten werden und die Komponenten optional bleiben).
Softwaremäßig gebe ich diese Funktion aus der Hand

Zitat von: ext23 am 09 Februar 2016, 11:24:22
Gibt es eigentlich das ganze auch als LAN Version?

Zitat von: AxelSchweiss am 09 Februar 2016, 11:59:31
An einer LAN Version hätte ich auch Interesse.
Eventuell lässt sich ja in die Software/ESP noch ein W5100 oder ein ENC28J60 anflanschen.

Sicherlich nice to have - aber ich möchte mich damit nicht auch noch auseinander setzen  ;). Aber da die LED Bibliothek und die "Firmware" getrennt entstehen - steht einem Fork ja nicht viel im Weg oder?

Zitat von: Pf@nne am 09 Februar 2016, 12:50:14
Die verwendeten MOSFETs sind zwar LL (LogicLevel) aber die direkte Ansteuerung mit einem GPIO sehe ich da auch noch nicht.

Nochmals das Datenblatt:
http://www.irf.com/product-info/datasheets/data/irlz44n.pdf

Die Lasten von LED Streifen sollten kein Problem sein.
Wenn ich nun 5A annehme, dann habe ich 0.3V (DS); Sprich ich hab eine Abwärme von 0.3V&5A = 1.5W

Wenn ich nun die Maximal Wärmewiederstand zur Umwelt von 62C/W annehme, dann kriegt der Mosfet 93Grad über Umgebungstemperatur. - Bleibt also definitiv unter seinen 170 Maximalspezifikation.

Zitat von: Pf@nne am 09 Februar 2016, 12:50:14
Ich bin in der FET-Materie auch nicht mehr so tief drin, vielleicht kann sich da nochmal ein Spezi zu äußern

LogicLevel ist aber nicht gleich LogicLevel, da musst du aufpassen, 5V ist auch LogicLevel.

Also bei meinem RGB Board habe ich mal 20 A gestestet, die Dinger wurden nicht mal pupwarm. Das Einzige was warm wurde waren die Leiterbahnen die langsam das Rauchen angefangen haben ;-) Aber ich habe auch andere verwendet.

Ansonsten ist ein Treiber mit Sicherheit immer besser, aber ich hatte kein Platz mehr auf meinem Board. Und ich glaube bei den Strömen über die wir reden oO Der Großteil hier wird eh irgend welche LED billig Ware aus China verwenden weil man keine Lust hat 160 Euro für 5 Meter Osram LED Band zu bezahlen. Von daher liegt der Verlust noch an ganz anderen Stellen ;-) Ansonsten stimmt das natürlich, man sollte schon Energie sparen wo es nur geht.

Sollte man wirklich hohe Ströme schalten, dann rate ich immer Tempfühler bzw. Temp Sicherungen an die MOSFETs zu klemmen. Wenn die Hütte erst mal brennt ist es zu spät.

Zum Thema Maximal - Verweiss ich ganz Dezent dass ich schon in Github geschrieben habe, dass ich maximal ~4.5A pro Kanal vorschlage  ;)
(https://github.com/patrickjahns/esp_rgbww_controller/tree/v1.1#esp8266-wifi-rgbww-led-dimmer)

Dann aus eigener Erfahrung:
Ich nutze das Board gerade mit 5x IRLZ34N - 1 RGB 5050 und 1 Weiss 0603 stripe
Die Mosfets werden dabei nichtmals handwarm ....
Der IRLZ34 verkraftet weniger Strom als der IRLZ44, also sollte da sogar noch mehr Spielraum nach oben sein

Ich kann heute Abend nochmal den Strom messen (Wieviel Pro Kanal und Insgesamt)

Und beim Controller Layout - irgendwann ist auch auf der Leiterplatine Schluss - die Leiterbahnen der einzelnen Kanäle sollten ohne bedenken 10A abhaben können - bei der gemeinsamen Masse wird es kritischer - da würde ich nicht mehr als insgesamt 30-40A 20-30A fließen lassen.

Aus den Leiterbahnen und den Mosfet Daten sind die 4.5A für mich als Safe enstanden.
Oder gibt es Einwände? (z.B. etwas außer acht gelassen?)

Zitat von: ext23 am 09 Februar 2016, 13:59:39
LogicLevel ist aber nicht gleich LogicLevel, da musst du aufpassen, 5V ist auch LogicLevel.

Siehe Datenblatt - der IRLZ ist voll ab 2.5V gesättigt - mit den 3,3V die wir vom ESP haben ist das Gewährleistet. (Vorrausgesetzt man bekommt keine gefälschten aus China - ist mir passiert.)

Zitat von: ext23 am 09 Februar 2016, 13:59:39
Ansonsten ist ein Treiber mit Sicherheit immer besser, aber ich hatte kein Platz mehr auf meinem Board. Und ich glaube bei den Strömen über die wir reden oO Der Großteil hier wird eh irgend welche LED billig Ware aus China verwenden weil man keine Lust hat 160 Euro für 5 Meter Osram LED Band zu bezahlen. Von daher liegt der Verlust noch an ganz anderen Stellen ;-) Ansonsten stimmt das natürlich, man sollte schon Energie sparen wo es nur geht.


Sollte man wirklich hohe Ströme schalten, dann rate ich immer Tempfühler bzw. Temp Sicherungen an die MOSFETs zu klemmen. Wenn die Hütte erst mal brennt ist es zu spät.

Wenn man einen extra Treiber verwenden möchte, kann man auch gleich die FETs austauschen und einen Treiber nehmen der z.B. die 12V schalten würde. Gibt günstigere MOSFETs als die IRLZ44. Ich hab für mich die "direkte" Steuerung gewählt. Sparrt Bauteile - wenn aber gewünscht ist und jemand einen passenden Treiber + FETs raussucht, kann man das Layout noch umändern

Bezüglich dem Wiederstand vor dem Gate - ich sehe ihn nicht als nötig, da wir nur die FETs ansteuern und die Umladelast sehr klein ist.
Aber es tut mir nicht weh noch 5 120Ohm Wiederstände einzubauen. (Der ESP liefert maximal 14mA pro Pin)

Aber da würde ich gerne nochmal einen Testaufbau machen um zu sehen inwiefern es Auswirkungen hat.

mMn würde der Wiederstand nur als Schutz für den ESP dienen, viel enstören tut er nicht.

Heya,

Ich greif diese beiden Punkte nochmal auf: SSL, Radius

Zitat von: ext23 am 09 Februar 2016, 11:24:22
- SSL für die Kommunikation

Der ESP SDK (espiff SDK) bietet keine server library für SSL an. Es ist möglich ausgehend Verbindungen via SSL zu benutzen. (z.B. einen webserver aufrufen um daten zu laden), aber ein Server ist bisher nicht implementiert.

Ich persönlich sehe nicht die Notwendigkeit für SSL - Um die Sicherheit im eigenen Heimnetzwerk zu erhöhen, ist SSL die falsche Stellschraube.


Der Controller bietet von sich aus 2 Sicherheitsmerkmale:
- Im Accesspoint Modus kann das Netzwerk mit WPA2-PSK gesichert sein
- Die OTA Webseite ist nur erreichbar, wenn der ESP mit einem AccessPoint/Router verbunden ist
- Die OTA Webseite kann zusätzlich mit einem Passwort gesichert werden*

*) Wenn der Angreifer sich schon im Heimnetzwerk befindet, könnte er es auslesen. Aber mal ehrlich, wenn der Angreifer schon im Netzwerk ist, ist der RGBW Controller die geringste Sorge  ;)

Zitat von: ext23 am 09 Februar 2016, 11:24:22
- Eventuell WLAN via Radius

Fällt flach, solange - der SDK von espressif  kein WPA Enterprise unterstützt

Naja wie leicht man in WLANs kommt muss man ja niemanden erklären. Vor allem wenn man sein Key nicht öfter mal ändert... Und das ist ein Spass bei vielen WLAN Geräten wenn man kein WPA Enterprise hat. Die WPA Keys lassen sich auf den Geräten ja wunderbar auslesen, da reicht ein kleiner Trojaner ;-)

Aber mei, nicht jeder benutzt wie mein Nachbar sein Zunamen als WPA Key, aber er rafft es nicht obwohl ich schon 10 schwarze Seite auf seinem Tintenspritzer gedruckt habe oO, also stimmt schon.

Aber gut wenn man tagtäglich mit zu tun hat wird man wohl etwas paranoid ;-)

/Daniel

Off Topic
Daniel bestaetigt den Eindruck und mein Bild von Ihm.
no more words.

Last uns nicht abschweifen bitte.

Hier gehts um den controller - ein aufregendes Projekt finde ich.

vg
joerg

Hallo zusammen,

ich hab jetzt mal kurz den Code (HSV2RGB & Farbkorrektor)  etwas gesäubert und in dem dev-branch auf Github geschoben

https://github.com/patrickjahns/RGBWWLed/tree/dev-v0.1

Anmerkung: Nach herumexperimentieren mit verschiedenen Rechenmodellen bin ich wieder bei einer einfachen IF/ELSE Abfrage für die Sektoren gelandet. Es gibt sogesehen 7 Grenzen - 6 Wertebereiche. Die 24byte Speicherbedarf dafür sind effektiver geutzt als komplexe Rechenmodelle  ;)

@ Joerg
Ich bräuchte mal kurz deine Meinung wegen der Gamma/Helligkeits Korrektur:

Ich hatte bei RGB (ohne W) keinen Unterschied sehen können, wenn die Helligkeits Korrektur vor bzw. nach der Berechnung der Werte statt findet.


Warum würdest du nur die Korrektur auf Value ansetzen? Die Sättigung ist doch auch nicht Linear?
Oder hab ich da einen Denkfehler?

Im Moment berechne ich die Werte nach der Rechnung von der Englischen HSV Seite (https://en.wikipedia.org/wiki/HSL_and_HSV#From_HSV)

Das entspricht dem von dir bisher genannten Vorgehen - erst werden die jeweiligen Farbanteile berechnet und zum Schluss der Weißanteil (m) auf R,G,B addiert.

---

SSL+Wifi Diskussion
Ich hatte es vorher schon geschrieben, dass es Limitationen vom SDK gibt.
Diskussion zu WPA Enterprise im ESP
(Siehe: https://github.com/esp8266/Arduino/issues/1032 und http://www.esp8266.com/viewtopic.php?f=6&t=1243&start=28)

Wenn die Dringlichkeit dieser Aspekte für jemanden sehr hoch ist, dann schlage ich vor, dass er sich daran macht, das Projekt zu Forken und es zu implementieren und dann der Community zur Verfügung zu stellen. Meine Augenmerkt ist im Moment auf zentraleren Funktionen (Led Ansteuerung, Einbindung) und alles was sich außerhalb diesen Dimensionen bewegt kommt auf eine "Vielleicht" Liste von mir.


Hardware Modifikationen
Für mich primär ist gerade wichtig, dass die Funktionalität von 5 PWM Kanälen für die Ansteuerung von LED Streifen via Wifi gewährleistet ist. Falls Erweiterungen gewünscht werden, dann wäre es mir wichtig, einen konkreten Vorschlag für die Umsetzung zu bekommen  ;)
(z.B. ich hätte gerne Z - dafür musst du GPIO A mit einem pull down versehen und auf eine Stifleiste nach außen führen.....)
Wenn die Modifikation mit der Grundfunktionalität vereinbar ist, dann kann ich das gerne in der Bestellung berücksichtigen. Falls die Modifikation aber wesentlich mehr ändert muss es auf eine Extra Ausführung verschoben werden.

Im Moment ist nur noch 1 GPIO frei - der ADC GPIO kann eventuell noch genutzt werden - GPIOs die für den Boot process pull ups/downs haben, könnten verwendet werden - wenn jemand eine entsprechende Logik/Schaltung entwirft. (Diese muss aber Gewährleisten, dass der ESP im "Normalbetrieb" ohne manuelle Eingriff startet).

boah, ich bin kurz raus ;)

das aufaddieren von W (m) ist ja nur notwendig wenn es ein RGB gemischtes Weiß ist.
Die Sättigung (in HSV) ist schon linear.

Um die logarithmische Helligkeitskorrektur anzuwenden gibt es ja grundsätzlich zwei Stellen:
Vor dem HSV2RGB(W) auf dem V Kanal oder danach auf jedem Kanal einzeln.

Wenn man das danach macht passieren aber zwei Sachen. Im Modell steigt (Sektor 1) ja grün linear an. Wenn man die Korrektur auf die einzelnen Kanäle anwendet wäre der Anstieg (hier GRÜN) nicht mehr linear sondern logarithmisch. Das führt zu einem breiteren ROT und schmalerem GELB. Dazu kommt das bei Mischfarben (bsp unkorrigiert 80%ROT, 20%GRÜN) ein reiner fade über die Helligkeit die relativen Farbanteile verändert. Damit verändert sich bei einem V-fade auch die Farbe.

Daher sehe ich die Korrektur vor dem HSV2RGB, also im HSV und dort nur auf dem V Kanal.

vg
joerg

Hi,

wo ich bei den ganzen Thread noch nicht so richtig durchblicke, für welchen Typ von LED Stripes ist denn nun die BastelPlatine geeignet?
RGBWW
RGB
WW
oder gar alle drei Varianten (natürlich mit Einschränkung)

//bb

So mal kurz den Hauptthread ergänzt:

Die "Hardware" des Controller stellt folgendes bereit:

• 5 Ausgänge zur Ansteuerung von LEDs via PWM (Primär gedacht als RGB, WarmWeiss und KaltWeiss*

*) Eine Änderung/Modifikation ist via der Firmware + Ansteuerung möglich - primär wird aber für RGB+W+W entwickelt

---

Beudetet - alles 3 ist möglich, sogar mehere Kombination.
Hauptfokus für mich liegt aber gerade auf RGBW (Wobei W aus kalt und WarmWeis gemischt wird).
Es ist später alles nur eine Frage der Erweiterung der Firmware/RGBWWLibrary um andere Funktionalität zu ermöglich.
(Es wird immer möglich sein, jedem Kanal "manuell" eine bestimmte Helligkeit zu geben - bedeutet theoretisch wären auch 5 Weiße Stripes möglich)

Zur hardware hab ich im anderen Thread schon was geschrieben - hab nen paar Sachen die letzten Tage nochmals getestet (auch aus Anregung der Gespräch zu Mosfets von hier)


Zur Software:
Mir hat dadurch die Zeit gefehlt viel weiter zu machen, aber ich hab mir noch ein paar Gedanken gemacht:
- die Library wird eine "AnimationsQueue" erhalten - Wechsel zu einer anderen Farbe ist nichts mehr als eine Animation; Effekte sind eine "besondere" Animation
- wenn intern schon eine Queue verwendet wird, dann kann man diese gleich nach außen zur Verfügung stellen -> man kann z.B. mehrere Farbwechsel in Auftrag geben die dann nacheinander abgearbeitet werden. In abstrackter Form sind so einfache Effekte auch vom Benutzer programmierbar über die API (für komplexeres kann man sich ja noch überlegen wie es implementiert werden kann)

Ich suche gerade aber nach einem Weg, wie man in C++ mit Structs/Unions und Klassen das am einfachsten implementieren kann, ohne den Speicher des ESP gleich zum überlaufen zu bringen.

Ideen? Vorschläge?

@Joerg

Du hattest doch einen Code zur Weißkorrektur für RGB, kannst du mir den mal zukommen lassen?
Falls du anderen Code/Codefetzen hast, die hilfreich sind für Animationen/Effekte dann auch gerne weiterleite - ich schaue dann mal was/wie ich das implementieren kann

Hallo,

ich verfolge das Projekt schon eine Weile. Hört sich sehr gut an und ich finde es auch sehr gut dass du eine Sammelbestellung auf die Beine stellst.

Wie  ich lese ist aktuell noch nicht implementiert das Modul in eine bestehendes Wlan mit WPA2 Verschlüsselung zu hängen. Die Einschränkung ist aber nur softwareseitig oder? Dann ist es nur eine Frage der Zeit.

Zitat von: kadettilac89 am 14 Februar 2016, 08:59:45
Hallo,

ich verfolge das Projekt schon eine Weile. Hört sich sehr gut an und ich finde es auch sehr gut dass du eine Sammelbestellung auf die Beine stellst.

Wie  ich lese ist aktuell noch nicht implementiert das Modul in eine bestehendes Wlan mit WPA2 Verschlüsselung zu hängen. Die Einschränkung ist aber nur softwareseitig oder? Dann ist es nur eine Frage der Zeit.

Die Anbindung an WPA2-psk (die Verschlüsselung die in den Routern für den Heimgebrauch vorzufinden ist) ist schon vorhanden - jediglich funktioniert WPA2-enterprise (Radius) nicht/eingeschränkt.

Zitat von: mrpj am 14 Februar 2016, 12:30:50
Die Anbindung an WPA2-psk (die Verschlüsselung die in den Routern für den Heimgebrauch vorzufinden ist) ist schon vorhanden - jediglich funktioniert WPA2-enterprise (Radius) nicht/eingeschränkt.

Perfekt, dann hab ich wahrscheinlich nicht alles gelesen. Danke dir!

Moin,

im anderen Thread hatte ich es ja schon kurz das update gepostet.

Ich habe nun HSV Transitions implementiert - (Video Hue 1 - 1 in 20s (https://www.dropbox.com/s/u0ivbqv5dkpan9c/VID_20160215_230325.mp4?dl=0))

Funktioniert einwandfrei mit 50fps - (PWM ist 200hz)


Aktuelle dev version der Library ist hier zu finden
https://github.com/patrickjahns/RGBWWLed/tree/dev-v0.2
PS: der Code ist noch ziemlich roh - Feinschliff kommt wenn die Funktionalität gegeben ist

Den Demosketch hab ich auchmal upgedated
https://github.com/patrickjahns/esp_rgbww_firmware


- Die Grundzüge für die Farbtemperatur (Kelvin) sind auch schon im code geschaffen - nun bräuchte ich mal Hilfe mit dem Algorithmus für den Weissabgleich für RGB, RGB+WarmWeiss, RGB+KaltWeiss, RGB+WarmWeiss/KaltWeiss.

Im anderen Thread hab ichs schon angekündigt - die weitere Entwicklung am Code muss ich in meiner Priorität bis Anfang April runter schrauben.

Funktioniert das eigentlich auch noch mit dem umfunktionierten IR-Controller?

Die Library kann man in allen ESP(LED) Projekten einsetzen, welche Modifikationen an der Firmware/Arduino Sketch nötig sind und welche Frequenz der Mod mitmacht, kann ich dir aber nicht sagen.

Trial and Error  ;)

---

Offtopic: Der Benutzername hat mich gerade begeistert  ;D

Hallo mrpj,

deine Platine bzw. die ESP müssen ja inital befüllt werden. Reicht hier ein billiger USB to serial wie dieser hier ...

http://de.aliexpress.com/item/1pcs-USB-to-TTL-USB-TTL-STC-microcontroller-programmer-PL2303-in-nine-upgrades-plate-with-a/696402213.html?spm=2114.010208.3.133.brHx3D&ws_ab_test=searchweb201556_2,searchweb201644_5_505_506_503_504_10020_502_10001_10002_10017_10010_10005_10011_10006_10003_10021_10004_10022_10009_10008_10018_10019,searchweb201560_2,searchweb1451318400_-1,searchweb1451318411_6451&btsid=b0e79818-8167-4636-b50f-bc9d9de60d79 (http://de.aliexpress.com/item/1pcs-USB-to-TTL-USB-TTL-STC-microcontroller-programmer-PL2303-in-nine-upgrades-plate-with-a/696402213.html?spm=2114.010208.3.133.brHx3D&ws_ab_test=searchweb201556_2,searchweb201644_5_505_506_503_504_10020_502_10001_10002_10017_10010_10005_10011_10006_10003_10021_10004_10022_10009_10008_10018_10019,searchweb201560_2,searchweb1451318400_-1,searchweb1451318411_6451&btsid=b0e79818-8167-4636-b50f-bc9d9de60d79)

Ich möchte mir diesen jetzt schon bestellen damit ich nicht im Anschluss nochmal 1 Monat warten muss.

Gibt es auch eine Möglichkeit den ESP initial mit einem Arduino nano zu flashen? Von denen hätte ich ein paar rumliegen. Frage nur mal in den Raum gestellt.

Zitat von: kadettilac89 am 26 Februar 2016, 09:37:04
Hallo mrpj,

deine Platine bzw. die ESP müssen ja inital befüllt werden. Reicht hier ein billiger USB to serial wie dieser hier ...

http://de.aliexpress.com/item/1pcs-USB-to-TTL-USB-TTL-STC-microcontroller-programmer-PL2303-in-nine-upgrades-plate-with-a/696402213.html?spm=2114.010208.3.133.brHx3D&ws_ab_test=searchweb201556_2,searchweb201644_5_505_506_503_504_10020_502_10001_10002_10017_10010_10005_10011_10006_10003_10021_10004_10022_10009_10008_10018_10019,searchweb201560_2,searchweb1451318400_-1,searchweb1451318411_6451&btsid=b0e79818-8167-4636-b50f-bc9d9de60d79 (http://de.aliexpress.com/item/1pcs-USB-to-TTL-USB-TTL-STC-microcontroller-programmer-PL2303-in-nine-upgrades-plate-with-a/696402213.html?spm=2114.010208.3.133.brHx3D&ws_ab_test=searchweb201556_2,searchweb201644_5_505_506_503_504_10020_502_10001_10002_10017_10010_10005_10011_10006_10003_10021_10004_10022_10009_10008_10018_10019,searchweb201560_2,searchweb1451318400_-1,searchweb1451318411_6451&btsid=b0e79818-8167-4636-b50f-bc9d9de60d79)

Ich möchte mir diesen jetzt schon bestellen damit ich nicht im Anschluss nochmal 1 Monat warten muss.

Gibt es auch eine Möglichkeit den ESP initial mit einem Arduino nano zu flashen? Von denen hätte ich ein paar rumliegen. Frage nur mal in den Raum gestellt.

Du musst aufpassen das dein USB2Seriell auch die 3,3 Volt an den RX/TX hat  .... ich glaube zu wissen das der ESP an die IO nicht 5 Volt tolerant ist.

Zitat von: AxelSchweiss am 26 Februar 2016, 09:58:48
Du musst aufpassen das dein USB2Seriell auch die 3,3 Volt an den RX/TX hat  .... ich glaube zu wissen das der ESP an die IO nicht 5 Volt tolerant ist.

Aber der geponstete Usb2Ttl würde passen wenn ich die RX-Spannung ggf. mit Widerständen auf 3,3 reduziere?

Spar nicht am falschen Platz und kauf dir z.B. so einen Adapter:
http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-/380887255552?hash=item58aea64a00:g:Ou4AAOSw7NNT-av~ (http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-/380887255552?hash=item58aea64a00:g:Ou4AAOSw7NNT-av~)
http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-TE203-/281909029942?hash=item41a3166c36:g:HdAAAOSwLN5Wl3lF (http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-TE203-/281909029942?hash=item41a3166c36:g:HdAAAOSwLN5Wl3lF)

Zitat von: AxelSchweiss am 26 Februar 2016, 11:13:47
Spar nicht am falschen Platz und kauf dir z.B. so einen Adapter:
http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-/380887255552?hash=item58aea64a00:g:Ou4AAOSw7NNT-av~ (http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-/380887255552?hash=item58aea64a00:g:Ou4AAOSw7NNT-av~)
http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-TE203-/281909029942?hash=item41a3166c36:g:HdAAAOSwLN5Wl3lF (http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-TE203-/281909029942?hash=item41a3166c36:g:HdAAAOSwLN5Wl3lF)

OK, dann nehm ich richtig Geld in die Hand und kauf mir den umschaltbaren :) ... danke fürs Feedback.

Sorry ich hab die Nachrichten jetzt erst gelesen -

AxelSchweiss hat es genau richtig beschrieben - der ESP verträgt nur 3.3V

Die Platinen mit "FT232L" sind meist zwischen 3.3V und 5V mit einem jumper umstellbar.
Günstiger als der link von Alex ist hier: http://www.aliexpress.com/wholesale?SearchText=FTDI+FT232RL+USB+to+TTL+Serial+Converter&opensearch=true

Sind auch meist in 2-3 Wochen da

Zitat von: mrpj am 27 Februar 2016, 15:08:53
Sorry ich hab die Nachrichten jetzt erst gelesen -

AxelSchweiss hat es genau richtig beschrieben - der ESP verträgt nur 3.3V

Die Platinen mit "FT232L" sind meist zwischen 3.3V und 5V mit einem jumper umstellbar.
Günstiger als der link von Alex ist hier: http://www.aliexpress.com/wholesale?SearchText=FTDI+FT232RL+USB+to+TTL+Serial+Converter&opensearch=true

Sind auch meist in 2-3 Wochen da

Danke, hab mir gestern schon einen bei Ali bestellt.

Moin,

nochmal wegen dem PWM (Für die Statistik). Hab eben mal mein Oszi an diesen UFO WiFi LED Controller gehangen, der arbeitet mit 431 Hz.

/Daniel

Da sich sicherlich einige nur für die RGBWW Bibliothek und nicht für den Controller interressieren, hier mal ein Querpost zu dem aktuellen Stand der Entwicklung der Bibliothek. Mithilfe bei den ToDos ist sehr erwünscht ;-)


RGBWW

Die Basis Funktionalität ist erstellt und gestetet. Eine Berechnung und Animation eines Farbwechsels funktioniert auf dem Controller flüssig und zuverlässig.

Die verschiedenen Ideen um die Farbausgabe des Controllers zu verändern wurden implementiert, so ist es möglich ähnlich wie im FHEM wifilight Modul die "Grundfarben" (Rot, Gelb, Grün, Cyan, Blau, Magenta) zu verschieben um die Wiedergabe von den Farben anzupassen.
Weiterhin ist es möglich, einzelne Farbkanäle in der Helligkeit von 0-100% zu regeln. Es ist eine zusätzliche Möglichkeit die Farben und Helligkeit anzupassen.

Der Controller besitzt die Möglichkeit mit verschiedenen Ausgabeverhalten zu arbeiten (nur RGB, RGB+Warmes Weiss, RGB+KaltesWeiss, RGB+Warm& Kalt Weiss)

Es ist möglich die Farbtemperatur des WeissKanals (bei der Nutzung von Warm und Kaltweiss) anzupassen

Derzeit sind "nur" 2 Animationen/Effekte vorhanden:

• Farbwechsel von Farbe A nach Farbe B im Zeitraum X (kurzer/langer Weg)
• Zeige Farbe A für den Zeitraum X  (X kann dauerhaft/unendlich bedeuten)

Ich denke jedoch, das diese beiden Animationen 95% dem Nutzungsverhalten entsprechen ;-)

Intern arbeitet die RGBWWLed Bibliothek mit einer Queue/Warteschleife - das bedeutet es ist möglich auch komplexere Animationsketten an den Controller zu schicken und diese werden dann nach und nach abgearbeitet.

Beispiel:
Farbwechsel von Farbe A zu Farbe B in 30 Sekunden; zeige Farbe B fur 60 Sekunden, Wechsel zu Farbe C in 10 Sekunden; Wechsel zu Farbe D in 180 Sekunden, Zeige Farbe D für 3600 Sekunden

RGBWW ToDos

Es gibt noch einige ToDos um die Bibliothek "komplett" zu machen bzw zu erweitern:

• Die Farbtemperatur kann im Moment nur zwischen den Warm/Kaltweissen Led Streifen verschoben werden

Eine Erweiterung wäre es, die Farbtemperatur durch Berechnung weiter zu verschieben bzw. auch zu verschieben, wenn nur ein Weisskanal / RGB vorhanden ist
Ich habe schon einige Ansätze gefunden - jedoch bisher aus Zeitnot nicht die Möglichkeit gehabt es mir genauer anzuschauen und die Berechnung letztendlich zu implementieren. Eine Mithilfe wäre hier sehr gewünscht

Mehr Informationen/Hintergrund Informationen
http://www.tannerhelland.com/4435/convert-temperature-rgb-algorithm-code/
http://www.cree.com/~/media/Files/Cree/LED-Components-and-Modules/XLamp/XLamp-Application-Notes/LED_color_mixing.pdf
https://web.archive.org/web/20131224221243/http://pidome.wordpress.com/2013/08/21/working-with-heating-and-cooling-light-colors
http://www.research.ed.ac.uk/portal/files/17162678/published_paper.pdf

• Implementierung von 2 weiteren Berechnungsmodelle um vom HSV Raum zum RGB+W Farbraum zu gelangen

Im Moment wird die Wandlung vom HSV zu RGB Farbraum mit dem "Standard" Algorithmus durchgeführt - dabei wird die Helligkeit insgesamt verschoben (z.B. sind bei Gelb Rote und Grüne Leds auf 100%) bzw. die Komposition entspricht nicht der natürlichen Wahrnehmung des Menschen 

Mehr Informationen dazu:
https://github.com/FastLED/FastLED/wiki/FastLED-HSV-Colors
http://www.fourmilab.ch/documents/specrend/
http://stackoverflow.com/questions/5162458/fade-through-more-more-natural-rainbow-spectrum-in-hsv-hsb

• Implementierung von weiteren Effekten/Animationen

Die Bibliothek hat schon ein abstraktes Interface für Animationen/Effekte, welches bereits für den Farbwechsel genutzt wird. Weitere Effekte können dadurch auf einfache Weise hinzugefügt werden


Sourcecode befindet sich hier:
https://github.com/patrickjahns/RGBWWLed

Was hältst du davon, die möglichkeit einzubauen, so eine selbst definierte Queue automatisch zu loopen. Dann braucht man nicht jedes mal neu die Befehle schicken, wenn man so ein dauerhaftes überblenden etc. will.

Viele Grüße,
Kuzl

Um das zu realisieren gibt es bereits 3 Möglichkeiten mit der Library:

1) Du erweiterst die Bibliothek um eine allgemeine Möglichkeit eine Gewisse Animationsreihenfolge (Array/Liste mit Pointern zu den jeweiligen Animationsobjekt) übergibst.

2) Du erstellst eine eigene AnimationsKlasse die von RGBWWLedAnimation erbt und implementierst dann das interface und schiebst diese Animation in die Qeue des RGBWWLed Objekts

3) Du nutzt void setAnimationCallback( void (*func)(RGBWWLed* led) ) und implementierst die Funktionalität in deinem Hauptprojekt selbst
AnimationCallback wird immer dann aufgerufen, wenn eine Animation (z.B. ein Farbübergang) zuende ist. Das kannst du dann abfangen und direkt eine neue Animation aus deiner Animationsliste in die Queue schieben


Option 1) bevorzuge ich, da es auch anderen Nutzern der Bibliothek zugut kommt.

Hallo,

auch wenn das Theme schon ein wenig älter ist, ist es für mich gerade topaktuell.

Ich bin bei genauerer Recherche über folgendes Projekt gestoßen: https://github.com/mariusmotea/diyHue

So wie ich das verstanden habe, werden Lampen oder LED Stripes mit dem ESP gesteuert und auf z.b. einem Raspberry läuft eine HUE Bridge emulation, die die Lampen in das HUE System einbindet und sie dadurch durch die originale HUE APP gesteuert werden können.

Der ESP wird nur mit einem der vorgefertigten Skripte geflasht und ins WLAN eingebunden.

Demnach müsste es doch auch möglich sein die Lampen dann auch direkt unter FHEM als HUE Lampe einzubinden.
Das Projekt unterstützt normale RGB Stripes, SK6812 rgbw und WS2812B RGB Stripes.

Wie ich finde eine sehr interassante Lösung...

Zitat von: hoffma0901 am 20 Mai 2017, 12:29:43
Demnach müsste es doch auch möglich sein die Lampen dann auch direkt unter FHEM als HUE Lampe einzubinden.

Das mit der Hue App klappt wunderbar nur das einbinden in FHEM leider nicht es gibt Probleme mit der Bridge.

Vielleicht hat ja schon jemand eine Lösung