Geräte "Alive" Überwachung - Wie habt ihr es gelöst?

[chunter1]

Ich suche eine möglichst einfache und universelle Möglichkeit verschiedene Gerätetypen (Homematic, Jeelink, ESPEasy, Xiamo etc.) auf ihre Funktion zu überwachen.
Gibts dafür evtl ein Modul das schon auf die Besonderheiten der verschienen Typen getrimmt ist?
Wie habt ihr das umgesetzt?

[chunter1]

Gut, dann quatsch ich einfach mal mit mir selbst.
Wenn alle Geräte/Module zwingend ein einheitliches "Standard" reading "presence" o.ä. hätten, wäre die Überwachung ein Kinderspiel oder seh ich das falsch?
Jedes Geräte-Modul weiß doch selbst am besten, wie oft welche message vom device kommen muss bevor es von "alive" auf "dead" gesetzt wird?

Alternativ könnte natürlich eine eigene Funktion erstellen die alle Geräte in FHEM überwacht  - das ist aber mühsam, fehleranfällig und man vergisst bei Änderungen schnell die Funktion anzupassen.

[Beta-User]

Moin, dann quatsch ich halt mal hier mit...

Also: Es gibt ein Modul namens monitoring: https://fhem.de/commandref_DE.html#monitoring, das aber nicht speziell auf alive oder dead zugeschnitten ist und alles Mögliche überwachen können sollte.

Was es nach meiner Kenntnis nicht gibt, sind einheitliche Readings oder auch nur state-Inhalte. Ich habe mir daher z.B. für meine MySensors-Nodes eine ReadingsGroup gebastelt, die nur dann was anzeigt, wenn eine auf Fehler geht (was allerdings im regulären Betrieb schon lange nicht mehr vorgekommen ist).
Für HM (@CUL_HM) gibt's den AcctionDetector (den ich aber auch nicht wirklich nutze, weil die HM-Dinger auch zuverlässig laufen, solange die Batterie mitmacht, aber das ist ja wieder ein anderes Thema).

Einheitlichkeit wäre was für den Developer-Bereich bzw. die Wunschliste, aber m.E. lohnt der Aufwand nicht; dazu sind die Anforderungen und Erkenntnismöglichkeiten für jeden Gerätetypen/jedes Protokoll vermutlich zu verschieden.

Gruß,
Beta-User

[bartman121]

Wie oft kommen denn solche "Ausfälle" vor und vor allem was tust du dann?
Das Problem bei solchen überwachungen ist doch, dass man vorher nicht weiß wie sich ein Fehler äußert.

Wenn du immer wiederkehrende Ausfälle hast, dann solltest du die Ursache beseitigen.

[viegener]

Einfach nur als Anregung mein Ansatz:

Ich habe immer erst wenn etwas unvorhergesehens (Ausfall, Fehler, etc) passiert ist, mir überlegt, ob sich das entsprechend automatisiert erkennen lässt.

Dann habe ich für diesen Fall eine spezifische Überwachung eingerichtet (üblicherweise per notify oder watchdog etc)
(Warum nicht monitoring - wieder eine eigene Syntax und ich hatte damals nicht gesehen, wie das Ausbleiben eines Events oder gar eine Kombination leicht zu überwachen ist)

Alle diese Überwachungsroutinen verwenden ein paar gemeinsame Skriptzeilen, um Fehler zu melden

Diese Skriptzeilen packen alle Alarme in eine readingsHistory zusätzlich alarmieren sie aber auch aktiv über verschiedene Kanäle, je nach Typ des Alarms (Telegram msg, Audiomeldung)

Hintergrund:
- Vordenken von Ausfällen fand ich schwierig, deshalb habe ich mich für reagieren entscheiden (Ausnahme sind z.B. Batteriewarnungen). Von testen gar nicht zu reden.
- Bekannte Mechanismen (notfiy, watchdog, DOIF) sind für mich einfacher, da ich sie für viele Fälle nutze
- Zentrale Benachrichtigung (mit Skript) kam erst dazu, als es eine ganze Reihe von Alarmen gab und ich vereinheitlichen wollte (und weniger tippen)

[Damian]

Man könnte einmal pro Tag abfragen, welche Devices schon länger nicht gesendet haben (die sonst regelmäßig senden):

Code Auswählen Erweitern

define ausfall DOIF ([18:00]) (set pushbullet massage Folgende Devices sind ausgefallen [@""::ReadingsAge($name, "temperature", 0) > 3600,"alle OK"])
attr ausfall do always


Hier werden alle Devices aufgezählt, deren temperatur-Reading länger als eine Stunde nicht aktualisiert wurde.

Man kann die Auswahl an Devices per Regex einschränken oder andere Readings abfragen.