98_DeviceMonitor: Überwachung von Devices - Testuser gesucht

[Dennis G]

Hallo zusammen,

ich habe aus der Idee von Willi (checkstate siehe https://groups.google.com/forum/?hl=de&fromgroups=#!topic/fhem-users/u55ed9-x8ME) 

über die Zwischenlösung „checkstate2“ nun eine neue Version einer Funktionalität zur Überwachung von Sensoren/Aktoren („Devices“) gebaut, 

hierfür sind einige Anregungen aus der Developergroup eingeflossen. 

Über die Funktion bestand dort weitestgehend Einigkeit, für die Umsetzung gab es mehrere Optionen mit Vor- und Nachteilen. 

Der wesentliche Vorteil dieser Lösung ist die Echtzeitmeldung von Ausfällen (Definition Ausfall: Kein Event nach Ablauf einer vorher bestimmten Zeit) 

bzw. Aktivität. Bedenken bestehen z.T. bezüglich der Auswirkung auf die Performance, ich habe das bei mir mit 15 Sensoren auf einem RPI 

getestet und konnte keine Auswirkungen (LoadAverage, RAM) feststellen (die Werte bewegten sich in dem Bereich in dem sie auch sonst waren).

Daher werden nun weitere Erfahrungen benötigt (mehr Sensoren/andere Systeme) und ich würde mich freuen wenn sich der ein oder andere an dem Versuch 

beteiligt und seine Erfahrungen mitteilt. Ob das Modul so weiterentwickelt wird dass es sich in die Reihe der „offiziellen“ Fhem Module einreiht hängt vom Ergebnis 

des Tests und der allgemeinen Resonanz ab.

Danke für Feedback, Gruß Dennis

#############################################################################################

98_DeviceMonitor.pm

Hinweis:

Dieses ist eine Testversion, daher Einsatz auf eigene Gefahr :-)

Problemstellung:

Devices können ausfallen (Funkverbindung gestört, Schnittstelle (CUL etc.) gestört, Batterie leer, Gerät defekt …), 

derzeit gibt es keine zentrale Überwachungsfunktionalität die alle Devices abbilden kann.

Lösungsansatz/Funktionsbeschreibung:

Wenn ein Device überwacht werden soll dann wird an diesem ein Attribut „Device_Timeout“ gesetzt, wird von diesem Gerät 

innerhalb dieses Zeitraumes kein Event generiert bekommt es den Status „dead“ ansonsten den Status „alive“. 

Ist das Gerät im Status „dead“ und es wird wieder ein Event empfangen wechselt der Status wieder auf „alive“. 

Der Status wird sowohl bei dem betroffenen Gerät als auch in den Readings des DeviceMonitor angezeigt, 

zudem wird jeweils ein Event generiert welches gelogt oder z.B. via Notify dazu verwendet werden kann 

andere Ereignisse (E-Mail senden, Hupe an, etc.) auszulösen.

Ziel des Tests:

Es soll ermittelt werden ob die Funktion zuverlässig funktioniert und insbesondere ob und in welchem Maße es durch 

aktivieren der Funktion zu Performanceverschlechterungen kommt. Desweiteren sollen Wünsche für weitere Funktionen 

des Devicemonitors gesammelt werden bzw. überhaupt ermittelt werden ob dieses Modul als Sinnvoll erachtet wird und in 

die Standardmodule mitaufgenommen werden soll.

Installation:

- Datei 98_DeviceMonitor.pm im FHEM Verzeichnis ablegen (dort wo auch die anderen XX_Name.pm Dateien liegen)

        Quelle: http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/contrib/DeviceMonitor/

- Im FHEM Kommandofeld reload 98_DeviceMonitor.pm eingeben und Enter drücken, Es sollten keine Fehlermeldungen auftreten

- In der fhem.cfg eintragen define einBeliebigerName DeviceMonitor

- Der DeviceMonitor sollte nun verfügbar sein, falls nicht: shutdown restart

