ESP RGBWW Wifi Led Controller - fhem - Modul

[pjakobs]

Hatte die Datei direkt aus dem git.

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

github packt eine Datei in html code ein, es sei denn, Du klickst auf den "raw" button. Die Update Funktion ist wesentlich praktischer, zumal Du so aktuelle Updates bekommst. (ich habe Dir allerdings den Link auf den devel Branch gegeben, der könnte zuweile auch ... interessate ... Funktionen beinhalten )

pj

[Per]

Genauso wie bei hsv/raw. Das sollte der gleichen Logik folgen.

ZB. dimup:
dimup 20 10 s
-> erhöhe Helligkeit um 20 und bleibe dort für 10 s

dimup 20 10
-> erhöhe Helligkeit um 20 mit einer Ramp von 10 s


rotate 30 10 s
-> rotiere Hue um 30 und bleibe dort für 10 s

rotate 30 10
-> rotiere Hue um 30 mit einer Ramp von 10 s

(nur weils komisch aussieht: das "s" im Befehl steht für "solid", das "s" in meiner Beschriebung für Sekunden)

Also solid schaltet immer sofort auf den neuen Wert und bleibt (mindestens) die Zeit dort.
Fade interpretiert die Zeit als ramp mit Wert als Ziel.

So hatte ich zumindest immer solid/fade verstanden. Bitte korrigieren falls ich mich irre. Dann hab ich vermutlich an ziemlich vielen Stellen ziemlich Mist gebaut 

Ist es nicht so, dass "solid" nix anderes ist als eine Rampe mir Steigung 0?
Also z.B.
dimup 20 (0)
dimup 0 10
-> erhöhe Helligkeit um 20 und bleibe dort für 10 s

[vbs]

Ist es nicht so, dass "solid" nix anderes ist als eine Rampe mir Steigung 0?

Hm, mit einer Steigung von 0 könnte man doch aber den aktuellen Wert nie verlassen oder?

Also z.B.
dimup 20 (0)
dimup 0 10
-> erhöhe Helligkeit um 20 und bleibe dort für 10 s

