Modul 98_monitoring zur Überwachung von Geräten

Begonnen von igami, 09 März 2017, 22:12:42

Vorheriges Thema - Nächstes Thema

octek0815

Zitat von: ToM_ToM am 05 Dezember 2017, 10:51:37
Hey, dein zweiter Regex ist nicht so ganz korrekt wenn du tatsächlich immer auf "Nicht 12.0" Grad reagieren möchtest.
Probier mal folgenes:

([1-9][1|3-9]?|[2][1-9])\.[0-9]$

VG, Thomas

Klappt auch nicht.

igami

#121
Habe es mit einem Dummy und folgender DEF erfolgreich getestet:

.*:desired-temp:.12 .*:desired-temp:.(?!12$).*
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

octek0815

Zitat von: igami am 10 Dezember 2017, 18:10:58
Habe es mit einem Dummy und folgender DEF erfolgreich getestet:

.*:desired-temp:.12 .*:desired-temp:.(?!12$).*

Das ist echt seltsam. Es funktioniert tatsächlich mit einem Test-Dummy, aber es reagiert nicht auf Homematic HM-CC-RT-DN bzw. HM-TC-IT-WM-W-EU

automatisierer

#123
hast du bei deinen HM-CC-RT-DN bzw. HM-TC-IT-WM-W-EU eventuell event-on-change-reading auf ein bestimmtes Reading gesetzt? so dass keine entsprechenden Events kommen?


EDIT:
.*:desired-temp:.12.* .*:desired-temp:.(?!12$).*

HT und WT senden:
desired-temp 12.0

igami

Zitat von: automatisierer am 10 Dezember 2017, 20:31:27
HT und WT senden:
desired-temp 12.0
Ohne Doppelpunkt?

Zeig mal bitte einen Auszug aus dem Eventmonitor.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

automatisierer

nein, mit :
Climate desired-temp: 20.5
sorry, den hab ich unterschlagen.

mir ging es um das .0 , welches hinter der 12 steht.

Dadurch triggert
desired-temp:.12
dann nicht.

igami

Ja, dann musst du nur noch .0 hinter der 12 ergänzen, dann sollte das funktionieren.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

octek0815

Zitat von: igami am 13 Dezember 2017, 09:09:00
Ja, dann musst du nur noch .0 hinter der 12 ergänzen, dann sollte das funktionieren.

so funktioniert das jetzt:

.*:desired-temp:.12.0 .*:desired-temp:.(?!12.0$).*


Vielen Dank für eure Untersützung!

pano

Hallo allersteits. Vorweg erst mal sehr cooles und hilfreiches Modul.
Ich konnte dadurch eine menge Dummys und Notifys einsparen, stoße aber grade an einige Grenzen (wohl auch aufgrund eingeschränkter Perl Kenntnisse).

Folgender Usecase:
Ich habe im Keller einen Lufttrockner mit Wassertank stehen, der regelmäßig volläuft. Im betreffenden raum messe ich über einen TX29DTH-IT Temperatur und Luftfeuchtigkeit.
Den Energieverbrauch des Lufttrockners wiederum messe ich über eine Zwave Steckose mit Energiemessung.

Das Error-Ereigniss definiere ich derzeit indem ein Notify bei jeder Veränderung der rel. Feuchtigkeit prüft, wie hoch der Stromverbrauch des Trockners ist. Wenn Luftfeuchtigkeit > 55% und Energieverbrauch < 5W, bedeutet das, dass der Trockner nicht anspringt, weil vmtl. voll.

Nun ist mir nicht ganz klar, wie ich das mit dem monitoring Device abbilden soll. In der Def des monitoring moduls kann ich ja nur auf ein Reading prüfen und nicht auf das Ergebnis einer Vergleichsoperation. Meine Verständnis ist, dass dafür errorFuncAdd vorgesehen ist. Allerdings verstehe ich aus den beigefügten Beispielen nicht so recht, wie ich das abbilden müsste. Auf ein vorausgehendes Warning würde ich auch gerne verzichten wollen.

In einem ersten Versuch mit errorFuncAdd scheint diese garnicht anzuziehen. Insofern habe ich den Mechanismus wohl nicht richtig verstanden und bin für hilfreiche Erläuterungen sehr dankbar.

Und so sieht mein Monitoring Device aus:

