OWX: Reset failure on bus 1wireBus

[Tobias]

Hallo,
ich habe öfters mal den u.g. Fehler. Der Fehler wird dann sekündlich im Log geloggt und müllt es auch damit zu. In diesem Fehlerfall ist FHEM per webif nicht mehr ansprechbar. Bisher half leider nur fhem neu zu starten. Danach ging es wieder.
Die frage ist:
1. woher könnte soetwas kommen?
2. Kann oWX das selbstständig lösen? Nach einem Restart funkts ja wieder..

Code Auswählen Erweitern

OWX: Reset failure on bus 1wireBus

Gruss

[det.]

Hallo Tobias,
Bei mir ist selbiger Sachverhalt weg, seit ich den 1-wire Bus konsequent linearisiert habe ( wilde Abzweigungen [ stubs ] entfernt ). Das ging u.a. durch Aufteilung auf zwei USB Adapter. Seit dem ist auch die an den DS2438 gemessene Busspannung näher an 5V.

[Tobias]

mein Bus ist auch streng linearisiert, keine Abzweigungen innerhalb eines Bus-Stranges länger als 50cm. Ich setze den USB-Buskoppler und den 1wireHub von eservice-online ein. Läuft es mit owserver statt owx (in kombination mit den pah-Modulen owcount,owswitch etc) besser?
Folgende Devices:

Code Auswählen Erweitern

OWX: 1-Wire devices found on bus 1wireBus
20.50310C000000      DS2450     Bodenfeuchte
20.30D70F000000      DS2450     Wasserdruck
20.23B214000000      DS2450     1wire_Hub
28.08A22A040000      DS18B20    Gaestezimmer_Raumtemp
28.38C02A040000      DS18B20    Oelkeller_Raumtemp
28.DAA12A040000      DS18B20    BadezimmerKG_Raumtemp
28.7AB82A040000      DS18B20    Naehzimmer_Raumtemp
28.86F2AC030000      DS18B20    Heizung_Raumtemp
28.B6A92A040000      DS18B20    Waschkueche_Raumtemp
28.F9C3AC030000      DS18B20    Garage_Raumtemp
28.F5B62A040000      DS18B20    Keller_Eingangstuer_Raumtemp
12.A0AE7B000000      DS2406     BadezimmerKG_Fenster
12.60F17B000000      DS2406     Heizung_Fenster
12.2AAF7B000000      DS2406     Oelkeller_Fenster
12.061B7D000000      DS2406     Garage_Tor
12.BE5B92000000      DS2406     Gaestezimmer_Fenster
12.45AF7B000000      DS2406     Naehzimmer_Fenster
12.B3F17B000000      DS2406     Garage_Tuer
12.D75592000000      DS2406     Waschkueche_Fenster
12.B7EA7B000000      DS2406     Garage_Fenster
12.F71A7D000000      DS2406     Oelkeller_Tuer
12.6F5B92000000      DS2406     Keller_Eingangstuer
3A.2F5503000000      DS2413     Heizung_Steuerung
29.F4D210000000      DS2408     Schalter_links
29.8DDA10000000      DS2408     Schalter_rechts
1D.FEC30D000000      DS2423     Wasserzaehler

[Prof. Dr. Peter Henning]

Ob das "besser" läuft, muss jeder selbst beurteilen. Dass beim OWServer diese Fehlermeldungen nicht geloggt werden, heißt ja nicht, dass die Fehler nicht auftreten - sie werden nur von OWFS versteckt.

"Reset failure" deutet auf jeden Fall auf ein Hardwareproblem auf dem Bus hin. Das kann durchaus mit der Bus-Größe zusammenhängen, z.B. kann es vorkommen, dass bei einem sehr langen Bus der Widerstand des Kabels verhindert, dass der Reset-Puls von allen angeschlossenen Devices erkannt wird.

Wie hoch (und wie stabil ?) ist die Versorgungsspannung (am Ende des Bus !)?

LG

pah

[ntruchsess]

Hallo Peter,

vieleicht könnte man bei der Weiterentwicklung von OWX ja zusammenarbeiten - ich würde das gerne auf asynchrone Verarbeitung umbauen, das würde jeden Einfluss des Zeitverhaltens von OWX auf alles was im FHEM sonst noch so läuft ausschließen.

Ist schon klar - das löst natürlich kein physikalisches Problem auf dem 1-Wire Bus, aber es ist auch ziemlich ärgerlich wenn so ein Problem die FHEM-main-loop ausbremst.

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Kann man gerne machen - aber das "Ausbremsen" sehe ich bisher nicht. Ich habe 4 verschiedene 1-Wire-Bussysteme an meinem RPi, und sehe da keine Bremsprobleme.

LG

pah

[Tobias]

Naja, ich habe o.a. Devices bei denen die meisten alle 5-10sek abgefragt werden. Im Fhem Webif habe ich bei jeden Klick Wartezeiten bis zu 5sek :(

[ntruchsess]

das 'Ausbremsen' ist ja glücklicherweise auch nicht der Normalfall ;-)

Wie können wir da effektiv zusammenarbeiten? Im SVN-trunk kann man ja keine Zwischenstände committen ohne dass der code instabil wird. Ich würde vorschlagen mit SVN Branches zu arbeiten in die jeder seine Änderungen commitet und die des anderen jeweils merged bevor das Ergebniss dann im Trunk landet. Wobei das im fhem-svn bisher ja noch leider gar nicht gelebt wird. (Warum eigentlich nicht?)
SVN aber leider nicht besonders stark darin wechselseitig Änderungen zwischen 2 Branches hin- und her zu mergen (seit SVN 1.7 klappt es so einigermaßen, jedenfalls wenn man nicht vergisst die SVN-properties immer brav mit zu mergen). Wenn da mal was falsch läuft kriegt man die eigenen Änderungen beim zurückmergen als Conflikt angezeigt (auch wenn es in Wirklichkeit gar keiner ist).

Die Alternative dazu wäre jeder forked sich den FHEM-mirror auf Github (https://github.com/mhop/fhem-mirror.git) und commitet seinen aktuellen Stand (auch wenn er noch nicht stabil ist) in seinen Fork. Damit kann jeder sehen, was der ander gerade macht und Ich könnte meine Änderungen auf deinen jeweiligen Arbeitsstand anpassen. Das zusammenmergen kann man mit Git entweder einfach selber machen (indem man sich den fremden remote-branch mit 'git pull' ins eigene Repository holt) oder über Gitgub aktiv per pull-request dem andern schicken. Wenn das Ergebniss dann stabil ist, committest Du das Ergebniss in den svn-trunk. Das schöne an Git ist, dass jeder die volle Hoheit über sein Repository hat - da muss keiner befürchten, dass jemand anders etwas commitet, was mit dem eigenen Arbeitsstand nicht zusammenpasst. Wenn es nicht passt, dann kommentiert man einfach den entsprechenden Pull-request und der Ersteller des Pull-requests bessert nach... (Das wäre in diesem Fall in der Regel natürlich ich...)

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Na, dann würde ich mal ausrechnen, was das für einen Traffic auf dem Bus macht ...

Wundert mich nicht, dass es da Kollisionen gibt.


Und die Wartezeiten sind sicher nicht die Schuld von OWX.

LG

pah

[Prof. Dr. Peter Henning]

Nö, lieber nicht bei einem öffentlichen Server.

Ich kann einen Zugang öffnen in einem meiner Server, die im Netz stehen. Kann ich heute abend schicken (aber nur per direkter eMail, bitte...)

LG

pah