Betaversion der openHAB-Bindings

[Malik]

Danke

[KlausGünther]

Hallo Erik,

mal eine Frage dazu.

Könnte man nicht einen Red-Brick (sofern man wie ich noch einen hat) laufen lassen, das an den Stapel anklemmen und dann dort alle TF-items einbinden und die Sachen machen die man so macht (was berechnen...) und dann mit dem remote openHAB Bindung eine Verbindung zwischen der Version 2 auf dem Red-Brick und dem OH3 herstellen ?

[rtrbt]

Die Doku zu den Remote-openHAB-Binding sagt zumindest, dass es genau für solche Fälle da ist. Ich habe aber keine Ahnung wie viel Aufwand es ist das Binding einzurichten. Im RED-Brick-Image ist aber vermutlich auch eine ältere openHAB-Version, die müsstest du von Hand aktualisieren.

Eventuell wäre folgendes einfacher: Die Tinkerforge-Bindings selbst können sich zu einem Brick Daemon verbinden, der nicht lokal läuft, sondern über das Netzwerk. D.h. du könntest da, wo OH3 bei dir läuft, OH2 daneben installieren, dich mit dem Binding zum RED-Brick verbinden (auf dem dann nur der Brick Daemon läuft) und es sollte funktionieren. Ich würde auch erwarten, dass die Performance dann besser ist: Der RED-Brick ist immerhin nur so schnell wie ein Pi 1, openHAB läuft auf dem Brick eher gemächlich.

[KlausGünther]

Und ich stelle gerade fest das der Red-Brick das Wifi 2.0 nicht unterstützt...also schon mal Käse mit meiner Idee.

 

 

[rtrbt]

openHAB kann sich auch zu WiFi Extensions verbinden. D.h.

openHAB3 <--> openHAB2 <--> Stack mit Master + Wifi Extension funktioniert auch ohne RED Brick, wenn du die openHAB2-Instanz auf dem selben Rechner laufen lässt wie die openHAB3-Instanz.

[StefanOHAN]

Hallo Eric,

kürzlich habe ich für das LCD 128x64 die neue Firmware eingespielt (2.0.10) leider ist das Problem mit dem Tab noch immer nicht behoben. Nach einer gewissen Zeit reagieren diese nicht mehr und nur ein Reset über den Brick Viewer schafft Abhilfe

Meine Bitte wäre, wenn Du wieder Zeit hast am Binding zu arbeiten, eine Art "Rest-Funktion" mit einzubauen. Dies sollte doch möglich sein oder ? Über den Brick Viewer kann man ja einen Rest für das Bricklet ausführen.

 

Viele Grüße

Stefan

 

[rtrbt]

Moin Stefan,

Das ist kein Problem, wundert mich warum ich das nicht schon gemacht hatte. Ich setze es mal auf die TODO-Liste. Habe gerade keine funktionsfähige Umgebung um das Binding zu bauen, sonst hätte ich das gleich gemacht.

[piwo2]

tinkerforge_openhab_bindings_2_0_0_beta9.zip       24-Sep-2019 15:06             3566354

liebe leute ...

sosehr ich die nöte einer wallbox-opportunity die eier legt sehe, möchte ich auch drauf hinweisen, dass das tinkerforge-ecosystem aus viel und teuerer brick/bricklet-hardware besteht, das auch ein bisschen was vertragen könnte :

ich erwarte sehnlichst eine definitive openhab (3/2???) integration samt definitiver installationsanleitung wo dieser bereich endlich aus den tiefen aufsteigt und auch für normalsterbliche verwendbar ...

eine ETA die halbwegs haltbar ist und nicht "mal sehen" wäre da auch glaube ich nichts, was einer zumutung gleichkäme, denke ich

danke für das verständnis & die aufwände
wp

[batti]

Hallo Piwo,

leider können wir kein ETA nennen. Die OpenHAB 2 Bindings, die nach wie vor im Beta Status sind, sind nachdem OpenHAB 3 nun der Standard ist nicht mehr sinnvoll fertigzustellen. Der Aufwand dafür wäre einfach immer noch recht groß und dann hätten wir Bindings für das alte System. Das heißt wenn müssten wir uns um OpenHAB 3 Bindings kümmern. Dies heißt technisch aber für uns quasi von vorne anzufangen.

Die OpenHAB 3 Bindings sind aus unserer Sicht definitiv wünschenswert, aber es stellt sich die Frage ob der Aufwand gerechtfertigt wäre. Insbesondere da es ja mit MQTT eine Möglichkeit gibt unsere Module in OpenHAB zu integrieren.