defmod CheckState_LufttrocknerVoll monitoring KG_(vk|wk)_TF_Klimasensor:humidity.*
attr CheckState_LufttrocknerVoll errorFuncAdd {
my $room = substr($name,3,2);
fhem("setreading CheckState_LufttrocknerVoll TestReading $room");
return 1;
}
attr CheckState_LufttrocknerVoll errorReturn {return unless(@errors) }
attr CheckState_LufttrocknerVoll errorWait 0
attr CheckState_LufttrocknerVoll warningReturn {return unless(@warnings) }




igami

Hilfreiche Erläuterung mache ich morgen mal in Ruhe. Erstmal eine Nachstellung mit dummy:

defmod Lufttrockner dummy
attr Lufttrockner readingList power
attr Lufttrockner room pano
attr Lufttrockner setList power:slider,0,1,100
attr Lufttrockner stateFormat P: power
attr Lufttrockner webCmd power

setstate Lufttrockner P: 20
setstate Lufttrockner 2017-12-15 23:38:56 power 20

defmod TX29DTH dummy
attr TX29DTH readingList humidity
attr TX29DTH room pano
attr TX29DTH setList humidity:slider,0,1,100
attr TX29DTH stateFormat H: humidity
attr TX29DTH webCmd humidity

setstate TX29DTH H: 22
setstate TX29DTH 2017-12-15 23:38:59 humidity 22

defmod CheckState_LufttrocknerVoll monitoring TX29DTH:humidity.*
attr CheckState_LufttrocknerVoll errorFuncAdd {\
  return 1 if(ReadingsNum("Lufttrockner", "power", 0) < 5);;\
  return;;\
}
attr CheckState_LufttrocknerVoll errorFuncRemove {\
  return 1 if(ReadingsNum("Lufttrockner", "power", 0) >= 5);;\
  return;;\
}
attr CheckState_LufttrocknerVoll room pano

Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

igami

Nun noch einmal ausführlich und etwas angepasst.
In der DEF wird, wie bei einem notify, das Ereignis angegeben wann geprüft wird. In deinem Fall ist das Luftfeuchtigkeit > 55%.
In dem errrorFuncAdd Attribut kann spezifiziert werden wann das Gerät auf die Error Liste gesetzt wird. In deinem Fall bei Energieverbrauch < 5W.
Nun kann man noch das errorFuncRemove Attribut setzen um das Gerät auch wieder Automatisch entfernen zu lassen.

Durch deine DEF "KG_(vk|wk)_TF_Klimasensor:humidity.*" gehe ich davon aus, dass du mehrere Sensoren und Lufttrockner hast.
Ich habe bei mir nun je zwei dummys angelegt.

Rausgekommen ist dabei folgendes (Raw definition):

defmod KG_vk_Lufttrockner dummy
attr KG_vk_Lufttrockner readingList power
attr KG_vk_Lufttrockner room pano
attr KG_vk_Lufttrockner setList power:slider,0,1,100
attr KG_vk_Lufttrockner stateFormat P: power
attr KG_vk_Lufttrockner webCmd power

defmod KG_vk_TF_Klimasensor dummy
attr KG_vk_TF_Klimasensor readingList humidity
attr KG_vk_TF_Klimasensor room pano
attr KG_vk_TF_Klimasensor setList humidity:slider,0,1,100
attr KG_vk_TF_Klimasensor stateFormat H: humidity
attr KG_vk_TF_Klimasensor webCmd humidity

defmod KG_wk_Lufttrockner dummy
attr KG_wk_Lufttrockner readingList power
attr KG_wk_Lufttrockner room pano
attr KG_wk_Lufttrockner setList power:slider,0,1,100
attr KG_wk_Lufttrockner stateFormat P: power
attr KG_wk_Lufttrockner webCmd power

defmod KG_wk_TF_Klimasensor dummy
attr KG_wk_TF_Klimasensor readingList humidity
attr KG_wk_TF_Klimasensor room pano
attr KG_wk_TF_Klimasensor setList humidity:slider,0,1,100
attr KG_wk_TF_Klimasensor stateFormat H: humidity
attr KG_wk_TF_Klimasensor webCmd humidity

