LD382 keine weichen Übergänge aus FHEM

[martin2day]

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

[r00t2]

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.

[Beta-User]

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

[Thorsten Pferdekaemper]

das habe ich bereits gemacht und auch geschrieben.

Sorry, hab ich anscheinend übersehen.

Ich 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.

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.

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.

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.

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.

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 

[Beta-User]

...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

[r00t2]

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

[budy]

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

[perseusarm]

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

Code Auswählen Erweitern

getLD382aValues("WZ_WifiLight") bzw.

Code Auswählen Erweitern

getLD382aValuesNew("WZ_WifiLight") eingebe bekomme ich

Code Auswählen Erweitern


Unknown command getLD382aValues("WZ_WifiLight"), try help. 

Gruß
Sascha

[Thorsten Pferdekaemper]

Wenn ich in die Kommandozeile in FHEM

Code Auswählen Erweitern

getLD382aValues("WZ_WifiLight")

Versuch mal

Code Auswählen Erweitern


{getLD382aValues("WZ_WifiLight")}

Ich nehme an, dass das Perl ist.
Gruß,
  Thorsten

[perseusarm]

Bei

Code Auswählen Erweitern

{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 ?

[Thorsten Pferdekaemper]

Hi,
ja klar, das musst Du schon laufen lassen. Zum Test kannst Du es ja mal einfach manuell starten.
Gruß,
   Thorsten

[perseusarm]

Danke für die Mühe, aber ich hab das Thema erst mal nach hinten geschoben um die wichtigen Dinge zu realisieren.