rtrbt

Vielen Dank für deine Erklärung. Ich vermute es ist das selbe für Motion Detector Bricklet 2.0?

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.

nebenbei : warum wird für jeden internen zustand der bindings ein eigener topic mit inhalt "null" genutzt ?

 

es wäre doch EIN topic mit entsprechdem inhalt ev. besser

bzw. EIN topic für (re-)start und je EINER für jeden "internen zustand" einer dezidierten komponente :

z.b. mqtt-status, brickd-status, _ERROR-status ....

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.

bitte nochmals ein review, das die (externe) restartlogik in die überlegungen miteinbezieht

Brauchst du die externe Restartlogik für die Bindings oder dein Programm, dass mit dem Bindings MQTT spricht?

und : wie wird der MQTT-proxy eigentlich von aussen "regulär beendet" ? SIGTERM ? ... er läuft ja idealerweise endlos ... und KeyboardInterrupt von extern triggern - da bin ich kein spezialist ;-)

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:

-> callback/ip_connection/connected wird am anfang aber explizit nie aufgerufen :

Das stimmt. Das Problem war, dass zuerst die IP-Connection aufgebaut wurde, danach die Verbindung zum Broker. Das passiert jetzt andersrum.

stattdessen ist mit dem initialisierungs-file implizit die einzige möglichkeit gegeben, callbacks zu registrieren bzw. ein anfängliches enumerate anzustossen ...

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.

-> callback/ip_connection/disconnected ist aber z.zt. ebenfalls "seltsam" :

 

soweit ich sehe, wird dieser callback nur getriggert, falls ein "regulärer" ausstieg via KeyboardInterrupt erfolgt. alle anderen umstände haben "seltsame" dinge zur folge :

 

(PROBLEM ? BUG? falsch verstanden ?)

 

wenn ich eine zwischenzeitliche ip-netzwerk-unterbrechung zum brickd simuliere, scheint der disconnect probe thread dies nicht zu erkennen !

 

selbst wenn ich abseits der zu erwartenden callbacks auch funktionen via -> request/.../get_identity o.ä. absetze, erhalte ich -> response/.../get_identity { '_ERROR' : "Did not receive response for function BLAH in time ..." } ...

 

aber es erfolgt keinerlei triggern eines -> callback/ip_connection/disconnected !!!

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.

jeden topic auf { ..., "_ERROR" : ... } zu prüfen IST mühsam !

 

es könnte auch einen weiterer "höher" aggregierter topic z.b.

-> callback/bindings/issue { "type" : ... } eingebaut werden, wo dann von aussen entschieden werden kann, ob es sich um ein potentiell temporäres problem der ip_connection handelt und das wartens auf ein reconnect sinnvoll ist oder eine - permanent fatale - exception auftrat ...

Das kannst du aktuell auch haben, indem du tinkerforge/# subscribst und nachsiehst ob "_ERROR" im Payload ist.

aufgrund dieser info kann man noch immer entscheiden, ob man mittels z.b. -> request/bindings/terminate ein normales mqtt-disconnect durchführt oder über -> request/bindings/abort und den proxy ohne disconnect mit exit(1) beendet ...

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.

so wie bei fatalen fehlern den proxy einfach beendet und den "last will" triggert ...

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.

Moin,

Kannst du das ganze mit einer älteren Brick Viewer Version (2.4.6 oder älter) testen? Wir haben mit der 2.4.7 alle Verbindungen auf https umgestellt, eventuell macht das bei dir Probleme.

Moin,

Führst du den Brick Viewer aus Source aus? Die Pfade im Callstack sehen so aus. Da wir vor kurzem Teile der UI geändert haben, musst du nochmal build_src.py in brickv/src ausführen, damit die neuen UI-Elemente in Pythoncode gegossen werden.

Moin,

Das funktioniert nicht out-of-the-Box, da müsste man einen eigenen Kerneltreiber schreiben. Ein Seriell-USB-Wandler + USB-Hub ist da einfacher. Alternativ kannst du ein GPS-Bricklet und dieses Programm benutzen.