Hallo,
ich versuche meine Leuchten im Haus möglichst auf LEDs umzustellen. Daher habe ich inzwischen auch einige LED Leuchtmittel im Einsatz in klassischer Glühbirnen-Bauform, z.B. Osram LED Supetstar Classic B40adv, 6W 470 lm. Die machen ordentliches Licht mit akzeptabler Lichtfarbe und sind dimmbar. Daneben habe ich auch noch eine dimmbare Philips-Trelome LED-Wandleuchte im Einsatz. Zum Dimmen verwende ich den oben genannten UP Homematic Dimmer, der grundsätzlich auch ordentlich mit den LED Leuchtmitteln funktioniert.
Ein Problem das ich habe ist, das der Helligkeitsbereich von dunkel bis ganz Hell der LED auf dem Dimmer nur einem Dimmbereich von 0-20% entspricht. Schaltet man also eine Lampe an und dimmt dann herunter passiert scheinbar erst einmal gar nichts. Dafür geht dann am Ende innerhalb von 1.5 sec die Lampe von voller Helligkeit auf 0 herunter. Dadurch kann man z.B. nur sehr schwer eine geringe Helligkeit einstellen.
Ich hatte dieses Problem schon mal im Anfängerforum gepostet und dort den Tip erhalten, es doch in diesem Forum noch einmal zu veröffentlichen, um herauszukriegen ob es möglich ist den Homematic Dimmer so zu konfigurieren, das die Abbildung von Dimmbereich des Dimmers auf die Lichtleistung der Lampe in dem Sinn verbessert werden kann, das man nicht in 1.5sec von voller Helligkeit auf 0 kommt, man also fein-granularer dimmen kann.
Gibts hier evtl. eine Möglichkeit?
Viele Grüße
Rainer
Ich habe das Problem noch nicht - noch keine LED im diesem Dimmer.
Machbar ist da schon etwas.
a) dimmen per Button/peer/remote
- erst einmal die eingebauten Buttons sichtbar machen
- getConfig - warten bis abgeholt.
- maximalstufe des Dimmer auf 20% setzen
- dimmsteps klein setzen (hier 1%)
- Alles für jeden Peer durchführen
set <dev> regSet intKeyVisib visib
set <dev> getConfig
#warten...
set <chan01> regSet prep lgDimMaxLvl 20 self01
set <chan01> regSet prep lgDimStep 1 self01
set <chan01> regSet prep lgOnLevel 20 self01
set <chan01> regSet exec lgRampSstep 1 self01
set <chan01> regSet prep lgDimMaxLvl 20 self02
set <chan01> regSet prep lgDimStep 1 self02
set <chan01> regSet prep lgOnLevel 20 self02
set <chan01> regSet exec lgRampSstep 1 self02
b) schalten aus der Zentrale: Hier kannst du deine ramptime entsprechend setzen
Bin gespannt ob das klappt. Ich hätte noch eine Idee macht es vielleicht Sinn, eine eigene Kompatibilitätsliste mit diesem Dimmer ins Wiki zu setzten: http://www.fhemwiki.de/wiki/HM-LC-Dim1TPBU-FM_1-Kanal-Dimmer_UP ? Ich überlege den Dimmer mit 4 IKEA LEDs einzusetzen (10Watt 600lm) und überlege wie ich das vorher testen kann. Weil meine Alternative wäre ohne Dimmer mit dunkleren LEDs.
nun, klappen muss es eigentlich. Es ist nur etwas 'umständlich'.... aber man könnte ein template bauen (HMInfo). Dafür ist template ja gedacht.
Der Dimmer sollte mit allen dimmbaren LEDs zurecht kommen (liege ich falsch?). Was sollte man hier eintragen? Alle dimmbaren LEDs?
LEDs sind schon sehr störrisch. Es gibt welche die Dimmen gar nicht, andere fangen an zu brummen, manche flackern (sieht man z.B. mit einer Videokamera sehr gut). Wiederrum andere wie hier, haben einen winzigen Bereich in dem was passiert. Dafür haben bessere Dimmer z.B. auch Justierschrauben. Hier gibt es einige Infos dazu:
http://fastvoice.net/2014/03/07/led-lampe-und-dimmer-immer-noch-kein-traumpaar/
nun, alle HM dimmer haben SW-justierschrauben...
welche LED mit an- oder abschnitt zurecht kommt ist eine andere Frage...
Sollte man aber nicht nach anschnitt/abschnitt/PWM unterschieden? modell ist etwas zu fein aufgedrösslt
Wenn es denn so einfach wäre. Leider kann man nicht sagen wenn die 7Watt LED von XY geht, geht auch die 10 Watt LED. Das ist wirklich von Modell zu Modell unterschiedlich.
Zitat von: martinp876 am 19 März 2014, 09:42:14
Ich habe das Problem noch nicht - noch keine LED im diesem Dimmer.
....
set <dev> regSet intKeyVisib visib
set <dev> getConfig
#warten...
set <chan01> regSet prep lgDimMaxLvl 20 self01
set <chan01> regSet prep lgDimStep 1 self01
set <chan01> regSet prep lgOnLevel 20 self01
set <chan01> regSet exec lgRampSstep 1 self01
set <chan01> regSet prep lgDimMaxLvl 20 self02
set <chan01> regSet prep lgDimStep 1 self02
set <chan01> regSet prep lgOnLevel 20 self02
set <chan01> regSet exec lgRampSstep 1 self02
b) schalten aus der Zentrale: Hier kannst du deine ramptime entsprechend setzen
Hallo,
ich hab versucht das mal umzusetzen und hab mich dabei leider bei der Angabe de chan01 vertan :-(.
Letzlich war es soweit das der Dimmer nicht mehr auf Status-Requests und getConfig-Aufrufe geantwortet hat sondern ein response Timeout kam.
Also habe ich den Dimmer letztlich komplett am Config-Button am Dimmer mit 4sec, -, 4sec drücken resettet, fhem gestoppt, die Config des Dimmers aus fhem.cfg herausgenommen, fhem.save gelöscht und fhem neu gestartet .
Jetzt wollte ich neu anlernen, aber an neuer Konfig erscheint in fhem.cfg anschließend nur noch folgendes:
define CUL_HM_HM_LC_Dim1TPBU_FM_1AA526 CUL_HM 1AA526
attr CUL_HM_HM_LC_Dim1TPBU_FM_1AA526 room CUL_HM
define FileLog_CUL_HM_HM_LC_Dim1TPBU_FM_1AA526 FileLog ./log/CUL_HM_HM_LC_Dim1TPBU_FM_1AA526-%Y.log CUL_HM_HM_LC_Dim1TPBU_FM_1AA526
attr FileLog_CUL_HM_HM_LC_Dim1TPBU_FM_1AA526 logtype text
attr FileLog_CUL_HM_HM_LC_Dim1TPBU_FM_1AA526 room CUL_HM
mehr nicht, vorher war das ungefähr das 5fache an Zeilen. Reagieren tut der Dimmer auch nicht auf fhem-Kommandos (z.B. StatusRequest) mit einem anderen Homematic Wandsender kann ich den Dimmer aber wieder pairen und betreiben.
Andere "alte" Geräte in FHEM klappen auch weiter prima.
Irgendeine Idee was bei meiner Reset-Prozedur noch fehlt?
Danke
Rainer
Hallo,
noch ein paar Infos, die vielleicht etwas besser helfen die "Lage" zu verstehen:
Ein get <dev> regList liefert das:
list: register | range | peer | description
0: intKeyVisib | literal | | visibility of internal channel options:visib,invisib
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
Bei einem set <device> getConfig sieht man 4 CMDs pending, dann nach einer Weile den Timeout. Im Logfile steht dann:
2014.03.19 20:19:57.256 4: CUL_send: COCAs 0A 02 8002 F11234 1AA53C 00
2014.03.19 20:19:59.807 4: CUL_Parse: COC A 0F 05 8410 1AA526 000000 06011E00801E0D -67.5
2014.03.19 20:22:09.693 2: CUL_HM set CUL_HM_HM_LC_Dim1TPBU_FM_1AA526 getConfig
2014.03.19 20:22:09.699 4: CUL_send: COCAs 10 02 A001 F11234 1AA526 00040000000000
2014.03.19 20:22:15.104 4: CUL_send: COCAs 10 02 A001 F11234 1AA526 00040000000000
2014.03.19 20:22:19.796 4: CUL_send: COCAs 10 02 A001 F11234 1AA526 00040000000000
2014.03.19 20:22:25.799 4: CUL_send: COCAs 10 02 A001 F11234 1AA526 00040000000000
Versuche ich anschließend ein get <dev> reg all kommt letztlich nichts dabei raus:
CUL_HM_HM_LC_Dim1TPBU_FM_1AA526 type:dimmer -
list:peer register :value
Danke
Rainer
get reglist zeigt die,welche register vorhanden sein sollten und welche Optionen/wertebereiche möglich sind. Es zeigt überhaupt nicht, was im Device los ist. Eigentlich ist es in help zu registern.
Das log zeigt, dass das Device nicht antwortet.
Die gelesenen Register sind leer - was dann ja auch sinn macht.
=> das Device antwortet nicht.
Hast du schon einmal den Strom ausgeschaltet? Sicherung raus!
Dann sollte sich das Device einmal melden. Du kannst dann auch noch einmal pairen - ist nach Reset notwendig. Irgend etwas sollte dann zu mindest noch kommen.
In FHEM brauchst du es eigentlich nicht löschen
Gruss Martin
Hallo,
nach einer Nacht mit Stromentzug für den Dimmer war dieser heute morgen wieder kooperativ ;). Evtl mußten sich auch noch irgendwelche caches in FHEM erst noch leeren. Ich weiß es nicht.
Im zweiten Anlauf hab ich jetzt auch die richtigen Channels genommen. Das Ergebnis ist fast so wie es sein solle, prima, eine Sache stimmt aber noch nicht.
Das Problem ist der level beim Einschalten der Lampe. Versuche ich anschließend nach unten zu dimmen, dauert es wohl ne halbe Minute bis ich eine erste Helligkeitsänderung sehe. Schalte ich die Lampe aus und dimme sie dann nach oben und halte die Taste gedrückt auch wenn das Maximum schon erreicht ist, kann ich anschließend sofort durch herab-dimmen eine kleine Verdunklung der Lampe beobachten. Das Dimmen selbst erfolgt langsamer als zuvor wegen der 1% Schritte, was ja auch so gewollt ist.
Es scheint also als ob ich beim heller Dimmen maximal die eingestellten 20% erreiche, beim Einschalten jedoch wohl 100%. Das zumindest würde das Verhalten erklären.
Die Kommandos habe ich über das Telnet-Interface von FHEM eingegeben. Dabei habe ich die Kommandos zunächst in einem Text-Editor mit korrektem Channel-Namen versehen und dann mit copy/paste als ein Block mehrerer Zeilen (das getconfig ausgemommen) in das telnet-Fenster gepastet. Einmal hab ich im Log eine Fehlermeldung gesehen das ein zu setzender Wert nicht numerisch sei, was ich dann so interpretiert habe das die als Block eingefügten set Kommandos nicht voneinander getrennt erkannt wurden sondern als Argumente für das erste set.
Daher hab ich mich gefragt ob ich die Kommandos zeilenweise eines nach dem anderen ins telnet interface pasten muß, weil ein blockweises pasten mehrerer Zeilen (mit Zeilentrennern) nicht erlaubt ist und zu Fehlinterpretationen der Kommandos führen kann?
Eine Andere Frage die ich mir gestellt habe ist, wie lange die gesetzten Register-Werte erhalten bleiben. Stehen die im Aktor in permanentem Flash-Speicher oder würde ein Stromausfall sie löschen?
Viele Grüße
Rainer
Hallo Rainer,
ZitatEs scheint also als ob ich beim heller Dimmen maximal die eingestellten 20% erreiche, beim Einschalten jedoch wohl 100%.
einschalten ist ein kurzer tastendruck lokal? Da musst du also in den 'sh' (short) der internen Tasten (self01, self02) nachsehen.
ggf. intKeysVisib auf visib setzen, dann sind die 'selfs' zu sehen.
ZitatDaher hab ich mich gefragt ob ich die Kommandos zeilenweise eines nach dem anderen ins telnet interface pasten muß, weil ein blockweises pasten mehrerer Zeilen (mit Zeilentrennern) nicht erlaubt ist und zu Fehlinterpretationen der Kommandos führen kann?
ich paste blockweise - das gibt keine probleme - zumindest mit meiner telnet-applikation
ZitatEine Andere Frage die ich mir gestellt habe ist, wie lange die gesetzten Register-Werte erhalten bleiben. Stehen die im Aktor in permanentem Flash-Speicher oder würde ein Stromausfall sie löschen?
Die stehen im Flash (alles andere wäre auch eine Katastrophe). FHEM hat somit immer das 'problem' am Ball zu bleiben - will sagen FHEM liest die Register gelegentlich (nichtregelmässig...) und stellt das gelesene dar. Eine gewisse vosicht ist also geboten.
Gruss Martin
Hallo Martin,
vielen Dank fuer die Hilfe. Ich habs jetzt am Laufen wie es sein soll. Den Sinn des Register Präfix sh und lg hab ich nun auch kapiert :-)
Kleinere Problemchen waren immer wieder mal Schwierigkeiten, das nach dem Setzen von Registerwerten das getConfig eine Antwort schuldig blieb. Bei mir hat es dann geholfen FHEM neu zu starten und die Daten erneut zu setzen und dann wieder ein getconfig zu machen. Dann klappte es in aller Regel.
Das Regelverhalten ist durch die Parameter die Du genannt hattest jetzt viel besser als zuvor und perfekt anpassbar an das Verhalten der entsprechenden LED, ich hab auch noch den unteren Minimalwert lgOnMinLevel etwas herunter gesetzt so das man noch weniger Licht machen kann, wenn man es will.
Viele Grüße
Rainer
ZitatBei mir hat es dann geholfen FHEM neu zu starten und die Daten erneut zu setzen und dann wieder ein getconfig zu machen. Dann klappte es in aller Regel.
das enttäuscht mich. Ein reboot sollte nicht notwendig sein.
Wenn es noch einmal hängt kannst du die Lage einmal geschreiben:
list des Device
aufnahme von rohmessages
Hallo Martin,
genau genommen war ja kein reboot des System nötig auf dem FHEM arbeitet (Raspberry Pi) sondern nur ein Neustart von FHEM selbst. Aber wenn ich das Problem nochmal habe mache ich mal das list <device> und schicke mal die Messages mit, die zu dieser Zeit ausgetauscht wurden.
Grüße
Rainer
Hallo Martin,
hatte gerad enochmal den Fall. Vor ca. 2h hatte ich erfolgreich einige Register neu gesetzt, um die Dimmparameter feiner anzupassen und dann ein getConfig gemacht. Jetzt hatte ich festgestellt das ich die Variable lgOnMinLevel noch korrigieren wollte für alle Peers.
Ich hab dann ohne ein erneutes getConfig direkt via telnet die Kommandos eingegeben:
set Dimmer_WZ2 regSet exec lgOnMinLevel 4 self01
set Dimmer_WZ2 regSet exec lgOnMinLevel 4 self02
set Dimmer_WZ2 regSet exec lgOnMinLevel 4 CUL_HM_HM_PB_2_WM55_205682
set Dimmer_WZ2 regSet exec lgOnMinLevel 4 CUL_HM_HM_PB_2_WM55_205682_chn:02
Anschließend hab ich ein getConfig gemacht, um sie zum Dimmer übertragen zu lassen. Dann trat der resonse timeout auf. Nach einem Neustart von FHEM und erneuten getConfig; Parameter setzen und getConfig klappte es dann wieder.
Evtl liegts ja daran das ich vor dem Setzen kein extra getConfig gemacht habe?
Hier das Device list und die Messages:
Ich halte folgendes für Möglich
- das Device hat seine max sendekapazität für eine Zeitperiode überschritten und braucht eine Pause.
Ich denke nicht, dass ein FHM neustart die Situation verbessert hat. Enfaches Warten und noch einmal probieren hätte evtl geholfen. Du hast ziemlich viel auf einmal gesendet...
Wo genau hier die Grenze liegt kann ich nicht sagen.
Warte das nächste mal etwas. dann ein getCnfig nachsenden. Wenn du willst ein set <dev> clear msgEvents - damit die hässlichen Fehler verschwinden und du neu zählen kannst
Zitat von: martinp876 am 21 März 2014, 20:32:54
Ich halte folgendes für Möglich
- das Device hat seine max sendekapazität für eine Zeitperiode überschritten und braucht eine Pause.
Was dazu nicht so richtig dazu passt ist die Tatsache, das ich zuletzt nur genau 4 Register neu gesetzt habe. Vor zwei Stunden habe ich wesentlich mehr fehlerfrei gesetzt (in protCmdPend im Webinterface stand dort "40 Cmds pending", die dann abgearbeitet wurden.
Beim nächsten Mal warte ich einfach mal ne Minute und schaue dann ob ein erneutes getConfig zum Ziel führt. Das restart von FHEM hat bisher immer zum Erfolg geführt, aber auch damit ist ja eine kurze Wartezeit verbunden. Ich schau mal....
Grüße
Rainer
habe gerade einen Fall gesehen,da hat FHEM 10 sec pause gemacht - mehrfach... keine Ahnung warum. Sollte so etwas auch bei dir vorkommen erklärt es das Verhalten. Dazu müsstest du rohmessages aufzeichnen, damit wir es analysieren können
Hallo Martin,
das ist jetzt fast die Antwort auf das, was ich neulich auch gesucht/gefragt hatte.
Einziges Manko: In FHEMWEB habe ich natürlich auch nur noch den Wertebereich 0-20 parat. Wäre es denkbar, dass man dort die nur noch übrigen realen 20% wieder auf virtuelle 100% hochrechnet? Dann hätte man im Web wieder den gewohnten Wertebereich 0-100% verfügbar. Den Slider zwischen 0 und 20 zu verschieben ist dann doch etwas fizzelig :-/
macht sinn - muss ich einmal über eine Realisierung nachdenken.
An den Readings kann man es nicht festmachen, da hier ein Max wert je peer eingegeben werden kann... Das sind zu viele max-werte...
Noch ein Problem: Man kann immer nur 0.5% schritte eingeben... die Üblichen 200 Schritten gehen dann nicht mehr, es würden umgerechnet Schritte von 2,5% sein, 40 Schritte eben.
Vielleicht ist es besse/hinreichend den Slider von 0 bis 20 laufen zu lassen?
Das automatisch 'on' wird es auch nicht mehr geben.... das kommte bei 100...
Gruss Martin
Zitat von: martinp876 am 22 März 2014, 20:21:55
Vielleicht ist es besse/hinreichend den Slider von 0 bis 20 laufen zu lassen?
Für den Slider natürlich schon, aber schicker wäre es ja, wenn das vollkommen transparent wäre und 100% einfach das Maximum darstellen würde. Wenn ich jetzt einen Dimmer mit Poti hätte, dann wüsste FHEM ja auch nix davon ;)
Kann man diese Register nicht als wirklich intern behandeln und sie nicht 1zu1 (ja, ich weiß, 2zu1 :) ) übernehmen? Quasi als virtuelles Poti ;D
das ist nicht so einfach. Ein dimmer hat jede Menge mit 'maxlevel'.
1) du stellst nirgendwo einen max-level für den Aktor ein
2) du stellst einen max level für den Aktor 'von einem Peer' ein - das sind realistisch schon allein 10 Werte
3) Jeder Peer hat einen maxDimLevel, maxOnLevel - und das ganze auch nochl als min-wert.
4) das Kommando aus der Zentrale wird damit erst einmal nicht beschränkt.
5) die Schrittweite ist immer "0.5%-punkte". nicht 0,5% Das muss im Slider berücksichtigt werden
Machbar ist
a) slider settings zu adaptieren
b) Level für Commands zu beschränken
a) habe ich gerade probiert...nicht schlecht, aber ich denken zu komplex...
b) ist besser machbar
- User legt ein Attribut 'levelRange 10,30' fest, somit einen min und einen max level
- das bezieht sich NUR auf das Kommando. NICHT auf Register
- Der Level und state wird auf den neuen Range umgerechnet - dann können auch level über 100% erreicht werden
a) Ist das Konzept klar?
b) ist das Ergebniss hinreichend/gewünscht?
Gruss Martin
Zitat von: martinp876 am 23 März 2014, 11:17:53
a) Ist das Konzept klar?
b) ist das Ergebniss hinreichend/gewünscht?
B klingt für mich genau richtig :)
Hallo Loredo,
für Dimmer kann man jetzt
attr <dimmer> levelRange 10,40
setzen.
bitte
- testen
- commandref lesen, beachten und kommentieren
Gruss Martin
Hallo Martin,
tolle arbeit.
Leider erhalte ich eine Fehlermeldung :
Wand_Lampe: unknown attribute levelRange. Type 'attr Wand_Lampe ?' for a detailed list
define Wand_Lampe CUL_HM 1F0659
attr Wand_Lampe .devInfo 110100
attr Wand_Lampe .stc 20
attr Wand_Lampe IODev HMLAN1
attr Wand_Lampe autoReadReg 4_reqStatus
attr Wand_Lampe expert 2_full
attr Wand_Lampe firmware 2.1
attr Wand_Lampe model HM-LC-DIM1T-FM
attr Wand_Lampe peerIDs 00000000,
attr Wand_Lampe room Praxis
attr Wand_Lampe serialNr JEQ0659219
attr Wand_Lampe subType dimmer
attr Wand_Lampe levelRange 20,80
attr Wand_Lampe webCmd statusRequest:toggle:on:off:up:down
Grus Stefan
Hallo Martin,
jetzt ist es fast perfekt!
Ich habe bei mir levelRange=4,20 gesetzt, weil darunter die LEDs flackern. Wenn ich jetzt allerdings pct=0 setze oder auch ein off schicke, bleiben die LEDs trotzdem an. Das hatte ich aus der CommandRef anders verstanden (zumindest bei off, aber 0 sollte da irgendwie als off interpretiert werden).
Durch die Umrechnung der Werte kommt beim Setzen von pct=[3|2|1] trotzdem 0 raus (obwohl richtig gedimmt wird).
Dass nach dem Setzen eines Wertes hinterher ein anderer dort steht ist ja grundsätzlich in Ordnung (und entspricht auch dem sauberen Umrechnen), nur bei 1-3 sollte trotzdem immer noch 1 rauskommen und bei 0 sollte eben off interpretiert werden.
Gruß
Julian
ZitatWenn ich jetzt allerdings pct=0 setze... bleiben die LEDs trotzdem an.
ja
Zitatoder auch ein off schicke, bleiben die LEDs trotzdem an.
nein.
Off macht aber immer in 0 - da kommt keine Umrechnung zum Tragen. Funktioniert bei mir... sollte auch bei dir.
Der Slider ist Linear. Wenn du 0 einstellst kommt min-level raus.
ZitatDurch die Umrechnung der Werte kommt beim Setzen von pct=[3|2|1] trotzdem 0 raus (obwohl richtig gedimmt wird).
bei levelRang 4,20 kommt, wenn du pct=3 setzt wird der physikalische Level 0,48% errechnet - plus Min level = 4,48%. Das gibt auf der HM Skala von 0 bis 200 einen level von 8,96 - Perl rundet ab, also 8 (8* 0,5%).
1 pct auf der HM Scala sind somit 0,16%. HM Devices unterscheiden ab 0.5%
=> 4pct sind 4,5% physikalisch
0...3 => 4%
4...6 => 4,5%
7..9 => 5%
Mehr geht nicht.
Das mit dem Off ist mir aber zu heiss. Gefällt mir garnicht.
Ich werden also einbauen, das 0pct = off ist, also 0 physikalisch. Das macht mehr sinn.
Kannst du noch einmal testen? V 5308
Zitatnur bei 1-3 sollte trotzdem immer noch 1 rauskommen und bei 0 sollte eben off interpretiert werden.
siehe Rechnung oben. Alles was nach
pct*(20-4)/100 < 0,5
ist wird zu physikalisch 4 und logisch 0.
Gruss Martin
Ich habe mit Rev5309 getestet.
Vom Verhalten her ist es jetzt denke ich so, wie es sein sollte (oder sein kann, granularer/gleichmäßiger lässt halt die Hardware nicht zu denke ich).
Einzig optisches Manko was noch bleibt: Der Slider springt hin und wieder in den Minus-Bereich (besonders bei den niedrigeren Werten natürlich). Ich muss trotz Longpoll die Seite neu laden, damit der Slider den korrekten Wert anzeigt.
Ansonsten: Echt toll, freut mich sehr, dass das jetzt so funktioniert :) :) :)
EDIT:
Korrektur. Wenn ich pct=0 per Slider setze, bleibt der Slider jetzt dauerhaft auf -17. (bei levelRange=3,20)
EDIT 2:
Ich fände es nach wie vor prima, wenn bei allen Werten, wo die LEDs zwar an sind, rechnerisch aber 0 als pct-Wert heraus kommt, den pct-Wert 1 zurück zu melden. Ansonsten kann ich jetzt gerade die Leuchten nicht per devStateIcon aus schalten, weil ja angenommen wird, dass sie bereits an sind. Sie werden deshalb natürlich auf 100% geschaltet statt aus... :-\
Zitatoder sein kann, granularer/gleichmäßiger lässt halt die Hardware nicht zu denke ich)
korrekt. HM kann 0,5% stufen ... dein Bereich ist ungerechnet...
ZitatEinzig optisches Manko was noch bleibt: Der Slider springt hin und wieder in den Minus-Bereich (besonders bei den niedrigeren Werten natürlich). Ich muss trotz Longpoll die Seite neu laden, damit der Slider den korrekten Wert anzeigt.
hm - da kann ich wenig tun - denke ich zumindest
ZitatKorrektur. Wenn ich pct=0 per Slider setze, bleibt der Slider jetzt dauerhaft auf -17. (bei levelRange=3,20)
ja... das wird ein Problem bleiben, denke ich.
Der Slider gehört mir nicht, das ist web-interface. Er stellt einen linearen Wertebereich dar - ist normal auch super.
probier noch einmal mit 5316
Hallo,
vielen Dank für die Infos hier, hat schon prima geklappt bei mir.
Habe noch eine Frage:
durch kurzes tippen auf den Schalter / Fernbediennung geht der Dimmer auf 100 und nicht auf 30, dadurch dauert es beim herunterdimmern sehr lange bist min von 100 in den relevanten bereicht con 30-0% kommt gerade bei 2% Schritten.
habe ich da noch was vergessen ?
set Decke_WZ regSet prep shOnLevel 30 self01;set Decke_WZ regSet prep shDimMaxLvl 30 self01;set Decke_WZ regSet prep shCtValHi 30 self01;set Decke_WZ regSet exec lgCtValHi 30 self01
set Decke_WZ regSet prep lgDimMaxLvl 30 self01; set Decke_WZ regSet prep lgDimStep 2 self01;set Decke_WZ regSet prep lgOnLevel 30 self01; set Decke_WZ regSet exec lgRampSstep 2 self01
set Decke_WZ regSet prep shOnLevel 30 self02;set Decke_WZ regSet prep shDimMaxLvl 30 self02;set Decke_WZ regSet prep shCtValHi 30 self02;set Decke_WZ regSet exec lgCtValHi 30 self02
set Decke_WZ regSet prep lgDimMaxLvl 30 self02; set Decke_WZ regSet prep lgDimStep 2 self02;set Decke_WZ regSet prep lgOnLevel 30 self02; set Decke_WZ regSet exec lgRampSstep 2 self02
Ich stand vor genau dem gleichen Problem und habe nach einigen Stunden des Herumprobierens mit den div. Registern es hinbekommen, beim Einschalten die Lichtstärke zu begrenzen.
In unserem Wohnzimmer hängt eine Lampe mit 6 Fassungen, die bisher mit 5W Osram Nano Twist Energiesparlampen bestückt war. Über zwei (untereinander liegenden) Lichtschaltern wurden konnten 4 und 2 Fassungen geschaltet werden. Der Innendurchmesser der Glaskörper hat die Auswahl von dimmbaren LEDs stark eingeschränkt. Ich habe bei ELV passend dazu die Sigor Ecolux 5,5-W-LED-Kerzenlampe E14 (warmweiß, dimmbar) gefunden. Bei 100% hat man den Eindruck, in einen Flutlichtstrahler zu schauen, also kam nur ein gedimmtes Einschalten in Frage. Die 3,5W Version wäre zwar vom Lumenwert mit den Osrams nahezu identisch gewesen, jedoch war hier die Lichtstärke schon sehr knapp. Beim Einbau des Dimmers habe ich den zweiten Schalter stillgelegt und alle 6 Fassungen wieder zusammengefasst.
60% als Einschaltwert ist für uns ideal. Die LEDs lassen sich bis 10% runterdimmen, beim gedimmten Einschalten (=langer Druck nach unten) schalten bei 10% aber nur 3 von 6 LEDs ein. Bei 5% zeigen 2 LEDs ein sichtbares Flackern. Ich habe deshalb den unteren Wert fürs Dimmen auf 20% gelegt.
Was mir noch fehlt ist, wie ich das Dimmen etwas verlangsamen kann. Der Wertebereich wird mir noch etwas zu schnell durchlaufen um mehr oder weniger direkt auf die gewünschte Lichtstärke zu kommen ohne Nachkorrigieren zu müssen. Falls hier jemand noch einen hilfreichen Tipp hat, wäre ich sehr dankbar.
Hier die Ausgabe von get eg_wz_Licht_Sw regTable:
No regs found for:
eg_wz_Licht_Sw type:dimmer -
list:peer register :value
1: fuseDelay :1 s
1: logicCombination :or
1: ovrTempLvl :80 C
1: powerUpAction :off
1: redLvl :40 %
1: redTempLvl :75 C
1: statusInfoMinDly :2 s
1: statusInfoRandom :1 s
1: transmitTryMax :6
self01 self02
lg sh lg sh
ActionTypeDim downDim jmpToTarget upDim jmpToTarget
CtDlyOff geLo geLo geLo geLo
CtDlyOn geLo geLo geLo geLo
CtOff geLo geLo geLo geLo
CtOn geLo geLo geLo geLo
CtRampOff geLo geLo geLo geLo
CtRampOn geLo geLo geLo geLo
CtValHi 100 100 100 100
CtValLo 50 50 50 50
DimElsActionType off off off off
DimElsJtDlyOff rampOff rampOff rampOff rampOff
DimElsJtDlyOn rampOn rampOn rampOn rampOn
DimElsJtOff dlyOn dlyOn dlyOn dlyOn
DimElsJtOn dlyOff dlyOff dlyOff dlyOff
DimElsJtRampOff off off off off
DimElsJtRampOn on on on on
DimElsOffTimeMd absolut absolut absolut absolut
DimElsOnTimeMd absolut absolut absolut absolut
DimJtDlyOff rampOff rampOff rampOn rampOn
DimJtDlyOn dlyOff dlyOff rampOn rampOn
DimJtOff dlyOff dlyOff dlyOn dlyOn
DimJtOn dlyOff dlyOff rampOn rampOn
DimJtRampOff off off rampOn rampOn
DimJtRampOn dlyOff dlyOff on on
DimMaxLvl [%] 100 60 100 60
DimMinLvl [%] 20 0 20 0
DimStep [%] 10 5 10 5
MultiExec on off on off
OffDly [s] 0 0 0 0
OffDlyBlink on on on on
OffDlyNewTime [s] 0.8 0.4 0.8 0.4
OffDlyOldTime [s] 0.8 0.4 0.8 0.4
OffDlyStep [%] 5 5 5 5
OffLevel [%] 10 0 10 0
OffTime unused unused unused unused
OffTimeMode absolut absolut absolut absolut
OnDly [s] 0 0 0 0
OnDlyMode setToOff setToOff setToOff setToOff
OnLevel [%] 100 60 100 60
OnLvlPrio high high high high
OnMinLevel [%] 30 60 30 60
OnTime [s] 1 unused unused unused
OnTimeMode minimal absolut absolut absolut
RampOffTime [s] 0.5 0.5 0.5 0.5
RampOnTime [s] 0.5 0.5 0.5 0.5
RampSstep [%] 5 5 5 5
Vielleicht hilft es ja dem Einen oder Anderen.
VG
Stefan