OneWire Bricklet mit DS18B20 Sensoren erfordert Reset nach 12h

[DoIT]

Hallo,

ich habe folgendes Problem. Ich bin dabei einen Temperaturlogger zu erstellen welcher auf DS18B20 aufbaut. Ich lese aktuell 18 Sensoren vom Typ DS18B20 über Onewire ein.

Grundsätzlich funktioniert das ganze. Ich bekomme Temperaturen und schreibe diese in eine Datenbank.

Das Problem was ich habe das nach etwa 12h (manchmal mehr, manchmal auch weniger Zeit) sich das Onewire Brickelt so verhält das es entweder gar keine Sensoren mehr findet oder Zombis liefert. Bedeutet neue Sensoradressen mit den Messwerten -0,1C.

Sobald ich das Onewire Bricklet Resete ist wieder für einige Stunden ruhe und die Sensoren funktionieren alle und liefern passende Messwerte.

Bei der Bustopologie habe ich auf eine verteilten Stern gesetzt. Ich habe drei Unterverteiler wo jeweils ca. 6 Sensoren angeschloßen sind. Zusätzlich habe ich dort jeweils einen 10k Pullup verwendet um den Bus zu stabilisieren. Als Spannungsversorgung verwende ich die internen 5V vom Onewire Bricklet. Gemessen mit einem Multimeter bricht die Spannung nicht ein.

Es ist für mich nicht schlimm fals ich das Onewire Modul öfters mal Reseten muss. Ich möchte nur gerne verstehen woher der Fehler kommt?
Aktuell Resete ich das Modul ca. alle 2h um sicher keine falschen Messwerte zu protokollieren.

Ich habe gelesen das die Sensoren auch einen CRC haben zum prüfen der Werte. Ehrlich gesagt habe ich das einfach nicht verstanden wie ich das anzuwenden habe.
Als Beispiel Habe ich hier einen Screenshot der aktuellen Sensoren angefügt. Es gelingt mir aber nicht den CRC über die angeführte Adresse zu berechnen.

Auf dieser Seite kann man CRC berechnen lassen: https://crccalc.com/

Jedoch komme ich nie auf den hier angeführten CRC egal was ich angebe.

Wie wäre das umzusetzen?

Oder gibt es andere Möglichkeiten die Zuverlässigkeit zu erhöhen?

Danke für eure Hilfe.

Gruß

 

[borg]

Ist der Screenshot von einer Situation wo die Werte nicht OK sind?

In der Liste ist bei der ID die führende 0 nicht mit angegeben, sprich der zu überprüfende HEX-String für "Search Bus(0)" ist 280218607460ff, was aber wenn ich das richtig sehe eine CRC von 0xBC ergeben sollte.

[DoIT]

Danke für deine Antwort.
Der Screenshot ist aufgenommen wo die werte passen. Also nach einem Reset vom Bricklet.
Auf das Ergebnis was du schreibst bin ich auch gekommen. Ich verstehe es aber nicht. Der CRC Wert wird ja vom Sensor gesendet oder wird der im Brickviewer berechnet?
 

[DoIT]

Hast du eine Idee was ich versuchen könnte? Oder wo das Problem liegen könnte?

Vielen Dank.

[borg]

Die CRC wird nicht berechnet vom Brick Viewer, den Anzeigecode kannst du hier finden: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/one_wire/one_wire.py#L91

Das Bricklet selbst überprüft allerdings die CRC: https://github.com/Tinkerforge/one-wire-bricklet/blob/master/software/src/one_wire.c#L291

Dementsprechend sollten da sowieso nie unkorrekte CRCs im Brick Viewer auftauchen.

Das bedeutet aber auch, dass wenn du die fehlerhaften Werte (-0.1°) bekommst diese wirklich von den 1-Wire-Sensoren verschickt werden (oder die CRC passt nur zufällig). Sehr seltsam.

Wenn du sagst ein "Reset" hilft, meinst du dann ein Reset per Software?

[DoIT]

Danke für deine Antwort.
Ist das dann ein Fehler im Brickelt selbst da ja der CRC so nicht stimmt oder?
Es reicht sein Softwarereset aus um wieder richtige Werte zu bekommen. Ein und Ausstecken vom Bricklet ist nicht nötig.