defmod CheckState_LufttrocknerVoll monitoring KG_(vk|wk)_TF_Klimasensor:humidity:.(5[5-9]|[6-9][0-9])
attr CheckState_LufttrocknerVoll errorFuncAdd {\
  $name =~ s/TF_Klimasensor/Lufttrockner/;;\
  return 1 if(ReadingsNum($name, "power", 0) < 5);;\
  return;;\
}
attr CheckState_LufttrocknerVoll errorFuncRemove {\
  $name =~ s/TF_Klimasensor/Lufttrockner/;;\
  return 1 if(ReadingsNum($name, "power", 0) >= 5);;\
  return;;\
}
attr CheckState_LufttrocknerVoll room pano

Da das auslösende Gerät ja der Sensor ist muss in dem errorFuncX Attribut noch der Name auf den Trockner geändert werden. Habe ich hier einfach mal durch suchen und ersetzen gemacht.

Grüße
igami
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

pano

Großartig, danke für die Hilfestellung.
Das mit dem Umbenennen ist sehr effizient, auch wenn ich in einem Monat sicher nicht mehr weiss, waum das da steht ;-)

In welche Richtung möchtest Du das Modul eigentlich weiterentwickeln, bzw. welcher Anwendungsfall schwebte dir dabei vor?

Hintergrund der Frage ist, dass ich seit einiger Zeit rumbastel wie man Überwachung und Alarmierung der Heimautomation sinnvoll ausgestalten/umsetzen kann.
Meine bisherigen Überlegungen führen aber - je nach Größe der FHEM Installation - zu einer enormen Menge von Dummys, Notifys, Komplexität.
Dein Modul hilft da schon einiges zu konsolidieren. Wenn das den Fokus dieses Threads nicht sprengt, würde ich mich gerne hier mit dir und anderen Interessierten über mögliche Usecases und Implementierungsvarianten austauschen.

Der Ansatz, den ich bisher gedanklich vefolgt hatte war anforderungsseitig:
a1) Überwachung der technischen Komponenten => zB Server/Sensor/Aktor lebt noch
a2) Überwachung von (logischen) Zuständen => zB ist es zu kalt, ist das Fenster zu lange offen, ist der Lufttrockner voll
a3) Erkennen von Fehlerursachen => zB is ist zu kalt, weil das Fenster offen ist oder der heizungsregler ausgestellt ist
a4) Erkennen von unspezifischen Problemen => zB Anzahl von Logeinträgen pro Zeit steigt

Der nächste Schritt wäre die sinnvolle Darstellung und Benachrichtigung von Events (da ich zu Hause keinen Leitstand mit Displaywand  voller Dashboards durchgesetzt bekomme).
b1) kontinuierliche Meldung bei Fehlern => zB Rote Lampe leuchtet, Sirene heult, ... solange Fehler andauert
b2) diskrete Benachrichtigung => Aussteuern von Mails/SMS/... mindestens beim Eintreten und Auflösen eines Fehlers, ggf. periodisches wiedererinnern
b3) Eventeskalation => Retest um "Verschlucker" und False-Positives zu erkennen, Wechseln von Warnings zu Critical nach x Retests oder Fehlerdauer, etc.
b4) Komfortfunktionen  => Sleep/Mute und Ignore von Alarmen, die man temporär "akzeptieren" möchte

Nach Erkennung und Benachrichtigung von Fehlerzuständen ginge es dann noch an das Lösen des eigentlichen Problemes:
c1) Triggern von Aktionen zur "Selbstheilung" (zB Neustart von FHEM, erneutes Ansprechen von Aktoren,...)
c2) Handlungsempfehlungen ausgeben (zB "Fenster sollte geschlossen werden", Lufttrockner ausleeren")

Ach ja, dass das Ganze auch bis zu einem gewissen Punkt Ehefrauenkompatibel sein muss versteht sich natürlich von selbst ;-)

FHEM bietet jetzt schon diverse Module, die Teilaufgaben hiervon übernehmen können (Alarm, actiondetector, monitoring um einige zu nennen). Andererseits gibt es auch am Markt Tools, die zB auf das Managen von Events (zB Nagios) oder das Darstellen von Zuständen/Dashboards spezialisiert sind (letzteres wird grade durch das recht neue InfluxDB Modul in Kombination mit Grafana recht interessant)

