HM-LC-DIM2L-SM (2fach AP Dimmer): Merkwürdigkeiten

[M_I_B]

... Update ... Ich geb's auf 
Ich habe mir beim Lasttest jetzt zum dritten mal meine elektronische Last zerschossen. Die scheint mit Phasenabschnitt irgendwie so gar nicht klar zu kommen. Ich muss jetzt erstmal neue Halbleiter für die Last beschaffen, da mein Vorrat aufgebraucht ist (und die Bude deutlich nach "Strom" riecht).
Sollte mir noch ein anderer gangbarer Weg einfallen, ohne gleich eine neue, stärkere Last kaufen zu müssen, greife ich das Thema wieder auf. Aber vorerst packe ich das mal zur Seite resp. verbaue den Dimmer am angedachten Platz...

NACHTRAG:
Im Zusammenhang mit meinen "rauchigen" Tests ist mir bei diesem Dimmer und auch bei z.B. dem 4fach Hutschinenaktor aufgefallen, das eQ3 das Design derart gestaltet hat, das ein Herauslegen der Antenne resp. Umbau auf SMA nicht möglich ist, da das ganze Chassis unter Spannung steht. Dort wird nicht ein normales Trafo- oder Schaltnetzteil verwendet, sondern die Netzspannung ohne galvanische Trennung per Switcher auf die benötigte Betriebsspannung herunter gesetzt. Das mag zwar preiswert sein, versperrt aber erst einmal jegliche Modifikationen, welche interne Geräteteile nach Außen bringen.
Interessanter Weise ist zumindest im AP- Dimmer mehr als genug Platz für einen klassischen Trafo, meinetwegen auch ein Schaltnetzteil (ungern, da zusätzliche Störstrahlung produzierend). Daher werde ich mir wohl noch einen Zweiten bestellen und den dann entsprechend mit klassischem Trafo und ext. Antenne modifizieren, um auch Reichweiten weiot über der Spec. zu erreichen. Was ich allerdings noch nicht habe klären können ist, ob die Triacs direkt oder über Opto angesteuert werden. Letzteres wäre natürlich von Vorteil, aber da ich meinen Ersten bereits gestern verbaut habe, muss ich erst auf den Nächsten warten.

Allgemein:
Besteht denn hier überhaupt Interesse an solchen Hardware- Mod's? Ich will Euch ja nicht mit Dingen nerven, die außer mir eh keiner umsetzt resp. benötigt ...

[M_I_B]

... inzwischen ist alles angeschlossen und funktioniert so weit ...

Erster Knackpunkt war, das der zweite Kanal, an dem ein Deckenventilator im Wohnzimmer hängt, nicht so wollte wie ich. Wenn man auf 100% gegangen ist und dann langsam zurück, klappte das, aber wenn ich von OFF auf z.B. 50% wollte, ging der Dimmer sofort wieder auf OFF.
Das konnte ich durch "regSet loadErrCalib 0" beseitigen. Das Problem liegt zum einen in der rein induktiven Last (obwohl der Dimmer dafür ausgelegt ist), im speziellen aber daran, das die Last einfach zu klein ist. Denn mit einer 40W Funzel parallel dazu geht es.

Woran ich mir aber die Zähne ausbeiße ist das Setzen des minimalen Dim-Level...
In der Liste gibt es da mehrere Register. Zum einen "lgDimMinLvl" und "shDimMinLvl", dann noch "lgOnMinLevel" so wie "shOnMinLevel".
Zum einen geht keiner der genannten Register (Fehler: "Peer not specified" / Welchen Peer soll ich wie wo spezifizieren?!? ), zum anderen verstehe ich nur einen Teil der genannten Register ...

Hat da irgend wer Plan von, wie hier der minimale DimLevel einzustellen ist und kann vielleicht sogar die ganzen Register erklären ? Das würde sicherlich auch viele andere "Dimmeruser" interessieren, oder?

[martinp876]