- Bei allen zu überwachenden Geräten das nun verfügbare Attribut „Device_Timeout“ setzen, Angabe in minuten

- Ergebnis der Überwachung im Event Monitor, überwachtem Device und Devicemonitor ablesbar (nach Empfang des ersten Events oder 

        Ablauf des TimeOuts).

Besonderheiten:

- Soll ein Device überwacht werden welches auch „event-on-change-reading“ oder „event-on-update-reading“ nutzt muss sichergestellt sein das 

genügend Events generiert werden um die Überwachung gewährleisten zu können - Ansonsten wird das Gerät 

fälschlicherweise als „dead“ erkannt. Beispiel: Ist bei einem TempSensor „event-on-change-reading“ auf das Reading „state“ gesetzt empfiehlt es 

sich ein zusätzliches „event-on-update-reading“ auf z.B. “battery” zu setzen, dadurch wird jedesmal wenn „battery“ empfangen wird ein event ausgelöst das von 

DeviceMonitor als Lebenszeichen gedeutet werden kann. 

Screenshots:

- Ansicht überwachtes Device (Ausschnitt):

- Ansicht Devicemonitor:

#############################################################################################

[puschel74]

Hallo,

ich wollte mich eigentlich als unbedarfter User der Herausforderung stellen und das Modul testen.
11 FHT80b inkl 11 Ventilantrieben, 6 S300TH und 2 Feuchtesensoren über ECMD.
Funktioniert soweit alles einwandfrei.
Das 98_DeviceMonitor.pm ins FHEM-Verzeichnis zu den anderen xx_Name.pm gepackt und ein beherztes
reload 98_DeviceMonitor.pm
bringt mir

2012.10.27 15:05:17 1: reload: Error:Modul 98_DeviceMonitor deactivated:
 Can't modify constant item in predecrement (--) at ./FHEM/98_DeviceMonitor.pm line 6, near "ViewVC :: http"
syntax error at ./FHEM/98_DeviceMonitor.pm line 6, near "ViewVC :: http"
"no" not allowed in expression at ./FHEM/98_DeviceMonitor.pm line 19, at end of line
syntax error at ./FHEM/98_DeviceMonitor.pm line 22, near "36px"
Unmatched right curly bracket at ./FHEM/98_DeviceMonitor.pm line 23, at end of line
syntax error at ./FHEM/98_DeviceMonitor.pm line 37, near "-->"
syntax error at ./FHEM/98_DeviceMonitor.pm line 43, near "END:"
syntax error at ./FHEM/98_DeviceMonitor.pm line 59, near "" class="logo"
syntax error at ./FHEM/98_DeviceMonitor.pm line 86, near ">"
syntax error at ./FHEM/98_DeviceMonitor.pm line 103, near "<a href="/viewvc"
./FHEM/98_DeviceMonitor.pm has too many errors.

Das 98_DeviceMonitor.pm habe ich aus der oben verlinkten Quelle gezogen.
Hab ich da einen Denkfehler oder hab ich vergessen was zu definieren?
Mein fhem ist
2012.10.22 19:19:28 0: Server started (version Fhem 5.2 (DEVELOPMENT), $Id: fhem.pl 1966 2012-10-15 08:01:58Z rudolfkoenig $, pid 20057)
evtl. ein uodate nötig?

Grüße

[puschel74]

Hallo,
achso ja tut mir leid.
Plattform ist ein FB7390 mit 1 CUL und 2 CUNO und ein AVR Net IO.

Grüße

[Dennis G]

Hallo,

das sieht so aus als ob du den Quelltext der Internetseite gespeichert hättest und nicht die .pm Datei, schau mal hier:

http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/contrib/DeviceMonitor/98_DeviceMonitor.pm?view=log

da gibt es dann auch einen "Download" Link, wenn du die Datei mit einem Texteditor aufmachst müssen die 

ersten Zeilen so aussehen:

# $Id: 98_DeviceMonitor.pm  $
#
# Copyright (C) 2012 Dennis Gnoyke
#
#  This script is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# 
# This library is free software; you can redistribute it and/or modify
# it under the same terms as Perl itself, either Perl version 5.8.7 or,
# at your option, any later version of Perl 5 you may have available.
#
package main;
use strict;
use warnings;

ich vermute die Datei die du als 98_DeviceMonitor.pm gespeichert hast sieht so ähnlich aus:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!-- ViewVC :: http://www.viewvc.org/ -->

<head>

das würde die Fehlermeldungen erklären :-)

Gruß Dennis

[puschel74]

Hallo,

Asche auf mein Haupt.
Ich hab mir das .pm-file grad angeschaut und hab mir noch gedacht - ich werde doch nicht zu doof sein um ein File
aus sourceforge zu speichern :-((
Right - ich hab den Quelltext gespeichert ich xxxxxx.

Danke für den Hinweis.
Auf ein neues ;-)

Grüße

[Mitch]

gerade installiert und funktioniert soweit.

Melde mich mich wieder in ein paar Tagen.

[Turbokid]

nehme auch teil.

installiert und melde mich wieder. Erstmal Timeouts gut einstellen :D

[puschel74]

Hallo,

ich bin nach Anleitung vorgegangen und hab auch das Device_Timeout gesetzt aber ich hab kein Reading alive oder Dead *grübel*

define Eingang_aussen CUL_WS 5
attr Eingang_aussen Device_Timeout 10
attr Eingang_aussen room 20_Erdgeschoss,25_Heizung,95_Heizung

Der DeviceMonitor heisst bei mir Devicecheck und steht als DEFINED in fhem aber auch dort keine Devices gelistet.

Ich hab erstmal nur meine CUL_WS eingetragen aber ich bekomm kein Alive.
shutdown restart hab ich auch gemacht aber nüscht.
Im Log auch keine Fehlermeldung.
Ich hab sicher wieder was falsch gemacht - siehe download von Sourceforge ;-)

Grüße

Am Samstag, 27. Oktober 2012 11:36:24 UTC+2 schrieb Dennis G:

[Dennis G]

Hi,

device_timeout muss kleingeschrieben sein, falls es dennoch nicht funktioniert, probiere mal in das Kommandofeld von fhem folgendes :

trigger Eingang_aussen test

im FileLog von Eingang_aussen müsste der Eintrag "test" zu sehen sein und im Devicemonitor der Eingang_aussen aufgelistet sein.

Ich vermute jedoch das nur das attr Eingang_aussen Device_Timeout 10 mit großem D und T schuld dran ist :-)

Gruß Dennis

[puschel74]

Hallo,

ok, kleinschreibung hats gebracht.
Der DeviceMonitor ist nun ENABLED und die Geräte werden auch gelistet.
Dachte ich mir doch das der Fehler wieder zwischen Tastatur und Bildschirm saß ;-)
Danke für die Hilfe.

Grüße

[Erwin]

Hi Dennis,

...erster test erfolgreich, danke für das Modul, erspart einiges an watchdog/at logik....

Was mir aufgefallen ist und mir fehlt:
Falls ich ein device_timeout lösche (und damit aus dem Monitoring wieder raus haben will)..... geht der status irgendwann auf dead.
IMHO sollten aber sowohl die readings im DeviceMonitor als auch die CFGDEF im betreffenden Device gelöscht werden, oder ?

l.g. erwin

[Dennis G]

Hallo Erwin,

in der Tat, ich hatte das am Wochenende schon eingebaut jedoch noch nicht in das SVN hochgeladen:

- Feature: Wenn das attr device_timeout auf 0 gesetzt oder entfernt wird dann wird das Device nicht mehr im 

 Monitor gelistet und die CFGDEF entfernt. Dieses erfolgt nach Empfang des nächsten Events oder wenn "dead" auftritt 

(Je nachdem was als erstes der Fall ist)

