Jump to content

'Neue Technologie' IoT: Node-RED (von IBM) integration der Tinkerforge Elemente


Recommended Posts

Der Bereich IoT ist ja komplett am explodieren (Mit all den zugehörigen Kollateralschäden)...

IBM hat mit Node-RED einen erfreulich einfachen Einstieg in diese Welt erschaffen. (Ich arbeite nicht dort!)

http://nodered.org/

 

Bin ich komplett auf dem Holzweg wenn ich frage, ob Tinkerforge ein 'API' für Node-Red schreiben würde?

 

 

 

D.h. sämtliche Brick(let)s würden als Nodes in Node-RED zur Verfügung gestellt?!

 

Wenn dann Node-RED statt auf dem Raspi sogar noch auf RED-Brick laufen würde, könnte Tinkerforge die bereits erfreulich grosse Palette an Möglichkeiten für die Entwickler nochmals um eine Stufe 'abstrahieren'.

 

Oder nicht?

Link to post
Share on other sites

Ähm, vielleicht schreibst du das nächste Mal dazu gleich als Warnung dazu, dass Node-RED erstmal nix mit dem Brick-RED zutun hat. Also ich fang immer an bei solchen pauschalen Eingebungen von Neu-Technologien - erstrecht wenn es Namensvettern sind - geistig zu rotieren :o:P.

 

Aber warum passt IBM selbst nicht ihre API an, um TF Teile zu unterstützen ? 8)

Link to post
Share on other sites

Selbstverständlich könnte die Implementierung auch von 'ausserhalb' geschehen... so wie Nic das vorschlägt (vielleicht aber sollten wir in diesem Fall nicht zu toll auf IBM hoffen  :-)  ).

 

-Falls wir also hier mit so einer Integration anfangen sollten, wollte ich bloss et-welche 'Doppelspurigkeit' vermeiden!

 

Link to post
Share on other sites
  • 6 years later...

Ich sehe, dass der letzte Eintrag zu Node-RED schon eine Weile her ist. Gibt es denn hier schon User, die Tinkerforge/Node-RED auf einem Rasbi erfolgreich nutzen? Eure Erfahrungen dazu würden mich interessieren ;-)

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

Hallo Uwe,

aktuell nutze ich die Nodes nicht. Bin aber am überlegen. 

Möchte meine tinkerforge eigentlich direkt in iobroker einbinden. 

Da gibt es meines Wissens auch nur den Weg über MQTT oder aber über Node-Red....

Bin aber mit meinem Smarthome noch ziemlich am Anfang. Eventuell kann ich später mehr erzählen.

Zum Thema dritte Seite. Der Sourcecode steht auf Github, jeder kann den forken und selber aktualisieren und auch natürlich weiterentwickeln. Es schaut so aus als hätte der Entwickler nur seine Module umgesetzt und etwas bugfixing betrieben.

Ich finde es immerhin gut, dass der Entwickler es überhaupt mit der Community geteilt hat. 

 

Gruss

Wolfgang

 

 

 

Link to post
Share on other sites
vor 6 Stunden schrieb duaw:

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 ;-) )


auch etwas off-topic:
Ich bin um ehrlich zu sein nicht sonderlich vom MQTT Binding begeistert (und würde mich schon über ein Note-Red Binding freuen).
Das MQTT Binding ist hat leider nicht selbständig, es setzt immer ein Server voraus auf dem das Binding läuft.
Läuft Node-Red in der Cloud, auf einem Server wo man keine Rechte hat etwas Nachzuinstallieren oder in einem anderen Netzwerk hat man ein Problem. 

Zudem kenne ich das von vielen IOT Geräten so, das sie sich Aktiv beim Server melden. Das ist halt hier nicht so, sind die Tinkerforge Bausteine mal länger aus, muss man erstmal das MQTT Binding neu starten damit die Verbindung wieder aufgebaut wird. 

Ich hoffe das wird sich mit dem ESP32 Brick ändert, dort soll man ja auch eine Art MQTT Proxy laufen lassen können, so das sich die Tinkerforge Bausteine dann Aktiv beim MQTT Sever melden und man nicht mehr das MQTT Binding braucht. Ich hoffe zu mindestens das sich das so verstanden habe 😀

 

 

Link to post
Share on other sites

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

Link to post
Share on other sites
  • 3 weeks later...
On 3/27/2021 at 10:14 AM, duaw said:

Was der ESP32-Brick grundsätzlich anders machen soll als der Red-Brick überblicke ich nicht. 

Grundlegend ist der Vorteil des ESP32-Bricks, dass du kein Linux darauf hast, sondern direkt mit der Hardware reden kannst, z.B im Arduino-Stil.

On 3/26/2021 at 2:28 PM, luxor said:

Ich hoffe das wird sich mit dem ESP32 Brick ändert, dort soll man ja auch eine Art MQTT Proxy laufen lassen können, so das sich die Tinkerforge Bausteine dann Aktiv beim MQTT Sever melden und man nicht mehr das MQTT Binding braucht. Ich hoffe zu mindestens das sich das so verstanden habe

Da verwechselst du Dinge. Der ESP32 Brick hat einen Proxy-Modus, was aber nicht über MQTT läuft, sondern das normale Tinkerforge-Protokoll. D.h. du kannst ihn genau wie alle anderen Bricks verwenden und z.b. dich mit dem Brick Viewer darauf verbinden. Deshalb funktionieren dann auch die MQTT-Bindings damit. Aktiv macht der Brick aber nichts über MQTT, es sei denn man schreibt eine entsprechende Firmware.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...