98_DeviceMonitor: Überwachung von Devices - Testuser gesucht

[Dennis]

                                                 

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

<https://lh4.googleusercontent.com/-18Ipjh3Oca4/UIupX2EtBgI/AAAAAAAAAfM/bgkqLsvciqs/s1600/screenshot.55.png>
- Ansicht Devicemonitor:

<https://lh5.googleusercontent.com/-pdQ5hsUuq00/UIupp15uXTI/AAAAAAAAAfU/Do1dIVj0GtM/s1600/screenshot.56.png>


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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[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 "./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



Am Samstag, 27. Oktober 2012 11:36:24 UTC+2 schrieb 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):
>
>
> <https://lh4.googleusercontent.com/-18Ipjh3Oca4/UIupX2EtBgI/AAAAAAAAAfM/bgkqLsvciqs/s1600/screenshot.55.png>
> - Ansicht Devicemonitor:
>
>
> <https://lh5.googleusercontent.com/-pdQ5hsUuq00/UIupp15uXTI/AAAAAAAAAfU/Do1dIVj0GtM/s1600/screenshot.56.png>
>
>
>
> #############################################################################################
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Puschel74]

                                               

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

Grüße

Am Samstag, 27. Oktober 2012 15:12:21 UTC+2 schrieb 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 "> ./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
>
>
>
> Am Samstag, 27. Oktober 2012 11:36:24 UTC+2 schrieb 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):
>>
>>
>> <https://lh4.googleusercontent.com/-18Ipjh3Oca4/UIupX2EtBgI/AAAAAAAAAfM/bgkqLsvciqs/s1600/screenshot.55.png>
>> - Ansicht Devicemonitor:
>>
>>
>> <https://lh5.googleusercontent.com/-pdQ5hsUuq00/UIupp15uXTI/AAAAAAAAAfU/Do1dIVj0GtM/s1600/screenshot.56.png>
>>
>>
>>
>> #############################################################################################
>>
>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dennis]

                                                 

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:
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">



das würde die Fehlermeldungen erklären

Gruß Dennis



Am Samstag, 27. Oktober 2012 15:25:56 UTC+2 schrieb puschel74:
>
> Hallo,
> achso ja tut mir leid.
> Plattform ist ein FB7390 mit 1 CUL und 2 CUNO und ein AVR Net IO.
>
> Grüße
>
> Am Samstag, 27. Oktober 2012 15:12:21 UTC+2 schrieb 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 ">> ./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
>>
>>
>>
>> Am Samstag, 27. Oktober 2012 11:36:24 UTC+2 schrieb 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):
>>>
>>>
>>> <https://lh4.googleusercontent.com/-18Ipjh3Oca4/UIupX2EtBgI/AAAAAAAAAfM/bgkqLsvciqs/s1600/screenshot.55.png>
>>> - Ansicht Devicemonitor:
>>>
>>>
>>> <https://lh5.googleusercontent.com/-pdQ5hsUuq00/UIupp15uXTI/AAAAAAAAAfU/Do1dIVj0GtM/s1600/screenshot.56.png>
>>>
>>>
>>>
>>> #############################################################################################
>>>
>>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[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

Am Samstag, 27. Oktober 2012 16:03:19 UTC+2 schrieb 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:
> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>
>
>
> das würde die Fehlermeldungen erklären
>
> Gruß Dennis
>
>
>
> Am Samstag, 27. Oktober 2012 15:25:56 UTC+2 schrieb puschel74:
>>
>> Hallo,
>> achso ja tut mir leid.
>> Plattform ist ein FB7390 mit 1 CUL und 2 CUNO und ein AVR Net IO.
>>
>> Grüße
>>
>> Am Samstag, 27. Oktober 2012 15:12:21 UTC+2 schrieb 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 ">>> ./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
>>>
>>>
>>>
>>> Am Samstag, 27. Oktober 2012 11:36:24 UTC+2 schrieb 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):
>>>>
>>>>
>>>> <https://lh4.googleusercontent.com/-18Ipjh3Oca4/UIupX2EtBgI/AAAAAAAAAfM/bgkqLsvciqs/s1600/screenshot.55.png>
>>>> - Ansicht Devicemonitor:
>>>>
>>>>
>>>> <https://lh5.googleusercontent.com/-pdQ5hsUuq00/UIupp15uXTI/AAAAAAAAAfU/Do1dIVj0GtM/s1600/screenshot.56.png>
>>>>
>>>>
>>>>
>>>> #############################################################################################
>>>>
>>>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Mitch]

                                                     