Aktuell ist in der Tat das Thema Wallboxen sehr wichtig für uns. Es wird aber voraussichtlich Ende diesen Monats auch neue Module für das Baukastensystem geben.

[StefanOHAN]

Hallo Eric, hallo Batti

ich muss Piwo2 recht geben.
Bis heute habe ich über 76 TF Brick/Bricklets/Extetions ... beschafft (allein ca. 10 Masterbrick) und einen Betrag deutlich über 1500€ investiert. Wenn ich Kabel und Zubehör mit berücksichtige, wird sich der Betrag um einige Hundert Euro erhöhen.
Wenn mir klar gewesen wäre, dass TF hier nicht konsequent die Binding Entwicklung durchziehen will, hätte ich keinen Cent in mein 2tes OpenHab-Projekt mit Tinkerforge Technik investiert. Ich vermute dass ca 2/3 meiner bisherigen Ausgaben in das zweite Projekt geflossen sind (das ich bis heute noch nicht abgeschlossen habe). 

Wenn über MQTT aus TF Sicht Eure Module zu integrieren sind, dann hättet Ihr das bitte schon vor   einem Jahr sagen sollen. Dementsprechend hätte man sich eine alternative Strategie überlegen können.

Wenn ich über „Umwege“ die Komponenten ansprechen / auslesen muss, hätte ich mich nie für TF entschieden.

Bitte entschuldigt diese direkten Worte, aber ganz persönlich bin ich extrem enttäuscht über diese Wendung. 

viele Grüße

Stefan 
 

[sihui]

Da TF Hardware auch in der Bucht nicht zu einem akzeptablen Preis zu verticken gewesen ist habe ich alle Bauteile als Elektroschrott entsorgt und bin auf andere Hardware umgestiegen.

Jetzt ist alles wieder gut und openHAB3 läuft und läuft und läuft ...

Danke TF für NICHTS!

[batti]

Hallo Stefan,

Danke dir für die offenen Worte. Ich kann die Enttäuschung ehrlich verstehen und möchte mich dafür Entschuldigen!

Das große Problem bei OpenHAB ist, dass deren Abbildung von Dingen, d.h. die Darstellung von Sensoren und Aktoren sich massiv zu unserer Abbildung unterscheidet. Daher gibt es für sehr viele Dinge keine 1 zu 1 Abbildung und wir müssen dies über Sonderkonstrukte lösen. Da wir die Bindings generieren müssen, anders wären für uns die vielen Programmiersprachen nicht zu warten, macht dies den Generator sehr sehr aufwändig. Dieses Problem haben wir bei den anderen Programmiersprachen nicht. Durch die Umstellung von OH2 auf OH3 ist vieles von dem bereits existierenden Code obsolet. In die bisherigen unfertigen OH2 Bindings haben wir schon einige Mannmonate investiert und bis zu fertigen OH3 Bindings wäre eher nochmal mehr zu investieren.

Das direkte OH3 Bindings deutlich bequemer einzusetzen sind wie die bestehenden MQTT Bindings ist uns bewusst. Dennoch sehe ich es so, dass über die MQTT Bindings eine Möglichkeit besteht unsere Komponenten in OH3 einzusetzen.

Wie gesagt ich schreibe die OH3 Bindings nicht vollends ab, aber es ist nicht realistisch dass wir diese irgendwann in nächster Zeit fertig stellen werden. Dies können wir aktuell einfach nicht leisten. Entschuldigt bitte, wenn wir euch falsche Hoffnungen gemacht haben! Dies war nicht unsere Absicht!

[StefanOHAN]

Hallo Batti,

danke für Deine Ausführungen.

Auch wenn ich jetzt nicht darauf warten würde dass von Euch in nächster Zeit ein OH3 taugliches Binding bereit gestellt wird, würde ich jedoch bitten dass Eric das OH2 Binding finalisiert. So wie ich das in Erinnerung habe, ist da nicht mehr soviel zu tun (z.B Einbau der Soft-Reset-Funktion der Bricklets ...).

Die Erfahrung aus meinem OH2 Testsystem zeigen, dass das "spezial-Binding" (Eric weiß was ich meine -> Thema Auto Check bei Betrieb von mehr als einem Brick-Dämon) bis auf ein paar Kleinigkeiten stabil  läuft ( Kleinigkeit = z.B LCD128x64 funktioniert nach einer gewissen Laufzeit die TAB nicht mehr, daher auch das Soft-Reset für die Bricklets).

Dies würde zumindest die Möglichkeit geben, Eure Komponenten noch "einfach" in einer OH2 Installation zu nutzen. 

Ich wäre mit dieser Notlösung nicht glücklich, aber man müsste nicht den komplizierten Weg über MQTT nutzen, oder gar schlimmer das Entsorgen von all den beschafften Komponenten.

