duaw

Also, eine "Instanz" von ipcon.c , die beim Linken mit gebunden wird, ermöglicht in einem Programm dann einen einzelnen Listener. Da funkt der Brickv natürlich dazwischen. (Wann er das tut, weiß ich nicht. Beim Connect? Bei Klicken auf den Tab? ...) Blind, blind, blind ... Habe blind auf "Callbacks" geklickt und das Kapitel "Konfigurationsfunktionen für Callbacks" oberhalb übersehen ... Dass ich das auch in der Header-Datei übersehen habe ... tsss ... Werde zukünftig NICHT mehr an euch zweifeln.

Ich lese in der Doku: Java: "Dieser [BrickletLEDStripV2.FrameStartedListener()] Listener kann mit der Funktion addFrameStartedListener() hinzugefügt werden." (Ein 'n' fehlt.) C: "Die Registrierung kann mit der led_strip_v2_register_callback() Funktion durchgeführt werden:" Beobachtung: Man kann zu einem Zeitpunkt nur nur einen Listener haben. Wenn unterschiedliche Programm auf das Bricklet zugreifen (z.B. ein parallel geöffneter Brick Viewer), dann ist das Ergebnis erratisch ... Ich lese in der Doku: Java: "Ein hinzugefügter Listener kann mit der Funktion removeFrameStartedListener() wieder entfernt werden." C: Ich vermisse in der Doku int led_strip_v2_set_frame_started_callback_configuration(LEDStripV2 *led_strip_v2, bool enable) Diese Funktion (und int led_strip_v2_get_frame_started_callback_configuration(LEDStripV2 *led_strip_v2, bool *ret_enable)) ist ja definiert. Gruß, Uwe

Geht! 👍 (Ausprobiert auf dem neuen Mac mini, auf dem das Symptom aufgetreten ist. Noch nicht gecheckt, ob es auf dem MacBook Pro -alt- auch noch geht. 😏)

Hmm ... wieso geht es dann bei mir von einem Mac aus, aber nicht vom anderen? Wie gesagt: Kein drängendes Problem. Der Urlaub ist definitiv verdient! Gruß, Uwe

Hallo! Nach dem (eigentlich reibungslosen) Umzug auf einen neuen Mac mini mit M1 sehe ich im Brick Viewer am unteren Fensterrand die Message "Update information could not be downloaded from tinkerforge.com. Is your computer connected to the Internet?" Ist er natürlich. Ich habe auch sonst absolut keine Probleme, auch Brickd und der Rest vom Brickv laufen einwandfrei. Ist nur unschön, aber nicht überlebenswichtig. Gruß, Uwe

Hallo, Thomas, ich verwende NodeRED. Die ankommende Nachricht übersetzte ich und veröffentliche sie so, wie ich das brauche, einfach nochmal. Die (Prozessor-) Last ist dabei nicht sehr hoch. Das erschien mir der einfachste Weg, insbesondere bei neuen Versionen des Bindings. Gruß, Uwe

Hallo, luxor, klar, das Bindung läuft irgendwo. Bei mir läuft für jeden Stapel mit eigener IP-Nummer eine Instanz davon bei mir im Netz auf einer HW, da wird das Topic mit gesetzt. Das Bindung läuft bei mir also "nah" an der TF HW, im selben Netzwerk. Der MQTT-Broker kann dann laufen, wo er will, Hauptsache er ist erreichbar (bei mir im lokalen Netz). Und NodeRED kann auch laufen, wo es will -- Hauptsache, der Weg zum Broker ist frei. (NodeRED in der Cloud ist für mich keine Option. Ich will grundsätzlich, dass alles auch ohne Cloud funktioniert.) Ich habe das TF-MQTT-Binding noch nie neu gestartet. Das liegt aber vielleicht auch daran, dass ich polle. NodeRED weiß, welche HW ich habe, dort wird der Request per MQTT abgegeben, das Bindung hat kriegt das dann mit. Was der ESP32-Brick grundsätzlich anders machen soll als der Red-Brick überblicke ich nicht. Gruß, Uwe

