rtrbt

Du kannst das einfach dranstecken, der Brick Daemon auf dem Raspberry Pi findet sowohl HAT und daran angeschlossene Bricklets, als auch Bricks, die per USB angeschlossen sind. Du kannst dann mit einer IP-Connection beides steuern, so als ob alles am HAT oder per USB angeschlossen wäre.

Beta 6 ist jetzt im Post oben.

@maxico: Das mit dem Averaging war ein Copy-Paste-Fehler, das Analog In 2 hat einen Moving Average, Version 1 einen "normalen" Durchschnitt. Das hatte ich irgendwie übersehen. Du kannst die Channel selbst in der PaperUI auch konfigurieren, die meisten (wie auch das Analog In) haben ein Update Interval. Mit dem Bugfix gestern habe ich das Speichern der Channelkonfiguration aber zerlegt, heute Nachmittag kommt dann Beta 6, die das wieder repariert, sorry dafür. @StefanOHAN: Actions kann der Generator noch nicht, d.h. die GUI kannst du mit den Bindings noch nicht benutzen. Das steht noch auf meiner TODO-Liste. Die Fragen nerven nicht, im Gegenteil, das Feedback ist immer hilfreich. Ich teste immer mit der PaperUI, das geht schneller. Du kannst aber auch Rule-Dateien verwenden, die Items würde ich aber über die UI anlegen, das spart Tipp-Arbeit.

Ja. Beta fünf ist im Post oben.

Ja, das ist kein Problem.

@Jerome: Wenn du ein Motion Detector 1.0 hast, gibt es zwei Trigger-Channel: Motion Detected löst aus, wenn eine Bewegung bemerkt wurde, Detection Cycle Ended, wenn ein Bewegungserkennungszyklus beendet ist. Der Motion Detector 2.0 hat zusätzlich noch Channel für die LEDs, da kannst du jeweils Zahlen von 0 (aus) bis 255 (volle Helligkeit) reingeben und die Empfindlichkeit ist konfigurierbar. @StefanOHAN: Hm die Firmwareversion scheint man (laut diesem Thread) nicht in einer Rule auslesen zu können. Aber wie du schon sagst, ist das eher was für die Nice-to-have-Liste. Doku findest du in der Zip im Ordner Docs. Das sind die Beschreibungen usw. für Channel und Parameter, die zeigt die PaperUI selsamerweise nicht an, deshalb erstmal so. Measured Level und Edge Counter sind die Channel, die die IO-16 dir gibt, wenn ein Pin auf Input konfiguriert ist. Measured Level ist einfach der aktuelle Wert (0 oder 1), Edge Counter kannst du als Flankenzähler benutzen. Wenn du einen Pin als Output konfigurierst (lies diesbezüglich auch den @maxico-Teil), bekommst du stattdessen Set Level- (das ist der Wert (0 oder 1) den du ausgeben möchtest) und Monoflop-Channel. @maxico: Bei der Discovery (genau genommen erst wenn du in der Inbox den Haken anklickst um das Thing hinzuzufügen) setzen die Bindings das jeweilige Gerät auf einen Standardzustand. Bei der IO-16 ist das alle Pins auf Input zu setzen. Unabhängig davon war aber ein Bug in der Pinkonfiguration, der dazu geführt hat, dass man die Pins nicht auf Output konfigurieren kann. Es gibt dann heute noch Beta 5, bei der das funktioniert.

Moin, Ich habe mal wieder den Post editiert, Beta 4 mit vielen neuen unterstützten Bricklets ist veröffentlicht. @andreasOH: Node-RED ist derzeit nicht geplant, aber du kannst die MQTT-Bindings benutzen und dann von Node-RED aus MQTT sprechen. @StefanOHAN: Ich habe mal eingebaut, dass die Geräte ihre installierte Firmware bei der Discovery melden. openHAB zeigt das dann in den Thing-Eigenschaften an.

