cbachmann Geschrieben February 24, 2021 at 11:41 Geschrieben February 24, 2021 at 11:41 Ich würde gerne mehrere ds18b20 Temperatursensoren an einem 1-wire Bricklet betreiben und via MQTT (Mosquitto, Node-RED) auslesen (wohl günstiger als mehrere PT100 oder Thermoelement-Bricklets). Ich habe es relativ schnell geschafft, von einem einzelnen angeschlossenen Temperatursensor gültige Werte zu bekommen (auch dank der guten Beispiele hierfür). Wenn ich jetzt aber mehrere auslesen möchte, muss ich den "identifier" von 0 auf den tatsächlichen Wert des jeweiligen auszulesenden Sensors setzen, um sie unterscheiden zu können (?). Ich sehe auch im BrickViewer nach einem Klick auf "SearchBus" die ID (ok hier als hex, muss ich in meinem Fall mit NodeRED noch nach dezimal konvertieren).. Ersetze ich in meinem Test-Flow den "identifier" von 0 auf diesen Wert, sind die ausgelesenen Temperaturwerte aber leider unsinnig. Ich habe zur Überprüfung, ob ich die korrekten Identifier verwende, versucht die identifier der Teilnehmer am Bus via MQTT auszulesen; dazu gibt es ja den MQTT request auf dem topic "tinkerforge/request/one_wire_bricklet/<meineID>/search_bus". Versuche ich das, kommt aber nichts zurück; ich bin relativ sicher, dass ich wenn was käme es mitbekommen würde - "reset_bus" geht nämlich und es gibt eine sinnvolle Antwort; requeste ich z.B. als Test das topic "search-bus" (falsch geschrieben), bekomme ich auch eine Fehlermeldung. Scheint mir ein Bug in der 1-Wire Firmware? Hat jemand das schon einmal versucht? Danke im Voraus Zitieren
rtrbt Geschrieben February 24, 2021 at 13:53 Geschrieben February 24, 2021 at 13:53 Moin, Das scheint ein Bug in den MQTT-Bindings zu sein. Funktioniert es mit der angehangenen Version der Bindings? tinkerforge_mqtt_bindings_2_0_14_030e9ae2.zip Zitieren
cbachmann Geschrieben February 24, 2021 at 21:32 Autor Geschrieben February 24, 2021 at 21:32 Danke für die schnelle Antwort. Also ich kann mit der oben angehängten Version der mqtt Bindings zumindest den identifier auslesen. Der ist tatsächlich anders als ich mir aus den BrickViewer-Ausgaben errechnet hatte.. komisch, aber ok.. Leider bin ich beim Auslesen der Temperaturen aber immer noch nicht erfolgreich - ich glaube, es liegt daran, dass die "Auflösung" des Zahlenformats (MQTT, vielleicht aber auch Node-RED) an einer Stelle zu gering ist (vielleicht nicht ganz präzise formuliert). Der "identifier" ist: 72366772975674664 (Antwort auf search_bus kam als String Object (JSON)). Gebe ich den Wert (als Zahl, nicht als String) in meinem Subflow ein, wird über MQTT der identifier als Payload mit einer Zahl (kein JSON-String) vom Wert 72366772975674660 übertragen. Das kann ja eigentlich nicht gehen? Ich habs als JSON String versucht, dann gibt das MQTT Binding aber die Fehlermeldung: <ERROR> MQTT bindings: Call write_command of one_wire_bricklet N7s: Argument identifier was not of expected type int. Ideen? Hoffe, ich habs präzise genug formuliert.. Zitieren
rtrbt Geschrieben February 25, 2021 at 10:27 Geschrieben February 25, 2021 at 10:27 Du hast vermutlich folgendes Problem: Die Identifier von search_bus sind 64-Bit-Zahlen, die die MQTT-Bindings auch ganz normal behandeln. Node-RED parst das JSON und wandelt dabei die Zahl in einen double um, mit dem Ganzzahlen nur bis 53 Bit korrekt darstellbar sind. Das passiert, weil in Javascript der Zahl-Typ immer double ist (es sei denn man benutzt BigInt, das ist aber recht neu). Die Lösung dafür ist, Node-RED den Payload nicht parsen zu lassen, sondern händisch auf dem JSON-String zu arbeiten um dir die Zahlen rauszuziehen. Da müsstest du etwas Javascript schreiben und BigInt benutzen. Damit das in Zukunft einfacher ist, werde ich in die MQTT-Bindings einen Javascript-Kompatibilitätsmodus einbauen, der 64-Bit-Zahlen als Strings ausgibt, die man direkt in BigInt benutzen kann. Das wird aber voraussichtlich erst nächste Woche. Zitieren
cbachmann Geschrieben February 25, 2021 at 20:29 Autor Geschrieben February 25, 2021 at 20:29 Danke wiederum für die schnelle Antwort. Bin nicht sicher, ob ich richtig liege - vielleicht habe ich oben auch unklar formuliert. Also ich kann definitiv den korrekten/kompletten Identifier vom Sensor aus dem Bricklet via MQTT auslesen. Ich empfange einen JSON String, kein JSON Objekt, deswegen stört die mangelnde Auflösung hier nicht - so sieht die Response Message aus in Node-RED: Das Problem ist bei der anderen Richtung - also wenn ich Kommandos an das Gerät mit dem entsprechenden Identifier SENDEN will. Da muss ich anscheinend ein JSON-Objekt (Zahl) via MQTT senden; sende ich einen JSON-String wie in der Response ja auch gekommen war, dann kommt o.g. Fehlermeldung: <ERROR> MQTT bindings: Call write_command of one_wire_bricklet N7s: Argument identifier was not of expected type int. Sende ich stattdessen ein JSON Objekt mit dem Identifier als Zahl, dann wird die wegen mangelnder Genauigkeit verfälscht (sehe ich schon in Node-RED) und (das nehme ich an, habs nicht mit dem Oszi geprüft, was wirklich auf dem 1-Wire anliegt) eben dort falsch gesendet. Könntet ihr nicht einfach im MQTT Binding auch so einen JSON String akzeptieren? Vielleicht verstehe ich das aber auch falsch.. Ich kann ruhig ein paar Tage warten, bis das geht - wäre ja eh schon super-schnell, vielen Dank. Mit Javascript Programmierung wollte ich eigentlich nicht anfangen,dann könnte ich ja gleich auf das MQTT verzichten.. Zitieren
rtrbt Geschrieben February 26, 2021 at 12:49 Geschrieben February 26, 2021 at 12:49 Ah das hatte ich tatsächlich genau falsch herum verstanden. 16 hours ago, cbachmann said: Könntet ihr nicht einfach im MQTT Binding auch so einen JSON String akzeptieren? Das sollte gehen. Ich pack es mal mit auf die Liste für das nächste Release. Zitieren
cbachmann Geschrieben February 27, 2021 at 21:00 Autor Geschrieben February 27, 2021 at 21:00 Ok, vielen Dank - dann warte ich darauf. Zitieren
rtrbt Geschrieben March 1, 2021 at 15:11 Geschrieben March 1, 2021 at 15:11 Teste mal bitte die Version im Anhang. Du kannst damit jetzt Strings als Zahlen übergeben (sogar mit z.b "0xCAFE", "0o777" und "0b1001" hexadezimal, oktal und binär). Außerdem kannst du den Bindings das Argument "--int64-as-string" mitgeben, dann werden 64-Bit-Zahlen stattdessen als String in das JSON-Objekt eingefügt, damit du immer das JSON parsen kannst (und dann komfortabler damit arbeiten). tinkerforge_mqtt_bindings_2_0_14_8f0ac4c1.zip Zitieren
cbachmann Geschrieben March 8, 2021 at 13:24 Autor Geschrieben March 8, 2021 at 13:24 Danke - damit geht es. Ich habe nicht alles ausprobiert, was Du geschrieben hast, sondern einfach nur den identifier als JSON string geschickt. Leider kämpfe ich noch mit anderen Problemen - wenn das 1-Wire Bricklet angeschlossen ist, stürzt der komplette Brick-Stack ca. 1x am Tag ab; stecke ich ihn ab, geht es problemlos auch deutlich länger. Meine Tests fahre ich gerade an einem zweiten Brick. Evt. gibt es einen Zusammenhang zu diesem Thema? Keine Ahnung.. Damit wäre das hier beschriebene Problem aber gelöst. Danke nochmal. Die anderen Dinge später. Zitieren
DoIT Geschrieben March 9, 2021 at 10:38 Geschrieben March 9, 2021 at 10:38 (bearbeitet) Da hier auf meinen Thread verlinkt wurde, möchte ich mich kurz zu Wort melden. Leider ist das Problem nach wie vor nicht gelöst, es ist aber schön wenn ich nicht der Einzige mit dem Problem bin. Wie viele Sensoren verwendest du? Welche Kabellängen? Ist es bei dir auch so, dass die LEDs vom Bricklet ausgehen oder werden "nur" keine Sensoren mehr gefunden? bearbeitet March 9, 2021 at 10:43 von DoIT Zitieren
cbachmann Geschrieben March 10, 2021 at 20:11 Autor Geschrieben March 10, 2021 at 20:11 Nur 1 Sensor bisher.. Kabellänge 50cm, glaube ich. Brick ist dann nach einigen Stunden komplett tot und braucht Reset, nicht nur das 1-Wire Bricklet.. ich muss zugeben, ich hatte Deinen Thread schon vor einiger Zeit gelesen - ich habe eben nochmal geschaut, ist bei mir wohl doch eine etwas andere Situation. Vielleicht sollte man den Link doch wieder entfernen. Ich habe erst wieder in ca. 1 Woche Zeit zum weiteren Experimentieren. Zitieren
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.