ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[Pf@nne]

Moin,

ich wollte meinen Senf zur MQTT-Anbindung auch nochmal loswerden....

Die Grundidee einer internen universellen API auf JSON-Basis halte ich für sehr flexibel, damit lassen sich alle weiteren Anbindungen (UDP, TCP, seriell, MQTT etc.) einheitlich nachrüsten.

Aber, was spricht dagegen mit MQTT zweigleisig zu fahren?

Man könnte zum Einen ein Topic für die API-Anbindung (JSON-String) bereitstellen und zum Anderen
auch alle internen API-Funktionen in einem eigenen Topic darstellen.

Code Auswählen Erweitern

  sub.E1.item[1] = "color";
  sub.E2.item[1][0] = "setRAW";
  sub.E3.item[1][0][0] = "R";
  sub.E3.item[1][0][1] = "G";
  sub.E3.item[1][0][2] = "B";
  sub.E3.item[1][0][3] = "WW";
  sub.E3.item[1][0][4] = "CW";
  sub.E2.item[1][1] = "setHSV";
  sub.E3.item[1][1][0] = "H";
  sub.E3.item[1][1][1] = "S";
  sub.E3.item[1][1][2] = "V";
  sub.E3.item[1][1][3] = "CT";


Damit wäre dann ein direkter Zugriff z.B. auf die einzelnen Farbkanäle möglich.

Entweder über den API-Topic:

Code Auswählen Erweitern


publish xx/API {"hsv": {"h": 200.0,"s": 100.0,"v": 100.0,"ct": 2700,},cmd: "fade","t": 600,"q": false,"d": 1}


oder über die Topics direkt:

Code Auswählen Erweitern


publish xx/setHSV 200.0,100.0,100.0,2700,fade,600,false,1


Code Auswählen Erweitern


publish xx/setRAW 100,100,100,50,50

oder
publish xx/setRAW/R 100




Die hälfte der Einzelfunktionen ist in meinem Fork schon enthalten und läuft soweit, momentan habe ich bloß kaum Zeit, da ich mein Carportach gerade neu mache....


Gruß
Pf@nne

[pjakobs]

Moin!

Moin,

ich wollte meinen Senf zur MQTT-Anbindung auch nochmal loswerden....

Die Grundidee einer internen universellen API auf JSON-Basis halte ich für sehr flexibel, damit lassen sich alle weiteren Anbindungen (UDP, TCP, seriell, MQTT etc.) einheitlich nachrüsten.

Aber, was spricht dagegen mit MQTT zweigleisig zu fahren?

Man könnte zum Einen ein Topic für die API-Anbindung (JSON-String) bereitstellen und zum Anderen
auch alle internen API-Funktionen in einem eigenen Topic darstellen.

der Mann versteht mich!

[...]
Die hälfte der Einzelfunktionen ist in meinem Fork schon enthalten und läuft soweit, momentan habe ich bloß kaum Zeit, da ich mein Carportach gerade neu mache....

Ich fänd's klasse, wenn wir einen "working prototype" dafür bekommen könnten, dann kann ich anfangen, die mqtt subscriptions für die Readings einzubauen.

pj

PS: mein Carport müsste auch anders werden, wenn Du fertig bist, komm einfach mal vorbei
PPS: wenn Dein "Moin" lebensraum-angepasst ist, dann ist das garnicht so weit

[mrpj]

Aber, was spricht dagegen mit MQTT zweigleisig zu fahren?

Man könnte zum Einen ein Topic für die API-Anbindung (JSON-String) bereitstellen und zum Anderen
auch alle internen API-Funktionen in einem eigenen Topic darstellen.

Für mich spricht auf lange Sicht die Codepflege dagegen. Wenn es zu Bugs/Fehlern/notwendigen Änderungen kommt, gilt es den Code an mehreren Stellen anzupassen.

[pjakobs]

Für mich spricht auf lange Sicht die Codepflege dagegen. Wenn es zu Bugs/Fehlern/notwendigen Änderungen kommt, gilt es den Code an mehreren Stellen anzupassen.

das verstehe ich vielleicht einfach noch nicht.

