Betaversion der openHAB-Bindings

[rtrbt]

On 11/28/2020 at 4:36 PM, sihui said:

Gibt es eine grobe Timeline wann Tinkerforge openHAB3 kompatibel wird?

Ich habe leider keine grobe Timeline, wann ich überhaupt wieder für openHAB Zeit habe. Ich sehe mal zu, dass ich im Dezember noch ein paar Tage zwischendurch investieren kann. Wenn es sich ergibt, teste ich diese Woche mal, ob ich das Binding zumindest erstmal so bauen kann, dass es mit openHAB 2 und 3 kompatibel ist.

[sihui]

vor 2 Stunden schrieb rtrbt:

ob ich das Binding zumindest erstmal so bauen kann

"erstmal so" würde ja vorerst reichen, es funktioniert ja ohne große Probleme.

Danke.

[rtrbt]

On 12/1/2020 at 9:49 AM, rtrbt said:

Wenn es sich ergibt, teste ich diese Woche mal, ob ich das Binding zumindest erstmal so bauen kann, dass es mit openHAB 2 und 3 kompatibel ist.

Habe mir das gerade mal angesehen und musste feststellen, dass das nicht klappt. Die Umbenennungen von org.eclipse.smarthome nach org.openhab sind in openHAB 2 nur halb gemacht, aber in openHAB 3 komplett. Das heißt, dass ich bestimmte Pakete nicht einheitlich importieren kann.

Der nächste Schritt wird dann wohl sein, noch eine letzte openHAB 2 kompatible Beta zu bauen, mit den kleineren Änderungen die so aufgelaufen sind, und danach auf openHAB 3 zu wechseln. Das wird wie gesagt aber noch etwas dauern, sorry.

[sihui]

vor 19 Stunden schrieb rtrbt:

Das wird wie gesagt aber noch etwas dauern, sorry.

Danke für die Bemühungen.

[skober19]

Liebe Community,

ich betreibe OpenHAB 2.5 nun seit 6 Monaten mit verschiedenen Bindings (AVM, EnoceanPi, MQTT usw.). Nun bin ich auf Tinkerforge aufmerksam geworden und habe mir ein MasterBrick mit einem Outdoor Weather Bricklet besorgt. Soweit so gut - brickv zeigt den Outdoor Temperatur-Sensor an.
Ich hab die Beta23 im Addons Ordner hinzugefügt  - leider kam dann die Meldung, dass ein Requirement nicht gegeben ist:

2020-12-06 12:21:54.400 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.tinkerforge-2.5.6-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.tinkerforge [255]
  Unresolved requirement: Import-Package: org.openhab.core.automation.annotation; resolution:="optional"
  Unresolved requirement: Import-Package: com.tinkerforge; version="[2.1.0,3.0.0)"

        at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]

