ESP RGBWW Wifi Led Controller - fhem - Modul

[pjakobs]

Oh - Alles gut. Das hatte ich auch keinesfalls so aufgefasst. Ich wollte Dich vor dem Frust bewahren jetzt alles einzurichten und dann in einigen Tagen alles wieder neu, evtl sogar anders, machen zu müssen. Alles jut

vg
joerg

na ja, mal abgesehen von groß/KLEINschreibung sollte das Interface doch mehr oder weniger gleich bleiben, ich würde es jedenfalls versuchen wollen. Bei Readings (und m.E. damit automatisch bei Settings) hatten wir uns auf Kleinschreibung geeinigt, oder?

@kadettilac89 ich denke, Du kannst hsv und rgb auf alle Fälle verwenden.

Die erweiterten Möglichkeiten werden sich sicher hie und da noch ändern, und so ein paar Dinge sind gewiss noch buggy, aber ich habe jetzt einen Teil meiner täglich genutzten Beleuchtung darauf umgestellt - habe also durchaus ein Interesse immer eine funktionsfähige Version zu liefern

Grüße

pj

[mrpj]

Hallo ihr,

ich hab heute mal mich mit dem "solid" Bug auseinander gesetzt und den Fehler behoben. Bevor ich die auf Github pusche, dachte ich mir, ich lass euch das mal testen. Im Anhang ist also das aktuellste rom.

Folgender python code läuft bei mir einwandfrei:
- fade von schwarz nach HSV(0, 100, 100) in 1 Sekunde
- bleibe bei HSV(0, 100,100) für 2 Sekunden
- fade auf HSV(60, 100, 100) in 1 Sekunde
- bleibe bei HSV(60, 100, 100) für 4 Sekunden
- fade auf HSV(210, 100, 100) in 10 Sekunden
- bleibe bei HSV(210, 100, 100) für 10 Sekunden
- schwarz

Code Auswählen Erweitern


import requests
import json
import time

solid1 = {"hsv":{"h":0.0,"s":100.0,"v":100.0,"ct":0},"cmd":"solid", "t":2000, "q": 1}
solid2 = {"hsv":{"h":60.0,"s":100.0,"v":100.0,"ct":0},"cmd":"solid", "t":4000, "q": 1}
solid3 = {"hsv":{"h":210.0,"s":100.0,"v":100.0,"ct":0},"cmd":"solid", "t":10000, "q": 1}

fade1 = {"hsv":{"h":0.0,"s":100.0,"v":100.0,"ct":0},"cmd":"fade", "t":1000, "q": 1}
fade2 = {"hsv":{"h":60.0,"s":100.0,"v":100.0,"ct":0},"cmd":"fade", "t":1000, "q": 1}
fade3 = {"hsv":{"h":210.0,"s":100.0,"v":100.0,"ct":0},"cmd":"fade", "t":10000, "q": 1}

black1 = {"hsv":{"h":0.0,"s":100.0,"v":0.0,"ct":0},"cmd":"solid", "t":20, "q": 1}
black3 = {"hsv":{"h":210.0,"s":100.0,"v":0.0,"ct":0},"cmd":"solid", "t":20, "q": 1}

if __name__ == '__main__':
r = requests.post(url, data=json.dumps(black1))
r = requests.post(url, data=json.dumps(fade1))
r = requests.post(url, data=json.dumps(solid1))
r = requests.post(url, data=json.dumps(fade2))
r = requests.post(url, data=json.dumps(solid2))
r = requests.post(url, data=json.dumps(fade3))
r = requests.post(url, data=json.dumps(solid3))
r = requests.post(url, data=json.dumps(black3))



PS:
Das Update führt noch eine Erweiterung für /color ein: es ist nun möglich von einer definierten Farbe auf die Endfarbe zu Faden:

Beispiel:

Code Auswählen Erweitern


{
  "hsv": {
   "h": 200.0,
   "s": 100.0,
   "v": 100.0,
   "ct": 2700,
   "from": {
      "h": 10.0,
      "s": 100.0,
      "v": 100.0,
      "ct": 2700,
   }
  },
  cmd: "fade",
  "t": 600,
  "q": false,
  "d": 1
 
}


Ist z.B. Hilfreich beim faden von einem "Aus" (schwarz) Zustand auf einen "An" Zustand wenn sich der H Wert ändern würde. Z.b. wenn man der alte Wert im Controller noch HSV(60, 100, 0) ist - man nun aber eigentlich auf die Farbe HSV(210, 100, 100) "anschalten" möchte. Zuvor würde der Controller von dem alten Hue Wert faden - nun ist es einfach möglich zu sagen, fade von HSV(210, 100, 0) auf HSV(210, 100, 100)

Ich hab es nur schnell getestet - Feedback und eigene Erfahrung gerne gesehen