Hi, I've spent the last months extending our binding generator to be able to generate openHAB bindings. The 23rd beta version can be found here. Installation: The bindings require an openHAB 2.5.0 Milestone/Snapshot installation. To install the bindings, just copy the two JARs into the addons directory of your installation. openHAB will then load the bindings. Afterwards you can add a Brick Daemon over the inbox. Configuration: Attached devices are automagically put into the inbox after adding the Brick Daemon instance. Devices and channels can be configured: Channels typically allow changing the update rate. Some Bricklet's configuration can show/hide channels, for example the IO-4/16's pin configuration will dynamically create input or output channels. Sometimes the PaperUI needs to be refreshed by pressing F5 to show new channels. Only configuration that is stored in a Bricklet's RAM is supported. Persistant configuration has to be set externally (e.g. by using Brick Viewer), because openHAB will often reconfigure devices, for example on startup or when reconnected to a Brick Daemon. Writing persistant configuration would then take too many write-cycles. Further documentation: Can be found here: https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html#api-bindings-openhab Actions in rules: There are actions to be used in rules available for all devices. To use actions of a device in a rule, first the actions have to be loaded with: var devActions = getActions("tinkerforge", "tinkerforge:[devicetype]:[Device UID]") Then they can be used with devActions.[actionname]([parameters]). The following example shows how to show a GUI on an LCD 128x64 Bricklet with the UID "HQ6": rule "startrule" when System started then var lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQ6") lcdActions.brickletLCD128x64ClearDisplay() lcdActions.brickletLCD128x64RemoveAllGUI(); lcdActions.brickletLCD128x64SetGUIButton(0, 0, 0, 60, 20, "button"); lcdActions.brickletLCD128x64SetGUISlider(0, 0, 30, 60, 0, 50); lcdActions.brickletLCD128x64SetGUIGraphConfiguration(0, 1, 62, 0, 60, 52, "X", "Y"); lcdActions.brickletLCD128x64SetGUIGraphData(0, newArrayList(0, 10, 20, 40, 20, 15)); lcdActions.brickletLCD128x64SetGUITabConfiguration(3, false); lcdActions.brickletLCD128x64SetGUITabText(0, "Tab A"); lcdActions.brickletLCD128x64SetGUITabText(1, "Tab B"); end Functions that expect arrays as parameters can also be called with lists, as shown in the call of setGUIGraphData in the example. Results are returned as a Map<String, Object>, that can be used as follows: rule "otherrule" when Item Enx_Button changed to OFF then val lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQ6") pixels = lcdActions.brickletLCD128x64ReadPixels(0, 0, 127, 63).get("pixels") val inverted = pixels.map[p | !p] lcdActions.brickletLCD128x64WritePixels(0, 0, 127, 63, inverted) end This rule is triggered if the Item Enx_Button changes to OFF (i.e. if the corresponding RGB LED Button is released). It will then read the pixels currently shown on the LCD Bricklet, invert them and draw the inverted pixels back on the LCD. Nearly the complete API of devices can be used as actions. Operations that invalidate the state of channels will refresh them automatically. Not supported are operations, that would write EEPROM or Flash Storage, to avoid unneccesary write-cycles. Display Bricklets: Text can be set as follows: [line],[position],[text]. Further ',' after the first two are handled as part of the text. In the text you can use the display's character set directly with \x[two hex digits]. Unicode characters are furthermore mapped to the display character set, as is done in the code examples, see f.e. here: https://www.tinkerforge.com/en/doc/Software/Bricklets/LCD20x4_Bricklet_Java.html#unicode As an example 1,2,Hello, opεnH\xE0B! will print Hallo, opεnHαB! stating at line 1, column 2 on an LCD 20x4. The small epsilon was mapped from Unicode into the LCD character set, 0xE0 (224) is the small alpha. PaperUI truncates whitespace at the start and end of commands. So to clear (parts of) a line, you can not use f.e. 1,2,[spaces]. Instead you can use the empty character like this 1,2,\xFE\xFE\xFE to delete three characters at Line 1, Column 2. Missing features: Channels accept one CommandType only. For example the LED of a RGB LED Button Bricklet can only be set using an HSBType, not the others that openHAB expects support for (e.g. if only the brightness is changed, an PercentType is sent). Known Bugs: Display Bricklets show '-' as text (NULL if clicked), if no text was already set using the UI. PaperUI does not show descriptions of channel(types) and configuration parameter groups. These are listed in the doc subfolder per device. Unknown Bugs: If you find another bug, please attach the openHAB Log. This can be found in the userdata/logs folder of your openHAB installataion. If the bug is reproducable, you can try to increase the log level with log:set TRACE org.openhab.binding.tinkerforge in the karaf console. Maybe this will show more useful information. log:exception-display can help too. If there are errors shown in the PaperUI, they can be investigated using the web developer tools of your browser. Run the network monitor, reload the page and take a look at the responses of requests with status code 500. log:exception-display (in the karaf console) could be useful here too.