Ist es möglich das einer oder merhere Sensoren da Probleme machen?
Wobei es ja nach einem Brickletreset wieder funktioniert.

Nach einigen Stunden erscheinen dann eben auch diese Geistersensoren auf dem Bus welche einen neue Adresse haben und den Temperaturwert von -0,1C und die echten Sensoren sind nicht mehr am Bus ersichtlich.

Wie könnte man einen eventuell defekten Sensor finden? Und was genau macht der Brickletreset mit dem Bus?

 

 

 

[borg]

Die CRC-Berechnung ist schon korrekt, sonst würde das Bricklet auch gar nicht funktionieren. Wir nutzen die original Lookup-Table von Maxim von hier: https://www.maximintegrated.com/en/design/technical-documents/app-notes/2/27.html

Ich hab gerade hier https://www.maximintegrated.com/en/design/technical-documents/app-notes/4/4600.html auch eine Excel-Datei von Maxim gefunden mit der man die CRC überprüfen kann und da mal die Daten aus dem Brick Viewer Screenshot eingetragen:

Da muss irgendwo etwas anders sein bei 1-Wire-CRC im Vergleich zur Standard-CRC-Berechnung. Daher passt es bei der CRC-Seite nicht. Das Polynom (x⁸+x⁵+x⁴+1) ist eigentlich korrekt.

Warum ein Software-Reset hilft um das Problem zu beheben ist mir aktuell noch schleierhaft. Das Reset startet den Micrcontroller neu, aber ich finde da jetzt nichts in der Initialisierung vom Bricklet was dazu führen könnte ein Problem mit den angeschlossenen Sensoren zu beheben.

Hast du schon ausprobiert "reset_bus" aufzurufen wenn das Problem auftritt? Hilft das?

[DoIT]

OK dann stimmen die angezeigten CRC Werte also.
Würde es für meine Funktion dann überhaupt Sinn machen den CRC Wert zu berechnen wenn dies eh schon das Bricklet erledigt?

Werden readings im Brickviewer verworfen wenn der CRC nicht korrekt ist?

Sobald ich in meinem Programm fehlerhafte Werte bekomme also etwa nach 12h ist es so das ich im Brickviewer bei Search Bus keine Sensoren mehr finde. Abhilfe das wieder Sensoren gefunden werden ist ein Reset im Brickviewer oder aber das ab und anstecken vom Bricklet selbst was ja auch ein Reset ist ein Reset Bus hilft nichts.

Über meine Programm bekomme ich dann aber für einige Sensoren noch die Werte geliefert.

Das Lesen der Sensoren sieht bei mir so aus und wird pro Onewire Bricklet durchgeführt. Aktuell ist aber nur eines angeschlossen.

for i in self.onewire:
    i.reset_bus()  # setzt den Bus zurück
    searched = i.search_bus()
    if not confeach:
        for x in searched[0]:
            i.write_command(x, 68)  # CONVERT T (start temperature conversion)
        time.sleep(1)  # Wait for conversion to finish
    for x in searched[0]:
        if confeach:  # Das wird nur ausgeführt wenn es einen oder mehrere Sensoren gibt die neu sind oder neu am bus
            i.write_command(x, 78)  # WRITE SCRATCHPAD
            i.write(0)  # ALARM H (unused)
            i.write(0)  # ALARM L (unused)
            i.write(127)  # CONFIGURATION: 12-bit mode
            i.write_command(x, 68)  # CONVERT T (start temperature conversion)
            time.sleep(0.75)  # Wait for conversion to finish
        i.write_command(x, 190)  # READ SCRATCHPAD
        t_low = i.read().data
        t_high = i.read().data
        temperature = t_low | (t_high << 8)
        if temperature > 1 << 12:
            temperature -= 1 << 16
        temperature = temperature / 16.0  # Das ist nötig damit der Wert stimmt
        crc = hex(x)[2:4]
        family = hex(x)[-2:]
        address = hex(x)[(2 + len(crc)):(len(hex(x)) - len(family))]

[borg]

Danke für den Code.

Ich hab da jetzt keine Ideen mehr, ich müsste dann versuchen das Problem hier zu reproduzieren. Du weißt nicht zufällig ob das Problem bei dir auch mit nur einem Temperatursensor auftritt? Ich hab nur einen hier, ich würde jetzt sonst erst 16stk bestellen um zu versuchen das zu reproduzieren.

