Wifilight.pm

Begonnen von herrmannj, 18 Januar 2014, 04:10:07

Vorheriges Thema - Nächstes Thema

herrmannj

die HUE machen das auf dem device. Logischerweise schick :) Der Vergleich ist aber mMn ein klein wenig ;) Apfel und Birne - siehe Preis ...

Beim LD382: teste das mal mit einer leeren cfg. Kannste ja aus sf ziehen, Deine aktuelle cfg gut sichern, die leere testweise einsetzen und *NUR* den LD382 installieren.

Wenn der dann deutlich flüssiger läuft kannst Du evtl in Deiner "echten" cfg tuning durchführen.

vg
joerg

budy

Zitat von: herrmannj am 07 Oktober 2015, 20:04:41
die HUE machen das auf dem device. Logischerweise schick :) Der Vergleich ist aber mMn ein klein wenig ;) Apfel und Birne - siehe Preis ...

Ich habe mich nicht beschwert...!  ;) Mir ist völlig klar, dass man beim LD382 nur das bekommt, was man bezahlt hat und das sich Philips natürlich die ganze Entwicklung bezahlen lässt. Daran ist nichts auszusetzen und die Kombi LD382 plus ein ordentliches Netzteil und ein 5m RGBW machen dafür ja auch mehr Licht.

Zitat von: herrmannj am 07 Oktober 2015, 20:04:41
Beim LD382: teste das mal mit einer leeren cfg. Kannste ja aus sf ziehen, Deine aktuelle cfg gut sichern, die leere testweise einsetzen und *NUR* den LD382 installieren.

Wenn der dann deutlich flüssiger läuft kannst Du evtl in Deiner "echten" cfg tuning durchführen.

vg
joerg

Nun, daran habe ich auch schon gedacht und hatte auch mal dein Perfmon Modul mitlaufen, aber obwohl ich schon fit in Linux und Perl bin, habe ich es nicht herausbekommen, was da zweimal die Minute am bremsen ist...
Ich hatte dann mal testweise einen FHEM auf einem anderen Rechner installiert, wo ich tatsächlich nur den LD383 drin hatte, aber das Ergebnis war halt trotzdem nicht so toll. Besser als auf dem Raspi2, aber so richtig fließend war das trotzdem nicht.

Daher ja auch meine Idee, es mal mit Python zu probieren.

Und auch ein ganz klares Statement... ich mag das Wifilight Modul und käme auch nicht im Traum darauf, mir hier etwas eigenes basteln zu wollen!

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

herrmannj

no prob, ist nicht als Beschwerde angekommen :)

Irgendwann (in ferner Zukunft !) werde ich die transitions mal in einen eigenen Prozess auslagern. Damit ist das timing dann von anderen modulen unabhängig.

Das ist aber nicht ganz trivial und hat bei mir auch keine prio :)

vg
joerg

mike.d

Top. Funktioniert "relativ" stabil. :- )

Danke!

Zitat von: herrmannj am 28 September 2015, 16:53:07
genauso ist es. Hatten wir auch schon einige Male.

Die App verhält sich anders weil sie die Verbindung komplett aufbaut. Das ist für fhem keine option weil dann Software fades extrem ruckeln würden.

Normaler advice ist, lass das Ding am Strom. Geht jetzt bei Dir nicht wirklich.

Die Idee hinter dem Vorschlag ein Kommando an den stromlosen LD382 zu schicken: in diesem Fall kann fhem registrieren das der LD382 weg ist und kappt die Verbindung.

Wenn Du ihn dann erst wieder ansprichst wenn er komplett gebootet hat wird die Verbindung ebenfalls komplett neu aufgebaut. Kannst ja mit dem Wissen nochmal versuchen.

Wenns echt nicht geht habe ich leider keine weitere Idee. Solange der LD382 die Kommandos annimmt (und dann nichts macht) ohne sie zurückzuweisen lässt sich das von fhem aus nicht messen. Sorry

vg
joerg

budy

Zitat von: herrmannj am 08 Oktober 2015, 09:45:29
no prob, ist nicht als Beschwerde angekommen :)

Irgendwann (in ferner Zukunft !) werde ich die transitions mal in einen eigenen Prozess auslagern. Damit ist das timing dann von anderen modulen unabhängig.

Das ist aber nicht ganz trivial und hat bei mir auch keine prio :)

vg
joerg

Völlig verständlich...

Ich habe mal eben einen sehr kleinen Python client zusammen gehackt, der mir auf meinem LD382A mal Rot komplett rauf und wieder runter fährt. In Python geht das auf meinem MBP und meinen Raspi2 völlig gleich. In beiden Fällen gibt es eine sehr flüssige Transition mit rund 60 tps(?). Der Python code war auf meinem MBP ein wenig schneller abgearbeitet als auf dem Raspi2, aber bei einer transision time von 4s für Rot 0->255 von 0.22s vs 0.33s fällt das wohl nicht ins Gewicht... ;)

Sprich, auf auf dem LD382 werden die Transisions wohl gebuffert, da die TCP-Connection bereits nach 0,2s wieder zu war. Wenn es also auf dem Raspi2 mit FHEM ruckelt, dann kann das nur an FHEM selber liegen...

