[gelöst] OWX-SER/OWID schaltet state auf „present“ obwohl DS2401 abgeklemmt ist

[Xaneu]

Hallo FHEM-Community,

ich betreibe ein 1-wire Netz an ein Raspberry Pi 4 über ein USB/RS232-1-wire Interface. Basis sind die Module (OWX-SER, OWTHERM, OWMULTI und OWID).
Momentan gibt es die Teilnehmer 3x DS18B20, 1x DS2438 und seit jüngster Zeit ein DS2401.
Den DS2401 betreibe ich an einem Leckage-Sensor, der diesen über ein Relaiskontakt (NO) im Falle einer Leckage mit dem 1-wire-Netzwerk verbindet. Hier ist meine Gedanke, dass ich im Falle einer Leckage durch das Emfangen der Seriennummer (ID) des DS2401 eine relativ sichere Information bekomme, dass eine Leckage auch tatsächlich existiert. U.a. sperre ich ggf. die Hauptwasserleitung mit einem Motorventil ab und möchte natürlich nicht, dass das wegen irgendwelchen Störungen unberechtigt passiert.

Nun zu meinem Problem. Es gibt jetzt ca. 2 mal am Tag eine Meldung, dass der DS2401 gefunden wurde. Erst dachte ich, dass der Relaiskontakt unberechtigt schaltet. Das war aber nicht der Fall. 'habe dann festgestellt, dass das sogar passiert, wenn ich den Leckagesensor samt DS2401 komplett vom 1-wire Bus trenne.
In der FHEM-Logdatei erscheinen ggf. immer folgende Meldungen in der dargestellten Reihenfolge und mit gleichem Zeitstempel:

OWX_SER::Search reset failed on bus OWire
Leckage in der Waschküche!

Es sieht also so aus, dass es zu einem Bus-Reset kommt und dadurch das Reading „state“ des Sensors kurzzeitig auf den Zustand „present“ gesetzt wird, obwohl der DS2401 überhaupt nicht mehr am Bus hängt.
Dass scheint mir ein Bug oder zumindest eine Schwäche zu sein, die mein Sicherheitgedanke (siehe oben) zu Nichte macht.
Meine relevanten Konfiguration zur Leckage-Erkennung sieht so aus:

Code: [Auswählen]

define OWire OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE06Krr-if00-port0

define Leckage_Waschkueche OWID DS2401 6520C1080000
attr Leckage_Waschkueche IODev OWire
attr Leckage_Waschkueche interval 10
attr Leckage_Waschkueche model DS2401
attr Leckage_Waschkueche stateFormat {ReadingsVal($name,"present",0) ? "present" : "not present"}

define Leckage_Waschkueche_Status dummy
attr Leckage_Waschkueche_Status devStateIcon trocken:ok feucht:fehler
attr Leckage_Waschkueche_Status setList trocken feucht
define Leckage_Waschkueche_Status_Init notify global:INITIALIZED set Leckage_Waschkueche_Status trocken

define Leckage_Waschkueche_ermitteln notify Leckage_Waschkueche:present.*1 {\
if (Value("Leckage_Waschkueche_Status") eq "trocken") {\
fhem("set Leckage_Waschkueche_Status feucht");;\
}\
}

Ich bin dabei meine 1-wire Verdrahtungstopologie zu optimieren, so dass es möglichst nicht mehr zu Resets in Folge von Störungen kommt.
Mir geht es hier aber in erster Linie darum, warum es zu dem Schaltereignis (trotz abgeklemmtem DS2401-Baustein) kommt und wie ich es abstellen kann, da ich davon ausgehe, dass es immer mal zu einer Störung auf dem Bus kommen kann.

Würde mich freuen, wenn jemand eine Idee oder Lösung hat.

P.S. Habe das FHEM-System vor ca. 3 Wochen komplett upgedatet, so dass es auf einem relativ neuen Stand ist.

[Prof. Dr. Peter Henning]

