WIFILED.pm heißt jetzt LW12.pm

Begonnen von betateilchen, 15 Dezember 2014, 13:56:58

Vorheriges Thema - Nächstes Thema

bigjob

#60
Genau so habe ich es auch gemacht!

--> attr LED webCmd rgb:on:off:dim:next:speed

Wenn ich die Leiste über On einschalte und dann direkt einfach so am Speed-slider schiebe, wars das!
FHEM auf Raspberry
Max, HM, FS20, LW12, HM IP, TUYA

Kuzl

Hm versuch mal davor über die kommandozeile speed auf einen wert zu setzen und aanschließend erst den slider hinzuzufügen

bigjob

Witzig,

das selbe hatte ich auch vor... und siehe da jetzt geht es.

In diesem falle sollte noch ein Automatischer default werd gesetzt werden. Aber das ist nichts für mich. Ansonsten ist die Anbindung echt toll!!!
FHEM auf Raspberry
Max, HM, FS20, LW12, HM IP, TUYA

Invers

Mein Stripe hängt an einer DECT200 (Schaltsteckdose), die tagsüber natürlich aus ist. Dann wird einmal pro Minute im Log eine Meldung erzeugt: "2015.01.26 16:53:34 3: Can't connect to socket!"
Schalte ich die Dose ein, kommt diese Meldung nicht mehr.
Kann man was tun, um diese Meldung zu unterbinden? Oder muss ich leider den Stripe direkt an das Stromnetz anschliessen?
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

betateilchen

Zitat von: Invers am 26 Januar 2015, 21:54:10
Kann man was tun, um diese Meldung zu unterbinden?

Den Loglevel entsprechend setzen.

Simpelste fhem Grundlagen...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Invers

Ich nahm an, der steht standardmässig beim Modul auf 0. Verbose habe ich jetzt trotzdem extra auf 0 gesetzt. Mal sehen, ob es geht.

Danke.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

betateilchen

Zitat von: Invers am 26 Januar 2015, 22:10:16
Ich nahm an, der steht standardmässig beim Modul auf 0.

In der von Dir zitierten Meldung:

Zitat2015.01.26 16:53:34 3: Can't connect to socket!

steht doch klipp und klar, dass die Meldung mit Loglevel 3 kommt. Wie kommst Du da auf 0?

Ausserdem ist Loglevel 0 nicht immer die glücklichste Lösung. Immerhin gibt es Loglevel von 0 bis 5 - das muss ja einen Sinn haben :)

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Invers

Ja, weil ich die 3 leider überlesen hatte. Sorry.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Raudi

Gibt es eigentlich ne Möglichkeit, um Übergänge fließend zu machen? Ich möchte z.B. auf Knopfdruck das Licht an schalten, aber nicht abrupt, sondern heller werdend über eine Sekunde oder so. Oder beim Wechsel von Farbe A zu Farbe B mit Übergang. Die einzige Möglichkeit, die ich gefunden habe, ist mit den benutzerdefinierten Animationen. Aber die laufen dann ja im Loop. Bei wifilight geht das ganze relativ einfach, aber die Übergänge sind alles Andere als flüssig. Gibt die Hardware des LW12 sowas her, oder müsste man da selbst Hand anlegen und andere Funktionen "missbrauchen"?

Kuzl

Die hardware kann das leider nicht ohne loop. Ich hab das beim einschalten so gelöst, dass ich eine benutzerdefinierte  animation mache und dann nach der zeit nach der die zielfarbe erreicht ist, diese fest setze.

Raudi

#70
Hatte ich mir schon fast gedacht, dass man das so machen muss. Gibt es da eine bestimmte Umrechnung von der eingestellten Geschwindigkeit in Sekunden oder so? Und wäre es nicht auch theoretisch möglich nach dem Starten des loops immer den aktuellen Wert abzufragen, bis der gewünschte erreicht ist und dann zu stoppen? Oder ist da die Verzögerung zu groß? Werde wenn ich zuhause bin mal damit rum experimentieren. Wäre natürlich genial, wenn so ne Funktion schon in das Modul eingebaut werden könnte.