Das konnte ich durch Google-Recherche lösen indem ich die tinkerforge-2.1.26.jar durch die tinkerforge-2.1.29.jar von MAVEN (https://search.maven.org/search?q=g:com.tinkerforge) ersetzt habe.

Nun erscheint das Tinkerforge-Binding bei Klick auf "+" in der Inbox. Wenn ich jedoch darauf gehe erscheint ein leerer Bildschirm - ich habe keine Möglichkeit den Brickd hinzu zufügen. Was machen ich falsch?

Hier noch die Information von OpenHAB:

root@karakal:/etc/openhab2# openhab-cli info

Version:     2.5.10 (Build)

User:        openhab (Active Process 17584)
User Groups: openhab tty dialout audio

Directories: Folder Name      | Path                        | User:Group
             -----------      | ----                        | ----------
             OPENHAB_HOME     | /usr/share/openhab2         | openhab:openhab
             OPENHAB_RUNTIME  | /usr/share/openhab2/runtime | openhab:openhab
             OPENHAB_USERDATA | /var/lib/openhab2           | openhab:openhab
             OPENHAB_CONF     | /etc/openhab2               | openhab:openhab
             OPENHAB_LOGDIR   | /var/log/openhab2           | openhab:openhab

URLs:        http://192.168.101.10:8080
             https://192.168.101.10:8443

root@karakal:/usr/share/openhab2/addons# ls -la
total 198548
drwxr-xr-x 2 openhab openhab      4096 Dec  6 12:23 .
drwxr-xr-x 4 openhab openhab      4096 Oct 26 15:34 ..
-rw-r--r-- 1 openhab openhab 199358169 Oct 25 19:25 openhab-addons-2.5.10.kar
-rw-r--r-- 1 openhab openhab   2177624 May 19  2020 org.openhab.binding.tinkerforge-2.5.6-SNAPSHOT.jar
-rw-r--r-- 1 openhab openhab        70 Oct 26 08:38 README
-rw-r--r-- 1 openhab openhab   1760259 Dec  5 11:18 tinkerforge-2.1.29.jar

 

[StefanOHAN]

Hallo Skober19

Frage: Erscheint nach betätigen des + beim TF Binding 

Zitat

Thing not found ? Manually add Thing ?

Wenn ja : solltest Du über "Manually add Thing" eine Liste der TF Thing öffnen können und  darüber den Brick-Dämon hinzufügen.

viele Grüsse

 

Stefan

 

[rtrbt]

Moin,

22 hours ago, skober19 said:

Das konnte ich durch Google-Recherche lösen indem ich die tinkerforge-2.1.26.jar durch die tinkerforge-2.1.29.jar von MAVEN (https://search.maven.org/search?q=g:com.tinkerforge) ersetzt habe.

Es wundert mich, dass das funktioniert hat. Hattest du die 2.1.26 auch im Addons-Ordner liegen?

Zusätzlich zu dem was Stefan schreibt: Hast du den Browser-Cache geleert? Mir passiert es überraschend oft mit der PaperUI, dass Einträge fehlen weil der Cache veraltet ist. Mach, wenn du auf das + in der Inbox geklickt hast, mal ein Strg+F5.

Falls das nicht hilft kannst du in der openHAB-Konsole mit

log:set TRACE org.openhab.tinkerforge

das Debug-Log aktivieren, dann openHAB neustarten und dann würde mich das openHAB-Log interessieren.

Erik

[skober19]

Hallo Stefan und Erik,

danke für eure Hinweise - tatsächlich hat bereits das Löschen des Caches geholfen. Damit konnte ich den Brickd sehen und hinzufügen.

Bezüglich des 2.1.26.jar's: Ja das hatte ich auch im Addons-Verzeichnis liegen. Ich kann es sogar reproduzieren, indem ich die 29er wieder durch die 26er tausche - sofort erscheint die Fehlermeldung im Log.

Ich denke nun komme ich erst einmal selbst weiter.

Vielen vielen Dank!!

bearbeitet December 7, 2020 at 17:10 von skober19

[skober19]

Hallo in die Runde,

ich brauche dann doch nochmal eure Hilfe.

Ich würde gern die gesamte Konfiguration über Konfigurationsdateien unter /etc/openhab2/ machen.

Soweit gelingt mir das bis zum Bricklet (das Auslesen der Sensor-IDs sowie die Volt/Ampere des Master Bricks klappt)

Bridge tinkerforge:brickd:abb7a53b "brickd_gepard" [ host="192.168.101.11", password="<PW>", port="4223", backgroundDiscoveryInterval="10.0", auth="true" ] {
        Thing brickmaster 6F4zNr "Brickmaster" [ serialNumber="6F4zNr" ]
        Thing brickletoutdoorweather RuC "OutdoorWeatherBricklet" [ serialNumber="RuC" ]
}

Nun scheitere ich daran den TH-6148 hinzuzufügen. Wenn ich ihn innerhalb der Bridge hinzufüge hagelt es nur Java-Fehler. Hier die Konfiguration:

Bridge tinkerforge:brickd:abb7a53b "brickd_gepard" [ host="192.168.101.11", password="<PW>", port="4223", backgroundDiscoveryInterval="10.0", auth="true" ] {
        Thing brickmaster 6F4zNr "Brickmaster" [ serialNumber="6F4zNr" ]
        Thing brickletoutdoorweather RuC "OutdoorWeatherBricklet" [ serialNumber="RuC" ]
        Thing tinkerforge:outdoorweathersensor:d3887d30 "OutdoorSensor1" [ bridgeUID="tinkerforge:brickletoutdoorweather:abb7a53b:RuC", sensorID="169" ]
}

Und der Fehler:

2020-12-07 23:05:21.922 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherSensorHandler@46f07de9': class org.openhab.binding.tinkerforge.internal.handler.BrickDaemonHandler cannot be cast to class org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherHandler (org.openhab.binding.tinkerforge.internal.handler.BrickDaemonHandler and org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherHandler are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @8788ca)
java.lang.ClassCastException: class org.openhab.binding.tinkerforge.internal.handler.BrickDaemonHandler cannot be cast to class org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherHandler (org.openhab.binding.tinkerforge.internal.handler.BrickDaemonHandler and org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherHandler are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @8788ca)
        at org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherSensorHandler.initialize(BrickletOutdoorWeatherSensorHandler.java:81) ~[?:?]
        at jdk.internal.reflect.GeneratedMethodAccessor112.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:834) [?:?]
2020-12-07 23:05:21.923 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'tinkerforge:outdoorweathersensor:d3887d30': class org.openhab.binding.tinkerforge.internal.handler.BrickDaemonHandler cannot be cast to class org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherHandler (org.openhab.binding.tinkerforge.internal.handler.BrickDaemonHandler and org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherHandler are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @8788ca)
java.lang.ClassCastException: class org.openhab.binding.tinkerforge.internal.handler.BrickDaemonHandler cannot be cast to class org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherHandler (org.openhab.binding.tinkerforge.internal.handler.BrickDaemonHandler and org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherHandler are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @8788ca)
        at org.openhab.binding.tinkerforge.internal.handler.BrickletOutdoorWeatherSensorHandler.initialize(BrickletOutdoorWeatherSensorHandler.java:81) ~[?:?]
        at jdk.internal.reflect.GeneratedMethodAccessor112.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:834) [?:?]

