ElabNET Technik Forum

Hallo zusammen, gibt es eine Möglichkeit den online Status von 1-wire Geräten zu überwachen?
Die interne 1-wire Schnittstelle ist bei mir schon ein paar mal komplett ausgefallen ohne das ich es mitbekommen habe.
Aktuell sind laut Anzeige 29/40 Geräte online. Die bussauslastung ist 75%.
Sobald ich zwei weitere DS18B20 Sensoren anschließe fällt der Bus sporadisch aus. Das ist sehr unschön weil ich es aktuell nicht mitbekomme wenn ich nicht aktiv nachschauen.

Im voraus vielen Dank für eure Unterstützung

Vg
Uwe

Mein Vorschlag währe eine Logik je Gerät zur Überwachung zu verknüpfen
Sowie alle Ausgänge widerum in eine auswerte Logik mit reinpacken um die Menge sowie welcher ausgefallen ist als Anzeige zu haben

Ist zwar viel Fleißarbeit aber ich würde es so lösen wenn bei mir das Problem auftreten würde

Oder gleich von der ki eine Logik erstellen lassen die alles mit reinpackt
Gib ihr nur alle Infos die du überprüfen möchtest und sie schreibt dir die Logik komplett wie du es haben möchtest samt Nummern der Geräte samt Beschriftung damit du auch den richtigen verknüpfst

Weiterhin liest ja die ki bei der richtigen Übergabe der Daten zur Erstellung der Logik die abfrageintervale mit aus und kann eine zeittrigger mit einbauen je Gerät das du überprüfen möchtest mit einigem zeitversatz wegen Abfrage Überschneidungen

Weiterleiten in eine oder mehrere zeitserien oder gleich auf Telegram weiterleiten lassen oder wo auch immer du es haben möchtest

So währe mein Ansatz der mir spontan einfällt

Hallo Uwe,

bitte füge dem Betreff die aktuelle Version deines TWS hinzu. (siehe Forenregeln)

Danke

Beste Grüße
Jens

@eib-eg vielen Dank für die Antwort. Vielleicht ist das ein guter Grund sich in das KI Thema einzuarbeiten . Ich verstehe allerdings noch nicht was ich überwachen soll?
Aus meiner Sicht bleiben die ausgangswerte auch bei offline Geräten auf dem letzten Wert stehen. Was allerdings auch ein Zustand im online betrieb sein kann. Ich bräuchte eine Möglichkeit den Geräte Status oder den zeitstempel der letzten Aktualisierung zu überwachen.

Wenn eine Logik durch einen Eingangswert getriggert wird, lässt sich das in Logiken auswerten. Insofern kann eine Logik erkennen ob ein Messwert am Eingang der Logik ankam, unabhängig davon ob es einen Wertwechsel gab. Fehlt ein eingehender Wert nach einem bestimmten Zyklus scheint der Sensor wohl offline zu sein.

Vielen Dank für die Erklärung. Daran habe ich nicht gedacht. Ich schau mal ob man damit eine funktionierende Überwachung realisieren kann.

Ich werde mich heute Abend mal damit auseinandersetzen

Das einzige was dir dazu fehlt wenn du es mit ki machen möchtest,
ist mein oder ein gut funktionierender timberwolflogik promt

@eib-eg :dann schon mal vielen Dank im Voraus. Ich habe mehrere Versuche unternommen. Keine der logiken ist aber durch den parser gekommen und meine programmierkentnisse im Bereich der Custom logiken sind noch zu schwach

@Uwe303
ihr kennt mich wenn es um anleitungen geht
ab hier KI text
______________________________________

Hallo zusammen,

als Antwort auf die Frage von @Uwe303 (Erkennung 1-wire device offline) habe ich mich des Themas angenommen. Das Problem ist ja bekannt: Wenn ein Sensor ausfällt, bleibt der letzte Wert oft einfach stehen. Eine Logik, die nur auf "Änderung" (c) triggert, merkt das nicht.

Zusammen mit meiner "KI-Abteilung" habe ich eine robuste Watchdog-Logik entwickelt, die bis zu 8 Sensoren gleichzeitig überwacht und detaillierte Diagnose-Daten liefert.

Das Problem

1-Wire Sensoren senden zyklisch (z.B. alle 60s oder 300s), auch wenn sich der Wert nicht ändert. Wenn ein Sensor schweigt, muss ein Alarm losgehen. Da aber jeder Sensor ein anderes Sendeintervall haben kann (Sendefilter i), braucht jeder Kanal seinen eigenen "Countdown".

Die Lösung: Der 8-fach Watchdog (V1.3)

Diese Logik überwacht 8 Eingänge unabhängig voneinander.

Die Features:

Individuelle Timeouts: Jeder der 8 Sensoren hat einen eigenen Parameter für die Wartezeit.

Sammelstörung: Ein Ausgang (Alarm Sammel), der sofort TRUE wird, wenn irgendeiner der Sensoren ausfällt.

Fehlerzähler: Ein Ausgang (Anzahl Fehler), der sagt, wie viele Sensoren fehlen.

Bitmaske: Ein Ausgang (Bitmaske), der für die Visu oder Grafana genau codiert, wer fehlt (Bit 0 = Sensor 1, Bit 1 = Sensor 2, usw.).

