ESP RGBWW Wifi Led Controller - Firmware vbs

[kaihs]

Ich habe seit einiger Zeit Probleme mit meinen drei LedControllern. Diese reagieren gar nicht oder nur sehr verzögert auf Änderungen die durch das 32_EspLedController.pm:?/2019-03-21 Modul ausgelöst werden. Das hat schon mal einwandfrei funktioniert.

Direkte Steuerung über die Weboberfläche funktioniert ohne Verzögerung. Ping Zeiten sind <4 ms.
Im Log steht z. B. nach einem  set LEDController-WZ off auf das der Controller nicht reagiert:

Code Auswählen Erweitern


2019.04.23 22:00:00.269 4: wz_led_TV: EspLedController_CheckConnection: Connection still alive. Last data received 1.44699788093567 s ago
2019.04.23 22:00:00.481 5: wz_led_TV (Set) called with ?, busy flag is 0
name is wz_led_TV, args
2019.04.23 22:00:12.047 4: wz_led_TV: EspLedController_CheckConnection: Connection still alive. Last data received 13.225152015686 s ago
2019.04.23 22:00:14.938 5: wz_led_TV (Set) called with off, busy flag is 0
name is wz_led_TV, args
2019.04.23 22:00:14.941 5: wz_led_TV: called SetHSVColor
2019.04.23 22:00:14.943 5: wz_led_TV: encoded json data: {"q":"single","t":"500","d":"1","cmd":"fade","hsv":{"v":0,"s":"+0","h":"+0"}}
2019.04.23 22:00:14.944 5: wz_led_TV: set HSV color request: {"q":"single","t":"500","d":"1","cmd":"fade","hsv":{"v":0,"s":"+0","h":"+0"}}
2019.04.23 22:00:15.091 5: wz_led_TV (Set) called with ?, busy flag is 1
name is wz_led_TV, args
2019.04.23 22:00:17.409 5: wz_led_TV: EspLedController_ParseBoolResult
2019.04.23 22:00:17.410 2: wz_led_TV: EspLedController_ParseBoolResult error: http://LEDController-WZ/color: empty answer received


Auffallend ist 'EspLedController_ParseBoolResult error: http://ledcontroller-wz/color: empty answer received

Wenn ich den Aufruf per wget vom Rechner auf dem fhem läuft durchführe erhalte ich sehr wohl eine Antwort:

Code Auswählen Erweitern


{"raw":{"r":0,"g":0,"b":0,"ww":0,"cw":0},"hsv":{"h":0.00,"s":0.00,"v":0.00,"ct":2700}
[code]

Hier noch ein list des Devices:
[code]
nternals:
   DEF        LEDController-WZ
   DeviceName LEDController-WZ:9090
   FD         80
   FUUID      5c432751-f33f-a4cf-e124-efe08f8001ea45af
   FVERSION   32_EspLedController.pm:?/2019-03-21
   IP         LEDController-WZ
   LAST_RECV  1556050198.46122
   NAME       wz_led_TV
   NR         402
   NTFY_ORDER 50-wz_led_TV
   PARTIAL   
   PORT       9090
   STATE      opened
   TYPE       EspLedController
   OLDREADINGS:
   READINGS:
     2019-04-23 21:33:18   colorMode       hsv
     2019-04-23 21:58:42   config-color-brightness-blue 100
     2019-04-23 21:58:42   config-color-brightness-cw 100
     2019-04-23 21:58:42   config-color-brightness-green 100
     2019-04-23 21:58:42   config-color-brightness-red 100
     2019-04-23 21:58:42   config-color-brightness-ww 100
     2019-04-23 21:58:42   config-color-colortemp-cw 6000
     2019-04-23 21:58:42   config-color-colortemp-ww 2700
     2019-04-23 21:58:42   config-color-hsv-blue 0
     2019-04-23 21:58:42   config-color-hsv-cyan 0
     2019-04-23 21:58:42   config-color-hsv-green 0
     2019-04-23 21:58:42   config-color-hsv-magenta 0
     2019-04-23 21:58:42   config-color-hsv-model 0
     2019-04-23 21:58:42   config-color-hsv-red 0
     2019-04-23 21:58:42   config-color-hsv-yellow 0
     2019-04-23 21:58:42   config-color-outputmode 0
     2019-04-23 21:58:42   config-color-startup_color last
     2019-04-23 21:58:42   config-events-color_interval_ms 500
     2019-04-23 21:58:42   config-events-color_mininterval_ms 500
     2019-04-23 21:58:42   config-events-server_enabled 1
     2019-04-23 21:58:42   config-events-transfin_interval_ms 1000
     2019-04-23 21:58:42   config-general-device_name wz_led_TV
     2019-04-23 21:58:42   config-general-pin_config 13,12,14,5,4
     2019-04-23 21:58:42   config-network-ap-password rgbwwctrl
     2019-04-23 21:58:42   config-network-ap-secured 0
     2019-04-23 21:58:42   config-network-ap-ssid RGBWW10676753
     2019-04-23 21:58:42   config-network-connection-dhcp 1
     2019-04-23 21:58:42   config-network-connection-gateway 0.0.0.0
     2019-04-23 21:58:42   config-network-connection-ip 0.0.0.0
     2019-04-23 21:58:42   config-network-connection-netmask 0.0.0.0
     2019-04-23 21:58:42   config-network-mqtt-enabled 0
     2019-04-23 21:58:42   config-network-mqtt-password
     2019-04-23 21:58:42   config-network-mqtt-port 1883
     2019-04-23 21:58:42   config-network-mqtt-server mqtt.local
     2019-04-23 21:58:42   config-network-mqtt-topic_base home/
     2019-04-23 21:58:42   config-network-mqtt-username
     2019-04-23 21:58:42   config-ota-url  http://rgbww.dronezone.de/release/version.json
     2019-04-23 21:58:42   config-security-api_secured 0
     2019-04-23 21:58:42   config-sync-clock_master_enabled 0
     2019-04-23 21:58:42   config-sync-clock_master_interval 30
     2019-04-23 21:58:42   config-sync-clock_slave_enabled 0
     2019-04-23 21:58:42   config-sync-clock_slave_topic home/led1/clock
     2019-04-23 21:58:42   config-sync-cmd_master_enabled 0
     2019-04-23 21:58:42   config-sync-cmd_slave_enabled 0
     2019-04-23 21:58:42   config-sync-cmd_slave_topic home/led1/command
     2019-04-23 21:58:42   config-sync-color_master_enabled 0
     2019-04-23 21:58:42   config-sync-color_master_interval_ms 0
     2019-04-23 21:58:42   config-sync-color_slave_enabled 0
     2019-04-23 21:58:42   config-sync-color_slave_topic home/led1/color
     2019-04-23 21:33:18   ct              2700
     2019-04-23 21:33:18   hsv             0,0,0
     2019-04-23 21:33:18   hue             0
     2019-04-23 15:18:49   info-connection-dhcp 1
     2019-04-23 15:18:49   info-connection-gateway 192.168.2.1
     2019-04-23 15:18:49   info-connection-ip_address 192.168.2.41
     2019-04-23 15:18:49   info-connection-mac 5ccf7fa2ea11
     2019-04-23 15:18:49   info-connection-netmask 255.255.255.0
     2019-04-23 15:18:49   info-connection-ssid Husen
     2019-04-23 15:18:49   info-current_rom_slot 0
     2019-04-23 15:18:49   info-deviceid   10676753
     2019-04-23 15:18:49   info-event_num_clients 1
     2019-04-23 15:18:49   info-firmware   vbs35b
     2019-04-23 15:18:49   info-heap_free  22120
     2019-04-23 15:18:49   info-sming_version 3.5.1
     2019-04-23 15:18:49   info-uptime     1275540
     2019-04-23 15:18:49   info-webapp_version 0.3.3-shojo7
     2019-04-23 21:33:18   pct             0
     2019-04-23 21:33:18   raw_blue        0
     2019-04-23 21:33:18   raw_cw          0
     2019-04-23 21:33:18   raw_green       0
     2019-04-23 21:33:18   raw_red         0
     2019-04-23 21:33:18   raw_ww          0
     2019-04-23 21:33:18   rgb             000000
     2019-04-23 21:33:18   sat             0
     2019-04-23 21:58:37   state           opened
     2019-04-23 21:33:18   stateLight      off
     2019-04-23 21:33:18   val             0
   helper:
     isBusy     0
     oldVal     0
     cmdQueue:
     lastCall:
       NAME       
       addr       http://LEDController-WZ:80
       auth       0
       buf       
       compress   1
       conn       
       data       {"q":"single","t":"500","d":"1","cmd":"fade","hsv":{"v":0,"s":"+0","h":"+0"}}
       displayurl http://LEDController-WZ/color
       header     User-Agent: fhem
Accept: application/json
Content-Type: application/json
       host       LEDController-WZ
       hu_blocking 0
       hu_port    80
       hu_portSfx
       loglevel   5
       method     POST
       path       /color
       protocol   http
       redirects  0
       timeout    30
       url        http://LEDController-WZ/color
       cmd:
         cmd        fade
         d          1
         q          single
         t          500
         hsv:
           h          +0
           s          +0
           v          0
       hash:
       sslargs:
Attributes:
   alias      LED Fernseher
   defaultRamp 500
   icon       light_led_stripe_rgb
   room       HUEDevice,Multimedia,Wohnzimmer
   userattr   structexclude wohnung wohnung_map wz_led wz_led_map
   verbose    5
   webCmd     hsv:toggle:on:off
   widgetOverride hsv:colorpicker,HSV,hue,0,1,360,sat,0,1,100,val,0,1,100
   wohnung    struc_wohnung_aus_schlafen
   wz_led     struc_wz_leds


Hat jemand eine Idee was die Ursache sein könnte?

[pjakobs]

Ich habe seit einiger Zeit Probleme mit meinen drei LedControllern. Diese reagieren gar nicht oder nur sehr verzögert auf Änderungen die durch das 32_EspLedController.pm:?/2019-03-21 Modul ausgelöst werden. Das hat schon mal einwandfrei funktioniert.

moin, kannst Du mal untersuchen, ob die Verzögerung innerhalb FHEM auftritt oder ob der Controller verzögert reagiert?
Ich hab das auch manchmal und in meinem Fall habe ich deutlich FHEM im Verdacht. Bestärkt wird das dadurch, dass auch andere Devices (z.B. Sonoff) nur verzögert schalten.

pj

[vbs]

Genau, wäre auch meine Vermutung.

Mach doch mal eine Minimal-FHEM-Config mit nur einem RGB-Controller drin und prüfe, ob das dann weiterhin auf tritt. Falls nicht, dann mal mit apptime prüfen, welche Geräte in deiner normalen Config die Delays verursachen.

[pjakobs]

hey, @vbs, nachdem ich heute den Produktionsauftrag für die 1000 Controller gegeben habe, können wir nochmal kurz über die freien GPIOs reden?
0, 2 und 16 sind jetzt auf den Header rausgezogen mit der Idee, dass man da Taster ran hängen kann.
Man könnte damit natürlich einerseits lokale Events auslösen (Licht an/aus, dimmen etc - das geht in Tasmota) aber ich fänd es besser, wenn das einfach einen Event im FHEM Device auslösen könnte, den man dann per Notify / Doif abfangen kann.
Siehst Du einen Weg, das sauber und ohne großen Aufwand zu implementieren? Du hast ja eh schon einen aktiven push event server eingebaut, der könnte doch auch Events für diese Pins liefern, oder?

pj

[kaihs]

moin, kannst Du mal untersuchen, ob die Verzögerung innerhalb FHEM auftritt oder ob der Controller verzögert reagiert?
Ich hab das auch manchmal und in meinem Fall habe ich deutlich FHEM im Verdacht. Bestärkt wird das dadurch, dass auch andere Devices (z.B. Sonoff) nur verzögert schalten.

pj

Danke für die Hinweise. Es war ein LacrosseGateway das disconnected war und dadurch hohe Last erzeugte.

[vbs]

Hatten da ja schon ein paar Mal drüber geredet, wenn ich mir recht erinnere... Gab da auch schon einen anderen User, der gerne die GPIOs auch als Ausgänge nutzen wollte. Das alles unter einen Hut zu bringen, ist machbar, aber macht schon etwas Arbeit. Es müsste dann per Config recht flexibel konfigurierbar sein. Die Firmware läuft außerdem ja auch auf anderer Hardware. Ich kann da momentan nichts versprechen.
Ein anderes Problem, das ich habe ist, dass die letzte "stable" Firmware über 6 Monate her ist. Seitdem hat sich in der "RC"-FW einiges getan (inkl. größerem Sming-Update). Ich hab die RC bei mir laufen aber es gab noch nicht genug Rückmeldungen, dass ich mich trauen würde, den Stand als "stable" zu deklarieren. Ich würde da in dem jetzigen Zustand ungern noch weitere Baustellen aufmachen.

[pjakobs]

Hatten da ja schon ein paar Mal drüber geredet, wenn ich mir recht erinnere... Gab da auch schon einen anderen User, der gerne die GPIOs auch als Ausgänge nutzen wollte.

Ich glaube, dass bei der gegebenen Hardware die IOs aus Ausgänge wenig sinnvoll sind.

Das alles unter einen Hut zu bringen, ist machbar, aber macht schon etwas Arbeit. Es müsste dann per Config recht flexibel konfigurierbar sein. Die Firmware läuft außerdem ja auch auf anderer Hardware.

Wie aufwendig wäre es denn, den Status "einfach" in Form von drei boolschen Readings darzustellen?

Ich kann da momentan nichts versprechen.
Ein anderes Problem, das ich habe ist, dass die letzte "stable" Firmware über 6 Monate her ist. Seitdem hat sich in der "RC"-FW einiges getan (inkl. größerem Sming-Update). Ich hab die RC bei mir laufen aber es gab noch nicht genug Rückmeldungen, dass ich mich trauen würde, den Stand als "stable" zu deklarieren. Ich würde da in dem jetzigen Zustand ungern noch weitere Baustellen aufmachen.

Ich hab die 4.0 jetzt auf die beiden Sampels gepackt und werde die mal ausgiebig testen.

pj

[vbs]

Für mich wäre das Hauptfeature eines lokalen Tasters, das man das Device noch schalten kann, wenn FHEM/MQTT ausfällt. Um da flexibel zu sein, müsste man am besten einen JSON-Befehl (gemäß API) einem Taster zuweisen können. Ist als JSON-Befehl wiederum etwas sperrig. Einfacher wäre es in Form eines FHEM-Befehls. Die Syntax versteht der Controller wieder aber nicht von sich aus... 

[pjakobs]

na ja, ein Schritt nach dem anderen.
Mit einer Schleife über FHEM (oder von mir aus auch gerne einem MQTT topic) ließe sich das jetzt schonmal remote lösen und später dann richtig machen.

pj

[edit]
noch ein Gedanke: ein Taster könnte ja einfach eine ein/aus Funktion haben und dann die gleiche Helligkeit/Farbe aktivieren, wie beim normalen Schalten über FHEM - zumindest wenn eine default Farbe vorgegeben ist. Wenn das Teil über FHEM ausgeschaltet ist und den aktuellen Zustand speichert, dann geht das natürlich nicht.
Diese Funktion müsste natürlich deaktivierbar sein, wenn ich über ein NOTIFY schalten will.

[pjakobs]

und mal zum rc: ich hab jetzt mal acht meiner Controller auf den Testing Pfad gesetzt. Ich werde Bericht erstatten.

pj

[kmxak]

Moin, im github steht auch was von udp Verbindung aber leider nichts genaueres. Ist da schon etwas in der Richtung eingebaut? Multicast wäre nett für meine Zwecke.
Aus Interesse worüber kommuniziert der der fhem  mit dem Controller? (tcp/json?)

Mqtt war ja nur für device Sync untereinander richtig?

Gruß Alex

Gesendet von meinem SM-G930F mit Tapatalk

[vbs]

Moin, im github steht auch was von udp Verbindung aber leider nichts genaueres. Ist da schon etwas in der Richtung eingebaut? Multicast wäre nett für meine Zwecke.

Hm, habe im Github nichts zu UDP gefunden gerade. Hast du einen Link? Sowas ist momentan nicht implementiert und auch eigentlich ncihts geplant in der Richtung.

Aus Interesse worüber kommuniziert der der fhem  mit dem Controller? (tcp/json?)

Im Normalfall wird JSON geredet (über HTTP/TCP). Der Event-Server redet auch JSON aber direkt auf TCP (ohne HTTP). Und es gibt eben noch MQTT anstelle von HTTP aber dann auch wieder mit JSON-Inhalten.

Mqtt war ja nur für device Sync untereinander richtig?

Genau. Jedoch ist der Controller ein "MQTT-Slave" in dem Moment. Ihm ist eigentlich egal, ob die MQTT-Steuerkommandos von einem anderen Controller kommen oder von etwas anderem. Also du kannst auch selbst die MQTT-Master-Kommandos per Hand versenden und der Controller wird drauf reagieren.

[kmxak]

Ja in deiner Wiki steht tcp/udp mit einer leeren Seite. Dachte da gäbe es evtl etwas. Aber gut das bringt mich schon mal ein gutes Stück vorwärts.

Gesendet von meinem SM-G930F mit Tapatalk

[Eisix]

@vbs: Habe jetzt einen Controller mit deiner FW + Modul seit 2 Tagen laufen.  Funktioniert soweit gut, Danke für die Arbeit.

Was mir aufgefallen ist:
- mein Device behält das attr Room nicht. Habe mich erst gewundert und dachte ich hätte es vergessen aber beim dritten mal muss es an was anderem liegen?
- mein Device habe ich nach dem ersten testen umbenannt und unter config-general-device_name ist immer noch der ursprüngliche Namen. Ist das so gewollt oder egal?
- Wäre es möglich das Modul mit basic auth kompatibel zu machen? Ich weiß es schützt nur bedingt aber zumindest kann nicht jedes Spielkind in meinem Netz am Licht basteln.

Gruß
Eisix

[vbs]

- mein Device behält das attr Room nicht. Habe mich erst gewundert und dachte ich hätte es vergessen aber beim dritten mal muss es an was anderem liegen?

Hm, keine Idee. Hab ich nichts mit zu tun, denk ich.

- mein Device habe ich nach dem ersten testen umbenannt und unter config-general-device_name ist immer noch der ursprüngliche Namen. Ist das so gewollt oder egal?

Das FHEM-Modul weist automatisch beim Verbinden den FHEM-Namen zu. Passt das für dich nicht? Wäre vermtl. wenig Aufwand, das einstellbar zu machen.

- Wäre es möglich das Modul mit basic auth kompatibel zu machen? Ich weiß es schützt nur bedingt aber zumindest kann nicht jedes Spielkind in meinem Netz am Licht basteln.

Ja, ist vermutlich machbar. Würde aber vermtl. so enden, dass das Passwort in FHEM als normales Attribut im Klartext sichtbar wäre. Ist das problematisch?