Für mich zum Verstehen: Nutzt du die Nodes? (Ich habe sie noch nicht ausprobiert.) Welchen wirklichen Benefit siehst Du grundsätzlich im Vergleich zu MQTT? MQTT ist immer top-aktuell. Zur Verwendung braucht es natürlich ein laufendes MQTT-Binding ... aber das läuft ja einfach. Alles, was von dritter Seite zur Unterstützung von TF kommt, hängt immer hinterher. (Etwas, das ich bei NodeRED als suboptimal empfinde ist die Unübersichtlichkeit über third-party-Nodes. Welche gibt es, wie sind die dokumentiert und gepflegt?) Gruß, Uwe

Hallo, ewu68! Bei mir läuft das Trio NodeRED, MQTT und Tinkerforge super erfolgreich und komfortabel. Auf einem Raspi in der isolierten Gartenhütte steuert/regelt es Licht und Temperatur gegen den Pflanzentot im Winter, ein Server, der eh läuft, erledigt allerhand nebenher. Da ist dank MQTT auch anderes (z.B. Shelly) dabei und es gibt ja allerhand NodRED-Nodes für Dinge, die nicht MQTT sprechen (mir gefällt immer noch mein LaMetric-Display). Also ich bin sehr zufrieden. Ich brauche keine Tinkerforge-NodeRED-Nodes. Läuft. Ist performant, stabil, erweiterbar, wartbar (man muss aber wie bei allen grafischen "Sprachen" aufpassen und sich selbst disziplinieren. Was mir nicht immer gelingt ... ) Etwas off-topic: Ich kann – ganz ehrlich – auch nicht den Bedarf am TF-openHAB-Binding nachvollziehen. Ja, Komfort bei der Einrichtung. Noch etwas? Aber um welchen Preis? Warum nicht einfach per MQTT an openHAB andocken? (Ich habe mich aber von openHAB getrennt. NodeRED und ich sind jetzt ein Paar ;-) ) Gruß, Uwe

Schön (heraus-) zu lesen, dass das Geschäft mit den Wallboxen dermaßen brummt ... Die Kehrseite der Medaille ist dann leider ... Bleibt spannend! Gruß, Uwe

Ja, Batti, das klingt gut. Ich gehe gerne zu Fuß! Ich habe in der Nähe vom Einsatzort im Keller schon einen Stapel zum Überwachen/Steuern der Zu-/Abluft, am Stack ist noch ein Steckplatz frei. Mit nem langen Bricklet-Kabel könnte das was werden. Dann einklinken in MQTT und NodeRED, fertig ist es! @DoIT: Das Wasser kam von außen rein über die Zu-/Abluft. Die Entwässerung derselben (im Sommer gibt es da Kondenswasser, jetzt war alles so draußen gesättigt, dass das Regenwasser im Boden seinen Weg da in die Zuluft hinein fand) in das Abwasser hatte ein – wirklich zweckfreies – Sieb, das sich zugesetzt hatte. Abschalten muss ich da nix. Wäre grundsätzlich natürlich bei Waschmaschinen etc. sinnvoll. Hmm, ich kenne niemanden, dem die ausgelaufen ist. Gruß, Uwe

Hallo, zusammen, nachdem es viel Wasser von oben und eine Verstopfung im Abfluss nach unten gab, stand das Wasser im Keller. Blöd. (Freundlicherweise war es klares Wasser, dass seinen Weg gefunden hatte, keine braune Brühe ... ) Wie würde man einen Wasserstandswarner mit TF realisieren? Mit welchem Bricklet (und ggf. Zusatz-HW) könnte man auf welche Art & Weise stehendes Wasser >1mm auf dem Boden feststellen und so die Basis für eine Wasserwarnung realisieren? Gruß, Uwe

Hallo! Wie verarbeitest Du die Nachrichten denn? Auch in C, Java, ... könntest Du doch flexibel die Position der Größe suchen, die dich interessiert. Ich nehme NodeRED / Javascript. Da spielt die konkrete Reihenfolge eine absolut untergeordnete Rolle. MQTT und Reaktion auf eingehende Nachrichten ist ... einfach Klasse! Gruß, Uwe