Moin, Hier ist Beta 3 mit Support für die LED Strip und GPS Bricklet. @StefanOHAN: Was hast du mit dem Master Brick und openHAB vor? Bin mir da noch unschlüssig was sinnvoll abzubilden ist. Outdoor Weather und NFC stehen noch aus, da sie aber schwieriger umzusetzen sind, wird das noch etwas dauern. Das Outdoor Weather Bricklet werde ich voraussichtlich als eine Bridge abbilden, die gefundenen Sensoren und Stationen als Einzeldevices. Beim NFC muss ich die State-Machine implementieren. HAT Brick nehme ich mir mal für Beta 4 vor. Zu deinen weiteren Fragen: Geplant ist, dass die openHAB-Bindings bezüglich Wartung und Weiterentwicklung genauso behandelt werden wie die für alle unterstützten Programmiersprachen. Ich weiß nicht, ob Theo vor hat, seine Variante der Bindings weiterzuentwickeln. Vorteil der generierten Bindings ist, dass sie offiziell von uns unterstützt werden, also kannst du bei Feature-Wünschen und Bugreports immer ins Forum posten. @xsherlock: I've translated the readme, everything else is english anyway. I will post a thread in the General Discussion in a moment. Edit: done.

Ich meinte die OH2 Bindings. Ich editiere gleich den Post oben auf einen Link zur Beta 2. Die unterstützt die vier Bricklets auf deiner Liste und das Joystick V2. Vom Analog In (1) und Industrial Digital In 4 habe ich hier keins mehr gefunden, die kannst du ja mal testen

Moin, Geplant ist möglichst alle Bricks und Bricklets generieren zu lassen. Ich habe für die Beta nur erstmal die, die Theos Bindings unterstützen genommen, da das ja scheinbar die sind, an denen openHAB-User am wahrscheinlichsten interessiert sind. Die vier auf deiner Liste habe ich beim spontanen Codedurchsuchen in Theos aktuellen Bindings nicht gefunden, ich setze sie mir aber trotzdem mal auf der TODO-Liste nach oben.

Zeit für Eigenwerbung: bei den generierten Bindings hier kannst du diese Dinge kontrollieren. Der Heater vom Humidity 2.0 wird allerdings aktuell als Konfiguration, nicht als Switch-Channel abgebildet, das ist nicht all zu clever, werde ich für die nächste Beta-Version mal ändern.

It seems like the MQTT out node sends either to the wrong topic or to the wrong broker. Can you try again, but with mosquitto_sub -v -t '#' instead of mosquitto_sub -v -t 'tinkerforge/#' This will print everything published to the broker.

Can you post the output of mosquitto_sub -t tinkerforge/# and the debug output from the bindings for both cases? (Changing the color via the terminal and with a MQTT out node) Also, the debug node outputs differ: If you use the terminal, the payload is a string, with the node, it is an object. Maybe you have to convert the JSON object to a string before publishing it?

You have to subscribe to the [...]/response/[...] topic, instead of the [...]/request/[...] topic. So in your case mosquitto_sub -t tinkerforge/response/rgb_led_v2_bricklet/Jng/get_rgb_value If you then run mosquitto_pub -t tinkerforge/request/rgb_led_v2_bricklet/Jng/get_rgb_value -m '' in another shell, you will see the color. For debugging purposes, you can start the bindings with tinkerforge_mqtt --debug The response paths are then printed to standard out. Also you can subscribe to tinkerforge/# to see all traffic.

Moin, Der Generator ist dieser hier. Er erzeugt die API-Bindings für alle unterstützten Programmiersprachen und jetzt auch für openHAB. Den kannst du theoretisch bei dir ausführen, aber zur Zeit ist es noch etwas Handarbeit, die openHAB-Bindings zu kompilieren. Erik

Zur Erklärung dazu: Die Konfigurationen der Bricklets hat jetzt ein openhab-Dictionary, darin werden die Channels und Konfigurationsparameter spezifiziert. Das ist im Moment nicht so generisch wie ich es gerne hätte (damit auch andere Sachen wie der Data-Logger das verwenden können), aber erstmal hinreichend. Der Generator nimmt die Informationen und erzeugt daraus aufgebohrte Java-Bindings, die dann von einem generischen DeviceHandler usw. benutzt werden.

Ist inzwischen hier.

