1-Wire Monitor

[mivola]

ich habe das Plugin und die Config eben auf GitHub gestellt und Pull Requests gestellt.

Ich hab das Update bei mir eingespielt und es funktioniert. Warnungen hab ich bis jetzt nicht gesehen. Von daher bin ich mal so frei und versuche mal den Pull Request zu bearbeiten. Wird auch mein erstes Mal ;-)

VG
Micha

[Dirk42]

Hallo Micha,

mal sehen ob's geklappt hat - ich habe das Plugin und die Config eben auf GitHub gestellt und Pull Requests gestellt.

Viele Grüße

Dirk

[mivola]

Hi Dirk,

danke erstmal fürs Beheben der Probleme. Ich denke es wäre trotzdem sinnvoll den Code in Github zu bringen, dort kann dann jeder darauf zugreifen, verbessern und v.a. auch die Historie sehen...
Wenn es OK für dich ist, kann ich das auch übernehmen.

VG
Micha

[Dirk42]

Hallo Micha,

bisher gab es so wenige Rückmeldungen, dass ich das Plugin noch nicht auf github hochgeladen habe. Ich habe den aktuellen Code im ersten Beitrag aktualisiert. Allerdings habe ich etwa "gepfuscht", indem ich die Unterroutine einfach inline eingefügt habe, damit umgehe ich die entsprechenden Perl Warnungen... aber einen kleinen Bug habe ich dank der Warnungen gefunden und gefixt

Viele Grüße

Dirk

[mivola]

Dirk42 Ich hatte irgendwo gelesen, dass du die Warnungen, die das Script erzeugt (und seit 1.2.6 im WG angezeigt werden) behoben hast. Könntest du das Script in github bitte hochladen?

Danke!
Micha

[mivola]

Die Frage ist daher, wo wir die Schwelle ansetzen wollen - ich überlege, ob ein Zähler sinnvoll ist, damit man nicht von Fehlalarmen zugemüllt wird. Erst wenn x mal hintereinander falsche Werte kommen wird eine Warnung ins rsslog geschrieben?

Naja, ich denke damit sollte man am Anfang bissl rumspielen. Aber ich denke wenn mehr als 2-3x nacheinander was fehlerhaftes kommt, sollte man sich das anschauen...

Von Hand die genaue Sensorinfo zusammenbasteln ist wahrscheinlich auch etwas kompliziert... Kann man aus dem Script heraus die config anpassen, geht das? Dann könnte man vielleicht ein "Lernflag" setzen, ist das gesetzt wird die aktuelle Info in die config gespeichert und das Lernflag zurückgesetzt...

Das würde ich nicht so kompliziert machen. Ich denke es wäre ausreichend, wenn man sich als Nutzer einfach 1x den String ausm RSS kopiert, zB "Busmaster (DS1420): 3, Temp (DS1820): 19, I/O (DS2413): 12, DS2438: 14" und das in die Config einträgt.

VG
Micha

[Dirk42]

Hallo Micha,

wie StefanW geschrieben hat ist es völlig unkritisch, dass mal zwischendurch der ein oder andere Sensor fehlt oder kurz keine Info kommt. Er schreibt meine ich etwas von 1-2% Fehlerrate.

Die Frage ist daher, wo wir die Schwelle ansetzen wollen - ich überlege, ob ein Zähler sinnvoll ist, damit man nicht von Fehlalarmen zugemüllt wird. Erst wenn x mal hintereinander falsche Werte kommen wird eine Warnung ins rsslog geschrieben?

Von Hand die genaue Sensorinfo zusammenbasteln ist wahrscheinlich auch etwas kompliziert... Kann man aus dem Script heraus die config anpassen, geht das? Dann könnte man vielleicht ein "Lernflag" setzen, ist das gesetzt wird die aktuelle Info in die config gespeichert und das Lernflag zurückgesetzt...

Viele Grüße

Dirk

[mivola]

Hi,

Ich hätte noch eine Feature-Idee: ich fände es gut im RSS Log auf den ersten Blick zu erkennen (zb mittels Prefix), wann ein "fehlerhafter" Zustand erkannt wurde. Dazu müsste man eine Art Soll-Zustand (als String?) definieren und beim Schreiben des RSS-Logs entsprechend vergleichen.

Was sagt ihr dazu?

VG
Micha

[heckmannju]

Hi,
ich habe 5 Linien nur eine ist problematisch. Ich würde jetzt halt 4 Linien ausstecken.
Viele Grüsse
Jürgen

[Dirk42]

Hallo Jürgen,

ich zähle alle Sensoren am WG. Das ist einfacher als nach Linien zu analysieren - und für eine Einschätzung der Stabilität reicht das denke ich aus. Oder bringt es mehr nach Linien zu unterscheiden?

Viele Grüße

Dirk

[heckmannju]

Hi,
zählst du die Sensoren pro Linie oder alle Sensoren pro WG?
Viele Grüsse
Jürgen

[Dirk42]

Hallo,

ich habe grade V0.3 oben in den ersten Artikel kopiert: V0.3 zeigt nun auch den Professional Busmaster an - genauer gesagt drei DS2431 pro PBM.

Wer DS2431 anderweitig einsetzt kann bei Bedarf die Bezeichnung im Skript anpassen, einfach nach "P-Busmaster" suchen.

Viele Grüße

Dirk

[mivola]

Ich lese auch mit. Habs jetzt auch mal installiert ... Mal schauen was im RssLog die nächste Zeit so rauskommt...

Den Output von "owdir /uncached" direkt zu lesen fänd ich auch besser.

VG
Micha
PS: Danke für deine Mühen!

[henfri]

Ja, ich lese mit :-)

ein entfernter (d.h. auf einem anderen ow-server liegender) Bus taucht m.W. auch im Baum vom owdir auf, wenn entsprechend konfiguriert. So funktioniert m.W. der IP-Extender.

Gruß,
Hendrik

[Dirk42]

Irgendwie fühle ich mich ein bisschen alleine hier im Thread - ich hoffe es liest irgendwer mit

Ich bin absoluter OWFS-Newbie, daher grad erst aufgefallen: Statt den Output über http einzulesen, wärs sicher deutlich schneller einfach den Output von "owdir /uncached" zu lesen.
Das bedeutet aber, dass das Plugin auf dem gleichen WireGate laufen muss wie der OWFS. Gäbe es aus Eurer Sicht Anwendungsfälle, bei denen man einen "fremden" OWFS abfragen möchte...?