Dimmbereich bei LEDs mit HM-LC-DIM1TPBU-FM

[rainer042]

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:

[martinp876]

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

[rainer042]

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

[martinp876]

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

[Loredo]

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 :-/

[martinp876]

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

[Loredo]

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

[martinp876]

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

[Loredo]

a) Ist das Konzept klar?
b) ist das Ergebniss hinreichend/gewünscht?

B klingt für mich genau richtig

[martinp876]

Hallo Loredo,

für Dimmer kann man jetzt
attr <dimmer> levelRange 10,40
setzen.

bitte
- testen
- commandref lesen, beachten und kommentieren

Gruss Martin

[stefanm]

Hallo Martin,

tolle arbeit.

Leider erhalte ich eine Fehlermeldung :

Wand_Lampe: unknown attribute levelRange. Type 'attr Wand_Lampe ?' for a detailed list

Code Auswählen Erweitern


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

[Loredo]

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

[martinp876]

Wenn ich jetzt allerdings pct=0 setze... bleiben die LEDs trotzdem an.

ja

oder 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.

Durch 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

nur 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

[Loredo]

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... 

[martinp876]

oder sein kann, granularer/gleichmäßiger lässt halt die Hardware nicht zu denke ich)

korrekt. HM kann 0,5% stufen ... dein Bereich ist ungerechnet...

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.

hm - da kann ich wenig tun - denke ich zumindest

Korrektur. 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