André K.

Zum Thema Kalibrierung und der Frage was der "echte" Wert ist hat der YouTuber "Big Clive" mal ein interessantes Video gemacht, das Verfahren war mir bis dato nicht bekannt (und selbst getestet habe ich es auch nicht). André

Daß es nicht direkt in der Sonne hängt macht vermutlich den Unterschied aus … seitdem es nicht mehr so ätzend heiß ist läuft es bei mir auch ziemlich stabil. André

Ist das der Prozessor auf der Ethernet Extension? RED-Brick ist für mich ja uninteressant, weil nicht in Verwendung André

Das ist richtig, da mein Gehäuse ja im Außenbereich hängt ist das aber "per Design" ohne Luftaustausch, denn es darf ja kein Wasser eindringen. Welcher Temperaturbereich wird den "offiziell" unterstützt? André

Würde ich auch als wahrscheinlich ansehen, bei mir traten jetzt bei den heißen Tagen die Ausfälle wie erwähnt schon bei unter 50°C im inneren auf. Wie misst Du die Temperatur im Gehäuse? Bei mir habe ich dafür ein ausrangiertes Temperature 1.0 Bricklet drin. André

Danke für die Info! Bevor ich an dem einen Tag hingefahren bin habe ich noch ein paar Versuche mit Telnet unternommen, bis dann irgendwann auch da nur noch "Connection refused" kam und auch der Brick Viewer keine Verbindung mehr aufbauen konnte. Ich schätze, daß einer der Master-Bricks ausgestiegen ist. In den Tagen danach, als es wieder so heiß war, ist der Stapel noch zwei Mal komplett ausgefallen, jedes Mal so um die 50°C gemessener Innentemperatur herum. Da scheint dann also so etwa die Grenze zu sein. Wenn es sich auf ein paar Tage im Jahr beschränkt werde ich damit leben müssen … die alte Conrad-Telemetrie-Wetterstation die über 20 Jahre dort in einem viel kleineren Gehäuse hing hat das übrigens klaglos mitgemacht André

Ich krame diesen Thread mal hervor … Meine Erfahrung der letzten Tage ist, daß es ab 45°C anscheinend kritisch wird. Was natürlich für eine Wetterstation irgendwie blöd ist, aber da muß ich mir wohl was einfallen lassen wie ich das löse. Vielleicht kann jemand vom Tinkerforge-Team aber nochmal was "Offizielles" dazu sagen. André

Bin gestern übrigens doch noch vor Ort gefahren und hab den Stecker kurz gezogen. Dabei ist auch zum ersten mal eine "unhandled enumeration" vorgekommen, das Logging funktioniert also grundsätzlich. Für welchen Betriebs-Temperaturbereich ist der Master-Brick und die Ethernet-Extension eigentlich ausgelegt? Nicht daß ich da zu großzügig bin … ich hab das alte Temperature-Bricklet ja in den grauen Kasten verfrachtet und zuletzt hatte es 49°C gemeldet. Viel, aber noch nicht kritisch, oder doch? André

Es nimmt kein Ende … heute Morgen ist wieder das eine Bricklet ausgestiegen, und noch bevor ich jetzt daheim war hat es um kurz vor vier anscheinend den ganzen Stapel zerlegt. Der Brick Viewer connected sich, aber zeigt nix an. Auf Ping antwortet es noch. Was kann ich noch tun, außer zum Haus meiner Eltern zu fahren und das Netzwerkkabel zu ziehen? Zu dumm daß der Switch nicht gemanaged werden kann, sonst hätte ich ja kurz PoE abdrehen können, sowas fällt einem immer erst hinterher ein … André

Das könnte etwas schwierig werden 😂 Aber ich hoffe Du lässt es noch etwas laufen, hier dauert es ja auch manchmal Tagelang. Und ich meine, eines hat sich seit dem Einspielen der Test-FW ja auch geändert, nämlich daß per Getter nicht immer derselbe Wert geliefert wird. André

