Hallo,
mit nachstehender Zeile habe ich "notify" definiert:
define HFehler notify HkVL:temperature.* { fhem("set FS20_WzK on") if ($defs{'HkVL'}{STATE} =~ m/.*Cool.*/) }
Der HkVL wurde zuvor definiert mit:
define HkVL OWTHERM DS18B20 2732F0010000
attr HkVL stateAH <span style="color:red">▴
attr HkVL stateAL <span style="color:red">▾
attr HkVL tempHigh 70
attr HkVL tempLow 28
Log geht, Alarmdreieck kommt - nur mein notify geht nicht.
Was ich noch fragen wollte:
Welchen Vorteil hat es den Grenzwert des Fühler auszuwerten gegenüber einer Grenzwertbildung aus dem Temperaturwert über Programmcode?
Grüße Klaus
IMHO müsste dann aber folgendes definiert sein:
attr HkVL stateAL (Cool)▾
Viele 1-Wire Devices bieten die Möglichkeit, bereits bei der Device-Suche auf dem Bus nur diejenigen zu berücksichtigen, die das Alarm-Flag gesetzt haben. Das ist in OWX noch nicht vollständig implementiert, es gibt aber bereits eine Routine OWX_Alarms in 00_OWX.pm (die natürlich nur bei USB-Interfaces funktioniert)
Wenn man das nutzt (wird kommen ...), lässt sich mit sehr viel weniger Aufwand herausfinden, wo ein Alarm vorliegt, als wenn jeweils erst die Messwerte geholt und mit Sollwerten verglichen werden.
So könnten man z.B. Temperaturwerte alle 5 Minuten abholen, aber alle 10 Sekunden einen Alarm Search durchführen. Na, und dann bei entsprechendem Alarm dieses Device in der Messfrequenz hochsetzen.
LG
pah
wird es so ein Alarm auch beim OWSWITCH geben?
Hi,
...dachte schon, das Hot bzw. Cool wären fhem Begriffe.
Den Code für die Auswertung des Alarms hab' ich im Forum gefunden und einfach abgeschrieben.
Offensichtlich ist es viel einfacher den Alarm auszuwerten!?
Die Dreiecke sind wohl Standard - ein explizites Attribut ist gar nicht erforderlich.
Wie müsste die einfachste Definition der <pattern> im notify aussehen um einen 1wire Alarm auszuwerten?
Danke
Gruß Klaus
Danke für die ausführliche Antwort zu (Alarm oder Grenzwert), das leuchtet ein.
Andererseits könnte ich mir vorstellen, dass es für die Betriebsamkeit auf dem 1-wire-Bus keinen großen Unterschied macht, ob man den Messwert oder nur den Alarm abfragt - Adressen usw. müssen ohnehin geschickt werden.
Die Zeitvorteile liegen eher im Rechner.
Der Vergleich des Messwertes mit einem Sollwert dürfte zum Alarm keinen großen Unterschied machen!?
Der Aufwand die Messwerte bei 10sec anstatt bei 300sec zu loggen ist natürlich ungleich höher.
Frage: Wie müsste der einfachste Vergleich eines Sollwertes mit einer 1wire-Messung in fhem lauten?
Danke
Gruß Klaus
Nun, matchen auf den event
2013-01-07 20:49:17 OWTHERM <devicename> temperature: 18.50 °C ▴
mit dem entsprechenden regulären Ausdruck
define notyfy <devicename>.*C.*; {Befehle ...}
Das letzte Semikolon kommt nur zur Wirkung, wenn das "Alarmzeichen" (Pfeil hoch oder runter) an den state angehängt wird.
Kann man auch noch unterscheiden zwischen high und low.
Außerdem noch ein Hinweis zur Geschwindigkeit: Die Alarmsuche auf dem 1-Wire Bus geht tatsächlich deutlich schneller, als die Abfrage diverser Messwerte.
LG
pah
Vorerst nicht.
Die einfachen Schalter DS2406 und DS2413 haben keine Alarmfunktionalität - aber der DS2408 hat die Möglichkeit, eine bedingte Suche durchzuführen - liefert dann nur etwas, wenn bestimmte Bits gesetzt sind. Das kann man zwar machen - hat aber m.E. geringe Priorität.
LG
pah
Puhhh...zu abstrakt für mich! Ich brauch' ein konkretes Beispiel.
Kannst du bitte nachstehende Definition ergänzen mit dem Vergleich in {}, wenn die gemessene Temperatur auf Unterschreiten von 28°C überwacht werden soll?
define HFehler notify HkVL"was müsste hier hin" { fhem("set FS20_WzK on") if ("was müsste hier rein") }
Danke
LG Klaus
Zitat von: Klaus schrieb am Di, 08 Januar 2013 11:52define HFehler notify HkVL"was müsste hier hin" { fhem("set FS20_WzK on") if ("was müsste hier rein") }
1. Attribut tempLow auf 28 setzen => Low Alarm bei 28 Grad Celsius
2. define HFehler notify HkVL.*C.*E; { fhem("set FS20_WzK on") }
Das "E;" sind die beiden letzten Zeichen des Strings ▾ = Unicode-Bezeichnung für "Pfeil nach unten"
Achtung: Das schaltet natürlich die Heizung nur EIN. Idealerweise setzt man einen zweiten Alarm mit tempHigh, sagen wir bei 30 Grad Celsius
define HFehler2 notify HkVL.*C.*4; { fhem("set FS20_WzK off") }
Das "4;" sind die beiden letzten Zeichen des Strings ▴ = Unicode-Bezeichnung für "Pfeil nach oben"
Dann wird die Temperatur immer zwischen diesen beiden Werten gehalten - ohne irgendeinen Zahlenvergleich im Programm
LG
pah
ich hab heute mal mit Alarms beim DS18B20 rumgespielt. An sich eine feine Sache allerding läuft das ganze nicht so autonom wie man es gerne hätte. Man muss man ja immer erst die A/D-konvertierung in allen Sensoren über den 1-Wire-bus triggern, damit die Alarme auch ausgewertet (und beim nächsten Alarms-search) berücksichtigt werden. Man spart also etwa die Hälfte der Kommunikationsvorgänge, wenn kein Sensor Alarm schlägt, und muss effektiv auch nur einmal die für eine A/D-konvertierung benötigte Zeit warten (weil alle Sensoren parallel wandeln können, wobei man das bei geschickter Implementierung auch so hinbekäme, allerdings müssten dafür die Trigger für die A/D-wandlung und für das spätere Auslesen Deviceübergreifend koordiniert werden).
Ich habe gleich mal Unterstützung für die Alarmsuche in die Arduino-Firmata firmware eingebaut (siehe: https://github.com/ntruchsess/arduino/commits/master (//github.com/ntruchsess/arduino/commits/master)). An einem Adapter zwischen dem OWX- und meinem FRM-modul arbeite ich gerade. Wenn das fertig ist, könnte man mit einem einzigen Arduino bis zu 54 parallele OneWire-Busse an FHEM andocken (mit Arduino Due oder Mega). Der Vorteil gegenüber den 'normalen' Adaptern ist halt, dass der Arduino das OneWire-protokoll auf dem Bus aktiv abwickelt, die Antworten kommen dann asynchron - FHEM kann derweil andere Dinge tun und muss z.B. nicht auf längerlaufende Searches auf dem OneWire-Bus warten. :-)
Zusätzlich ist es auch schon möglich z.B. die Trigger für die A/D-Wandlung und den anschließenden Alarm-search komplett auf dem Arduino zu schedulen, dann wartet das FRM-modul nur noch darauf, dass sich der Arduino mit einer Liste der Sensoren mit gesetztem Alarm-flag meldet. (Das skaliert auf den kleinen Arduinos mangels Speicher nicht besonders hoch, da gehen so 20 Sensoren, auf einem Due oder Mega ließen sich aber hunderte von Sensoren autonom auf Alarme monitoren).
Gruß,
Norbert
ach so: ein codebeispiel, wie kompakt so eine sich dynamisch anpassende Alarmsuche in perl aussehen kann liegt hier:
https://github.com/ntruchsess/perl-firmata/blob/master/examples/example-onewire-alarms.pl (//github.com/ntruchsess/perl-firmata/blob/master/examples/example-onewire-alarms.pl)
Ein gemeinsames Anstoßen der Konversion auf allen Sensoren ist in OWX bereits eingebaut. Das tatsächliche Verfolgen der Alarme allerdings erst rudimentär.
LG
pah
Hallo hab jetzt 10 DS1820 Wie kann ich jetzt die Alarme alle auf einmal Als E-Mail weitersenden?
define TempFehler notify Temp.*C.*4; { DebianMail('test@test.de','TempFehler','Temp');; }
? Kenn mich nicht mehr aus
Geuß Otto
Zitat von: otto am 09 August 2014, 15:53:57
Hallo hab jetzt 10 DS1820 Wie kann ich jetzt die Alarme alle auf einmal Als E-Mail weitersenden?
Beantwortet zwar nicht direkt Deine Frage, aber Ich schreib einfach mal das, was tatsächlich implementiert ist:
In OWX_ASYNC kann man ein notify auf das 'alarm'-reading (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/00_OWX_ASYNC.pm#L410) des OWTHERM-devices setzen. Das notify wird nur aufgerufen, wenn sich der alarm-Zustand tatsächlich ändert. Eine regelmäßige Alarm-search wird im nach der im Attribut 'interval' konfigurierten Zahl an Sekunden durchgeführt. Zusätzlich findet man alle aktuell als alarmed geführten Devices im Internal 'ALARMDEVS'.
In OWX ist das nicht implementiert. Da muss man eine Alarm-search mit 'get <owx> alarms' triggern. Anschließend findet man alle Alarmed-devices (so wie bei OWX_ASYNC) im Internal 'ALARMDEVS'. OWX beschreibt kein alarm-reading in den Devices, daher kann man darauf auch kein notify setzen.
Gruß,
Norbert