Soll heissen, im Zweifel und mithilfe aller möglichen Module und selbstgebastelter Utils bekommt man sicherlich alles auch innerhalb von FHEM hin. Fraglich ist aber, ob das auch der sinnvollste Weg ist.
Ich denke, da FHEM in den meisten Fällen die Steuerung des SmartHomes übernimmt, wäre hier die Bestimmung von Fehlern aus a2) sinnvoll aufgehoben, vmtl. auch a3). Bei a1) wäre ich mich schon nicht mehr sicher, ob man das nicht besser auslagern sollte, insb. wenn man über FHEM hinaus noch weitere Komponenten (NAS, Router, ...) im Netzwerk stehen hat.

Spätestens bei b1) bis b4) stellt sich die Frage, ob ein System sich selbst überwachen und melden soll, da ein Komplettausfall des Systemes auch die Überwachung selbst betreffen würde. Davon abgesehen wäre die robuste Nachbildung all der Funktionen von bestehender spezialisierter Software recht aufwändig. Fairerweise würde ich aber auch das in b1) beschriebene Leuchten der Roten Lampe durch FHEM lösen, aber vielleicht sinnvollerweise einer getrennten FHEM Installation (wozu hat man üblicherweise unmengen Raspis im Haus ;-)

Ähnlich verhält es sich mit c1) und c2). Ist es die richtige Strategie die Problemlösung vom betroffenen System selbst triggern zu lassen, oder sollte man da eher auf Drittsysteme (zusätzliche FHEM Installation, Jobsteuerung a la Jenkins) zurückgreifen.

Ideen und Meinungen sind herzlich willkommen.

igami

Zitat von: pano am 17 Dezember 2017, 00:22:52
Das mit dem Umbenennen ist sehr effizient, auch wenn ich in einem Monat sicher nicht mehr weiss, waum das da steht ;-)
Kommentare, durch # eingeleitet, sind momentan leider noch nicht möglich, da muss ich noch nach gucken wie ich das umsetzen kann.

Zitat von: pano am 17 Dezember 2017, 00:22:52
In welche Richtung möchtest Du das Modul eigentlich weiterentwickeln, bzw. welcher Anwendungsfall schwebte dir dabei vor?
Die Idee zu dem Modul kommt daher, dass ich eine relativ große FHEM Installation in einer Firma administriert habe.
Irgendwie musste man dann ja überwachen bei welchen Funkaktoren die Batterie nachlässt. Bei den Beispielen die es gab wird immer bei battery: low eine E-Mail verschickt. Dabei bedeutet low ja nicht leer, weiterhin pendelt der Status auch gerne zwischen high und low wenn man sich an der Grenze befindet und ich wollte auch nicht außerhalb der Arbeitszeit eine so unwichtige Nachricht erhalten, dass die Batterie bald leer ist. Daraufhin habe ich monitoring entwickelt. Neben den Batterien gab es dann noch die Filterüberwachung der Klimaanlagen, Fehlermeldungen von APs und anderen Geräten, etc.

Zitat von: pano am 17 Dezember 2017, 00:22:52
Hintergrund der Frage ist, dass ich seit einiger Zeit rumbastel wie man Überwachung und Alarmierung der Heimautomation sinnvoll ausgestalten/umsetzen kann.
Meine bisherigen Überlegungen führen aber - je nach Größe der FHEM Installation - zu einer enormen Menge von Dummys, Notifys, Komplexität.
Dein Modul hilft da schon einiges zu konsolidieren. Wenn das den Fokus dieses Threads nicht sprengt, würde ich mich gerne hier mit dir und anderen Interessierten über mögliche Usecases und Implementierungsvarianten austauschen.

Der Ansatz, den ich bisher gedanklich vefolgt hatte war anforderungsseitig:
a1) Überwachung der technischen Komponenten => zB Server/Sensor/Aktor lebt noch
a2) Überwachung von (logischen) Zuständen => zB ist es zu kalt, ist das Fenster zu lange offen, ist der Lufttrockner voll
a3) Erkennen von Fehlerursachen => zB is ist zu kalt, weil das Fenster offen ist oder der heizungsregler ausgestellt ist
a4) Erkennen von unspezifischen Problemen => zB Anzahl von Logeinträgen pro Zeit steigt
Die Fällte a1, a2 und a4 sollten sich durch monitoring abbilden lassen.
Die ganzen Benachrichtigunen b sind bewusst nicht in monitoring implementiert, das es viel zu viele verschiedene Möglichkeiten gibt. Auf der Arbeit habe ich noch ein userattr priority eingebaut. Fällt die Klimaanlage im Serverraum aus bekomme ich sofort eine Benachrichtigung, ansonsten bekomme ich nur Benachrichtigungen während der Arbeitszeit. Das ganze ist mit einem DOIF gelöst.

