HM-WDS30-OT2-SM

[VolkerW]

Hallo,
ich bin erst kürzlich in das Thema FHEM eingestiegen und habe zur Zeit den Differenztemperatursender HM-WDS30-OT2-SM in Bearbeitung.
Er ist bereits in mein System integriert und generiert reichlich Events.
Ich versuche mit dem Attribut "event on change reading" die Meldeflut in den Griff zu bekommen (mit wenig Erfolg).
So wie ich das sehe erkennt Fhem bereits einen Change, wenn sich die Sensortemperatur nur um +/-0,1°C ändert, was vielleicht alle 2 min der Fall ist.
Gibt es eine Möglichkeit diese Ansprechschwelle individuell beispielsweise auf +/- 1°C einzustellen? Das würde die Anzahl der Events deutlich reduzieren.

[Groby]

Hallo,

versuche es doch zusätzlich mal mit dem Attribut "event-min-interval"...

MfGroby

[martinp876]

Ist die Frage, ob "event-min-interval" das Problem löst - es wird dann faktisch immern nach dieser Zeit der trigger ausgelöst.
Eine Hystherese für trigger könnte schon sinn machen...
Die Readings sollten immer upgedated werden nur der trigger soll nicht erfolgen?

[VolkerW]

Das die Readings aktualisiert werden ist vollkommen in Ordnung und wünschenswert.
Der Trigger soll aber erst auslösen und ein Event erzeugen, wenn sich die Temperatur signifikant verändert hat (+/- 1° oder auch +/- 2°, möglichst per Parameter einstellbar).
Ich betreibe Fhem auf einer Synology DS212J. Die soll wenigstens Nachts in den Ruhezustand gehen.
Obwohl ich bereits alle Log-files auf einen USB-Stick ausgelagert habe, sorgt doch jedes Event dafür, das der Ruhezustand meiner NAS verhindert wird (warum auch immer).
Ich möchte von meinen Temperatursensor nur die Differenztemperatur nutzen (für die Beschattung meines Wintergartens).
Nachts wird die Temperaturdifferenz irgendwo um die 0° schwanken.  Schon bei einer Ansprechschwelle (Hysterese)von +/- 1° wird Nachts kein Event erzeugt und meine NAS kann "ruhig schlafen".

[martinp876]

ok- ich denke es verstanden zu haben.
Leider gibt es keine möglichkeit trigger zu unterdrücken... also "no-event-on-reading".

Du kannst aber einmal threashold ansehen. Das könnte dir vielleicht helfen.

[VolkerW]

So wie ich das verstanden habe funktioniert das attribut "event on change reading" gut, wenn das reading binär ist (also die Stati on und off hat).
Beispiel Türkontakt: Der Türkontakt meldet 10 mal hintereinander "auf" und es wird kein event erzeugt. Erst wenn er beim 11 mal "zu",  meldet wird der event erzeugt.
Beispiel Temperatur: Der Sensor meldet "10,1", "10,0", "10,1" und so weiter. Es wird trotz "event on change reading" jedesmal ein event erzeugt obwohl sich die Temp. nicht geändert hat.
Sobald das reading quasi einen analogen Wert darstellt wäre eine parametrierbare Ansprechschwelle oder Totzone (oder wie immer man das nennen will) schon hilfreich.

[martinp876]

event-on-change-reading vergleicht strings - keine Werte. Es ist eine generelle FHEM-Funktion und nicht änderbar.

Sobald das reading quasi einen analogen Wert darstellt

nun, wir sind immer digital.

Threshold sollte so etwas machen, was du suchst.

Du kannst also
- den messwert nicht loggen lassen. Werfe ihn aus allen logfiles, das hast du in der hand => kein loggen, kein "aufwachen"
- baue ein threshold, der dir ein Reading deiner wahl setzt oder logt

das muss auf jeden Fall funktionieren.

Die Alternative wäre, das sich in CUL_HM ein attribut vorsehe, mit dem die Hystherese eingebaut wird. Ist ein ziemlicher Aufwand und kostet processing time. Daher zögere ich, da es mir kein "allgemeines" feature darstellt.

Versuche einmal die vorhandenen Optionen
Gruss Martin

[VolkerW]

Hallo Martin,

ersteinmal vielen Dank für Deine Unterstützung.
Das mit Threshold funktioniert.
Es funktionier aber leider nur, wenn ich die Events meines Sonnensensor nicht unterdrücke. (Damit bin ich wieder am Anfang).

Zum Test habe ich folgende einfache Schaltung aufgebaut:

define Sonnensensor_T1_T2 CUL_HM 24855B03
attr Sonnensensor_T1_T2 event-on-update-reading 1
attr Sonnensensor_T1_T2 expert 1
attr Sonnensensor_T1_T2 model HM-WDS30-OT2-SM
attr Sonnensensor_T1_T2 peerIDs 00000000,
attr Sonnensensor_T1_T2 verbose 0

