Neues Modul: 30_MilightBridge / 31_MilightDevice

[Markus M.]

Ich (glaube) dass ich zur Zeit darüber stolpere, dass Reading und Set für RGB unterschiedlich geschrieben werden (rgb vs. RGB)

Was so natürlich keinen Sinn macht.
Fix siehe Anhang, die alten Reading bekommst du raus mit deletereading lampe.* RGB (je nachdem wie deine Geräte heissen).

[elfrinjo]

Danke, funktioniert!

[inesa394]

Warum funktioniert dieses DOIF nicht
([?{sunset(0,"19:00","21:00")}-23:00] and [HausBewohner] eq "home" ) (set Wz.DeckeFarbe hsv 0,0,75 300) DOELSE (set Wz.DeckeFarbe dim 0 120)
Fhem meldet mir diesen Fehler
set Wz.DeckeFarbe hsv 0: Usage: set Wz.DeckeFarbe hsv <h(0..360)>,<s(0..100)>,<v(0..100)> [seconds(0..x)] [flags(l=long path|q=don't clear queue)] 75 300: Unknown command 75, try help.
Wenn ich aber set Wz.DeckeFarbe hsv 0,0,75 300 händisch eingebe funktioniert es
cu

[herrmannj]

http://fhem.de/commandref_DE.html#DOIF

Falls ein Komma nicht als Trennzeichen zwischen FHEM-Befehlen gelten soll, so muss der FHEM-Ausdruck zusätzlich in runde Klammern gesetzt werden:

[inesa394]

So dann ((set lampe hsv 0,0,75 300)) ??

[inesa394]

So funktioniert es nur leider dimmt er so nicht langsam hoch
([?{sunset(0,"19:00","21:00")}-23:00] and [HausBewohner] eq "home" ) ((set Wz.DeckeFarbe hsv 0,0,75 300)) DOELSE (set Wz.DeckeFarbe dim 0 120)
Wenn ich es dann so versuche bekomme ich error im log
([?{sunset(0,"19:00","21:00")}-23:00] and [HausBewohner] eq "home" ) ((set Wz.DeckeFarbe dim 0,set Wz.DeckeFarbe hsv 0,0,75 300)) DOELSE (set Wz.DeckeFarbe dim 0 120)
Vieleicht bin ich auch hier im falschen Thread um meine Fragen loszuwerden

[Kriebs]

Hi,

bin selbst noch neu im Thema aber:

dim <percent(0..100)> [seconds(0..x)] [flags(l=long path|q=don't clear queue)]

heißt für mich:

(set Wz.DeckeFarbe dim 0 120)  <-- die 0 muss z.B. 100 sein für 100%.

Gruß
Torsten

[kennymc.c]

Wie sieht es mit dem Modul eigentlich bei der Zuverlässigkeit aus? Hab momentan noch mehrere LD382 im Einsatz, die ja direkt über Wifi mit Fhem kommunizieren. Leider gibt das immer wieder Probleme, so das manchmal die LEDs erst nach mehreren Aufforderungen reagieren oder der Controller erst neu gestartet werden muss. Gibt es solche Probleme auch mit den MiLights oder hilft da die zusätzliche Funkverbindung?
Was ich hier schon mehrmals gefragt habe, aber immer noch nicht beantwortet bekommen habe: Sind Dimmvorgänge und Farbverläufe komplett ruckelfrei? Ist der Controller selbst dafür verantwortlich oder muss das vorher in Fhem berechnet und in einzelnen Befehlen übertragen werden?

[Noxus]

Wie sieht es mit dem Modul eigentlich bei der Zuverlässigkeit aus? Hab momentan noch mehrere LD382 im Einsatz, die ja direkt über Wifi mit Fhem kommunizieren. Leider gibt das immer wieder Probleme, so das manchmal die LEDs erst nach mehreren Aufforderungen reagieren oder der Controller erst neu gestartet werden muss. Gibt es solche Probleme auch mit den MiLights oder hilft da die zusätzliche Funkverbindung?
Was ich hier schon mehrmals gefragt habe, aber immer noch nicht beantwortet bekommen habe: Sind Dimmvorgänge und Farbverläufe komplett ruckelfrei? Ist der Controller selbst dafür verantwortlich oder muss das vorher in Fhem berechnet und in einzelnen Befehlen übertragen werden?

Ich habe momentan eine LED Stripe und 4 Lampen von Milight über fhem im Einsatz.
Zuverlässigkeit: 100%     nichts mit Neustarten oder so...
Dimmvorgänge sind ruckelfrein (gerade noch getestet und von Frau bestätigt)

[Markus M.]

Sind Dimmvorgänge und Farbverläufe komplett ruckelfrei? Ist der Controller selbst dafür verantwortlich oder muss das vorher in Fhem berechnet und in einzelnen Befehlen übertragen werden?

Die Befehle (Queue) laufen in FHEM.

Übertragungsfehler sind selten, kommen aber vor.
Ich hatte ein Montagsmodell der Bridge das ständig die wlan Verbindung verloren hat. Wenn die hält, bemerkt man im Alltag aber nichts. Wenn nicht, nimmt das Modul in meiner Version den Schaltvorgang nicht an.
Eventuell kann ich das noch umbauen so dass die Befehle in die Queue geschrieben werden.
Ich weiß aber nicht ob es Sinn macht, etwas 10 oder 30 Minuten später auszuführen wenn die Verbindung wieder da ist.

Für White habe ich einen Modus eingebaut der so etwas teilweise tut.
Bei absoluten Befehlen (nur RGBW) könnte man auch mehrmals senden.
Ohne dass das jemand wirklich braucht werde ich es aber nicht implementieren. Das kann man nach Bedarf auch in der Programmierung machen.

Bei mir läuft es jedenfalls zuverlässig genug.

Gruß, Markus

[hyper2910]

Hallo,


habe dieses Modul jetzt seit Anfang des Jahres im Einsatz, vorher das Wifilight.pm von hermannJ.


Bin total zufrieden nur habe ich ein kleines Problem.

Immer mal wieder schleicht sich dieses Stück Code ein, obwohl ich nichts daran verändere, auch nach einem Löschen ist es nach ein paar Tagen wieder da und gibt natürlich eine Fehlermeldung, aber woher kommt dieses:

Code Auswählen Erweitern

attr LICHT lightSceneParamsToSave hsv

[Markus M.]

Immer mal wieder schleicht sich dieses Stück Code ein, obwohl ich nichts daran verändere, auch nach einem Löschen ist es nach ein paar Tagen wieder da und gibt natürlich eine Fehlermeldung, aber woher kommt dieses:

Code Auswählen Erweitern

attr LICHT lightSceneParamsToSave hsv

Das Attribut ist eigentlich von Lightscene, wird aber in MilightDevice gesetzt. Ist ein wenig unglücklich gemacht.
Nimm einfach meine Version von weiter oben, dann sollte der Fehler weg sein und das Attribut nicht weiter stören.

[Markus M.]

Neue Version, neues Glück!
Heute mit dabei: gamma zur Helligkeitskorrektur.
Funktioniert so wie bei WifiLight nur andersrum, da dort die Werte verdreht waren.
Hoher Wert = dunkler, kleiner Wert = heller.
Der dim Slider wird dabei auf 1er Schritte gesetzt, da die Steps bei einer Korrektur nicht mehr linear sind.

Die Version erfordert einen Neustart von FHEM.

[Markus M.]

Neue Version, neues Glück!

Heute mit dabei: gamma zur Helligkeitskorrektur.
Funktioniert so wie bei WifiLight nur andersrum, da dort die Werte verdreht waren.
Hoher Wert = dunkler, kleiner Wert = heller.
Der dim Slider wird dabei auf 1er Schritte gesetzt, da die Steps bei einer Korrektur nicht mehr linear sind.

Die Bridge hat ein checkInterval bekommen, falls jemand nicht alle 10 Sekunden einen Ping rausschicken will.

Die Version erfordert einen Neustart von FHEM.

[det.]

Hallo Markus,
irgendwas ist da noch, nach Neustart kommt:

Code Auswählen Erweitern

Prototype mismatch: sub main::round ($$) vs none at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 1875.
at ./FHEM/31_MilightDevice.pm line 34