Temperatur und Luftdruck liefern plötzlich falsche Werte

[André K.]

vor 1 Stunde schrieb rtrbt:

Das ist für mich ein sehr starker Indikator dafür, dass das Bricklet sich resettet. Mir ist nur unklar warum das so oft passiert und warum du die Enumerations nicht siehst, wenn es wieder kommt.

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é

[rtrbt]

1 hour ago, André K. said:

Von wem wird die denn angestoßen, vom Master?

Normalerweise nur wenn du es aus deinem Programm heraus machst. Wenn du aber z.b. Stromversorgungsprobleme oder sowas hast kann das auch sporadisch passieren.

1 hour ago, André K. said:

Und wie bekommt der das mit — senden die Bricklets beim „Booten“ eine entsprechende Nachricht?

Die (Koprozessor-)Bricklets warten beim Boot eine Sekunde auf eine Enumerate-Anfrage, wenn die nicht kommt schicken sie von sich aus ein Enumerate mit connection_type=..._CONNECTED. Deshalb meinte ich, dass du bei deinem Enumerate-Handler darauf reagieren solltest.

[André K.]

vor 5 Stunden schrieb rtrbt:

Die (Koprozessor-)Bricklets warten beim Boot eine Sekunde auf eine Enumerate-Anfrage, wenn die nicht kommt schicken sie von sich aus ein Enumerate mit connection_type=..._CONNECTED. Deshalb meinte ich, dass du bei deinem Enumerate-Handler darauf reagieren solltest.

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é

[rtrbt]

12 hours ago, André K. said:

Deutet dieser eine gezählte Fehler auf nichts hin?

Das ist ein Framing-Error, das heißt das ein Paket entweder eine komplett ungültige Länge hatte (z.b. nur ein halber Header) oder dass die Länge im Header nicht zur echten Paketlänge gepasst hat. Das könnte eventuell das letzte Paket sein, das gerade halb gesendet wurde, als das Bricklet sich neu gestartet hat. Ich hätte eher die Hoffnung gehabt, dass da deutlich größere Zahlen stehen, dann hätte man in Richtung defektes Kabel o.Ä. gehen können. So ist das ein eher schwaches Indiz.

12 hours ago, André K. said:

Und was hat Dein Versuchsaufbau ergeben?

Der steht seit Tagen hier rum und hat bisher maximal für 13 Sekunden die selbe Temperatur gemessen. Es scheint als bräuchte ich dein Dach hier.

[André K.]

vor 22 Stunden schrieb rtrbt:

Es scheint als bräuchte ich dein Dach hier.

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é

[rtrbt]

3 hours ago, André K. said:

Aber ich hoffe Du lässt es noch etwas laufen, hier dauert es ja auch manchmal Tagelang.

Den kann ich noch eine Weile laufen lassen, stört in der Ecke keinen.

3 hours ago, André K. said:

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.

Das heißt hoffentlich, dass es jetzt kein I2C- sondern nur ein Reset-Problem ist. Damit kann man notfalls ja umgehen, wenn die Enumerations ankommen.

[duaw]

Hallo,

mein altes Temperature-Bricklet liefert ja auch gelegentlich falsche Werte. Es ist via TF-MQTT-Service angeschlossen, der wie in der Doku beschrieben das MQTT-Binding bereitstellt.. 

In Node-Red erkenne ich das, dann resette ich dem Master in Node-Red per exec-Node. 

Leider muss ich dann den TF-MQTT-Service für diesen Stapel (eigene IP) neu starten. (Was ich jetzt erst mal noch manuell mache , aber das geht sicher auch via Node-Red ). 

Ein ganz "normaler" Reset des Masters parallel aus dem brickv bringt den Service/das Bindung auch aus dem Tritt. Nicht aber einen parallel laufenden anderen brickv. 

Warum ist das so?

Gruß, Uwe

 

[rtrbt]

Moin,

Was passiert mit dem Binding genau, wenn du den Master resettest? Starte die Bindings am besten mal mit --debug, dann sieht man eventuell mehr. Benutzt du für die Temperaturabfrage Callbacks oder Getter?

[duaw]

Hallo!

Ich frage alle 30sec zyklisch ab. Das sollte doch unkritisch sein, oder?

