ESP RGBWW Wifi Led Controller - fhem - Modul

[Shuzz]

Ähm, wärt ihr evtl. mal für einen Plausch am Abend zu haben?
z.B. in Discord oder sowas.
Mit pj hatte ich das schonmal gemacht, bin nur nicht sicher ob er das Trauma bereits überwunden hat oder nicht. 

Ich finde einfach, wenn nun vier Leute an dem Projekt arbeiten (wollen) ist so'n kurzes "Meeting" hilfreich.


Grüße,

Shuzz

[pjakobs]

Ähm, wärt ihr evtl. mal für einen Plausch am Abend zu haben?
z.B. in Discord oder sowas.
Mit pj hatte ich das schonmal gemacht, bin nur nicht sicher ob er das Trauma bereits überwunden hat oder nicht. 

Ich finde einfach, wenn nun vier Leute an dem Projekt arbeiten (wollen) ist so'n kurzes "Meeting" hilfreich.


Grüße,

Shuzz

Gern, wobei ich ja nur Wünsche äußern würde und irgendwelche komischen Vorschläge haben...

Gesendet von meinem HTC 10 mit Tapatalk

[vbs]

Ich muss gestehen, dass ich gerne erstmal meinen aktuellen Stand fertig machen würde. Also testen, stabilisieren, dokumentieren etc. Weiß nicht, ob ich da jetzt an der Stelle direkt die nächste Baustelle für mich aufmachen will.
Dann muss ich mal gucken, wie es damit weitergeht. Also ob ich das dann erstmal für mich nutze/pflege oder ob ich euch das so verkauft bekomme, dass ihr alles oder Teile davon in die offizielle Firmware übernehmen wollt. Dann mal sehen, auf welchem Stand man dann ist.
Ganz davon zu schweigen, dass ich (hoffentlich) in den nächsten Tagen auch mal wieder etwas löten werde (und Eier suche)

[pjakobs]

@vbs lass uns doch einfach mal quatschen und sehen, ob wir ein paar gute Ideen in den Topf werfen können

Kurz da auf dem Telefon getippt

[vbs]

Ok ok, würde euch Freitag nachmittag passen? Keine Ahnung so 15/16h?

[Shuzz]

Hmmm, kann ich derzeit noch nicht sagen...
Sofern meine besser Hälfte mich da nicht auf ner Wanderung durch den Taunus schleift gern.

@vbs: Naja, uns musst Du erstmal nicht viel verkaufen sofern es die Firmware betrifft. Die hat patrick jahns noch in der Hand, wobei ich mich frage ob er die nicht irgendwann mal abgeben mag da er selbst ja keine Zeit hat sich zu kümmern. Aber wie pj sagt: Soll eher so ne Art Brainstorming werden, ggf. Abstimmung was man machen kann/will/soll/mag/...

[pjakobs]

lasst uns die Firmware Diskussion mal hier führen.

[pjakobs]

Ein paar Ideen zum fhem Modul:

