ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

vbs · 31 Dezember 2016, 14:21:24

Zitat von: pjakobs am 31 Dezember 2016, 14:18:37
wenn ich das richtig sehe, liest Du aber nur die aktuellen h,s,v Werte des Moduls aus, oder? Die stehen, nachdem die Kette der Controller Befehle abgearbeitet wurde, auf dem Zielwert des letzten Befehls in der Queue. Weiter oben hast Du geschrieben, dass das update command nicht funktioniert, das wäre dann ein bug, und ich fürchte, den Code hat nie jemand wirklich getestet, das schau ich mir mal an.

Genau, das war mMn einfach nicht implementiert. Siehe: https://forum.fhem.de/index.php/topic,48918.msg549894.html#msg549894

Zitat von: pjakobs am 31 Dezember 2016, 14:18:37
Was ich eigentlich schon lange haben will, da bin ich mir mit Patrick aber nicht einig geworden ist, dass der Controller seinen aktuellen hsv Wert per mqtt publiziert und wir den zum hsv Reading machen. Das hätte für viele Szenarien erhebliche Vorteile, so auch hier. Es wäre z.B. auch möglich "slave" Controller zu konfigurieren (einfach über ein notify, zwar nicht ms synchron aber sicher gut genug).

Vielleicht nimmt sich ja mal jemand dessen in der Firmware an, ich fänd das den elegantesten Weg.

Genau, dann bräuchte man nichtmal pollen, fände ich auch super.

pjakobs · 31 Dezember 2016, 14:52:20

Zitat von: vbs am 31 Dezember 2016, 14:21:24
Genau, das war mMn einfach nicht implementiert. Siehe: https://forum.fhem.de/index.php/topic,48918.msg549894.html#msg549894
Genau, dann bräuchte man nichtmal pollen, fände ich auch super.

Hast Du dafür einen pull request offen? Ich schau's mir mal an, wenn's passt ist's super.

pj

vbs · 31 Dezember 2016, 14:57:20

Ja, der ist hier: https://github.com/patrickjahns/esp_rgbww_fhemmodule/pull/15

pjakobs · 31 Dezember 2016, 15:19:06

Zitat von: vbs am 31 Dezember 2016, 14:57:20
Ja, der ist hier: https://github.com/patrickjahns/esp_rgbww_fhemmodule/pull/15

ich hab den pull request jetzt gemerged weil ich auf die Schnelle keine Probleme sehen konnte, grundsätzlich wäre es aber sinnvoll, sowas gegen den "develop" branch zu machen.

Danke für die Hilfe

pj

pjakobs · 31 Dezember 2016, 15:35:59

Sammelbestellung, nächster Versuch

Patrick hatte ja mal eine zweite Sammelbestellung angeschoben, aber leider kam ihm dann offenbar jede Menge Leben dazwischen.
Nachdem ich noch einen ganzen Schwung Controller brauche würde ich gerne von Euch nochmal hören, welchen Bedarf Ihr seht. Die Bedingungen bleiben inetwa gleich, der Preis irgendwo bei 8-10EUR plus Versand, wobei ich noch keine aktuellen sicheren Preise für die Bauteile rausgesucht habe, aber die dürften im Bereich +/- 50ct zu letztem Sommer liegen.
Bezahlung per Vorkasse, Versand wenn die Ware hier eintrifft und einzeln eingetütet ist. Je nach Lieferant sind aktuell Lieferzeiten bis zu 45 Tage für einige der China Komponenten zu erwarten, bei den Platinen habe ich noch keine Erfahrung.
Ich würde mal mutmaßen, dass wir Ende Februar dann Controller in Händen halten.
Patrick hatte die Details schon vor einiger Zeit in diesem Post beschrieben.
Einfach, um mal den Bedarf abzufragen, füllt doch bitte mal dieses Google Forumlar aus.

Danke

pj

Per · 31 Dezember 2016, 16:28:52

Zitat von: pjakobs am 31 Dezember 2016, 15:35:59füllt doch bitte mal dieses Google Forumlar aus.

Name? Forum-Nick oder real oder beides?

pjakobs · 31 Dezember 2016, 17:43:54

Zitat von: Per am 31 Dezember 2016, 16:28:52
Name? Forum-Nick oder real oder beides?

Is mir im Moment egal, es geht mir hier nur drum, mal festzustellen, wieviele wir denn zusammen bekommen, dann können wir sauber planen und dann gibt's die offizielle Bestellung.

der Plan war immer, mindestens 100 Bausätze zusammen zu bekommen. Wenn ich die zahlen der ersten vier sehe, dürfte das kein echtes Problem werden.

pj

Per · 02 Januar 2017, 08:59:10

Ich hatte vor einem halben Jahr (?) schon mal den Tread ausgezählt und war deutlich über 100!

RaspiLED · 02 Januar 2017, 09:33:10

Nein, er meint für die nächste Sammelbestellung! Also ein neues Ziel

