Autor Thema: ESP RGBWW Wifi Led Controller - fhem - Modul  (Gelesen 20794 mal)

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2968
    • _.:|:._
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #135 am: 24 Januar 2017, 10:07:33 »
Git treibt mich zuweilen in den Wahnsinn.

Kenne ich ;) Und wenn man in dann der Github Online Hilfe sucht, dann wird man in einigen Fällen doch wieder auf die command line Variante verwiesen. Vielleicht sollte man grundsätzlich nur die command line Variante verwenden...

Ich habe den/die Threads zum Controller noch nicht komplett gelesen. Gibt es zZ. konkrete Baustellen oder Featurewünsche für das Modul, die angegang werden könnten?

Offline pjakobs

  • Sr. Member
  • ****
  • Beiträge: 571
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #136 am: 24 Januar 2017, 10:21:07 »
Kenne ich ;) Und wenn man in dann der Github Online Hilfe sucht, dann wird man in einigen Fällen doch wieder auf die command line Variante verwiesen. Vielleicht sollte man grundsätzlich nur die command line Variante verwenden...

Ich habe den/die Threads zum Controller noch nicht komplett gelesen. Gibt es zZ. konkrete Baustellen oder Featurewünsche für das Modul, die angegang werden könnten?

@Shuzz hat neulich das Modul ziemlich aufgeräumt und was drin ist, funktioniert im Moment prima.

Zwei große Baustellen sind offen:
  • Auftrennen von Kanälen (daran wird gerade auch in der Firmware gearbeitet). Die Idee ist: man kann den Controller, so wie es heute implementiert ist, als ein Vollfarb-Gerät verwenden und alles weitere passiert in der Firmware, aber: Viele nutzen nur einen Weiß-Kanal (RGBWW) und der zweite bleibt ungenutzt. Außerdem gibt es Anwendungen, in denen es interessant wäre, einen Controller als fünf verschiedene Geräte anzusprechen, ähnlich wie die Milight Controller mit WifiLight.
  • Alles, was die Konfiguration und OTA des Controllers angeht.
    • das API unterstützt Over The Air update, das Modul derzeit noch nicht
    • das API kann, wenn ich es richtig gesehen habe, logging einschalten und ggf. die Logdaten zurückmelden (da bin ich nicht ganz sicher)
    • wlan Konfiguration (wobei ich mir nicht sicher bin, ob das wirklich sinnvoll ist)
Es gibt sicher noch ein paar weitere Ideen, aber für einige brauchen wir Firmware Änderungen (gespeicherte Fades, seperate Fades für Kanäle etc)

pj

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2968
    • _.:|:._
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #137 am: 24 Januar 2017, 10:48:38 »
Danke Dir für die Infos, ich werde am Wochenende einen ESP auf einem Steckbrett verkabeln und dann weiter sehen.

Offline Shuzz

  • New Member
  • *
  • Beiträge: 49
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #138 am: 27 Januar 2017, 21:40:55 »
Eine weitere Baustelle die mir gerade noch einfällt:

- Im Modul ein Interface zu schaffen um mehrere Fades in ein FHEM-Kommando zu packen. Das könnte zunächst in einzelne Requests aufgebrochen und verschickt werden. Wenn die Firmware später einmal direkten Support für Animationen bietet dann könnte man's darauf umbiegen.


Grüße,

Christian

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2968
    • _.:|:._
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #139 am: 28 Januar 2017, 06:51:43 »
Es ist aus meiner Sicht nicht empfehlenswert, Funktionen, die in den Controller gehören, im Modul (temporär) abzubilden. Ich habe mich auch schon dazu hinreißen lassen und mich im Nachhinein geärgert es gemacht zu haben. Es verkompliziert mMn den Modulcode unnötig und ist schwer wieder zu entfernen ohne dass der Anwender etwas umstellen muss. Neben diesen Umstellunen schleichen sich auch gerne wieder Fehler ein...
Wenn allerdings abzusehen ist, dass es nicht ein den Controller Code einfließen wird, dann ist es natürlich etwas anderes.

