HM-LC-DIM1L-CV - Schalthysterese mit Luftfeuchtesensor

[hauwech]

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

Code Auswählen Erweitern

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

[hauwech]

... gerade gesehen: steht jetzt auf " R-pairCentral   set_0x272DDE"
Der war aber schon richtig gepairt und trotzdem "missing ack" gemacht.

[hauwech]

so, nochmal angelernt, jetzt ist er gepairt. Neues List (jetzt aber ohne state missing ack, momentan funktionierts auch):

Code Auswählen Erweitern

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

[frank]

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.

[Pfriemler]

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.

[frank]

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.

[hauwech]

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

[hauwech]

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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

[Nobbynews]

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
Damit steuere ich meinen Lüfter inkl. Hysterese in der Waschküche.

Norbert

[hauwech]

... ist mir noch nicht über den Weg gelaufen, das muß ich mir mal ankucken, danke.

[Otto123]

Hi,

ich halte die Kombination für doppelt gemoppelt:
event-on-change-reading .*
event-on-update-reading temperature,humidity

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

Code Auswählen Erweitern

event-on-change-reading .*ist die sinnvolle Wahl bei allen HM Geräten.

Gruß Otto

[Beta-User]

Code Auswählen Erweitern

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

[hauwech]

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

Code Auswählen Erweitern

event-on-update-reading temperature
Wenn ich das richtig überschaue, kommt dann mit

Code Auswählen Erweitern

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

[frank]

das glaube ich nicht. 
schau auf den eventmonitor, da "siehst" du die events.

ich behaupte mal, du bekommst nur noch "temperature" bei jedem update.

[Beta-User]

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