Zum einen geht keiner der genannten Register (Fehler: "Peer not specified" / Welchen Peer soll ich wie wo spezifizieren?!? ),

welchen peer? na den, welchen du benutzen willst.
die Register lg/sh beziehen sich IMMER auf eine Peer - also einen Taster überwelchen der Aktor gesteuert werden soll.
evtl willst du die eingebauten nutzen, also die Self01/02. die musst du erst sichtbar machen.
Wenn dir das alles unkalr ist, schaue ins Einsteigerdoc HM Bereich um di r ein Grundwissen anzueignen.

zum anderen verstehe ich nur einen Teil der genannten Register ...

nun - long und short wirst du jetzt im Einsteigerdoc nachlesen. bleiben noch:
DimMinLvl und OnMinLevel
das eine ist wohl der Level bis zu dem man down dimmen kann. Mit diesem peer.
Das andere ist der Level, nach dem das Licht abschaltet, wenn es weniger % sind. Das verhindert, dass man 2% on stehen lässt und ins Bett geht.

[M_I_B]

welchen peer? na den, welchen du benutzen willst.
die Register lg/sh beziehen sich IMMER auf eine Peer - also einen Taster überwelchen der Aktor gesteuert werden soll.
evtl willst du die eingebauten nutzen, also die Self01/02. die musst du erst sichtbar machen.

HU? Was macht denn das im Zusammenhang mit dem mindest erforderlichen Level für einen Sinn? Wenn ich physikalisch ein bestimmtes Gerät am Dimmer habe, welches sich erst ab z.B. 30% rührt und somit der nutzbare Dimmbereich 30-100 beträgt, so ist das doch vollkommen unabhängig von einem X-beliebigen Peer, weil es der Verbraucher ist, der diese Parameter vorgibt und nicht irgend eine oder gar mehrere gepeerte Tasten. Die physikalischen Parameter des Verbrauchers am Peer fest zu machen erschließt sich mir irgendwie gerade nicht... Mag ja sein, das ich mal wieder zu viel von der Hardwareseite denke, aber Lastparametrierung gehört nach allg. Verständnis in die Treiberstufe (hier der Dimmer als Hardware) und nicht in die ausführende Logik...

Wenn dir das alles unkalr ist, schaue ins Einsteigerdoc HM Bereich um di r ein Grundwissen anzueignen.
nun - long und short wirst du jetzt im Einsteigerdoc nachlesen.

... sei lieb und bleib locker; das hatten wir doch schon hinter uns, oder? ... Das von Dir immer so gern zitierte Einsteigerdock hilft mir weder bei der Erkenntnis bezgl. des Festmachens phys. Eigenschaften an einem Peer, noch bei der Erklärung der Register und der Präfixe lg/sh

bleiben noch:
DimMinLvl und OnMinLevel
das eine ist wohl der Level bis zu dem man down dimmen kann. Mit diesem peer.
Das andere ist der Level, nach dem das Licht abschaltet, wenn es weniger % sind. Das verhindert, dass man 2% on stehen lässt und ins Bett geht.

Ah ok. das macht Sinn, zumindest in Bezug auf den Verbraucher... DimMinLvl hatte ich auch so gesehen, nur OnMinLvl hätte ich jetzt vermutlich anders interpretiert.
Letztlich brauche ich für CH1 DimMinLvl 10 (Licht) und für CH2 DimMinLvl 20 (VentiLenti).

Also mal zusammenfassend:
Es gibt demnach keine Möglichkeit, den Dimmer resp. den jeweiligen Kanal des Dimmers auf den (i.d.R. immer dort verbleibenden) Verbraucher zu parametrisieren?!
D.h., das ich immer den Umweg über einen Peer (hier z.B. die int. Tasten) gehen muss, um dieser dann die Parametrisierung des Verbrauchers mitzugeben, womit ich den Dimmer/Kanal dann nicht mehr direkt, sondern nur via Peer steuern kann/darf?

[martinp876]

HU? Was macht denn das im Zusammenhang mit dem mindest erforderlichen Level für einen Sinn?