Das könnte dann so aussehen:
-Aktuelle Farbe als Anfang der Animation setzen
-Gewünschte Farbe als Ziel der Animation
-Gewünschte Zeit in Geschwindigkeit umrechnen(falls möglich)
-Animation starten
-Wenn gewünschte Farbe erreicht ist, Animation stoppen

Dann müsste man einfach nur nen optionalen Parameter Zeit (oder falls das nicht geht halt die Geschwindigkeit) beim setzen einer Farbe angeben, anstatt jedes mal nen eigenes Skript dafür zu machen. Ich steuere z.B. das Licht über meine Pebble smartwatch und da mit Skripten zu hantieren wäre doch sehr umständlich.

Ich werde es mir aber später auf jeden Fall nochmal ansehen. Gestern habe ich bei einem kurzen Test allerdings auch bemerkt, dass die Farbverläufe vom Controller nicht immer so optimal sind. Mal sehen, woran das liegen kann und was man dagegen machen kann ;)

Raudi

Ok, Ich habe nen paar Tests gemacht und das dabei heraus bekommen:

1. Animationen Farbübergangsverhalten
Wenn man eine benutzerdefinierte Animation von einer Farbe zur Anderen laufen lässt, erhöht/erniedrigt der LW12 jeden RGB Kanal separat in der selben festgelegten Geschwindigkeit, bis der jeweilige Kanal seine gewünschte Helligkeit erreicht hat.
Das funktioniert auch prima solange die Differenz in jedem Kanal ähnlich ist, aber sobald es eine größere Diskrepanz zwischen den Differenzen der einzelnen Kanäle gibt, sieht es manchmal komisch aus.
Ein Beispiel:
Sagen wir ich möchte ein orange, das eine ähnlich Farbe wie eine Flamme hat. Wenn ich das in RGB umwandele, ergibt das bei mir ungefähr folgendes als Dezimalzahlen: R:255 G:60 B:0.
Hier ein kleines Beispiel, wie es beim LW12 aussieht, wenn man von kompletter Dunkelheit zu dieser Farbe einen Verlauf haben möchte:
R:0   G:0  B:0
R:1   G:1  B:0
R:2   G:2  B:0
...
R:30  G:30 B:0
...
R:59  G:59 B:0
R:60  G:60 B:0
R:61  G:60 B:0
...
R:255 G:60 B:0

Das bedeutet, dass am Anfang die Farbe gelb/grün ist, bis der grüne Kanal sein Maximum mit 60 erreicht  hat. Da der rote Kanal dann noch weiter heller wird, wird die Farbe dann langsam immer mehr zu der Gewünschten.
Wenn man dann runter dimmen möchte, greift der selbe Mechanismus. Aber da am Anfang beide Kanäle gleich schnell dunkler werden, ist die Farbe anfangs orange und wird dann immer mehr zu einem rot, bis der grüne Kanal 0 erreicht hat. Von da an wird das rot nur noch dunkler.

2. Animationsgeschwindigkeit:
Um den realen Wert der Animationsgeschwindigkeit herauszufinden, habe ich den Update Intervall vom Modul auf 0.5 Sekunden gesetzt(es geht auch niedriger, aber der Log arbeitet nur mit vollen Sekunden). Dann habe ich eine Animation von 000000 zu FFFFFF bei verschiedenen Geschwindigkeiten laufen lassen und die Zeit von 0 auf 100% anhand des Logs errechnet. Da die Reaktionszeit variieren kann und der Log nur mit vollen Sekunden arbeitet, können gewisse Ungenauigkeiten vorhanden sein, aber ich denke von meinem ergebnis kann man ganz gut sehen, wie es in etwa funktioniert:
Geschwindigkeit Zeit
0 28
10 26
20 25
30 25
40 23
50 22
60 21
70 20
80 18
90 17
100 17
110 16
120 15
130 14
140 13
150 12
160 11
170 10
180 8
190 7
200 6
210 5
220 4
230 3
240 2
250 ~1(nicht mehr wirklich messbar mit meiner Methode)