Offline pjakobs

  • Sr. Member
  • ****
  • Beiträge: 571
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #140 am: 19 März 2017, 10:56:16 »
Oje, ist etwas länger geworden, sorry schonmal dafür  :-X
das wird noch mehr :D
Ich denke, dass sich damit Fades nicht ohne weiteres abbilden lassen, oder?
Also vorweg: ich sehe da eigentlich weder mit der FHEM-Methode noch mit MQTT Probleme bzgl. der Latenz.
Bist du sicher wegen der FHEM-Queue? Ich hab nochmal drüber nachgedacht und ich bin jetzt eigentlich der Meinung, dass Befehle, die ein Modul per fhem() absetzt gar nicht durch die Event-Queue gehen, sondern direkt synchron ausgeführt werden.

fades sind, im aktuellen Zustand der LedController Firmware so oder so ein Problem, denn:
Der Controller kann ja eine ganze Folge von Fades (eben maximal 50 iirc) im lokalen Speicher haben, und die über eine lange Zeit hinweg abfahren (Minuten bis Stunden).
Die Idee mit einem "Output" MQTT Endpoint würde imho genau dieses Problem lösen: das Modul weiß nicht, was die tatsächliche RAW/hsv Einstellung des Controllers zu einem bestimmten Zeitpunkt ist, es könnte aber MQTT nutzen, um diese Information zu bekommen. Dann ist es aber egal, ob ich das erst dem Modul übergebe oder gleich den Input eines (oder mehrerer) Controller damit füttere. Nicht die Fades würden so abgebildet, sondern der jeweilige Zustand des Master Controllers, was also auch ungleich laufende Uhren in den Controllern egalisieren würde.
Außerdem, wenn man mal vergleicht, was in beiden Szenarien passiert wenn man einen Befehl an einen Master und einen (oder mehr Slaves) schicken möchte:
FHEM:
-> FHEM sendet nacheinander die HTTP-Requests non-blocking an alle Master und Slaves (ich denke sogar ohne Event-Queue dazwischen) -> fertig

MQTT:
-> FHEM sendet an den Master -> Master prozessiert Nachricht -> Master sendet an MQTT-Broker -> MQTT-Broker prozessiert Nachricht -> MQTT-Broker sendet an alle Slaves -> fertig

Ich kann mir nicht vorstellen, dass man mit dem MQTT-Ansatz kleinere Latenzen erreicht. Bitte korrigier mich, wenn ich etwas falsch dargestellt bzw. falsch verstanden habe.
s.o. - der MQTT Ansatz ist grundlegend anders als der, den Du gewählt hast.
Darüberhinaus finde ich es im FHEM-Umfeld nicht so gut, Logik und/oder Konfiguration vom zentralen FHEM-Server in die Endgeräte zu verschieben, aber das mag Geschmackssache sein. Ich hab da Logik/Config gerne zentral im Zugriff.

