Hallo Liebe Leute,
am gestrigen Tage ist mal wieder ein Paket mit diversem HM- Equipment angekommen, u.a. auch der o.g. Dimmer, der letztlich für einen Deckenventilator mit Licht eingesetzt werden soll (deshalb auch Phasenanschnitt für induktive Lasten).
Autocreate resp. Pairing hat wunderbar und auf Anhieb geklappt, auch mehrere getConfig sind im Gegensatz zu anderen Geräten ohne Fehler oder TimeOut's jedesmal durchgelaufen.
Zu den Merkwürdigkeiten:
Wenn ich den Slider auf einen beliebigen Wert stelle, taucht in den Readings z.B. "set_50" auf, aber mehr passiert nicht. Aktualisiere ich mit einem Browser-Refresh oder auch mit "statusRequest" steht alles weiterhin auf "off". Selbiges passiert auch, wenn ich z.B. "toggle, on, up" benutze...
Heute Morgen standen alle Stati auf "???", obwohl über Nacht kein Netzausfall o.ä. vorhanden war (UPS).
Eine weitere Merkwürdigkeit besteht darin, das in der GUI bei Klick auf ON im ersten Kanal die Grafik kurz auf ON und sofort wieder auf OFF wechselt (die grau/gelb default- "Birnen"- Grafik), im zweiten Kanal aber die Grafik auf ON mit Ausrufezeichen stehen bleibt. Benutze ich hingegen z.B. UP, habe ich beim CH1 wieder selbiges, bei CH2 aber erscheint "set_10" an Stelle der Grafik, wobei in beiden Fällen ein "statusRequest" die Grafik zu OFF wechseln lässt.
Ich bin dann heute Morgen beigegangen und habe die durch Autocreate generierten Zeilen entsprechend erweitert in der Hoffnung, das sich das Verhalten ggf. ändert und sich daraus ein Zusammenhang ableiten lässt, aber leider ohne Erfolg.
Anbei die geänderten Zeilen, wobei ich entsprechende Kommentare zu Änderungen hinterlegt habe (CH2 identisch zu CH1)
# 2fach HM2D1 Dimmer
define HM2D1 CUL_HM 220AD4 #Namen geändert
attr HM2D1 IODev SCC2
attr HM2D1 alias 2fach Dimmer #Alias hinzugefügt
attr HM2D1 autoReadReg 4_reqStatus
attr HM2D1 expert 2_raw
attr HM2D1 firmware 2.3
attr HM2D1 group HM.Aktoren # Gruppe hinzugefügt
attr HM2D1 model HM-LC-DIM2L-SM
attr HM2D1 msgRepeat 3 #Hinzugefügt
attr HM2D1 room EG.Wohnzimmer #Hinzugefügt
attr HM2D1 serialNr KEQ0530035
attr HM2D1 subType dimmer
attr HM2D1 webCmd getConfig:clear msgEvents
define HM2D1_1 CUL_HM 220AD401 #Namen geändert
attr HM2D1_1 group HM.Aktoren #Gruppe hinzugefügt
attr HM2D1_1 model HM-LC-DIM2L-SM
attr HM2D1_1 peerIDs 00000000,
attr HM2D1_1 room EG.Wohnzimmer #Raum Hinzugefügt
attr HM2D1_1 webCmd statusRequest:toggle:on:up:pct:slider,0,1,100:down:off #pct:Slider... hinzugefügt
define HM2D1_2 CUL_HM 220AD402
attr HM2D1_2 group HM.Aktoren
attr HM2D1_2 model HM-LC-DIM2L-SM
attr HM2D1_2 peerIDs 00000000,
attr HM2D1_2 room EG.Wohnzimmer
attr HM2D1_2 webCmd statusRequest:toggle:on:up:pct:slider,0,1,100:down:off
Man sollte doch zumindest davon ausgehen können, das sich beide Kanäle identisch verhalten, oder?
Ich habe heute den Tag über keine Zeit, aber heute Abend werde ich beide Kanäle mal mit einer identischen Last beaufschlagen ...
Also erstmal grundsätzliche Frage, ob jemand da ggf. irgend etwas zu anmerken kann, warum sich die Kanäle so komisch und vor allem unterschiedlich verhalten?
Zitat von: M_I_B am 07 Mai 2016, 10:53:15
Pairing hat wunderbar und auf Anhieb geklappt
Glaube ich nicht, zeig ein list von HM2D1.
... sollst Du gerne haben:
Internals:
CFGFN /opt/fhem/aktoren.cfg
DEF 220AD4
IODev SCC2
LASTInputDev SCC2
MSGCNT 29
NAME HM2D1
NR 693
SCC2_MSGCNT 29
SCC2_RAWMSG A0E1E8002220AD4F100000101000616::-25:SCC2
SCC2_RSSI -25
SCC2_TIME 2016-05-07 10:44:44
STATE CMDs_done
TYPE CUL_HM
channel_01 HM2D1_1
channel_02 HM2D1_2
lastMsg No:1E - t:02 s:220AD4 d:F10000 0101000616
protLastRcv 2016-05-07 10:44:44
protSnd 41 last_at:2016-05-07 10:44:44
protState CMDs_done
rssi_SCC2 min:-22 lst:-22 max:-21 cnt:15 avg:-21.66
rssi_at_SCC2 lst:-25 min:-25 max:-24 cnt:29 avg:-24.55
Readings:
2016-05-06 23:54:39 D-firmware 2.3
2016-05-06 23:54:39 D-serialNr KEQ0530035
2016-05-07 10:38:55 PairedTo 0xF10000
2016-05-07 10:38:55 R-pairCentral 0xF10000
2016-05-07 10:38:55 RegL_00. 02:01 0A:F1 0B:00 0C:00 15:FF 16:00 00:00
2016-05-07 10:44:44 state CMDs_done
Helper:
HM_CMDNR 30
cSnd 01F10000220AD4020E,11F10000220AD40202140320FFFF
mId 002E
rxType 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +220AD4,00,00,00
nextSend 1462610684.43586
prefIO
rxt 0
vccu
p:
220AD4
00
00
00
Mrssi:
mNo 1E
Io:
SCC2 -23
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
Scc2:
avg -21.6666666666667
cnt 15
lst -22
max -21
min -22
At_scc2:
avg -24.551724137931
cnt 29
lst -25
max -24
min -25
Shadowreg:
Tmpl:
Attributes:
IODev SCC2
alias 2fach Dimmer
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.3
group HM.Aktoren
model HM-LC-DIM2L-SM
msgRepeat 3
room EG.Wohnzimmer
serialNr KEQ0530035
sortby 30
subType dimmer
webCmd getConfig:clear msgEvents
Zitat von: M_I_B am 07 Mai 2016, 11:11:49
2016-05-07 10:38:55 PairedTo 0xF10000
2016-05-07 10:38:55 R-pairCentral 0xF10000
Sieht in der Tat gut aus. ICH würde den Dimmer löschen, den Dimmer auf Werkseinstellungen bringen und es noch einmal probieren. Normalerweise muss nix in der cfg ergänzt werden. Mein HM-LC-DIM2
T-SM machte keine Zicken beim Anlernen, ist aber auch das Phasenabschnitts-Modell...
Zitat von: dev0 am 07 Mai 2016, 11:18:08Sieht in der Tat gut aus.
... mein Reden ... Ich bin alt, aber noch lernfähig ;D
Zitat von: dev0 am 07 Mai 2016, 11:18:08ICH würde den Dimmer löschen, den Dimmer auf Werkseinstellungen bringen und es noch einmal probieren.
Ja, das werde ich heute Abend mal machen; wie gesagt müssen wir gleich los... Sonne brennt, rechte Hand jukt und EInladung des MoorRider MC wartet auf Einlösung ;)
Zitat von: dev0 am 07 Mai 2016, 11:18:08... ist aber auch das Phasenabschnitts-Modell...
Ob An- oder Abschnitt kommt erst weit hinter den HM-relevanten Teilen. Ich denke (hab noch kein Schaltbild), das beide Modelle bis auf die Art der Tryac- Ansteuerung (BTA08-600 / 8A, 600V), welche vollkommen losgelöst vom µC autark vorgenommen wird, vollkommen identisch sind.
... so ... (Das Witzige am Ende...)
Wie angesagt habe ich die Definition au sder CFG gelöscht, den Dimmer einmal auf Werksreset, CFG in FHEM neu geladen. Dann FHEM in den Pairingmode gebracht und gepairt, das Ganze zur Sicherheit 3 mal, wobei weitere Versuche keine Änderung mehr ergaben. FHEM hat den nun wie folgt angelegt:
define HM_220AD4 CUL_HM 220AD4
attr HM_220AD4 IODev SCC2
attr HM_220AD4 autoReadReg 4_reqStatus
attr HM_220AD4 expert 2_raw
attr HM_220AD4 firmware 2.3
attr HM_220AD4 model HM-LC-DIM2L-SM
attr HM_220AD4 room _autocreate_
attr HM_220AD4 serialNr KEQ0530035
attr HM_220AD4 subType dimmer
attr HM_220AD4 webCmd getConfig:clear msgEvents
define HM_220AD4_Sw_01 CUL_HM 220AD401
attr HM_220AD4_Sw_01 model HM-LC-DIM2L-SM
attr HM_220AD4_Sw_01 peerIDs
attr HM_220AD4_Sw_01 webCmd statusRequest:toggle:on:off:up:down
define HM_220AD4_Sw_02 CUL_HM 220AD402
attr HM_220AD4_Sw_02 model HM-LC-DIM2L-SM
attr HM_220AD4_Sw_02 webCmd statusRequest:toggle:on:off:up:down
List des Device
CFGFN
DEF 220AD4
IODev SCC2
LASTInputDev SCC2
MSGCNT 37
NAME HM_220AD4
NR 1002
SCC2_MSGCNT 37
SCC2_RAWMSG A0E278002220AD4F100000101000616::-27:SCC2
SCC2_RSSI -27
SCC2_TIME 2016-05-07 20:31:39
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_220AD4_Sw_01
channel_02 HM_220AD4_Sw_02
lastMsg No:27 - t:02 s:220AD4 d:F10000 0101000616
protLastRcv 2016-05-07 20:31:39
protSnd 48 last_at:2016-05-07 20:31:39
protState CMDs_done
rssi_SCC2 avg:-22.33 cnt:9 max:-22 min:-23 lst:-22
rssi_at_SCC2 lst:-27 min:-32.5 avg:-27.2 max:-26.5 cnt:37
Readings:
2016-05-07 20:27:13 CommandAccepted yes
2016-05-07 20:27:12 D-firmware 2.3
2016-05-07 20:27:12 D-serialNr KEQ0530035
2016-05-07 20:27:33 PairedTo 0xF10000
2016-05-07 20:27:33 R-pairCentral 0xF10000
2016-05-07 20:27:33 RegL_00. 02:01 0A:F1 0B:00 0C:00 15:FF 16:00 00:00
2016-05-07 20:31:39 state CMDs_done
Helper:
HM_CMDNR 39
cSnd 01F10000220AD40203,11F10000220AD40202C80000
mId 002E
rxType 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +220AD4,00,00,00
nextSend 1462645899.5837
prefIO
rxt 0
vccu
p:
220AD4
00
00
00
Mrssi:
mNo 27
Io:
SCC2 -25
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat 02
Role:
dev 1
prs 1
Rssi:
Scc2:
avg -22.3333333333333
cnt 9
lst -22
max -22
min -23
At_scc2:
avg -27.2027027027027
cnt 37
lst -27
max -26.5
min -32.5
Shadowreg:
Tmpl:
Attributes:
IODev SCC2
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.3
model HM-LC-DIM2L-SM
room _autocreate_
serialNr KEQ0530035
subType dimmer
webCmd getConfig:clear msgEvents
List des 1. CH
CFGFN
DEF 220AD401
NAME HM_220AD4_Sw_01
NR 1003
STATE off
TYPE CUL_HM
chanNo 01
device HM_220AD4
Readings:
2016-05-07 20:31:39 CommandAccepted yes
2016-05-07 20:27:34 R-loadAppearBehav off
2016-05-07 20:27:34 R-powerUpAction off
2016-05-07 20:27:58 RegL_01. 12:01 30:06 31:00 56:00 57:24 00:00
2016-05-07 20:31:39 deviceMsg off (to SCC2)
2016-05-07 20:31:39 dim stop:off
2016-05-07 20:31:39 level 0
2016-05-07 20:30:45 levelMissed desired:53
2016-05-07 20:31:39 overheat on
2016-05-07 20:31:39 overload on
2016-05-07 20:31:39 pct 0
2016-05-07 20:31:39 recentStateType ack
2016-05-07 20:31:39 reduced off
2016-05-07 20:31:39 state off
2016-05-07 20:31:39 timedOn off
Helper:
peerIDsRaw ,00000000
Dir:
cur stop
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shadowreg:
Tmpl:
Attributes:
model HM-LC-DIM2L-SM
peerIDs 00000000,
webCmd statusRequest:toggle:on:off:up:down
List des 2. CH
CFGFN
DEF 220AD402
NAME HM_220AD4_Sw_02
NR 1004
STATE set_on
TYPE CUL_HM
chanNo 02
device HM_220AD4
Readings:
2016-05-07 20:27:34 R-loadAppearBehav off
2016-05-07 20:27:34 R-powerUpAction off
2016-05-07 20:31:11 RegL_01. 12:01 30:06 31:00 56:00 57:24 00:00
2016-05-07 20:29:14 level set_50
2016-05-07 20:31:39 state set_on
Helper:
dlvl C8
dlvlCmd ++A011F10000220AD40202C80000
peerIDsRaw ,00000000
stateUpdatDly 120
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shadowreg:
Tmpl:
Attributes:
model HM-LC-DIM2L-SM
peerIDs 00000000,
webCmd statusRequest:toggle:on:off:up:down
Wie man sieht, sind die beiden Channel vollkommen unterschiedlich. Zum einen verhalten sie sich unterschiedlich beim Absetzen eines Steuerbefehls (on, off, up, down, ...), zum anderen hat der CH1 deutlich mehr readings, was sich auch durch ungezählte getConfig u.ä. nicht ändert...
... und jetzt kommt's:
Ich habe dann mal beide Kanäle mit etwas Last versehen (je 40W). Dann, aber erst dann werden beide Kanäle gleich in jeder Hinsicht und reagieren dann auch identisch ... Wer hat's verbrochen? eQ3 hat's verbrochen :o ::)
Noch mal ne vielleicht blöde Frage:
Wenn ich mit "devStateIcon" eine Lämpchengrafik (www\images\openautomation\light_light_dim_xx) setzen möchte, reagiert die ja nur auf gerade 10er. Ich kann zwar Konstrukte ala "devStateIcon off|00:light_light_dim_00" oder "devStateIcon 0.5|1|1.5|2|...|14.5:light_light_dim_10" generieren, um alle Zwischenstufen "gerundet" anzeigen zu lassen, aber das wird ja ein irrer Rattenschwanz. Da gibt es doch sicher eine geschicktere Lösung?!?
HINT:
Der verbaute Triac lässt sich direkt durch die 16A Variante "BTA16-600" resp. "BTA16-800" ersetzen; gerade getestet. Dann aber bitte die Leiterbahnen und Sicherungen entsprechend verstärken. Für eine Dauerbelastung mit 2 x 16A ist allerdings weder das Kühlblech noch die Leiterbahnen und Drosseln ausgelegt. Also entweder als kurzzeitige Reserve für Geräte betrachten, die einen hohen Einschaltstrom benötigen, oder mit größerem Kühlblech und Lüfter nachhelfen...
Zitat von: M_I_B am 07 Mai 2016, 23:44:28
aber das wird ja ein irrer Rattenschwanz. Da gibt es doch sicher eine geschicktere Lösung?!?
Lässt sich mit regexp etwas verkürzen. Kann man auch in einer Perl sub zusammenfassen, dann musste nur noch den Funktionsnamen eintragen.
1\d.*:light_light_dim_10:off 2\d.*:light_light_dim_20:off ...
Zitat... und jetzt kommt's:
Ich habe dann mal beide Kanäle mit etwas Last versehen (je 40W). Dann, aber erst dann werden beide Kanäle gleich in jeder Hinsicht und reagieren dann auch identisch ... Wer hat's verbrochen? eQ3 hat's verbrochen :o ::)
bei diesem dimmer gibt es doch sicherlich auch eine mindest-last-angabe.
Zitat von: frank am 08 Mai 2016, 10:28:38bei diesem dimmer gibt es doch sicherlich auch eine mindest-last-angabe.
Gut möglich, aber dann steht das irgendwo versteckt in den Registern und ist von mir nicht zu sehen.
Aber unabhängig davon sollten doch bitteschön die Readings u.s.w., also der digitale Teil der Sache, auch ohne Last vollständig lesbar/erreichbar sein... Das ist m.E. ein böser BUG resp. Designfehler. Ich denke, das niemand auf die Idee kommt, das Teil erstmal an vielleicht sehr unzugänglicher Stelle einzubauen und dann anzulernen. Das muss also auch immer auf dem Tisch anlernbar sein ...
Zitat von: dev0 am 08 Mai 2016, 07:37:52Lässt sich mit regexp etwas verkürzen. Kann man auch in einer Perl sub zusammenfassen, dann musste nur noch den Funktionsnamen eintragen.
Gute Idee; bin ich gerade nicht drauf gekommen ... Aber da geht die Idee gleich mit mir durch ;)
Frage:
Wäre es nicht möglich die Werte auf die PERL-Ebene zu übergeben resp. dort zu grabben und damit z.B. via GD oder ImageMagick die Grafik dynamisch zu generieren? Das hätte den Vorteil, das nur die SUB mit einem Befehl angesprochen werden muss (bei einem Event) und die Grafik auch das gleitende Hoch/Runterdimmen mit anzeigt. Dann könnte man auch diverse Spielereien mit analogen Zeigern oder mitlaufender Werteangabe in der Grafik realisieren...
Finde ich ziemlich gut, aber geht das auch?
ZitatGut möglich, aber dann steht das irgendwo versteckt in den Registern und ist von mir nicht zu sehen.
schau mal in der bedienungsanleitung => technische daten. register gibt es sicherlich nicht.
zumindestens der eine chn zeigt ja auch funktionsstörungen:
2016-05-07 20:31:39 overheat on
2016-05-07 20:31:39 overload on Zitatalso der digitale Teil der Sache, auch ohne Last vollständig lesbar/erreichbar sein...
das wäre sicherlich wünschenswert. :)
Zitat von: frank am 08 Mai 2016, 10:53:35schau mal in der bedienungsanleitung => technische daten. register gibt es sicherlich nicht.
... stimmt ... RTFM ^^ Dafür ist 25-500VA angegeben, also ~25W Mindestleistung.
Zitat von: frank am 08 Mai 2016, 10:53:35zumindestens der eine chn zeigt ja auch funktionsstörungen:
2016-05-07 20:31:39 overheat on
2016-05-07 20:31:39 overload on
... was hier in beiden Fällen eine Falschmeldung ist (noch ein BUG). Denn ohne Last kann ich weder eine Übertemperatur noch eine Überlastung generieren ... Das ist m.E. mal wieder von eQ3 mit der heißen Nadel gestrickt >:( Dafür sind ~140 Tacken m.E. eine Frechheit!
Overhead und overload kan ich mir einmal ansehen wenn du ein paar rohmessages sniffen.
Koennte sein, dass das device es nicht unterstützt.
Hallo
Soweit ich noch weiss hat der Dimmer einen automatischen Lastausfall-Erkennungsabgleich.
Diesen kann man mit der Homematic Software starten.
Denn erhaltenen Wert speichert mann dan im Dimmer.
Habe bei mir den Wert aber damals mit 0 ersetzt.
Das heist die Lasterkennung ist aus oder wenn das nicht geht sehr träge eingestellt.
Bei mir steht:
Zitatoverheat off
overload off
Das ging damals aber nicht mit FHEM, nur über die Homematic Software.
Mein Dimmer hat anfangs so gar nicht funktioniert, wollte ihn schon wieder ausbauen.
Denn Hinweis habe ich damals aber im Homematic Forum erhalten.
ZitatSoweit ich noch weiss hat der Dimmer einen automatischen Lastausfall-Erkennungsabgleich.
Diesen kann man mit der Homematic Software starten.
könnte das mit diesem register zu tun haben?
Zitat2016-05-07 20:27:34 R-loadAppearBehav off
Zitat2016-05-07 20:27:34 R-loadAppearBehav off
Das Register ab ich nicht.
Mein Dimmer hat aber Firmware 1.9.
Habe auch das Gefunden:
https://forum.fhem.de/index.php?topic=22935.0 (https://forum.fhem.de/index.php?topic=22935.0)
... kurz zwischendurch ...
2016-05-07 20:31:39 overheat on
2016-05-07 20:31:39 overload on
Sobald eine Last dran ist, gehen die auf OFF, unabhängig vom eingestellten Level. Overload habe ich gerade getestet. Bei überschreiten von ca. 550W dauert es ca. 3 Sekunden und dann geht der auf ON und schaltet die Last ab. Ob das so sein soll und ob es da Unterschiede beim L-Typ oder T-Typ gibt, kann ich noch nicht sagen. Overheat kann ich im Moment nicht testen, da meine elektronische Last mit 550W schon deutlich über dem Limit läuft. Da muss ich mir erstmal was mit 250W Flutern zusammenbosseln...
die dim.L haben kein overload/temp sondern einen loaderror.
probiert einmal mit der neues Version
... ich hatte heute Mittag ein FHEM- Update gemacht; da war es noch nicht dabei und aktuell "nothing to do...".
Logisch. Die files aus svn werden in den frühen Morgenstunden auf Update gestellt. Du kannst es aus svn jederzeit laden. Oder auf morgen warten
... ok, wusste ich noch nicht ... Und direkt aus SVN laden habe ich noch nicht gemacht. Also habe ich bis eben gewartet. Folgendes ist angekommen:
2016.05.09 08:47:45.105 1: UPD ./CHANGED
2016.05.09 08:47:45.708 1: UPD ./fhem.pl
2016.05.09 08:47:46.154 1: UPD FHEM/00_FBAHAHTTP.pm
2016.05.09 08:47:46.203 1: UPD FHEM/00_ZWDongle.pm
2016.05.09 08:47:46.297 1: UPD FHEM/10_CUL_HM.pm
2016.05.09 08:47:47.291 1: UPD FHEM/10_FBDECT.pm
2016.05.09 08:47:47.363 1: UPD FHEM/31_HUEDevice.pm
2016.05.09 08:47:47.463 1: UPD FHEM/37_plex.pm
2016.05.09 08:47:47.652 1: UPD FHEM/93_DbLog.pm
2016.05.09 08:47:47.851 1: UPD FHEM/98_HMinfo.pm
2016.05.09 08:47:48.096 1: UPD FHEM/HMConfig.pm
2016.05.09 08:47:48.364 1: UPD FHEM/SetExtensions.pm
2016.05.09 08:47:48.473 1: UPD www/images/fhemSVG/gasoline.svg
overheat und overload sind aber immer noch da ... Natürlich Shutdown/Restart gemacht und anschließend, da mal wieder fällig, Raspbian auf aktuellen Stand gebracht und Server neu gestartet...
Ist das reading noch alt? Löschen doch mal alle mit clear readings.
Dann schalten und statusrequest.
... hab ich getan wie gesagt:
"clear readings" und zur Sicherheit "clear all" jeweils beim Device und bei den Channels. Dann jeden Kanal einmal ON und wieder OFF ...
... und schwuppdibupp sind die altbekannten "overheat" und "overload" wieder da :o
Dann gerade noch mal definition in der cfg gelöscht, Dimmer FactoryReset, neu gepairt, ... bleibt so...
Hat mit pairen nichts zu tun. Muss ich testen. Es sollte bei allen l Typen nicht mehr kommen... Sicher ein bug
Zitat von: martinp876 am 10 Mai 2016, 20:39:12Hat mit pairen nichts zu tun.
... naja, kann ja nix schaden und da es noch auf'm Tisch liegt ...
Aber mal doof gefragt: Wäre es so schlecht, wenn das so bliebe? Immerhin reagiert zumindest "overload" korrekt. Wenn die Tage schlechtes Wetter is, teste ich auch noch mal, ob "overheat" entsprechend reagiert, wobei ich da aber Zweifel habe: Am Kühlblech ist kein Sensor, der das erkennen könnte und die Triac's sind AllerWeltsTypen ohne Sense- Funktionalität. Denkbar wäre lediglich ein Sensor auf der Platine (habe ich noch nicht rausgefummelt) resp. der im AVR. Aber wenn die "mir ist zu heiß" melden, dürfte der Kühlkörper sich schon längst durch die Plaste geschmolzen haben ^^
die DIM waren nicht dabei, nur die Dim.
korrigiert.
overheat ist schlicht nicht im Angebot bei "L" typen
Zitat von: martinp876 am 11 Mai 2016, 10:38:26die DIM waren nicht dabei, nur die Dim.
... alles wird gut ;)
Zitat von: martinp876 am 11 Mai 2016, 10:38:26overheat ist schlicht nicht im Angebot bei "L" typen
Ok, dann brauche ich da gar nicht erst was zum Testen frickeln. Ich frage mich nur, wie die dann eine Überhitzung physikalisch abfangen... Durch selbstständiges Auflöten der Triac- Anschlüsse?!? ;D
Kann ich nicht sagen könntest du testen.
Was ist overload? Thermisch? Elektrisch? Hast du eine Beschreibung? Immer wenn man genau nachsieht kommt man drauf, dass man es auch anders sehen kann.
Der aktor koennte sich schützen und abschalten aber keineinfo schicken. Er könnte overload schicken, was ja stimmt.
Es ist auch möglich er schicktovertemp aber wir kennen den code nicht.
... "overload" ist aus Sicht des Elektronikers immer eine leistungsmäßige Überlastung und wird dann ggf. von "overtemp" gefolgt.
Eigentlich muss man das vollkommen getrennt betrachten, denn eine Übertemperatur muss nicht zwingend einer Überlastung folgen, sondern kann auch andere Ursachen haben, wie z.B. parasitäre Schwingungen o.ä. (gerne genommen in Verstärkern aller Art). Aber im Fall eines schnöden Dimmers, der i.d.R. nicht freiwillig zum Sender wird, sollte Übertemteratur immer Überlast folgen und nie umgekehrt.
Ich werde es aber noch mal explizit testen; Ersatzteile in Sinne von abgerauchten Triacs, Drosseln und Sicherungen habe ich genug auf Lager ;) Kann aber noch 1-2 Tage dauern, da gerade andere wichtige Baustelle am Start...
Schon klar mit Überlast..... Wenn man es vereinfacht betrachtet und eine über temp ansteht woraufhin die last reduziert werden muss ist es aus Sicht des Users Überlast. Schlussendlich reduziert sich die maximale last aufgrund der Umgebungstemperatur , je nach Schaltung.
Vergiss nicht HT die messages zu loggen wenn du dein device e quälst.
... 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 ...
... 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?
ZitatZum 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.
Zitatzum 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.
Zitat von: martinp876 am 27 Mai 2016, 21:37:23welchen 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...
Zitat von: martinp876 am 27 Mai 2016, 21:37:23Wenn 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
Zitat von: martinp876 am 27 Mai 2016, 21:37:23bleiben 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?
ZitatHU? 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.
ZitatDas 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.
ZitatEs 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.
ZitatD.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.
Zitat von: martinp876 am 28 Mai 2016, 11:13:44man 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*
Zitat von: martinp876 am 28 Mai 2016, 11:13:44(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.
Zitat von: martinp876 am 28 Mai 2016, 11:13:44hm - 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 ...
Zitat von: martinp876 am 28 Mai 2016, 11:13:44Was 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!
>:( >:( >:( 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 ?!?
tztztz
du erwartest hoffentlich keine Antwort :) ich hasse textaufgaben
sinnvoll wäre gewesen. ein aktuelles list vom device, oder kurz Befehle sniffen ....
ZitatBei 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 :)
Zitat von: fhem-hm-knecht am 02 Juni 2016, 13:00:22du erwartest hoffentlich keine Antwort :) ich hasse textaufgaben
... wie jetzt? Auch in der Schule schon? :P
Zitat von: fhem-hm-knecht am 02 Juni 2016, 13:00:22sinnvoll 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
Zitat von: fhem-hm-knecht am 02 Juni 2016, 13:00:22und bevor ich den Werksreset gemacht hätte, hätte ich anlernknopf gedrückt, bzw hmPairSerial <seriennummer> von der vccu ausgelöst
... ach nee ;D 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 ...
Zitat von: fhem-hm-knecht am 02 Juni 2016, 13:00:22ohne Logs nur doofes raten , ich werf mal chemtrails in den Raum :)
... he, Verschwörungstheoretiker? ::) 8)
Dennoch die Frage nochmal: Neigen die Teile dazu, sich beim Abschmieren von FHEM gelegentlich selbst aufzuhängen?
... 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...
### 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
... 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?!
try!
physLevel ist jetzt der physLevel - also ohne "umrechnung".
... sach blos, ich hab' ma'n "echten" Fehler entdeckt? Is ja'n Ding ;D
Danke für's Fixen. Teste ich zeitnah aus!