Welche Sensoren verwendest du genau?

In der Zwischenzeit als Workaround kannst du aber im Code auch wenn das Problem auftritt einmal reset() auf dem Bricklet aufrufen (das geht nicht nur im Brick Viewer).

 

Edit: Und ja, die CRC brauchst du eigentlich gar nicht mehr überprüfen, da wir sowieso nur Daten mit überprüfter CRC übertragen.

[DoIT]

Gerne.  Und Danke für deine Hilfe! :-)
Das ganze läuft auf einem Raspi mit installiertem Wireguard. Würde es dir helfen Zugriff zum testen auf das System zu bekommen?

Möchte das Projekt später sowieso gerne vorstellen und veröffentlichen.

Es sind Sensoren vom Typ DS18B20 die ich von Amazon oder Aliexpress habe das kann ich nicht mehr genau sagen. Sowas:

10 stücke DALLAS DS18B20 18B20 ZU 92 IC CHIP Thermometer Temperatur Sensor|ic chip|sensor chipsensor ds18b20 - AliExpress

An die Sensoren habe ich dann ein 3 poliges Kabel mit Schirm angelötet. Es sind dann 3 Unterverteiler mit je ca. 6 Sensoren mit Kabellängen zwischen 0,5m bis 4m.

Ich werde es jetzt über die Nacht noch mit weniger Sensoren versuchen um zu sehen ob das einen Unterschied macht.

[DoIT]

Ich habe jetzt nochmals ohne Änderung mein Programm laufen lassen. Also mit allen Sensoren weil ich einen Screenshot vor und nach dem Reset machen wollte. 

Hier nun das Ergebnis. Es steht Bussy. Was bedeutet das genau?
Auch sieht man schön das ein Reset Bus nichts ändert. Es werden erst wieder Sensoren nach dem Reset vom Bricklet selbst gefunden. Mein Programm war zu diesem Zeitpunkt beendet. Also hierdurch ist eine Blockierung nicht möglich. Die Timeouts sind denke ich schon älter und stammen von anderen Versuchen von mir wie sich das Programm verhält wenn ich die Netzwerkverbindung trenne. Ich denke nicht das dies mit dem Fehler zusammenhängt. Aktuell ist es noch so, dass das Programm auf meinem PC läuft. Wenn es dann fertig ist kommt es auf den Raspi. 

[DoIT]

Update: Mit weniger Sensoren verhält es sich gleich. Was mir jedoch aufgefallen ist. Die Zeit bis es zu diesem verhalten kommt, sind nicht immer 12h. Es ist mir auch schon nach 1h passiert aber genauso auch erst nach 14h. Es lässt sich also zeitlich nicht wirklich eingrenzen. Mit nur einem Sensor habe ich den Fehler nicht bekommen.

Ein weiters verhalten was ich nun festgestellt habe ist, dass manche Sensoren plötzlich keine Temperatur mehr liefern. Diese sind nicht am gleichen Verteiler noch immer die selben. Es kommen dann immer wieder Temperaturwerte von -0.1°C. Zusätzlich werden dann Sensoren erkannt die es gar nicht gibt. Also Adressen geliefert die gar nicht am Bus hängen. Eben auch mit Temperaturwerten von -0.1°C. Auch findet das Bricklet ab hier keine Sensoren mehr im Brickviewer(wie oben kommt nur Bussy). Erst nach einem Reset kommen wieder Sensoren und es werden bei allen Sensoren korrekte Werte gelesen. Ich kann natürlich einen Defekt eines Sensors nicht ausschließen aber wie soll ich diesen finden wenn er nach einem Reset vom Bricklet immer einen korrekten Wert liefert?

Hier ein Beispiel der neuen Geistersensoren: ( Sensoren mit diesen Adressen sind nicht am Bus)

