photron

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

Plugin: Ambient Light Bricklet 2.0 2.0.1 Ungültige Sensorwerte werden jetzt ignoriert Download: Ambient Light Bricklet 2.0

Diese Lücken in den Graphen sind mir nicht klar. Zeichnet das Tool keinen durchgehenden Graph, sondern nur Punkte? Oder sind die Lücken absichtlich da? Kannst du mal dein Skript zeigen, dass die Daten abfragt und in die RRD Datei packt? Einmal pro Minute 3 Werte messen sollte überhaupt kein Problem sein. Fragst du die Daten per GetIlliminance() ab? Behandelt dein Script Fehler die der GetIlliminance() Aufruf haben kann, z.B. Timeout? Das einzige was ich in Firmware 2.0.1 geändert habe ist die Behandlung ungültiger Werte vom Sensor. Firmware 2.0.0 hat versucht die zu verwenden und hat dann potentiell falsche Ergebnisse geliefert. Das war der Grund warum deine erste Messreihe mit 64000 Lux Messbereich und 400 ms Integrationszeit bei 38070 Lux stecken geblieben ist. In 2.0.1 werden ungültige Werte jetzt ignoriert. Dass heißt, wenn der Sensor in Sättigung läuft, weil der Messbereich zu klein und/oder die Integrationszeit zu lang ist, dann liefert das Bricklet so lange den letzten gültige Messwert bis der Sensor wieder gültige Werte liefert.

Wir sind das hier noch mal im Detail durchgegangen: - Auf dem RED Brick wird das sendemail Tool (nicht zu verwechseln mit sendmail) verwendet. Dieses nutzt nicht ssmtp, sondern arbeitet autark und benötigt keine anderen Tools. Daher können Änderungen an der ssmtp Konfiguration keinen Effekt haben. - Wir haben das hier mit unserem Email Server und Google Mail getestet und auch die SMTP Kommunikation mit dem SMTP Server per Wireshark angesehen und in keinem Fall taucht eine andere From Adresse als die eingestellt aus. Daher ist mir nicht klar warum All-Inkl sagt die From Adresse wäre nicht passend. - Ich habe eben noch mal mit einer All-Inkl Email Adresse, einem RED Brick mit Image Version 1.7 und Brick Viewer 2.2.7 getestet und es funktioniert ohne Probleme: From: <name>@<domain> To: <name>@tinkerforge.com Server: <subdomain>.kasserver.com Port: 25 User: <name>@<domain> Passwort: <password> SSL/TLS: aktiv Mir ist nicht klar was da bei dir das Problem macht.

jan, für SMS-only kannst du den Mobile Internet Service abgeschaltet lassen. SMS senden und Mobile Internet sind zwei unabhängige Dinge.

Testet mal bitte diese Version: http://download.tinkerforge.com/_stuff/brickd_macos_2_2_2_rc1.dmg Die betroffenen Verzeichnisse werden jetzt ab 10.11 nicht mehr verwendet.

Ich hab heute mal den ganzen Tag eine Messreihe laufen lassen. Alle 5 Sekunden abgefragt und ich kann keine Aussetzer feststellten. Es war heute aber auch nicht sonnig. Maximal 10000 Lux gabs.

Du muss immer die UID des Bricks oder Bricklets nehmen mit dem du arbeiten willst. Wie die Bricklets an Bricks angeschlossen sind spielt keine Rolle. Und es funktioniert eben nicht beim Simple Beispiel. Das sieht nur aus als ob: Distance: 14671 cm Das sind 146,71 m, das Laser Range Finder Bricklet misst aber maximal bis 40 m.