man kann es je peer einstellen. Zum einen kann man es aus den registern lesen (peer erforderlich sollte das klären) und zum andere könnte es eine Sinnvolle option for den einen oder anderen sein. Es hat nicht nur etwas mit der Physik sondern auch etwas mit comfort zu tun.
Egal - eQ3 hat es so gemacht - ich kann es nicht ändern.
Aber: ich verstehe dein Anliegen. Nur: ich sehe ein Problem sondern eine Lösung - Templates.
(auch wenn ich mich wiederhole): definiere ein Template mit den Einstellungen zu diesen Werten. Dann nutze das Template für alle Peers dieses Dimmers. Das Template stellt sicher (oder zumindest erlaubt die Kontrolle mit configCheck) dass alle Peers so eingestellt sind.
Möglich ist es, templates mit Parametern auszurüsten. Also "myDimmerTemplate" mit einem "minLevel" zu parametrisieren. Damit kann man das (und mehr) lösen.
Wichtig (oder sinnvoll - man kann alles problemlos ändern) ist es, die gewünschten Verhalten zu definieren und unterschiede zu erkennen. Diese kann man dann einstellbar machen.

Das von Dir immer so gern zitierte Einsteigerdock hilft mir weder bei der Erkenntnis bezgl. des Festmachens phys. Eigenschaften an einem Peer, noch bei der Erklärung der Register und der Präfixe

hm - ist es so schlecht? long und short sind dort erklärt, schon seit urzeiten, unverändert. Auch was ein peer ist. und wo man einen peer braucht. und dass es "interne" peers gibt die man sichtbar machen muss  will man sie einstellen.
Zumindest einige deiner Fragen hättest du beantworten können - meine ich. Alle wohl nicht.

Es gibt demnach keine Möglichkeit, den Dimmer resp. den jeweiligen Kanal des Dimmers auf den (i.d.R. immer dort verbleibenden) Verbraucher zu parametrisieren?!

ja - nein - ....
1) die Zentrale kann (fast) alles. auch minlevel unterschreiten (alles habe ich nicht getestet, ist aber einfach zu prüfen.
2) bei peers kann man das machen - einzeln.
3) mit templates kann man das üersichtlich(er) gestalten. De Facto sind register cool - aber etwas zum Basteln und für ... zumindest sehr interessierte. Templates sind eine Abstraktion welche man weniger interessierten zu verfügung stellen sollte. Ich denke daran ein repository in wiki einzurichten, welches man nutzen kann.  Ferner sind Tempaltes auch für freaks ein mittel die Übersicht zu behalten und das System zu kontrollieren - nach dem freaky register-setting.  => ich gehe dazu über ALLE register in templates zu abstrahieren

==> deine Wahl, ob es dir hilft.

D.h., das ich immer den Umweg über einen Peer (hier z.B. die int. Tasten) gehen muss, um dieser dann die Parametrisierung des Verbrauchers mitzugeben, womit ich den Dimmer/Kanal dann nicht mehr direkt, sondern nur via Peer steuern kann/darf?

verstehe ich nicht. alles was du über einen Button machen willst (egal welcher) wird im Button(also peer - schon klar oder?) definiert.
Bleibt die Zentrale. Wenn du "on" sagst geht der dimmer auf 100%. Wenn du etwas anderes willst dann nutze "pct 70" und definiere es als "on". Wirkliches Dimmen (so mit drücke und warte) geht von der Zentrale aus nicht.
Was also fehlt, ist dass die Zentrale das einschränkt. aber fehlt das? hast du das Attr levelRange mal angesehen? sollte auch bei dir zu finden sein.

[M_I_B]

man kann es je peer einstellen. Zum einen kann man es aus den registern lesen (peer erforderlich sollte das klären) und zum andere könnte es eine Sinnvolle option for den einen oder anderen sein. Es hat nicht nur etwas mit der Physik sondern auch etwas mit comfort zu tun.
Egal - eQ3 hat es so gemacht - ich kann es nicht ändern.

