duaw

Hallo!

Ich habe einen Bestand an Bricks und Bricklets, die ich per MQTT in HA einbinde. Mit denen ich mit Node-Red meine Sachen mache. Das geht gut und ist einfach. Warum soll ich Neues kaufen, wenn das Alte bestens funktioniert?  Ja, dann muss auch mal etwas Ersatz her (den es ja noch gibt).

Ich mag bei TF das Konzept, die Qualität von HW und SW, den Support. 

Die rasante Entwicklung rund um ESP hat die Ursprungsidee von TF überrollt. Neu starten würde ich im Anwendungsfall HA heute mit ESP, ESPHome.

Cheers, Uwe  

Compiler complains: Don't know anything about iao. The thing is right. Always. All the functions are declared properly (and defined elsewhere, so the Linker won't complain) but the variable iao is not declared , that is unknown in the scope of where the call sits. It should be declared somewhere so the compiler gets happy und defined exactly once when linking that stuff. 

Cheers, Uwe 

Ich ziehe MQTT vor. Das ist eine saubere Sache, die Bindings von TF funktionieren  und das kommt der Idee von Node-RED mMn am nächsten. Die "Tinkerforge"-Nodes scheinen länger nicht angefasst worden zu sein.

Cheers, Uwe  

Ich habe mehrere Dateien z.B. mit dem Namen Tinkerforge_mqtt_111.service (111 Ende der lokalen IP vom Stapel) , darin den Service definiert 

und mit Standard-Bord-Mitteln von Linux (die ich immer neu googeln muss) als Service eingerichtet. 

[Unit]
Description=Tinkerforge MQTT Bindings on master brick 192.168.1.111

After=brickd.service
After=mosquitto.service

[Service]
ExecStart=/usr/bin/tinkerforge_mqtt  --broker-host 192.168.1.18 --ipcon-host 192.168.1.111 --global-topic-prefix tinkerforge/111

[Install]
WantedBy=multi-user.target

Das mit 112, 113, 114. Läuft. 

Cheers, Uwe 

Hallo!

Ich habe mehrere Instanzen des service unter Linux am laufen. tinkerforge_mqtt_1 , tinkerforge_mqtt_2 , … Jede Instanz bedient einen host. 

Cheers, Uwe 

Hallo!

"Could not resolve ftp.debian.org"

Kannst Du ftp.debian.org anpingen? Bei mir:

% ping ftp.debian.org
PING debian.map.fastlydns.net (146.75.118.132): 56 data bytes
64 bytes from 146.75.118.132: icmp_seq=0 ttl=59 time=12.158 ms

Cheers, Uwe

Moin!

Die grundlegende Idee des Callback ist es üblicherweise, schnell fertig zu sein. Der Callback ist eine von dir bereit gestellte Funktion, die von TF mit z.B. einem neuen Mess-Wert aufgerufen wird. In der Funktion legst Du den Wert, vielleicht mit anderer Verwaltungsinformation, zügig ab. Fertig. Danach geht es schnell in der aufrufenden (TF-) Software weiter.

Deine eigene Software läuft losgelöst davon unter einer eigenen Ablaufsteuerung. Da kannst Du sammeln und an die Queue weiter geben etc. 

Richtig blöd wäre es ja, wenn während der Ausführung der Callback-Funktion diese erneut aufgerufen würde, oder aufgerufen werden müsste (aber nicht würde) oder ... oder ...  

Also: "The name of the game is speed!" im Callback. 

Cheers, Uwe 

Hallo!

Ich möchte ab und an eine weitere Instanz des Brickv starten. Eine erste Suche im Forum hat nicht erbracht, dass diese Frage schon mal gestellt wurde. Es geht:

open -n /Applications/Brickv.app

startet eine weitere Instanz. 

Cheers, Uwe 

vor 3 Stunden schrieb bendebru:

und zwei Callbacks parallel laufen zu lassen auch nicht...

Warum sollte das keine gute Idee sein? 

👍 Sehr schön! Ich warte noch etwas, bis etwas mehr Doku da und weniger Experimentieren notwendig ist. 

Warnung
Der RED Brick ist leider abgekündigt. Mehrere ICs die auf dem RED Brick verwendet werden sind aktuell nicht mehr verfügbar oder haben extrem lange Lieferzeiten. Daher können wir keine neuen RED Bricks mehr fertigen.
Als möglichen Ersatz empfehlen wir ein Raspberry Pi (Zero) zusammen mit dem HAT (Zero) Brick

Leider ... Oder gibt es in einer Schublade noch welche?

Merry Christmas, Guys, a happy and successful New Year 2022!

Stay healthy, stay busy, stay successful!

Looking forward to tinkering with your stuff in 2022! 

Ich weiß, es gibt schon länger, gerade und noch weiter viel zu tun.

Aber: Stillstand ist Tod. Gibt es eine Perspektive, wie der Baukasten für professionelle Bastler hier aufgefrischt werden kann?

Funktioniert.

Hallo!

Bei meinem Mac mini M1 erscheinen keine seriellen Ports zur Wahl zum Flashen eines Masters (2.1) im BrickV (letzte und vorletzte Version). Passiert auch beim RED. Anschluss direkt am USB-A Port des Mini. 

(Sonst funktioniert alles.)

macOS 11.6 auf Intel Mac läuft (Gott Sei Dank!)

Gruß, Uwe 

Hallo!

Ich habe mehrere Instanzen von tinkerforge_mqtt  laufen (linux).

Ich habe dazu verschiedene Service-Dateien angelegt (tinkerforge_mqtt_111.service, tinkerforge_mqtt_112.service ... ) Die Dateien sind gleich, der Name ist unterschiedlich. Das sind Linux-Services.

Ich gebe jeder Instanz das Spezifische beim Start mit: 

   ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.111 --global-topic-prefix tinkerforge/111

So kann ich beim Broker nett unterscheiden, woher was kommt. 

Ich denke, das geht so oder so ähnlich auch in anderen Betriebssystemen. 

War das das Problem? 

Gruß, Uwe

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