WICHTIG: Die "Stolperfalle" beim Testen (Doktor-Modus)

Wenn ihr die Logik einrichtet und testet, werdet ihr vielleicht über ein Verhalten des Timberwolfs stolpern, das mich kurz Zeit gekostet hat:

Das Phänomen:
Ihr ändert im Doktor-Modus die Timeout-Zeit (z.B. von 600s auf 10s), um den Alarm zu testen, aber der Alarm kommt nicht nach 10 Sekunden, sondern erst viel später.

Der Grund:
Die internen Timer (Monoflops) übernehmen die neue Zeit NICHT sofort, wenn sie bereits laufen! Ein Timer, der mit 600s gestartet wurde, läuft diese 600s gnadenlos zu Ende, auch wenn ihr im Parameter inzwischen "10s" eingetragen habt.

Die Lösung:
Eine Zeitänderung wird erst beim nächsten Signal des Sensors wirksam (Retrigger).

Entweder: Warten, bis der alte Timer abgelaufen ist.

Oder: Den Sensor zwingen, einen Wert zu senden (oder im Doktormodus den Eingangswert kurz ändern), damit der Timer mit der neuen Zeit neu gestartet wird.

Anleitung zur Einrichtung

Logik importieren: Die JSON-Datei im Anhang herunterladen und importieren.

Eingänge verknüpfen: Zieht eure 1-Wire Sensoren auf die Eingänge 1 bis 8.

WICHTIG: Ihr müsst den Trigger-Modus der Eingänge zwingend auf "a" (Always / Immer) stellen! Nur so bekommt die Logik mit, dass der Sensor "lebt", auch wenn die Temperatur gleich bleibt.

Timeouts setzen: Schaut im Gerätemanager nach dem Sendefilter (i-Wert) des Sensors.

Faustformel: Timeout = i-Wert * 3.

Beispiel: Sensor sendet alle 60s -> Timeout auf 180s oder 200s stellen.

Nicht genutzte Kanäle: Wenn ihr nur 5 Sensoren habt, lasst die anderen Eingänge offen. Damit sie keinen Alarm auslösen, setzt deren Timeout auf eine sehr hohe Zahl (oder ignoriert die Bits in der Auswertung).

Viel Erfolg beim Überwachen!


______________________
ende ki text

Anhang:

ihr wisst
ab hier ki text nach vorgabe
____________________________


Update

1-Wire Watchdog 8-fach V2.0 (Auto-Disable) + Profi-Strategie zur Bus-Diagnose

Hallo zusammen,

nach dem Erfolg der V1.3 habe ich (zusammen mit meiner KI-Abteilung ) die Logik noch einmal auf die Hebebühne geholt. Das Ziel war mehr Komfort und weniger Konfigurationsaufwand.

Hier ist die Version 2.0 des 1-Wire Wächters.
Was ist neu in V2.0? (Das "Smart-Update")

In der alten Version musste man nicht genutzte Eingänge mühsam "ruhigstellen". Das ist jetzt vorbei.

Auto-Disable Funktion:
Der Standard-Wert für den Timeout ist jetzt 0.

Steht der Timeout auf 0, ist der Kanal komplett deaktiviert. Er löst keinen Alarm aus und beeinflusst die Statistik nicht.

Erst wenn ihr eine Zeit eintragt (z.B. 300), wird der Kanal "scharf" geschaltet.

Flexibilität:
Ihr könnt denselben Baustein nutzen, egal ob ihr 1, 3 oder 8 Sensoren überwachen wollt. Einfach importieren, Sensoren verknüpfen, Zeiten setzen – der Rest bleibt automatisch stumm.

Der Profi-Tipp: Die "Kanarienvogel-Strategie" (Bus-Diagnose)

Anstatt nur wild 40 Sensoren zu überwachen, könnt ihr diese Logik nutzen, um eure Topologie (Verkabelung) zu überwachen, besonders wenn ihr einen PBM (Professional Busmaster) mit mehreren Kanälen nutzt.

Die Idee:
Ihr nutzt eine Instanz dieser Logik als "Master-Wächter".

Ihr nehmt pro Bus-Strang (Kanal 1, 2, 3...) nur einen strategisch wichtigen Sensor (am besten den letzten im Strang) und legt ihn auf diese Logik.

Das Szenario:

Fällt ein einzelner Sensor in einer Raum-Logik aus -> Sensor defekt.

Schlägt aber dieser "Master-Wächter" auf Eingang 1 an -> Achtung: Der komplette Strang 1 ist tot! (Kabelbruch, Sicherung, PBM-Kanal).

So unterscheidet ihr blitzschnell zwischen "Bauteil kaputt" und "Anlage steht".
Kurzanleitung V2.0

Code importieren: Siehe Anhang.

Trigger: Die Eingänge der Sensoren zwingend auf "a" (Always) stellen!

Aktivieren:

Kanal nutzen? -> Timeout auf 3x Sendeintervall setzen (z.B. 300).

Kanal nicht nutzen? -> Timeout auf 0 lassen.

Hinweis zum Testen: Wenn ihr im laufenden Betrieb die Zeit ändert (z.B. von 600 auf 10s zum Testen), greift das erst beim nächsten Signal des Sensors.

Viel Erfolg mit der V2.0!

________________
ende ki text

Anhang: