ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

Begonnen von mrpj, 07 Februar 2016, 17:53:42

Vorheriges Thema - Nächstes Thema

mrpj

Macht euch mal keine Sorgen - falls etwas schief gegangen ist kann man mich immer kontaktieren und wir finden eine Lösung.

Ich für mich muss nur differenzieren ob jemand wirklich seinen Anteil möchte, oder ob es nur eine "Karteileiche" ist.

Zitat von: ext23 am 24 Februar 2016, 13:05:32
Aber gut 400mA, das sind doch nur peaks wenn der sendet oder? Mhh naja ist ja auch egal, DCDC Wandler sind eben wie Schaltnetzteile sehr anfällig, vor allem mit sinkendem Preis. Ich nutze übrigens gerne die DC/DC Wandler von Recom, klein und (bis jetzt) alle Ausfall frei. Wenn man nicht die Kopien aus Fernost nimmt :-( . Aber das ist natürlich auch eine andere Preisliga, also nicht geeignet wenn es billig sein muss. Bei mir kommt da ehe was anderes rauf, ich muss nur von 5V auf 3,3V. Ich habe beide Spannungen bei mir anliegen, also 24/12V für die Stripes und 5V für den Rest.

Das ist ne andere Ausgangslage - 5V auf 3.3V sind mit nem LDO kein Problem. Auch wenn 400mA peaks sind, kalkulier ich das ein.
Die Peaks kommen dann vor allem vor, wenn der ESP eine Verbindung zum AP (immer wieder mal) verliert oder die Verbindung generell "grenzwertig hinzu schlecht ist"- dann verbraucht er ziemlich viel. Ich finde das Risiko mit einem LDO in dieser Situation "zu hoch" ohne ausreichende Wärmeableitung. Der DC Wandler hat das Problem nicht ....

.....und ist auch noch freundlich zum Geldbeutel  ;) (Macht im Jahr hier 8 Euro aus - das sind immerhin schon 3 halbe in der Kneipe oder nen halber Bierkasten für Zuhause)


Wäre es für deinen spezielle fall nicht besser, wenn du das Design deinen (speziellen) Gegebenheiten anpasst und dann über dirtypcb einfach 10 Prototypen orderst? Bauteile (ESP und Mosfets kann ich dir auch ohne PCB zukommen lassen)

ext23

Ja naja das ist kein Problem, ich hab ja 2 Boards bestellt. Eins baue ich so auf wie beschrieben, sonst macht das ja kein Sinn. Und das andere werde ich ein bissel pimpen. Ich hab auch wenig Erfahrung mit dem verwendeten WLAN Controller, ich nutze die nur als Console zu WLAN Brücke für unser Lab um die Geräte per Tab zu konfigurieren, von daher muss man schauen. Wenn das Ding im Fehlerfall natürlich 400mA Dauerhaft zieht, ist das Peke wenn das Gehäuse von der Decke tropft, das stimmt schon.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

tomster

Zitat von: ext23 am 24 Februar 2016, 14:08:42
ich nutze die nur als Console zu WLAN Brücke für unser Lab um die Geräte per Tab zu konfigurieren,

Nur ganz kurz ein bissl off-teppich:
Das ist aber nicht zufällig eine Art WiFi-to-Serial-Bridge, vielleicht von WiFi nach RS485/RS232 oder so? Nach sowas würde ich nämlich gerade händeringend suchen...

mrpj

#108
Zitat von: ext23 am 24 Februar 2016, 14:08:42
Ja naja das ist kein Problem, ich hab ja 2 Boards bestellt. Eins baue ich so auf wie beschrieben, sonst macht das ja kein Sinn. Und das andere werde ich ein bissel pimpen. Ich hab auch wenig Erfahrung mit dem verwendeten WLAN Controller, ich nutze die nur als Console zu WLAN Brücke für unser Lab um die Geräte per Tab zu konfigurieren, von daher muss man schauen. Wenn das Ding im Fehlerfall natürlich 400mA Dauerhaft zieht, ist das Peke wenn das Gehäuse von der Decke tropft, das stimmt schon.