Bei Interesse poste ich gerne mal den lütten Python client... ;)

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

herrmannj

Wenn es also auf dem Raspi2 mit FHEM ruckelt, dann kann das nur an FHEM selber liegen...

Ja, so ist es. Fhem macht ein "kooperatives Multitasking", da heist Wifilight bekommt keine garantierten Zeitscheiben. Weil das Auge sehr empfindlich ist werden bereits kleine Störungen in diesem timing sichtbar und das Ergebniss ist sehr davon abhängig "was die anderen" module so machen.

In meinem (persönlichen) setup hier spielt das übrigens kaum eine Rolle. Module die Blocking arbeiten verwende ich nicht und wirklich schnelle transitions brauch ich nicht. Um weich zwischen Lichtszenen zu wechseln reicht das locker.

Die Funktion Deines phyton clients geht schon ein wenig in Richtung des eigenen Prozesses. Die Schwierigkeiten kommen weil der Prozess gesteuert werden muss. Angenommen Du fadest über 20 Sekunden, brichst aber nach 5 Sekunden mit einem anderen Befehl ab dann müssen die beiden Prozesse (Wifilight und der "fader") kommunizieren. Noch komplexer wirds bei den milights - da müssen alle Leuchtmittel auf einer bridge berücksichtigt werden. Daher das "nicht trivial".

vg
joerg

budy

Na jaa... ich wollte den Python client auch nicht integrieren, sondern nur mal sehen, wie das so geht. Ich benötige auch keine schnellen transisions und wenn ich Party machen will, dann gibt es für meine HUE(s) dafür Programme wie Sand am Meer... ;)

Da der LD382A je eh' keine Rückmeldung gibt, wäre alles andere auch eher logistisches Harakiri, was die synchronisation zwischen dem FHEM/Wifilight und dem extra laufenden Python client angeht... Da kann ja im Haus jederzeit jemand auf einen der vielen Knöpfe drücken...

Weißt du, ob es irgendwo eine dokumentierte API gibt... ist wahrscheinlich eine dumme Frage, aber trotzdem - dümmer wird man ja nicht.

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

herrmannj

für den ld382 ?

Eine API, so im Wortsinn, haben die sowieso nicht.

Das Protokoll ist auch nirgends dokumentiert. Das wir das nehmen ist das Ergebniss von reverse engeneering. Das mit

dem synchrionisieren ist garnicht so Harakiri. Wenn die Transitions irgendwann mal in einen eigenen Prozess sollen dann muss das sein. Dabei ist es auch egal ob der dann phyton oder perl ist. Ein seperater perl Prozess kann das genauso schnell. Man muss halt gleichzeitig auch so designen das dann ein einziger Prozess ALLE wifilight device abfrühstückt. Sonst haste bei 15 Lampen auch 15 Prozesse.

Vom speed her ist da auch fhem nicht so übel. Ich habe (damals ;-) ) einen lw12 auf der fritzbox mit ca 30Hz laufen gehabt. Dürfen halt keine bremsenden Module installiert sein, filelogs optimieren, notifys anpacken und optimieren.

vg
joerg

budy

#1553
Zitat von: herrmannj am 08 Oktober 2015, 21:44:50
für den ld382 ?

Vom speed her ist da auch fhem nicht so übel. Ich habe (damals ;-) ) einen lw12 auf der fritzbox mit ca 30Hz laufen gehabt. Dürfen halt keine bremsenden Module installiert sein, filelogs optimieren, notifys anpacken und optimieren.

vg
joerg

Tja... ich habe meine beiden "Problem-Module" gefunden... STV und XMBC... beide scheinen mit Geräten, welche aus sind nicht so besonders gut zurecht zu kommen... ;) Ich habe die beiden schließlich über apptime identifiziert, nachdem ich alle filelogs, welche ich nicht unbedingt benötige  - sprich alle außer das vom fhem selber - deaktiviert habe.

Außerdem muss man natürlich beim faden auch darauf achten, was man möchte und was das System leisten kann. Wenn man also bei einer max. Frequenz von 60Hz vom LD382 verlangt innerhalb von 2s von 100 auf 0 zu dimmen, dann muss man zwangsläufig Ruckler, durch die ausgelassenen Frames, bekommen.

Man kann sich also die Ramp nur bedingt aussuchen... ;) Ich habe vorhin mal beide TVs eingeschaltet und dann waren die perfmon-Nachrichten weg, apptime war sauber und eine ramp von 4s brachte eine fast saubere Transition von 100 auf 0. ;)

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

RidcuIIy

Hallo, ich habe Fragen zum LD382:

Farbwechsel.