Ich habe das gerade nachgestellt (auf meinem Mac, habe Node-RED-Flow in der Zeit deaktiviert: 

python3 tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.111 --global-topic-prefix tinkerforge/111 --debug

Request:

2020-08-06 17:05:37,639 <DEBUG> MQTT bindings: Configuring connection to MQTT broker at 192.168.1.18:1883

2020-08-06 17:05:37,639 <DEBUG> MQTT bindings: Connected to MQTT broker at 192.168.1.18:1883

2020-08-06 17:05:37,646 <DEBUG> paho.mqtt.client: Sending CONNECT (u0, p0, wr0, wq0, wf1, c1, k60) client_id=b''

2020-08-06 17:05:37,647 <DEBUG> paho.mqtt.client: Received CONNACK (0, 0)

2020-08-06 17:05:37,647 <DEBUG> MQTT bindings: Connected to mqtt broker.

2020-08-06 17:05:37,647 <DEBUG> paho.mqtt.client: Sending SUBSCRIBE (d0, m1) [(b'tinkerforge/111/request/#', 0)]

2020-08-06 17:05:37,647 <DEBUG> paho.mqtt.client: Sending SUBSCRIBE (d0, m2) [(b'tinkerforge/111/register/#', 0)]

2020-08-06 17:05:37,647 <DEBUG> paho.mqtt.client: Sending PUBLISH (d0, q0, r0, m3), 'b'tinkerforge/111/callback/bindings/restart'', ... (4 bytes)

2020-08-06 17:05:37,647 <DEBUG> paho.mqtt.client: Sending SUBSCRIBE (d0, m4) [(b'tinkerforge/111/callback/bindings/restart', 0)]

2020-08-06 17:05:37,648 <DEBUG> MQTT bindings: Connecting to brickd at 192.168.1.111:4223

2020-08-06 17:05:37,648 <DEBUG> paho.mqtt.client: Received SUBACK

2020-08-06 17:05:37,649 <DEBUG> paho.mqtt.client: Received SUBACK

2020-08-06 17:05:37,649 <DEBUG> paho.mqtt.client: Received SUBACK

2020-08-06 17:05:37,651 <DEBUG> MQTT bindings: Connected to Brick Daemon: Connection established after request from user.

2020-08-06 17:05:37,652 <DEBUG> MQTT bindings: Connected to brickd at 192.168.1.111:4223

2020-08-06 17:05:49,496 <DEBUG> paho.mqtt.client: Received PUBLISH (d0, q0, r0, m0), 'tinkerforge/111/request/temperature_bricklet/aK1/get_temperature', ...  (0 bytes)

2020-08-06 17:05:49,497 <DEBUG> MQTT bindings:



2020-08-06 17:05:49,497 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet.

2020-08-06 17:05:49,503 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet succedded.

2020-08-06 17:05:49,503 <DEBUG> MQTT bindings: Publishing response to tinkerforge/111/response/temperature_bricklet/aK1/get_temperature

2020-08-06 17:05:49,504 <DEBUG> paho.mqtt.client: Sending PUBLISH (d0, q0, r0, m5), 'b'tinkerforge/111/response/temperature_bricklet/aK1/get_temperature'', ... (21 bytes)

2020-08-06 17:05:49,504 <DEBUG> MQTT bindings:

 

Alles Gut. 😀

2020-08-06 17:06:49,747 <DEBUG> paho.mqtt.client: Sending PINGREQ

2020-08-06 17:06:49,748 <DEBUG> paho.mqtt.client: Received PINGRESP

Reset im Brickviewer. Das folgende passiert dann manchmal

2020-08-06 17:07:47,960 <DEBUG> MQTT bindings: Device available: 6kN4to at 0 (Pos 0), Hardware: 2.1.0, Firmware: 2.4.10, Dev ID: 13

Exception in thread Callback-Processor:

Traceback (most recent call last):

  File "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 926, in _bootstrap_inner

    self.run()

  File "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 870, in run

    self._target(*self._args, **self._kwargs)

  File "tinkerforge_mqtt", line 1470, in callback_loop

    self.dispatch_packet(data)

  File "tinkerforge_mqtt", line 1363, in dispatch_packet

    firmware_version, device_identifier, enumeration_type)

  File "tinkerforge_mqtt", line 7123, in <lambda>

    self.ipcon.register_callback(IPConnection.CALLBACK_ENUMERATE, lambda *args: self.ip_connection_callback_fn(IPConnection.CALLBACK_ENUMERATE, *args))

  File "tinkerforge_mqtt", line 7208, in ip_connection_callback_fn

    d["_display_name"] = display_names[dev_id]