[pjakobs]

klasse! ich hab heute eh gerade einen neuen Controller gelötet, ich werd das morgen testen.

danke & Grüße

pj

[herrmannj]

@mrpj: super, Danke!

@pjakobs

Der Umbau am modul ist so etwas umfangreicher.
Der asynchrone call ist soweit angelegt. Als nächtes queue ich die set, parametriere die api call (gehen jetzt statisch auf /info) und bau den parser für die Antworten rein.

Ein call sieht jetzt so aus:

Code Auswählen Erweitern

2016.06.30 00:54:42.521 4: led: API call init
2016.06.30 00:54:42.525 4: led: connected
2016.06.30 00:54:42.525 4: led: send 49 from 49 chars
2016.06.30 00:54:42.539 4: led: recv 464 chars
2016.06.30 00:54:42.539 4: led: response code is 200
2016.06.30 00:54:42.539 4: led: response length is 341
2016.06.30 00:54:42.539 4: led: close connection

damit bin ich sehr zufrieden.

vg
joerg

[pjakobs]

@mrpj: super, Danke!

@pjakobs

Der Umbau am modul ist so etwas umfangreicher.
Der asynchrone call ist soweit angelegt. Als nächtes queue ich die set, parametriere die api call (gehen jetzt statisch auf /info) und bau den parser für die Antworten rein.

Ein call sieht jetzt so aus:

Code Auswählen Erweitern

2016.06.30 00:54:42.521 4: led: API call init
2016.06.30 00:54:42.525 4: led: connected
2016.06.30 00:54:42.525 4: led: send 49 from 49 chars
2016.06.30 00:54:42.539 4: led: recv 464 chars
2016.06.30 00:54:42.539 4: led: response code is 200
2016.06.30 00:54:42.539 4: led: response length is 341
2016.06.30 00:54:42.539 4: led: close connection

damit bin ich sehr zufrieden.

vg
joerg

wenn ich das richtig sehe, hast Du die Queue jetzt auf der Kommando, nicht mehr der API Ebene angelegt?

pj

[herrmannj]

wenn ich das richtig sehe, hast Du die Queue jetzt auf der Kommando, nicht mehr der API Ebene angelegt?

pj

Wie jetzt ?

Das log sind api calls. Knapp 200msec, trotzdem async. Zwischen jedem Eintrag ist "Platz".

vg
joerg

[mrpj]

Gibt es von euch beiden Feedback zur Firmware? Wenn es keine Probleme mehr gibt pushe ich am Wochenende den neuen Release 

[herrmannj]

sorry, konnte niich nicht testen.

Kann ich die eigentlich auch schon ota aufspielen ?

Danke vg
joerg

[mrpj]

Ja - muss nur auf nem eigenen server gehostet werden  .

Python tool dazu ist im git repository:
https://github.com/patrickjahns/esp_rgbww_firmware/tree/master/tools

Rom und Spiffs (von der vorherigen Firmware) in das selbe Verzeichnis wie das Python script und der updateserver ist dann unter http://computerip/version.json erreichbar.

[pjakobs]

Ja - muss nur auf nem eigenen server gehostet werden  .

Python tool dazu ist im git repository:
https://github.com/patrickjahns/esp_rgbww_firmware/tree/master/tools

Rom und Spiffs (von der vorherigen Firmware) in das selbe Verzeichnis wie das Python script und der updateserver ist dann unter http://computerip/version.json erreichbar.

hmm.. ich bekomme zwar die Dateien angezeigt, aber nicht die Versionen - was fehlt mir?

Code Auswählen Erweitern


{"rom": {"fw_version": "unknown", "url": "http://192.168.29.15:88/rom0.bin"}, "spiffs": {"url": "http://192.168.29.15:88/spiff_rom.bin", "webapp_version": "unknown"}}


pj

[pjakobs]

so, OTA vom lokalen Server hat funktioniert. Ich hab im fhem Modul den "pause" Befehl wieder auf "solid" umgebaut und - jetzt scheint das auch zu funktionieren. Das Timing ist noch etwas unvorhersagbar, aber ich bin mir nicht sicher, ob das am Queueing liegt, ich warte mal, was Jörg in der Hinterhand hat.

[edit]
ich hab mir auch gerade das Verhalten, beim Disconect / Reconnect des konfigurierten Netzwerkes angesehen.
WLAN Verbindung geht verloren: AP wird gestartet
WLAN wieder verfügbar: AP Wird abgeschaltet, Verbindung wieder hergestellt.

top!

Danke für's Update, Patrick!

pj

[mrpj]

hmm.. ich bekomme zwar die Dateien angezeigt, aber nicht die Versionen - was fehlt mir?

Code Auswählen Erweitern


