ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[Torben]

Hallo,

ich wollte mich auch noch mal herzlich für Deinen Einsatz bedanken. Es ist echt ein cooles Projekt. Nur meinen beschränkten Lötkünste haben es etwas schwierig gemacht. Da hat mich freundlicherweise Pf@nne ziemlich unter die Arme gegriffen.

Nun ist eine Esstischlampe rausgekommen. Sie hat jeweils einen 5050er RGW und einen 2835er WW Streifen parallel nebeneinander. Ich habe zwei Controller eingebaut, damit man die Streifen, die nach oben zeigen unabhängig von denen nach unten und zur Seite steuern kann.
Als nächstes kommt dann noch die Integration in fhem, damit ich sie über eine Elro-Fernbedienung an und ausschalten kann. Für die Farbeinstellungen muss ich mir dann noch mal Gedanken machen.

Viele Grüße
Torben

[kadettilac89]

Danke dir für die Mühe und die ganzen Informationen!

Ich werde mich die Tage durcharbeiten - zuerst zu dem CURL Problem, dass ich gerade direkt beantworten kann.

Der Curl String mit POST passt - ich gehe dem ganzen nochmal die Woche auf den Grund.
Zu den Fehlern:

Code Auswählen Erweitern


"{"error":"bad request"}"


GET requests enthalten nach RFC keinen Inhalt - nur URL Parameter sind möglich.
Daher reagiert /system nur auf POST

Code Auswählen Erweitern

curl -v -H "Content-Type: application/json" -X POST -d '{ "cmd": "restart" }'  http://192.168.0.60/system.168.0.60/system


mit "restart" funktioniert die Kommunikation, "success:true".

Beim debuggen werden aber 2 Parameter gesetzt, kann es sein, dass im API die Auswertung nicht ganz passt oder die Verkettung im Befehl? Wenn du mir einen Build zukommen lässt bei dem Debugging permanent aktiv ist kann ich das auch flashen (debug-Firmware).

[tomster]

So, nun habe ich es endlich auch geschafft die Firmware zu Flashen. Hat im Großen und Ganzen reibungslos geklappt. Ich würde nur Pf@nne bitten das Bild mit den Einstellungen des expressif-Tools im "So Flashe ich richtig"-Posting noch zu Korrigieren.
https://forum.fhem.de/index.php/topic,48918.msg443761.html#msg443761
Dort zeigen die Einstellungen den Speicherbereich 0x30000 für das SPIFF. Das müsste aber 0x10000 heissen, sonst ist das WebUI nach dem Flashen nicht erreichbar.

Jetzt brauch ich nur noch einen LED-Strip mit WW. Vor lauter Wurschteln an anderen Dingen hab ich doch glatt vergessen einen zu Besorgen...

[herrmannj]

Hello @all,

im Anhang eine erste Version des fhem moduls.

!!! :
Es handelt sich um eine erste und sehr rudimentäre Version.
Es finden kaum Fehlerbehandlungen statt. Bitte nicht produktiv einsetzen! Ich garantiere das sie fhem zum Absturz bringen kann, bspw durch falsche Eingaben.

Unterstützt werden derzeit zwei sets:
'HSB' (ist exakt HSV. Das "B" steht für brightness, scheint mir etwas angenehmer als das Value "V")
Der Syntax entspricht Wifilight, also set led HSB H,S,B [time] [sql]

'update', holt die aktuellen HSB (HSV) Werte vom controller.

Nach einem set HSB werden die readings aktualisiert. Beim starten wird ebenfalls der aktuelle Status geholt.

define mit name LedController ip

Es fehlt noch viel:
Keine RGB Readings, ergo kein widget.
Beim faden werden die readings nicht aktualisiert.
Mein controller benötigt bisweilen einige Sekunden (>10) um einen Befehl anzunehmen. Technisch gesehen dauert der connect solange. Weil das modul asynchron arbeitet hat das keinen Einfluss den Rest von fhem. Allerdings kann das dazu führen das man versucht einen neuen Befehl abzusetzen obwohl der aktuelle noch nicht durch ist. Da muss ich mir noch was gegen einfallen lassen.