Zitat von: pano am 17 Dezember 2017, 00:22:52
Der nächste Schritt wäre die sinnvolle Darstellung und Benachrichtigung von Events (da ich zu Hause keinen Leitstand mit Displaywand  voller Dashboards durchgesetzt bekomme).
b1) kontinuierliche Meldung bei Fehlern => zB Rote Lampe leuchtet, Sirene heult, ... solange Fehler andauert
b2) diskrete Benachrichtigung => Aussteuern von Mails/SMS/... mindestens beim Eintreten und Auflösen eines Fehlers, ggf. periodisches wiedererinnern
b3) Eventeskalation => Retest um "Verschlucker" und False-Positives zu erkennen, Wechseln von Warnings zu Critical nach x Retests oder Fehlerdauer, etc.
b4) Komfortfunktionen  => Sleep/Mute und Ignore von Alarmen, die man temporär "akzeptieren" möchte
Zu Hause habe ich das userattr executor welches ich mit Residents verknüpft habe um die "Aufgaben" an bestimmte Personen zu verteilen. Die Benachrichtigung erfolgt über Telegram. Die Benachrichtigung wird dabei 15 Minuten nach dem man nach hause kommt automatisch versendet. Alternativ kann sie manuell abgerufen werden.

Zitat von: pano am 17 Dezember 2017, 00:22:52
Nach Erkennung und Benachrichtigung von Fehlerzuständen ginge es dann noch an das Lösen des eigentlichen Problemes:
c1) Triggern von Aktionen zur "Selbstheilung" (zB Neustart von FHEM, erneutes Ansprechen von Aktoren,...)
c2) Handlungsempfehlungen ausgeben (zB "Fenster sollte geschlossen werden", Lufttrockner ausleeren")
Hier ist es ähnlich wie bei b. Es ist von Fall zu Fall unterschiedlich was die richtige Vorgehensweise ist. C2 lässt sich durch das Attribut errorReturn umsetzen, dies dient dazu die Nachricht zu formatieren. So bekommt man nicht nur die Namen der Geräte mit niedrigen Batteriestand sondern eine Nachricht in der Form:
Zitat
Bei den folgenden 3 Geräten muss die Batterie gewechselt werden:
- Arbeitszimmer: Fenster links
- Wohnzimmer: Heizung
- Flur: Bewegungsmelder

Zitat von: pano am 17 Dezember 2017, 00:22:52
Ach ja, dass das Ganze auch bis zu einem gewissen Punkt Ehefrauenkompatibel sein muss versteht sich natürlich von selbst ;-)
Das liegt in deiner Hand. Ich habe diverse DashButtons in der Wohnung verteilt. Wurde der Wasserfilter gewechselt: drücken. Das klappt wunderbar. Ich wurde nur gebeten noch bald ausstehende Aufgaben auch mit anzugeben, wie "In 3 Tagen muss der Wasserfilter gewechselt werden". Das lässt sich ja durch die warning Liste managen.

Zitat von: pano am 17 Dezember 2017, 00:22:52
FHEM bietet jetzt schon diverse Module, die Teilaufgaben hiervon übernehmen können (Alarm, actiondetector, monitoring um einige zu nennen). Andererseits gibt es auch am Markt Tools, die zB auf das Managen von Events (zB Nagios) oder das Darstellen von Zuständen/Dashboards spezialisiert sind (letzteres wird grade durch das recht neue InfluxDB Modul in Kombination mit Grafana recht interessant)

Soll heissen, im Zweifel und mithilfe aller möglichen Module und selbstgebastelter Utils bekommt man sicherlich alles auch innerhalb von FHEM hin. Fraglich ist aber, ob das auch der sinnvollste Weg ist.
Ich denke, da FHEM in den meisten Fällen die Steuerung des SmartHomes übernimmt, wäre hier die Bestimmung von Fehlern aus a2) sinnvoll aufgehoben, vmtl. auch a3). Bei a1) wäre ich mich schon nicht mehr sicher, ob man das nicht besser auslagern sollte, insb. wenn man über FHEM hinaus noch weitere Komponenten (NAS, Router, ...) im Netzwerk stehen hat.