Ich denke, da ist eine sinnvolle Balance gefragt. Die Architektur von fhem ist derart, dass man die Bearbeitungszeit in Modulen so kurz wie möglich halten sollte, wenn ich Aufgaben so in Geräte auslagern kann, dass sie sich sinnvoll verhalten, und ich dieses Verhalten auch von fhem aus kontrollieren kann, dann ist das imho durchaus sinnvoll.
In LedController wäre das z.B. ein "stop" Befehl, der jeden Fade sofort anhält und den aktuellen Farbwert beibehält. Das ist aktuell im Modul rudimentär umgesetzt und müsste eigentlich in die Firmware, damit wir nur noch ein "stop" Kommando an den Controller senden müssten.
Ahh ok, verstehe. So einen Fall mit mehr als 3 Befehlen hatte ich bei mir noch nicht, aber klar, man kann auch 50 Befehle absetzen. Aber wenn man für den Fall optimieren will, wäre es dann nicht besser im Modul eine Schnittstelle zu schaffen, so dass man direkt mit einem set-Befehl mehrere LED-Befehle einliefern kann? So in der Art "set myLed HSB 100,100,100 4:150,20,100 4:50,100,100 2"? Ist vermutlich auch nicht sooo aufwendig. Da würde man schonmal den ganzen FHEM-Drumrum Overhead sparen. Im Idealfall könnte das Modul dann auch direkt an den Controller per API (HTTP/MQTT) mehrere Befehle absetzen.
Was schon länger für die Firmware geplant ist, sind gespeicherte Folgen von Fades. Sobald das da ist, werden wir es im Modul einbauen, da kannst Du dann eine Folge vorbereiten, im Controller ablegen und mit einem einzigen Kommando starten. (z.B. "set myLED run Sonnenaufgang")
Über die Idee, eine ganze Folge, wie Du es vorschlägst, in einem Kommando zu übergeben werd ich mal nachdenken, das gefällt mir...
Außerdem kann man in FHEM längere Befehlskette aufbrechen, in dem man ein "sleep 0" einstreut. Damit baut ja FHEM ein internes "at" welches dann über die Event-Queue abgearbeitet wird. Damit könnten dann auch andere Events zwischendurch zum Zuge kommen (so als yield-Ersatz). Hatten das Thema hier neulich erst:
https://forum.fhem.de/index.php/topic,68350
oh, das hatte ich noch nicht gesehen. Das Problem in unserem Fall war:
die callback Events der asynchronen http messages wurden nicht ausgelöst, solange das Modul selbst noch mit dem cracken der Befehlszeile beschäftigt war, wenn aber noch ein NonBlockingGet in flight ist, wird offenbar kein neues ausgelöst, d.h. das http interface hängt, bis die ganze Zeile zerlegt und in neue Requests umgesetzt ist, dann wird die erste Response Message abgeholt und der Rest läuft durch.
----
Ich denke, ich hab jetzt ganz gut verstanden, wie du dir das vorstelltst mit dem Auslagern in ein eigenes Modul, also danke erstmal für die Erklärung!Hm weiß nicht, ich denke schon, dass das zumindest schon recht modul-spezifisch sein wird (s.u.).
Also ich denke, dass man damit aber viele Sachen nachbauen würde, die es in FHEM sowieso schon gibt. Und auch recht grundlegende Funktionen dazu. Im Prinzip ist gibt es ja das, was dir vorschwebt schon ziemlich genau so in Form von "structure" (jedoch ohne die Transformationsschicht). Deinen ersten Punkt ("alle Slave Devices sollen das gleiche tun und verstehen die gleiche "Sprache") deckt das bestehende structure jetzt schon ab, denk ich.
Für die anderen Fälle müsste man es aufbohren und hätte dann mMn eine Art "structure 2.0" :) Wenn man das jedoch so bauen würde und da sehr generisch Befehle an mehrere verschiedenartige Geräte absetzen möchte, dann würde man das doch momentan in FHEM auch schon per notify/DOIF bauen können, oder?
Mir ist noch nicht ganz klar welche konkreten Einsatzszenarien es überhaupt dafür gibt, aber wenn ich, sagen wir, die Raumtemperatur auf 20°C schalten möchte, wenn jemand die LED auf "rot" setzt, dann ginge das doch schon mit einem notify recht einfach:
define nty notify wl_led:hsv 0,.* set wz_temp 20(bitte mich nicht drauf festnageln, mag genau so evtl. nicht funktionieren, aber ich hoffe man versteht die Idee:))
Structure kannte ich noch garnicht (shame on me!) - ich hab ja nur auf Deinen Vorschlag hier reagiert.
Persönlich habe ich zwei Terassenlampen (leider MiLight über WifiLight),  eigentlich einfache 220V Lampen, ausgestattet mit MiLight "Glühbirnen". Die Lampen haben zusätzlich einen Kranz von LED, die leuchten, sobald die Lampe "Strom hat" - logisch, sie ist ja auch dafür gedacht, über einen Schalter ein- und ausgeschaltet zu werden.
Ich hab sie also hinter einen unterputz HomeMatic 433MHz Schalter gehängt.