Erstens halte ich die Idee für Humbug, auf diese Weise eine Leckage feststellen zu wollen. Dafür nimmt man einen 1-Wire Switch, wie etwa einen DS2406. Auf diese Weise betreibe ich inzwischen 6 verschiedene Wasser-Warnmelder parallel an einem Bus, und zwar seit fast 10 Jahren.

Zweitens nehme ich an, dass die komische Mimik mit dem Relais am Bus für Fehler sorgt.

Drittens: Wenn in FHEM ein Gerät definiert ist (wie ein DS2401), versucht der Busmaster natürlich, das Gerät anzusprechen. Und geht erst in den "not present" Modus, wenn er keine Antwort bekommt. So ist das im Modul OWID gedacht, und so bleibt es auch.

LG

pah

[Xaneu]

Sehr geehrter Herr Prof. Dr. Henning,

erst ein mal vielen Danke für Ihre Antwort.
Ich schätze Ihre Arbeit für das FHEM-System (Module, Wiki-Beiträge und Einsatz im Forum) sehr und kann mir vorstellen, dass das viel Zeit in Anspruch nimmt.

zu 1.)
Ich werden den DS2401 für diesen Anwendung nehmen. Hatte mir inzwischen auch schon selbst überlegt, besser einen Baustein zu nehmen, der immer am Bus hängt. Wusste nicht, dass es auch auch einen bedrahteten Baustein mit GPIO im TO92-Gehäuse gibt, der parasitär versorgt werden kann. Umso einfacher wird für mich der Umbau.
Den Leckage-Sensor über einen DS2401, wie er hier gemäß Forum-Beiträge häufig auch als Fensterkontakt eingesetzt wird, ist wahrscheinlich wirklich nicht besonders sinnvoll, zu mal es auch andere Nachteile dabei gibt (https://forum.fhem.de/index.php/topic,29028.0.html).

zu 2.)
Ich gebe Ihnen Recht, dass beim Zuschalten des DS2401 über ein Relais alleine schon wegen des Prellens zu Störungen auf dem Bus kommen kann. Das ist im Falle des o.g. Fensterkontakts üblicherweise realisiert durch ein Reed-Kontakt genau so.
Allerdings möchte ich hier noch mal betonen, wie ich es schon in meinem ersten Beitrag explizit beschrieben hatte, dass das Verhalten auch auftritt, wenn ich den DS2401-Baustein samt dem Leckage-Sensor mit Relaisausgang komplett abklemme. Das Verhalten ist reproduzierbar.

zu 3.)
Ich habe den Eindruck, dass der Busmaster im Falle einer Störung („OWX_SER:: Search reset failed on Bus OWire“) versucht das Gerät anzusprechen und dabei das Reading “state” kurzzeitig in den “present”-Modus und anschließend in den Zustand “not present” geht. Zumindest reagiert mein notify Befehl bei oder nach dem Ereignis „OWX_SER:: Search reset failed on Bus Owire“ auf den “present”-Zustand des Geräts, obwohl der zugehörige Baustein physikalisch überhaupt nicht mehr am 1-wire-Bus hängt.

Ich hätte Verständnis dafür, wenn Sie sich nicht weiterhin mit 2./3. beschäftigen wollen.
Ggf. würde ich den Thread als [gelöst] kennzeichnen, da ich mit 1. eine gute Lösung hätte.

Gruß
Xaneu

[Prof. Dr. Peter Henning]

3) ist ganz richtig, das hatte ich oben schon geschrieben. Das ist kein Bug, sondern ein Feature.

2) kommt daher, dass im asynchronen Modus auf eine Antwort gewartet wird - von einem definierten Gerät, das nicht vorhanden ist.

LG

pah

[Xaneu]

Hallo Prof. Dr. Henning,

alles klar, ich hatte Ihre ersten Antwort (insb. 3.) offensichtlich nicht genau genug gelesen.
Und Danke für die Klärung. Jetzt gibt es hier Gewissheit und auch eine vernünftige Lösung (-> DS2406).

Gruß
Xaneu