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
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
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
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
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
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
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
Wireshark?
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
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
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
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
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
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ß
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
Hallo Thorsten,
das habe ich bereits gemacht und auch geschrieben.
Ich habe mittels event-on-change-reading:state nur den eigentlichen on/off Zustand abgefragt. Das Eventlog ist damit vollkommen leer.
Damit habe ich viel bessere Übergänge erhalten. Nicht optimal, aber es wäre ausreichend, aber:
Beim Rumspielen ist mir ein weiteres Sachverhalt aufgefallen. Ich nutze unter anderem auch die Verbindung zur S7, auch andere Module können schon mal mehr wie 100ms in Anspruch nehmen. Ich habe beobachtet, dass ich teilweiße im Verlauf wie Blitze (kurzes helles aufflackern) habe, immer dann wenn im Event durch ein anderes Device etwas mehr geschrieben wird.
Ich vermute hier, dass Daten dann nur Teilweiße an den LD382 Übertagen werden, weil er bleibt nicht da stehen wo er ist, sondern geht auf einen umplausiblen Wert.
Aber leider bin ich was das angeht zu viel Leihe um bessere Aussagen treffen zu können. Aber im Grunde denke ich ist es in meinen Augen die falsche Herangehensweise zweitkritische Dinge, die zyklisch bearbeitet werden müssen, in FHEM zu erledigen.
Ich denke deine Antwort mit einem eigenem Server Prozess ist damit auch gemeint.
Gruß Martin
Ein eigener Prozess wäre schon was Feines.
Und wenn, wie Martin ja bereits schreibt, das "Ausdünnen" der Events schon etwas bringt, könnte man das ja ggf. gleich damit einbeziehen.
eine Kombination aus event-min-interval und event-on-change-reading wäre da auf jeden Fall ein Ansatz.
Wenn z. B. jedes Mal ein Event für "on" oder "hue" bzw. "saturation" generiert wird, obwohl die Readings sich nicht (jedes Mal) ändern, dann nimmt das schon etwas Last vom System.
Und wenn das Modul jetzt sendeseitig noch soweit optimiert wird, dass es nur noch ein "on" sendet, wenn es auch benötigt wird (sprich, es noch nicht auf "on" ist) etc. könnte man noch etwas mehr raus holen, denke ich.
Werde mir das Gerät dann mal bestellen und an die Test-FHEM anschließen. Mal sehen, ob ich etwas dazu beitragen kann, dass es flüssiger läuft.
Zitat von: r00t2 am 15 Februar 2017, 16:01:21
Ein eigener Prozess wäre schon was Feines.
M.E. noch cooler wäre eine eigene HW-Schnittstelle für die Milights.
Es gibt das Projekt openmili, auf dessen Basis schka17 hier auch (auf ESP8266-Basis) eine eigene Bridge-Lösung vorgestellt hat.
Meine Idee dazu wäre, das dahingehend aufzubohren, dass man den Transition-Prozess vom SW-Modul trennt. Und dafür dann nur ein paar Parameter vorab an die HW-Bridge (Arduino oder ESP8266) zu übergeben. Die könnte dann die notwenigen RF-Befehle und das Timing für's Absetzen autonom generieren. Das ginge sogar gruppenweise.
Das "Schmankerl" wäre, das zusätzlich noch als Fernbedienungsempfänger zu nutzen und einen Rückkanal einzubauen :).
Gruß, Beta-User
Zitat von: martin2day am 15 Februar 2017, 15:55:31das habe ich bereits gemacht und auch geschrieben.
Sorry, hab ich anscheinend übersehen.
ZitatIch nutze unter anderem auch die Verbindung zur S7, auch andere Module können schon mal mehr wie 100ms in Anspruch nehmen.
So etwas versuche ich zu vermeiden. In meiner Installation darf eigentlich kein Modul mehr als 100ms blockieren.
ZitatIch habe beobachtet, dass ich teilweiße im Verlauf wie Blitze (kurzes helles aufflackern) habe, immer dann wenn im Event durch ein anderes Device etwas mehr geschrieben wird.
Ich vermute hier, dass Daten dann nur Teilweiße an den LD382 Übertagen werden, weil er bleibt nicht da stehen wo er ist, sondern geht auf einen umplausiblen Wert.
Das ist jetzt aber auch etwas seltsam. Ich hätte schon erwartet, dass da alles auf einmal übertragen wird. Wenn die "Schnittstelle" hier aber so ähnlich ist wie bei den MiLights, dann... Naja.
ZitatAber im Grunde denke ich ist es in meinen Augen die falsche Herangehensweise zweitkritische Dinge, die zyklisch bearbeitet werden müssen, in FHEM zu erledigen.
Das kann man so oder so sehen. Natürlich wäre anders besser, aber so geht es wenigstens einigermaßen. Anders wäre wohl keine Zeit dafür gewesen und dann gäbe es das gar nicht. Wenn man außerdem einen ordentlichen Rechner nimmt und keine blockierenden Module verwendet, hat man das Problem ggf. auch nicht.
Zitat von: Beta-User am 15 Februar 2017, 16:17:04
M.E. noch cooler wäre eine eigene HW-Schnittstelle für die Milights.
Es gibt das Projekt openmili, auf dessen Basis schka17 hier auch (auf ESP8266-Basis) eine eigene Bridge-Lösung vorgestellt hat.
Meine Idee dazu wäre, das dahingehend aufzubohren, dass man den Transition-Prozess vom SW-Modul trennt. Und dafür dann nur ein paar Parameter vorab an die HW-Bridge (Arduino oder ESP8266) zu übergeben. Die könnte dann die notwenigen RF-Befehle und das Timing für's Absetzen autonom generieren. Das ginge sogar gruppenweise.
Das "Schmankerl" wäre, das zusätzlich noch als Fernbedienungsempfänger zu nutzen und einen Rückkanal einzubauen :).
...also eigentlich wollte ich das mal mit Homebrew-Wired machen... Aber wie immer fehlt die Zeit.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 15 Februar 2017, 16:26:12
...also eigentlich wollte ich das mal mit Homebrew-Wired machen... Aber wie immer fehlt die Zeit.
...Zeit ist das eine, aber meine programmiertechnischen Kenntnisse sind auch eher bescheiden...
Hier wäre ja neben der eigentlichen HW-Schnittstelle noch erforderlich, dass man auch die Ansteuerung per Modul irgendwie hinbekommt. Und dann ist diese Implementierung mit 4in1 auch irgendwie naja...
Vielleicht müßte man sich dazu mal eine Roadmap machen, mit der man eine generische Lösung hinbekommt, die am besten auch noch die "neuen" (längeren) MiLight-Codes berücksichtigt... Halt eine Art Signalduino für MiLight :). Am liebsten wäre mir schlicht eine Arduino-Lösung mit serieller Ausgabe ;).
Gruß, Beta-User
Bei Homebrew-Wired wäre ich auch mit dabei.
Wäre mir sogar um einiges lieber, als ein WLAN Gerät...
Habe mir gerade einen Controller und eine PSU bestellt und bin zu einigen Schandtaten bereit, wenn die Sachen da sind :)
Muss ja nicht gleich eine "alles-in-1" Lösung sein, eine abgespeckte, die erweiterbar ist, tut es ja auch für den Anfang.
Hätte vielleicht gleich noch eine Ethernet Schnittstelle für Arduino Nano bestellen sollen :)
Zitat von: Thorsten Pferdekaemper am 15 Februar 2017, 13:01:44
Ist das Ding für die "Öffentlichkeit" geeignet? Dann könnte man das vielleicht auch als Lösung hier anbieten.
Gruß,
Thorsten
Das Teil liegt auf Github... https://github.com/budachst/ld382
Gruß,
Stephan
Zitat von: budy am 15 Februar 2017, 21:12:25
Das Teil liegt auf Github... https://github.com/budachst/ld382
Gruß,
Stephan
Hallo Stephan,
klingt sehr interresant, aber ich bin noch nie mit einem Python-Server in Kontakt gekommen...
Den Code habe ich in der 99_MyUtils drinnen und die ld382.py hab ich auch auf dem Raspi
Aber wie bekomme ich jetzt den Server zum laufen ?
Wenn ich in die Kommandozeile in FHEM
getLD382aValues("WZ_WifiLight") bzw.
getLD382aValuesNew("WZ_WifiLight") eingebe bekomme ich
Unknown command getLD382aValues("WZ_WifiLight"), try help. Gruß
Sascha
Zitat von: perseusarm am 16 Februar 2017, 23:28:01Wenn ich in die Kommandozeile in FHEM getLD382aValues("WZ_WifiLight")
Versuch mal
{getLD382aValues("WZ_WifiLight")}
Ich nehme an, dass das Perl ist.
Gruß,
Thorsten
Bei {getLD382aValuesNew("WZ_WifiLight")} bekomme ich
ERROR in Socket Creation : Verbindungsaufbau abgelehnt.
Ich vermute weil ich das kleine Python-Server Skript nicht als Server laufen habe, oder ?
Hi,
ja klar, das musst Du schon laufen lassen. Zum Test kannst Du es ja mal einfach manuell starten.
Gruß,
Thorsten
Danke für die Mühe, aber ich hab das Thema erst mal nach hinten geschoben um die wichtigen Dinge zu realisieren.