Naja die von mir beschriebenen Szenarien sind ja kein "Fehlerfall" sondern normale Szenarien die im Alltag durchaus passieren. Je nachdem wo man wohnt ist der WLAN Funkbereich ziemlich "verstopft" bzw sind viele verschiedene APs/Teilnehmer im selben Funkbereich/Kanal), da ist es dann nicht ungewöhnlich das Geräte mit höchster  Sendeleistung arbeiten um ihren gewünschten Empfangspartner noch zu erreichen. Auch sind die meisten verwendeten Router nicht umbedingt "stabil" - der Telekom Router der hier steht bringt mich manchmal echt zum verzweifeln - ab und an verliert er einfach Pakete für 2-3 Minuten und dann ist alles wieder beim alten. (In der Zeit kann ich beobachten wie der Stromverbrauch am ESP auch steigt).

Zum CHIP der beim DCDC Wandler verwendet wird, ist hier das Datenblatt:
http://www.seeedstudio.com/wiki/images/4/4e/MP1584_r1.0.pdf

Laut Datenblatt ist die Ausgangsspannung vom Eingang unabhängig - ich würde es dennoch lieber erstmal verifizieren bevor man zwischen 12 und 24V hin und her wechselt ;-). Datenblätter sind manchmal sehr geschöhnt. (Und manchmal bekommt man ganz andere Bauteile geliefert als drauf steht - z.B. gefälschte Mosfets  >:( >:( - daher werden die nun bei tme.eu geordert und nicht in Asien)




PS: Und die kosten von 55Cent für so ein Modul sind auch nicht viel teurer, als wenn ich LDO + Stabilisierung drum herum als Bestückung nehmen würde  ;)


ext23

Zitat von: tomster am 24 Februar 2016, 14:32:42
Nur ganz kurz ein bissl off-teppich:
Das ist aber nicht zufällig eine Art WiFi-to-Serial-Bridge, vielleicht von WiFi nach RS485/RS232 oder so? Nach sowas würde ich nämlich gerade händeringend suchen...

Genau so etwas ist das. Ich hab immer kein Bock im Lab zu sitzen wo es kalt ist, nur weil ich mal wieder ein paar Firewalls oder Cisco Büchsen erstkonfigurieren muss und unsere ganzen Terminal Consolen Switche alle voll sind.

Ist aber selber gebastelt im Flug verdrahtet. Als Stromversorgung USB, da kann man dann entweder die USB Buchse der Geräte nehmen oder ein Akkupack ran. Da drin ist ein kleiner converter von 5 auf 3,3V für den ESP. Und der hat diese Transparente Firmware drauf.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Morgennebel

Zitat von: tomster am 24 Februar 2016, 14:32:42
Nur ganz kurz ein bissl off-teppich:
Das ist aber nicht zufällig eine Art WiFi-to-Serial-Bridge, vielleicht von WiFi nach RS485/RS232 oder so? Nach sowas würde ich nämlich gerade händeringend suchen...

Schau mal hier: http://www.get-console.com/airconsole/

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

mrpj

Updates zu Sammelbestellung und Warteliste

Der Großteil der Forumsgemeinde hat schon seine Anteile bezahlt und das Geld ist bei mir eingetroffen - es fehlen heute noch die Geldeingäng von ca. 10 Mitgliedern.
Falls es knapp wird/wurde mit der Überweisung wäre ich für ein kurzes Lebenszeichen dankbar - auch wenn jemand sich anders entschieden hat.
Es erleichtert mir die Organisation um einiges und macht es auch angenehmer, wenn mit mir kommuniziert wird.  ;)

Ich habe heute die Bestellung von den Bauteilen aus Asien (DCDC Wandler, Esps) abgeschickt und damit beginnt das warten auf die Bauteile die "am längsten brauchen".