NEU Sensor: 1036 hat gerade -0.1 °C mit der Adresse: 031867ff7cff
NEU Sensor: 1037 hat gerade -0.1 °C mit der Adresse: 031867fbf6ff
NEU Sensor: 1038 hat gerade -0.1 °C mit der Adresse: 011867bbfdff
NEU Sensor: 1039 hat gerade -0.1 °C mit der Adresse: 031867fbabff
NEU Sensor: 1040 hat gerade -0.1 °C mit der Adresse: 031867bbd9ff
NEU Sensor: 1041 hat gerade -0.1 °C mit der Adresse: 031865befdff
NEU Sensor: 1042 hat gerade -0.1 °C mit der Adresse: 031867bbddff
NEU Sensor: 1043 hat gerade -0.1 °C mit der Adresse: 031865f6f7ff
NEU Sensor: 1044 hat gerade -0.1 °C mit der Adresse: 031867bbdfff
NEU Sensor: 1045 hat gerade -0.1 °C mit der Adresse: 02186073d7ff

Gibt es eine Möglichkeit zu erkennen wann die Sensoren nicht mehr richtige Werte liefern? Da die -0,1°C ja auch ein gültiger Wert sind wäre ein Prüfung auf diesen Wert ja nicht zielführend. Aktuell mache ich 1x pro Stunde ein Bricklet Reset was den Fehler aber leider auch nicht beseitigt da es manchmal auch schon früher zu diesem Fehler kommt und wieder falsche Werte geschrieben werden.

Danke für deine Hilfe 😃

[borg]

Ich lasse mal einen Langzeittest mit den Sensoren laufen die ich hier hab, mal schauen ob ich es reproduzieren kann.

[DoIT]

Ich habe jetzt ein paar Versuche gemacht und mir das Bussignal mit einem Oszi angesehen. Folgendes habe ich versucht bzw. ist mir aufgefallen.

Abgeleitet von hier:
Guidelines for Reliable Long Line 1-Wire Networks (maximintegrated.com)
und hier:
1-Wire Störungsbeseitigung – FHEMWiki

habe ich vermutet das am Bus ein sogenanntes Undershooting passiert. Und deshalb die Sensoren oder auch der Busmaster durcheinander kommt. 

Als erstes habe ich deshalb ein neues Onewire Bricklet genommen und einen DS18B20 mit ganz kurzen Leitungen verbunden und mir das Signal angesehen. Also ohne extra Pullup oder sonstiges. Das Signal zeigt eine leichte Abflachung. Für mich war das jetzt die Referenz und somit auch der Optimalfall. 

Blau ist immer die Datenleitung also BUS und gelb ist immer 5V VCC.
Optimalfall ist als erstes also mit nur einem Sensor.

Als nächstes habe ich dann mit einem neuen Onewire Bricklet einen Verteiler mit 9 Sensoren angeschlossen. Ein PULLUP MIT 2,2k EXTRA angeschlossen.
Zuleitung ist hier ca. 5m zum Verteiler und die Kabellänge pro Sensor zwischen 0,5m bis 3m. Auch hier wieder ein kleiner Kondensator zur Spannungsstabilisierung.
Hier sieht man schön das die Impulse schon relativ abgeflacht sind.

 Als nächstes habe ich dann auf einem weiteren Onewire Bricklet einen weiteren Verteiler angeschlossen. Auf diesem sind 2x DS18B20 mit jeweils ca. 3m Kabellänge und einer Zuleitung von ca. 10m MIT extra PULLUP 2,2k. Hier sieht man nun schön das das Signal schon sehr abflacht. Im Verteiler selbst ist ein kleiner Kondensator zur Spannungsstabilisierung.



Dann habe ich noch auf einem neuen Onewire Bricklet 6 Sensoren ohne extra Zuleitung und mit Leitungslängen von ca. 1,5m und 2,2k PULLUP sowie 220pF und 68Ohm Serienwiderstand als RC-Glied am Datenbus. So wie es auf der Maxim Seite beschrieben ist hinzugefügt. 

Es war mir zu jedem Zeitpunkt möglich die Sensoren bei jedem Modul auszulesen. Aber egal bei welchem Modul ich das ganze habe laufen lassen. Nach einiger Zeit sind immer wieder plötzlich Sensoren aufgetaucht welche es nicht wirklich gibt. Oder es wär plötzlich nicht mehr möglich die Sensoren auszulesen bzw. wurde im Brickviewer Busy angezeigt. Auch der zusätzliche Pullup hat nichts geändert. 

Soweit ich das jetzt von Maxim lesen habe können. Dürfte der Fehler vielleicht schon auf ein schlechtes Signal zurückzuführen sein.