{"rom": {"fw_version": "unknown", "url": "http://192.168.29.15:88/rom0.bin"}, "spiffs": {"url": "http://192.168.29.15:88/spiff_rom.bin", "webapp_version": "unknown"}}


Das updateserver tool ist einfach gehalten und daher parst es weder die ROM noch das SPIFFS nach Versionsnummern, sondern gibt direkt unknown aus.

Wenn das Tool die Versionsnummer auslesen würde, wäre das sicher "nice to have", aber nötig zum updaten ist es nicht. 

so, OTA vom lokalen Server hat funktioniert. Ich hab im fhem Modul den "pause" Befehl wieder auf "solid" umgebaut und - jetzt scheint das auch zu funktionieren. Das Timing ist noch etwas unvorhersagbar, aber ich bin mir nicht sicher, ob das am Queueing liegt, ich warte mal, was Jörg in der Hinterhand hat.

Nutze doch als Vergleich das python script von mir. Wenn es bei dem einfachen script einwandfrei funktioniert, dann liegt es noch an dem queueing in fhem.

So am Rande:
Ich hatte nicht gedacht dass die Anbindung an FHEM so kompliziert sein kann.
Auch die Verarbeitungszeit von 20ms im Controller ist etwas hoch - ein Teil davon sind die Debug Nachichten via Serial - das ist leider blocking

[pjakobs]

Nutze doch als Vergleich das python script von mir. Wenn es bei dem einfachen script einwandfrei funktioniert, dann liegt es noch an dem queueing in fhem.

ich sehe ja am Log / Trace, dass das immer noch das Verhalten der ersten Queue Implemenation ist.

So am Rande:
Ich hatte nicht gedacht dass die Anbindung an FHEM so kompliziert sein kann.

ich denke, @herrmanj kann dazu mehr sagen, mein Verständnis ist:: fhem ist darauf angewiesen, dass eine Zentralschleife häufig genug aufgerufen wird. Das Parsen einer einzelnen Kommandozeile läuft aber in einem Stück, alles, was darin passiert muss also durchlaufen werden, bevor wieder andere Aufgaben erledigt werden. Andere Aufgaben sind eben auch alles asynchrone. Ist wohle in bisschen unglückliches Design.

Auch die Verarbeitungszeit von 20ms im Controller ist etwas hoch - ein Teil davon sind die Debug Nachichten via Serial - das ist leider blocking

um 20ms mach ich mir erstmal keine Sorgen - wenn es asynchron ist.

pj

[kaihs]

Ich greife diesen Punkt aus dem anderen Thread mal auf:

eventuell ein HSV+WW/CW? Damit ließe sich theoretisch die dreifache Weiß-Helligkeit erreichen, auf Kosten der Farbqualität. Im Grunde wäre das nur eine Abwandlung des RAW Modes

Dieses Feature fände ich sehr gut, da ich damit mit nur einem Controller einen RGB und einen getrennten WW Stripe steuern könnte. Die möchte ich unabhängig von einander ansteuern.
Bisher geht das ja nur mit zwei unabhängigen Controllern.

[pjakobs]

Ich greife diesen Punkt aus dem anderen Thread mal auf:

Dieses Feature fände ich sehr gut, da ich damit mit nur einem Controller einen RGB und einen getrennten WW Stripe steuern könnte. Die möchte ich unabhängig von einander ansteuern.
Bisher geht das ja nur mit zwei unabhängigen Controllern.

Ich hab bei mir schon ne Version mit RAW support laufen, allerdings hab ich noch keine klare Idee, wie ich die Readings abbilde.
Momentan verwenden wir ja hsv und rgb mit 8-Bit Werten und die sind immer äquivalent, weil wir rgb in hsv umrechenen.
Bei RAW habe ich 1. 10 Bit rgb Werte und 2. zusätzlich bis zu 2x 10 Bit weiß. Daraus einen vernünftigen hsv Wert zu rechnen mag mir gerade nicht einfallen. Vielleicht frage ich einfach den Controller, was er errechnet hat.
Dazu müsste ich dann ansich auch 10 Bit Readings einbauen, das könnte etwas unübersichtlich werden:

h     [0-255]
s     [0-255]
v     [0-255]
rgb [0x000000-0xffffff]
r10 [0-1023]
g10 [0-1023]
b10 [0-1023]
ww10 [0-1023]
cw10 [0-1023]
rgb10 [0x000000000-0x03ff03ff03ff]
ziemlich unelegant, finde ich, zumal die Werte nicht mehr eineindeutig sind. Der worauf sollte sich der hsv Wert beziehen, wenn ich r10, g10, b10, ww10, cw10  gesetzt habe? Nur auf rgb? oder auch auf hsv?
Eigentlich denke ich, ich möchte den RAW Modus ganz unabhängig vom hsv Modus halten.

pj