Als sehr grobe Faustregel würde ich mal folgendes davon ableiten:
Zeit(in s) = (260-Speed)/10
Geht sicherlich noch genauer, aber es fehlt mir einfach die Zeit und Lust das Ganze noch mehrmals zur Mittelwertsbildung durchlaufen zu lassen und nach einer Möglichkeit zu suchen den Log genauer zu machen. Vielleicht kann ja wer anderes meine Ergebnisse korrigieren.

Kuzl

Hallo Raudi,

Ich hab auch schon mal untersuchungen dazu gemacht und folgendes herausgefunden:
-Die geschwindigkeit ist abhängig von der animationsart.
-Die geschwindigkeit ist abhängig von der Anzahl der verwendeten Farben.
-Aus irgendeinwm Grund starten die benuzerdefinierten animationen immer bei 000000. Das macht farbübergänge von einer farbe zur andern eigentlich unmöglich

Newima1201

Hallo zusammen,

die hier stehenden Beiträge gehen irgendwie von einem funktionierendem System aus.
Ich habe FHEM so Anfang Dezember installiert die von Euch für das LW12 als define angegebenen Codes münden bei mir immer nur in der Fehlermeldung.
"Unknown module WifiLight Unknown module WifiLight" (ich habe 2 davon)
Nun habe ich durch Recherche herausgefunden, das Ihr das Modul in die Distribution gegeben habt und nun per "Update" mit geladen werden sollte. Leider Fehlanzeige. Das Modul ist nicht im Pfad /opt/fhem/FHEM zu finden.
Dann habe ich das Modul manuell als 98_LM12.pm dorthin kopiert. Funktion immer noch Fehlanzeige.
Was mache ich hier falsch? Oder besser, wie bekommt man das zum Laufen?

Raudi

Zitat von: Newima1201 am 01 Februar 2015, 14:04:51
Hallo zusammen,

die hier stehenden Beiträge gehen irgendwie von einem funktionierendem System aus.
Ich habe FHEM so Anfang Dezember installiert die von Euch für das LW12 als define angegebenen Codes münden bei mir immer nur in der Fehlermeldung.
"Unknown module WifiLight Unknown module WifiLight" (ich habe 2 davon)
Nun habe ich durch Recherche herausgefunden, das Ihr das Modul in die Distribution gegeben habt und nun per "Update" mit geladen werden sollte. Leider Fehlanzeige. Das Modul ist nicht im Pfad /opt/fhem/FHEM zu finden.
Dann habe ich das Modul manuell als 98_LM12.pm dorthin kopiert. Funktion immer noch Fehlanzeige.
Was mache ich hier falsch? Oder besser, wie bekommt man das zum Laufen?
wifilight ist nen anderes Modul, dass nichts mit diesem zu tun hat, außer, dass beide den LW12 steuern können. Bist du sicher, dass du den korrekten define Befehl nimmst?
Zitat von: Kuzl am 01 Februar 2015, 11:56:38
-Die geschwindigkeit ist abhängig von der animationsart.
-Die geschwindigkeit ist abhängig von der Anzahl der verwendeten Farben.
Wie meinst du das mit der Animationsart und den Farben?
Wenn man nicht mindestens eine Farbe von 0 auf 255 bringt, dann verringert sich natürlich die Animationszeit. Die Geschwindigkeit scheint aber gleich zu bleiben, sodass ein dimmen auf 50% dann einfach die Hälfte der Zeit benötigt. Müsste ich mir aber nochmal ansehen.