Hm, ich glaube, dass du dir das zu kompliziert machst: Falls die Bindings einen nicht fatalen Fehler finden, schreiben sie ins Log und laufen weiter. Beispiele dafür sind nicht-parsebare Topics oder Timeouts usw.. Falls ein fataler Fehler auftritt, d.h. einer bei dem die Bindings nicht weiterlaufen können, dann ist das entweder ein Problem des Rechners auf dem sie laufen, z.B. RAM voll, Abhängigkeiten nicht installiert, defekte Hardware oder sowas. Dann wird der Fehler ausgegeben, es ist aber immer Nutzerinteraktion nötig, um das Problem zu lösen. Oder es ist ein Bug in den Bindings, dann fixen wir den. Automatische Neustarts führen dann nur dazu, dass Probleme versteckt werden. Die Null-Topics gibt es nur für den Zustand der Bindings, Brickd-Status bekommst du wie bei allen anderen API-Bindings über die Callbacks der IP-Connection und get_connection_state. Der MQTT-Status ist ein interessantes Problem: Wenn der nicht "okay" ist, dann können die Bindings das auch nicht mitteilen. Sie sind aber robust dagegen, dass die Verbindung zum Broker mal wegbricht. Für den Binding-Status habe ich drei Topics gebaut, anstelle von einem mit Payload, weil 1. das restart-Topic vor den anderen existierte, d.h. das rückwärtskompatibel zu ändern ist nicht drin. 2. sind das ja eher Trigger, auf die andere Software reagieren soll. Wenn das einzelne Topics sind, kann man sich dann auf das registrieren, was einen interessiert. (So wie es die Bindings selber mit restart machen um Kollisionen mit anderen Bindings-Instanzen zu erkennen) Du kannst dich natürlich auf tinkerforge/callback/bindings/+ registrieren, dann hast zu ein Verhalten, das sehr ähnlich zu einem Topic mit Payload ist.

Moin, Hier die erste Beta der generierten openHAB-Bindings. @Theo: Das ganze hat, wie angekündigt, etwas länger gedauert. Danke nochmal für den Aufwand, den du dir mit deinen Bindings gemacht hast.