- Feature: Es gibt nun ein "get <nameDeviceMonitor> <Kriterium1>_<Kriterium2>"

Kriterium1 kann sein: dead, alive, total

Kriterium2 kann sein: count, text, html

Beispiel:

get myMonitor dead_cnt  Gibt die Anzahl der Geräte mit Status 'dead' zurück

get myMonitor dead_html Gibt eine HTML Tabelle der Geräte mit Status 'dead' zurück, Gerätename ist als Link zu den Gerätedetails ausgeprägt.

Verwendung z.B. als Weblink: define Devicecheck weblink htmlCode {fhem "get myMonitor dead_html"}

get myMonitor total_text Gibt einen Text aller überwachten Geräte zurück, Verwendung z.B. als Body in einer E-Mail:

Device AR_Temperatur has health_state 'alive' reported at 2012-10-30 05:19:06
Device Aussentemperatur has health_state 'alive' reported at 2012-10-30 05:15:04
Device BD_Temperatur has health_state 'alive' reported at 2012-10-30 05:18:16
Device DB_Temperatur has health_state 'alive' reported at 2012-10-30 05:14:59
Device DZ_Heizung has health_state 'alive' reported at 2012-10-30 05:12:12

[...]

Wichtig: get bildet nur den aktuellen Stand bei Aufruf ab (sollte klar sein :-)) und derzeit wird bei Verwendung von  {fhem "get ..."} immer 

das Ergebnis des get in das fhem Log geschrieben, Rudi wollte diese Woche prüfen ob er einen zusätzlichen Parameter einführt mit dem man dieses Verhalten unterdrücken 

kann.Daher hatte ich diese Version bis dato noch nicht in das SVN geladen - Habe es nun doch gemacht :-)

Installation für diejenigen die den DeviceMonitor schon testen:

neue Version Revision 2038 runterladen:

http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/contrib/DeviceMonitor/98_DeviceMonitor.pm?view=log

und in das FHEM Verzeichnis kopieren (bestehende Datei ersetzen).

reload 98_DeviceMonitor.pm in das fhem Kommandofeld eingeben.

Für die Erstinstallation ändert sich an der Anleitung des ersten Beitrages nichts (ausser das Device_Timeout kleingeschrieben werden muss :-))

Schöne Grüße ...

Dennis

[Rudolf Koenig]

> Rudi wollte diese Woche pruefen ob er einen zusaetzlichen Parameter einfuehrt
> mit dem man dieses Verhalten unterdruecken kann.

Habs eingecheckt: fhem("get WEB", 1) schreibt keine Rueckgabewerte mehr ins
Log.

[Turbokid]

So Test sieht gut aus.

Habe eine Komponente ab gemacht bevor ich den DeviceMonitor eingebaut habe um zu schauen, wie er darauf reagiert.

Leider taucht das Device garnicht auf(habe es perWeb gemacht das Att), kann es daran liegen, weil die TimeOutzeit von 3 Tagen noch nicht um ist? Müssten nicht  alle mit dead starten?

[Dennis G]

Hi,

der Start erfolgt mit "alive" sobald das erste event empfangen wurde, es muss also einmalig etwas empfangen werden damit der DeviceMonitor 

überhaupt mitbekommt das da ein device ist was er überwachen kann.

Gruß Dennis 

[Turbokid]

Feedback: Augenscheinlich ist meine CPU Auslastung höher, bedeutet regelmässig bei 100%(FB7390). Habe es wieder deaktiviert und habe jetzt keine 100% mehr. Welcher Prozess es ist, weiß ich leider nicht, da ich im Unix noch nicht so fit bin, noch nicht :D

[Dennis G]

Hi,

100% Auslastung würde mich jetzt doch sehr überraschen, wieviel
Devices hast du im Monitor ?
Ich habe mit 18 getestet ohne nennenswerte Veränderung, CPU dümpelt
bei mir quasi im Leerlauf
(RPI nicht FBox). Kannst du mal bei dir folgendes definieren:

