Jump to content
theo

openhab Integration

Nächste Bricks/Bricklets mit openHAB Unterstützung  

23 members have voted

  1. 1. Nächste Bricks/Bricklets mit openHAB Unterstützung

    • Stepper
    • IMU
    • IMU 2.0
    • Accelerometer (fertig)
    • Analog In (fertig)
    • Analog In 2.0 (fertig)
    • Analog Out
    • Analog Out 2.0
    • GPS
    • Industrial Analog Out
    • Industrial Dual Analog In (fertig)
    • Laser Range Finder (fertig)
    • NFC/RFID
    • Color (fertig)


Recommended Posts

Hallo Theo,

 

das PiHat liegt schon seit einer Woche auf dem Schreibtisch.

Ich habe parallel noch einen Pi 4b mit 4GB bestellt, der leider noch nicht da ist. Ich will gleich beides in einem Aufwasch testen.

Meine aktuelle Test-Config hat noch einen Pi 2b, den werde ich dann in die Rente schicken.

 

Grüsse

Stefan

Share this post


Link to post
Share on other sites

Guten Morgen Zusammen,

 

ich habe da mal eine Anfänger-Frage. Geht im speziellem um das UV-Light 2 Bricklet.

Ich habe gestern alles angeschlossen und Openhab2 hat das Bricklet in Rekordzeit gefunden. Das Thing habe ich über PaperUI angelegt, gleiches gilt für die 3 Items (UV-A, UV-B und UV Index) Der UV Index ist ja "Dimensenless", die Werte für UV-A und UV-B scheinen mW/m² zu sein, was die PaperUI als Intensity (W/m²) erkannt haben will.

Problem:

Ich bekomme die Werte für UVA+B nicht angezeigt, dafür eine Ellenlange Fehlermeldung in der Worte wie Eclipse, could not parse m(W/m²)...steht. Ich habe mal versucht das ganze auf Dimensenless umzustellen, passiert das gleiche. Hat einer schon mal das gleiche gehabt bzw. einen Tipp was man mal als Lösung probieren könnte ?

 

 

Share this post


Link to post
Share on other sites

dafür eine Ellenlange Fehlermeldung in der Worte wie Eclipse

 

Das hört sich fast so an als wenn du noch openHAB 2.4 nutzt. Das funktioniert leider nicht mehr mit dem brandneuen Tinkerforge Binding, du musst 2.5 Snapshot nutzen.

 

Falls das Problem dadurch nicht behoben werden sollte schau dir mal die Doku zu UoM an:

https://www.openhab.org/docs/concepts/units-of-measurement.html#units-of-measurement

Share this post


Link to post
Share on other sites

aber ob ich so mutig bin auf 2.5 snapshot umzusteigen muss ich mir erst noch überlegen

 

Die Milestone (zur Zeit M2) laufen absolut stabil. Ich persönlich habe noch nie eine Stable Version bei openHAB genutzt,

Share this post


Link to post
Share on other sites

Hallo Theo,

 

das passt ja super mit  dem neuen Snapshot Binding. Heute soll mein Pi 4 kommen, dann kann ich am Sonntag gleich das neue Pi-Hat-Brick testen.

 

Grüsse Stefan

Share this post


Link to post
Share on other sites

Hallo

 

ich freue mich zu sehen, dass die Integration weiter Fortschritte macht!

Kurze Frage: das Industrial Digital In 4 Bricklet 2.0 ist laut Doku noch nicht unterstützt, gibt es dafür eine Planung? Ich möchte das Teil zum Auslesen eines Garagentorantriebs nutzen.

 

Danke, Gruß

Andreas

Share this post


Link to post
Share on other sites

Hallo Theo

 

so habe heute damit verbracht das neue Brick-HAT zu integrieren.

Mit dem Pi 4 hatte ich noch probleme, es scheint, dass ich mit dem neuen openhabian (v1.5) permissions ändern muss. (muss das mal in aller ruhe Testen)

 

Aus dem Grund bin ich auf einem Pi 3 mit der vorletzten openhabian version

(V1.4.1) ungestiegen.

 

Soweit bekomme ich das HAT auf dem Pi 3 zum laufen. Neben dem Hat-Brick sind auch noch Masterbrick über USB angeschlossen.

Ich sehe die angeschlossenen Bricklets.

Ganz funktioniert es aber noch nicht, denn nach einem Init 6 sind jetzt 2 Bricklets (das 128x64 und ein QuadRelay V2) offline.

 