Es funktioniert auch wenn ich alle Sensoren und Verteiler auf einen Onewire Bricklet zusammenführe. Die Topologie ist leider eine Sternverkabelung und im Fall von Onewire nicht optimal. Das ist mir klar. Aber in Summe bin ich mit allen Leitungen unter 100m. Auch verwende ich geschirmte Kabel. 

Ich würde nun vermuten das es an den Kabellängen liegt warum es zu diesem verhalten kommt. Aber selbst bei 6 Sensoren mit jeweils 1,5m Kabel kommt es schon zu Problemen. Wäre es möglich die Signale irgendwie zu verstärken. Gibt es da etwas? Oder wie könnte man das Problem verbessern?

Weiters ist mir aufgefallen es es nicht -0,1°C sind welche immer wieder gelesen werden sondern -0,0625°C habe ich übersehen weil beim lesen der Werte schon gerundet wird.

Wie siehst du das ganze? Hast du etwas finden können?
Danke für deine Hilfe.
Gruß
 

[DoIT]

Konntest du den Fehler nachstellen? Oder hast eine Idee dazu?

[borg]

Bisher konnte ich es leider nicht reproduzieren.

Ich hab meinen Kollegen der für das Hardwaredesign zuständig ist mal auf diesen Thread aufmerksam gemacht, eventuell hat er ja eine Idee ob man das anders verdrahten kann o.ä.

[DoIT]

Danke für deine Rückmeldung.

Ich habe nun noch folgende Versuche gemacht.
Immer ausgehend von einem Onewire Bricklet. Den Kabelschirm habe ich beidseitig NICHT aufgelegt so wie das auch von Maxim empfohlen wird.
Master Brick --> Onewire Bricklet --> 10m Cat7 Kabel  --> 1x DS18B20 = Lesefehler obwohl das Signal mit dem Oszi gut aussieht.

Master Brick --> Onewire Bricklet --> 10m Cat7 Kabel  --> 1x DS18B20 + 4k7 = etwas weniger Lesefehler

Raspi Hat --> Onewire Bricklet --> 10m Cat7 Kabel  --> 1x DS18B20 + 4k7 = gleiches Ergebnis

Master Brick --> Isolator Bricklet --> Onewire Bricklet --> 10m Cat7 Kabel oder auch 3pol geschirmt  --> 1x DS18B20 + 4k7 = keine Lesefehler mehr nur mehr Timeouts bzw. Busy

Es ist also so das das Kabel keinen Unterschied macht. Auch neue Sensoren oder neue Bricklets habe ich getestet. Es scheint so als wäre das Problem die Kabellänge wobei ich das noch nicht verstehe warum das so ist.

Definitiv einen großen Unterschied macht hier das Isolator Bricklet. Wobei ich nicht verstehe warum das hier so zum Tragen kommt. Die Sensoren sind potentialfrei montiert.
 

Sobald ich ein Isolator Bricklet verwende ist es möglich alle Sensoren(18 Stück) auf ein Onewire Bricklet zu verbinden. Ich habe lediglich noch pro Unterverteiler einen 4k7 Ohm Pullup hinzugefügt(der ist nötig sonnst werden die Sensoren nicht gefunden). Es kommt hier zu keinen Geistersensoren mehr. Es passiert dann "nur" das beim Lesen Busy kommt bzw. ein Timeout als Exception im Code, was durch einen Bricklet Reset dann behoben werden kann.
 

[DoIT]

Hallo,

leider habe ich immer noch keine Lösung für mein Problem finden können. Es hat sich aber trotzdem einiges geändert und ein paar Erkenntnisse konnte ich noch gewinnen.

Ich habe herausgefunden das meine Sensoren Counterfit Sensoren sind. Also keine Originalen von Maxim/Dallas. Es gibt hier ein super Projekt: https://github.com/cpetrich/counterfeit_DS18B20
Ich habe gar nicht gewusst das es "Fake" Sensoren gibt 😅

Über die Arduino Sketches konnte ich meine Sensoren klassifizieren. Ich hatte Fake Sensoren der Klasse B2.

Ich habe mir nun Original Sensoren besorgt und alle Sensoren ausgetauscht. Jetzt sind nur mehr Originale DS18B20+ von Maxim verbaut.
Das Problem ist aber leider immer noch da. Auch wenn es sich etwas geändert hat.

