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..
OWX: Reset failure on bus 1wireBus
Gruss
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.
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:
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
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
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
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
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 :(
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 (//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
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
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