Martin 0 Posted January 3 Share Posted January 3 Hallo, wo findet sich eine "Einstiegsseite" für OpenHAB2+Tinkerforge mit aktuellem Downloadlink und kurzem Readme zur Installation? So eine Diskussion (mit aktuell 15 Seiten) ist recht umständlich, um an die relevante Information zu kommen. Zu Beginn findet sich unterhttps://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/ zwar ein Link aufhttps://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta23.zip (wobei "Die 23. Beta findet sich hier." nicht gerade optimal für eine Internet-Suche ist) Später dann z.B. unterhttps://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/page/12/?tab=comments#comment-30294 noch ein Anhang (https://www.tinkerunity.org/applications/core/interface/file/attachment.php?id=2096), der hier allerdings scheinbar nicht mehr vorhanden ist ("unavailable"). Unter https://download.tinkerforge.com/_stuff/ findet sich aber gerade keine neuere Version. (Wo dann?) Welches Java Binding soll verwendet werden?https://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/?do=findComment&comment=31828 Was denn nun? tinkerforge-2.1.26.jar oder 2.1.29? Für Debian/Ubuntu gibt es eine Tinkerforge Repository mit Java-Bindings, s.https://www.tinkerforge.com/de/doc/Software/APT_Repository.html#pakete Nach der Installation von libtinkerforge-java: $ ls -l /usr/share/java/tinkerforge* lrwxrwxrwx 1 root root 15 Nov 2 17:33 /usr/share/java/tinkerforge-2.1.29.jar -> tinkerforge.jar -rw-r--r-- 1 root root 1734763 Nov 2 17:33 /usr/share/java/tinkerforge.jar (Kurios, dass hier die der Link die Version im Namen trägt und nicht die Datei.) Die aktuelle Version ist hier aktuell also 2.1.29. Vielleicht könnte man die openhab Bindings einfach auch hier verfügbar machen. Am besten wäre aber (wieder) ein "offizielles" OpenHAB Binding (am besten gleich für OpenHAB3). Muss (in OpenHAB2) das OpenHAB1 Binding deinstalliert oder nur deaktiviert sein, falls man dieses OpenHAB2 Binding testen will? Martin Quote Link to post Share on other sites
rtrbt 27 Posted January 4 Author Share Posted January 4 Moin, @Martin Du suchst vermutlich diese Seite: https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html (Der Download-Link darauf bringt dich nicht weiter, aber die ganze Dokumentation sollte hilfreich sein.) 12 hours ago, Martin said: zwar ein Link aufhttps://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta23.zip (wobei "Die 23. Beta findet sich hier." nicht gerade optimal für eine Internet-Suche ist) Später dann z.B. unterhttps://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/page/12/?tab=comments#comment-30294 noch ein Anhang (https://www.tinkerunity.org/applications/core/interface/file/attachment.php?id=2096), der hier allerdings scheinbar nicht mehr vorhanden ist ("unavailable"). Die funktionieren bei mir beide. Nimm im Zweifel eher den zweiten, also den Anhang im Forum. Warst du eventuell nicht eingeloggt, als du versucht hast den runterzuladen? Das sollte eigentlich ohne Login gehen, aber vielleicht ist die Forensoftware da falsch konfiguriert. 12 hours ago, Martin said: Welches Java Binding soll verwendet werden?https://www.tinkerunity.org/topic/4901-betaversion-der-openhab-bindings/?do=findComment&comment=31828 Was denn nun? tinkerforge-2.1.26.jar oder 2.1.29? 2.1.26. Mir ist absolut unklar, was bei der Installation von skober19 dazu führt, dass die Version nicht funktioniert. 12 hours ago, Martin said: Für Debian/Ubuntu gibt es eine Tinkerforge Repository mit Java-Bindings Das bringt dich nicht weiter, du musst die Java-Bindings-Jar direkt mit in den addons-Ordner von openHAB ablegen. 12 hours ago, Martin said: Vielleicht könnte man die openhab Bindings einfach auch hier verfügbar machen. Am besten wäre aber (wieder) ein "offizielles" OpenHAB Binding (am besten gleich für OpenHAB3). Das ist langfristig das Ziel, dafür muss das Binding nur erst "fertig" werden. Auch für die anderen im Thread: Ich weiß, dass sich das schon lange verschleppt, ich kann als schlechte Ausrede aber nur anbieten, dass ich halt als einziger daran entwickle und der Aufgabenhaufen mit höherer Priorität (Mikrocontroller-Bindings, ESP32-Brick-Firmware, Wallbox-Firmware) langsam aber sicher kleiner wird. Quote Link to post Share on other sites
StefanOHAN 8 Posted January 8 Share Posted January 8 Hallo Erik gestern hatte ich wieder den Fehler, dass mein Astro & NTP Binding den Dienst eingestellt hat. Die letzte Meldung in Log war ein Reconnect des WIFI Dämon. Mit Deinem Spezial Binding ist die Konfiguration jetzt einige Monate ohne Fehler gelaufen. Ich weiß nicht ob es damit zusammen hängen kann, in der Woche nach Neujahr habe ich mein internes Netzwerk umgebaut und das Openhab-System war einigen Stunden ohne funktionierendes Netzwerk. Somit war für das Openhab die Brick des WIFI-Dämon und die Bricks des PI2/Hat Dämons nicht erreichbar . Der Ausfall war aber erst Gestern. Aktuell läuft die Konfiguration mit 3 Dämons 1 x WIFI (Masterbrick mit WIFI Extension) 1 x Remote für Pi2 mit BrickHat & USB angebunden Masterbricks (auf dem Pi2 läuft nur der BrickDämon kein OpenHab) 1 x auf dem Openhab Pi (4) mit ZeroHat Wenn ich mir das Ergebnis des trace aus der Konsole anschaue, sehe ich dass auf jedem Fall sehr viele Prozesse vorhanden waren. (siehe begefügten trace)Thread-openhab-20210107.txt Nach dem Reboot des Openhab-System funktionierte wieder alles. Viele Grüße Stefan Quote Link to post Share on other sites
rtrbt 27 Posted January 8 Author Share Posted January 8 Das sieht wieder genau nach dem Problem aus, das die Spezialversion fixen sollte: Alle 5 ThingHandler-Threads hängen wieder beim Versuch zu testen ob ein Bricket erreichbar ist. Bist du dir sicher, dass es die Version ist? ;) Wenn ja muss ich mir das nochmal in Ruhe ansehen, Multi-Threading ist kompliziert. Das kommt auf jeden Fall ganz oben auf die openHAB-Todo-Liste, wird aber wie gesagt noch etwas dauern, bis ich dazu komme. Quote Link to post Share on other sites
StefanOHAN 8 Posted January 8 Share Posted January 8 Hallo Erik, ja es ist noch Deine Spezial Version. Seit ich von Dir diese Version bekommen habe, habe ich das System nicht neu konfiguriert / installiert. Bisher hatte ich nur den reconnect des WIFI Dämons (hier hatte ich mit Deiner Spezial-Version keine Probleme), in der letzten Woche war aber mal das komplette Netzwerk für ein paar Stunden nicht verfügbar, da ich meine Verkabelung vom Router zu den Switchen auf LWL umgestellt habe. Das ist der einzige Unterschied der ich zur damaligen Situation hatte. viele Grüße Stefan Quote Link to post Share on other sites
Tamino 0 Posted January 15 Share Posted January 15 Hallo zusammen, ich würde gerne mit einem Solid State Relay Bricklet 2.0 mittels PWM (Monoflop) einige LEDs schalten und dimmen. Das schalten klappt soweit auch sehr gut, auch mit Google Assistant. Nur beim dimmen finde ich irgendwie keine brauchbaren Regeln und bräuchte hier etwas Hilfe. Hat jemad einen Ansatz wie ich dies realisieren kann? Schöne Grüße Alex Quote Link to post Share on other sites
rtrbt 27 Posted January 15 Author Share Posted January 15 Ich hoffe, du hast diese Warnung gelesen, ich vermute deine LEDs würden bei maximal 30 Hz ziemlich flackern und mehr ist wie beschrieben wirklich keine gute Idee. Falls du mit den niedrigen Schaltfrequenzen leben kannst, hast du das nächste Problem, dass du mit einer openHAB-Regel sauber ein 30 Hz Timing hinbekommen musst. Da sehe ich ehrlich gesagt schwarz. Du könntest stattdessen z.B. ein Pythonscript schreiben und mit openHABs Exec-Bindung ausführen. Dann darfst du aber nicht das Relay Bricklet parallel in openHAB benutzen (lies: nicht aus der Inbox als Thing übernehmen). Quote Link to post Share on other sites
Tamino 0 Posted January 16 Share Posted January 16 Hi und vielen Dank für die Info. Habe das Beispiel Python Script geladen und eingebunden. Dies funktioniert auch soweit sehr gut. Das einfache script schaltet ja jetzt nur 5x ein und wieder aus und wird dann beendet. Gibt es eventuell schon Beispiel Scripte für das Dimmen über PWM, oder muss ich mir das selbst zusammen klöppeln? Schöne Grüße Alex Quote Link to post Share on other sites
_Andy_ 0 Posted February 3 Share Posted February 3 Gibt es schon Neuigkeiten bzgl. Openhab 3? Ich habe mir extra wegen der vermeintlich guten Integrierbarkeit Tinkerforge-Komponenten zugelegt - um jetzt beim Installieren festzustellen dass wohl bei der Kompatibilität "openHAB 2.5.0 or newer" nicht 3.0 gemeint ist... Quote Link to post Share on other sites
rtrbt 27 Posted February 4 Author Share Posted February 4 Moin, Das ist leider missverständlich formuliert, "openHAB 2.5.0 or newer" meint nur, dass weitere 2.5-Versionen (oder falls es 2.6 gegeben hätte das) problemlos funktioniert. Ich ändere den Text mal, damit das nicht so verwirrend ist. Die openHAB 3-Version dauert noch etwas, ich bin Stand jetzt noch gut mit der Wallbox beschäftigt. Quote Link to post Share on other sites
StefanOHAN 8 Posted February 11 Share Posted February 11 Hallo Eric, heute (09.02.2021) hatte ich wieder den Effekt, dass am LCD128x64 die Tab‘s nicht mehr auf Berührung reagierten. Egal welchen TAB ich berührte (es sind 3 Stück konfiguriert), es änderte sich nichts an der Darstellung auf dem Display. Beim berühren werden mit im Log die Koordinaten angezeigt aber nicht ob ein Tab berührt wurde. Die Buttons und die Slider funktionieren noch. Auch das Löschen des Display‘s per Rule funktioniert. Wie es scheint funktionieren alle anderen Rules / Bricklets. In den Log's sehe ich keine Fehlermeldung bezüglich des Display. Ich füge mal die Thread aus der Console an. Nachdem ich über den BrickViewer einen Reset für das LCD-Bricklet ausführte, funktionierten die Tabs wieder. Viele Grüße Stefan P.S. ich arbeite noch immer mit Deinem Spezial-Binding 202102210-21Uhr.txt Quote Link to post Share on other sites
rtrbt 27 Posted February 12 Author Share Posted February 12 Moin Stefan, (Das Problem hatten wir ja schonmal, sorry falls ich gerade Dinge doppelt frage) On 2/11/2021 at 9:27 AM, StefanOHAN said: Die Buttons und die Slider funktionieren noch. Reagierst du auf die Buttons und Slider auch mit Rules und wenn ja funktionierten die auch? D.h. waren nur die Tab-Wechsel kaputt und alles andere funktionierte noch? In dem Log sind ein paar Dinge interessant: Ich sehe keine ThingHandler, eventuell übersehen ich da aber gerade etwas. (Thing kommt nicht vor, das ist sehr suspekt) Welche openHAB-Version ist das? Ich sehen drei Brickd-Receiver Threads (und auch Callback-Processor- und Disconnect-Prober-Threads). Hast du drei Brick Daemons konfiguriert oder ist das kaputt? Quote Link to post Share on other sites
StefanOHAN 8 Posted February 14 Share Posted February 14 (edited) Hallo Eric, zu Deinen Fragen: Ja die Button und Slider sind mit Rule verknüpft und diese funktionieren auch. Neben den 3xTab sind auf dem „Startbildschirm“ des LCD128x64 2xButton konfiguriert. Der eine Button ruft eine Rule zum Neuaufbau des LCD-Screen auf. Dieser wird dadurch komplett gelöscht und anschließend 2xSlider konfiguriert (dies funktioniert). Die beiden Slider zeigen Ihre Rückgabewerte auf dem LCD128x64 an. Wenn die Slider von rechts nach links bewegt werden, werden die entsprechend geänderten Rückgabe-Werte am Display angezeigt. Einzig die Tabs reagieren nicht. Folgendes ist aktuell auf dem OpenHAB-System (PI3) konfiguriert: openHAB 2.5.8-1 (Release Build) 3 x OpenHAB-Tinkerforge-Dämon (Spezial-Version 23b) >> Ja es sind 3 Dämon konfiguriert Linux armhf Tinkerforge Brick-Dämon 2.4.1 (19.12.2019) Kernel = Linux 5.4.51-v7+ Der aktuelle Testaufbau sieht wie folgt aus: PI3 mit Zero-Head-Brick, hier läuft das Openhab-System PI2 mit Head-Brick sowie ein Stapel von 3xMasterbrick und 2xRS485-Extemtion die per USB angeschlossene sind. Auf dem PI2 läuft nur Linux und der Linux-Tinkerforge-Dämon, kein Openhab Masterbrick per WIFI Extention angebunden Du schreibst: Zitat „Ich sehe keine ThingHandler, eventuell übersehen ich da aber gerade etwas. (Thing kommt nicht vor, das ist sehr suspekt) Welche openHAB-Version ist das?“ Frage: Kann es sein, dass man das LCD-Thing nicht im Log sieht, da es am PI2 über ein HeadBrick angeschlossen ist (und nicht am "OpenHAB"-Pi3), und dieser PI2 über das Netzwerk mit dem zugehörigen BrickDämon auf dem "OpenhHab"-PI3 kommuniziert ? An dem PI3 (auf dem das OpenHab-System läuft) ist aktuell nur ein Zero-Brick-Head aufgesteckt an dem ein Clock-Bricklet angeschlossen ist, mehr nicht. Ich füge eine Zeichnung der Konfiguration bei, ich hoffe dass es dadurch etwas übersichtlicher wird. (siehe PDF, hier sind auch Details zu den TF-Brick-Dämon Versionen und den konfigurierten Bricklets enthalten.) Aktuell bin ich mir jetzt nicht sicher, es kann aber durchaus sein, dass die Probleme mit den LCD-Tabs erst aufgetreten sind, nachdem ich im letzten Jahr die Konfiguration auf die 2 verschiedene PI3 / PI2 aufgesplittet habe. Heute habe ich auf dem PI3 und dem PI2 einen Update des Linux-armhf-Brick-Dämon auf die neueste Version 2.4.3 ausgeführt und anschließend beide neue gebootet. Für das Linux und Openhab-System habe ich keinen Update ausgeführt. Frage: Nachdem das LCD nicht an dem PI3 mit der OpenHab-Installation angeschlossen ist, gibt es andere Log-Quellen des PI2 die Dir helfen könnten ? Hinweis: In diesem etwas kleinteiligen OpenHab Aufbau (PI3 + PI2 + WIFI-Extention) versuche ich die möglichen Grenzen auszutesten. Wenn ich mein Prod-System umstelle, wird das System wieder einfacher aufgebaut sein (die WIFI-Extention wird keine Verwendung finden, ggf. werden auch wieder alle Bricklets an dem OpenHab-Pi angeschlossen da ein P4 dafür vorgsehen ist. Beibehalten werde ich aber die RS485 Extention). viele GrüßSkizze-konfig-202101.pdfe Stefan Edited February 14 by StefanOHAN Quote Link to post Share on other sites
rtrbt 27 Posted February 15 Author Share Posted February 15 Moin, On 2/14/2021 at 10:54 AM, StefanOHAN said: Ja die Button und Slider sind mit Rule verknüpft und diese funktionieren auch. Neben den 3xTab sind auf dem „Startbildschirm“ des LCD128x64 2xButton konfiguriert. Der eine Button ruft eine Rule zum Neuaufbau des LCD-Screen auf. Dieser wird dadurch komplett gelöscht und anschließend 2xSlider konfiguriert (dies funktioniert). Die beiden Slider zeigen Ihre Rückgabewerte auf dem LCD128x64 an. Wenn die Slider von rechts nach links bewegt werden, werden die entsprechend geänderten Rückgabe-Werte am Display angezeigt. Einzig die Tabs reagieren nicht. Das ist sehr interessant, vorallem in Kombination mit dieser Aussage: On 2/11/2021 at 9:27 AM, StefanOHAN said: Egal welchen TAB ich berührte (es sind 3 Stück konfiguriert), es änderte sich nichts an der Darstellung auf dem Display. Da du das nichts so betonst: Meinst du mit nichts auch, dass das hier. Quote dass sich beim berühren eines Tab die Ihm umranden Linie nach oben „öffnet“ ? nicht ging? Dann wäre das ein reines Problem des LCD 128x64 und komplett unabhängig von openHAB. Das würde das Debuggen extrem vereinfachen. On 2/14/2021 at 10:54 AM, StefanOHAN said: Frage: Kann es sein, dass man das LCD-Thing nicht im Log sieht, da es am PI2 über ein HeadBrick angeschlossen ist (und nicht am "OpenHAB"-Pi3), und dieser PI2 über das Netzwerk mit dem zugehörigen BrickDämon auf dem "OpenhHab"-PI3 kommuniziert ? Nein, das sollte aus openHAB-Sicht keinen Unterschied machen. Eventuell sind aber die Threadnamen verquer und ich habe das deshalb nicht gesehen. On 2/14/2021 at 10:54 AM, StefanOHAN said: Frage: Nachdem das LCD nicht an dem PI3 mit der OpenHab-Installation angeschlossen ist, gibt es andere Log-Quellen des PI2 die Dir helfen könnten ? Das hängt stark von der Antwort auf meine erste Frage ab. Wenn die Tab-Leiste korrekt gezeichnet wurde, wäre /var/log/brickd.log des Pi 2 interessant. Übrigens ein cooler Aufbau, damit sollten sich alle absurden Verbindungs-Bugs finden lassen :D Quote Link to post Share on other sites
StefanOHAN 8 Posted February 15 Share Posted February 15 (edited) Hallo Eric, es war etwas unglücklich von mir formuliert, ich meinte dass sich beim berühren eines Tab die Ihm umranden Linie nach oben nicht „öffnet“ (und im Log keine Meldung erscheint, welcher Tab berührt wurde). Somit wird mit Deinen Worten die Tab-Leiste "nicht" korrekt gezeichnet, oder ? Ansonsten reagiert das Display wie erwartet, die Rules scheiben Zeichen in verschiedener Größe ... usw. Der Slider reagiert in der Form, dass der "Schieber" des Slider mit der Fingerbewegung sich an die Stelle bewegt auf dem der Finger ihn hin schiebt. Beim Betätigen des Button hab ich jetzt nicht aufgepasst ob sich optisch was ändert, der Button hat auf jedem Fall die passende Rule an getriggert. Viele Grüße Stefan Edited February 15 by StefanOHAN Quote Link to post Share on other sites
SimRa 0 Posted February 19 Share Posted February 19 Am 4.2.2021 um 16:52 schrieb rtrbt: Die openHAB 3-Version dauert noch etwas, ich bin Stand jetzt noch gut mit der Wallbox beschäftigt. Hallo Zusammen, über welchen Zeitraum wird hier gesprochen? 1 Woche, 1 Monat,.. ? Würde das gerne wissen, um zu entscheiden, on ich mir die Mühe machen muss, unnötige zusätzliche Hardware zwischen openhab3 und die Wetterstation einzubinden. Zuvor habe ich es mit einer zweiten frischen OH-Installation versucht. Seit Openhab3 kann man die Installation auf Openhab2-Kompatibilität stellen. Soweit ich das richrig verstanden habe. Eine andere Möglichkeit, eine ältere Version(2.5.x) von Openhab zu nutzen habe ich nicht gefundene, bzw hat nicht funktioniert. Hat das "aktuelle" Binding schon jemand mit der Kompatibilitäts-Version getestet? Nach dem Ablegen der Jar-Dateien im Addon-Ordner wird im Log folgendes angezeigt: 2021-02-18 12:57:26.212 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.tinkerforge-2.5.6-SNAPSHOT.jar org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.tinkerforge [218] Unresolved requirement: Import-Package: org.eclipse.smarthome.config.core 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.doProcess(DirectoryWatcher.java:520) [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] Besten Dank und Grüße, Simon Quote Link to post Share on other sites
rtrbt 27 Posted February 22 Author Share Posted February 22 On 2/19/2021 at 7:21 PM, SimRa said: über welchen Zeitraum wird hier gesprochen? 1 Woche, 1 Monat,.. ? Mindestens einen Monat, eher etwas länger. Der aktuelle Schlachtplan ist für die Wallbox (neben 100 kleineren Dingen) eine Zeitschaltung und Lastmanagement über OCPP zu implementieren. Wenn das weg ist und danach nicht neue dringende Featurewünsche auflaufen, kann ich vermutlich Zeit einschieben, die angefallenen aber unfertigen Projekte zu beenden, heißt openHAB- und C/C++-für-Mikrocontroller-Bindings. Aktuell ist aber die Wallbox das was mit Abstand am höchsten priorisiert wird. On 2/19/2021 at 7:21 PM, SimRa said: Seit Openhab3 kann man die Installation auf Openhab2-Kompatibilität stellen. Soweit ich das richrig verstanden habe. Das klingt interessant, gibt es da Dokumentation zu? Ich habe beim spontanen suchen nichts gefunden. On 2/19/2021 at 7:21 PM, SimRa said: Würde das gerne wissen, um zu entscheiden, on ich mir die Mühe machen muss, unnötige zusätzliche Hardware zwischen openhab3 und die Wetterstation einzubinden. Bevor du da Hardware draufwirfst: Du kannst notfalls den Weg über die (Tinkerforge-)MQTT-Bindings und das (openHAB 3-)MQTT-Binding gehen. Ist nicht ganz so komfortabel wie ein natives Binding, aber immerhin. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.