Jump to content

DoIT

Members
  • Content Count

    33
  • Joined

  • Last visited

Everything posted by DoIT

  1. 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. 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 nu
  3. 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"
  4. 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 Spannungsversorg
  5. 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
  6. 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 kanns
  7. 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
  8. 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
  9. 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 Beisp
  10. Hallo Uwe, ich verstehe dein Problem nicht ganz. Geht es dir um ein eine Hardwarelösung oder eine Softwarelösung? Du könntest ja prüfen ob die Menge die benötigt wird einen Grenzwert unterschreitet und dann das takten(Intervallbetrieb) in einen Thread auslagern. Grüße Markus
  11. 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 -->
  12. 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 ext
  13. 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 Sen
  14. Ok jetzt verstehe ich das. Den nebenbei habe ich noch den Brickviewer geöffnet. Ah irgendwie bin ich davon ausgegangen das es nötig sein sollte die Objekte bei einem Verbindungsverlust neu zu erstellen. Habe den Code nun nach deinem Beispiel angepasst. Jetzt funktioniert es. Vielen Danke! 😀
  15. 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
  16. 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
  17. 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 tr
  18. 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
  19. 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 Pr
  20. 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 event
  21. Hast du eine Idee was ich versuchen könnte? Oder wo das Problem liegen könnte? Vielen Dank.
  22. 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?
  23. 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 einig
  24. Moin, danke für deine Antwort, komme leider erst jetzt dazu deine Antwort umzusetzen. Ist es ein Problem wenn ich die Registrierung von Callbacks für ein Modul mehrfach ausführe? Wird dann der Callback mehrfach ausgeführt? Danke.
×
×
  • Create New...