define Uptime weblink htmlcode{qx(uptime)}

Ob es auf der FB funktioniert weiss ich nicht, wenn es Unix/Linux ist
sollte es das wohl...
es wird ein Weblink erzeugen der in etwa sowas anzeigt:
00:58:04 up 7:07, 4 users, load average: 0.15, 0.14, 0.18

load average wäre das interessante und gibt die Prozessorauslastung
der letzten minute / 5 min. / 15 min.
an. Bei einem Rechner mit einem Prozessor ist es günstig wenn
insbesondere der 15 min. Wert unter 1.0 liegt.
http://de.wikipedia.org/wiki/Load#Der_Load_Average_auf_Unix-Systemen

Das wäre eine gute Vergleichsmöglichkeit um die Systemauslastung
vorher / nachher zu beurteilen
insbesondere wenn man darauf mal öfter ein Auge wirft....

Gibt es schon resultate von weiteren Usern ?

Gruß Dennis

[puschel74]

Hallo,

so, nun auchmal von mir ein Feedback.
ich habe zur Zeit 19 Geräte definiert welche ich mit dem Device-Monitor überwache.
Erstmal nur als Anzeige in fhem, Mailnachricht kommt noch.
Die CPU-Auslastung geht bei meiner 7390 immer mal wieder auf 93% hoch - das war
aber auch vor dem Device-Monitor schon.
Die Überwachung funktioniert einwandfrei mann muss halt nur die Überwachungszeit abwarten
bis von alive auf dead umgeschaltet wird, das ist logisch.

Also dann noch die Mailnachricht einbauen und weiter testen.

Grüße

[zwiebel]

Hallo Dennis,

tolles modul! Funktioniert ohne CPU problem auf meiner FB7390. Hab etwa 8 devices in der Überwachung.
Wie bekomm ich ein Mail alert hin?

define MailDeviceMonitor notify .*health_state:.* {if("%" !~ m/dead/) {\
    {FB_mail('user@@domain.de','FHEM Device Monitor','@ %')};;\
    Log 3, "@: FHEM Device Monitor %";;\
    }\
}
versteh nicht was ich falsch mache....
return value: syntax error at (eval 11715) line 1, near ""health_state: dead"B "

vielen dank
Zwiebel

[Dennis G]

Hallo Zwiebel,

danke für die Rückmeldung, ich bin leider etwas knapp dran, daher komme ich gerade nicht dazu dein notify auszuprobieren, 

es scheint syntaktisch ok zu sein.Probiere am besten mal das notify zu vereinfachen indem du z.B. direkt nach .*dead.* suchst

um das Problem einzugrenzen.

Es gibt noch eine andere Option, mit der du nicht für jedes Gerät eine Mail bekommst sondern eine zusammenfassung, überprüfen via at:

define CheckDevices at +*00:15:00 {FB_mail('user@@domain.de','FHEM Device Monitor',fhem("get Monitor dead_text",1))}

da würdest du alle 15 min. eine Mail mit der Auflistung aller Devices im Status "dead" bekommen, du kannst das ganze noch 

verfeinern indem du noch ein if davorbaust:

if (fhem("get Monitor dead_count",1) > 5)   also nur wenn mehr als 5 Devices ausgefallen sind.

Bin an diesem Wochenende auf Reisen und werde erst darauffolgendes WE wieder an dem Modul arbeiten, dann würde ich es gerne 

als reguläres Modul einchecken (muss noch CommandRef etc. fertigstellen).

Schöne Grüße ...

Dennis

[zwiebel]

Hallo Dennis,

das define von dir um Mails zu versendet geht! Hab aber nur ein @ gebraucht.
Alle 15 min sind etwas  oft, wenn man nicht gleich um den fehler kümmern kann...

Vielen dank nochmal für dieses FHEM Modul!

Gruß
Zwiebel

[B50one]

Hallo Daniel,

ich möchte an dieser Stelle meine Erfahrungen mit dem Monitor aufzeigen.