Füge ich ihn außerhalb dazu wird er zwar korrekt erkannt - jedoch fehlt im PaperUI die Bridge wie auch die sensorID. Welche Parameter muss ich übergeben, damit das funktioniert?

Bridge tinkerforge:brickd:abb7a53b "brickd_gepard" [ host="192.168.101.11", password="<PW>", port="4223", backgroundDiscoveryInterval="10.0", auth="true" ] {
        Thing brickmaster 6F4zNr "Brickmaster" [ serialNumber="6F4zNr" ]
        Thing brickletoutdoorweather RuC "OutdoorWeatherBricklet" [ serialNumber="RuC" ]
}

Thing tinkerforge:outdoorweathersensor:d3887d30 "OutdoorSensor1" [ bridgeUID="tinkerforge:brickletoutdoorweather:abb7a53b:RuC", sensorID="169" ]

 

[skober19]

Hallo in die Runde,

es hat sich erledigt - ich hab es selbst herausgefunden:

Bridge tinkerforge:brickd:abb7a53b "brickd_gepard" [ host="192.168.101.11", password="<PW>", port="4223", backgroundDiscoveryInterval="10.0", auth="true" ] {
        Thing brickmaster 6F4zNr "Brickmaster" [ serialNumber="6F4zNr" ]
        Thing brickletoutdoorweather RuC "OutdoorWeatherBricklet" [ serialNumber="RuC" ]
}

Thing tinkerforge:outdoorweathersensor:d3887d30 "OutdoorSensor1" (tinkerforge:brickletoutdoorweather:abb7a53b:RuC) [ sensorID="169" ]

Danke euch!

Ein super Projekt!!!

VG
Sebastian

[StefanOHAN]

Hallo Sebastian (skober19)

bis jetzt habe ich nur in meiner Openhab 1.9 Prod Umgebung die Things über Conf-Dateien angelegt. In  meiner Openhab 2.x Testumgebung sind Items / Sitemap und rules über Konfig-Dateien angelegt,  jedoch noch nicht die Thinkerforge-Things. 

Wenn ich mein Prod-System umstelle, würde ich auch soweit als möglich auf Config-Dateien zurückgreifen und die GUI nur dann nutzen wenn es nicht anders geht.

Frage: Was hast du außer dem Outdoor Weather Bricklet über die Thing Config Datei schon angelegt ? 

Deine Sensor-ID ist aktuell fest in der Config Datei "verdrahtet", oder ?

Hast Du schon eine Idee wie Du mit der neuen ID des Sensor beim Tausch der Batterie umgehen willst ? 

 

viele Grüsse

 

Stefan

 

[sihui]

vor 6 Stunden schrieb StefanOHAN:

Wenn ich mein Prod-System umstelle, würde ich auch soweit als möglich auf Config-Dateien zurückgreifen und die GUI nur dann nutzen wenn es nicht anders geht

 

Dann schau dir mal die neue MainUI in openHAB3 an. Du wirst keine Textdateien mehr mögen.

Und auch das stetige Argument, "wenn ich viele gleichartige Things anlegen möchte geht das nur über Textdateien flott" ist ad acta gelegt: das geht jetzt auch über die MainUI und zwar ähnlich flott.