Ah OK … wie gesagt, seit dem 22. Juli sollte ich das mitbekommen. Wirklich testen konnte ich es ja nicht, aber der else-Zweig ist ja so simpel, der sollte funktionieren … Ich würde also eher mal tippen daß etwas anderes passiert als ein "sauberer" Reboot. Deutet dieser eine gezählte Fehler auf nichts hin? Und was hat Dein Versuchsaufbau ergeben? André

Von wem wird die denn angestoßen, vom Master? Und wie bekommt der das mit — senden die Bricklets beim „Booten“ eine entsprechende Nachricht? Bis jetzt läuft übrigens alles noch normal … André

Update 😅 Diesmal hat es nur 15 Minuten gedauert bis zum erneuten Auftreten … gleiches Bild, Callback-Config "vergessen" aber jetzt wurde ein "error_count_frame" gezählt: Error status: array(4) { ["error_count_ack_checksum"]=> int(0) ["error_count_message_checksum"]=> int(0) ["error_count_frame"]=> int(1) ["error_count_overflow"]=> int(0) } André

Habe ich jetzt mal gemacht, mit (für mich) durchaus überraschendem Ergebnis: Per getter erhalte ich tatsächlich einen plausiblen Wert, der sich auch von Aufruf zu Aufruf geringfügig ändert. Aber: Das Bricklet hat anscheinend die Callback-Config vergessen, und auch die Status-LED-Config ist auf dem Defaultwert 3. Das hier ist das komplette Test-Skript: require_once('Tinkerforge/IPConnection.php'); require_once('Tinkerforge/BrickletTemperatureV2.php'); use Tinkerforge\IPConnection; use Tinkerforge\BrickletTemperatureV2; const HOST = '192.168.1.105'; const PORT = 4223; const UID = 'KEv'; // Change XYZ to the UID of your Temperature Bricklet 2.0 $ipcon = new IPConnection(); // Create IP connection $t = new BrickletTemperatureV2(UID, $ipcon); // Create device object $ipcon->connect(HOST, PORT); // Connect to brickd // Get current temperature $temperature = $t->getTemperature(); echo "Temperature: " . $temperature/100.0 . " °C\n"; echo "Callback configuration:\n"; $conf = $t->getTemperatureCallbackConfiguration(); var_dump($conf); echo "LED status:\n"; $led_status = $t->getStatusLEDConfig(); var_dump($led_status); echo "Error status:\n"; $error_status = $t->getSPITFPErrorCount(); var_dump($error_status); echo "Press key to exit\n"; fgetc(fopen('php://stdin', 'r')); $ipcon->disconnect(); Und das hier die komplette Ausgabe: Temperature: 24.5 °C Callback configuration: array(5) { ["period"]=> int(0) ["value_has_to_change"]=> bool(false) ["option"]=> string(1) "x" ["min"]=> int(0) ["max"]=> int(0) } LED status: int(3) Error status: array(4) { ["error_count_ack_checksum"]=> int(0) ["error_count_message_checksum"]=> int(0) ["error_count_frame"]=> int(0) ["error_count_overflow"]=> int(0) } Press key to exit So, und nachdem ich mich anschließend via Brick-Viewer verbunden habe (und damit die Enumeration getriggert habe) kamen auch sofort wieder Callbacks an, ohne zusätzlichen Reset. Und das kleine PHP-Skript hat dann auch die korrekte Callback-Config geliefert: Callback configuration: array(5) { ["period"]=> int(1000) ["value_has_to_change"]=> bool(true) ["option"]=> string(1) "x" ["min"]=> int(0) ["max"]=> int(0) } LED status: int(0) Ich hoffe, mit diesen Infos kannst Du was anfangen. André

Bislang kein einziges Mal, weder im Syslog noch in der Datenbank. Dieser else-Zweig ist allerdings erst seit der Version vom 22. Juli drin. Übrigens, während wir hier schreiben ist es wieder aufgetreten bzw. heute morgen um kurz vor 10, ich hab da so eine interne Statusseite auf der ich nachsehen kann wann zuletzt was eingetrudelt ist: ("Temperatur 2" ist übrigens der Wert vom Humidity-Bricklet) Soll ich noch irgendwas spezielles testen, bevor ich gleich per Brick-Viewer drauf gehe? André