Hallo! Ich werde openHAB den Rücken kehren und auf NodeRed umsteigen. Ich habe mal mit OH1 angefangen, die Lösung dann mit OH2 betrieben. OH2 und OH3 gefällt mir einfach nicht mehr. NodeRed passt bei mir persönlich besser. Und meine Bedürfnisse bzgl. TF werden bestens mit den MQTT-Bindings erfüllt. Da muss ich nichts neues kaufen ... Gruß, Uwe

Hallo! besteht grundsätzlich auch die Möglichkeit, dass der Brickv anzeigt, mit welcher Version des Brickd er gerade verbunden ist? Und dass ein Update für den verbundenen Brickd bereit liegt? (Kommt zwar sehr selten vor, erleichtert dann aber das systematische Updaten!) Gruß, Uwe

Alles befolgt unter https://www.tinkerforge.com/de/doc/Software/APT_Repository.html#apt-repository ? brickd läuft ? systemctl status brickd liefert bei mir ● brickd.service - Brick Daemon Loaded: loaded (/lib/systemd/system/brickd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2020-08-10 08:27:30 CEST; 7h ago Process: 460 ExecStart=/usr/bin/brickd --daemon (code=exited, status=0/SUCCESS) Main PID: 471 (brickd) Tasks: 7 (limit: 2068) CGroup: /system.slice/brickd.service └─471 /usr/bin/brickd --daemon Ach ja: Raspi aktuell ? sudo apt update // sudo apt upgrade durchgeführt? Gruß, Uwe ... jetzt weg.

Hallo, Philipp, leider habe ich das outdoor_weather_bricklet nicht. Um auszuschließen, dass das ein Bug im Bindung (in getstation_data) ist, sollte get_identity funktionieren. Das können ja alle Bricklets. Hier mein Setup: Mac (mit brickd und Brickv) und Raspi mit IP 192.168.1.200.Natürlich kann ich den Raspi vom Mac aus im Netz erreichen. Unter MQTT.fx auf dem Mac habe ich ein Connection Profile zum Broker 192.168.1.200 erstellt. Ich habe testweise ein humidity_v2_bricklet mit UID Dkd am Raspi am HAT Zero und einen Master mit temperature_bricklet mit UID zkv am USB des Raspi. Auf dem Raspi läuft der MQTT-Broker (Test: vom Mac aus kann ich mich mit MQTT.fx mit diesem verbinden, ich subscribe "#" und publishe "Blabla", dann wird "Blabla" am Mac wieder empfangen) der brickd (Test: vom Mac aus kann ich mich mit dem BrickV mit 192.168.1.200:4223 verbinden. Ich sehe am Mac das HAT Zero und den Master mit allen Bricklets) der tinkerforge_mqtt-Service (installiert mit sudo apt install tinkerforge-mqtt) Mein Test des Service, Schritt für Schritt: Start MQTT.fx auf dem Mac Connect vom Mac mit Broker auf Raspi (192.168.1.200) . Ich ordne Subscribe/Publish von MQTT.fx an, damit ich schöne beides im Blick habe. subscribe # (alles) publishe vom Mac tinkerforge/request/humidity_v2_bricklet/Dkd/get_identity erhalte die Antwort {"connected_uid": "QeK", "uid": "Dkd", "device_identifier": "humidity_v2_bricklet", "hardware_version": [1, 0, 0], "position": "b", "firmware_version": [2, 0, 6], "_display_name": "Humidity Bricklet 2.0"} publishe vom Mac tinkerforge/request/temperature_bricklet/zkv/get_identity erhalte die Antwort {"connected_uid": "62eUJm", "uid": "zkv", "device_identifier": "temperature_bricklet", "hardware_version": [1, 1, 0], "position": "c", "firmware_version": [2, 0, 4], "_display_name": "Temperature Bricklet"} Wenn Du ein anderes Bricklet hast, dann teste das auch mal. Wenn der Fehler bleibt, dann ... 🤨 Gruß, Uwe PS Ich hoffe, dass klappt. Bin erst am Freitag wieder da.