Die 2. Zeile (event on update reading) verhindert sicher, das der Sonnensensor ein Event erzeugt.
Nur wenn ich diese Zeile entferne, setzt das Threshold den dummy "Beschattung" auf "ein", wenn der Sollwert erreicht ist.

define Roll_down THRESHOLD Sonnensensor_T1_T2:temperature.* |set Beschattung ein||
attr Roll_down state_format _m _dv

Gibt es eine andere Möglichkeit, das Loggen der Temperaturwerte zu unterdrücken, ohne das Attribut "event on update reading" vergewaltigen zu müssen?

Gruß, Volker

[martinp876]

Hallo Volker,

Die 2. Zeile (event on update reading) verhindert sicher, das der Sonnensensor ein Event erzeugt.

cool - damit kann man ja alle trigger abschalten - hatte ich nicht gewusst.
is it a bug or a feature? or is the a bug a feature?

Nun, wenn du aber alles abschalten kannst dann solltest du ein user-reading einbauen können mit dem du deinen Threshold realisieren kannst. Entweder über threshold oder gleich selbst machen. Das userReadigns werden nach jedem Ändern eines Wertes ausgeführt - sollte vom trigger unabhängig sein

Gruss Martin

[VolkerW]

Hallo Martin,

Danke für Antwort. Ich werde das Userreading ausprobieren und mich melden, wenn ich erfolgreich war.

Auch wenn es vielleicht langsam nervig wird, möchte ich noch einen Vorschlag unterbreiten.
Du hast geschrieben, dass es ziemlich aufwendig ist und Prozessorzeit kostet, meinen ursprünglichen Vorschlag (Einführung eines Deadbands für quasi analoge Werte) umzusetzen.

Ich kann mir folgende Realisierung vorstellen, die aus meiner zugegebenermaßen eingeschränkten Sichtweise (Ich hab keine Ahnung wie die Fhem-Software intern aufgebaut ist) nicht aufwendig ist und wenig Prozessorzeit kosten.

1. Punkt:
Einführung eines Attributs Deadband -> Deadband = 1 würde bedeuten, das der Ansprechwert für eine signifikante Temperaturänderung 1°C ist.
Dieses Attribut arbeitet zusammen mit dem Attribut "event on change reading"
Wenn das Attribut Deadband nicht ausgewählt wurde, verhält sich "event on change reading" wie bisher.
Wenn das neue Attribut ausgewählt wurde, soll folgendes passieren:

2. Punkt:
Es wird einmalig eine Variable "Altwert" generiert, die mit dem Wert 0 initialisiert wird.
In Perl-Code: my $altwert = 0;

3. Punkt:
Jedes reading, das vom Sensor gesendet wird und mit mit dem Attribut "event on change reading" ausgewählt wurde, wird in einer Variable Neuwert zwischengespeichert (wie immer das geht).
Daraufhin wird folgender Perl Code ausgeführt:

if (abs($neuwert - $altwert) >= $deadband) {
$altwert = $neuwert;
(trigger setzen, event  erzeugen, Wert loggen, wie immer das geht);
}

Ich will damit sagen, das immer nur, wenn diese Bedingung erfüllt ist, ein reading an den Anwender übergeben wird.
Alle anderen Readings sollen unterdrückt werden.
Wichtig dabei ist, dass der Altwert mit dem Neuwert aktualisiert wird, wenn die Bedingung erfüllt ist also das Deadband überschritten ist.
Dies führt zu deutlich weniger Events und zu einem ruhigem Temperaturverlauf. Die Wirkung ist einem Tiefpassfilter ähnlich.

Ob die Umsetzung loht und vom Aufwand her machbar ist, musst Du entscheiden.
Ich würde mich freuen, wenn es realisiert wird.

Gruß, Volker

[martinp876]

Hallo Volker,

wie man eine Hysterese baut ist mir schon klar.
Wenn ich eine baue ist es nicht nur für dich - es kommt in den allgemeinen Teil. Das erste einmal, dass es nicht auf temperaturen beschränkt sein kann - den gleich kommt der nächste mir einem Problem anderer Readings (humidity, sonnen-sensor, hellgkeit). man muss also bestimmen können: welche Attribute und welchen Hysterese für diesen Wert.
Diese Prüfung muss bei jedem durchgeführt werden: ist das attribut gesetzt? Für welche Readings? Ist der level überschritten.

Event-on-change-reading ist einen level höher eingebaut - das ist nicht HM, das ist FHEM-central. Falls Rudi dies einbauen will habe ich natürlich kein Problem - musst du aber dort einkippen und anfordern.

wenn du Probleme mit meinem Vorschlag hast, lass hören. Falls Rudi es allgemein einbaut ist es mir natürlich auch recht.

Gruss Martin

[VolkerW]

Hallo Martin,

ich war unterwegs und konnte mich erst jetzt mit Deinem Vorschlag bezüglich der userreadings beschäftigen.
Über userreading kann ich meine deadband Funktion realisieren. Damit komm ich erst mal weiter.
Also, vielen Dank für Deinen Vorschlag und für Deine Unterstützung.

Gruß, Volker