Ok, kapiert; ist halt so und ich kann es leider auch nicht ändern... Sagte ich schon mal, das eQ3 m.E. doch manchmal ziemlich verquer denken?!?
Auch wenn wir es nicht ändern können; den Komfort kann ich hier ehrlich gesagt nicht sehen. Wenn ich auf Hardwareseite die Last parametrieren könnte, wäre das m.E. viel komfortabler, da ich mich im Anschluß nie wieder darum kümmern muss, egal ob ich via Peer, Pear oder was auch immer den Dimmer ansteuere. Denn die Lastparametrierung soll ja dafür sorgen, das die Last in einem zulässigen Bereich arbeitet, welcher auf 0-100% nach außen umgesetzt wird. Das Über- oder Unterschreiten und somit Betrieb der Last ausserhalb der Parametrierung sollte m.E. auch nicht über die Zentrale, Peer, Pear, ... möglich sein.
... aber gut, ist eh nicht zu ändern *seufz*

(auch wenn ich mich wiederhole): definiere ein Template mit den Einstellungen zu diesen Werten. Dann nutze das Template für alle Peers dieses Dimmers. Das Template stellt sicher (oder zumindest erlaubt die Kontrolle mit configCheck) dass alle Peers so eingestellt sind.

Mit Templates habe ich noch nie was gemacht. Da muss ich mich erst einmal reinlesen. Schreibe ich mir mal auf die ToDo... Danke für den Hinweis.

hm - ist es so schlecht? long und short sind dort erklärt, schon seit urzeiten,

Nein, das es schlecht ist wollte ich damit keinesfalls zum Ausdruck bringen. Ich schaue da schon oft rein und es hilft mir auch i.d.R.. Nur manchmal, wie eben in diesem Fall, kann es meine Fragen einfach nicht beantworten, oder auch keine tieferen Zusammenhänge klären. Ich möchte Dir mal ein Beispiel nennen, warum ich z.B. in diesem Fall aus der Spur komme:
In der Robotik kann man grundsätzlich aufteilen in den Steuerrechner (FHEM), die Leistungselektronik (Dimmer) zur Ansteuerung der Achsmotoren, die Sensorschnittstellen (Rückkanal) zur Erfassung der tatsächlichen Position so wie natürlich der Motoren (Last/Lampen) und Sensoren (ggf. OverTemp u.ä.) selbst am Roboter(Arm). Die Schnittstelle Steuerrechner zu Leistungselektronik resp. Positionsgeber ist annährend genormt. Motoren, Getriebe, Verfahrwege u.s.w. aber sind ja bei allen Geräten anders. Daher werden die Daten der Motoren und Sensoren in der Leistungselektronik resp. Sensorschnittstelle parametriert und nicht im Steuerrechner. So kann man quasi jeden x-beliebigen Steuerrechner anschließen und sagen "X+13, Y+100, Z+400, M1-50, ..." und das Ziel wird unabhängig vom Steuerrechner (FHEM) immer getroffen...
Das ist derart verinnerlicht bei mir, das ich echt Probleme bekomme, wenn das wie hier vollkommen anders läuft ...

Was also fehlt, ist dass die Zentrale das einschränkt. aber fehlt das? hast du das Attr levelRange mal angesehen? sollte auch bei dir zu finden sein.

Ahhh... Ok, das Attribut hatte ich irgendwie übersehen Das ist ja im Prinzip so etwas, was ich benötige, auch wenn es auf Softwareseite arbeitet. Das probiere ich mal aus. Vielen Dank!

[M_I_B]

  So, jetzt hat es den Dimmer wohl Empfangstechnisch gerissen 