Im Grunde ist vieles, was wir hier gerade an Diskussion führen hier abgebildet:
   define LED_Te dummy
   attr LED_Te room Licht
   attr LED_Te userReadings HSV, RGB
   attr LED_Te webCmd RGB:RGB FFFFFF:RGB AFAFAF:RGB 7F7F7F:RGB 3F3F3F:RGB 000000:RGB 7f0000:RGB 007f27:RGB 0000ff
   attr LED_Te widgetOverride RGB:colorpicker,HSV
   
   define NO_Li_Te notify LED_Te.* {fhem("set LED_T1 $EVENT");;;;fhem("set LED_T2 $EVENT")}
   attr NO_Li_Te room Licht,Regeln,Terasse
   
   define NO_Li_Te_SW notify LED_T1:brightness:.*|LED_T2:brightness:.* {if($EVTPART1 != 0 and ReadingsVal("SW_Licht_Aussen", "state
   attr NO_Li_Te_SW room Licht,Regeln

  • Über den Dummy und NO_Li_Te  kann ich beide Lampen gleichzeitig steuern
  • Über die beiden individuellen Devices kann ich noch immer jede Lampe für sich steuern
  • Der NO_Li_Te_SW kümmert sich darum, dass der 433MHz Schalter ein- und ausschaltet, abhängig vom status der Lampen

Das ließe sich vermutlich eleganter mit einem entsprechenden Master Modul konfigurieren, zumal ich immer wieder das Problem habe, dass der Schalter ja erst in Folge der Änderung an den Lampen geschaltet wird, die Controller der Lampen vorher ja aber keine Änderung empfangen können und deshalb zumindest der erste Befehl damit in's Leere läuft.
Ein Master / Slave könnte da ggf. eine sinnvollere Abfolge einhalten.

Und das halte ich eigentlich für einfacher, also dafür ein Master-Modul zu definieren und dann per Attribut (vermutlich) recht komplexe Transformationsausdrücke zu definieren. Ich fürchte, dass die recht komplex sein müssen, weil das Modul ja sehr generisch sein soll und zwischen beliebigen Devices transformieren können soll. Damit geht mMn eine gewisse Komplexität einher. Dieser Ansatz mit dem notify wiederum klappt bei dem LedController mMn eben nicht so gut, nämlich wieder wegen den Fades. Man kann eben nicht auf hsv-Events lauschen (per notify) und diese dann 1:1 auf ein anderes LED-Gerät übertragen. Man muss das wirklich auf Befehlsebene machen, denk ich. Und darum denke ich, dass es doch irgendwie modulspezifisch ist.

Ein anderer Punkt sind die Readings: um mit dem LedController sinnvolle Logiken zu basteln, braucht man Zugriff auf die Readings. Wenn man nun ein separates Master-Modul baut, dann müsste man sich irgendwie auch überlegen, wie man den Zugriff auf Readings abbilden will. Wenn das dann auch entsprechend generisch sein soll, wird man da auch nochmal einiges an Transformationslogik reinstecken müssen.
Hmmm... Die Readings zu bekommen ist ja kein Problem, aber Du hast schon recht, sie generisch zu "verstehen" (also korrekt zu interpretieren) ggf. schon.
Ich glaube der Aufhänger für diesen generischen Ansatz ist, dass LedController per Slave in der Lage ist WifiLight zu steuern, oder? Ich vermute, wenn das WifiLight da nicht vorgekommen wäre, hätte es sich für dich weniger unpassend angefühlt? Da würde ich dir teilweise zustimmen. LedController sollte eigentlich nicht das Interface von anderen Modulen kennen und die steuern können. Wenn man da konsequent wäre, könnte man diese Funktion auch wieder rausnehmen, so dass LedController nur andere LedController steuern könnte. Andererseits ist es auch ganz schick, dass man damit WifiLight mit abdeckt mMn. Bin unschlüssig :)
Der Aufhänger war: ich mag die Idee, ich habe tatsächlich, s.o., ein ähnliches Problem schon "mit Bordmitteln" gelöst, aber ich finde, dass das Problem selbst zu generisch ist, als dass man es in einem so spezifischen Modul wie 32_LedController lösen sollte.
Oh mann, vermutlich mein längster Post ever :) Sorry, dass ich da an den meisten Stellen unterschiedlicher Meinung bin :( Ich finde die Diskussion jedoch an beiden Ecken sehr interessant!
Is völlig ok, Entschuldigungen fangen erst bei persönlichen Beleidigungen an, gutes Software Design ist eben nicht immer völlig simpel und hat viele Seiten.
Ich hätte ja auch einfach Deinen Pull Reqest akzeptieren können, aber ... ich bin da halt anderer Meinung ;-)

Grüße

pj
« Letzte Änderung: 19 März 2017, 11:01:41 von pjakobs »

Offline vbs

  • Hero Member
  • *****
  • Beiträge: 1480
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #141 am: 20 März 2017, 15:25:07 »
Zitat von: vbs
Die Idee mit einem "Output" MQTT Endpoint würde imho genau dieses Problem lösen: das Modul weiß nicht, was die tatsächliche RAW/hsv Einstellung des Controllers zu einem bestimmten Zeitpunkt ist, es könnte aber MQTT nutzen, um diese Information zu bekommen. Dann ist es aber egal, ob ich das erst dem Modul übergebe oder gleich den Input eines (oder mehrerer) Controller damit füttere. Nicht die Fades würden so abgebildet, sondern der jeweilige Zustand des Master Controllers, was also auch ungleich laufende Uhren in den Controllern egalisieren würde.
Aber wie würden Fades dann in der Praxis funktionieren? Der Master gibt regelmäßig (mehrmals pro Sekunde?) seinen Zustand aus und die Slaves schalten dann immer "hart" auf diesen um? Ich finde es eigentlich sehr elegant, dass momentan die Fades innerhalb des Controllers ausgeführt werden.
Sorry, wenn ich nochmal "nachnerve", aber ich interessiere mich wirklich für diesen MQTT-Master-Slave-Ansatz. Hast du Lust, da nochmal 1-2 Sätze zu zu schreiben, wie du dir das vorstellst? Vielleicht werde ich dann auch bald MQTT-User :)
« Letzte Änderung: 24 März 2017, 20:00:01 von vbs »

