Wofür sind die Bricklets von Tinkerforge?

[thobastian]

Sorry, für diese provokante Frage. Aber ich bin schon lange auf der Suche nach einer einigermaßen ordnetlichen GUI um Tinkerforge steuern zu können. Openhab ist für mich einfach zu groß und FHEM geht zurzeit nicht. Zumindest hat von der FHEM-Gemeinde keiner ein Interesse. Aber warum Tinkerforge kein Interesse, zumindest FHEM zum Laufen zu bekommen? oder Home Assistant? Beide können mqtt verwenden. Das können doch von Tinkerforge erstmal vorbearbeitet werden. Für mich scheint mqtt ziemlich kompliziert zu sein.  Ich bin echt enttäuscht von Tinkerforge.

[markus5766h]

... und warum sollte Tinkerforge das tun ?

In erster Linie liefert Tinkerforge HARDWARE mit entsprechenden

Bindings für so ziemlich alle gängigen - und auch industriell genutzten - Programmiersprachen.

Punkt.

Irgendwas soll der User ja auch noch selbst tun.

Für fertige Projekte / Projektgruppen gibt es sicherlich auch einen Markt,

allerdings dann in einem ganz anderen Preissegment.

... und FHEM : auf diesem Markt (Home-Automatisation) wird IMHO derzeit so viel

unsinniges Zeugs angeboten - da konstruiere ich mir das lieber selbst.

 

... ist nur meine bescheidene Meinung . . .

[borg]

Ich muss markus5766h da ein Stück weit recht geben. Die primäre Schnittstelle der Bricks und Bricklets sind unsere Bindings für die Programmiersprachen.

 

Die Liste von neuen hippen Home Automation/IoT/Industrie 4.0 Protokollen die wir unterstützen könnten ist endlos. Erschwerend kommt hinzu, dass diese Art von Protokollen alle irgendwelche Meta-Informationen brauchen (wie eine Einordnung einer Funktion in eine bestimme Gruppe o.ä.) welche sich aktuell noch nicht generieren lassen.

 

Langfristig wollen wir unsere Generatoren soweit aufbohren das wir auch Proxies für MQTT, CoAP, OPC UA usw. automatisch generieren können. Der MQTT Proxy den wir aktuell händisch pflegen ist dafür sowas wie in erste Schritt um Erfahrungen in dieser Richtung zu sammeln.