Nun zum ausstehenden Update mit der Warteliste: ich habe mich entschlossen 300 statt 200 PCBs auf eigenes Risiko zu ordern. Das bedeutet, dass jeder der sich eingtragen hat, noch teil der ersten Sammelbestellung wird.

Im laufe des Abends erhalten alle auf der Warteliste eine E-mail mit den Details.

Es sind nach aktuellem überschlagen von Warteliste und mir bekannten "ausfällen" noch knapp 80 Platinen die auf einen neuen Besitzer warten.
Die Anzahl der verfügbaren Platinen ist somit begrenzt - bei den Bauteilen aus Asien habe ich die Anzahl aus der Sammelbestellung und Warteliste + einen Puffer auf eigenes Risiko bestellt. D.h. es wird weiterhin die Möglichkeit geben, komplette Bausätz/Platinen in begrenzter Anzahl zu erhalten.


Ich habe darüber nachgedacht, wie ich die Situation handhaben möchte - vor allem auch im Bezug auf Fairness gegenüber den Forenmitgliedern die jetzt schon ihr Geld an mich überwiesen haben und dadurch erst die Bestellungen ermöglichten.

Für mich ist die Bestellung von mehr Platinen und Bauteilen "auf Vorrat" ein Risiko und bedeutet langfristig einen erhöhter logistischen Aufwand, da ich regelmäßig Formular, Bankkonto, Forum überprüfen muss, nachdem die Frist der Sammelbesteller verstrichen ist.

Daher werde ich die Preise für neue Bestellungen anpassen. (Auf das Niveau als wäre es eine kleinere Bestellung):







Ausführung
1) RGBWW Platine 2€
2) RGBWW Platine + Bauteile (ohne ESP)     6€
3) RGBWW Platine + Bauteile (mit ESP) 8,50€
4) RGBWW Platine fertige aufgebaut* 15€
*) Fertig gelötet und Firmware aufgespielt

Jeder der sich noch bis zum 06.03.2016 in die Sammelbestellung einträgt und sein Geld überweist, ist noch bei den aktuellen Preisen aus der Sammelbestellung mit dabei. (Solange verfügbar). Danach werde ich das Formular aktualisieren und die andere Preisstaffelung tritt in Kraft.

Ich hoffe das dieser Vorschlag im Sinne von allen ist

pc1246

Hallo mrpj

Ich kann Dich voll verstehen, und waere damit einverstanden, hab ja schon bezahlt. Da ich das sowieso so gesehen hatte, habe ich eh grosszuegig aufgerundet, und da denke ich bin ich nicht alleine!?
Gruss und Danke nochmals
Christoph
HP T610
Onkyo_AVR;Enigma2; SB_Server; SB_Player; HM-USB; PhilipsTV; harmony hub; Jeelink mit PCA301; Somfy; S7-300; LGW; HUE; HM-IP auf Charly; div

Roger

Hi mrpj,
vielen lieben Dank, dass Du nun auch noch die Warteliste mit belieferst  :).
Ich habe soeben überwiesen.

Roger
Zotac & RPIs mit 10*FHEM
2*HM-LAN, 2*JeeLink, 2*RS485, SignalESP
HomeMatic, PCA301 Komponenten, ModBus: Stromzähler, Fronius WR, Shelly, Victron

Andy89

#114
Servus,
ich habe gerade erst diesen Thread gesehen und bin froh, dass man sich noch bis zum 6.3 eintragen konnte. Habe direkt bestellt und das Geld überwiesen.

Vielen Dank schon ein Mal für die Mühe =)
Beste Grüße
Andy

P.s.: @PC1246: ganz alleine bist du sicher nicht. Hab auch mal bisschen mehr für paar Bier überwiesen  ;D
FHEM 6.0 auf rPi4 docker (mit Alexa & Siri); dbLog, FTUI, Sonos, XiaomiMapCreator auf rPi4 docker;
raspimatic auf rPi3+ > diverse Aktoren und Sensoren;
LGW > (PCA301),EC3000,LaCrosse; MQTT2 > WLAN-Steckdosen,Xiaomi Map;
Harmony Hub;Sonos;Onkyo AVR;RGB WLAN Controller;Netatmo;Withings;Unifi;AMAD