Es passiert jetzt eigentlich nur mehr das nach ein paar Stunden/Tagen plötzlich auf dem Bus keine Sensoren mehr gefunden werden und vom Bricklet "Bussy" kommt.
Es hilft dann eben ein reset vom Bricklet oder aber auch das Aus/An stecken vom Bricklet selbst. Was ich auch versucht habe und weiß, dass es funkioniert ist. Das Ab und Anklemmen der Sensoren. Also ohne das Bricklet zu reseten oder abzustecken. Dann funkioniert es wieder. Es hängt also irgendwie mit dem reseten der Sensoren zusammen. Nach etwas suchen bin ich noch auf den "latch up" effekt gestoßen. Aber eine Lösung habe ich nicht finden können. https://de.wikipedia.org/wiki/Latch-Up-Effekt

 

Ich würde mich wirklich sehr über Tips oder Hilfe bei meinem Problem freuen. Ich möchte nur einen stabilen OneWire Bus haben.

Ich habe inzwischen noch Hardwaretechnisch folgendes geändert.

Alles 3 Polige geschirmte Kabel. Auch bei den Sensoren.
3 Onewire Bricklets mit Isolator Bricklet sowie ein Masterbricklet mit eigenem Stepdown
Pro Bricklet nur mehr einen Onewire Verteiler. Somit ist die Sensor Aufteilung so:

1 Bricklet --> direkter Verteiler mit 6x Onewire Sensoren mit je. 1,5m Kabel zusätzlich 1x Pullup mit 4k7

2 Bricklet --> 10m Zuleitung zum Verteiler 9x Onewire Sensoren mit je 1,5m Kabel zusätzlich 1x Pullup mit 4k7 plus 1x Pulldown 22k und 10nF Kondensator im Verteiler

3 Bricklet --> 12m Zuleitung zum Verteiler 2x Onewire Sensoren mit je 3,5m Kabel zusätzlich 1x Pullup mit 4k7

 

Leider passiert es bei jedem der Bricklets das der Bus ausfällt bzw. es zu Fehlern kommt.

Ich weiß nun wirklich nicht mehr was ich noch probieren könnte.

Was mir noch aufgefallen ist. Hin und wieder kommt es vor das eines der Onewire Bricklets sich verabschiedet. Es leuchtet dann kein LED mehr und auch ist es per Software nicht mehr erreichbar. Weder im Brickviewer noch sonst wie. Es hilft dann nur das ab und wieder anstecken um es wieder erreichbar zu machen. Hier ein Bild:

 

Ich würde mich wirklich sehr freuen eine Rückmeldung bzw. Tips/Hilfe zu bekommen. 😃
Danke

Grüße

Markus

[DoIT]

Ich habe nun noch den Versuch gestartet die Sensoren über eine exteren Stromversorgung zu betreiben. Leider wieder ohne Erfolg.
Es passiert nun öfter das bei manchen Onewire Bricklets die LEDs ausgehen und dann kein Verbindung mehr besteht also weder über den Brickviewer noch sonnst wie.
Auch ein Reset ist nicht mehr über Software möglich. Es hilft wirklich nur das Ab und Anstecken vom Bricklet selbst. Dann funktioniert es wieder "normal".
Wie kann soetwas passieren. Oder was muss dazu passieren?
Ich habe aktuell versucht einen Workaround zu bauen indem ich die Externe Spannungsversorgung bei einem Fehler Ab und Anschalte damit ich die Sensoren wieder zum reden bewegen kann. Das hilft mir aber nichts wenn die Bricklets tot sind und ein händisches Ab und Anstecken benötigen.
Hier noch ein Bild wo man schön sieht das zwei der drei Bricklets tot sind und händisch wiederbelebt werden müssen.

 

Es Spielt dabei keine Rolle wie viele Sensoren angeschloßen sind. Es muss also etwas mit der Kabellänge zu tun haben. Induktive Lasten werden keine in der Nähe geschaltet. Aber sind 2 Sensoren mit vielleicht ingesamt 25m Kabel wirklich zu viel?

Ich habe nun meine ganze Steuerung auf Tinkerforge Module aufgebaut. Alles funktioniert super bis auf diese sch*** Onewire Sensoren.

Es muss doch eine Lösung für das Problem geben. Ich würde wirklich nur sehr ungern wieder andere Hardware kaufen. Aber ich bin verzweifelt.