Moin, Ich habe die letzten Monate daran gearbeitet, unseren Binding-Generator so aufzubohren, dass auch openHAB-Bindings generiert werden können. Die 24. Beta findet sich hier. Edit: Beta 24 mit folgenden Änderungen: - Reset-Action für Koprozessor-Bricklets hinzugefügt - Simple Mode für NFC hinzugefügt - Neue API als Actions durchgereicht - I2C-Modus für Barometer Bricklet hinzugefügt - Unterstützung folgender Bricklets hingefügt: Industrial Dual AC Relay Industrial PTC IMU 3.0 - Frame Started Channel von LED Strip Bricklets abschaltbar gemacht - Clear Error LED Channel für Bricklets mit Error LED hinzugefügt - Binärinputs von Switch auf Contact gewechselt - Work-Around für nicht funktionierende Actions nach Neustart eines Addons hinzugefügt - Firmware-Updates repariert - Heartbeat-Mechanismus für mehr als 4 Brick Daemons repariert - Die Bindings kompilieren gegen die Java-Bindings 2.1.26. Das heißt, dass zur Installation die Jar mit den Java-Bindings aus der Zip neben die neue openHAB-Bindings-Jar in das addons-Verzeichnis gelegt werden muss. - Online-Dokumentation (vorerst nur auf Englisch) Hier der Inhalt der README: Installation: Die Bindings benötigen eine openHAB 2.5.0 Installation. Zum Installieren reicht es, die beiden JARs in das addons-Verzeichnis zu kopieren. Nachdem openHAB das Addon geladen hat (das kann einen Moment dauern), kann über die Inbox ein Brick Daemon hinzugefügt werden. Konfiguration: Nachdem der Brick Daemon hinzugefügt wurde, werden angeschlossene Geräte automagisch in die Inbox gelegt. Sowohl Geräte als auch Channels können Konfiguration haben: Channels typischerweise die Aktualisierungsrate (Default: 1s). Die Brickletkonfiguration kann Channels anzeigen/verstecken, z.b. erzeugt die Pinkonfiguration der IO-4/16 Input/Output-Channels je nachdem, ob ein Pin auf Input oder Output konfiguriert wurde. Die PaperUI braucht manchmal eine Aktualisierung per F5, damit neue Channels angezeigt werden. Es kann nur Konfiguration gesetzt werden, die im RAM des Geräte gespeichert wird. Persistente Konfiguration muss extern (z.b. mit dem Brick Viewer) gesetzt werden, da openHAB diese jedes Mal schreiben würde, wenn openHAB startet, oder die Verbindung zum Brick Daemon wiederhergestellt wurde usw. Das kostet zu viele Flash-Schreibzyklen. Weitere Dokumentation: Findet sich hier: https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html#api-bindings-openhab (vorerst nur auf Englisch) Actions in Rules: Es werden für alle unterstützten Geräte Actions zur Verwendung in Rules zur Verfügung gestellt. Um in einer Rule auf die Actions eines Gerätes zuzugreifen, müssen diese zunächst mit var devActions = getActions("tinkerforge", "tinkerforge:[Gerätetyp]:[Device UID]") geladen werden. Danach können sie mit devActions.[actionname]([parameter]) verwendet werden. Zum Beispiel zeigt die folgende Rule auf einem LCD 128x64 Bricklet mit der UID "HQ6" eine graphische Oberfläche an: rule "startrule" when System started then var lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQ6") lcdActions.brickletLCD128x64ClearDisplay() lcdActions.brickletLCD128x64RemoveAllGUI(); lcdActions.brickletLCD128x64SetGUIButton(0, 0, 0, 60, 20, "button"); lcdActions.brickletLCD128x64SetGUISlider(0, 0, 30, 60, 0, 50); lcdActions.brickletLCD128x64SetGUIGraphConfiguration(0, 1, 62, 0, 60, 52, "X", "Y"); lcdActions.brickletLCD128x64SetGUIGraphData(0, newArrayList(0, 10, 20, 40, 20, 15)); lcdActions.brickletLCD128x64SetGUITabConfiguration(3, false); lcdActions.brickletLCD128x64SetGUITabText(0, "Tab A"); lcdActions.brickletLCD128x64SetGUITabText(1, "Tab B"); end Funktionen, die Arrays erwarten, können in openHAB-Regeln auch mit Listen verwendet werden, wie dies im Beispiel von setGUIGraphData gezeigt wurde. Rückgabewerte werden als eine Map<String, Object> zurückgeben, diese kann wie folgt verwendet werden: rule "otherrule" when Item Enx_Button changed to OFF then val lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQ6") pixels = lcdActions.brickletLCD128x64ReadPixels(0, 0, 127, 63).get("pixels") val inverted = pixels.map[p | !p] lcdActions.brickletLCD128x64WritePixels(0, 0, 127, 63, inverted) end Die Rule wird ausgelöst, wenn das Item Enx_Button auf OFF geändert wird (d.h. wenn der zugehörige RGB LED Button losgelassen wird). Sie liest gesamten Pixel des LCD Bricklets aus, invertiert diese und zeichnet die invertierten Pixel wieder auf das LCD. Über Actions kann fast die gesamte API der Geräte genutzt werden. Actions die den Zustand von Channels ändern, aktualisieren diese automatisch. Nicht unterstützt werden Operationen, die EEPROM- oder Flash-Speicher der Geräte schreiben würden. Auch hier sollen unnötige Schreibzyklen vermieden werden. Display-Bricklets: Text wird auf folgende Weise gesetzt: [line],[position],[text]. Weitere ',' nach den ersten beiden werden als Teil des Textes behandelt. Der Text kann mit \x[zwei Hex-Ziffern] das Character-Set des Displays verwenden. Zusätzlich werden Unicode-Zeichen so gut es geht auf das Display-Character-Set abgebildet, wie das auch in den Code-Beispielen passiert, siehe z.B. hier: https://www.tinkerforge.com/de/doc/Software/Bricklets/LCD20x4_Bricklet_Java.html#unicode Beispielsweise gibt 1,2,Hallo, opεnH\xE0B! auf einem LCD 20x4 in Zeile 1, Spalte 2 aus: Hallo, opεnHαB! Das kleine Epsilon wurde von Unicode in das LCD-Character-Set übersetzt, 0xE0 (224) entspricht dem kleinen Alpha. Die PaperUI scheint Leerzeichen am Rand des Commands abzuschneiden. Um (Teile) einer Zeile zu löschen kann also nicht ein Befehl wie 1,2,[Leerzeichen] verwendet werden. Stattdessen kann 1,2,\xFE\xFE\xFE benutzt werden um in Zeile 1, Spalte 2 drei Zeichen zu löschen. Fehlende Features: Channels akzeptieren nur einen CommandTypen, d.h. z.B. LED des RGB LED Button Bricklets nimmt nur HSBType an, nicht die anderen, die von openHAB erwartet werden (wie PercentType wenn die Brightness geändert wird) Bekannte Bugs: Display Bricklets zeigen auf der Übersichtsseite, solange noch kein Text gesendet wurde, '-' als Text an, wenn darauf geklickt wird NULL. PaperUI zeigt die Description von Channel(Typen) und Konfigurationsparameter-Gruppen nicht an. Unbekannte Bugs: Falls ein anderer Bug auftritt, bitte das openHAB-Log mit anhängen. Das Log findet sich im userdata/logs-Verzeichnis der openHAB-Installation. Falls der Bug reproduzierbar ist, kann mit log:set TRACE org.openhab.binding.tinkerforge (in der Karaf-Konsole) das LogLevel erhöht werden, dann erscheinen eventuell weitere hilfreiche Informationen im Log. Außerdem hilfreich ist log:exception-display. Falls Fehler in der PaperUI angezeigt werden, können diese mit der Netzwerkanalyse der Web-Entwickler-Tools untersucht werden. Dann mit laufender Analyse die Seite neuladen und die Antworten von Anfragen mit Statuscode 500 ansehen. Eventuell hilft hier auch log:exception-display.

