1Wire Probleme

[Bartimaus]

MoinMoin,
ich habe meine (DS18B20) wilde Baum/Sternverteilung (ca 90m) via GPIO4 jetzt auf OWX-USB-Busmaster umgebaut. In diesem Zuge habe ich die Verteilung (3adrig, zZt 30m) auch so umgebaut, das es jetzt einen Strang ergibt an dem die Sensoren hängen (gem. Schaubild 3 http://www.fhemwiki.de/wiki/1-Wire_Busverlegung#Topologie ) . Nachdem das System erstmal viele Aussetzer hatte, habe ich jetzt testweise den Strang verkürzt und mehrere Sensoren abgeklemmt um evtl die Fehler eingrenzen zu können.

USB-Busmaster und Raspi hängen an einem aktivem USB-Hub.

Dennoch bekomme ich jetzt nach ca. spätestens 12h die ersten ERRCOUNT Meldungen an den einzelnen Sensoren (derzeit 13 Stck). Dabei wird auch der "TempLow"-Wert auf 70 zurückgesetzt. Irgendwann geht dann garnichts mehr.
Habt Ihr noch Tips ? So langsam beisse ich mir in den ***** weil ich die Regel "never change a running system" gebrochen habe 

[MadCat]

Kann es sein das Du keine Pullup Wiederstände verwendest und auch keine Entstörkondensatoren?

[Bartimaus]

Richtig.
Ich dachte das mit dem PullUp-Widerstand wäre nur bei GPIO4 nötig gewesen.
Wo sollte man den Widerstand+Entstörkondensator einbinden ?

[MadCat]

Zum entstören kannst Du an den einzelnen Sensoren 100nF anklemmen, bei den Pullup wirds schon schwieriger, mann kann nicht einfach wahllos irgend einen Wiederstand anbringen. Du must jeden Strang mit einem guten Messgerät die Spannung messen und den nötigen Ohmwert ermitteln.

[Bartimaus]

Ok. Mit den Entstörkondensatoren schaue ich mal.
Via GPIO4 bin ich letztlich auf einen 820Ohm Widerstand an meiner Verkabelung ausgekommen

[Prof. Dr. Peter Henning]

100nF bei jedem Sensor sind tolerabel, scheinen mir aber zu hoch gegriffen. Die Gesamtkapazität eines Strangs mit 100 Sensoren wäre dann so groß, dass man schon Probleme mit den Signalflanken bekäme.

Das mit dem Widerstand und der Messung ist hingegen absoluter Käse. Hierzu sollte man bitte das entsprechende Whitepaper lesen: http://pdfserv.maximintegrated.com/en/an/AN4255.pdf.

LG

pah

[Bartimaus]

Hm,
jetzt habe ich mal in FHEM am Adapter auf "Get devices" geklickt.
Alle Sensoren melden sich brav, jedoch mit einem zusätzlichen "PhantomSensor"....

Code Auswählen Erweitern

OWX: 1-Wire devices found on bus 1wire
28.909B51050000       DS18B20      Sensor1
28.84045F050000    DS18B20    Sensor2
28.A2595F050000   DS18B20    Sensor3
28.3A4A56060000  DS18B20    Sensor4
28.DE235F050000  DS18B20    Sensor5
28.791945050000    DS18B20   Sensor6
28.ADFB44050000 DS18B20   Sensor7
28.BD6D52050000  DS18B20   Sensor8
28.7D405F050000   DS18B20   Sensor9
28.D33157060000   DS18B20   Sensor10
28.B7B55E050000  DS18B20   Sensor11
28.FF1A103B0400  DS18B20   Sensor12
28.FFDF0C3E0400 DS18B20   Sensor13
00.000000000000    unknown    OWX_00_000000000000
Hat das schonmal jemand gehabt ?

[Prof. Dr. Peter Henning]

Gibt es nur, wenn auf dem Bus irgendetwas komplett schief läuft - sporadische Signale bei der Device-Suche.

LG

pah

[Bartimaus]

Yo. Nur wird die Fehlersuche jetzt schwierig. Wie gesagt, alle Sensoren hängen an einem Strang ohne zusätzliche Verästelungen. Der Strang selber ist aktuell ca.25-30m lang.

Einzelne Sensoren hängen jedoch schonmal ein paar Meter entfernt vom Strang. Als Kabel verwende ich geschirmtes 4adriges 2*2*0,6mm Telefonkabel.

[MadCat]

100nF bei jedem Sensor sind tolerabel, scheinen mir aber zu hoch gegriffen. Die Gesamtkapazität eines Strangs mit 100 Sensoren wäre dann so groß, dass man schon Probleme mit den Signalflanken bekäme.

Leider ist es auch hier so wie mit fast allem, fragt man 20 Experten, bekommt man 20 verschiedene Antworten und Meinungen.

Ich bin kein Experte und kann nur von meiner Erfahrung mit meinem 1Wire Bus berichten, da haben die 100nF und drei verschiedene Pullaps geholfen.

Aber soweit ich bisher in Erfahrung gebracht habe ist 1Wire nicht gleich 1Wire, unterschiedliche Busmaster, Kabelqualität, Länge, anzahl der Sensoren, in sofern ist es schwierig zu sagen welcher Wiederstand oder Kondensator genommen werden soll.

Zu beginn hatte ich auch noch gedacht 1Wire prima, man Verkabelt die Sensoren und das ganze Läuft, aber so ist es eben nicht.

[Bartimaus]

Zu beginn hatte ich auch noch gedacht 1Wire prima, man Verkabelt die Sensoren und das ganze Läuft, aber so ist es eben nicht.

Tja, via GPIO4 war das wirklich so. Die Kabel wurden wie Kraut und Rüben in den Lüsterklemmen verschraubt, und das Ding lief 1 Jahr lang stabil. Leider zu stabil, da es langweilig wurde, und ich dachte es wäre besser auf einen richtigen Hardware-Busmaster umszusteigen.....

[Prof. Dr. Peter Henning]

Aus dem Grund verweise ich ja auf die Whitepaper von Maxim.

Ich betreibe derzeit 5 verschiedene 1-Wire Bussysteme, die Sensoren und Aktoren zähle ich gar nicht erst. Alles stabil, ohne Probleme. Und auch keine besonderen Tricks.

@Bartimaus: Ich würde den Bus langsam aufbauen und schrittweise mehr Sensoren anklemmen. Sieht so aus, als ob einer per Wackelkontakt angebunden ist.

LG

pah

[Bartimaus]

Aus dem Grund verweise ich ja auf die Whitepaper von Maxim.

Ich betreibe derzeit 5 verschiedene 1-Wire Bussysteme, die Sensoren und Aktoren zähle ich gar nicht erst. Alles stabil, ohne Probleme. Und auch keine besonderen Tricks.

@Bartimaus: Ich würde den Bus langsam aufbauen und schrittweise mehr Sensoren anklemmen. Sieht so aus, als ob einer per Wackelkontakt angebunden ist.

LG

pah

Alle an einem Raspberry/Fritz/Banana/Cubie was weiss ich ?
Ich frage fast alle Sensoren mit einem 3600Sekunden Intervall ab. Bis auf 2 Sensoren alle 900Sekunden. Und genau die beiden haben 4 ERRCOUNT's in 18h. Die beiden werde ich mir in der Tat nochmal vornehmen.

[Prof. Dr. Peter Henning]

Alle an einem Cubie 2 (äquivalent zum Cubietruck)

[Bartimaus]

Sieht so aus, als ob einer per Wackelkontakt angebunden ist.

LG

pah

Jetzt wo Du es sagst, .....das könnte sein. Ein paar Sensoren sind an die Kabel angelötet. Evtl. hat sich beim umklemmen eine von den Lötstellen gelöst.