photron

Signal 9 ist das Unix Signal SIGKILL. Wenn du im Brick Viewer den Kill Knopf für das Programm klickst, dann wird es mit SIGKILL umgebracht. Das wichtige an SIGKILL ist, dass sich das Programm nicht dagegen wehren kann. Wenn du den den Exit Knopf klickst wird das Programm mit SIGTERM (Signal 15) gebeten sich zu beenden. Wenn das Programm aber nicht will, kann es SIGTERM ignorieren. Sprich SIGKILL kann auftreten, wenn du den Kill Knopf klickst, was du wahrscheinlich nicht getan hast. Ansonsten kann SIGKILL auftreten, wenn du das Programm löscht während es noch läuft, oder der RED Brick API Daemon sich beendet wenn es noch läuft. Das wird aber alles hier nicht der Fall sein. Wie viel RAM braucht dein Programm? Es kann sein, dass dein Programm allen RAM des RED Bricks belegt. In dem Fall kommt der Linux OOM (Out-of-Memory) Killer ins Spiel, der so lange Programm (mit SIGKILL) umbringt bis wieder ausreichend RAM frei ist damit das System weiterlaufen kann.

Ich denke dein Problem ist, das du zwar den Mode umstellen kannst und der Monitor auch folgt, aber X nicht. Ich habe hier gerade etwas damit herumgetestet bekomme aber X nicht dazu nach einer Mode-Änderung seine Auflösung mit zu ändern. Die Fallback-Auflösung ist in der Kernel Kommandozeile definiert. Die ist beim RED Brick mit in den Kernel reinkompiliert und daher extern nachher nicht mehr änderbar. Um diese zu ändern müsstest du also den Kernel seblst neu kompilieren: https://github.com/Tinkerforge/red-brick/blob/master/image/README.rst

In which file format did you store the data? Here's a LabVIEW example for reading CSV files: https://decibel.ni.com/content/docs/DOC-12287

LPD, ich nehme mal an dein Skript würde nicht 0 ins RRD eintragen, wenn der Sensor nicht wirklich 0 geliefert hat. Ich hatte hier einen einwöchigen Test mit 3 Bricklets laufen, keine Probleme. Ich hatte sie allerdings nicht in einem geschlossenen Gehäuse wie du. Es besteht also die Chance, dass es dem Bricklet in deinem Gehäuse zu warm wird. Die Möglichkeit kann ich nicht ausschließen. Abgesehen davon gehen mir die Ideen aus. Was ich dir anbieten kann, ist dir ein neues Ambient Light Bricklet 2.0 zu zuschicken, um zu sehen ob das einen Unterschied macht. Melde dich dafür mit deiner Bestellnummer bei info@tinkerforge.com und verweise auf den Thread hier.

Loetkolben: Der Sensor verwendet einen 16 Bit 2-Kanal ADC. Dies beiden 16 Bit Werte sind aber nicht in Lux, sondern müssen noch nach einer bestimmten Formel mit einander verrechnet werden um den endgültigen Messwert in Lux/100 zu erhalten. Daher mach es keinen Sinn die 16 Bit Rohdaten des Sensors durchzureichen. Lux/100 sind schon richtig. Das Bricklet gibt den Wert in hundertstel Lux an (Lux/100). Du musst ihn als durch 100 Teilen um einen Wert in Lux zu bekommen. Bezüglich der 64k Lux Grenze: Die ist nicht hart. Der Sensor kann bis zu 150% darüber messen, sprich bis zu ca. 100k Lux. Allerdings nimmt ab 64k Lux die Genauigkeit ab. Da ist kein Fehler diesbezüglich in der Firmware des Bricklets. Allerdings ist die Dokumentation nicht ganz vollständig an der Stelle. Ich habe das nun korrigiert.

Ich nehme an du hast den Monitor angeschlossen und dann erst den RED Brick angeschlossen? Falls nicht, teste das bitte mal in der Reihenfolge. Wenn du nicht Mode 26 setzt, dann skaliert der Monitor das 800x480 Bild auf 1360x768 hoch? Wenn du Mode 26 setzt, dann skaliert der Monitor nicht mehr, sondern zeigt das 800x480 Bild mit schwarzen Balken rundherum auf 1360x768 aufgefüllt an? Das 800x480 Bild ist aber immer vollständig und nichts ist abgeschnitten?

Wenn du einfach das PHP Beispiel hier unverändert (abgesehen von der UID des Brickelts) testet, funktioniert das? http://www.tinkerforge.com/de/doc/Software/Bricklets/NFCRFID_Bricklet_PHP.html#write-read-type-2 Hast du mal Daten lesen/schreiben mit Brick Viewer getestet?

Ich nehme an, dass du das "Write Read Type 2" Beispiel angewandelt hast? Ich habe deine Änderungen getestet und es funktioniert. Wie testet du denn ob es funktioniert hat, bzw. wie stellst du fest, dass es nicht funktioniert hat?

Jedes deiner 4 Linear Poti Bricklets sendet seinen Callbacks für sich selbst, da wird nichts zusammengefasst oder so. Wenn du 4 Bricklets hast kannst du auch 4 verschiedene Callbacks erhalten.

Nein, nicht jedes Device hat einen Callback Thread, sondern jede IP Connection. Wenn du deine 4 Linear Potis über die gleich IP Connection ansprichst, dann werden deren Callbacks über den einen Callback Thread der einen IP Connection ausgeliefert.