Ich empfehle mal die Aufzeichnung des virtuellen openHAB Meetups v. 05.12. anzuschauen, ab ca. 26:30 min geht es los mit der Vorstellung der MainUI.

 

bearbeitet December 8, 2020 at 14:24 von sihui

[skober19]

Hallo Stefan,

ich habe bisher tatsächlich nur die 3 Komponenten - das war der Startschuss für die Outdoor Wetter Station. Ich wollte erst einmal schauen, ob es so funktioniert wie ich mir das denke. Von daher kann ich dir leider keine weiteren Beispiele liefern.
Die Sensor-ID ist fest verdrahtet - die muss ich dann halt ändern, wenn mal die Batterie leer war. Die Info dazu liefert dann der brickv.

Bei den Konfigurationsdateien geht es mir wie dir - ich möchte gern alles an einer Stelle haben. Da ich die Rules eh im VI schreibe, da kann ich auch den Rest im VI bearbeiten.
Aber grundsätzlich ist das wie die Diskussion zwischen Nagios ./. CheckMK. Wenn OpenHAB3 dann tatsächlich alles einfach über die Oberfläche bereit stellt, dann bin ich der letzte der an den Konfig-Dateien festhält ;-)

Viele Grüße

Sebastian

[MiRo]

Moin mal wieder,

"leider" läuft mein System gerade sehr stabil. Der Counter ist bei 23k - nach einem Restart wegen eines Updates (bei 56k).

Also keine neuen Traces. Aber gestern habe ich durch Zufall das in meinem Log (log.txt) gefunden.

2020-12-07 08:53:07.659 [vent.ItemStateChangedEvent] - tinkerforge_Io16_mod3_ina0 changed from OFF to ON
2020-12-07 08:53:07.679 [vent.ItemStateChangedEvent] - tinkerforge_Io16_mod3_ina1 changed from OFF to ON
2020-12-07 08:53:07.687 [vent.ItemStateChangedEvent] - tinkerforge_Io16_mod3_ina2 changed from OFF to ON
2020-12-07 08:53:07.691 [vent.ItemStateChangedEvent] - tinkerforge_Io16_mod3_ina3 changed from OFF to ON

 

Mitten aus dem "Nichts" werden kurzfrisig sehr viele - aber auch nicht alle - Ports auf ON gesetzt und ganz kurz später wieder auf OFF. Aber einige Ports bleiben ON

• tinkerforge_Io16_mod3_ina0
• tinkerforge_Io16_mod3_ina1
• tinkerforge_Io16_mod3_ina3
• tinkerforge_Io16_mod3_ina5

Da alle diese Ports aber als FensterKontakte dienen, können die in echt nicht wechseln - zumal zu dieser Zeit gar keiner zu Hause war.

Vielleicht gibt das ja eine Idee.

Schönen Gruß

Michael

[StefanOHAN]

Hallo sihui

danke für den Link der Dezember Video Präsentation der neuen Openhab3 Version.

Ich habe mir das Video angesehen und es unumstritten dass die neue MainUI sehr viele Möglichkeiten bietet, die das Leben in Openhab erleichtern wird.

Ich werde auf jedem Fall die neue MainUI testen, kann durchaus sein, dass ich dann auf Text-Config-File verzichten werde.

Ein NOGO für mich wäre, wenn ich keine Rule als Text-File anlegen könnte, denn das wäre für mich ein absoluter Kontrollverlust. So wie ich das verstanden ist dies aber in Openhab3 weiterhin möglich.

Es lebe die Vielfalt :-)

viele Grüße Stefan

[sihui]

vor 9 Stunden schrieb StefanOHAN:

Ein NOGO für mich wäre, wenn ich keine Rule als Text-File anlegen könnte, denn das wäre für mich ein absoluter Kontrollverlust. So wie ich das verstanden ist dies aber in Openhab3 weiterhin möglich.

Ja, die Rules DSL ist weiterhin vorhanden, es gibt aber einige kleine Änderungen was "now.get ..." angeht, aber die sind mit VSC schnell erledigt.

Inzwischen wird auch Javascript nativ unterstützt und auch Blocky falls jemand seine Rules gerne per grafischem Blockgeklicke (ähnlich wie Node Red) zusammenklicken möchte. Ist nicht mein Ding, aber bestimmt für den ein oder anderen Nutzer hilfreich.

[Sam]

