Hallo zusammen,
ich muß meinen Dachboden zwangsentlüften und habe mir deshalb einen Außenwandlüfter besorgt. Als Hausautomatisierer muß ich den natürlich luftfeuchteabhängig steuern. Das funktioniert mit dem genannten Phasenanschnitt Dimmer eigentlich gut. Leider funktioniert der gelieferte HM-LC-DIM1L-CV nur einige Stunden lang, dann reagiert er nicht mehr auf Funkbefehle, sondern geht auf Status "Missing Ack". Nach Stromlos-Setzen geht es wieder eine unbestimmte Zeit, dann wieder "Missing Ack".
Da das Teil verhältnismäßig schlecht zugänglich installiert werden soll, geht das regelmäßige Stromlos-setzen natürlich nicht. Ich habe allerhand Homematic Devices im Einsatz, aber der Dimmer ist das Einzige, was solche Probleme macht.
Ich habe das Teil schon mehrfach resettet, neu angelernt usw. - keine Besserung. Ich habe auch andere IO's (HMUart2/3) getestet, auch das ändert nix.
Ich hänge mal ein "list" mit dran, vielleicht sieht einer der Experten, wo es klemmen könnte.
Gruß Roland
Internals:
CFGFN
DEF 6BA7DF
FUUID 5f12bf86-f33f-af18-1e11-34202e16d7b86e2b
HmUART1_MSGCNT 39
HmUART1_RAWMSG 0501003437A4106BA7DF272DDE0601000038
HmUART1_RSSI -52
HmUART1_TIME 2020-07-19 19:05:18
HmUART2_MSGCNT 36
HmUART2_RAWMSG 0500004637A4106BA7DF272DDE0601000038
HmUART2_RSSI -70
HmUART2_TIME 2020-07-19 19:05:18
IODev HmUART1
LASTInputDev HmUART1
MSGCNT 75
NAME HG_DB_Dimmer
NOTIFYDEV global
NR 157007
STATE MISSING ACK
TYPE CUL_HM
chanNo 01
lastMsg No:37 - t:10 s:6BA7DF d:272DDE 0601000038
protCmdDel 17
protLastRcv 2020-07-19 19:05:18
protRcv 40 last_at:2020-07-19 19:05:18
protResnd 48 last_at:2020-07-19 20:23:13
protResndFail 16 last_at:2020-07-19 20:23:20
protSnd 76 last_at:2020-07-19 20:23:00
protState CMDs_done_Errors:1
rssi_HmUART1 cnt:30 min:-58 max:-52 avg:-54.66 lst:-56
rssi_HmUART2 cnt:1 min:-92 max:-92 avg:-92 lst:-92
rssi_at_HmUART1 cnt:40 min:-61 max:-49 avg:-52.02 lst:-52
rssi_at_HmUART2 cnt:36 min:-92 max:-70 avg:-74.88 lst:-70
READINGS:
2020-07-19 12:00:56 CommandAccepted yes
2020-07-18 11:23:19 D-firmware 2.3
2020-07-18 11:23:19 D-serialNr PEQ1913799
2020-07-18 11:23:19 R-pairCentral set_0x272DDE
2020-07-19 19:05:18 deviceMsg off (to VCCU)
2020-07-19 19:05:18 dim stop:off
2020-07-19 19:05:18 level 0
2020-07-19 19:05:18 loadFail off
2020-07-19 19:05:18 pct 0
2020-07-19 19:05:18 recentStateType info
2020-07-19 20:23:20 state MISSING ACK
2020-07-19 19:05:18 timedOn off
helper:
HM_CMDNR 59
cSnd 11272DDE6BA7DF0201C80000,01272DDE6BA7DF010E
dlvl C8
dlvlCmd ++A011272DDE6BA7DF0201C80000
mId 0012
peerFriend peerSens,peerVirt
peerOpt 3:dimmer
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
ack:
dir:
cur stop
rct down
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +6BA7DF,00,01,00
nextSend 1595178319.05332
prefIO
rxt 0
vccu VCCU
p:
6BA7DF
00
01
00
mRssi:
mNo 37
io:
HmUART1:
-46
-46
HmUART2:
-70
-70
HmUART3:
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
prs 1
rpt:
IO HmUART2
flg A
ts 1595178318.67419
ack:
HASH(0x11f50620)
378002272DDE6BA7DF00
rssi:
HmUART1:
avg -54.6666666666667
cnt 30
lst -56
max -52
min -58
HmUART2:
avg -92
cnt 1
lst -92
max -92
min -92
at_HmUART1:
avg -52.025
cnt 40
lst -52
max -49
min -61
at_HmUART2:
avg -74.8888888888889
cnt 36
lst -70
max -70
min -92
shadowReg:
RegL_00. 02:01 0A:27 0B:2D 0C:DE
tmpl:
Attributes:
IODev HmUART1
IOgrp VCCU
alias Dachbodenlüfter
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.3
model HM-LC-DIM1L-CV
room CUL_HM
serialNr PEQ1913799
subType dimmer
webCmd statusRequest:toggle:on:off:up:down
... gerade gesehen: steht jetzt auf " R-pairCentral set_0x272DDE"
Der war aber schon richtig gepairt und trotzdem "missing ack" gemacht.
so, nochmal angelernt, jetzt ist er gepairt. Neues List (jetzt aber ohne state missing ack, momentan funktionierts auch):
Internals:
CFGFN
DEF 6BA7DF
FUUID 5f12bf86-f33f-af18-1e11-34202e16d7b86e2b
HmUART1_MSGCNT 56
HmUART1_RAWMSG 0501003370A4106BA7DF272DDE06010000
HmUART1_RSSI -51
HmUART1_TIME 2020-07-19 21:01:15
HmUART2_MSGCNT 53
HmUART2_RAWMSG 0500004B70A4106BA7DF272DDE06010000
HmUART2_RSSI -75
HmUART2_TIME 2020-07-19 21:01:14
IODev HmUART1
LASTInputDev HmUART1
MSGCNT 109
NAME HG_DB_Dimmer
NOTIFYDEV global
NR 157007
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:70 - t:10 s:6BA7DF d:272DDE 06010000
protCmdDel 17
protLastRcv 2020-07-19 21:01:14
protRcv 57 last_at:2020-07-19 21:01:14
protResnd 48 last_at:2020-07-19 20:23:13
protResndFail 16 last_at:2020-07-19 20:23:20
protSnd 99 last_at:2020-07-19 21:01:14
protState CMDs_done
rssi_HmUART1 cnt:32 min:-61 max:-52 avg:-54.81 lst:-53
rssi_HmUART2 cnt:1 min:-92 max:-92 avg:-92 lst:-92
rssi_at_HmUART1 cnt:57 min:-64 max:-49 avg:-52.94 lst:-51
rssi_at_HmUART2 cnt:53 min:-92 max:-70 avg:-74.71 lst:-75
READINGS:
2020-07-19 21:01:06 CommandAccepted yes
2020-07-19 21:00:59 D-firmware 2.3
2020-07-19 21:00:59 D-serialNr PEQ1913799
2020-07-19 21:01:10 PairedTo 0x272DDE
2020-07-19 21:01:04 R-loadAppearBehav off
2020-07-19 21:01:04 R-pairCentral 0x272DDE
2020-07-19 21:01:04 R-powerUpAction off
2020-07-19 21:01:10 RegL_00. 00:00 02:01 0A:27 0B:2D 0C:DE 15:FF 16:00
2020-07-19 21:01:10 RegL_01. 00:00 12:01 30:06 31:00 56:00 57:24
2020-07-19 21:01:14 deviceMsg off (to VCCU)
2020-07-19 21:01:14 dim stop:off
2020-07-19 21:01:14 level 0
2020-07-19 21:01:14 loadFail off
2020-07-19 21:01:14 pct 0
2020-07-19 21:01:14 recentStateType info
2020-07-19 21:01:14 state off
2020-07-19 21:01:14 timedOn off
helper:
HM_CMDNR 112
cSnd 01272DDE6BA7DF01040000000001,01272DDE6BA7DF0103
mId 0012
peerFriend peerSens,peerVirt
peerIDsRaw ,00000000
peerOpt 3:dimmer
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
ack:
dir:
cur stop
rct down
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +6BA7DF,00,01,00
nextSend 1595185275.2907
prefIO
rxt 0
vccu VCCU
p:
6BA7DF
00
01
00
mRssi:
mNo 70
io:
HmUART1:
-45
-45
HmUART2:
-75
-75
HmUART3:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
prs 1
rpt:
IO HmUART2
flg A
ts 1595185274.90667
ack:
HASH(0x11f50620)
708002272DDE6BA7DF00
rssi:
HmUART1:
avg -54.8125
cnt 32
lst -53
max -52
min -61
HmUART2:
avg -92
cnt 1
lst -92
max -92
min -92
at_HmUART1:
avg -52.9473684210526
cnt 57
lst -51
max -49
min -64
at_HmUART2:
avg -74.7169811320755
cnt 53
lst -75
max -70
min -92
shadowReg:
tmpl:
Attributes:
IODev HmUART1
IOgrp VCCU:HmUART1
alias Dachbodenlüfter
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.3
model HM-LC-DIM1L-CV
peerIDs 00000000,
room CUL_HM
serialNr PEQ1913799
subType dimmer
webCmd statusRequest:toggle:on:off:up:down
ist deine steuerung eventuell "murks", weil sie den aktor zu häufig schaltet?
zb keine hysterese.
der aktor und/oder das io gehen deswegen dann in overload?
nach einem reset hat der aktor dann wieder volle credits und läuft wieder einige zeit.
eigentlich ist doch das Stundenlimit das Schädliche, oder? Nach einer Stunde sollte doch eine "Selbstheilung" eintreten und der Aktor dann wieder funktionieren - wenn es daran liegt.
btw: wo ist eigentlich die Möglichkeit, den loadLvl eines Aktors abzuschätzen? Ich kenne das nur von HM-Ios.
Und ein List von der Regelroutine wäre auch toll.
bei der ermittlung der credits werden immer alle sendungen der letzten stunde betrachtet (fifo; first in, first out).
wenn zb zyklisch gesendet wird, fällt immer die älteste sendung raus und die neuste kommt wieder für ein stunde in den fifo speicher.
dabei reicht es dann auch aus, dass im schnitt eine sendung zu viel pro stunde gesendet wird. ab und zu wird mal eine gesendet, kurze zeit später ist das limit wieder erreicht.
bei einer angenommenen 2-punkt-regelung braucht zb nur der messwert um den sollwert toggeln, um ständige cmds zu senden.
der energy-mess-aktor blinkt zb bei overload.
bei hmccu devices habe ich auch schon "duty"-datenpunkte gesichtet, denke ich. habe aber keine ahnung, ob da infos kommen.
Duty cycle muß ich mir mal ankucken, hatte ich noch nicht. Es ist schon passiert, daß bei Luftfeuchte-Änderung an der Schaltgrenze getoggelt wird, das werde ich noch ändern, dass nur innerhalb bestimmter Ranges geschaltet wird. Ich habe aber das notify derzeit "inaktiv" geschaltet. Der Aktor geht auch bei manuellem Tests - die den duty cycle nicht ausreizen - trotzdem auf missing ack. Heute ist er allerdings noch ansprechbar, nach dem letzten Neu-Anlernen gestern.
Ich beobachte weiter....
Ich denke aber - wie Pfriemler schon meinte - daß er - wenns am duty cycle liegt, wieder gehen sollte, wenn die Sperrzeit um ist.
Gruß Roland
Zur Zeit scheint der Dimmer zu funktionieren, vielleicht hat das letzte Neuanlernen geholfen. Die notify-Automatik ist noch aus, weil der Lüfter noch nicht installiert ist.
Ich habe mir nochmal Gedanken zum Thema Hysterese gemacht. Ob die Speed-Werte zur jeweiligen Luftfeuchte praxistauglich sind, muß sich erst noch herausstellen.
Ich kann abfangen, daß nur geschaltet wird, wenn sich die Wunsch-Speed von der aktuellen speed unterscheidet. Ich habe aber keine Idee, wie ich abfangen soll, wenn die Luftfeuchte z.B. zwischen 66/67 oder 70/71 schwankt. Das kann schon mal häufig passieren, bis der neue Wert aus dem Bereich raus ist. Ein "on-for-timer-pct" geht ja nicht und das reading timedOn kann man nicht manuell setzen (oder?). Ich habe auf dem Temp/Humi-Sensor
event-min-interval state:600,temperature:600,humidity:600,battery:3600
event-on-change-reading .*
event-on-update-reading temperature,humidity
weil die Sensoren ziemlich geschwätzig sind. Wahrscheinlich kann ich das nur regeln, wenn ich das "event-on-update-reading humidity" und "event-on-change-reading" entferne. Ansonsten müßte ich wohl die Schaltzeit in einen Dummy schreiben und die Zeitdifferenz im notify auswerten. Elegant ist das aber auch nicht. Vielleicht hat jemand eine bessere Idee.
sub FanSpeed($)
{
my $CurrSpeed = ReadingsVal("HG_DB_Dimmer","pct","");
my ($Humi) = @_;
my %Speeds = ( 60 => 0,
61 => 40,
62 => 40,
63 => 40,
64 => 50,
65 => 50,
66 => 50,
67 => 60,
68 => 60,
69 => 60,
70 => 60,
71 => 70,
72 => 70,
73 => 70,
74 => 80,
75 => 80,
76 => 80,
77 => 90,
78 => 90,
79 => 90,
80 => 100);
my $Speed = $Speeds{$Humi};
if ($Humi < 60) { $Speed = 0; fhem ("set HG_DB_Dimmer pct 0"); }
elsif (($Humi > 60 && $Humi <= 80) && ($CurrSpeed != $Speed)) { fhem ("set HG_DB_Dimmer on-for-timer 10;sleep 5;set HG_DB_Dimmer pct $Speed"); }
elsif ($Humi > 80) { $Speed = 100; fhem ("set HG_DB_Dimmer pct 100"); }
Log3 undef,1,"Fan Speed bei $Humi% Luftfeuchte auf $Speed% gesetzt.";
}
Gruß Roland
Zitat von: hauwech am 21 Juli 2020, 08:44:39
Ich kann abfangen, daß nur geschaltet wird, wenn sich die Wunsch-Speed von der aktuellen speed unterscheidet. Ich habe aber keine Idee, wie ich abfangen soll, wenn die Luftfeuchte z.B. zwischen 66/67 oder 70/71 schwankt. Das kann schon mal häufig passieren, bis der neue Wert aus dem Bereich raus ist.
Schon mal an das Modul Threshold gedacht?
https://fhem.de/commandref_DE.html#THRESHOLD (https://fhem.de/commandref_DE.html#THRESHOLD)
Damit steuere ich meinen Lüfter inkl. Hysterese in der Waschküche.
Norbert
... ist mir noch nicht über den Weg gelaufen, das muß ich mir mal ankucken, danke.
Hi,
ich halte die Kombination für doppelt gemoppelt:
event-on-change-reading .*
event-on-update-reading temperature,humidity
ZitatDie unterschiedlichen Bedeutungen von event-on-update-reading und event-on-change-reading sind folgende:
Wenn beide Attribute nicht gesetzt sind erzeugt jede Aktualisierung eines jeden "readings" eines Gerätes ein Ereignis.
Wenn eines der Attribute gesetzt ist, erzeugen nur Updates oder änderungen von "readings" die in einem der Attribute gesetzt sind ein Ereignis.
Wenn ein "reading" in event-on-update-reading aufgeführt ist, erzeugt eine Aktualisierung ein Ereignis unabhängig ob das "reading" auch in event-on-change-reading aufgelistet ist.
event-on-change-reading .*ist die sinnvolle Wahl bei allen HM Geräten.
Gruß Otto
Zitat von: Otto123 am 21 Juli 2020, 09:26:08
event-on-change-reading .*ist die sinnvolle Wahl bei allen HM Geräten.
Moin zusammen,
auch wenn martinp876 das auch immer so in den Raum stellt, bin ich - im Nachgang zu einigen Diskussionen mit Rudi zu dem Thema - nicht so ganz überzeugt, dass das korrekt ist und meine, dass die von hauwech gewählte Variante durchaus ihre Berechtigung hat, jedenfalls, wenn man das ganze loggen will.
In dem Zusammenhang (da ich das auch lange nicht wahrgenommen hatte, und es ggf. anderen genauso geht): Es gibt seit einiger Zeit auch noch "timestamp-on-change-reading"; jedenfalls für Schaltzustände (on/off/level/pct) kann das ggf. auch Sinn machen...
Die Temp/Humi Sensoren sind Technoline TX29DTH-IT. Die feuern per default - glaube ich - alle 3 Sek die Werte. Wenn man sie nicht bändigt, fluten sie das Log ruckzuck. Ich stelle den jetzt mal auf
event-on-update-reading temperature
Wenn ich das richtig überschaue, kommt dann mit event-min-interval state:600,temperature:600,humidity:600,battery:3600 von der Luftfeuchte nur noch alle 10 Minuten ein event, damit sollte das flapping vorbei sein.
Gruß Roland
das glaube ich nicht. ;)
schau auf den eventmonitor, da "siehst" du die events.
ich behaupte mal, du bekommst nur noch "temperature" bei jedem update.
Hmmm, also irgendwie kam mir event-on-change-reading naheliegender vor als -on-update, ggf. mit der Angabe einer Hysterese (und natürlich min-interval).
Trotzdem macht es mMn. Sinn, auch bei den Schaltvorgängen dann nochmal eine Hysterese einzubauen, THRESHOLD kann da gute Dienste leisten.
(Irgendwie hat das jetzt aber alles nur noch sehr lose was mit dem Thread-Titel zu tun...)
Zitat von: Beta-User am 21 Juli 2020, 13:33:15
(Irgendwie hat das jetzt aber alles nur noch sehr lose was mit dem Thread-Titel zu tun...)
Du hast Recht, ich habe den Titel mal geändert, das Thema ist verrutscht.
Zumal der Dimmer derzeit keinen missing ack mehr macht. Er hat wohl mehrere Anlernvorgänge gebraucht.
Die Events muß ich heute mal beobachten, hatte gestern keine Zeit.
Gruß Roland
Zitat von: frank am 21 Juli 2020, 13:31:04
das glaube ich nicht. ;)
schau auf den eventmonitor, da "siehst" du die events.
ich behaupte mal, du bekommst nur noch "temperature" bei jedem update.
Du hast Recht, mit
event-on-update-reading temperature kommt nur noch temperature.
Ich lese derweil mal den treshold thread.
Gruß Roland
Ich habe zwar noch nicht alles im treshold thread gelesen, aber was ich bisher verstanden habe: wenn ich 7 Schaltschwellen definieren will, brauche ich auch 7 treshold Devices. Ich möchte halt den Lüfter nicht nur Ein/Aus steuern, weil der auf 100% Drehzahl deutlich vernehmbar laut wird. Aus eben diesem Grund habe ich mich für einen Dimmer anstatt eines Schalters entschieden. Mit 50% Drehzahl fördert er auch schon ordentlich Luft, aber deutlich leiser. Wenn ich also das flapping um die Schaltschwellen herum unterbinden möchte, werde ich wohl um einen Schaltzeit-dummy nicht herum kommen. Ich wollte mich um das Zeit-Handling mit Perl drücken. Eine sub-Routine in myUtils ist dann doch übersichtlicher als mehrere Definitionen für die gleiche Aktion, die sich nur in den Parametern unterscheidet.
Aber genau an solchen Stellen freue ich mich immer, daß ich mich damals für fhem entschieden habe: Es gibt immer einen Weg. Man könnte ja sogar die treshold-Sollwerte in der subroutine entsprechend setzen ;D.
Gruß Roland
Hmm, ja, vermutlich ist THRESHOLD nicht das Mittel der Wahl, wenn es um was substantiell anderes geht wie ein/aus.
Da sich vermutlich der Luftfeuchtigkeitswert nicht sprunghaft ändert und das Zieldevice sich auch rein nummerisch schalten lassen sollte (dim 0=aus), werfe ich mal ungeprüft noch das Stichwort PID20 in den Raum. Das scheint lt. Wiki und Commandref zwar eigentlich für die Steuerung von Temperaturen gedacht zu sein, aber auf die Schnelle sehe ich keinen Grund, warum das nicht auch für Luftfeuchtigkeit/Entlüftung gehen sollte. Besonders interessant ist die Option, Vor- und Nachberechnungen durchzuführen (siehe die Codeschnipsel am Ende der Attributbeschreibung in https://fhem.de/commandref_modular.html#PID20)
ZitatEr hat wohl mehrere Anlernvorgänge gebraucht.
das ist natürlich "quatsch". ;)
beim anlernen wird die 6-stellige hmid der zentrale im eeprom gespeichert. wenn das funktioniert hat,
kann diese zentrale den aktor "steuern".
das hat ja mehr als prächtig funktioniert.
deine letzten ausführungen haben meine overload-theorie noch bekräftigt.
wenn die steuerung mit einem update-interval von 3s anfängt zu toggeln, dann gute nacht.
setze unbedingt attr event-on-change. am besten eine liste mit den readings, die du wirklich brauchst, dann bleiben die nicht genannten readings still.
ein zusätzliches attr event-min für ausgewählte readings der ersten on-change-liste, kann dann wieder ein paar events mehr für diese readings zulassen, damit das minimum-interval eingehalten wird.
also erst drastisch reduzieren (on-change), danach eventuell moderat erhöhen (min-interval). für deine regelung würde ich das nicht erhöhen.
event-on-update brauchst du
nur, wenn trotzdem ein reading unbedingt bei jedem update (3s) feuern soll.
hoffentlich feuern in deinem system nicht noch weitere sensoren derart häufig.
edit: hysterese oder andere begrenzungen würde ich direkt ins notify einbauen.
oder, wie beta-user schreibt, nur mit pid20 probieren.
Die "event-on-" Attribute habe ich natürlich gesetzt, siehe Beitrag #7: https://forum.fhem.de/index.php/topic,113001.msg1073505.html#msg1073505 (https://forum.fhem.de/index.php/topic,113001.msg1073505.html#msg1073505).
Zitathoffentlich feuern in deinem system nicht noch weitere sensoren derart häufig.
Nein, ich habe alle gebändigt, die event-on-change-reading .* Empfehlung habe ich bei den devices, wo es Sinn macht umgesetzt.
Ich bekomme von den Temp/Humi-Sensoren im Normalfall alle 10 Minuten wie gewünscht ein event. Nur wenn die Luftfeuchte zwischen zwei Werten toggelt, sind es mehr (wegen event-on-change-reading .*). Das wird auch ein nicht vorhandenes "event-on-update-reading temperature,humidity" nicht ändern, oder?
PID20 klingt interessant, wieder was gelernt. Das werde ich mir auf jeden Fall anschauen. Derweil habe ich mir einen timestamp-dummy angelegt und schalte nur, wenn z.B. 20 Minuten vergangen sind.
Gruß Roland
Du kannst auch in event-on-change direkt eine Hysterese einbauen. Das würde ich hier auch empfehlen...
Tipp: das Attribut wird von links nach rechts abgearbeitet, es geht also auch sowas wie
humidity:2,.*
oder auch in ahängigkeit der regeldifferenz die steuerung unterbrechen => aktor off, oder ein anderer wert.
aber auch mit hysterese.
zb bei differenz kleiner 5 regelung stoppen.
aber erst bei einer höheren differenz von zb 10 wieder fortsetzen.
Zitat von: Beta-User am 22 Juli 2020, 10:55:49
Du kannst auch in event-on-change direkt eine Hysterese einbauen. Das würde ich hier auch empfehlen...
Tipp: das Attribut wird von links nach rechts abgearbeitet, es geht also auch sowas wie
humidity:2,.*
Das ist ja interessant, wieder was gelernt. Danke.
Gruß Roland
Ich habe mich übrigens zu früh gefreut, heute steht er wieder auf "missing ack". Das notify ist immer noch inaktiv, der Dimmer hat also über Nacht nur rumgelegen, ohne einmal zu schalten. In irgendeinem Beitrag zum Thema "missing ack" hatte ich gelesen, daß der user bei einem problematischen missing-ack-Device mit einem at regelmäßig einen statusRequest macht. Ich mache das seit einiger Zeit jede Stunde auf dem Dimmer, hier hilft es aber nicht. So werde ich das Teil jedenfalls nicht verbauen.
Ich habe ihn reklamiert, vielleicht hat der doch eine Firmware-Macke. Ich habe mir einen HM-LC-Dim1L-Pl-3 bestellt, mal sehen, ob der besser geht. Der HM-LC-Dim1L-CV ist bei ELV nicht mehr lieferbar, den gabs nur noch bei Pollin.
Gruß Roland
Als Ergänzung:
Heute sprang der Lüfter plötzlich scheinbar ohne ersichtlichen Grund mit 40% an, obwohl er bis dahin auf missing ack stand und das notify immer noch inaktiv ist. Ein Blick ins Log zeigt, daß das genau nach einem at-gesteuerten statusRequest passierte. (Der Log-Auszug stammt von meinem Logserver, da kann man besser suchen.)
23.07.20 13:56:09,000
Jul 23 13:56:09 xxx.xxx.xxx.xxx 1 2020-07-23T13:56:09+02:00 fhem-nuc.zero.local splunklog_fhem 16445 FHEM [version@Log2Syslog version="5.12.2"] 3: CUL_HM HG_DB_Dimmer repeat, level 00 instead of 50
eventtype = fhem-log
host = xxx.xxx.xxx.xxx
process = 3
source = udp:515
23.07.20 13:56:09,000
Jul 23 13:56:09 xxx.xxx.xxx.xxx 1 2020-07-23T13:56:09+02:00 fhem-nuc.zero.local splunklog_fhem 16444 FHEM [version@Log2Syslog version="5.12.2"] 3: CUL_HM set HG_DB_Dimmer statusRequest
eventtype = fhem-log
host = xxx.xxx.xxx.xxx
process = 3
source = udp:515
Die Meldung "HG_DB_Dimmer repeat, level 00 instead of 50" sagt mir aber nix.
Gruß Roland
HG_DB_Dimmer repeat, level 00 instead of 50
erscheint z.B. immer dann, wenn FHEM ein Schaltkommando absetzt, der Aktor aber einen anderen Zustand zurückmeldet. Das passiert insbesondere gern, wenn es eine Reihe unterschiedlicher Befehle in kurzer Frist gibt und die verzögerte Aktorrückmeldung nicht zum letzten Schaltbefehl passt.
Hier sieht es so aus, als ob ein Schaltbefehl von FHEM nicht zugestellt werden konnte (MISSING ACK) und FHEM diesen sofort wiederholt, sobald die Kommunikation wieder zu funktionieren scheint (was nach einem erfolgreichen statusRequest angenommen werden darf). Über die Zeitdauer, wie lange ein Befehl "aufbewahrt" und ggf. wiederholt werden darf bevor er verfällt, herrscht nach meiner Sicht seit langem ein Dissenz.
Ich schicke den HM-LC-DIM1L-CV jetzt zurück. Der Dimmer wird nach endgültiger Installation schlecht zugänglich sein, da möchte ich nicht das unzuverlässigste Device verbauen. Ich habe einen HM-LC-Dim1L-PI-3 (Zwischenstecker) geholt. Bis jetzt macht der keine Zicken - dreimal-auf-Holz-klopf.
Schalthysterese habe ich mit einem timestamp dummy gebaut.
Gruß Roland
Vielleicht war da wirklich irgendwie der Wurm drin bei dem Ding. Wenn der Zwischenstecker es tut, ist das ja in der Regel auch eine gute Lösung. Ich habe sogar einen Dim1T-PL auf meinen Selbstbau-LED-Panelen im Wohnzimmer im Einsatz (statt bspw. des HM-LC-Dim1T-FM) - solange das kein Mensch sieht ...
Der Zwischenstecker läuft ohne Probleme, daher konnte ich mich eingehender mit dem eigentlichen Problem der Lüftung, dewpoint, Luftfeuchte & Co. befassen. Dabei ist herausgekommen, daß ich meine bisher ausgedachte Lüftungslogik auf den Kopf stelle. Nach Herumstöbern hier im Forum bin ich zu der Erkenntnis gelangt, daß man die Lüftung nicht an der lokalen relativen Luftfeuchte festmacht. Ein coole Idee habe ich hier: https://forum.fhem.de/index.php/topic,70706.msg1014080.html#msg1014080 (https://forum.fhem.de/index.php/topic,70706.msg1014080.html#msg1014080) gefunden. Die absolute Feuchte hat mir die Augen geöffnet. Ich habe auf die absolute Feuchte aller Temp/Humi Sensoren eine Plot gebaut. Dort habe ich gaaaanz deutlich gesehen, daß sich der Dachboden tagsüber deutlich aufheizt. Die relative Luftfeuchte bleibt im Tagesverlauf niedrig, aber die absolute Feuchte steigt auf Grund der höheren Temperatur unterm Dach deutlich über den Schnitt aller anderen Sensoren.
Ich werde nun die Lüftersteuerung an die Differenz der absoluten Feuchte Innen/Aussen hängen.
Gruß Roland
Mach dir wegen dem "Missing Ack" mal einen Trend für die RSSI- Werte! Für HM bekommt man zyklische Werte (falls das entspr. Gerät nicht selbst zyklisch sendet) indem in einem zyklischen at ein "get config" auf das Gerät geschickt wird. Es reichen so 10 Min. als Intervall.
Ich habe gestaunt wie sprunghaft manche Verbindungen sind, wenn die Antennenausrichtung nicht optimal ist: Mal um die -50 was perfekt wäre, aber dann auch über -90 was "Missing Ack"s en gros liefert. Ich habe wegen meiner HM- Beregnungsanlage solch einen Trend ständig mitlaufen. Seit der Antennenoptimierung (Groundplane am HM- Stick, Draht ausgerichtet am Aktor) muss ich dort kaum noch draufgucken.
Gruß
Frank
mach besser einen regelmässigen statusrequest.
das reduziert den traffic ggf deutlich.
Das mit dem RSSI Plot ist 'ne gute Idee, ich werde die Werte mal ins dblog mit aufnehmen.
Den zickigen Zwischendecken-Dimmer habe ich zurückgeschickt. Der Zwischenschalter-Dimmer, den ich jetzt habe, macht an den gleichen räumlichen Positionen gar keine Missing acks bis jetzt - nochmal dreimal-auf-Holz-klopf.
Gruß Roland