Icinger

Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

mrpj

Update

Ein kurzes Update - mehr gibt es am Wochenende allerspätestens am Wochenende darauf


  • Sammelbestellung

Bis auf 2 Sorgenkinder wovon nur 1. nicht erreichbar ist, hat alles mit der Bezahlung geklappt. Vielen Dank für die Motivationsbiere/Pizzen - die waren auch schon hilfreich um Abends nach dem Büro schnell was zu essen zu haben um weiter zu Programmieren  ;)


  • Bestellung der Bauteile

Bestellungen sind alle an die Händler rausgegangen - die Bauteile aus China sind alle "versandt"/auf dem Weg zu mir.
Die Großbestellung bei TME verschiebt sich um ein paar Tage, da wir die Menge an verfügbaren MOSFETs überschritten hatten  ::)


  • Firmware

Ich habe die Tage immer mal wieder etwas dafür getan - es geht vorran. Bei der Einbindung in FHEM und einigen aspekten bei der Berechnung der WeissFarbtemperatur hoffe ich auf Hilfe aus der Community

Dazu folgt aber ein längeres Update zeitnah -
Aber kurze Info: Ich habe den Framework von ARDUINO/ESP8266 auf SMING gewechselt (wechseln muessen). Der Framework ist zu Arduino Bibliotheken compatible - jedoch braucht man eine andere Entwicklungsumgebung. Das SMING Projekt ist zwar kleiner - aber die Community dahinter ist hilfsbereit und für Änderungen/Vorschläge offen, während ich bei der Arduino Community immer wieder an verschlossene Türen geraten bin  >:(

Mehr Informationen folgen bald - es fehlt nur die Zeit hier zu schreiben und sich um die Firmware gleichzeitig zu kümmern  ;)

mrpj

#117
Update

Wie im letzten post angekündigt, folgt nun ein etwas detailierteres update zur Entwicklung von Firmware und Library. Ich hatte die letzten Tage nochmal viel Zeit investiert um jeweils eine Basis zu erstellen, mit der auch die Community weiter arbeiten kann. Durch den regen Zuspruch aus dem Forum habe ich mich bemüht die Firmware nutzerfreundlicher zu gestalten - was leider auch viel Zeit und Resourcen in Anspruch genommen hat bzw. nimmt. Daher freue ich mich, wenn sich Mitglieder finden, die Interesse haben, bei der ein oder anderen Funktionalität mir unter die Arme zu greifen. (Besonders die Anbindung an FHEM)
Aber nun zu den updates:

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


Firmware
Die Erstellung der Firmware hat mich in den letzten Wochen einiges an Zeit und Nerven gekostet. Nachdem die LED Bibliothek soweit aufgebaut war, das auch komplexere Animationen/Farbübergänge möglich sind, habe ich damit gekämpft, dass die PWM Implementierung des ESP8266 Arduino Frameworks unzuverlässig ist. Vor allem wenn es darum geht mehr als 2 Kanäle gleichzeitig zu verändern.

Das der ESP8266 aber in der Lage ist zuverlässig merhere Kanäle mit PWM Signalen zu versorgen, bestätigte mir die Demo Anwendung des Herstellers espressif (mit dem offiziellen SDK zum Chip).

Als nächsten Schritt habe ich versucht, die Implementierung des espressif SDKs (der Arduino SDK basiert auf dem espressif SDK) zu nutzen. Nach mehreren fehlversuchen (in denen ich auch den Arduino framework umgeschrieben/umkompiliert hatte) habe ich das vorhaben erstmals aufgeben müssen. Es ist im Moment nicht möglich den offiziellen Arduino SDK und PWM zuverlässig zu nutzen.

Die Lösung der Situation gab sich, wie ich einen alternativen SDK  (SMING) gefunden habe, der im großen und ganzen zu Arduino (Bibliotheken) kompatibel ist. Dies ermöglichte es mir die bisherige Implementierung der Bibliothek weiter zu nutzen.