• Autoconfig
  ich denke schon seit einiger Zeit darüber nach, dass es eigentlich möglich sein müsste, Controller, die neu in's Netz kommen automatisch zu konfigurieren.
  
  
  
  • Controller wird eingeschaltet, öffnet den Accesspoint "ESP_0"
  • RaspberryPi Server hat ein "freies" WLAN interface, dass auf die Netzwerk ID "ESP_0" konfiguriert ist
  • Sobald dieses Interface eine ip-Adresse hat, triggert ein Script ein fhem notify, das das Modul veranlasst, den Controller unter 192.168.4.1 zu konfigurieren
  • Das fhem Modul braucht natürlich die Zugangsdaten zum "echten" Netzwerk (ein bisschen kritisch, denn der Schlüssel muss ja im Klartext verfügbar sein
  • Wenn der Controller konfiguriert ist, meldet er sich kurz mit der neuen IP Adresse zurück, das Modul kann dann einen Config Eintrag erzeugen
  Vorteil: man bräuchte nicht länger einen PC mit WLAN den man in die beiden unterschiedlichen Netze umschalten muss
  
• OTA Update
  Ich habe langsam so viele Controller, dass der Gedanke, an alle zu gehen, und die Software upzudaten nervig wird. Eleganter wäre es, wenn das Modul zentral (vielleicht sogar über den fhem update Befehl) das OTA Update aller ihm bekannten Controller steuern könnte. Ich hab noch keine genau Idee, wie das gehen könnte, außer, dass das API die Update Funktion hergibt.
• Konfiguration der neuen Firmware Optionen
  Wenn wir uns darauf einigen sollten, etwas wie Master/Slave Syc in der Firmware einzubauen, dann muss das natürlich zentral von fhem, also vom Modul aus, konfiguriert werden können. Ich stelle mir das inetwa so vor:
  
  
  
  • Attribute:
  
  
  • Master (IP Addr oder MQTT Endpoint)
  • Slave Mode (hsv, rgb, raw)
  • Slave Transformation
    Das könnte ein String sein, z.B. "h+10;v/2" (also: rotiere hue um 10° positiv und verwende die halbe Helligkeit)
    Was darin gültig ist hängt natürlich vom Slave Mode ab. Wenn ich mich auf RAW subscribe, dann kann ich keine hsv Transformation machen.
    Die Transformation selbst müsste natürlich auf dem Slave Controller ablaufen, was ggf. ziemliche Komplexität ergäbe.
  • API
  
  
  • set <xyz> enable/disable Slave
    Ein- oder Ausschalten der Slave Funktionalität, Wert wird in einem Internal gespeichert. Auf diesem Wege lässt sich für ein Device eine Slave Konfiguration definieren und diese ohne Änderung aktivieren und deaktivieren. Der aktuelle zustand würde in einem INTERNAL gespeichert und als READING dargestellt

[li]Multi Device Support
Wenn wir die Funktion der Kanalallokation in die Firmware einbauen, dann kann das Modul für mehrere DEFINES für die selbe IP Adresse aufgerufen werden und jedesmal testen, ob für die aktuelle Definition genügend und die richtigen Kanäle frei sind.
[/list]

Code Auswählen Erweitern


define RGBWW_LED LedController 192.168.112.20 RGBWW
# definiert ein Device, das die Kanäle R,G,B und WW verwendet, setzt damit automatisch den Colormode RGBWW für diese vier Kanäle

define CW_LED LedController 192.168.112.20 WHITE
# definiert ein Device, das versucht einen einzelnen Kanal als Weiß Kanal (oder was auch immer dran hängt) zu belegen.

define another_LED LedController 192.168.112.20 WHITE
# müsste in diesem Fall fehlschlagen, da keine Kanäle mehr frei.


Elegant dabei: wenn die Firmware das flexibel implementiert, dann wäre das eine gute Basis für den möglichen modularen ESP32 Controller, den @mrpj und ich mal ideenhalber diskutiert hatten, der hätte nämlich möglicherweise bis zu 15 Kanäle!
Komplex dabei: Eigentlich wird die feste Zuordnung der Kanäle an Farben damit zum Hindernis, denn wenn ich zuerst einen Weiß Kanal (also Kanal 0) alloziere, dann wäre es danach nicht mehr möglich, ein RGBWW zu allozieren. Es sei denn, wir allozieren einzelne Kanäle von oben nach unten.[/li]

[thorwin]

Ein paar Ideen zum fhem Modul:
[...]
Elegant dabei: wenn die Firmware das flexibel implementiert, dann wäre das eine gute Basis für den möglichen modularen ESP32 Controller, den @mrpj und ich mal ideenhalber diskutiert hatten, der hätte nämlich möglicherweise bis zu 15 Kanäle!
Komplex dabei: Eigentlich wird die feste Zuordnung der Kanäle an Farben damit zum Hindernis, denn wenn ich zuerst einen Weiß Kanal (also Kanal 0) alloziere, dann wäre es danach nicht mehr möglich, ein RGBWW zu allozieren. Es sei denn, wir allozieren einzelne Kanäle von oben nach unten.

D.h. ein RGBWW-Farbmodell kann nicht mit den Kanälen 2,3,4,5 "erzeugt" werden sondern nur mit 1,2,3,4? Vielleicht kann man da ansetzen und das abstrahieren?

EDIT: Das würde ja auch für einen Controller mit deutlich mehr Kanälen benötigt werden

[pjakobs]

Das ist aktuell korrekt, und ich denke, dass das vermutlich auch gut so ist, weil es eine sehr logische Regel zum Anschluss der Strips ist. Mal sehen. Wirklich bedeutsam wird das wohl erst, wenn viele Kanäle zur Verfügung stehen und man z.B. zwischen 3xRGBWWCW und 5xRGB wählen könnte. Für die aktuelle Hardware ist es Imho kein Problem.

Kurz da auf dem Telefon getippt

[thorwin]

Hmm, "logische Regel" klingt nach "starrem Schema" und beißt sich an der Stelle IMHO mit der gewünschten Flexibilität. 

*meinjanur*

[pjakobs]

Flexibilität in der Software ja, aber verkabeln willst Du doch nur einmal, oder?

Kurz da auf dem Telefon getippt

[gNomeX]

Hallo.

Habe versucht das Fhem Modul zu laden bekomme aber dieser Fehlermeldung.

Code Auswählen Erweitern

2017.04.13 12:27:48 1: PERL WARNING: Bareword found where operator expected at ./FHEM/32_LedController.pm line 23, near "<title>esp_rgbww_fhemmodule"
2017.04.13 12:27:48 1: PERL WARNING: (Missing operator before esp_rgbww_fhemmodule?)
2017.04.13 12:27:48 1: PERL WARNING: Bareword found where operator expected at ./FHEM/32_LedController.pm line 23, near "32_LedController"
2017.04.13 12:27:48 1: PERL WARNING: (Missing operator before LedController?)
2017.04.13 12:27:48 1: reload: Error:Modul 32_LedController deactivated:
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 61 at ./FHEM/32_LedController.pm line 23.

2017.04.13 12:27:48 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 61 at ./FHEM/32_LedController.pm line 23.

[pjakobs]

wie hast Du das heruntergeladen?
Ich bin mir relativ sicher, dass die Datei, die diese Fehler wirft nicht die wirkliche Datei ist, sondern (wenn ich das richtig interpretiere) eine html Datei.
Hast Du den update Mechanismus verwendet?

pj

[gNomeX]

Hatte die Datei direkt aus dem git.

funktioniert jetzt aber.  Habe sie gelöscht und den update Mechanismus genommen.