Das Datenblatt des Sensors schweigt sich über UV aus. Das erste Bild ist von einem der zwei Ambient Light 2.0 Bricklets, die hier schon seit Montag messen. Heute morgen habe ich sie nach draußen gestellt und zu Mittag waren sie direkt in der prallen Sonne. Keine Probleme. Das zweite Bild ist von einem weiteren Ambient Light 2.0 Bricklet, dass ich zur Westseite hinter ein Fenster gestellt habe. Die ersten beiden stehen an der Ostseite und sind jetzt mehr im Schatten. Dieses steht aber gerade in der vollen Sonne, allerdings hinter einer Fensterscheibe. Auch hier bisher keine Probleme. Ich glaube mein RRD ist etwas unglücklich eingestellt, was zu diesen etwas "eckigen" Graphen führt.

Plugin: Analog In Bricklet 2.0.5, Analog In Bricklet 2.0 2.0.1, Voltage Bricklet 2.0.2 Fix value range and comparison for threshold callback Download: Analog In Bricklet, Analog In Bricklet 2.0, Voltage Bricklet

Plugin: Analog In Bricklet 2.0.5, Analog In Bricklet 2.0 2.0.1, Voltage Bricklet 2.0.2 Wertebereich und Vergleichslogik für Threshold-Callback korrigiert Download: Analog In Bricklet, Analog In Bricklet 2.0, Voltage Bricklet

Das ist ein Copy-Paste Fehler. Der betrifft mehrere Bricklets. Aber der gültige Werte Bereich für min/max ist bei allen nicht beeinträchtigt. So dass wir die Stabilität der API höher gewertet haben als die Korrektheit der Typen. Als ich das noch mal durchgegangen bin ist mir allerdings aufgefallen, dass das für das Analog In Bricklet (2.0) nicht stimmt und nicht der vollständige Messbereich als min/max angegeben werden kann. Daher haben wir uns jetzt entschieden alle betroffenen Bricklets zu korrigieren.

Das ist so machbar, kein Problem.

Ich habe hier ein Ambient Light v2 gerade mal 5 Minuten lang mit 200°C Heißluft warm gemacht, keine Probleme. Ich versucht mal meinen Testaufbau hier mehr Sonne auszusetzen.

Mein Test hier läuft bisher ohne Probleme. Der Aufbau steht aber nicht ideal und bekommt nicht die maximale Sonne mit. Der Sensor auf dem Ambient Light v1 ist im Datenblatt bis +85°C angegeben, der des Ambient Light v2 bis +70°C. Möglich, dass die 15°C Differenz hier den Unterschied machen, aber ich glaube es nicht. Ist das Ambient Light v2 am gleiche Master Brick angeschlossen, wie die anderen Bricklets deren Graphen keine Lücken aufweisen? Kannst du mal in deinem crontab hier das > durch >> ersetzen und in aussenwerte.sh am besten auch noch date mit ausgeben? /home/lpd/aussenwerte.sh > /home/lpd/aussenwerte.lst Mich interessiert, ob zu den Zeiten an denen du Lücken im Graph hast die Shell Bindings Fehler/Timeouts melden.

You could build a scale for 100kg using two 50kg load cells and two Load Cell Bricklets and add the measurement of both for the final result.

Die nächste Brick Viewer Version wird auch openHAB .persist, .script und .transform Dateien unterstützen.

Verstehe ich die Graphen richtig, dass da zwischen ca 15:30 und 16:00 Uhr und kurz nach 18:00 Uhr einfach Daten fehlen? Warum da ab 13 Uhr so ein glatter Einbruch drin ist, ist mir nicht klar. Ich habe deine Script jetzt mal genommen und lasse sie hier gerade mit 2 Bricklets laufen. Eines mit Plugin 2.0.0 und eines mit Plugin 2.0.1. Bei sind auf 64000 lx und 50 ms eingestellt. Ich lasse allerdings cron nach aussenwerte.lst mit ">>" statt ">" schreiben, damit ich später auch noch ältere Fehler sehen kann. Bisher läuft es.

There are several print statements in the code like this one: print "CRITICAL : %s too high %s %s" % (self.name, val, self.unit) According to the link pnp4nagios expects <whatever> | <label>=<value>;[<warn>];[<crit>];[<min>];[<max>] to be printed. The script currently only prints the <whatever> part. You can extend the print statements like this to add the part pnp4nagios is looking for: print "CRITICAL : %s too high %s %s" % (self.name, val, self.unit) + " | " + self.name + "=" + str(val)

Plugin: Accelerometer Bricklet 2.0.1 Fix value comparison for threshold callback Download: Accelerometer Bricklet

Plugin: Accelerometer Bricklet 2.0.1 Vergleichslogik für Threshold-Callback korrigiert Download: Accelerometer Bricklet

Kann dir der Tobit Server oder All-Inkl sagen welche Absender Adresse wirklich verwendet wurde? Weil mir nicht klar ist wo die falsche Absender Adresse wegkommen soll. Testest du postfix auf dem RED Brick oder einem anderen Rechner?

Plugin: Ambient Light Bricklet 2.0 2.0.1 Ignore invalid sensor values Download: Ambient Light Bricklet 2.0