Jump to content

photron

Administrators
  • Content Count

    2642
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by photron

  1. Diese Frage kam schon häufiger auf und ich dachte eigentlich wir hätten das mittlerweile dokumentiert, scheint nicht der Fall zu sein. Der Sensor misst einfach die absolute Niederschlagsmenge seitdem die Batterien eingelegt wurden. Jeglichen anderen Zeitbezug musst du selbst berechnen. Das der Messwert fällt sollte unmöglich sein, wenn du nicht die Batterien für einen Reset herausgenommen hast. Hast du vielleicht mehr als eine Station in Empfangsreichweite und die haben zufälligerweise die gleiche ID?
  2. Also, so wie du Promise verwendest kann das nicht funktionieren. Du legst ein leeres device_promises Array an, und im Prinzip rufst direkt danach Promise.all auf ein leeres Array auf. Dieses Promise ist natürlich sofort erfüllt, denn die Enumerate Callbacks kommen erst danach an. Damit der Ansatz funktioniert musst du vor dem ipcon.enumerate() Aufruf wissen wie viele Devices vorhanden sind und die Promises vorher anlegen und nicht erst im Enumerate Callback, denn dort ist es zu spät. Wenn du nicht weißt wie viele Devices vorhanden sind kannst du das über einen Timeout lösen. Die Annahme d
  3. Ja, das ist leider so. Ich habe dem Update Dialog jetzt einen Hinweis hinzugefügt, dass der Prozess durchaus bis zu 2 Stunden dauern kann.
  4. Brick Viewer 2.4.14 Fix monoflop handling to cover full uint32 duration range Better indicate disconnected state Highlight timeout error counter > 0 in bold red Fix slider/spinbox mismatch on auto-reconnect in DC Brick plugin Avoid UI jumps on value changes in Energy Monitor Bricklet plugin Add extra checkbox to avoid accidental port number changes Handle all errors while downloading firmware updates Downloads: Windows, Linux, macOS
  5. Brick Viewer 2.4.14 Monoflop-Behandlung korrigiert damit der gesamte uint32 Zeitbereich genutzt werden kann Disconnected-Zustand wird besser dargestellt Timeout-Fehlerzähler wird bei Werten > 0 fett-rot hervorgehoben Abweichung zwischen Slider- und Spinbox-Wert im DC Brick Plugin nach Auto-Reconnect korrigiert UI springt nicht mehr bei Werteänderungen im Energy Monitor Bricklet Plugin Extra Checkbox soll unabsichtliche Änderungen der Portnummer verhindern Alle Fehler beim Herunterladen von Firmware Updates werden behandelt Downloads: Windows, Li
  6. Periodisch abgefragt werden: https://download.tinkerforge.com/latest_versions.txt https://download.tinkerforge.com/all_versions.txt Es kann sein, dass du das Popup da nicht siehst, weil es zu schnell wieder weg ist.
  7. Brick Viewer fragt auf tinkerforge.com die Liste der aktuellen Firmware Versionen ab, um Updates anzeigen zu können. Bei dieser Abfrage ist ein Übertragungsfehler aufgetreten, der im Code nicht behandelt wurde. Unbehandelt Fehler landen dann in diesem Fehlermeldungsdialog. Das hat nichts damit zu tun was du zu dem Zeitpunkt getan hast. So richtig erklären kann in den speziellen Fehler nicht. Da hatte entweder unser Server oder deine Internetverbindung gerade Schluckauf. Trat der Fehler nur einmal auf, oder tritt der immer wieder auf? In der nächste Brick Viewer wird dieser Fehle
  8. @duaw Der Fehler "NameError: name 'display_names' is not defined" wurde in den MQTT Bindings 2.0.10 behoben, wobei 2.0.11 die aktuelle Version ist. Du verwendest also nicht die aktuellste Version der MQTT Bindings. Teste mal bitte mit Version 2.0.11, ob da dein Problem auch noch auftritt. Stehen diese unvollständigen Zeilen "2020-08-06 17:05:49,497 <DEBUG> MQTT bindings:" da so wirklich so, oder hast du da etwas gekürzt?
  9. Die Inkompatibilität mit dem 5.4 Kernel ist durch das Firmware Update 2.0.2 des HAT Bricks behoben. Das Problem dabei ist das Firmware Update 2.0.2 auf den HAT zu bekommen, während der Kernel 5.4 verwendet wird. Das einfachst ist dafür auf einen älteren Kernel zu wechseln. Sobald du dann Firmware Update 2.0.2 auf dem HAT hast kannst du auch wieder Kernel 5.4 verwenden.
  10. systemd-timesyncd als NTP Client ist normalerweise installiert und ist eigentlich auch bei Raspbian dabei. Aber systemd-timesyncd ist eine simple minimale SNTP Implementierung. Das reicht für viele Zwecke. Aber ich habe auch schon festgestellt, dass systemd-timesyncd absolute nicht damit klar kommt, wenn die Internetverbindung schlecht ist, dann kommt keine sinnvolle Zeitsynchronisierung zustande. Für ntpd und chronyd ist das aber kein Problem. Interessant, wäre trotzdem zu sehen was passiert, wenn du alle NTP Dienste deaktivierst, damit zu erkennen ist, was die RTC da wirklich tut, denn
  11. Die Doku ist da etwas ungenau, das ist ein Super-Cap, keine Batterie. Leider hält der auf der aktuellen HAT Version 1.4 nicht besonders lange vor, bedingt durch den zu großen Leckstrom einer Diode. Das Problem ist auf der nächsten Hat Version 1.5 behoben. Es sollte eigentlich folgendes passieren: Das Raspberry Pi erkennt den HAT Brick und lädt den Kernel Treiber für den RTC Chip PCF8523. Der Kernel führt aber kein hwclock --hctosys aus, um die Systemzeit von der RTC Zeit zu setzen, dazu müsste der Kernel mit CONFIG_RTC_HCTOSYS=y gebaut sein, was bei Raspbian aber nicht der Fall ist. Jetzt
  12. Okay, dass bestätigt, dass irgendwo her ein Packet kommt, das an den HAT Brick geschickt wird und der dies als Abschaltbefehl für die Bricklets versteht. Das brickd.log verwirrt uns hier. Das Log quillt über an Warnungen dieser Art: Broadcasting response (...) because no client/zombie has a matching pending request Brick Daemon hat eine Antwort von der Hardware empfangen, für die es keine offene Anfrage gibt. Teilweise sind dies Antworten, die offensichtlich korrupt sind (unbekannte UID, ungültige Länge oder unbekannte Funktions-ID). Viele andere Antworten sind aber so ohne Kont
  13. Der HAT Brick flasht sich etwas ungewöhnlich. Du schließt den nicht per USB an, der micro USB Anschluss ist nur für Strom. Sondern du lässt den HAT Brick auf dem Raspberry Pi stecken, verbindest dich dann mit Brick Viewer zum Raspberry Pi und wählst auf den Update/Flashing Dialog den Bricklet Tab aus. Dort wählst du als Parent None und kannst dann als Port den HAT Brick auswählen. Dort wählst du als Plugin Custom aus und kannst dann die Firmware Datei über den Browse Knopf auswählen und der Flash Knopf die Firmwae flashen. Mit dem HAT Brick hat sich die Trennung zwischen Bricks und Brickl
  14. Teste auch mal bitte die angehängte Firmware 2.0.3 für den HAT Brick. Diese Version legt die set_bricklet_power Funktion tot, um zu verifizieren, dass es wirklich ein fälschlicher Aufruf dieser Funktion ist, der das Problem erzeugt. hat-brick-firmware-203.zbin
  15. Willst du damit sagen, dass du das Problem nicht nur an einem, sondern an zwei Aufbauten hast? Update auch mal bitte alle Tinkerforge Software. Also Brick Viewer auf 2.4.13, Brick Daemon auf dem Raspberry Pi auf 2.4.1 und C/C++ auf 2.1.19. Mir ist kein Bug bekannt in den alten Versionen der zum Problem passt, aber ich möchte vermeiden, dass wir hier alte bereits behobene Bugs suchen. Kannst du bitte das /var/log/brickd.log vom Raspberry Pi hier anhängen, vielleicht steht dort etwas interessantes drin. Welche Kernel Version hast du auf dem Raspberry Pi laufen (was gibt "uname -a"
  16. Hast du da einfach eine UID Kollision? Schau mal bitte das alle Bricks und Bricklets unterschiedliche UIDs haben.
  17. Zusätzlich könntest du das Programm in Valgrind laufen lassen. Valgrind dient u.a. dazu Speicherkorruption zu finden.
  18. Das sieht so aus als ob dein Programm da unabsichtlicherweise hat_set_bricklet_power(hat, false) aufruft. Ein industrial_dual_relay_set_monoflop(...) Aufruf für Channel 0 wird bei passend korrumpierter UID als hat_set_bricklet_power(hat, false) verstanden, da beide Funktionen die Funktions-ID 3 haben und der Channel 0 Parameter als false interpretiert werden kann. Daher wäre es interessant zu sehen (z.B. per Wireshark auf localhost), ob dein Programm wirklich diesen korrumpierten Aufruf schickt.
  19. Interessant! Zwischen dem 5V Regler und dem 5V Ausgängen zu den Bricklets sitzt ein TPS22975 Leistungsschalter, über den der HAT Brick die Versorgung der Bricklets abschalten kann. Der TPS22975 Chip hat auch einen Überlastschutz. Entweder schaltet der HAT Brick die 5V Versorgung willentlich ab, was er nicht von sich aus tut, sondern nur beim Aufruf der entsprechenden API Funktion, oder der Überlastschutz des Chips greift ein. Tritt das Problem auch auf, wenn der Display nicht über den Bricklet Port versorgt wird? Bzw. was ist der minimalste Aufbau mit dem das Problem auftritt? Ü
  20. Es wundert mich, dass du das 24V Netzteil mit 20V misst. Kannst du ein Foto vom Gesamtaufbau zeigen? Die 5V für die Bricklets und das Raspberry Pi können vom HAT Brick geschaltet werden. Die 3 großen Kondensatoren neben der micro USB Buchse auf dem HAT bilden die Ausgangskapazität des 5V Reglers. Könntest du dort auch mal die 5V messen (die Masseseite hat den schwarzen Balken) an einem der 3 Kondensatoren? Die Frage ist, ob der HAT Brick die 5V abschaltet (5V nur an den Bricklet Ports weg), oder ob der 5V Regler an sich einbricht (5V am Kondensator weg). Geht dann auch die Statu
  21. Woran machst du fest, dass das Raspberry Pi an bleibt? Das Raspberry Pi wird aber über den HAT Brick versorgt, oder versorgst du das Raspberry Pi unabhängig vom HAT?
  22. Du hast im Brick Viewer dem Haken für "Use Authentication" gesetzt, Authentication in Brick Daemon aber nicht konfiguriert. Nimm mal den Haken für "Use Authentication" im Brick Viewer wieder weg.
  23. Ich habe das Brick Viewer UI mal so abgewandelt, dass man den Port nicht so einfach aus Versehen verstellen kann.
  24. Tritt das Problem auch auf, wenn an den Relaisausgängen nichts angeschlossen ist? Wie häufig tritt das Problem auf? Eher alle 10 oder eher alle 1000 Schaltvorgänge? Wie werden die LEDs mit Strom versorgt? Auch über das 24V Netzteil? Wenn ja, wie viel Leistung nehmen die LEDs auf? Bricht vielleicht durch das Schalten der LEDs die Spannung des Netzteils zusammen? Geht auch das Raspberry Pi mit aus? In welcher zeitlichen Folge und mit welcher Frequenz werden die Relais geschaltet? Werden die abwechselnd oder alle gleichzeitig geschaltet?
  25. Was schaltest du denn mit den Industrial Dual Relais? Hast du da induktive Lasten dran, aber z.B. keine Freilaufdiode, Varistor oder Snubber verbaut?
×
×
  • Create New...