Ja, theoretisch könnte man "solid" händisch so nachbauen, denk ich. In der Praxis ist es aber so, dass ein dimup vom FHEM-Modul auf ein normales HSV-Kommando mit "fade" umgesetzt wird (wenn ramp > 0). Aber wenn eine Fade-Animation startet und merkt, dass der Zielwert identisch mit dem aktuellen Wert ist (also das Ziel schon erreicht ist), dann bricht sie sofort ab und ignoriert die Ramp-Time (https://github.com/patrickjahns/RGBWWLed/blob/master/RGBWWLedAnimation.cpp#L75). Das ist mMn nicht ganz sauber bzw. halte ich für inkonsistent, da dabei die Ramp-Time nicht eingehalten wird.
Du kannst aber das zweite dimup durch eine pause von 10 ersetzen, da eine pause immer als "solid" geschickt wird.
Ich fände es einfacher, dass ganze in einem Befehl zu machen, dem man das "solid"-Flag direkt mitgibt, aber das mag Geschmackssache sein.

[Shuzz]

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

Ich hatte mal überlegt, ob man die Kanalzuteilung bzw. deren Konfiguration nicht komplett aufheben könnte.
Für jedes Kommando würden dann sowohl der Farbmodus (RGB, RGBW, RGBWW) als auch die Kanäle für den Modus mit übertragen.
Vorteil: Keine Konfiguration auf den Controllern selbst mehr notwendig, abgesehen von Dingen wie Netzwerk.
Nachteil: Könnte schwierig werden mit Slave-Mode bzw. MQTT-based Synchronisierung.

mrpj war von der Idee gar nicht begeistert. Was haltet ihr davon?

Andere Frage bzgl. Sming-Update: Müssen wir das wirklich durchführen? Soweit ich das überblicke läuft die FW mit dem "alten" Sming ja soweit zufriedenstellend, d.h. die Lowlevel-Funktionalitäten sind stabil und zuverlässig. Die Änderungen die hier diskutiert werden beziehen sich ja eher auf ne Ebene darüber, d.h. quasi auf die API die von der FW bereitgestellt wird.
Daher die Frage: Ist ein Sming-Update hierfür notwendig? Bringt es irgendwas?

[Per]

Hast Du den update Mechanismus verwendet?

Also im "normalen" Fhem-Update kommt es nicht mit.
Könnte man im Post 1 (der ja irgendwoher kopiert wurde) nicht die übliche Übersicht anbringen?

Tante Edit hat zumindest die Anleitung für das Update gefunden...

[Shuzz]

Also, wie sieht's heute aus mit nem Plausch?

15-16 Uhr wird bei mir knapp, 16-17 wäre mir als Startzeit angenehmer.

Als Tool der Wahl würde ich Discord vorschlagen, ihr findet mich dort als ShuzzDE#8538

[pjakobs]

Discord hab ich noch nie von gehört, später wäre auch mir lieber, weil ich nochmal raus muss. Ich kann eine Reise web basierte (OK, Chrome) Videotelefonie anbieten

Kurz da auf dem Telefon getippt

[kmxak]

Discord ist was für die junge Gamer Jugend 

[Shuzz]

Naja, mit 39 Lenzen zähle ich da wohl nicht mehr in die Zielgruppe, aber praktisch ist das Tool trotzdem.

Wenn's heute nicht klappt macht auch nix, morgen is ja auch noch ein Tag (und übermorgen und überübermorgen und...).

[vbs]

Also ich hab jetzt Discord (vbs) am Laufen (das Argument mit der Gamer Jugend hat mich gepackt). 16h würde bei mir passen.

[pjakobs]

Also ich hab jetzt Discord (vbs) am Laufen (das Argument mit der Gamer Jugend hat mich gepackt). 16h würde bei mir passen.

Errm... Gibt's das für Linux? Und wieso überhaupt ein Client, sowas geht doch im Browser....

Versteh einer die Jugend.

Kurz da auf dem Telefon getippt

[kmxak]

https://discordapp.com/api/download?platform=linux&format=deb
oder
https://discordapp.com/api/download?platform=linux&format=tar.gz

[Kuse]

So, ich denke das ich hier nun richtig bin, danke an vbs für den Hinweis.

Ich bekomme das Modul nicht zum laufen und habe keine Idee mehr was ich noch machen könnte.

Zu Testzwecken habe ich zwei ,,blanke" Controller definiert, einen als ,White".

Bei beiden bekomme ich im Log folgende Meldungen:
2017.04.18 23:10:08 4:
global LogLevel: 3
module LogLevel: 5
compound LogLevel: 5
2017.04.18 23:10:08 5: CW_LED (Set) called with on, busy flag is 0
name is CW_LED, args
2017.04.18 23:10:08 3: CW_LED (Set) called with on, busy flag is 0
2017.04.18 23:10:08 5: CW_LED extended args raw: a=, b=
2017.04.18 23:10:08 5: CW_LED t= 0
2017.04.18 23:10:08 5: CW_LED extended args: t = 0, q = false, d = 1
2017.04.18 23:10:08 5: CW_LED setting VAL to 100, SAT to 0 and HUE 0
2017.04.18 23:10:08 5: CW_LED args[0] = , args[1] =
2017.04.18 23:10:08 5: CW_LED: called SetHSVColor 0, 0, 100, 2700, 0, solid, false, 1)
2017.04.18 23:10:08 2: CW_LED: error encoding HSV color request Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 554.

2017.04.18 23:11:48 4:
global LogLevel: 3
module LogLevel: 5
compound LogLevel: 5
2017.04.18 23:11:48 5: LED_Test (Set) called with rgb, busy flag is 0
name is LED_Test, args $VAR1 = 'c9c9c9';