Es handelt sich um eine erste POC Version. In der Hauptsache veröffentliche ich diese Version für erste Test und da ich bis Ende Mai auf Dienstreise bin und erst danach weitermachen kann.

vg
joerg

[r_knipp]

Der Syntax entspricht Wifilight, also set led HSB H,S,B [time] [sql]

Warum dann nicht in Wifilight den Controller mit aufnehmen? Oder würde das nicht funktionieren?

[herrmannj]

Der controller von mprj funktioniert anders (und viel besser ) als die anderen.

Deswegen muss das modul einige Sachen anders machen und es ist, Stand heute, vorteilhaft das getrennt von WifiLight zu programmieren. Für Dich als Anwender macht das doch keinen Unterschied, oder ?

vg
joerg

[r_knipp]

Der controller von mprj funktioniert anders (und viel besser ) als die anderen.

Achso, OK.

Für Dich als Anwender macht das doch keinen Unterschied, oder ?

Nein, natürlich nicht.

[vbs]

Habe gerade zwei Controller per UART auf 0.3.0 geupdatet. Keine Probleme gehabt. Flashen ging auf Anhieb bei 115200 Baud. Webinterfaces sofort erreichbar. OTA-Update noch nicht probiert.

[mrpj]

(https://forum.fhem.de/index.php?action=dlattach;topic=48918.0;attach=52445;image)
Sammelbestellung update

Gestern Vormittag sind (fast alle) fertigen Controller in den Versand gegangen. Status siehe https://goo.gl/kGuiis

Die ausstehenden 2 Päkchen gehen Montag/Dienstag in den Versand.

Der Versand ist somit "nur" 3 Wochen verspätet zum ursprünglichen Zeitplan - Lieferschwierigkeiten von TME sei Dank  .



Hinweis
Die Controller haben unterschiedliche Webinterface Versionen (0.3.0 - 0.3.3). Vor 0.3.3 gibt es einige kleinere Fehler im Webinterface, daher ist ein update zu empfehlen.
Sollte es Probleme geben beim Verbinden/Update - keine Panik - das ganze lässt sich auch ohne Webinterface regeln. Aber dazu dann mehr, wenn wirklich Probleme auftreten.

Weitere Hinweise aus dem letzten update:
https://forum.fhem.de/index.php/topic,48918.msg449584.html#msg449584

Wie gehts weiter?
Ich werde die nächsten Tage mal eine Pause von dem Projekt einlegen und mir etwas Freizeit gönnen. Danach unterstütze ich Joerg und Marco weiterhin bei der Integration in FHEM.
Weiterhin werde ich in den nächsten Tage in Ruhe den Thread durchgehen, die erste Seite auf den aktuellen Stand bringen und die bisherigen Fehler zusammen fassen.
Gleichzeitig schreibe ich in den nächsten Tagen die noch ausstehende Dokumentation auf Github weiter


Für alle die, die noch nach weiteren Bauteilen/Kits gefragt haben - es sind keine weiteren Bauteile/Kits derzeit über. Alles weitere zu einer zukünftigen Sammelbestellung lässt sich nach der Pause klären

[mrpj]

ich wollte mich auch noch mal herzlich für Deinen Einsatz bedanken. Es ist echt ein cooles Projekt. Nur meinen beschränkten Lötkünste haben es etwas schwierig gemacht. Da hat mich freundlicherweise Pf@nne ziemlich unter die Arme gegriffen.

Danke dir! Die Lampe sieht echt super aus! Ich bin auf weitere Bilder aus den Forengemeinde gespannt 

Beim faden werden die readings nicht aktualisiert.
Mein controller benötigt bisweilen einige Sekunden (>10) um einen Befehl anzunehmen. Technisch gesehen dauert der connect solange. Weil das modul asynchron arbeitet hat das keinen Einfluss den Rest von fhem. Allerdings kann das dazu führen das man versucht einen neuen Befehl abzusetzen obwohl der aktuelle noch nicht durch ist. Da muss ich mir noch was gegen einfallen lassen.

Die 10 Sekunden kommen mir immernoch etwas seltsam vor - eventuell wäre hier Feedback aus der community nochmal wichtig.

Frage:
Liegt es eventuell an dem Perl HTTP Modul? Dauert eine Verbindung auch zu gängigen Webseiten so lange?

Die Option mit Websockets steht uns ja immernoch offen - lass mich wissen und dann können wir das ganze bei Bedarf auch noch angehen

Beim debuggen werden aber 2 Parameter gesetzt, kann es sein, dass im API die Auswertung nicht ganz passt oder die Verkettung im Befehl? Wenn du mir einen Build zukommen lässt bei dem Debugging permanent aktiv ist kann ich das auch flashen (debug-Firmware).

Deine Vermutung ist fast korrekt - im Code war der Buffer für das parsen für den /system Endpunkt zu klein gewählt. In der nächsten Firmware Version ist es behoben.
In der Zwischenzeit bin ich flexibel - ich kann dir eine Version schicken in der es behoben ist, oder aber wir warten noch bis zum nächsten Firmware release.

Wie ist es dir lieber?

Habe gerade zwei Controller per UART auf 0.3.0 geupdatet. Keine Probleme gehabt. Flashen ging auf Anhieb bei 115200 Baud. Webinterfaces sofort erreichbar. OTA-Update noch nicht probiert.

Zur Baudrate noch was:
Ich habe zum flashen der 80 ESPs das Tool von espressif genommen:
http://bbs.espressif.com/viewtopic.php?t=25

Ich konnte dort die ganzen ESPs mit 576000 Baudrate mit einem FTDI232 (von aliexpress) flashen. Ich vermute mal, dass bei Probleme eine Kombination aus OS+Treiber+Chip zu den Fehlern davor geführt hat. Anders kann ich es mir nicht erklären

[kadettilac89]

Deine Vermutung ist fast korrekt - im Code war der Buffer für das parsen für den /system Endpunkt zu klein gewählt. In der nächsten Firmware Version ist es behoben.
In der Zwischenzeit bin ich flexibel - ich kann dir eine Version schicken in der es behoben ist, oder aber wir warten noch bis zum nächsten Firmware release.

Wie ist es dir lieber?

Wie am Anfang erwähnt, mir ist es aufgefallen, ich nutze aber den Controller nur über Smartphone. Die Analyse hab ich gemacht damit die Firmware den letzten Schliff bekommt. Ich habe auch kein Problem damit wenn es auf hold gesetzt wird. Priority low.

Nimm dir eine Auszeit und genieße das schöne Wetter.

[Icinger]

Die 10 Sekunden kommen mir immernoch etwas seltsam vor - eventuell wäre hier Feedback aus der community nochmal wichtig.

Habe jetzt mal einen Controller testweise in FHEM angelegt, und kann eigentlich so gut wie keine Verzögerungen feststellen beim schalten.
Habe es öfters probiert, gestern, heute morgen, jetzt grad auch wieder.
Lässt sich absolut problemlos (und eben ohne Verzögerung) schalten.

lg, Stefan

PS: Geniesse die Pause

[hermanski.k]

Bin absoluter Anfänger in Sachen FHEM. Kann mir jemand erklären wie ich das .pm Modul installieren und einrichten muss.

Vielen Dank.

[mahowi]

Mein Controller ist heute angekommen. 

Vielen Dank an Patrick für die Mühen! 
Jetzt muß ich nur noch Zeit finden, ihn auch zu testen und einzusetzen.

[urmel86]

Auch bei mir kam heute das Paket mit den Controllern an. Alles drin. Danke für die Mühe!

Gesendet von meinem Find7 mit Tapatalk