Spätestens bei b1) bis b4) stellt sich die Frage, ob ein System sich selbst überwachen und melden soll, da ein Komplettausfall des Systemes auch die Überwachung selbst betreffen würde. Davon abgesehen wäre die robuste Nachbildung all der Funktionen von bestehender spezialisierter Software recht aufwändig. Fairerweise würde ich aber auch das in b1) beschriebene Leuchten der Roten Lampe durch FHEM lösen, aber vielleicht sinnvollerweise einer getrennten FHEM Installation (wozu hat man üblicherweise unmengen Raspis im Haus ;-)

Ähnlich verhält es sich mit c1) und c2). Ist es die richtige Strategie die Problemlösung vom betroffenen System selbst triggern zu lassen, oder sollte man da eher auf Drittsysteme (zusätzliche FHEM Installation, Jobsteuerung a la Jenkins) zurückgreifen.
Zu a1: da kommt es darauf an ob FHEM das sicher überwachen kann. Geräte ohne Rückkanal lassen sich schlecht überwachen. Beim Server ist die Frage was man überwachen will: Stromverbrauch, Temperatur, erreichbarkeit per Ping, Stauts von Diensten, etc.
Wie heißt es doch so schön? Quis custodiet ipsos custodes? zu deutsch: Wer überwacht die Wächter? Sie überwachen sich gegenseitig. FHEM die NAS und die NAS FHEM.

Zitat von: pano am 17 Dezember 2017, 00:22:52
Ideen und Meinungen sind herzlich willkommen.
Ich bin auch für jedes Brainstorming offen. Wenn du noch weitere Anwendungsfälle hast immer her damit!
Ich selbst nutze monitoring als Aufgabensteuerung für:
- den Abfallkalender (Morgen wird XX abgeholt)
- den Wechsel der Bettwäsche (im Sommer ein anderes Intervall als im Winter, Bestätigung über einen DashButton)
- das Entkalken des Duschkopfs (Bestätigung über einen DashButton)
- den Wechsel des Wasserfilters (Bestätigung über einen DashButton)
- die Überwachung von Batterieständen
- das Ablesen von Strom-, Wasser- und Wärmemengenzählern (Eingabe über Telegram)
- den Wechsel der Zahnbürste (Bestätigung über einen DashButton)
- das Umschalten der Heizung zwischen Sommer- und Winterbetrieb

Weiterhin noch als Statusanzeige für geöffnete Fenster. Beim zubett gehen bekomme ich eine Nachricht und kann noch fix das Fenster im Bad schließen, damit es am nächsten Morgen nicht so kalt ist :D

Meiner Meinung nach ist FHEM eine gute Backend Software. Als Frontend gibt es dann Tablet UI oder Telegram, sofern benötigt.