[batti]

Hallo DoIT,

fest steht denke ich, dass das Bricklet nicht mehr erreicht werden kann. Die Frage ist warum.

1. Möglichkeit: Keine Spannung

Hast du irgendwie die Möglichkeit die Spannung an des Bricklets zu messen? Neben dem Brickletstecker befindet sich ein größerer und ein kleinerer Kondensator nebeneinander. Diese Puffern die Stromversorgung des Bricklets. Kannst du an dem größeren Kondensator messen? Einfach die linke und rechte Seite von dem Kondensator kontaktieren. Hat das Bricklet, trotz dass die LED aus ist noch Strom?

2. Möglichkeit: Softwarebug

Eine andere Möglichkeit ist, dass wir irgendwo einen Software-Bug haben und sich das System "verklemmt" und der Watchdog das nicht rettet. In diesem Fall würde der Prozessor an sich noch leben, hängt nur softwareseitig in irgendeiner Art Schleife fest. In diesem Fall würde der Prozessor die LED dann nicht mehr ein/ausschalten. Ich glaube ehrlich gesagt nicht, dass das der Fall ist.

3. Möglichkeit: Prozessor elektrisch getötet

Alternativ ist der Prozessor elektrisch tot. Das könnte zum Beispiel durch eine Spannungsspitze oder so verursacht werden. In diesem Fall würde ich erwarten, dass der Prozessor die LED elektrisch nicht mehr schalten kann, so dass diese aus ist. Da du jetzt keine Spannung mehr vom Bricklet nutzt und der Datenpin geschützt ist wundert mich das, ist aber aktuell mein Favorit.

Weiteres vorgehen:

Die LEDs der Bricklets stehen standardmäßig auf "show communication", d.h. die blinken wenn Daten ausgetauscht werden. Kannst du die LEDs mit dem Brick Viewer mal auf "on" = dauerhaft leuchten stellen?

Ich würde dann im Softwarebug Fall erwarten, dass die LED an bleibt. Im elektrisch getötet Fall würde ich erwarten, dass die LED aus ist. Falls die LED irgendwann wieder blinkt muss sich das Bricklet neugestartet haben und hat dementsprechend die LED Konfiguration vergessen. Das wäre auch interessant festzustellen.

[DoIT]

Hallo,

vielen Dank für deine Antwort.

1.) Bei einem ausgefallenen Bricklet(also keine LED leuchtet) liegt am Kondensator ca. 3.3V an und an Pin 1 und 2 vom Brickletstecker 5V. Also Strom müsste daher noch da sein.

3.) Wie könnte ich den Datenpin schützen? Welche Störungen könnten das sein. Gehen dann beide LEDs aus? 
Es sind schon Kabel in der Nähe die zu Pumpen oder auch Mischer Motoren laufen. Das ganze ist eine Heizungssteuerung/Anlagensteuerung. Größte induktive Last in der nähe ist nur eine Wärmepumpe. 

Das habe ich so nun versucht. Die LEDs bleiben trotz Einstellung "on" aus. 
Was bedeutet das die der Datenpin geschützt ist?

 

Vielen Dank für deine Hilfe.

Viele Grüße

Markus

 

[batti]

Hi Markus,

Danke für die schnelle Antwort.

Zitat

1.) Bei einem ausgefallenen Bricklet(also keine LED leuchtet) liegt am Kondensator ca. 3.3V an und an Pin 1 und 2 vom Brickletstecker 5V. Also Strom müsste daher noch da sein.

Das klingt gut

Zitat

3.) Wie könnte ich den Datenpin schützen? Welche Störungen könnten das sein. Gehen dann beide LEDs aus? 
Es sind schon Kabel in der Nähe die zu Pumpen oder auch Mischer Motoren laufen. Das ganze ist eine Heizungssteuerung/Anlagensteuerung. Größte induktive Last in der nähe ist nur eine Wärmepumpe. 

Der Pin verfügt eigentlich schon über einen Schutz.

Die Frage ist ob es sich um das Softwarebug Problem oder das elektrische Problem handelt. Daher die Frage zu:

Zitat

Das habe ich so nun versucht. Die LEDs bleiben trotz Einstellung "on" aus. 