Hallo, Philipp, subscribe doch mal tinkerforge/# in MQTT.fx Was passiert, wenn via MQTT.fx die Nachricht tinkerforge/request/outdoor_weather_bricklet/K5A/get_station_data publishst? Es sollte in MQTT.fx die Response ankommen. Passiert das? Gruß, Uwe

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

Hallo, Philipp, das im Video sieht alles ganz vernünftig aus. Ich bin den Weg mit der Anleitung von TF gegangen. Die ist doch ganz gut! Leider habe ich keine ausführlichere step-by-step-Anleitung ... VOR dem automatischen Ausführen als Service oder über crontab solltest Du manuell checken, ob die Einzelteile funktionieren. Und dabei "unten" anfangen. Wie ist Dein Aufbau? Welche HW verwendest Du? Welches OS? Aktuelle SW? Wo läuft der MQTT-Broker? Läuft der? Kannst Du mit MQTT.fx überhaupt Nachrichten publishen/subscriben ? Wo ist welches Bricklet wie angeschlossen? Siehst Du das im BrickViewer? Hast Du python wie erforderlich ? Wo läuft das Bindung tinkerforge_mqtt? Wie rufst Du das auf (nimm man --debug mit in den Aufruf 😉) Kannst Du das Binding in einer Shell (Konsole) aufrufen? Was funktioniert und was funktioniert nicht? Die Anleitung von TF ist doch ganz gut! Leider habe ich keine ausführlichere step-by-step-Anleitung ... Gruß, Uwe

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

Hallo, Philipp, ich bin wie hier beschrieben vorgegangen: https://www.tinkerforge.com/de/doc/Software/API_Bindings_MQTT.html# Unter Debian Linux (auch Raspi) sudo apt install tinkerforge-mqtt macht alles. Die Doku ist etwas gewöhnungsbedürftig. Am besten, du spielst mit den Kommandozeilentools oder z.B. MQTT.fx etwas rum. Gruß, Uwe

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

Hallo, der Maintainer maintaint wohl nur das, was er selbst hat. Ich verwende das MQTT-Binding. Das läuft gut und ist bestens supported! Gruß, Uwe

Hallo! Der Winter wird kommen und damit die Überwinterung von Pflanzen im (isolierten) Gartenhaus. Dazu möchte ich einen elektrischen Heizlüfter (500W), 2x RGB-Pflanzenlicht (à 50 W) und einen kleinen Bad-Lüfter (wenn es zu feucht/warm wird) schalten (mit MQTT/Node-Red auf Raspi [ist vorhanden] lokal in der Gartehütte). Das Licht ginge wie bisher auch über eine Zeitschaltuhr. Aber der "Frostwächter" ist zu aggressiv: Es darf ruhig unter 5°C kalt werden. Und beim Lüften möchte ich etwas Intelligenz einbauen. Die Außentemperatur kommt via MQTT/Netzwerk von aussen. Die Regelung muss aber lokal und stabil sein, weil die Netzwerkverbindung per Powerline hin und wieder kollabiert. Ich oute mich mal als elektrischer Dilettant: Wie geht das am besten? ("Gut" besitzt leider ganz verschiedene Aspekte: Betriebssicherheit, Kosten, Security, Lebensdauer ...) Mit TF : Sollte ich Funksteckdosen und Remote Switch 2.0 (alles vorhanden) nehmen? Da würde EIN Bricklet ja für alle 3 Funksteckdosen reichen. Ist das wohl zuverlässig? Mit TF: Oder doch Industrial Dual Relay Bricklet? Habe ja auf dem Zero HAT Brick nur 4 Ports (HAT Brick nicht lieferbar!) Oder ohne TF: MQTT und dann LAN oder WLAN-Schalter (z.B. Sonoff) ? Wie zuverlässig ist das? Welche Lösungen verwendet ihr? Gruß, Uwe