Ich hatte gestern Abend einen Tippfehler in einer RegEx, der beim ReLoad der Config FHEM zum Abschmieren gebracht hat. War schnell gefunden und der RPi eben so schnell neu gestartet. Alle HM- und IT- Systeme funktionieren wieder. Aber...
... genau seit dem Abschmierer kann ich den Dimmer nicht mehr ansteuern. Ausnahmnslos jeder Befehl läuft auf einen ResponseTimeout. Daher habe ich den Dimmer mehrfach stromlos gemacht. Bei Netzwiederkehr scheint er noch seinen aktuellen Status kund zu tun, da die roten Ausrufezeichen auf den Icon's verschwinden, aber dennoch laufen weiterhin alle Befehle auf einen Timeout.
Da der Dimmer bereits an ziemlich unzugänglicher Stelle verbaut ist, habe ich noch keinen Werksreset gemacht; hole ich nachher nach, wenn ich mich überwinden kann...

Hatte das Problem schon mal wer?
Wie kann das mit einem Abschmierer von FHEM zusammen hängen? Ist dabei vielleicht wirres Zeug in den Dimmer geschrieben worden?

UPDATE:
Nach dem ich zm Dimmer gekrabbelt bin (demjenigen, der da beim Bau Glas- an Stelle von Steinwolle verlegt hat, schlage ich den Kopf ab ) und zwei mal einen Werksreset (4 x Blinken beider LED) durchgeführt und neu gepairt habe, scheint er wieder zu funktionieren.

Bleibt die Frage, wie so was durch den Absturz von FHEM zustande kommen kann?
Wenn sowas nicht so selten ist, muss man/ich ja baulich dafür Sorge tragen, das man jederzeit irgendwie an die HM- Geräte heran kommt, um einen Werksreset durchführen zu können ?!?

[LuckyDay]

tztztz
du erwartest hoffentlich keine Antwort ich hasse textaufgaben

sinnvoll wäre gewesen. ein aktuelles list vom device, oder kurz Befehle sniffen ....

Bei Netzwiederkehr scheint er noch seinen aktuellen Status kund zu tun

warum sehe ich die hier nicht, was soll das Wort scheint bedeuten, hat er jetzt ... oder nicht

und bevor ich den Werksreset gemacht hätte, hätte ich anlernknopf gedrückt, bzw hmPairSerial <seriennummer> von der vccu ausgelöst
nur so mal als Beispiel.

ohne Logs nur doofes raten , ich werf mal chemtrails in den Raum

[M_I_B]

du erwartest hoffentlich keine Antwort ich hasse textaufgaben

... wie jetzt? Auch in der Schule schon? 

sinnvoll wäre gewesen. ein aktuelles list vom device, oder kurz Befehle sniffen ....warum sehe ich die hier nicht, was soll das Wort scheint bedeuten, hat er jetzt ... oder nicht

Hast ja recht... Gestern Nacht war ich zu genervt dazu u7nd bin stumpf ins Bett gegangen und heute Morgen habe ich nicht mehr dran gedacht...

Ansonsten bedeutet "scheint" in diesem Zusammenhang "er hat", und das mehrfach

und bevor ich den Werksreset gemacht hätte, hätte ich anlernknopf gedrückt, bzw hmPairSerial <seriennummer> von der vccu ausgelöst

... ach nee Aber im Ernst: Hatte ich nicht erwähnt, aber sehr wohl versucht (in umgekehrter Reihenfolge), schon alleine um mir ggf. das Krabbeln durch Glaswolle zu ersparen ...

ohne Logs nur doofes raten , ich werf mal chemtrails in den Raum

... he, Verschwörungstheoretiker? 

Dennoch die Frage nochmal: Neigen die Teile dazu, sich beim Abschmieren von FHEM gelegentlich selbst aufzuhängen?

[M_I_B]

... noch was komisches ... Oder gehört das in dsa DOIF- Board?