1. gäbe es das API, das einfach noch einen weiteren Transportmechanismus bekommt. Statt nur http wäre jetzt eben auch mqtt möglich, den Code dahinter gäbe es nur einmal. Mir ist klar, dass das ggf. ein Refacturing des APIs bedeuten würde, das heute an den http Server angebunden ist. Die mqtt topics könnten grundsätzlich sogar fast die gleiche Semantik haben wie die Endpoints der http/REST Schnittstelle, wobei aus dem color?RAW ein color/raw werden müsste.

2. und da entsteht dann wirklich zusätzlicher Code, würdest Du mit jeder Änderung eines Farbwertes die Topics /color/raw und /color/hsv neu publizieren, und zwar mit den entsprechenden json Strukturen. Sprich: Du müsstest die aktuellen Werte in json wrappen und die publish Funktion aufrufen. Doppelten Code sehe ich da nicht.

Stelle ich mir das nur zu einfach vor? Ich denke sogar, dass 2. auch ohne 1. existieren könnte, dann wären die Topics halt nur unidirektional.

Aber wie gesagt: vielleicht fehlt mir auch irgendwo ein Faktoid.

Grüße

pj

[mrpj]

Doppelt code bezieht sich auf den Vorschlag die API nicht an ein einzelnes JSON Topic zu binden, sondern für jeden Endpunkt nochmals ein Topic zu haben, welches ohne JSON angesteuert wird.

Siehe dem Vorschlag:

Damit wäre dann ein direkter Zugriff z.B. auf die einzelnen Farbkanäle möglich.

Entweder über den API-Topic:

Code Auswählen Erweitern


publish xx/API {"hsv": {"h": 200.0,"s": 100.0,"v": 100.0,"ct": 2700,},cmd: "fade","t": 600,"q": false,"d": 1}


Code Auswählen Erweitern


publish xx/setHSV 200.0,100.0,100.0,2700,fade,600,false,1


Code Auswählen Erweitern


publish xx/setRAW 100,100,100,50,50

oder
publish xx/setRAW/R 100


Dadurch müssen zwei "Datenstrukturen" in eine Representation umgewandelt werden - und genau solche Dinge möchte ich vermeiden. Eine Änderung an der API erfordert mehr Schritte.

Auch noch aus Sicht der Codepflege:
In mehreren Monaten werden die meisten hier aus dem Forum wahrscheinlich nichts mehr weiter am Code pflegen. Ich werde nicht in absehbarer Zukunft MQTT benötigen und somit wäre es, wenn ich der einzige maintainer bin, mir nur mit extra Aufwand möglich Änderungen zu testen. Für mich ist es wesentlich einfacher eine Datenstruktur (JSON) zu haben, auf die das Protokoll aufsetzt und die Daten nur durchreicht. Somit sind Änderungen an der API an einer Stelle.

Führt aber auch dazu, dass die aktuelle (bewusst einfach gehaltene) API auf einen einzelnen Endpunkt (z.B.) /api migriert werden muss


Nachtrag:

Die API ist kein REST - sondern eine JSON API. Es werden bei dieser API keine Resourcen verändert, sondern Befehle ausgeführt und am ehesten könnte man diese API als RPC (remote procedure call) bezeichnen

Nachtrag2:

Das größte Problem an der Geschicht ist gerade der Faktor Zeit - mein backlog für das Projekt ist relativ groß und es stehen bei mir einige Sachen über den Sommer an. (Daher auch bisher die Zurückhaltung mit einer zweiten Sammelbestellung)

[pjakobs]

@mrpj ok, kann ich (weitgehend) nachvollziehen. Es ist mir ja auch am Ende nicht so sehr wichtig.

Zur Bestellung: mein Bruder war heute hier und hat so ein bisschen gesehen, was wir tun - ich würde dann jetzt 10 abnehmen

Zum Modul: Ich werde das mal noch so erweitern, dass es fünf separate Kanäle bedienen kann - z.B., für fünf unabhängige weiß Kanäle.

pj

[funclass]

@pjakobs

Hab die aktuelle dev-Version mal getestet. Nach meinem Empfinden funktioniert nun alles bestens. Ohne defaultColor selbst zu setzen wird bei on auf Weiß gesetzt und die Verwendung von float bei Animationsdauer klappt auch 

