Hallo liebe Leute,
ich bin mir nicht so ganz sicher, ob dieses Thema in dieses Board gehört; es betrifft im Prinzip alle Dimmer in Verbindung mit 230V LED- Leuchtmitteln ... Man möge es verschieben, wenn es wo anders besser passt ...
Da wir nach und nach alle Leuchtmittel auf die inzwischen brauchbaren LED- "Birnen" umstellen, was natürlich auch dimmbare LED an üblichen Dimmern betrifft (z.Z. verschiedene HomeMatic und noch ein Teil klassisch verdrahtete Dimmer), konnten wir zumindest bei den HM- Dimmern über den Offset dafür sorgen, das der Tot- Bereich am Anfang verschwindet.
In dem Zusammenhang ist mir aber aufgefallen, das bei angenommenen 10% Dimmer- Schritten die Abstufung recht unglücklich ist. Das physiologische Helligkeitsempfinden ist leider nicht linear...
Daher bin ich auf die Idee gekommen, mit einem ekligen DOIF- Verhau eine Art logarithmische Steuerung zu testen (naja, jede Menge Festwerte in Anlehnung an einen Logarithmus). Und was soll ich sagen? Fast Perfekt!
Allerdings ist das mit Hilfe von DOIF nicht wirklich praktikabel, da es extrem viel Code generiert...
Meine Frage resp. Idee ist nun, ob man so etwas nicht als Attribut in Dimmer- Definitionen einbauen könnte, um bei Betrieb mit LED- Leuchtmitteln, welche ja immer mehr die klassischen Leuchtmittel verdrängen, optional auf solch eine "berechnete" Kennlinie umschalten kann ???
Was meint ihr dazu? Habt ihr ähnliche Erfahrungen mit LED machen können und wenn ja, wie habt ihr das gelöst?
ich weiß nicht was das DOIF hierbei verloren hat. aber das sollte mit einem perl einzeiler in 99_myUtils der dann einfach im set verwendet wird zu machen sein.
set <name> pct {pct2log(50)}
der routine könnte man auch noch einen gamma wert übergeben falls man leuchtmittel einsetzt die sich sehr unterschiedlich verhalten. oder man steckt den gamma wert in ein attribut und übergibt noch den device namen.
gruss
andre
Zitat von: justme1968 am 19 August 2016, 12:08:01ich weiß nicht was das DOIF hierbei verloren hat. aber das sollte mit einem perl einzeiler in 99_myUtils der dann einfach im set verwendet wird zu machen sein.
Nun ja ... Du darfst dabei nicht von deinen Kenntnissen ausgehen, sondern von meinen. Und für einen Test, ob die Sache in der Art denn funktioniert resp. die dann generierten Helligkeitsveränderungen mehr der physiologischen Empfindung entspricht, war das m.E. vollkommen ok...
Zitat von: justme1968 am 19 August 2016, 12:08:01set <name> pct {(pct2log(50)}
... siehe oben bezgl. Kenntnisse ;)
Mir ging es mehr um eine Diskussion darüber, ob das in Anbetracht der auf dem Vormarsch befindlichen LED- Leuchtmittel nicht allgemein sinnvoll wäre, so etwas direkt in die Dimmermodule zu integrieren, was auch Einsteigern und PERL- DAU's wie mir entgegenkommen so wie grundsätzlich den Code- Aufwand resp. Fehlerquellen minimieren würde ...
Sorry, ich kann das noch nicht so wirklich konkretisieren ... Deshalb ja auch dieser Thread um mal abzuklopfen, ob so etwas machbar, sinnvoll, wünschenswert, ... ist.
Ich möchte das mal an einem einfachen Beispiel fest machen...
Wenn ich einen HM- Dimmer ansteuere, wobei hier als Sensor parallel IT- Handsender, HM-6fach- Taster, Code via Presence u.a. zum tragen kommt, setze ich den Dimmer i.d.R. mit einem solchen Konstrukt:
set HM2SD1_1 {([HM2SD1_1:pct]+10)} 0 2) Hier erfolgt also eine lineare, schrittweise Erhöhung in 10er Schritten (resp. natürlich auch umgekehrt). Wenn jetzt aber z.B. das in FHEM dazu gehörende DimmerModul z.B. ein Attribut log = 1 gesetzt hat, dann ist eben gesetzte 10% real nicht 10% (Linearität der Dimmerhardware mal unterstellend), sondern ein errechneter Wert...
im prinzip hast und verwendest du doch schon genau das. du rufst im
set perl code auf. genau kommt auch die Gamma korrektur hin die ich oben vorgeschlagen habe. wenn du es schaffst die log tabelle in ein doif einzubauen schaffst du es ganz sicher auch das in eine perl formel zu gießen.
aber zurück zur generellen lösung: da gehört eigentlich auch noch die rückrechnung bzw. ein zusätzliches reading für den physiologischen wert mit rein. sonst geht das drauf addieren nicht sauber. du addierst logische 10% auf den aktuellen physikalischen wert.
ich könnte mir vorstellen das man etwas in der art in die SetExtensions mit einbaut. dann hätten es automatisch fast alle module. leider verwendet ausgerechnet hm diese aber nicht.
Zitat von: justme1968 am 19 August 2016, 12:45:55... doif einzubauen schaffst du es ganz sicher auch das in eine perl formel zu gießen.
... naja, theoretisch ;) Mache ich vielleicht auch, wenn diese Diskussion ergibt, das es keinen Sinn macht, das direkt in die Dimmer- Module zu implementieren ...
Zitat von: justme1968 am 19 August 2016, 12:45:55... auch noch die rückrechnung bzw. ein zusätzliches reading für den physiologischen wert mit rein. sonst geht das drauf addieren nicht sauber.
Japp... Auch wenn man das in ein DimmerModul packt, müsste man das Hardware:pct im Modul umbenennen und ein neues Reading im Modul als pct deklarieren, welches seinen Realwert an Hardware:pct übergibt (linear) oder aber den berechneten Logarithmus bei gesetztem Attribut ...
Geht dann auch nicht anders, da ansonsten die bestehenden Implementierungen inkompatibel wären. Wenn man das so macht, würden die ohne Änderungen weiterhin funktionieren und erst nach Setzen des Attributes die neue Funktionalität preis geben ...
Zitat von: justme1968 am 19 August 2016, 12:45:55... die SetExtensions mit einbaut. .../... ausgerechnet hm diese aber nicht.
Ja, doof, oder? Rein aus Interesse: Warum verwendet gerade HM das eigentlich nicht?
OT1: Aus irgend welchen Gründen hat sich mal wieder mein HM-LC-DIM2L-SM total aufgehängt; steht dann im Status "TimedOn" und ist nicht mehr steuerbar, auch nicht nach ReadConfig o.ä. Aktionen. Da hilft dann nur stromlos machen... Ist schon öfter vorgekommen...
OT2: Ich werde die kommenden Tage mal den Reparaturstau in Sachen Röhrentechnik beseitigen, da ich sowieso auf bestellte Hardware warten muss...
Hallo M_I_B,
konntest Du Dein Problem lösen?
Der Thread ist zwar schon etwas eingestaubt, aber ich stehe momentan vor der gleichen Herausforderung. Ich habe mehrere Dimmer (HM-LC-Dim1TPBU-FM) verbaut und würde damit gerne LEDs dimmen.
Mit
attr <dimmer> levelRange 0,84
kann ich den jeweiligen Dimmer im idealen Bereich bewegen. Nur ist das beim Dimmen nicht gerade ideal, da der Helligkeitsverlauf der LEDs nicht linear ist. Subjektiv sind die LEDs bereits bei 30% sehr hell und sie werden nach oben hin nur sehr langsam heller. Daher passiert beim Dimmen (hell nach dunkel) erst mal nicht viel und gegen Ende geht es sehr/zu schnell. Daher wäre ein logarithmischer oder exponentieller An- und Abstieg wesentlich idealer.
@all: konnte jemand von Euch dies realisieren? Wenn ja, dann bin ich über Eure Hilfe dankbar.
Moin Bualicher,
nein, ich konnte das Problem aus FHEM heraus nicht lösen, was allerdings auch an meinem diesbezüglichen Unvermögen liegen kann.
Hallo zusammen,
gibt es denn andere Lösungsansätze/Workarounds um das Dimmverhalten mit den Homematic-Dimmern einigermaßen in den Griff zu bekommen? Ich denke nicht, dass M_I_B und ich alleine dieses Problem haben.
@M_I_B: vielen Dank für Deine Antwort.
Aber wieso denn? Die von André propagierte Lösung
set <name> pct {(pct2log(50)}
ist doch vollkommen universell. Und da zwei verschiedene LED-Typen höchstwahrscheinlich komplett unterschiedliches Verhalten zeigen, ist das auch nicht besser zu lösen.
LG
pah
Hallo,
da ich mich gerade mit diesem Problem befasse, hole ich dieses Thema noch einmal noch oben.
Zitat von: Prof. Dr. Peter Henning am 28 Februar 2019, 06:48:45
Aber wieso denn? Die von André propagierte Lösung
set <name> pct {(pct2log(50)}
ist doch vollkommen universell. Und da zwei verschiedene LED-Typen höchstwahrscheinlich komplett unterschiedliches Verhalten zeigen, ist das auch nicht besser zu lösen.
Kannst du mir bei dem Perl Script ein wenig unter die Arme greifen? Stellen die "50" die Anzahl der Hash Elemente dar, die dann nacheinander aufgerufen werden ?
Vielen Dank
Tom
Hallo,
ich bin hier leider noch nicht weiter gekommen und verstehe diese Routine nicht. Kann mir da vielleicht doch einmal jemand weiter helfen?
Vielen Dank!
Tom
Ich versuche es mal.
Du baust Dir in deiner "99_myUtils" eine Funktion welche den übergebenen Wert für pct anhand eines logarithmischen Verlaufes zurückgibt.
Dabei gilt: 0 gibt 0 zurück und 100 gibt 100 zurück. Der Rest liegt nicht auf einer Geraden, sondern auf dem logarithmischen Verlauf.
Diesen, von der Funktion zurückgebenen, Wert übergibts Du als pct an den Dimmer.
ZitatStellen die "50" die Anzahl der Hash Elemente dar, die dann nacheinander aufgerufen werden ?
Für mich nicht, sondern den von Dir gewünschten pct-Wert.
Vielen Dank. Das ist war der nötige Denkanstoß :-)
Erster Testlauf war erfolgreich.