Nicht das es hier Misverständnisse gibt. Wenn du nicht mehr mit dem Bricklet kommunizieren kannst, dann wird das Bricklet auch nicht die LEDs umschalten können.

Das heißt gedacht war es so, dass du die Bricklets wieder zum Leben erweckst und dann alle LEDs auf "on" konfigurierst. Wenn dann das Problem wieder auftaucht, dann ist die Frage was die LED gemacht haben (aus, permanent an wie konfiguriert, oder blinken wieder -> haben sich neugestartet).

Probierst du das bitte?

[DoIT]

Hi, vielen Dank für die Rückmeldung 😀

Genau so hatte ich das gemacht. Also auf deinen Vorschlag bezogen.
Ich habe das Bricklet wieder zum Leben erweckt in dem ich es ab und angesteckt habe.
Dann meinen Code so angepasst das keine automatischen Resets gemacht werden.
Dann im Brickviewer die Einstellung der LED auf "an" gesetzt.
Nun habe ich gewartet bis das Bricklet wieder "tot" war und gesehen das die LEDs trotz dieser Einstellung aus waren. Also kein LED geleuchtet oder geblinkt hat. Auch der Zugriff auf das Bricklet per Brickviewer etc. ist nicht möglich.

Ich habe zum testen nun ein Onewire Bricklet an meinem Schreibtisch mit Masterbricklet getestet(gleicher Code). Nur 2x Sensoren ohne Kabel direkt angeschlossen.
Das läuft nun so seit Freitag ohne fehler oder Reset etc. So wie es sein sollte.

Ich denke nun auch das es etwas mit den Störungen zu tun haben muss. Ich frage mich nur warum dies genau nur die Onewire Bricklets betrifft. Sind diese besonders empfindlich? Habe ja sogar geschirmte Kabel verwendet.

Ich habe bei der Steuerung viele Module verbaut. Grob sieht das so aus:
RPI 4 mit HAT
3x IO16 Bricklet
1x Industrial OUT
1x LCD
1x Rotary Encoder
2x Temperature Bricklet
1x Humidity Bricklet
1x Master Brick
1x StepDown Brick
3x Onewire Bricklet plus Isolator Bricklet

Bei keinem anderen Bricklet habe ich Probleme und die Steuerung ist auf ca. 1m² am selben Ort platziert.
Zusätzlich sind noch Relais verbaut aber diese sind alle entstört.

 

Als weiteren Versuch habe ich gestern Abend noch die ganzen Onewire Bricks ca. 0,5m an das andere Ende der Montageplatte montiert. Mal schauen ob das etwas ändert.
Auch habe ich noch einen 100Ohm Widerstand in Serie zum Datenpin eingefügt sowie den Pullup mit einem 1k8 Ohm Widerstand ingesammt auf ca. 1k verringert sowie einen 22k Pulldown eingefügt.

Hättest du eine Idee wie ich den Bus entstören könnte?

 

Grüße

Markus

[DoIT]

Hallo,

ich wollte nochmals Rückmeldung geben.
Eines vorweg es kommt immer noch zu Lesefehlern sowie "toten" Onewire Bricklets.

Ich denke auch das es irgendetwas mit Störungen zu tun hat. Nur komme ich nicht dahinter wie ich das Problem beheben könnte.
Als Versuch habe ich nun die ganzen Onewire Bricklets auf eine Aluplatte montiert welche ich dann provisorisch geerdet habe.

Gefühlt am meisten hat jedoch der 100Ohm Serienwiederstand am Datenpin gebracht. Jetzt passiert es nur noch alle 1-2 Tage das sich das Onewire Bricklet "tötet".
Auch Lesefehler passieren jetzt noch ca. 2 mal pro Tag. Was gegenüber vorher schon sehr viel besser ist.

Wie könnte ich eine Entstörung aufbauen um Ruhe zu bekommen? Hast du da eine Idee?

Grüße

[lapawa]

Hallo,

sieht nach einem sehr interessantem Projekt aus. Ich verfolge deine Bemühung schon eine Weile.

Eine Idee hätte ich dazu auch noch.

Die neuen 7poligen Bricklets bieten per API die Möglichkeit Kommunikationsfehler zu erfragen.

Vielleicht kannst Du das 'Sterben' eines Bricklets darüber vorzeitig erkennen.

BrickletOneWire.get_spitfp_error_count()

Gruß