Hab mir mal die Doku von WiFiLight angesehen und gerade bei den set-befehlen viele Parallelen gefunden. Spricht etwas dagegen wenn ich dort für die Doku etwas "klaue"?

Nachtrag: das Senden mehrerer Befehle zum sequenziellen Abarbeiten über die Que funktioniert bei mir nicht. Entweder passiert gar nix, oder es wird nur (irgend)ein Befehl verarbeitet. Beim mehrmaligen Ausführen folgender Routine bekomme ich unterschiedliche Reaktionen des Controllers...

Bsp.:

Code Auswählen Erweitern


sub myTest() {
fhem ("set rgb_stripe hsv 0,100,80 5 q");
fhem ("set rgb_stripe hsv 0,100,0 4 q");
fhem ("set rgb_stripe hsv 300,100,30 3 q");
}


[herrmannj]

Klauen hiermit genehmigt

vg
herrmannj

[funclass]

Klauen hiermit genehmigt

Danke. Wir müssen das Rad ja nicht zweimal erfinden 

[pjakobs]

@pjakobs

Hab die aktuelle dev-Version mal getestet. Nach meinem Empfinden funktioniert nun alles bestens. Ohne defaultColor selbst zu setzen wird bei on auf Weiß gesetzt und die Verwendung von float bei Animationsdauer klappt auch 

so sollte das auch sein

Hab mir mal die Doku von WiFiLight angesehen und gerade bei den set-befehlen viele Parallelen gefunden. Spricht etwas dagegen wenn ich dort für die Doku etwas "klaue"?

sei so gut und sag mir auch, wo wir abweichen, ich denke, ich werd lieber die API anpassen - idealerweise sollte das hier ein drop-in Replacement für WifiLight sein.
Was ich schon weiß ist, dass wifilight

• hue
• saturation
• brightness

verwendet statt meinem hue, sat, val, ich denke, das werde ich anpassen.
Außerdem bin ich etwas verwirrt, eigentlich dachte ich, Internals werden groß geschrieben (STATE) und readings klein (rgb) - in WifiLight ist aber set RGB 0xrrggbb geboten, oder?

wie gesagt, wenn Du einfach schaust, wo die API abweicht zieh ich das nach.

Nachtrag: das Senden mehrerer Befehle zum sequenziellen Abarbeiten über die Que funktioniert bei mir nicht. Entweder passiert gar nix, oder es wird nur (irgend)ein Befehl verarbeitet. Beim mehrmaligen Ausführen folgender Routine bekomme ich unterschiedliche Reaktionen des Controllers...

Bsp.:

Code Auswählen Erweitern


sub myTest() {
fhem ("set rgb_stripe hsv 0,100,80 5 q");
fhem ("set rgb_stripe hsv 0,100,0 4 q");
fhem ("set rgb_stripe hsv 300,100,30 3 q");
}


das verstehe ich nicht. Ich hab das gestern ausgiebig getestet, sogar mit Blink-Abfolgen, und es hat funktioniert. Versuch bitte mal, die Queue Befehle im fhem Kommandofeld hintereinander weg einzugeben, mit ; separiert. Für das erste setting brauchst Du kein "q".
Dann schick mir bitte das logfile für beide Varianten

Code Auswählen Erweitern


tail -f /opt/fhem/log/fhem-2016-06.log |grep rgb_stripe


eigentlich sollte das funktionieren.

Grüße

pj

[herrmannj]

Oh, gehts locker an. WifiLight ist ja auch historisch gewachsen.

Das sieht man an den set sehr gut. Ich habe da sowieso ein "next gen" in der Mache - da würde ich mit großen internals und kleines readings mitziehen. Logisch müssten die set dann auch klein geschrieben werden.

Man muss alte Zöpfe auch mal abschneiden dürfen

vg
joerg

[Icinger]

Mal eine Bitte:
Könntet ihr die "print"-Ausgaben durch Log3 ersetzen? Evtl. auf Lvl 4?
Und im Idelfall noch mit dem Devicenamen voran

Kann auch gerne morgen einen Patch dazu liefern.

lg, Stefan

[pjakobs]

