cbachmann

Ja beide haben das schwarze Kabel. Ok vielen Dank, mit dem Umtauschangebot kann ich leben - ursprünglich war die Idee mal, mit den externen Antennen zu experimentieren, das ist aber nicht so wichtig. Email schreibe ich gleich.

Danke für die schnelle Antwort. Das mit dem UFL-Stecker hatte ich auch vermutet - die sind etwas "windig" und filigran. Die Kabel wirken etwas "kurz" und der Stecker unterliegt bei den einer leichten Biegung nach dem Stecker (das dünne Kabel ist halt nicht länger). Ich poste mal Fotos - sieht bei beiden Modulen, die ich habe, sehr ähnlich aus: Auf den ersten Blick sieht das für mich nicht ideal, aber ok aus ? Den Test mit einem der beiden Module als AP habe ich kurz versucht (auch wenn ich nicht glaube, dass es daran liegt - alle anderen Clients funktionieren super an meiner FritzBox). Leider gibt es da auch einen Fehler bei der Einrichtung ("Startup Error"), wenn ich eins der beiden als AP konfigurieren will.. das 2.0 Modul ist im Moment verbaut, das will ich gerade nicht zum Experimentieren hernehmen..

Ich habe hier zwei der alten Wifi Master Extensions und versuche sie ans Laufen zu bekommen. Eins hab ich neu von Tinkerforge (Anfang des Jahres), das andere gebraucht erstanden; mit beiden bekomme ich keine stabile Verbindung zu meinem WLAN-AP hin (FritzBox). Ich habe zum Vergleich eine neue Version 2.0 (ohne externe Antenne), die geht wunderbar; also denke ich nicht, dass es an den anderen Komponenten geht. Übersehe ich etwas Wesentliches? Das hier sind meine Einstellungen - das Passwort ist sicher korrekt. Ab und zu erreiche ich den hier dargestellten Zustand "Associated", starte ich den Stapel neu, gibt es aber keine Verbindung mehr. Auffällig ist auch, dass die "Signal Strength" wenn den mal eine Verbindung zustande kommt bei gleicher Entfernung/Position zum Router mit der alten 1.0 Extension viel schlechter ist (-82dB) als mit der neuen (-60 db, unten zum Vergleich): Alt: Neu: Beide Wifi Extensions 1.0 verhalten sich hier gleich (katastrophal schlecht / unbrauchbar); die 2.0 funktioniert hingegen perfekt. Beide 1.0 haben eine kurze Stummelantenne montiert; bei der einen ist es sicher die, die ich bei Tinkerforge mitbestellt hatte; die andere sieht äußerlich gleich aus, steht aber nichts drauf; ich hab keine weiteren Antennen zur Hand, um zu testen, ob es eventuell daran liegt, das falschegibt Antennen dabei waren.. Meine wichtigste Frage: Gibt es bekannte Probleme damit? Ist die Verbindungsqualität bei anderen besser? Oder sind "zufällig" meine beiden Extensions defekt? Diesen Blogeintrag kenne ich: https://www.tinkerforge.com/en/blog/2016/6/30/wifi-extension-2-0-available/

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.

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.

Ok, vielen Dank - dann warte ich darauf.

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..

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..

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