Jump to content

DoIT

Members
  • Gesamte Inhalte

    39
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von DoIT

  1. Da hier auf meinen Thread verlinkt wurde, möchte ich mich kurz zu Wort melden.
    Leider ist das Problem nach wie vor nicht gelöst, es ist aber schön wenn ich nicht der Einzige mit dem Problem bin.

    Wie viele Sensoren verwendest du?

    Welche Kabellängen?

    Ist es bei dir auch so, dass die LEDs vom Bricklet ausgehen oder werden "nur" keine Sensoren mehr gefunden?

  2. Hallo Uwe,

    wie man das mit Tinkerforge realisiert kann ich nicht sagen. Aber wie ich es realisiert habe.
    Habe mir Xiaomi Aquara Wassersensoren besorgt. Kannst du suchen gibts schon für unter 20€. Diese funken mit Zigbee.
    Hier hättest du jetzt die möglichkeit über die Originale Xiaomi Bridge (kostet ca. 30-50€) und Node Red oder auch über die Xiaomi App verschiedenste Benachrichtigungen einzustellen. mit Node Red könntest du sogar so weit gehen das du ein Ventil vom Hauswasser schließt. Sobald etwas erkannt wurde. Hat natürlich aber auch seine Gefahren sowas.
    Ich habe mir z.B. statt der Xiaomi Bridge einen zigbee2mqtt Adapter gebaut. https://www.zigbee2mqtt.io/

    Damit könntest du dann noch viel mehr Zigbee geräte Hersteller übergreifend auslesen/ansteuern. Und das ganze ohne China Cloud Server 😅

    Grüße

    Markus

  3. Hallo kreaktiv,

    vielen Dank für deine Empfehlungen. Im Grunde habe ich es genauso wie du geschrieben hast umgesetzt.
    Was ich jedoch geändert habe ist das ich zusätzlich beim Busmaster noch einen 1k8 Pullup hinzugefügt habe. Beim Tinkerforge Onewire Bricklet ist ein 4k7 eingebaut. So komme ich auf etwa 1k3 Pullup gesamt. Das habe ich gemacht da der Bus dadurch etwas stabiler wurde bzw. das Signal mit dem Oszi besser aussieht. Ich vermute immer noch das es zu so einem Latchup Effekt kommt das sich der Busmaster verabschiedet. Ich denke das kann nur passieren, wenn eine Spannungsspitze daherkommt oder ein EMV Impuls von einer größeren Induktiven Last. Da ich aber nur ein paar kleine Relais und Pumpenmotoren mit ca. 100W verbaut habe denke ich das die Induktivität von der Wärmepumpe kommen muss. Hier ist aber auch elektronik verbaut welche das nicht stört. Die Frage welche ich mir stelle wie könnte man das ganze Abschirmen oder entstören? Die anderen Tinkerforge Module stört das jedenfalls nicht. Hier ist es noch nie zu einem Ausfall gekommen. So wie es aktuell ist kommt es so ziemlich alle zwei Tage zu einem Busmaster Ausfall. Regelmäßiges reseten der Onewire Bricklets hilft leider auch nicht. Es muss also alle 2-3 Tage etwas passieren wodurch der Master sich verabschiedet. Ich habe ja 3 Busmaster aufgebaut welche nicht wirklich zusammen hängend sind. Es sind hier unterschiedliche Kabellängen und Sensoren verbaut und jedes der Bricklets fällt eben hin und wieder aus. Bevor dieser Ausfall passiert läuft der Bus wirklich super. Es nervt einfach immer alle 2-3 Tage die Module ab und anstecken zu müssen.

    Danke für deine Hilfe.

    Grüße

  4. Hallo lapawa,

    danke für deinen Tipp, gute Idee.  :-)

    Habe ich zum testen mal eingebaut. 

    Leider kommen aber hier kein Fehler zustande, habe das jetzt über einen Tag laufen lassen. 

    Es passiert eher spontan. 

    Habe nun noch versucht jeden Kabelschirm zu jedem Fühler auf Erde zu legen. Hat leider auch nichts geändert.

    Irgendwie ist das Onewire Bricklet schon sehr empfindlich. Ich finde einfach nichts wo ich noch ansetzten könnte. 

    Als nächstes werde ich mir wohl oder übel mal einen Arduino schnappen müssen und schauen ob dieser auch neu startet oder sich verabschiedet.

    Aktuell ist es so das ca. jeden 2 Tag eines der 3 Bricklets sich verabschiedet. Leider nicht immer das gleiche und leider auch nicht regelmäßig.

    Ich bin aktuell sogar am überlegen alle Onewire Sensoren gegen PT100 oder ähnliches zu tauschen. Die ganze Steuerung ist recht umfangreich und es scheitert aktuell nur mehr an den Sensoren. Gerne möchte ich mein Projekt und auch den Code dazu veröffentlichen. Dazu soll aber auch alles mal soweit funktionieren. Nicht das sich der nächste dann auch ärgern muss. 
    Im Code habe ich das sogar schon länger umgesetzt das ich auch Thermoelement Bricklets und auch PT Bricklets verwenden kann. Habe das nur aus Kostengründen nicht gemacht. Aktuell würde ich eben 18 Sensoren benötigen. Das würden viele Masterbricks sowie Sensor Bricklets benötigt.

    Ganz aufgeben habe ich die Hoffnung noch nicht, dass noch jemand der sich besser mit Elektronik auskennt, eine Schaltung hinbekommt wie man das Bricklet entstören oder das Problem ganz beben könnte. 

    Auch nach Tagen des Lesens in Foren und googeln bin ich nicht viel schlauer geworden und konnte keine Lösung finden. Teilweise werden dann spezielle Busmaster empfohlen, am besten soll da wohl der LinkUSB von iButtonLink sein.  Der soll eine spezielle Schaltung verwenden. Vielleicht kann da jemand was darüber sangen? Ich konnte da nichts rausfinden. Vielleicht kaufe ich mir auch so einen zum testen. Ich finde es nur sehr Schade in meiner sonnst komplett mit Tinkerforge Modulen aufgebauten Steuerung eventuell eine andere Lösung einbauen zu müssen. 

    Grüße
     

  5. 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.

    20210119_184143_resized.thumb.jpg.2f9c62b909d5ae284776448b19848291.jpg

    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

  6. 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

  7. 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

     

  8. 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.

    Fehler.thumb.jpg.cf9d9461adcd842ca3b8ba963b44f227.jpg
     

    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.

  9. 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:20201226_102942.thumb.jpg.07e9f6488520ff5a68f62b5043ce73a9.jpg

     

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

    Grüße

    Markus

  10. Normal ist es so das unter raspian(debian) der Befehl "python" auf die Version 2.* von python zeigt und der Befehl "python3" auf die Version 3.* von python zeigt, genau wie mit "pip" und "pip3". Das kann man zwar ändern ist aber nach dem frischen installieren so. Über die local.rc Datei müsstest du also auch "python3" anstatt python schreiben wenn du das script mit python3 starten möchtest. Schau mal hier: rc.local - Raspberry Pi Documentation

    Und unter systemd ist das ähnlich. systemd - Raspberry Pi Documentation

    Grundsätzlich würde ich dir dazu raten systemd zu verwenden dann kannst du dein Programm mit systemctl start bzw. stop etc. steuern. 

    Virtualenvironments kannst du hier nachlesen: Python Virtual Environments: A Primer – Real Python
    Kurz: Damit kannst du deine eigene Laufzeitumgebung unabhängig vom global installiertem python erstellen. 

  11. Wie startest du das script? Mit python3 "scriptname.py"
    Verwendest du eine Virtualenvironment? 

    Wenn du den Python Interpreter mit python3 startest und dann in die interaktive shell dein import eingibst kommt dann der gleiche Fehler?
    Es macht einen Unterschied ob du mit pip(für python version 2.*) oder mit pip3(für python version 3.*) die bindings installierst. Vielleicht hast du da etwas verwechselt?

    Grüße

    Markus

  12. Hallo Max Mustermann ...

    ein paar kleine Anmerkungen:

    1.) Hast du die tinkerforge bindings installiert? pip3 install tinkerforge  --> für den Raspi 
    2.) Es ist meiner Erfahrung nach nicht optimal mit input in python zu warten wenn du auch keinen Input erwartet also in deinem Fall da du dies ja als deamon laufen lassen möchtest.
    Es würde sich sowas anbieten:

    import threading
    # Anstatt input
    waiting = threading.Event()
    waiting.wait()

    3. Würde ich dir empfehlen deinen Code eventuell auf den Robusten Ansatz umzustrukturieren um Probleme zu vermeiden.

    Grüße
    Markus

  13. Da ich eigentlich so gut wie alles in Python programmiere ist meine Antwort jetzt vielleicht etwas python spezifisch. Müsste aber in C genauso möglich sein.
    Es gibt hier natürlich wie immer mehrere Möglichkeiten deine Anforderung zu lösen.
    Möglich wäre z.B.:
    Du erstellst dir eine Klasse Dosierung wobei nun jede Pumpe eine Instanz bzw. ein Objekt der Klasse wird.
    Du baust dir eine Schleife welche immer wieder alle Pumpen überprüft und führst diese regelmäßig in deinem Programm aus, ob die gewünschte Menge gefördert und die Zeit schon abgelaufen ist für das nächste Intervall.
    Zum Beispiel könnte ein Attribute die Pausenzeit definieren welche bei den Intervallen eingehalten wird.
    Alternativ könntest du jetzt natürlich auch einen eigenen Thread erzeugen der nur alle Pumpen prüft und diese entsprechend einstellt.
    Oder du erzeugst pro Pumpe einen Thread was dann beim erzeugen der Objekte möglich ist. Würde ich bei vielen Pumpen aber eher davon abraten.

    Vielleicht erklärst du mal was genau du dir schon überlegt hast?

    Ein Thread ist wie ein Task den du auslagern kannst welcher unabhängig von deinem main abgearbeitet wird(parallel). Kann hilfreich sein.

    Bzgl. Thread hier ein Link: https://stackoverflow.com/questions/266168/simple-example-of-threading-in-c

    Sowie hier noch ein Link der dich auch interessieren könnte:

     

  14. 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.
     

  15. 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.

    Onewire_1_Sensor.thumb.jpg.39299c8f9ff119e2cde674809021fdcd.jpgOnewire_1_Sensor_2.thumb.jpg.a96ad52f1cdcddd65fe7a1bd1d16786f.jpg

    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.

    Onewire_2_Sensor.thumb.jpg.b7c4d93eb04d788058e856126e6c744e.jpgOnewire_2_Sensor2.thumb.jpg.c2e04a40226be5f405a926d7f352b0de.jpg
    Verteiler_9_Sensor.thumb.jpg.d82c11abdc05c945ee5d3649776ee690.jpg

     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.
    Onewire_16_Sensor.thumb.jpg.c5358ef292e5f0363c30bd5b25762a51.jpg
    Verteiler_2_Sensor.thumb.jpg.c70b4c535e52f77caec88d1a51a96676.jpg

    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. 20201207_144641_resized.thumb.jpg.04b84c9e9ee2a6dcb54819009e087646.jpg

    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ß
     

    Onewire_16_Sensor2.jpg

    Verteiler_6_Sensor.jpg

  16. 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 😃

  17. Danke für deine Antwort.
    Ok jetzt wird es mir klarer.

    Nein auf den enumeration_type habe ich nicht geachtet jedoch habe ich den Code einfach vom Beispiel übernommen es steht also folgendes:

    if enumeration_type == IPConnection.ENUMERATION_TYPE_CONNECTED or enumeration_type == IPConnection.ENUMERATION_TYPE_AVAILABLE:

    Ich bin davon ausgegangen das es schon sinn machen würde sobald ein Enumeration Event ausgelöst wurde einfach die Objekte neu zu erzeugen und auch zu konfigurieren.

    Ok also ich ersetzte das Objekt nicht in der Liste. Sondern nur temporär das i Objekt.

    Wie würdest du das Problem lösen um aus einer Liste eventuell nicht mehr erreichbare Brickletobjekte zu löschen bzw. neu zu erzeugen?

    Bzw. warum ist das neu erzeugen nicht nötig?

    Danke für deine Hilfe.

    Grüße
     

  18. Ich suche nun schon seit Tagen an einem Fehler jedoch komme ich einfach nicht dahinter. Wahrscheinlich habe ich einen Denkfehler oder sonnst etwas.
    Ich hoffe das mal jemand darüber schauen kann und mir sagen was ich Falsch mache.

    Folgendes möchte ich umsetzten. 
    Ich verfolge dabei den Robusten Tinkerforge Ansatz in Python. 
    Es gibt eben eine Rugged Class wobei ich mir hier zwei Instanzen erstelle in einem Programm. Jede Instanz hat einen HOST(brickdeamon) jedoch gibt es eine Master Instanz. 
    Der Grund für diese Masterinstanz ist das alle anderen Instanzen neue Bricklets oder auch bestehende Bricklets in eine Liste des Masters hinzufügen. Und in der Masterinstanz werden dann verschieden Threads erzeugt welche dann wieder die Objekte Abfragen oder konfigurieren. 
    Ich hoffe mich bis jetzt Verständlich ausgedrückt zu haben.
    Das mache ich eigentlich egal ob Onewire Bricklet oder IO16 Bricklet immer gleich. Der Fehler besteht auch egal welches Bricklet.

    Folgenden vereinfachten Code aus der Enumeration von einem Onewire Bricklet habe ich hier:

    if device_identifier == BrickletOneWire.DEVICE_IDENTIFIER:
        #test = [BrickletOneWire(uid, self.ipcon)]
        self.sensors.stop_auto_reading()
        if not self.onewire:
            self.onewire.append(BrickletOneWire(uid, self.ipcon))
            self.sensors.add_onewire(self.onewire)
            return
        dead = []
        found = False
        for i in self.onewire:
            try:
                if i.get_identity().uid == uid:
                    i = BrickletOneWire(uid, self.ipcon)
                    found = True
            except:
                dead.append(i)
        for i in dead:
            if i in self.onewire:
                self.onewire.remove(i)
        if found is False:
            self.onewire.append(BrickletOneWire(uid, self.ipcon))
        self.sensors.add_onewire(self.onewire)

    Ich möchte prüfen ob in der Liste schon ein Objekt ist wenn nicht einfach gleich eines Anhängen und beeden.

    Wenn schon welche ich der Liste sind möchte ich diese neu erzeugen könnte ja sein das die Verbindung unterbrochen war. Und falls es dabei zu einem Fehler kommt muss es ein Objekt sein welches nur mehr ein Geist ist. Welches ich dann lösche. 
    Und wenn es wirklich ein neues Objekt ist also nicht gefunden wurde fügen wir es der Liste hinzu und übergeben es damit es ab nun an auch abgefragt werden kann.

    Dieser Code funktioniert auch solange ich keine Bricklet außer einem hinzufüge oder Reseten muss. 
    Ich komme einfach nicht dahinter. 

    self.sensors.stop_auto_reading() beendet einen Thread der das Auslesen von Sensoren übernimmt und blockiert auch solange bis der Thread sicher beendet ist.

    Grundsätzlich habe ich da noch ein paar fragen. Mir ist aufgefallen das get_identity().uid ohne Fehler durchläuft auch wenn das Objekt nicht mehr erreichbar ist kann das sein?
    Ist es sobald ein Objekt auf ein Bricklet erzeugt wurde so das, das alte Objekt nicht mehr erreichbar ist. Lässt sich also nur ein Objekt(aktiv) pro Bricklet erzeugen?

    Auch ist mir aufgefallen das die Enumeration beim start immer zweimal durchläuft. Ich verstehe nicht warum das passiert. 

    In der Rugged Class steht zwar am Ende vom init()

    self.ipcon.enumerate()

    Aber müsste nicht wenn die Enumeration durchgeführt wurde dies nicht nochmal passieren? Oder sollte dies aus der init entfernt werden?

    Achso hier noch die Methoden der Sensor Klasse: (vereinfacht)

    def add_onewire(self, onewireobject):  # Fügt ein Onewire Objekt hinzu das ab nun auch eingelesen wird
        self.stop_auto_reading()  # Das lesen beenden
        self.onewire = onewireobject
        self.start_auto_reading()
        return

     

    def start_auto_reading(self): # Startet den Thread der nun alle Fühler einließt
        if not self.__threadonewire.is_alive():
            self.__readingalowed = True
            self.__stopevent.clear()
            self.__threadonewire = threading.Thread(target=self.__getsensordata)  # Thread anlegen für das Erfassen der Temperaturwerte
            self.__threadonewire.setDaemon(True)  # damit wird der Task sofort beendet wenn das Hauptprogramm beendet wird
            self.__threadonewire.start()
    
    def stop_auto_reading(self): # stopt den Thread für das Lesen und wartet bis er auch gestoppt wurde!
        self.__readingalowed = False # Thread auffordern zum beenden
        help = time.time()
        while self.__threadonewire.is_alive() is True:
            help = time.time()
            self.__stopevent.wait()  # Solange warten bis das Event gesetzt wurde
        print("auf das beenden gewartet s: {}".format(time.time() - help))
        return
    

    Sobald nun ein Sensor Resetet wird oder hinzugefügt wird bekomme ich diesen Fehler: (Also nach der Enumeration)

    Traceback (most recent call last):
      File "C:\Program Files\Python39\lib\threading.py", line 888, in run
        self._target(*self._args, **self._kwargs)
      File "C:\Users\markus\PycharmProjects\HomeAtmosphereControl\hac_classes.py", line 111, in __getsensordata
        i.reset()  # Das wird überhaupt nur benötigt weil ein reset nötig ist da nach einer zeit keine Sensoren mehr gefunden werden
      File "C:\Users\markus\PycharmProjects\HomeAtmosphereControl\venv\lib\site-packages\tinkerforge\bricklet_one_wire.py", line 315, in reset
        self.check_validity()
      File "C:\Users\markus\PycharmProjects\HomeAtmosphereControl\venv\lib\site-packages\tinkerforge\ip_connection.py", line 496, in check_validity
        raise Error(Error.DEVICE_REPLACED, 'Device has been replaced')
    tinkerforge.ip_connection.Error: Device has been replaced (-16)

     

    Ich verstehe aber nicht Warum. Wenn ich in der Enumeration vom Onewire nur ein Objekt erzeuge also so:

    test = [BrickletOneWire(uid, self.ipcon)]
    self.sensors.add_onewire(
    

    Damit läuft der Code was aber auf nur ein Onewire Bricklet limitiert. Was ich nicht möchte. 

    Aktuell sind an beiden aktiven brickdeamons nur an einem ein Onewire Modul angeschlossen.

    Ich würde mich wirklich sehr über einen Tip oder Hilfe freuen.
    Danke.

    Grüße
    Markus 

  19. 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. 

    OneWire_Fehler.jpg

    OneWire_nach_Reset.jpg

  20. 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.

×
×
  • Neu erstellen...