hmm.. ich hab das gerade nochmal getestet und - ja, irgendwas stimmt mit den queued settings nicht. Vielleicht hat @herrmannj doch recht und wir müssen die API zum Controller serialisieren.
@mrpj hast Du ne Chance Dir mal anzusehen, was der Controller tut, wenn er direkt nacheinander Settings bekommt?
Es scheint, als ob das Verhalten da ein bisschen unvorhersagbar ist - manche Sachen funktionieren ohne Problem, manche werden einfach verschluckt.
Eigentlich will ich kein queueing bauen, weil das ja der Controller schon kann, ich denke, wenn, dann benutze ich ein semaphore internal. Nur wenn es gelöscht ist nehme ich ein set an, wenn ein set bearbeitet wird, wird das semaphore gesetzt und wieder gelöscht, wenn die <success> message vom API zurück kam. Wobei mir daran nicht gefällt, dass wir auf die Weise ggf. fhem komplett blockieren könnten...

ach, @funclass: ich hab Dir noch ein "pause" setting eingebaut. mit

Code Auswählen Erweitern


set LED pause n q kannst Du jetzt bestimmen, dass die aktuelle Farbe für n Sekunden gleich bleibt.

Grüße

pj

Nachtrag: @mrpj - Du hattest oben mal geschrieben, dass Du das <200 success> schon schickst, wenn der Controller die Daten übernommen hat, also habe ich auf dieser Seite der API eigentlich keine Möglichkeit, festzustellen, ob der Controller schon wieder neue Daten entgegennehmen kann, oder?

[pjakobs]

Oh, gehts locker an. WifiLight ist ja auch historisch gewachsen.

Das sieht man an den set sehr gut. Ich habe da sowieso ein "next gen" in der Mache - da würde ich mit großen internals und kleines readings mitziehen. Logisch müssten die set dann auch klein geschrieben werden.

Man muss alte Zöpfe auch mal abschneiden dürfen

vg
joerg

super, dann lass uns dafür sorgen, dass wir da gleich bleiben!

danke.

nebenbei Jörg:
Du hast ja für die Milight Bridge Code geschrieben, der die unterschiedlichen "slots" als verschiedene Devices an der selben Bridge anbindet.
Ich hab heute mal überlegt, ob ich zusätzlich zum aktuellen Modell (RGBWWCW immer via HSV) noch einen zweite "modus" anbiete, in dem die fünf Kanäle als fünf einzelne Devices (dann halt nur in der Helligkeit steuerbar) auftauchen.
Wenn ich das richtig gesehen habe, legst Du die Information über schon benutzte slots im internen $defs{} hash ab, richtig? Im Grunde sollte das doch hier auch möglich sein. Ich stelle mir eine Art "bitmap" vor, die die schon belegten Kanäle aufzählt.
Wenn ich ein

Code Auswählen Erweitern

define LED_RGBWW LedController RGBWW <hostname>
konfiguriere, dann würden eben die Kanäle 1,2,3 und 4 als "benutzt" gekennzeichnent, und ich könnte zusätzlich ein

Code Auswählen Erweitern

define LED_W LedController white <hostname> konfigurieren, dass dann den noch freien Kanal für eine einzelne, z.B. weiße Schiene definiert.

Das sollte, äquivalent zum MifiBrige-v3 code möglich sein.
Schwierig wird es dann, einzelne Kanäle zu setzen, denn dazu müsste das RAW Kommando eben auch gezielt für einzelne Kanäle funktionieren (momentan geht, wenn ich das richtig sehe, nur das komplette Set von fünf Kanälen) oder ich müsste den aktuellen Zustand auslesen und eben nur einen veränderten Kanal setzen. Das geht prima, solange keiner der anderen Kanäle gerade in einer Transition ist, dann wären wir wieder bei der Diskussion der letzten Tage, allerdings erschwert durch die Tatsache, dass sich der "laufende" Kanal auch noch zwischen "get" und "set" verändert hätte.

hmm..

Grüße

pj

[pjakobs]

Mal eine Bitte:
Könntet ihr die "print"-Ausgaben durch Log3 ersetzen? Evtl. auf Lvl 4?
Und im Idelfall noch mit dem Devicenamen voran

Kann auch gerne morgen einen Patch dazu liefern.

lg, Stefan

Hi Stefan, hast Recht, die Prints sollten noch raus. Ich schau gleich mal, können aber nur noch zwei oder drei sein... Debug-Faulheit halt

pj