Der Controller unterstützt eigene Scenes. Ich kann z.B. via App z.B. eine Farbe pulsieren oder einen Farbwechsel über das Spektrum ablaufen lassen. Das wird nicht über das Smartphone, sondern direkt auf dem Controller gesteuert (ich habe die App auf dem Smartphone gekillt / den Controller stromlos gemacht und nach Neubestromung lief die Scene weiter.

Kann man das in Wifilight integrieren / kennt jemand eine andere Möglichkeit um solche Scenes auf dem Controler auszulösen?

DIM über FHEM

Ich setze eine Farbe und eine Helligkeit über APP. Über FHEM setze ich ein set <name> dim 100 ab. Er dimmt immer weiß auf.
Gibt es hier, außer sich für einen ausschließlichen Weg (App oder FHEM) zu entscheiden, Abhilfe?

Neustart

Wenn der Controller stromlos gemacht wurde bekommt FHEM (anscheinend) keine Verbindung mehr hin. Schalte ich den LD382 ab und wieder an kriege ich diesen erst unter Kontrolle wenn ich einen Shutdown restart durchgeführt habe.Da dieser an einem Stromkreis angeschlossen ist der beim Verlassen der Wohung abgeschaltet wird, hängt, ist das suboptimal.

Sollte eine der Fragen bereits beantwortet worden sein, was bei der Länge des Threads nicht unwahrscheinlich erscheint, bitte ich um Entschuldigung. Wenn Funktionen nicht umgesetzt werden konnten da die API nicht hinreichend bekannt ist kann ich gerne versuchen via Wireshark Informationen zu erlangen, sofern hilfreich.

Stefan

Amenophis86

Zitat von: RidcuIIy am 19 Oktober 2015, 23:56:02
Wenn der Controller stromlos gemacht wurde bekommt FHEM (anscheinend) keine Verbindung mehr hin. Schalte ich den LD382 ab und wieder an kriege ich diesen erst unter Kontrolle wenn ich einen Shutdown restart durchgeführt habe.Da dieser an einem Stromkreis angeschlossen ist der beim Verlassen der Wohung abgeschaltet wird, hängt, ist das suboptimal.

Ist schon lange bekannt und lässt sich leider nicht ändern. Habe auch von schaltbarer Steckdose abgesehen, weil es sich sonst nicht richtig schalten lässt oder du jedes mal bis zu 30 min warten musst, bis FHEM es wieder schalten kann.

Der Rest deiner Frage wurde glaube auch schon im Thread besprochen, aber gerade zu faul es zu suchen. Denke die SuFu könnte dir dazu auch ne Antwort liefern ;)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

P.A.Trick

Zitat von: Amenophis86 am 20 Oktober 2015, 00:09:29
Ist schon lange bekannt und lässt sich leider nicht ändern. Habe auch von schaltbarer Steckdose abgesehen, weil es sich sonst nicht richtig schalten lässt oder du jedes mal bis zu 30 min warten musst, bis FHEM es wieder schalten kann.

Der Rest deiner Frage wurde glaube auch schon im Thread besprochen, aber gerade zu faul es zu suchen. Denke die SuFu könnte dir dazu auch ne Antwort liefern ;)

Das stimmt nicht, man kann den TCP Timeout im Webmenue ändern!
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

Amenophis86

fast richtig. Bei der alten Version war dies möglich, bei der neuen kommt man nicht mehr in die WebUI rein. Und ja, die login daten admin nimda sind bekannt. Aber die WebUI wurde abgeschaltet bzw. hat vermutlich einen Fehler und der Verkäufer auf Amazon ist nicht in der Lage hierzu Antworten bzw Support zu geben.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

P.A.Trick

Ich sag ja Philps oder Osram rocken mehr :-)
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

herrmannj

#1559
ZitatDenke die SuFu könnte dir dazu auch ne Antwort liefern
ja würde, aber ich versuch mal abzukürzen.

ZitatDer Controller unterstützt eigene Scenes...Kann man das in Wifilight integrieren / kennt jemand eine andere Möglichkeit um solche Scenes auf dem Controler auszulösen?
Njet. .. weil controller spezifisch. Das wäre nur im Rahmen eines moduls exklusiv für den LD382 möglich.

ZitatGibt es hier, außer sich für einen ausschließlichen Weg (App oder FHEM) zu entscheiden, Abhilfe?
Entweder App oder fhem ...

ZitatWenn der Controller stromlos gemacht wurde bekommt FHEM (anscheinend) keine Verbindung mehr hin. Schalte ich den LD382 ab und wieder an kriege ich diesen erst unter Kontrolle wenn ich einen Shutdown restart durchgeführt habe.Da dieser an einem Stromkreis angeschlossen ist der beim Verlassen der Wohung abgeschaltet wird, hängt, ist das suboptimal.
Ist ein limit in der fw des LD382 (und anderer).
irgendwo innerhalb der setzen 100 post ;) haben wir das mal so gelöst: strom weg, einige Minuten später ein "off" an den LD382 senden. Dann kann fhem registrieren das er weg ist. Soweit ich höre scheint das zu funktionieren.
ZitatIch sag ja Philps oder Osram rocken mehr :-)
Hatten wir auch schon. HUE ist die bessere Hardware, ohne Frage. Vom Preis her manchmal auch nicht. Hängt also sicher davon ab was ich damit mache. 4x e27 HUE in der Deckenleuchte haut halt rein und bringt da auch nicht so viel mehr ;) Ist Apfel gegen Birne. 

vg
joerg