Es gab dennoch einige Hürden zu meistern und die Firmware ist noch nicht in einem für FHEM nutzbaren Zustand, jedoch wurden die Grundlagen geschaffen:


  • Konfiguration über Webinterface
Zur einfachen Konfiguration des Controllers wurde eine WebApplikation geschaffen, die mit dem ESP über eine JSON Api kommuniziert. Durch die Kommunikation über eine API ist es in Zukunft einfach möglich, den Controller an diverse andere (Heimautomatisierungs) Software anzubinden und ist nicht nur auf FHEM beschränkt.

Für die Webapplikation wird AngularJS in Kombination mit Angular-Material verwendet - wie ich finde eine gute Kombination um einfach zu bedienende (Web-)wedungen zu erstellen. Ein kleiner Nachteil ensteht durch diese Vernwendung: der Nutzer benötigt einen aktuellen Webbrowser (eine Anforderung die ich als "Standard" empfinde - alte Webbrowser haben oftmals Sicherheitslücken). Falls das Webinterface probleme bereit sollte, kann man den Controller jedoch immernoch über die JSON Api konfigurieren/ansteuern.
Im Anhang befinden sich Bilder vom Interface - die Funktionalität lässt sich dadurch ableiten, so dass ich es nicht extra im Text aufzähle



Nächste Schritte:

  • Implementierung einer OTA Update Möglichkeit
Die SMING Bibliothek bietet schon ein Interface, welches ich noch erweitern werde sodass ein getrenntes updaten von Firmware und Webinterface möglich ist.




  • Anbindung an FHEM
Die Anbindung an FHEM ist noch offen. Im Fokus der Entwicklung standen bisher die Led Library sowie die Kernkomponenten der Firmware (einfache Konfiguration, Flexibilität, Updates).
Der SMING framework bietet die Grundlage um Anbindungen via TCP/UDP Server und MQTT zu realisieren.
Dadurch dass ich mich mit FHEM und den Modulen nur bedingt auskenne - wäre ich sehr dankbar, wenn sich Leute aus dem Forum finden, die bei der Anbindung eine Feder führende Hand einnehmen. Letztendlich geht es hier darum, die Kommunikationsschnittstellen zu definieren und erst im nächsten Schritt zu implementieren.

Sming hat einige Beispielimplementierungen:
MQTT:
https://github.com/SmingHub/Sming/tree/develop/samples/MqttClient_Hello

UDPServer
https://github.com/SmingHub/Sming/tree/develop/samples/UdpServer_Echo

TCPServer:
https://github.com/SmingHub/Sming/tree/develop/samples/Telnet_TCPServer_TCPClient

Entwicklung/Sourcecode derzeit im "develop" branch hier:
https://github.com/patrickjahns/esp_rgbww_firmware/tree/develop

Torben

Vielen Dank auch meinerseits für dieses Projekt und die Organisation der Sammelbestellung. Es hat mich auch dazu motiviert, mich jetzt mit LED-Stripes zu beschäftigen.
Verstehe ich es richtig, dass man KEIN dimmbares Netzteil benötigt, sondern nur eines, LEDs an sich bedienen kann wie z.B. dieses: http://www.ebay.de/itm/Elektronischer-LED-Trafo-1-80-Watt-Ausg-12-Volt-Eing-220-240-Volt-Transformator-/301433945055?_trksid=p2141725.m3641.l6368

ak323

RaspberryPi 2 im 19" Rack mit 16x2 i2c LCD, FHEM, diverse HomeMatic, 1-Wire (8x DS18B20, 3x DS2408, 2x DS2413, 5x DS2401, DS2423 ATTiny) über DS9490R#, Waterkotte Ai1QE (WWPR) Wärmepumpe über Modbus, WH1080 über Signalduino, 433MHz Funksteckdosen, WiFi RGBWW via Tasmota, ...