NameError: name 'display_names' is not defined

(Das ist aber wohl nicht kriegsentscheidend)

Jetzt wieder ein Request:

2020-08-06 17:09:14,327 <DEBUG> paho.mqtt.client: Received PUBLISH (d0, q0, r0, m0), 'tinkerforge/111/request/temperature_bricklet/aK1/get_temperature', ...  (0 bytes)

2020-08-06 17:09:14,327 <DEBUG> MQTT bindings:

Nicht mehr gut: 😒

2020-08-06 17:09:14,327 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet.

2020-08-06 17:09:14,327 <ERROR> MQTT bindings: Not connected (call of get_temperature of temperature_bricklet aK1)

2020-08-06 17:09:14,327 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet succedded.

2020-08-06 17:09:14,328 <DEBUG> MQTT bindings: Publishing response to tinkerforge/111/response/temperature_bricklet/aK1/get_temperature

2020-08-06 17:09:14,328 <DEBUG> paho.mqtt.client: Sending PUBLISH (d0, q0, r0, m6), 'b'tinkerforge/111/response/temperature_bricklet/aK1/get_temperature'', ... (127 bytes)

2020-08-06 17:09:14,328 <DEBUG> MQTT bindings:

Die Message ist

{"temperature": "{\"temperature\": null, \"_ERROR\": \"Not connected (call of get_temperature of temperature_bricklet aK1)\"}"}

Beenden des Bindings, Neustart, wieder alles gut. 

Hilft das?

Gruß, Uwe

 

[photron]

@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?

[duaw]

MEA CULPA ... 

1. Never touch a running system stimmt nicht immer! 

2. Gib' Acht, wo welche Datei liegt !!! (Und lösche, was Du nicht mehr brauchst ... )

python3 /usr/local/bin/tinkerforge_mqtt

Und: Ja, die Ausgabe ist 

2020-08-06 20:00:54,768 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet.
2020-08-06 20:00:54,772 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet succedded.
2020-08-06 20:00:54,772 <DEBUG> MQTT bindings: Publishing response to tinkerforge/111/response/temperature_bricklet/aK1/get_temperature
2020-08-06 20:00:54,772 <DEBUG> paho.mqtt.client: Sending PUBLISH (d0, q0, r0, m8), 'b'tinkerforge/111/response/temperature_bricklet/aK1/get_temperature'', ... (21 bytes)
2020-08-06 20:00:54,772 <DEBUG> MQTT bindings:

mit der letzten Leerzeile.

So geht's!

Danke! 

Uwe

[André K.]

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é

bearbeitet August 7, 2020 at 15:35 von André K.

[André K.]

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é

[batti]

Hallo  André ,

das du dich mit dem Brick Viewer verbinden kannst ohne Fehlermeldung ist sehr komisch. Ansonsten hätte ich folgende Theorie:

Ich habe den Thread nur kurz oberflogen und ggf. etwas übersehen. Ganz wichtig bei der Ethernet Extension ist es aber, dass diese nur eine begrenzte Anzahl an Sockets bereit stellt.

Sind diese belegt, kommst du nicht mir drauf. Daher ist es sehr wichtig sich nach dem "connect" auch sauber wieder zu "disconnecten". Das du die Ethernet Extension noch pingen kannst, deutet ein bisschen auf ein Problem dieser Art hin. Ich hatte vor kurzen einen Kunden der genau dieses Problem hatte. Bei ihm war das Problem, dass er sich in Fehlerfällen nicht sauber disconnect'tte. Über die Zeit waren dann irgendwann alle Sockets belegt und die Ethernet Extension nicht mehr erreichbar.

Wenn du die Standardkonfiguration der Ethernet Extension beibehalten hast, dann hast du vier normale Sockets und drei Websockets. In diesem Fall kannst du mal probieren mittels Websocket auf die Ethernet Extension zu kommen. Am einfachsten geht das über http://www.brickv.com/.

Hinweis: Brickv.com unterstützt längst nicht alle Module von uns. Der Master Brick müsste aber angezeigt werden.

Bzgl. des Temperaturbereichs gibt es keine generelle Aussage, da das sehr lastabhängig ist. Ich denke 49°C sollte hierfür in Ordnung, wenn auch irgendwo grenzwertig, sein.

[André K.]

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é