derzeit sind  2 Dimmer in Betrieb, ein UP "HM-LC-Dim1TPBU-FM" und den Zweikanaler "HM-LC-DIM2L-SM". Dazu den 6fach Taster "HM-PB-6-WM55". Alles so weit ok und alles funktioniert im Einzelnen.
Nun habe ich versucht in FHEM via DOIF den 6fach mit den Dimmern zu verknurzeln. Der Code ist bis auf natürlich das Ziel identisch... Und nun muss ich feststellen, das es beim UP- Dimmer wie erwartet funktioniert, bei dem 2Kanaler aber nicht. Dort passiert bei ?Long.* entweder gar nichts, oder aber, wenn bereits ein Wert Eingestellt ist, sptingt er entweder auf OFF oder dimmt herunter, aber nicht hoch ... Per Kommandozeile abgesetzt funktioniert up, down, on, off aber schmerzfrei, auch bei Auslösen von z.B. IT-Remote...
Was habe ich denn nun schon wieder verbockt? Kann ich mir nicht erklären Auch viel Suchen im Forum nach einer Standardlösung zum gepairten verbinden Taster/Dimmer habe ich nicht finden können, wo ich mal hätte nachschauen können...

Hier der Code... Die ersten Beiden tun nicht, de Letzte schon...

Code Auswählen Erweitern

### 6fach Taster Wohnzimmer > Licht und Lüfter, Esszimmer > Dimmer ###

# WZ Deckenlicht (HM-LC-DIM2L-SM, Kanal 1)
define WZLI1 DOIF ([HM6TA2_2:?Short.*]) (set HM2DI1_1 on) \
DOELSEIF ([HM6TA2_2:?Long.*]) (set HM2DI1_1 up) \
DOELSEIF ([HM6TA2_1:?Long.*]) (set HM2DI1_1 down) \
DOELSEIF ([HM6TA2_1:?Short.*]) (set HM2DI1_1 off) \
DOELSE
attr WZLI1 wait 1:1:1:1

# WZ Ventilator (HM-LC-DIM2L-SM, Kanal 2)
define WZVE1 DOIF ([HM6TA2_4:?Short.*]) (set HM2DI1_2 on) \
DOELSEIF ([HM6TA2_4:?Long.*] and [HM2DI1_2:pct] < 100) (set HM2DI1_2 up) \
DOELSEIF ([HM6TA2_3:?Long.*] and [HM2DI1_2:pct] > 0) (set HM2DI1_2 down) \
DOELSEIF ([HM6TA2_3:?Short.*]) (set HM2DI1_2 off) \
DOELSE
attr WZVE1 wait 1:1:1:1

# EZ Deckenlicht (HM-LC-Dim1TPBU-FM)
define EZLI1 DOIF ([HM6TA2_6:?Short.*]) (set HM2SD1_1 toggle) \
DOELSEIF ([HM6TA2_6:?Long.*] and [HM2SD1_1:pct] < 100) (set HM2SD1_1 up) \
DOELSEIF ([HM6TA2_5:?Long.*] and [HM2SD1_1:pct] > 0) (set HM2SD1_1 down) \
DOELSEIF ([HM6TA2_5:?Short.*]) (set HM2SD1_1 off) \
DOELSE
attr EZLI1 wait 1:1:1:1

[M_I_B]

... is das nun ein BUG oder mache ich was falsch?!?

Ich habe heute herausgefunden, das bei gesetztem Attribut "levelRange x,y", in meinem Fall "levelRange 10,100" ein "set [chanel] up" nicht mehr funktioniert, weder aus dem Code heraus (DOIF o.ä.), noch direkt aus der Kommandozeile. Sobald ich aber das Attribut auskommentiere und die Config neu lade, funktioniert ein UP in jedem Fall.
Da bei gesetzem Attribut "levelRange" die Readings "level" und auch "pct" negativ sind, funktioniert ein UP erst dann wieder, wenn der Level/PCT größer "0" ist.

@Martin: Kannst Du meinen BUG- Verdacht bitte mal evaluieren?!

[martinp876]

try!
physLevel ist jetzt der physLevel - also ohne "umrechnung".

[M_I_B]

... sach blos, ich hab' ma'n "echten" Fehler entdeckt? Is ja'n Ding 

Danke für's Fixen. Teste ich zeitnah aus!