Status soll Farbe ändern wenn er nicht aktualisiert wird.

[tomleitner]

Hallo,

Nun habe ich also alle möglichen Sensoren in meine FHEM Installation integriert ... von FS20 Temperatur über Shelly H&T uns selber gebaute Raspberry PIs mit einigen Sensoren. Alle zeigen brav in einer Übersichtsseite ihren Status und damit ihre Werte an.

Jeder Sensor hat sein eigenes Update Interval ... von 1 Minute bis tlw. 1 Stunde.

Nun will ich erreichen dass der STATE in ROT dargestellt wird wenn er eine bestimmte Zeit lang NICHT aktualisiert wurde ... einfach um anzuzeigen dass  der Wert bereits zu alt ist!!

Wie erreiche ist das?  Das sollte wohl eine standard Aufgabenstellung sein nicht?

Danke und Ciao // Tom

[Byte09]

Hallo,

Nun habe ich also alle möglichen Sensoren in meine FHEM Installation integriert ... von FS20 Temperatur über Shelly H&T uns selber gebaute Raspberry PIs mit einigen Sensoren. Alle zeigen brav in einer Übersichtsseite ihren Status und damit ihre Werte an.

Jeder Sensor hat sein eigenes Update Interval ... von 1 Minute bis tlw. 1 Stunde.

Nun will ich erreichen dass der STATE in ROT dargestellt wird wenn er eine bestimmte Zeit lang NICHT aktualisiert wurde ... einfach um anzuzeigen dass  der Wert bereits zu alt ist!!

Wie erreiche ist das?  Das sollte wohl eine standard Aufgabenstellung sein nicht?

Danke und Ciao // Tom

ohne weitere infos, was genau der state in den jeweiligen fällen beinhaltet würde ich das ggf mit 'stateformat' in abhängigkeit mit 'readingsAge' umsetzen .

ReadingsAge(<devicename>,<reading>,<defaultvalue>)
gibt das Alter des Readings in Sekunden zurück.

stateFormat
Ändert den Gerätestatus, dies ist z.Bsp. in der Ausgabe des list Kommandos zu sehen, oder in der Raumübersicht von FHEMWEB. Falls nicht gesetzt, dann wird das state Reading übernommen. Sonst werden alle Wörter im Wert des Attributes durch das entsprechende Reading des Gerätes ersetzt (soweit vorhanden). Falls der Wert in {} eingeschlossen ist, dann wird es als Perl Ausdruck ausgewertet. Die Auswertung passiert bei jeder Änderung eines Readings.
Die hier beschriebene "set magic" wird auch angewendet.

gruss Byte09

[rudolfkoenig]

Fuer die Anzeige in FHEMWEB bitte statt stateFormat lieber devStateIcon oder devStateStyle verwenden, da stateFormat auch die Daten fuer telnet/FileLog/Value()/jsonList/etc liefert.

[tomleitner]

Danke Euch ... ich schau mir das mal an und poste meine Lösung sofern ich eine finde ...

[tomleitner]

Hallo,

Hab mir das nun angeschaut und es scheint reichlich kompliziert zu sein. Hier hat das jemand mit einem periodischen AT gemacht:

http://www.linuxfun.de/homeautomation/fhem/batterieueberwachung-in-fhem/

Allerdings würde ich dann für jedes device ein solches brauchen, was mir zu aufwendig erscheint.

Schreit das nicht nach einer kleinen FHEM Erweiterung ca. so:

attr device stateTimeoutColor timeout color

Timeout wäre in Sekunden, Color wäre eine Farbe. Wenn State nach timeout Sekunden nicht aktualisiert wurde, wird er auf Color gesetzt. Nach der nächsten Aktualisierung wieder auf die ursprüngliche Farbe.

Geht das leicht zu implementieren ?

Thx. Tom

[Byte09]

Hallo,

Hab mir das nun angeschaut und es scheint reichlich kompliziert zu sein. Hier hat das jemand mit einem periodischen AT gemacht:

http://www.linuxfun.de/homeautomation/fhem/batterieueberwachung-in-fhem/

Allerdings würde ich dann für jedes device ein solches brauchen, was mir zu aufwendig erscheint.

Schreit das nicht nach einer kleinen FHEM Erweiterung ca. so:

attr device stateTimeoutColor timeout color

Timeout wäre in Sekunden, Color wäre eine Farbe. Wenn State nach timeout Sekunden nicht aktualisiert wurde, wird er auf Color gesetzt. Nach der nächsten Aktualisierung wieder auf die ursprüngliche Farbe.

Geht das leicht zu implementieren ?

Thx. Tom

es gibt so viele Möglichkeiten das mit relativ geringem Aufwand zu realisieren , das m.E die Notwendigkeit nicht besteht, zumal das ja bedeuten würde - glaube ich  -, das generell zyklisch eine Aktion - ähnlich 'event-min-intervall' - ausgelöst werden müsste , ohne dass sich im grunde etwas geändert hat an dem states , um diese prüfung des timeouts zu veranlassen und ggf. den state anzupassen - ich schätze mal das wäre eine deutlich spürbare Belastung der Resourcen  ?!

- lösbar über devstateicon ... wie von rudolf angemerkt
- lösbar über Hilfsmodul , welches periodisch prüft ( auch mit nur einem Device möglich )
- lösbar über userreadings
etc.pp

gruss Byte09

[KernSani]

Schau dir mal das Monitoring-Modul an. Das übernimmt den Monitoring-Teil. Was bei erkanntem Alarm passiert kannst du dann selbst definieren.


Kurz, weil mobil

[Tom111]

Die beste und einfachste Lösung, die ich schon seit Jahren verwende und die bisher IMMER zuverlässig funktioniert hat, ist der Code von dem User "Noname":
https://forum.fhem.de/index.php/topic,15173.msg261574.html#msg261574

[PatrickR]

Polling ist natürlich nur die zweitschönste Lösung. Eleganter, wenn auch mit höherem einmaligen Aufwand kann man das mit einem generischen DOIF lösen, das einem dann idealerweise auch die Pflege von Devicelisten spart.


Von unterwegs gesendet.

[tomleitner]

Danke euch allen ... ich schau es mir nochmal an und melde mich welche Lösung dann geklappt hat ....

[Prof. Dr. Peter Henning]

Schreit das nicht nach einer kleinen FHEM Erweiterung

Wir freuen uns immer, wenn relative Neulinge nach Erweiterungen "schreien"...

Ich halte es für komplett unergonomisch, eine solche Warnung durch eine Farbe zu signalisieren. In einem solchen Fall müsste besser ein Event ausgelöst werden, der auch an anderer Stelle verarbeitet werden kann. Dafür gibt es eine Vielzahl von Modulen, di ein den obigen Antworten genannt worden sind.

Darüber hinaus ist es m.E. vollkommen sinnlos, die Zustandsüberwachung mit timeout für jeden Sensor oder Aktor durchzuführen - so etwas sollte die Zentrale nur punktuell machen.

LG

pah