Gruß Arnd

Gesendet von iPhone mit Tapatalk

pjakobs · 02 Januar 2017, 11:14:32

Zitat von: RaspiLED am 02 Januar 2017, 09:33:10
Nein, er meint für die nächste Sammelbestellung! Also ein neues Ziel
Gruß Arnd

Gesendet von iPhone mit Tapatalk

so ist es, und wer vor einem halben Jahr hätte bestellen wollen, der hat vielleicht in der Zwischenzeit eine andere Lösung gefunden.

pj

Per · 02 Januar 2017, 12:28:33

Zitat von: vbs am 31 Dezember 2016, 14:03:40Ist mir eigentlich alles zu komplex und zu viel Code

Den DOIF-Teil würde ich schonmal etwas verschlanken.

Code Auswählen


define Taster2cycle DOIF ([Taster] eq "longpress on")
	((setreading LED cycling 1,set LED update))
DOELSEIF ([Taster] eq "longpress release")
	(setreading LED cycling 0,set LED update)
DOELSEIF ([Taster] eq "shortpress release")
	(set LED toggle)

attr Taster2cycle cmdState run|stop|off
attr Taster2cycle repeatsame 0:1:1
attr Taster2cycle repeatcmd  .2:0:0

Bei Perl bin ich eher außen vor (die Routinen müssten aber entsprechend angepasst werden), allerdings würde ich die Rampe nicht bei Max auf 0 springen lassen, sondern eher die Richtung umkehren. Vllt. auch bei jedem Longpress erneut?!
Weiterhin könnte man über einen Timer festlegen, dass, wird kurzpress kurz nach einem longpress release erkannt, kein toggle, sondern ein "einmaliger cycling" Befehl in alter Richtung abgesetzt wird.

vbs · 02 Januar 2017, 13:42:06

Zitat von: Per am 02 Januar 2017, 12:28:33
Den DOIF-Teil würde ich schonmal etwas verschlanken.

Die Sache hat leider einen Haken: ich hab bei mir leider kein longpress. Du bist bei HM-Tastern, oder? Es muss daher bei mir wirklich mit einem Event gehen (RFX).

Zitat von: Per am 02 Januar 2017, 12:28:33
Bei Perl bin ich eher außen vor (die Routinen müssten aber entsprechend angepasst werden), allerdings würde ich die Rampe nicht bei Max auf 0 springen lassen, sondern eher die Richtung umkehren.

Hm, aber warum? Es handelt sich ja um einen Farbkreis.

pjakobs · 02 Januar 2017, 13:53:36

Ich hab Euch mal ein "stop" Kommando gebaut, zu finden im "feature_stop" branch.
Es hat u.U. einen Haken, weil es einen non-blocking Call absetzt, d.h. es könnte fhem einfrieren, allerdings habe ich das timeout auf 2s gesetzt, damit dürfte nicht viel passieren. Es setzt zudem, um die Animation zu beenden, den aktuell ausgelesenen Wert. Da die Animation aber nach dem "get color" Aufruf weiter läuft, wird die Farbe mit dem "stop" ein kleines bisschen zurückspringen. Wie viel lässt sich nicht leicht sagen, da das von der Animationsgeschwindigkeit, der Netzwerklatenz und etlichen Anderen Dingen abhängt.
Testet das mal ausgiebig und lasst mich wissen, ob es Euch hilft.

There may be dragons!

Grüße

pj

(btw, eigentlich gehört diese Diskussion ja eher rüber in den "fhem modul" thread)

vbs · 02 Januar 2017, 14:27:01

Hey, super Sache, danke!
Das hat mich auch direkt auf eine Idee gebracht, wie man das Ganze sogar non-blocking machen könnte. Musste ich sofort einbauen

Kannst ja mal gucken, ob dir das gefällt: https://github.com/verybadsoldier/esp_rgbww_fhemmodule/tree/stop_non_blocking

Hat mMn den Vorteil, dass es nicht blockiert und außerdem wirklich super simpel und kaum neuen Code braucht.

pjakobs · 02 Januar 2017, 17:17:16

Zitat von: vbs am 02 Januar 2017, 14:27:01
Hey, super Sache, danke!
Das hat mich auch direkt auf eine Idee gebracht, wie man das Ganze sogar non-blocking machen könnte. Musste ich sofort einbauen
Kannst ja mal gucken, ob dir das gefällt: https://github.com/verybadsoldier/esp_rgbww_fhemmodule/tree/stop_non_blocking

Hat mMn den Vorteil, dass es nicht blockiert und außerdem wirklich super simpel und kaum neuen Code braucht.

stimmt, gute Idee! Ich sehe auf die Schnelle auch keine Seiteneffekte, sollte problemlos sein.
Mach mal nen Pull Request gegen develop, dann nehm ich das. Wobei ich die blocking Funktion drinbehalten möchte, denn die können wir später ggf. noch brauchen.

pj