Blog

Wir werden oft gefragt wie man eine Build-Umgebung aufsetzt mit der man Brick Firmwares oder Bricklet Plugins modifizieren und kompilieren kann oder wie man die API von Bindings ändern kann.

Ein Skript welches eine Build-Umgebung für das komplette Tinkerforge Ökosystem erstellt ist jetzt verfügbar. Zusätzlich gibt es ein Tutorial welches die Benutzung der Build-Umgebung erklärt.

Mit der Build-Umgebung kannst du:

* Brick Firmwares verändern und kompilieren.
* Bricklet Plugins verändern und kompilieren.
* APIs/Bindings für alle unterstützten Programmiersprachen verändern und generieren.
* Brick Viewer/Daemon verändern und kompilieren.
* Schaltpläne und Layouts der Bricks und Bricklets ansehen und verändern (mit KiCad).
* CAD Gehäusedaten ansehen und verändern (mit FreeCAD).
* Die Dokumentation verändern und bauen.

Überall hört man vom Internet der Dinge (Internet of Things) und M2M (machine to machine) Kommunikation. Eines der größten Hindernisse scheint die Festlegung eines Standards/Protokolls zur Kommunikation der Geräte/Maschinen untereinander zu sein. Unsere Lösung dieses Problems ist es, direkte Bindings für eine Vielzahl von Programmiersprachen anzubieten. So ist eine einfache Benutzung gesichert und die Protokollfrage erübrigt sich. Um zu zeigen wie einfach es ist, Bricks und Brikcklets trotzdem mit M2M-Protokollen anzusprechen haben wir einen Brick MQTT Proxy geschrieben.

Der Brick MQTT Proxy ist ein einfaches Python Skript welches ein Großteil unserer Bricklets unterstützt. Das Skript ist so ausgelegt, dass nicht unterstütze Bricks und Bricklets einfach hinzugefügt werden können. Näheres dazu findet ihr in der Brick MQTT Proxy Dokumentation.

MQTT ist in seiner Ursprungsfassung bereits vor dem Jahr 2000 entwickelt worden und stellt eine Möglichkeit dar, Daten zwischen den unterschiedlichsten Geräten/Maschinen auszutauschen. Wenn man so will ein Internet der Dinge Protokoll das seiner Zeit voraus war. Vereinfacht formuliert nutzt MQTT einen sogenannten Broker, der Daten zwischen Publishern (Geräte die Daten Senden wollen) und Subscribern (Geräten die Daten empfangen wollen) austauscht. Datenursprünge nennt man Topics (als Beispiel Temperatur), die von Publishern angeboten werden und von Subscribern abonniert werden können. Ein Gerät kann gleichzeitig Subscriber and Publisher für verschiedene Topics sein. Wer mehr dazu wissen möchte kann dies zum Beispiel in dem Artikel What is MQTT and how does it work with WebSphere MQ? erfahren.

Wir freuen uns auf euer Feedback und eure Projekte mit dem Proxy!