Hallo in die Runde,

ich habe mir nun auch mal das Binding als Beta installiert. U.a. weil bei mir der v1-Binding Probleme macht.

Installation - Kein Problem

Things (Brick Deamon, Master Brick, IO-16 Bricklet) - Kein Problem

Nun möchte ich aber einige der Ports auch als Output nutzen. Wie bekomme ich das hin? Auch wenn ich die Ports über den BrickViewer auf Output setze, wird diese Konfiguration immer wieder überschrieben (z.B. wenn ich das IO-16 Thing neu hinzufüge)

Dann habe ich weiter vorne gelesen, dass bereits geplant ist die Inputs als Contact statt Switch anzulegen. Wie ist dazu der Status? Bei mir ist es noch ein Switch.

Ich kann gerne weitere Informationen liefern, falls gewünscht.

Beste Grüße

Sam

[rtrbt]

Moin,

52 minutes ago, Sam said:

Nun möchte ich aber einige der Ports auch als Output nutzen. Wie bekomme ich das hin?

Das kannst du unter Configuration -> Things -> das IO-16-Bricklet einstellen. Da gibt es über den Namen einen blauen Button, mit dem du die Thing-Einstellungen öffnen kannst. Darin kannst du, genau wie mit Brick Viewer, die Ports konfigurieren.

54 minutes ago, Sam said:

Auch wenn ich die Ports über den BrickViewer auf Output setze, wird diese Konfiguration immer wieder überschrieben (z.B. wenn ich das IO-16 Thing neu hinzufüge)

Das liegt daran, dass die Bindings sich nicht darauf verlassen, dass die Konfiguration unverändert ist, wenn das Bricklet neu auftaucht oder openHAB neustartet o.Ä. und deshalb alles neu setzt.

55 minutes ago, Sam said:

Dann habe ich weiter vorne gelesen, dass bereits geplant ist die Inputs als Contact statt Switch anzulegen. Wie ist dazu der Status? Bei mir ist es noch ein Switch.

Das ist noch auf der Agenda. Ich bin leider immer noch mit einem anderen Projekt beschäftigt *hust*. Wenn da der Release-Stress etwas abgeklungen ist, geht es mit den Bindings aber auf jeden Fall weiter.

Gruß,
Erik

[Sam]

Moin Erik,

🙏danke!

Da war ich etwas blind. Normalerweise definiere ich alles in den Config-Files und mache es nicht über PaperUi.

Habe mir jetzt schon mit "things list" und "items list" einige Infos gezogen. Gibt es schon irgendwo eine Dokumentation über die Syntax zur Konfiguration per Config-File?

Gibt es auch schon einen groben Zeitplan, wann das Binding "released" wird?

Beste Grüße

Sam

[StefanOHAN]

Hallo Erik,

Mein Test-System läuft seit einigen Monaten ohne Störung. Gestern ist mir jedoch aufgefallen, dass bei berühren eines der 3 im LCD 128x64 konfigurierten Tab, das Item für selected Tab nicht mehr reagiert.

Zitat

ITEM >>

Number LCD128x64_ST  "Tab [%s]" (Test)  {channel="tinkerforge:brickletlcd128x64:HQJ:BrickletLCD128x64SelectedGUITab"}

 

Rule >>

 Item LCD128x64_ST changed ...

 

Die button's reagieren, auch bekomme ich einen Rückmeldung der Berührungs-Koordinaten. Nach einem Reset über den BrickViewer funktionierte wieder alles. Leider konnte ich keine Fehlermeldung im Log finden.

Diesen Effekt hatte ich schon vor einigen Monaten, dachte aber es lag an der alten Firmware des LCD.

Weiter werden mir über "configuration/Thing" bei vielen Bricklets "Current firmware version: 2.0.3 Unknown" angezeigt.

z.B. 

Tinkerforge Industrial Quad Relay Bricklet 2.0

Tinkerforge Outdoor Weather Bricklet

Tinkerforge Remote Switch Bricklet 2.0

Tinkerforge Real-Time Clock Bricklet 2.0

Tinkerforge LCD 128x64 Bricklet

 