2017.04.18 23:11:48 3: LED_Test (Set) called with rgb, busy flag is 0
2017.04.18 23:11:48 5: LED_Test extended args raw: a=, b=
2017.04.18 23:11:48 5: LED_Test t= 1800
2017.04.18 23:11:48 5: LED_Test extended args: t = 1800, q = false, d = 1
2017.04.18 23:11:48 5: LED_Test raw: c9c9c9, r: 201, g: 201, b: 201
2017.04.18 23:11:48 5: LED_Test: called SetHSVColor 0, 0, 79, 2000, 1800, fade, false, 1)
2017.04.18 23:11:48 2: LED_Test: error encoding HSV color request Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 554.

Ich denke das ich alle erdenklichen Seiten über diesen Controller nun durchgeackert habe, finde aber leider keine Lösung.
Gibt es irgendwo, ergänzend zu der Modul-Hilfe, ein HowTo in dem die richtige Vorgehensweise erläutert ist.
Welche Voraussetzungen gibt es softwareseitig um das Modul zum laufen zu bekommen?

JSON ist eigentlich installiert:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
libjson-perl ist schon die neueste Version.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 6 nicht aktualisiert.

Würde evtl. jemand eine funktionierende Konfiguration mit mir teilen in der ich mich auf die Suche nach Fehler begeben kann?

Vielen vielen Dank im Voraus für mögliche Unterstützung.

[pjakobs]

moin Kuse,

sorry, ich hatte Deinen Post gestern Abend schon gesehen, aber leider war mein fhem raspi an defekter SD-Karte gestorben und ich konnte nichts nachsehen...

versuche doch mal bitte (gilt für raspbian, andere Distros ggf. abweichend)

Code Auswählen Erweitern


dpkg-query -l|grep -i json|grep perl

das Ergebnis ist die Liste der installierten  perl json Pakete. Bei mir sieht das so aus:

Code Auswählen Erweitern


ii  libjson-any-perl                      1.38-1                                    all          wrapper class for the various JSON classes
ii  libjson-perl                          2.61-1                                    all          module for manipulating JSON-formatted data
ii  libjson-xs-perl                       2.340-1+b2                                armhf        module for manipulating JSON-formatted data (C/XS-accelerated)

Das Modul importiert json-xs, ich vermute, dass es das ist, dass bei Dir fehlt.

Grüße

pj

[MacReiner]

Ich möchte noch einmal auf das Problem beim Flashen einsteigen:

Mit dem FTDI-Adapter wurde das dritte file nicht fertiggestellt.
Das habe ich hier

Den LED Controller habe ich an 12V 100W. Den USB - Seriell Umsetzer habe ich auf 3,3V gejumpert.

Die ersten beiden files klappen:

Code Auswählen Erweitern

sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting....
Auto-detected Flash size: 32m
Running Cesanta flasher stub...
Flash params set to 0x0040
Wrote 4096 bytes at 0x0 in 0.4 seconds (85.7 kbit/s)...
Leaving...


Beim dritten files klappt es nicht. Auch nicht mit einer langsameren Baudrate:

Code Auswählen Erweitern

sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x100000 spiff_rom.bin
esptool.py v1.3
Connecting....
Auto-detected Flash size: 32m
Running Cesanta flasher stub...
Writing 786432 @ 0x100000... 229376 (29 %)
A fatal error occurred: Timed out waiting for packet header

Das genügt auf dem ersten Blick.
Hab so jetzt zwei Controller in mein WLan und in FHEM eingebaut und kann sie ansprechen.

schon dargestellt.

Jetzt habe ich mir den CP2104 gekauft,
dann unter OSX den Treiber dafür geladen

Code Auswählen Erweitern

https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers
und installiert.

Jetzt hat es auf Anhieb funktioniert.

Code Auswählen Erweitern

sh-3.2# esptool.py --p /dev/tty.SLAB_USBtoUART -b 115200 write_flash -fm qio 0x100000 spiff_rom.bin
esptool.py v1.3
Connecting....
Auto-detected Flash size: 32m
Running Cesanta flasher stub...
Wrote 786432 bytes at 0x100000 in 68.2 seconds (92.3 kbit/s)...
Leaving...