Was ich sagen kann, die Abfragen von 1-Wire (1W.T_Zirko) Elementen wird beeinflusst.

Habe es auch mit mehreren 1-Wire Elementen getestet, dass Ergebnis war immer gleich. 

Es wird das Device zuerst auf alive gesetzt, nach Ablauf der Zeit auf dead und verbleibt dort.

Daten werden von diesem Device auch nicht mehr geschrieben.

Sie Anhang.

Gruß Klaus

[Dennis G]

Hallo Klaus,

ich habe bei mir 1-Wire nur über die HMS Emulation des CUNO laufen, dort noch keine Probleme feststellen können.

Verwundern tut mich der Bericht insofern das der DeviceMonitor mit dem überwachtem Gerät nichts macht, er reagiert 

lediglich auf die Ereignisse die dieses Gerät erzeugt.

Hast du mehrere 1-Wire Sensoren gleichzeitig im Betrieb und kannst du mal bei einem dem DeviceMonitor aktivieren und bei den 

anderen nicht ? Interessant wäre ob beide ausfallen oder nur der überwachte.

Hilfreich wäre es weiterhin wenn das noch jemand mit 1-Wire im "Direktbetrieb" dieses Problem testen und bestätigen könnte.

Kannst du mir noch schreiben über welches Modul du die 1-Wire Daten erhälst und über welche Schnittstelle ?

Ich bin jetzt leider erstmal auf reisen und werde erst mitte nächster Woche dazu kommen mich mit dem Problem zu beschäftigen, 

vielleicht hat ja bis dahin schon jemand weitere Infos für mich.

Schöne Grüße ...

Dennis

[B50one]

Hallo Dennis,

ich habe neun 1-Wire Sensoren im System integriert.

Wenn ich alle aktiviere fallen auch alle aus ;-(

Ich benutze folgenden USB Adapter: http://www.fuchs-shop.com/en/shop/17/1/13372210/

Nutze alle Module von Peter A. Henning. OWX, OWID, OWTHERM. 

Weiterhin ist folgendes auffällig. Wenn ich die fhem.cfg über einen reread neu lade kommen Fehlermeldungen auf

und der Monitor wird nicht neu gestartet. Da hilft nur ein shutdown restart. 

Gruß Klaus

Hier noch einige Auszüge.

Nach einem reread kommen folgende Meldungen auf.

[Dennis G]

Hallo Klaus,

ich habe das Problem ermitteln können, die OW Module und DeviceMonitor wollen den gleichen Zeitgeber beanspruchen...Das funktioniert nicht so gut :-)

Ich habe Rudi um Rat gefragt ob und wie dieses Problem am besten umgangen werden kann, bis zur umsetzung kann es auch noch etwas dauern.

Ich melde mich sobald ich eine Lösung oder andere eindeutige Infos habe.

Vielen dank nochmal für die Meldung des Problems und die Teilnahme am Test!

Dennis 

[Jörg Do.]

Hallo,

bei mir funktioniert das Modul inklusive Versand einer Mail auch prima. Habe zwar nur ein Außensthermometer an einer FB 7390 mit CUL , aber egal.

In diesem Zusammenhang habe ich erkannt, dass dieses Modul ausschließlich für die Überwachung von Devices gut ist, die regelmäßig Daten senden. Ich habe aber ein anderes Problem: Ich betreibe vorrangig zeitgesteuerte Rolladenschalter von HM, welche mir in unregelmäßigen Abständen ein MISSING_ACK zurückgeben. Über diese Meldung möchte ich gerne per Mail informiert werden, damit ich diese dann manuell aus der Ferne hoch- bzw. runterfahren lassen kann. Vielleicht habe ich die Doku noch nicht komplett abgesucht, aber ich finde einfach keine Lösung mit Programmiervorschlag.

Hat jemand hierzu eine Idee oder soll ich einen eigenen thread aufmachen?

LG
Jörg