Das ist nicht für alle Bricklets der Fall, aber für die meisten. (Tinkerforge Humidity Bricklet 2.0 meldet >> Current firmware version: 2.0.6 Up to date "

Mal von den Rules für die LCD-Tab's abgesehen, funktioniert aber soweit alles.

Sind Dir diese beiden Effekte schon mal aufgefallen ?

viele Grüße

Stefan

[rtrbt]

Moin,

5 hours ago, StefanOHAN said:

Gestern ist mir jedoch aufgefallen, dass bei berühren eines der 3 im LCD 128x64 konfigurierten Tab, das Item für selected Tab nicht mehr reagiert.

Das ist interessant.

Hat das Tab-Wechseln visuell noch funktioniert? Also dass der berührte Tab dann aktiv war, auch wenn dessen GUI vermutlich gefehlt hat, weil ja das Callback fehlte. Damit könnte man gut diagnostizieren, wo das schief gelaufen ist.

5 hours ago, StefanOHAN said:

Weiter werden mir über "configuration/Thing" bei vielen Bricklets "Current firmware version: 2.0.3 Unknown" angezeigt.

Das kenne ich, da bin ich aber noch nicht hinterher gestiegen, man kommt hier ja zu nichts :D

 

19 hours ago, Sam said:

Habe mir jetzt schon mit "things list" und "items list" einige Infos gezogen. Gibt es schon irgendwo eine Dokumentation über die Syntax zur Konfiguration per Config-File?

Nein, weil das bisher von meiner Seite aus "ungetestet" ist. Als nächstes steht sowieso der Wechsel zu openHAB 3 an, da muss ich das dann in Ruhe ausprobieren, wie das mit den Files ist. Bisher "unterstützt" ist nur die Konfiguration per PaperUI.

19 hours ago, Sam said:

Gibt es auch schon einen groben Zeitplan, wann das Binding "released" wird?

Leider nein. Ich bin wie gesagt noch mit der Wallbox beschäftigt, aber optimistisch im Winter noch etwas Zeit in openHAB stecken zu können.

Frohe Weihnachten an alle!
Erik

[StefanOHAN]

Hallo Erik

 

meinst Du mit

Zitat

„Hat das Tab-Wechseln visuell noch funktioniert? Also dass der berührte Tab dann aktiv war,  “

dass sich beim berühren eines Tab die Ihm umranden Linie nach oben „öffnet“ ?

 

Darauf habe ich nicht geachtet. Ich kann nur sagen, dass die auf dem Display dargestellten Buttons funktionierten und „Ihre“ Rule aktivierten. Die Rule für den Button löscht per Actions den gesamten Inhalt des Display incl aller Tab/Button und stellt 2 Slider dar. Die Actions scheinen also nicht betroffen zu sein. 

 

Ich werde mal aufpassen wie sich die Tab‘s verhalten wenn der Fehler wieder auftritt.

 

Viele Grüße ein frohes Fest und ein gesundes neues Jahr

 

Stefan

[roben]

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.

bearbeitet December 25, 2020 at 22:24 von roben

[sihui]

vor 20 Stunden schrieb roben:

... und ich nicht länger auf das Update warten will

Danke für die Info. Ich habe einen anderen Weg gewählt um endlich auf openHAB3 umsteigen zu können: ich habe meine komplette Tinkerforge Hardware gegen andere Hardware getauscht, das ganze Zeugs gibt es demnächst im Aktionshaus zu kaufen.

Wenn schon der Hersteller der Hardware sich bereit erklärt die Software für bestimmte Hausautomatisierungen selbst zu pflegen erwarte ich eine deutlich schnellere Umsetzung der notwendigen Anpassungen. Da auch nicht absehbar ist wann das Binding in die offizielle openHAB Repo überführt wird ist mir die ganze Sache inzwischen hier zu heiß.

Das ging vorher, als es noch in Theos Händen und privater Initiative lag, deutlich schneller.

Eigentlich schade, meine erste Hardware vor mehr als fünf Jahren beim Einstieg in die Hausautomation war Tinkerforge.

[duaw]

vor 16 Stunden schrieb sihui:

Ich habe einen anderen Weg gewählt um endlich auf openHAB3 umsteigen zu können: ich habe meine komplette Tinkerforge Hardware gegen andere Hardware getauscht.

Hallo!

Ich werde openHAB den Rücken kehren und auf NodeRed umsteigen. Ich habe mal mit OH1 angefangen, die Lösung dann mit OH2  betrieben. OH2 und OH3 gefällt mir einfach nicht mehr.

NodeRed passt bei mir persönlich besser. Und meine Bedürfnisse bzgl. TF werden bestens mit den MQTT-Bindings erfüllt. Da muss ich nichts neues kaufen ... 

Gruß, Uwe