Jump to content

roben

Members
  • Gesamte Inhalte

    4
  • Benutzer seit

  • Letzter Besuch

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

roben's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Hi zusammen, da OpenHAB 3 ja nun erschienen ist, ich nur eine kleine Handvoll Tinkerforge-Items nutze und ich nicht länger auf das Update warten will, habe ich nach einer Alternative zum Binding gesucht und in Form von tinkerforge_mqtt gefunden. Damit lassen sich Tinkerforge Daemons mit einem MQTT-Broker verbinden und der wiederum lässt sich via OpenHABs MQTT-Binding nutzen. Es ist deutlich unkomfortabler und komplizierter als ein richtiges Binding, aber ist vielleicht eine Hilfe für alle, die wie ich erstmal eine Lösung bauchen. Kurzanleitung (Funktionierendes MQTT in OH vorausgesetzt): https://www.tinkerforge.com/de/doc/Software/API_Bindings_MQTT.html installieren, `/etc/tinkerforge_mqtt.cmdline` anpassen und mit `tinkerforge_mqtt --cmdline-file /etc/tinkerforge_mqtt.cmdline` starten. Nötige subscriptions kann man sich zum Beispiel in eine init file `/etc/tinkerforge_mqtt.init` im jSON-Format fest eintragen (und in der ...cmdline hinterlegen). Meine sieht für ein einzelnes IO16 (nur Port A) so aus: { "tinkerforge/register/io16_bricklet/xxx/interrupt": {"register": true}, "tinkerforge/request/io16_bricklet/xxx/get_port": {"port": "a"} } xxx entspricht der Device ID wie in OpenHAB (3 Buchstaben). Die zweite Zeile dient nur dazu, den aktuellen Port state beim Starten initial zu übermitteln. Der kommt auch leider nur als Bitmask (z. B. 254 / 255 nur bei einem pin 0 aktiv), also muss man mit einem Number Input und entsprechenden Rules in OH arbeiten, der dann andere Items bedient. Dort legt man sich letztendlich nur ein MQTT-Thing an, was tinkerforge/callback/io16_bricklet/xxx/interrupt als State Topic hat und `JSONPATH:$.value_mask` als value transformation. Zum Schreiben müssen noch MQTT Command Topic und Outgoing Value Format entsprechend definiert werden. Sorry, viel Text und etwas Off Topic, aber ich hoffe, es hilft jemandem.
  2. Oh man, danke für diesen Hinweis! Ich habe meinen Garagentorsensor seit der Umstellung auf OH2.5 / Beta-Binding nicht mehr an Laufen bekommen und es lag einfach nur daran, dass ich vom alten Binding noch "Contact" stehen hatte. DAS wäre definitiv noch ein guter Punk für die Doku, zumindest zum Umstieg vom alten Binding.
  3. Per Standardeinstellung sollte das natürlich auch aus sein, weil man den Bricknamen ja auch gar nicht vorher kennt. Ich arbeite sehr viel mit Zeroconf und bin bisher sehr zufrieden damit, aber es sollte natürlich auch keinem aufgezwungen werden
  4. Hallo beisammen, ich mache gerade meine ersten Experimente mit den Bricks und Bricklets und bin sehr begeistert. Bei meinem Versuchen ist mir allerdings eine Sache aufgefallen, die das Handling der Ethernet-Bricks (und Wifi) noch deutlich vereinfachen würde: Wenn man diesen Bricks eine Zeroconf-Funktionalität spendieren würde, bräuchte man sich nicht die Mühe machen, DHCP-Logs nach der neuen IP zu durchsuchen oder die IPs für jeden Masterbrick von Hand zu verwalten, um das Gerät eindeutig identifizieren zu können. Man könnte statt dessen einfach per brickname.local auf den gewünschten Brick zugreifen. Der Name ist ja bereits konfigurierbar, wird "nur" nicht per Zeroconf veröffentlicht. Ist bekannt, ob so etwas irgendwann umgesetzt werden kann/soll/wird? Wenn nicht, möchte ich das gerne als Anregung hier stehen lassen
×
×
  • Neu erstellen...