gerade installiert und funktioniert soweit.
Melde mich mich wieder in ein paar Tagen.


Am Samstag, 27. Oktober 2012 16:06:31 UTC+2 schrieb 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
>
> Am Samstag, 27. Oktober 2012 16:03:19 UTC+2 schrieb 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:
>> >> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>>
>>
>>
>> das würde die Fehlermeldungen erklären
>>
>> Gruß Dennis
>>
>>
>>
>> Am Samstag, 27. Oktober 2012 15:25:56 UTC+2 schrieb puschel74:
>>>
>>> Hallo,
>>> achso ja tut mir leid.
>>> Plattform ist ein FB7390 mit 1 CUL und 2 CUNO und ein AVR Net IO.
>>>
>>> Grüße
>>>
>>> Am Samstag, 27. Oktober 2012 15:12:21 UTC+2 schrieb 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 ">>>> ./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
>>>>
>>>>
>>>>
>>>> Am Samstag, 27. Oktober 2012 11:36:24 UTC+2 schrieb 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):
>>>>>
>>>>>
>>>>> <https://lh4.googleusercontent.com/-18Ipjh3Oca4/UIupX2EtBgI/AAAAAAAAAfM/bgkqLsvciqs/s1600/screenshot.55.png>
>>>>> - Ansicht Devicemonitor:
>>>>>
>>>>>
>>>>> <https://lh5.googleusercontent.com/-pdQ5hsUuq00/UIupp15uXTI/AAAAAAAAAfU/Do1dIVj0GtM/s1600/screenshot.56.png>
>>>>>
>>>>>
>>>>>
>>>>> #############################################################################################
>>>>>
>>>>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[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:
>
> 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):
>
>
> <https://lh4.googleusercontent.com/-18Ipjh3Oca4/UIupX2EtBgI/AAAAAAAAAfM/bgkqLsvciqs/s1600/screenshot.55.png>
> - Ansicht Devicemonitor:
>
>
> <https://lh5.googleusercontent.com/-pdQ5hsUuq00/UIupp15uXTI/AAAAAAAAAfU/Do1dIVj0GtM/s1600/screenshot.56.png>
>
>
>
> #############################################################################################
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dennis]

                                                 

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

Am Montag, 29. Oktober 2012 20:00:03 UTC+1 schrieb 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:
>>
>> 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):
>>
>>
>> <https://lh4.googleusercontent.com/-18Ipjh3Oca4/UIupX2EtBgI/AAAAAAAAAfM/bgkqLsvciqs/s1600/screenshot.55.png>
>> - Ansicht Devicemonitor:
>>
>>
>> <https://lh5.googleusercontent.com/-pdQ5hsUuq00/UIupp15uXTI/AAAAAAAAAfU/Do1dIVj0GtM/s1600/screenshot.56.png>
>>
>>
>>
>> #############################################################################################
>>
>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[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

Am Montag, 29. Oktober 2012 20:24:24 UTC+1 schrieb 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
>
> Am Montag, 29. Oktober 2012 20:00:03 UTC+1 schrieb 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:
>>>
>>> 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):
>>>
>>>
>>> <https://lh4.googleusercontent.com/-18Ipjh3Oca4/UIupX2EtBgI/AAAAAAAAAfM/bgkqLsvciqs/s1600/screenshot.55.png>
>>> - Ansicht Devicemonitor:
>>>
>>>
>>> <https://lh5.googleusercontent.com/-pdQ5hsUuq00/UIupp15uXTI/AAAAAAAAAfU/Do1dIVj0GtM/s1600/screenshot.56.png>
>>>
>>>
>>>
>>> #############################################################################################
>>>
>>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dennis]

                                                 

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
_"
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"}
<https://lh3.googleusercontent.com/-ZcMV98noSjY/UI9Uk1Wsb_I/AAAAAAAAAfk/3auBOv4W-dM/s1600/screenshot.59.png>
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*<http://fhem.svn.sourceforge.net/viewvc/fhem?view=revision&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


Am Dienstag, 30. Oktober 2012 00:23:05 UTC+1 schrieb 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
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dennis]

                                                 

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

Am Dienstag, 30. Oktober 2012 15:54:20 UTC+1 schrieb 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?
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com