Offline vbs

  • Hero Member
  • *****
  • Beiträge: 1480
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #142 am: 24 März 2017, 20:04:32 »
Argh ach du grüne Neune! Jetzt hab ich meinen letzten Post editiert und dadurch sozusagen gelöscht... wollte eigentlich nur einen unten dranhängen  :'(

Offline pjakobs

  • Sr. Member
  • ****
  • Beiträge: 571
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #143 am: 26 März 2017, 18:48:12 »
Ich hab die Diskussion nicht vergessen, im Moment hab ich nur ne Menge andere Dinge an der Backe, kommt noch 😉

Gesendet von meinem HTC 10 mit Tapatalk


Offline pjakobs

  • Sr. Member
  • ****
  • Beiträge: 571
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #144 am: 27 März 2017, 23:32:42 »
ich hab mal ne Frage:

Im Video habt Ihr gesehen, dass ich  bei einigen Controllern unterschiedliche Terminal Blocks liefern müsste - würde Euch das stören?
Die blauen bekomme ich als 3er Block nicht vor Ende April gelieferrt, die grünen zweier-Blocks könnte ich nachbestellen, allerdings zu einem Schweinepreis (fast 50ct pro Stück also 1,50 pro Controller)

Legt Ihr Wert darauf, dass die einheitlich sind, oder ist das Euch eher egal?

Grüße

pj

Offline AxelSchweiss

  • Sr. Member
  • ****
  • Beiträge: 675
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #145 am: 27 März 2017, 23:48:40 »
Nö .. mir ist das egal ... verschwindet eh in einem Gehäuse.

Offline Christian Uhlmann

  • Full Member
  • ***
  • Beiträge: 186
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #146 am: 28 März 2017, 07:38:15 »
Mir ist das egal.
Host: Debian Stretch als XEN Guest
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, CUL FS20, CUL HM, HMLan, HM-USB 2, JeeLink LaCrosse
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, FS20 und andere

Offline RaspiLED

  • Hero Member
  • *****
  • Beiträge: 1166
  • Es begann alles so klein ;-)
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #147 am: 28 März 2017, 08:21:22 »
Hi, ist so doch so egal - Im Gegenteil DIY! ;-) Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Offline vbs

  • Hero Member
  • *****
  • Beiträge: 1480
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #148 am: 28 März 2017, 09:04:15 »
Mir auch egal, Hauptsache billig  ;D

PS.
Ich glaube, jetzt sind wir aber falsche hier im FHEM-Modul-Thread, oder? :)

Offline pjakobs

  • Sr. Member
  • ****
  • Beiträge: 571
Antw:Entwicklung fhem modul für ESP RGBWW Wifi Led Controller
« Antwort #149 am: 28 März 2017, 09:52:12 »
Ja, die Verwirrung im Alter

Gesendet von meinem HTC 10 mit Tapatalk


 

decade-submarginal