viele Grüße

Stefan

bearbeitet November 5, 2021 at 10:01 von StefanOHAN

[rtrbt]

Moin,

Das Hauptproblem ist tatsächlich, dass

On 11/5/2021 at 11:00 AM, StefanOHAN said:

So wie ich das in Erinnerung habe, ist da nicht mehr soviel zu tun (z.B Einbau der Soft-Reset-Funktion der Bricklets ...)

nicht 100%ig stimmt. Ich bin mal die noch offenen Punkte durchgegangen, folgendes wäre noch zutun:

• Features
  • Allgemein
    • Deutsche Dokumentation
    • Advanced-Mode: Device führt dann keine Channels mehr raus, aber den kompletten Satz Java-API als Actions.
    • Konfiguration per Textdatei
    • Reset als Action rausführen
  • Device-Spezifisch
    • Thermal-Imaging: Neue Config-Parameter
    • LED Strip: ColorCommands akzeptieren, den Rest per Rule
    • Ambient Light v2/v3: Auto-Modus der Sättigung/Integrationszeit einstellt
    • Neu hinzugefügte API einfügen, z.B. Barometer I²C-Mode
  • Device-Gruppen-Spezifisch
    • Motorbricks wie DC-Brick bauen
    • Default-Werte des Update-Intervals kleiner machen wenn value_has_to_change verwendet wird, 1000ms sind gerade für IO-16 recht lang
    • Things mit Error-LEDs: Trigger-Channel hinzufügen, der nur im Show-Error-Modus der LED erzeugt wird, der Channel resettet die LED, indem setErrorLEDConfiguration(ShowErrors) nochmal aufgerufen wird.
    • Switch->Contact beim IO4/16 usw. Problem: Braucht Generatoränderungen
  • Dokumentation
    • Allgemeines Tutorial: Installation, Konfiguration von: Outdoor Weather Station, Remote Switch, LCD 128x64, irgendein normales Bricklet. Damit zeigen wie die "speziellen" Bricklets funktionieren, wie man sinnvoll Rules schreibt usw.
    • Outdoor Weather Station: relative rain fall example (https://www.tinkerunity.org/topic/5092-outdoor-wetter-station/?tab=comments#comment-28855)
    • in der API-Doku explizit erklären wie man einen Brick Daemon hinzufügt nach "You can then connect the bindings by adding a Brick Daemon thing in openHAB's Paper UI."
• Bugfixes
  • Prüfen ob alle Callbacks deaktiviert werden
  • https://github.com/openhab/openhab-core/issues/1265 (Actions sind nach Binding-Neustart kaputt)
  • https://github.com/openhab/openhab-core/issues/1233 (Uneindeutige Actions, wird von openhab-core nicht gefixt, heißt die Bricklet-Prefixe sind für die Ewigkeit)
  • dispose-Code dauert ewig/timeouts wenn Device ab ist
  • Display Bricklets zeigen auf der Übersichtsseite, solange noch kein Text gesendet wurde, '-' als Text an, wenn darauf geklickt wird NULL.
  • Read-Only Flags in den Channel-Typen setzen. Auto-Deduce?
  • Zip so bauen dass das zip-diff script funktioniert, also nicht nur unterorder einpacken
  • Reachabilitycheck doch single-threaden? Im Moment funktionierts, aber wenn jemand >= 5 Brick Daemons benutzt kann es doch passieren, dass die Threads lahmgelegt werden. Alternativ: Nicht blocken auf "sind die futures alle fertig" sondern pollen und yielden. Dann kann der Thread selbst die Tasks abarbeiten. Außerdem die "Burstigkeit" des ganzen verringern.

Dinge die durchgestrichen sind, würde ich jetzt droppen, damit man zu einem sinnvollen Abschluss kommt und das nicht noch Monatelang Vollzeitentwicklung ist. Dinge die kursiv sind, kommen vielleicht, das hängt konkret davon ab, wie viel Arbeit ich reinstecken muss/kann/will.

Ich werde dann jetzt voraussichtlich immer ~ einen Tag die Woche in die Bindings stecken, da die Liste so zusammengestrichen ist, sollte das dann nicht Monate dauern, bis eine "fertige" Version dabei rausfällt.

[theo]

Klingt für mich nach einem guten, pragmatischen Plan. 

[StefanOHAN]

Hallo Eric

das hört sich für mich auch gut an.

Danke

viele Grüsse

Stefan

[maxico]

Ein Binding für OH3 wäre weiterhin toll. Statt MQTT geht zumindest teilweise auch das OH Remote Binding

An dieser Stelle Danke an theo und sihui für das 1er Binding (läuft hier seit 2015).

 

[rtrbt]

Ein Weihnachtswunder:

https://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta24.zip

Das wird voraussichtlich die letzte Beta, bzw. falls keine kritischen Bugs darin sind ist es die "fertige" Version der openHAB-2-Bindings. Die Liste von oben ist soweit abgearbeitet. Außerdem neu ist Support für die seit der letzen Beta erschienenen Bricklets:
    - Industrial Dual AC Relay
    - Industrial PTC
    - IMU 3.0

sowie ein deutlich einfacherer Modus für das NFC-Bricklet (der aber nur Tag-IDs liest). Für die neuen Motor-Treiber-Bricklets gibt es keinen Support, das war zeitlich nicht drin und die Verwendung wäre ähnlich unkomfortabel wie die der alten Motor-Treiber gewesen.

Wichtig: In der Zip ist eine noch nicht veröffentlichte Version der Java-Bindings enthalten. Die ist notwendig um die teilweise neue API zu verwenden. Bei einem Update von einer älteren Bindingsversion bitte die 2.1.26er Jar löschen.

Mit der aktuellen Version und openHAB 2.5.9 scheint es auch zu funktionieren, die Bricks und Bricklets in einer .things-Datei zu definieren. Hier ein Beispiel:

Bridge tinkerforge:brickd:laptop [host="192.168.178.147"]

Thing tinkerforge:brickletmultitouch:zwL "Multitouch" (tinkerforge:brickd:laptop) [uid="zwL", proximityEnabled=false]

[StefanOHAN]

Hallo Eric,

danke für das "Weihnachtsgeschenk" :-)

 

Ich werde gleich dieses WE mit dem Testen beginnen.

Nochmal vielen Dank für Deine / Eure tolle Unterstützung

Viele Grüße

Stefan

bearbeitet December 17, 2021 at 08:39 von StefanOHAN

[StefanOHAN]

Hallo Eric,

ich habe dieses Wochenende mit dem testen des neuen Binding begonnen, ich bin noch nicht komplett fertig da ich noch nicht alle Rules auf die Änderungen angepasst habe.

Soweit ich es bis sehe, werde alle Input-Kanäle (IO-4 / IO-16 / Dual-Button / Digital-IN / Multi Touch …) in der Thing / Configuration GUI auch mit CONTACT als Hinweis dargestellt und reagieren im LOG auch mit einer Meldung CLOSED/OPEN

Um sicher zu stellen dass nicht die alte Binding Konfiguration Probleme bereitet habe ich

→ alle Rules deaktiviert

→ alle Things über die GUI gelöscht

→ alle Brick Daemons über die GUI gelöscht

→ das Binding über die openhab-cli console das Binding deinstalliert

→ einmal das System gebootet

→ den cache über openhab-cli clean-cache bereinigt

→ System einen init 6 ausgeführt

→ update des openHAB System (jetzt 2.5.12 ) ausgeführt (wird von mir nochmal geprüft)

→ beide neuen Binding eingefügt und THINGS mit Anpassung der Items neu angelegt.

 

Folgendes ist mir nach dem „ERSTEN“ Start mit Rule aufgefallen

→ nach dem umstellen und reaktivieren der Rule die für das LCD128x64 kam beim „anpassen“ des Display Backlight mit LCD128x64_BL.sendCommand(90) folgende Fehlermeldung.

 

Zitat

2021-12-19 22:17:41.595 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'LCD128x64-Menue': 'brickletLCD128x64RemoveAllGUI' is not a member of 'org.eclipse.smarthome.core.thing.binding.ThingActions'; line 71, column 17, length 48

 

Nach einem reboot erschien diese Meldung nicht mehr, und das Display funktionierte soweit. Ich hab das System jetzt mehrfach gebootet, der Fehler erschien nicht mehr. Keine Ahnung warum diese Fehlermeldung nach dem ersten Start der Rule kam.

 

Jetzt zum eigentlichen warum ich vorab schon hier poste

Ich habe Deinen Change-Log Eintrag für die Beta24 so verstanden, dass ein „soft-reset“ der Bricklets jetzt möglich ist

Zitat:

Zitat

-> 2021-12-16: 2.0.0 Beta 24
- Add reset action to CoMCU Bricklets

 

In Deiner OpenHab-Doku fand ich keinen Hinweis wie ich (z.B. ) für das LCD128x64 einen Reset ausführen kann.

In der JAVA API Beschreibung fand ich → void BrickletLCD128x64.reset()

Ich versuchte dann wie folgt einen Reset des LCD über eine Rule zu starten

Zitat

 

val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQJ")

lcdActions128x64.BrickletLCD128x64.reset()

 

dies ging aber total in die Hose, folgende Fehlermeldung bekam ich

Zitat

2021-12-20 07:04:02.251 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'button-LCD128x64_B8': 'BrickletLCD128x64' is not a member of 'org.eclipse.smarthome.core.thing.binding.ThingActions'; line 229, column 13, length 34

Es macht auch keinen Unterschied ob ich Klein / Großschreibung nutzte.

Wenn ich die Zeile „lcdActions128x64.BrickletLCD128x64.reset()“ aus kommentiere, erscheint keine Fehlermeldung.

Frage: wo liegt mein Fehler ?

Andere Action des Display scheinen zu funktionieren (Slider / Button / Tab )

Viele Grüße

Stefan

bearbeitet December 20, 2021 at 09:44 von StefanOHAN

[rtrbt]

Moin Stefan,

Das Problem nach dem ersten Start riecht noch nach irgendwelchen Cache-Problemen, bzw. was ich auch schon beobachten konnte: Manchmal passt beim ersten Start die Reihenfolge aus Thing erstellen und Rules ausführen nicht. Wenn das aber nicht nochmal auftaucht, würde ich das erstmal hinnehmen.

Der Reset ist noch nicht in der Doku, weil ich vergessen habe, die auf dem Server neuzubauen, sollte heute noch kommen. Der korrekte Weg ihn auszuführen sollte

val lcdActions128x64 = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQJ")

lcdActions128x64.brickletLCD128x64Reset() 

sein.

[StefanOHAN]

Hallo Eric,

danke für die schnelle Antwort.

Wie es schein hat mein Openhab-Update gestern nicht so richtig funktioniert, ich bin jetzt wieder bei v 2.5.8

Ich führe gerade einen weiteren Openhab Update durch (ich hoffe nur dass ich mir jetzt das Testsystem nicht zerlege).

Sobald mein System wieder verfügbar ist, werde ich den Reset Testen.

viele Grüsse

Stefan

bearbeitet December 20, 2021 at 10:18 von StefanOHAN

[StefanOHAN]

Hallo Eric,

kurzes Feedback.

Die Action Reset funktioniert beim LCD (was ein Punkt an der falschen Stelle für Auswirkungen haben kann).

Soweit ich es bis jetzt beurteilen kann, funktionieren meine angepassten Rule mit dem neuen Binding.

Einzig meine Rule für das NFC bringen noch Fehler im LOG, obwohl der TAG ausgelesen wird. Hier muss ich vermutlich die Rule komplett überarbeiten. 

Frage: Du schreibst

Am 16.12.2021 um 14:32 schrieb rtrbt:

sowie ein deutlich einfacherer Modus für das NFC-Bricklet (der aber nur Tag-IDs liest)

Wie wird/soll dies aussehen ?

 

Ich werde über die Feiertage meine Rules etwas entmisten und versuchen soviel als mögliche Funktionen der Bricklets zu testen.

Eine Frage noch, wird eigentlich der neue V3.1 Masterbrick auch von dem neuen Binding unterstützt ? (ich hab noch keinen, daher meine Frage). 

 

Viele Grüße Stefan

P.S. mein System läuft jetzt mit OpenHAB 2.5.12

bearbeitet December 21, 2021 at 08:31 von StefanOHAN

[rtrbt]

Der neue NFC-Modus funktioniert theoretisch ohne Rules: Der Modus ist eine Konfiguration des Bricklets, wenn du den auf "Simple" stellst, bekommt das Thing drei neue Channel, für Tag-ID, Tag-Typ und die Zeit wann ein Tag zuletzt gesehen wurde. Die befüllen sich automatisch, wenn du ein Tag dranhältst.

30 minutes ago, StefanOHAN said:

Eine Frage noch, wird eigentlich der neue V3.1 Masterbrick auch von dem neuen Binding unterstützt ? (ich hab noch keinen, daher meine Frage). 

Ja. Du kannst dann auch die neue Funktionalität des Bricks benutzen: es gibt einen "Bricklets Enabled"-Channel mit dem du die angeschlossenen Bricklets an und abschalten kannst.

[StefanOHAN]

Hallo Eric

 

wow die neue Simple NFC Read Funktionalität mit den 3 Items ist super genial und einfach zu nutzen.👍

Funktioniert extrem flott und ohne Rule 👍

Danke :-)

Ich wünsch Dir und dem Tinkerforge Team ein frohes Fest und ein gesundes neues Jahr

viele Grüße

Stefan

bearbeitet December 22, 2021 at 08:36 von StefanOHAN