Brauchst du die externe Restartlogik für die Bindings oder dein Programm, dass mit dem Bindings MQTT spricht? Den KeyboardInterrupt kannst du mit Strg-C auslösen, oder indem du SIGINT schickst. Ich habe gerade mal noch eingebaut, dass SIGTERM und SIGQUIT auch funktionieren. Edit: Durch das sinnvollere Signal-Handling kann man die Bindungs auch als systemd-Service verwenden, ein Beispiel-Service-File habe ich mal angehangen. tinkerforge_mqtt_bindings_2_0_8_beta2.zip tinkerforge_mqtt.service

Moin, Ich habe für die nächste Version der MQTT-Bindings mal einiges gefixt: Das stimmt. Das Problem war, dass zuerst die IP-Connection aufgebaut wurde, danach die Verbindung zum Broker. Das passiert jetzt andersrum. Das Init-File unterstützt jetzt eine zweigeteilte Syntax in dieser Form: { "pre_connect": { "tinkerforge/register/ip_connection/connected": {"register": true}, "tinkerforge/register/ip_connection/enumerate": {"register": true} }, "post_connect": { "tinkerforge/request/ip_connection/enumerate": "" } } Mit diesem Beispiel-Init-File werden vor dem Verbinden der IP-Connection die Callbacks registriert und direkt nach dem Connect wird ein Enumerate ausgelöst. Der Disconnected-Callback meldet den Verlust der TCP-Connection zum Brick Daemon. Wenn du das Netzwerkkabel rausziehst, wird die aber nicht geschlossen. Wenn du den Brick Daemon beendest, sollte der Callback auslösen. Detektieren, ob die Netzwerkverbindung an sich unterbrochen ist, können aktuell keine Bindings. Langfristig ist dafür aber eine Lösung geplant. Das kannst du aktuell auch haben, indem du tinkerforge/# subscribst und nachsiehst ob "_ERROR" im Payload ist. Eigentlich sollte es nicht nötig sein, die Bindings neuzustarten. Hast du das Verhalten bei Verbindungsproblemen mit den aktuellen Bindings getestet? Ich hatte für Version 2.0.7 einiges am Verhalten geändert, damit es saubere Reconnects zum Broker und Brick Daemon gibt. Falls du mit der angehangenen Version in der Richtung noch Probleme hast, gib nochmal Bescheid. Die Bindings schicken wie gehabt "null" nach tinkerforge/callback/bindings/restart und mit der neuen Version auch nach tinkerforge/callback/bindings/shutdown, wenn sie normal beendet werden oder nach tinkerforge/callback/bindings/last_will, falls sie abgeschossen wurden oder die Verbindung weg ist. Ich habe die aktuelle Version mal angehangen. tinkerforge_mqtt_bindings_2_0_8_beta.zip

Für die Updatesuche und Firmwaredownloads ist das immer https://download.tinkerforge.com

Ist aktuell nicht geplant, sorry.