Ich freue mich auch immer, wenn user einen Wiki Beitrag zu Modulen schreiben. Ich selbst bin nur leider nicht so Wortgewand und habe auch Angst, dass der Beitrag dann auf einem alten Stand bleibt (wie die Commandref zu monitoring auch schon :-[) und falsche Informationen sind schlimmer als gar keine.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

pano

Hallo igami.

Zuerst mal zu meinen Usecases.
meine Alarmierungen (wobei ich noch nicht weiss, welche davon ich mit Monitoring umsetzen werde):
- Fenster offen länger als x Minuten
- Fenster nicht mehr geöffnet seit x Stunden
- Raumtemperatur unter x Grad
- Fenster offen bei Taupunkt Innen > Taupunkt Aussen
- Waschmaschine / Waschtrockner Fertig (via Energieabfall an Energiemesssteckdose)
- Luftentfeuchter voll
- Jeelink-Temperatursensoren noch am Leben (gelegentlich muss der Jeelink mal reopened werden)

Darüber hinaus betreibe ich drei weitere Raspis für
- Anwesenheitserkennung (PiZero im Flur bei der Schlüsselablage, Schlüssel mit GTags ausgerüstet)
- Auslesen gaszähler und Stromzähler (per reed, bzw. Infrarotschnittstelle)
- Pi3 mit RaspiCam und Python/OpenCV-Scripten zum Ablesen des Betriebsmodus meiner Uralt-Heizungsanlage (via eines 7-Segment Display)
Alle drei stellen gelegentlich mal den Dienst ein und bedürfen eines "gegentretens"


Nun ein paar Anmerkungen/Vorschläge zum monitoring-Device als solchen.
a1) Status des monitoring Devices
In meinem aktuellen Setup habe ich spasseshalber 6 monitoring-Devices erzeugt (Fenster offen, Haustür offen, Garage offen, Lufttrockner voll, Raumtemperatur niedrig, Raumfeuchte hoch).
Unschön finde ich, dass man auf der Oberfläche (im State) nicht sieht, ob grade ein Fehler vorliegt (insb. wenn ein monitoring Device mehrere Geräte überwacht). Stattdessen sieht man welches Event als letztes ausgesteuert wurde. Das wiederum könnte interessant sein, da aber hier ein Zeitstempel fehlt hilft das nur bedingt.
Eine bessere State-Darstellung fände ich also zB "x Errors | y Warnings".
Alternativ und analog zu heute "warning remove: <ein device> (um hh:mm)".  Noch cooler wäre "Fehler bei <ein device> seit xy Stunden" (wobei ich allerdings nicht sicher bin, ob man in einem State einen sich periodisch verändernden Text hinterlegen sollte)

a2) Wechsel von Warning zu Error nach x Retrys
Derzeit basiert der Wechsel von einem in den anderen Status lediglich auf einer Fehlerdauer (attr errorWait). Gut wäre es, wenn es auch die Möglichkeit gäbe eine Anzahl von aufeinanderfolgenden Warning-Events zu hinterlegen nach denen in Error gewechselt wird. Zeitbasiert lässt sich das ansonsten nur "schätzungsweise" abbilden wenn mann Annahmen triift, wie oft eine Messung sich wiederholen könnte.

igami

Zitat von: pano am 17 Dezember 2017, 23:47:02
a1) Status des monitoring Devices
In meinem aktuellen Setup habe ich spasseshalber 6 monitoring-Devices erzeugt (Fenster offen, Haustür offen, Garage offen, Lufttrockner voll, Raumtemperatur niedrig, Raumfeuchte hoch).
Unschön finde ich, dass man auf der Oberfläche (im State) nicht sieht, ob grade ein Fehler vorliegt (insb. wenn ein monitoring Device mehrere Geräte überwacht). Stattdessen sieht man welches Event als letztes ausgesteuert wurde. Das wiederum könnte interessant sein, da aber hier ein Zeitstempel fehlt hilft das nur bedingt.
Eine bessere State-Darstellung fände ich also zB "x Errors | y Warnings".
Alternativ und analog zu heute "warning remove: <ein device> (um hh:mm)".  Noch cooler wäre "Fehler bei <ein device> seit xy Stunden" (wobei ich allerdings nicht sicher bin, ob man in einem State einen sich periodisch verändernden Text hinterlegen sollte)
Das soll doch bitte jeder so handhaben wie er möchte. Ich persönlich habe eine in den myUtils eine sub für stateFormat

sub monitoring_stateFormat($) {
  my ($SELF) = @_;
  my $ret = fhem("get $SELF all");

  if($ret){
    $ret =~ s/\n/<br>/g;

    return('<div style="text-align: left">' . $ret . '</div>' );
  }

  return("keine Meldungen");
}


Zitat von: pano am 17 Dezember 2017, 23:47:02
a2) Wechsel von Warning zu Error nach x Retrys
Derzeit basiert der Wechsel von einem in den anderen Status lediglich auf einer Fehlerdauer (attr errorWait). Gut wäre es, wenn es auch die Möglichkeit gäbe eine Anzahl von aufeinanderfolgenden Warning-Events zu hinterlegen nach denen in Error gewechselt wird. Zeitbasiert lässt sich das ansonsten nur "schätzungsweise" abbilden wenn mann Annahmen triift, wie oft eine Messung sich wiederholen könnte.
Da muss ich nächstes Jahr mal drüber nachdenken. Da ich bei fast allen Geräten event-on-change-reading verwende ergibt sich bei mir der Anwendungsfall mit wiederholenden Events nicht.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED