LD382 keine weichen Übergänge aus FHEM

Begonnen von martin2day, 14 Februar 2017, 09:54:45

Vorheriges Thema - Nächstes Thema

martin2day

Hallo zusammen,

um auch ein wenig mit den vorhandenen RGB LED's spielen zu können, habe ich mir kurzer Hand einen LD382a gekauft.
Dieser wird ja im Internet auf vielen Seiten hoch gelobt.

Nun habe ich alles installiert und mittels dem Modul WifiLight den LD382a auch in FHEM integriert.
Über den Router habe ich, da die neue Version ja keine Möglichkeit mehr besitzt, über die MAC eine feste IP per DHCP zugeordnet.
Der LD382a steht unmittelbar neben dem WLAN Router, Netz sollte also vorhanden sein.

Nun habe ich aber festgestellt, dass ich bei Rampen die 2s oder länge sind das Teil sichtbar ruckelt.
Nutze ich das WebInterface direkt über das iPhone funktioniert es einwandfrei.
Daher vermute ich ein Problem in meiner FHEM Konfiguration.
Was mir aufgefallen ist, wenn ich einen die Farbe über eine Rampe ändere ist im Event Monitor die Hölle los...

Ich bitte um Hilfe. Vielen Dank

Gruß Martin


Thorsten Pferdekaemper

Hi,
das hört sich so an, als ob FHEM die "Rampe" selbst macht. D.h. es müssen in recht kurzer Zeit viele Befehle rausgehen. Damit kann dann z.B. ein RasPi 1 überfordert sein. Das Web-Interface macht das vielleicht anders. Das müsste man mal analysieren.
Fang mal damit an, ein list Deines WifiLight-Devices in FHEM zu posten. Zeige und außerdem noch, wie Du genau die Rampe in FHEM auslöst.
...und vielleicht ein Auszug aus dem Event Monitor.
Gruß,
   Thorsten
FUIP

Take-Off

Hallo,

ich nutze ebenfalls das Modul WifiLight und kann dieses "Problem" bestätigen.
Die Rampe wird hier tatsächlich von FHEM heraus gesendet. Ich habe das Modul auf einem Raspi 2 und auf einem Raspi 3 laufen.
Der 3er schafft hier deutlich flüssigere Übergänge wobei dort auch der Umfang von FHEM deutlich kleiner ist.

Eine wirkliche Lösung gibt es dafür vermutlich nicht da Wifilight m.W. tatsächlich jeden Befehl einzeln an das Modul sendet. Dies kann man im EventMonitor auch schön beobachten.

Grüße
FHEM auf Raspberry Pi4
CUL868, CUL433, HM-CFG-USB2, HMW-LGW

martin2day

Hallo,

das habe ich auch vermutet, aber das kann ja nicht sein, oder? ;-)
Hier die list vom Device:
Internals:
   CONNECTION LD382A
   DEF        RGB LD382A:192.168.10.180
   IP         192.168.10.180
   LEDTYPE    RGB
   NAME       rgbTV
   NR         310
   NTFY_ORDER 50-rgbTV
   PORT       5577
   PROTO      1
   SLOT       0
   STATE      on
   TYPE       WifiLight
   Readings:
     2017-02-14 10:14:17   RGB             919116
     2017-02-14 10:14:17   brightness      57
     2017-02-14 10:14:17   hue             60
     2017-02-14 10:14:17   saturation      85
     2017-02-14 10:14:17   state           on
   Helper:
     COMMANDSET on off dim dimup dimdown HSV RGB
     llLock     0
     targetHue  60
     targetSat  85
     targetTime 1487063658.45162
     targetVal  57
     COLORMAP:
     0
     1
.......
    359
    0
GAMMAMAP:
       0
       0.0837677640068292
       0.243332430098219
........
98.4656868690975
       100
     hlCmdQueue:
     llCmdQueue:
Attributes:
   colorCast  0,-29,0,-10,0,10
   defaultColor 60,85,100
   defaultRamp 20
   dimStep    10 
   group      Licht Wohnzimmer
   room       Beleuchtung
   verbose    2
   webCmd     RGB
   whitePoint 1,1,1
   widgetOverride RGB:colorpicker,RGB


Ich habe eine feste Rampe vergeben, derzeit 10s. Schon ein einfaches ein und ausschalten funktioniert nicht ohne Ruckeln.

Hier ein Auszug beim einfachen ein/ausschalten
2017-02-14 14:41:50 WifiLight rgbTV brightness: 27
2017-02-14 14:41:50 WifiLight rgbTV RGB: 45450A
2017-02-14 14:41:50 WifiLight rgbTV on
2017-02-14 14:41:50 WifiLight rgbTV hue: 60
2017-02-14 14:41:50 WifiLight rgbTV saturation: 85
2017-02-14 14:41:50 WifiLight rgbTV brightness: 26
2017-02-14 14:41:50 WifiLight rgbTV RGB: 42420A
2017-02-14 14:41:50 WifiLight rgbTV on
2017-02-14 14:41:50 WifiLight rgbTV hue: 60
2017-02-14 14:41:50 WifiLight rgbTV saturation: 85
2017-02-14 14:41:50 WifiLight rgbTV brightness: 25
2017-02-14 14:41:50 WifiLight rgbTV RGB: 40400A
2017-02-14 14:41:50 WifiLight rgbTV on
2017-02-14 14:41:51 WifiLight rgbTV hue: 60
2017-02-14 14:41:51 WifiLight rgbTV saturation: 85
2017-02-14 14:41:51 WifiLight rgbTV brightness: 24
2017-02-14 14:41:51 WifiLight rgbTV RGB: 3D3D09
2017-02-14 14:41:51 WifiLight rgbTV on
2017-02-14 14:41:51 WifiLight rgbTV hue: 60
2017-02-14 14:41:51 WifiLight rgbTV saturation: 85
2017-02-14 14:41:51 WifiLight rgbTV brightness: 23
2017-02-14 14:41:51 WifiLight rgbTV RGB: 3B3B09
2017-02-14 14:41:51 WifiLight rgbTV on
2017-02-14 14:41:51 WifiLight rgbTV hue: 60
2017-02-14 14:41:51 WifiLight rgbTV saturation: 85
2017-02-14 14:41:51 WifiLight rgbTV brightness: 22
2017-02-14 14:41:51 WifiLight rgbTV RGB: 383808
2017-02-14 14:41:51 WifiLight rgbTV on
2017-02-14 14:41:52 WifiLight rgbTV hue: 60
2017-02-14 14:41:52 WifiLight rgbTV saturation: 85
2017-02-14 14:41:52 WifiLight rgbTV brightness: 21
2017-02-14 14:41:52 WifiLight rgbTV RGB: 363608


Ich habe dann einfach mal durch das attr event-on-change-reading:state nur das einfache on/off noch im Event anzeigen lassen.
Damit funktioniert der Verlauf viel besser, aber mir fehlt dann im Device die Rückmeldung welche Farbe und Welche Helligkeit gerade eingestellt wurde....

Bei mir läuft es auf einem aktuellen Pi3.

Gruß Martin

Thorsten Pferdekaemper

Zitat von: Take-Off am 14 Februar 2017, 14:48:17Eine wirkliche Lösung gibt es dafür vermutlich nicht da Wifilight m.W. tatsächlich jeden Befehl einzeln an das Modul sendet.
Das ist ja kein Grund dafür, dass es dafür keine Lösung gibt. Anscheinend gibt es ja ein Browser-Frontend, das weiche Übergänge macht. Vermutlich gibt es da einen Spezialbefehl, den man an die Steuerung schickt. Den muss man halt irgendwie aus FHEM heraus schicken. Warum sollte das nicht gehen?
Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Zitat von: martin2day am 14 Februar 2017, 14:49:16das habe ich auch vermutet, aber das kann ja nicht sein, oder? ;-)
Natürlich kann es das, warum nicht.
Du hattest von einem Web-Interface für das Teil geredet. Kannst Du mal einen Screenshot von der Seite schicken, mit der man eine "weiche" Rampe macht und die zugehörige HTML-Source?
Gruß,
   Thorsten
FUIP

martin2day

Thorsten,

na ja ich habe mich da falsch ausgedrückt. Es gibt eine App vom iPhone aus. MagicHome
Damit bekomme ich den Verlauf gut hin.
Davon kann ich aber den Code nicht einsehen... es bietet auch nicht viele Möglichkeiten.

Gruß Martin

Thorsten Pferdekaemper

FUIP

budy

Moin,

das ist eine Limitierung von Wifilight/FHEM. Das Modul müsste intern auf ein Thread-Model umgestellt werden, aber das schafft Joerg zur Zeit wohl nicht.
Ich habe mir aus diesem Grunde mal selber einen kleinen Python-Server geschrieben, den ich von FHEM aus ansteuere und damit geht es zumindets bei mir. Die Geschichte mit Wifilight auf einem RPix hinzubekommen, kannst du glaube ich abhaken. Ich hatte das aber auch mal auf einem Mac mini probiert und da war es dasselbel Problem... Wifilight wird andauernd unterbrochen und damit sind die Übergänge immer ruckelig.

Gruß,
Stephan
Debian stretch, FHEM 5.9.
HM-CC-RT-DN, HM-ES-PMSw1-Pl, HM-LC-Dim1TPBU-FM, HMUARTLGW, HMLAN, HM-SEC-KEY, HM-SEC-RHS, HM-SEC-SC-2, HM-SEC-SCo, HM-SEC-SD-2, HM-OU-CFM-TW, div. HUEs, Wifilight, Ring Video Pro

martin2day

Hallo Stephan,

also ist es wirklich so, dass FHEM die Übergänge selber erstellt und sende...
Okay, dann weiß ich persönlich erst einmal Bescheid und muss nicht weiter an meiner Einstellung "rumspielen".

Ich denke dafür sollte z.b. ein Arduino die passendere Wahl sein....

Vielen Dank für die Hilfe.

Gruß Martin

Thorsten Pferdekaemper

Zitat von: budy am 14 Februar 2017, 18:54:07
das ist eine Limitierung von Wifilight/FHEM. Das Modul müsste intern auf ein Thread-Model umgestellt werden, aber das schafft Joerg zur Zeit wohl nicht.
Weißt Du, was diese App treibt? Schickt die eine Art Dim-Befehl an den Controller oder schickt dann halt das Smartphone/Tablet in schneller Folge die Helligkeitswerte?
Gruß,
   Thorsten
FUIP

budy

Moin Thorsten,

Zitat von: Thorsten Pferdekaemper am 14 Februar 2017, 20:28:22
Weißt Du, was diese App treibt? Schickt die eine Art Dim-Befehl an den Controller oder schickt dann halt das Smartphone/Tablet in schneller Folge die Helligkeitswerte?
Gruß,
   Thorsten

also, nach allem, was ich weiß ist der LD382A ziemlich dumm und hat solche Befehle gar nicht. Wifilight und auch meine kleine App müssen von daher den ganzen Kram selber machen. Das müsste man aber tatsächlich mit tcpdump/wireshark sehen können, wenn man es drauf anlegte.

Gruß,
Stephan
Debian stretch, FHEM 5.9.
HM-CC-RT-DN, HM-ES-PMSw1-Pl, HM-LC-Dim1TPBU-FM, HMUARTLGW, HMLAN, HM-SEC-KEY, HM-SEC-RHS, HM-SEC-SC-2, HM-SEC-SCo, HM-SEC-SD-2, HM-OU-CFM-TW, div. HUEs, Wifilight, Ring Video Pro

Thorsten Pferdekaemper

Zitat von: budy am 14 Februar 2017, 18:54:07Ich habe mir aus diesem Grunde mal selber einen kleinen Python-Server geschrieben, den ich von FHEM aus ansteuere
Ist das Ding für die "Öffentlichkeit" geeignet? Dann könnte man das vielleicht auch als Lösung hier anbieten.
Gruß,
   Thorsten
FUIP

r00t2

Ich plane ebenfalls die Anschaffung eines solchen LED Steuermoduls und klinke mich mal mit ein.

Was ich nicht so ganz verstehe:
Wenn der Host (Handy, RPi, PC, ...) die ganze Umrechnung selbst macht, warum sollte dann ein RPi3 nicht ausreichend dimensioniert sein? Ist ein iPhone oder ein x-beliebiges Android-Smartphone denn wirklich so viel performanter (vor allem, weil auf deinen doch meist eh noch viel anderer "App Müll" nebenbei läuft)?

Oder limitiert hier nicht die Prozessorleistung an sich, sondern die Anbindung von Wifilight an FHEM bzw. umgekehrt?

Gruß
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

Thorsten Pferdekaemper

Zitat von: r00t2 am 15 Februar 2017, 13:09:10Wenn der Host (Handy, RPi, PC, ...) die ganze Umrechnung selbst macht, warum sollte dann ein RPi3 nicht ausreichend dimensioniert sein?
Ich vermute mal in etwa so:
FHEM macht da deutlich mehr, als man erst einmal denkt. Wie man am Event-Monitor-Auszug ein paar Posts vorher sieht, produziert das WifiLight-Modul eine ganze Reihe von Events. Dafür müssen die entsprechenden Readings gestzt warden und natürlich muss alles durch die Event-Loop. Natürlich ist das alles optimiert, aber irgendwann reicht das halt nicht mehr. Möglicherweise kann man was mit event-min-interval und ähnlichem machen, aber auch hier muss das System ja erstmal nachsehen, ob das Event davon betroffen ist oder nicht.
Ich denke mal, für eine richtig gute Lösung müsste man etwas am Modul ändern. Dann könnte man z.B. nur alle 5 Sekunden den Zustand melden, was ausreichen sollte. Noch besser wäre wahrscheinlich, wenn man einen eigenen Server-Prozess hätte, der parallel läuft und das übernimmt. Dann könnte man den RasPi 3 auch ausnutzen. Ansonsten dürfte es kaum einen Unterschied machen, ob RasPi 2 oder 3.

Also für Martin: Versuch mal per event-min-interval etc. die Anzahl der Events zu minimieren. Das könnte schonmal helfen.

Gruß,
   Thorsten

Gruß,
   Thorsten

 
FUIP