Per Rules's habe ich noch nichts getestet, muss erst mal schaun dass ich die Grund-Configuration sauber zum laufen bekomme.

 

viele Grüsse

 

Stefan

Share this post


Link to post
Share on other sites

Hallo Theo

 

leider schlechte Nachrichten. Ich habe heute sehr intensive mit dem neuen Binding (2.5.0-14) in folgender Konfiguration Test`s ausgeführt. Leider führten Restart von OpenHAB dazu dass einige Bricklets als offline angezeigt wurden.

Über einen Windows PC habe ich Remote den Brick-Viewer dazu genutzt, um zu prüfen, ob die Bricklets erreichbar sind. Im Brick-Viewer waren diese immer online.

Somit dürfte es kein Problem mit dem TF-Daemon gegeben haben.

 

Alle FT Komponenten haben den aktuellen FW Stand (01.09.2019). Auch FT-Daemon und das OS sind auf aktuellen Stand.

 

Version 1)

 

HW: Raspberry Pi 3 mit TF-Hat (Spannungsversorgung für den Pi über das TF-HAT)

OS: Openhabian Release = Raspbian GNU/Linux 10 (buster) / Kernel = Linux 4.19.66-v7+

OpenHAB: openHAB 2.5.0~S1673-1 (Build #1673) (Das Binding bekam ich nur mit der Testversion zum laufen)

 

Angeschlossene Komponenten

 

TH-Hat:

>>LCD 128x64

>>Industrial Quad Relay V2.0

>>Motion Detector V2.0

>>Humidity V2.0

>>NFC

>>Outdoor Weather

 

Master-Brick Nr1(V2.1) über USB am Pi angebunden

>>Multi Touch

>>LCD 20x4

 

Master-Brick Nr2 (V2.1) über USB am Pi angebunden

>>Ind Quad Relay V2.0

>>IO-16

>>Master-Brick Nr3 (V2.1) als Stapel auf Master-Brick Nr2

>>Humidity V2.0

>>IO-16

>>IO-16 V2

 

Nach der Installation des Bindings waren alle Bricklets unter

paperui/index.html#/inbox

sichtbar. Ich  habe alle per ADD hinzugefügt und sie waren anschließend auch unter

/paperui/index.html#/configuration/things

sichtbar.

 

Nachdem das System Item Linking auf Simple Mode eingestellt ist, waren alle Bricklets unter

paperui/index.html#/control

sichtbar und abhängig vom Binding-Entwicklungsstand auch bedienbar.

 

Nach dem ersten Durchstarten des System, waren einige Brickles als offline angezeigt.

 

Ich habe insgesamt 10x das OpenHAB System mit systemctl stop openhab2 / start durchgestartet um zu beobachten ob es immer die gleichen betrifft. (leider nein)

Siehe Tabelle1

 

Auch wenn ich über  openhab-cli console das Binding durchgestartet habe, hat sich das System ähnlich verhalten.

 

Nur wenn ich alle (offline) Brickles unter

paperui/index.html#/configuration/things

entfernte und das Openhab System neu startete, waren wieder alle Bricklets in der Inbox sichtbar und nutzbar.

 

Um aus zu schließen dass es nicht am FT-Hat lag, habe ich eine weiter Testreihe ohne das TF-Hat gestartet.

 

Version 2)

 

HW: Raspberry Pi 3 (Spannungsversorgung für den Pi über USB-Netzteil)

OS: Openhabian Release = Raspbian GNU/Linux 10 (buster) / Kernel = Linux 4.19.66-v7+

OpenHAB: openHAB 2.5.0~S1673-1 (Build #1673) (Das Binding bekam ich nur mit der Testversion zum laufen)

 

Angeschlossene Komponenten

 

Master-Brick Nr1(V2.1) über USB am Pi angebunden

>>Multi Touch

>>LCD 20x4

>>Motion Detector V2

>>LCD 128x64

 

Master-Brick Nr2 (V2.1) über USB am Pi angebunden

>>Ind Quad Relay V2.0

>>IO-16

>>Master-Brick Nr3 (V2.1) als Stapel auf Master-Brick Nr2

>>Humidity V2.0

>>IO-16

>>IO-16 V2

 

Nach der Installation des Bindings waren alle Bricklets unter

paperui/index.html#/inbox

sichtbar. Ich  habe alle per ADD hinzugefügt und sie waren anschließend auch unter

/paperui/index.html#/configuration/things

sichtbar.

 

aber auch hier waren nach einem Restart von Openhab nicht alle Bricklets online.

Hier habe ich dann 5x einen Restart ausgeführt.

siehe Tabelle 2)

 

Beim Restart des Binding über die Console (openhab-cli console ) habe ich ein paar Fehlermeldungen bekommen, ich kann mir aber nicht vorstellen dass sie die Ursache des Problem sind

 

Exception in thread "Callback-Processor" java.lang.RuntimeException: not implemented

        at org.m1theo.tinkerforge.client.devices.lcd128x64.BacklightChannel.getValue(BacklightChannel.java:110)

        at org.openhab.binding.tinkerforge.handler.LCD128x64BrickletHandler.getbacklight(LCD128x64BrickletHandler.java:1118)

        at org.openhab.binding.tinkerforge.handler.LCD128x64BrickletHandler.updateChannelStates(LCD128x64BrickletHandler.java:1063)

        at org.openhab.binding.tinkerforge.handler.LCD128x64BrickletHandler.enable(LCD128x64BrickletHandler.java:574)

        at org.openhab.binding.tinkerforge.handler.LCD128x64BrickletHandler.deviceChanged(LCD128x64BrickletHandler.java:1006)

        at org.m1theo.tinkerforge.client.impl.BrickdImpl.addDevice(BrickdImpl.java:364)

        at org.m1theo.tinkerforge.client.impl.BrickdImpl.access$100(BrickdImpl.java:24)

        at org.m1theo.tinkerforge.client.impl.BrickdImpl$EnumerateListener.enumerate(BrickdImpl.java:193)

        at com.tinkerforge.IPConnection.callEnumerateListeners(IPConnection.java:131)

        at com.tinkerforge.CallbackThread.dispatchPacket(IPConnectionBase.java:251)

        at com.tinkerforge.CallbackThread.run(IPConnectionBase.java:293)

 

Liegt es am Binding oder am OpenHAB ? Komisch ist ja nur, dass nach dem entfernen eines Bricklet aus "paperui/index.html#/configuration/things" und anschließenden restart des System die Bricklets wieder erkannt werden. Der Fehler tritt immer nur auf wenn das OS oder OpenHab neu gestartet wird.

 

Momentan weiß ich auch nicht weiter

 

viele Grüße

 

Stefan

 

P.S. der Pi 4 funktioniert, ich werde Ihn aber erst einsetzten wenn ich ein Gehäuse mit Passiver Kühlung habe.

mit-Hat.jpg.20024b38b17fcb3673178879ddc0a379.jpg

ohne-Hat.jpg.e7a55f2598a8f2d3e8f1dcfd8989da4a.jpg

Share this post


Link to post
Share on other sites

Hallo Stefan,

 

vielen Dank für das Testen! Ich vermute mal das liegt an der RuntimeException in BacklightChannel.getValue, da fehlt bisher die Implementierung. Der Fix ist in Arbeit.

 

Gruß,

Theo

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Hallo Erik,

 

das klingt gut! Vielen Dank. Wo finde ich denn den Source-code für den Generator, hier scheint er (noch) nicht zu sein?

 

Gruß,

Theo

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Ich habe noch mal eine Frage.

Mitlerweile läuft bei mir u.a. das HumidityV2 Bricklet, der MotionsensorV2 und das ParticualarMatter Bricklet. Alle drei sind Bricklets, bei denen man auch was"einstellen" kann, Beispielsweise der Heater, die LED´s oder die Laser Diode. Augenscheinlich passiert aber nix wenn man die entsprechenden Switch-Items betätigt. Nur kommt der Befehl anscheinend am Bricklet nicht an. Ich meine mich dunkel erinnern zu können das mal irgendwo Theo gesagt hat, das kommt später, habe das aber nicht mehr gefunden, kann mich eventuell jemand beleuchten ?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Hallo Theo,

 

ich hab Erik schon gefragt wie Ihr das zukünftig mit dem Binding Handhaben wollt. Momentan gibt es das von Dir gepflegte und von Tinkerforge (Erik).

 

Was ist Deine Planung ? Es geht ja nicht nur um das Binding sondern auch um einbringen in Openhab ohne immer über das Addon-Verzeichnis gehen zu müssen....

 

Grüsse Stefan

Share this post


Link to post
Share on other sites

Hallo liebe openHAB Tinkerforge Gemeinde,

 

nach mehr als 6 Jahren ist die Zeit gekommen diesen Thread zu schließen.

 

In dieser Zeit habe ich an vielen Abenden einige Stunden meiner Freizeit damit verbracht zwei openHAB Bindings für die Tinkerforge Welt zu schreiben. Das hat meistens sehr viel Spaß gemacht, war manchmal aber auch harte Arbeit.

Warum tut man sowas:

 

- wegen der tollen Tinkerforge Hard- und Software

- wegen der netten und freundlichen Tinkerforge User Gemeinde

- um openHAB weiterzuverbreiten und voranzubringen

 

Aus Sicht eines langjährigen aktiven Mitglieds der openHAB Entwicklergemeinde ist jetzt das Beste passiert was man sich wünschen kann: der Gerätehersteller programmiert selbst das openHAB-Binding für seine Hardware. Das wertet openHAB und das Binding natürlich ungemein auf. Da wird Geld in die Hand genommen um einen Entwickler zu bezahlen um einen Beitrag für ein open source Projekt zu schreiben. Super! Bei Fulltime-Entwicklung geht die Post natürlich auch ganz anders ab, als wenn man an ein paar Abenden in der Woche ein paar Stunden arbeiten kann. Das was Erik da macht ist super, besser geht es nicht. Andererseits bin ich aus Sicht des Tinkerforge Binding Entwicklers natürlich auch ein bisschen wehmütig, da mich das Projekt solange begleitet hat und ich auch ein bisschen stolz darauf bin.

 

Ich hoffe natürlich, dass Erik das Tinkerforge Binding auch in das openHAB2-addons Projekt integrieren lässt, so dass es mit den openHAB-Releases "offiziell" verfügbar ist (https://github.com/openhab/openhab2-addons).

 

Besonders bedanken möchte ich mich noch einmal für das Hardware-Sponsoring durch die Tinkerforge Macher. Bei Sigi (sihui) für die viele Arbeit an der openhab1 Tinkerforge-Binding Doku. Bei den vielen Testern! Hier im besonderen bei Stefan (StefanOHAN) für seine ausführlichen Tests und Berichte des OH2 Bindings. Bei den vielen Interessierten, die diesen Thread über die Jahre in Summe mehr als 130.000 mal gelesen haben. Das ist Tinkerunity Rekord!

 

Ich werde der Tinkerforge Gemeinde auch in Zukunft treu bleiben und die High-Level Tinkerforge Java-Bibliothek, die u.a. die Grundlage für mein openHAB 2 Binding ist, weiterentwickeln. Sobald es da etwas zu "sehen" gibt werde ich einen neuen Thread in der TinkerUnity aufmachen.

 

Natürlich werde ich auch weiterhin an openHAB mitarbeiten. In der Vergangenheit habe ich u.a. auch das InfluxDB Binding und das Linux-Packaging gemacht. Jetzt schaffe ich es hoffentlich endlich Erweiterungen für das Blukii Binding zu programmieren.

 

Bleibt openHAB und TF treu. Bis dahin,

 

Theo

Share this post


Link to post
Share on other sites

Hallo Theo,

 

auch mein ganz herzlicher Dank für Deine Arbeiten und Leistungen zu den Tinkerforge Bindings für openhab. Ich hoffe dass Du auch weiterhin mit Idee und Tips im Board aktiv bist.

 

Kleine Bitte, könntest Du Deine bisherigen Ergebnisse und Dokus im Git noch verfügbar lassen ?

 

viele Grüsse

 

Stefan

Share this post


Link to post
Share on other sites

Hallo Theo,

stellvertretend für alle OH-Nutzer (das meiste läuft über TF) in unserem Haus: Danke!!!

Anfang 2016 habe ich unser Haus mit einer größeren TF-Bestellung ein bisschen "smart" gemacht, ausschließlich weil es das 1er Binding schon gab!

Ich glaube die vielen Stunden Deiner Arbeit waren es in vielerlei Hinsicht wert, für TF, OH, den Komfort der Nutzer (jeden Tag), den Spaß beim Einbinden... Dafür nochmal Danke!!

 

 

Share this post


Link to post
Share on other sites

nach mehr als 6 Jahren ist die Zeit gekommen diesen Thread zu schließen.

 

Da schaut man mal eine Weile nicht in diesen Thread und dann sowas  :o

 

Theo, allerbesten Dank für das geniale Tinkerforge Binding, es ist mit Abstand das stabilste Binding was ich in inzwischen fast fünf Jahren openHAB genutzt habe.

Halt die Ohren steif!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...