HM-LC-DIM1L-CV - Schalthysterese mit Luftfeuchtesensor

[hauwech]

(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

[hauwech]

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

Code Auswählen Erweitern

event-on-update-reading temperature kommt nur noch temperature.
Ich lese derweil mal den treshold thread.

Gruß Roland

[hauwech]

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 .

Gruß Roland

[Beta-User]

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)

[frank]

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

[hauwech]

Die "event-on-" Attribute habe ich natürlich gesetzt, siehe Beitrag #7: https://forum.fhem.de/index.php/topic,113001.msg1073505.html#msg1073505.

hoffentlich 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

[Beta-User]

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

Code Auswählen Erweitern

humidity:2,.*

[frank]

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.

[hauwech]

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

Code Auswählen Erweitern

humidity:2,.*

Das ist ja interessant, wieder was gelernt. Danke.

Gruß Roland

[hauwech]

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

[hauwech]

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

Code Auswählen Erweitern

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

[Pfriemler]

Code Auswählen Erweitern

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.

[hauwech]

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

[Pfriemler]

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

[hauwech]

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