André K. Posted August 3, 2020 at 11:05 AM Author Share Posted August 3, 2020 at 11:05 AM 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é Quote Link to comment Share on other sites More sharing options...
rtrbt Posted August 3, 2020 at 12:21 PM Share Posted August 3, 2020 at 12:21 PM 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. Quote Link to comment Share on other sites More sharing options...
André K. Posted August 3, 2020 at 06:04 PM Author Share Posted August 3, 2020 at 06:04 PM 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é Quote Link to comment Share on other sites More sharing options...
rtrbt Posted August 4, 2020 at 06:50 AM Share Posted August 4, 2020 at 06:50 AM 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. Quote Link to comment Share on other sites More sharing options...
André K. Posted August 5, 2020 at 05:55 AM Author Share Posted August 5, 2020 at 05:55 AM 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é Quote Link to comment Share on other sites More sharing options...
rtrbt Posted August 5, 2020 at 09:34 AM Share Posted August 5, 2020 at 09:34 AM 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. Quote Link to comment Share on other sites More sharing options...
duaw Posted August 6, 2020 at 12:00 PM Share Posted August 6, 2020 at 12:00 PM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted August 6, 2020 at 12:39 PM Share Posted August 6, 2020 at 12:39 PM 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? Quote Link to comment Share on other sites More sharing options...
duaw Posted August 6, 2020 at 03:17 PM Share Posted August 6, 2020 at 03:17 PM 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 Quote Link to comment Share on other sites More sharing options...
photron Posted August 6, 2020 at 04:16 PM Share Posted August 6, 2020 at 04:16 PM @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? Quote Link to comment Share on other sites More sharing options...
duaw Posted August 6, 2020 at 06:03 PM Share Posted August 6, 2020 at 06:03 PM 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 Quote Link to comment Share on other sites More sharing options...
André K. Posted August 7, 2020 at 03:33 PM Author Share Posted August 7, 2020 at 03:33 PM (edited) 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é Edited August 7, 2020 at 03:35 PM by André K. Quote Link to comment Share on other sites More sharing options...
André K. Posted August 8, 2020 at 09:49 AM Author Share Posted August 8, 2020 at 09:49 AM 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é Quote Link to comment Share on other sites More sharing options...
batti Posted August 18, 2020 at 07:17 AM Share Posted August 18, 2020 at 07:17 AM 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. Quote Link to comment Share on other sites More sharing options...
André K. Posted August 18, 2020 at 07:45 AM Author Share Posted August 18, 2020 at 07:45 AM 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é Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.