Betaversion der openHAB-Bindings

[rtrbt]

Moin,

Beta 23 ist im Post oben.

DC Bricks haben jetzt Kontrollchannel und LED Strips einen Channel der konfigurierbar viele LEDs auf die selbe Farbe setzt. Die Farbe wird vom HSBType z.B. eines ColorPickers automatisch nach RGB(W) konvertiert. Die Dokumentation sollte gleich auf dem Tinkerforge-Server sein.

[StefanOHAN]

Hallo Erik

ich habe heute das neu Bindings (23) installiert. Leider kam es wieder zur gleichen Fehlermeldung für das Bricklet das ich beim HW-Umbau von WIFI-Dämon auf Dämon-USB/HAT umgestellt hatte.

Nach erneutem leeren des openhab-cache sowie 2 x System Neustart (per Init-6), war der Fehler weg.

Jetzt scheint wieder alles zu funktionieren.

Viele Grüsse

 

Stefan

bearbeitet May 20, 2020 at 13:00 von StefanOHAN

[Tamino]

Hallo Erik,

 

gute Arbeit.

Hab gestern den DC-Brick, der einen Lüfter steuert, in mein OpenHab eingebunden, funktioniert super.

Morgen werde ich mich mal an die LED-Stripes machen und berichten.

 

Schönen Feiertag

 

Alex

[rasby]

Hallo,

kurze Frage:

Bei den IO-16 Bricklets werden die Inputs ebenfalls als "Switch" angegeben. Hat das einen bestimmten Grund? Wäre "Contact" keine sauberere Lösung?

Ist es möglich die Channels direkt bei der Verlinkung zu aktualisieren? Bei mir behalten die Items solange den Wert NULL bis die Eingänge am IO16 Bricklet geändert wurden.

 

VG und schönen Sonntag

rasby

[rtrbt]

Moin,

On 5/24/2020 at 12:38 PM, rasby said:

Bei den IO-16 Bricklets werden die Inputs ebenfalls als "Switch" angegeben. Hat das einen bestimmten Grund? Wäre "Contact" keine sauberere Lösung?

Das liegt daran, dass ich eigentlich alles, was eine boolsche Variable ist auf einen Switch abbilde. Der Generator bekommt es aber nicht hin zu sehen, dass die Channel zumindest read only sein sollten. Ich gebe dir aber recht, dass Contact hier sinnvoller wäre. Setze ich mir mal auf die TODO-Liste.

On 5/24/2020 at 12:38 PM, rasby said:

Ist es möglich die Channels direkt bei der Verlinkung zu aktualisieren? Bei mir behalten die Items solange den Wert NULL bis die Eingänge am IO16 Bricklet geändert wurden.

Das funktioniert bei mir (sowohl mit der alten IO-16 als auch der 2.0). Welche openHAB und Bindings-Versionen hast du? Legst du neue Items für die Inputs an oder verlinkst du sie auf bereits existente Items? Ich sehe im Log (log:tail in der Karaf-Konsole) folgende Ausgabe, wenn ich ein neues Item anlege:

15:20:09.589 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'H5H_InputValuePin1A1-tinkerforge:brickletio16v2:H5H:BrickletIO16V2InputPin1' has been added.
15:20:09.592 [INFO ] [smarthome.event.ItemStateChangedEvent] - H5H_InputValuePin1A1 changed from NULL to ON

Gruß,
Erik

[sihui]

Am 25.5.2020 um 15:24 schrieb rtrbt:

Ich gebe dir aber recht, dass Contact hier sinnvoller wäre.

Da es nur ein UI Problem ist kann man das auch relativ einfach umgehen: einfach das Item mit Text item=meinSwitchItem aufrufen und das Problem ist gelöst.

Wenn man doch noch eine Map Transformation zur Hilfe nimmt kann man auch noch das on/off in irgendeinen beliebigen Text umwandeln.

[Tamino]

Hallo zusammen,

ich versuche einen über HDMI angeschlossenen TV mit CEC und OpenHAB zu steuern.
Ziel sollte sein mit der EXEC-Bindung und einem Switch beim triggern auf on das eine Bash-Script (tv-ein.sh) und beim triggern auf off das andere Bash-Script (tv-aus.sh) auszuführen.  
Die Rechte für den openhab Benutzer sind entsprechend gesetzt, das heißt wenn ich sudo -u openhab /etc/openhab2/scripts/tv-ein.sh usw. auf der Befehlszeile ausführe reagiert der TV auch wie erwartet. Nur über OpenHAB komme ich irgendwie nicht weiter...

Meine letzte Konfiguration:

exec.whitelist:
/etc/openhab2/scripts/tv-ein.sh
/etc/openhab2/scripts/tv-aus.sh
/etc/openhab2/scripts/tv-mute.sh
/etc/openhab2/scripts/tv-leiser.sh
/etc/openhab2/scripts/tv-lauter.sh
/etc/openhab2/scripts/tv-status.sh
/etc/openhab2/scripts/tv-%2$s.sh

things:
Thing exec:command:TVOnOff [ command="/etc/openhab2/scripts/tv-%2Ss.sh", interval=0, autorun=true, timeout=5 ]

items:
String TVOnOff {channel="exec:command:TVOnOff:input"}

sitemap:
Switch item=TVOnOff label="TV ein/aus" mappings=[ein="ein", aus="aus"]

Habe jetzt schon stundenlang sämtliche Variationen getestet, leider bisher ohne Erfolg.

Vielleicht hat von euch jemand eine Idee wie ich das besser umsetzen kann, evtl. mit einer Rule?

 

schöne Grüße 

 

Alex

[StefanOHAN]

Hallo Tamino,

Ich hatte kürzlich versucht mit dem Exec-Binding "/bin/date" aufzurufen und es funktionierte nicht (in meiner Openhab 1.9 Konfiguration funktioniert das ohne Probleme) . Ich fand dann in der Doku des EXEC-Binding den Hinweis, dass seit Openhab2 alle Befehle die über das Exec-Binding ausgeführt werden sollen, in die Datei "exec.whitelist" eintragen werden müssen.

Zitat

For security reasons all commands need to be whitelisted. Allowed commands need to be added to the misc/exec.whitelist file in the configuration directory. Every command needs to be on a separate line.

Nachdem ich die Datei "/bin/date" eingetragen hatte und einen neustart ausführte, klappte der Aufruf wieder.

Eventuell gilt dies auch für Shell-Skripte die Du über das Exec-Binding aufrufen willst.

Die Datei findest Du unter "openhab2-conf/misc/exec.whitelist"

viele Grüsse

Stefan

[Tamino]

Hallo Stefan,

 

vielen Dank für deine Hilfe!
Du hast Recht, auch oder gerade bei Shell-Skripten muss der entsprechende Befehl oder das Skript in der Whitelist eingetragen werden.
Dies habe ich aber, wie in meinem Post oben geschrieben, bereits eingetragen:

     exec.whitelist:
     /etc/openhab2/scripts/tv-ein.sh
     /etc/openhab2/scripts/tv-aus.sh
     /etc/openhab2/scripts/tv-mute.sh
     /etc/openhab2/scripts/tv-leiser.sh
     /etc/openhab2/scripts/tv-lauter.sh
     /etc/openhab2/scripts/tv-status.sh
     /etc/openhab2/scripts/tv-%2$s.sh

Noch irgendwelche andere Lösungen oder Vorschläge?

 

Gruß

 

Alex

[StefanOHAN]

Hallo Alex (Tamino)

stimmt jetzt wo ich Deine Frage nochmal genau gelesen habe, sehe ich dass du auf den Punkt mit der Whitelist schon hingewiesen hast.

Einen Vorschlag hätte ich noch, und zwar mit executeCommandLine(String commandLine)

Kannst du Du Deinen Skript auf eine Befehl reduzieren ? Eventuell kann man mit exceuteCommandLine auch ein Shell Skript aufrufen.

Die Syntax in Openhab2 scheint ähnlich zu sein wie in Openhab 1.9. Ich bin leider mit meiner Migration von Openhab1.9 auf Openhab2 noch nicht beim exexuteCommandLine angekommen und habe daher noch keine Erfahrung damit in Openhab2.

In meiner alten Openhab 1.9 Konfiguration führe ich damit einen Reboot/Shutdown aus.

So sieht mein Shutdown aus

Zitat

executeCommandLine("sudo@@/sbin/init@@0")

Die @ Zeichen anstelle der Leerzeichen waren bei mir notwendig, da ansonsten der Befehl nicht sauber ausgeführt wurde. Hierzu gibt es auch Hinweise in der Dokumentation.

Dein User hat ja schon sudo Rechte,  also  sollte es funktionieren.

Ich hatte damals Probleme zu erkennen dass die Berechtigungen / Zugriffsrechte  für den User nicht korrekt waren, da die Zugriffsberechtigung's Fehler nicht im Openhab-Log erschienen und mein Prod-OpenHab-Service einen anderen User verwendete als der User den ich nutzte wenn ich das "Test"-System über die Kommandozeile startete (also nicht als Service).

 

Viele Grüße

 

Stefan

[Tamino]

Hallo Stefan,

 

vielen Dank für deinen Support.
Ich habe das mit executeCommandLine getestet, leider ohne erfolg. 😕

Hat jemand eine Regel, mit der ich sowas umsetzen kann?

 

Grüße

 

Alex

[StefanOHAN]

Hallo Alex,

Vorschläge für  Rule's habe ich keine mehr.  Vermutlich hast Du auch schon in den System-log's nachgeschaut.

Mein Erfahrung mit Zugriffs/Berechtigung Fehler im Zusammenhang mit executeCommandline und Exec war, dass diese selten in den Openhab Logs zu finden waren sondern meist nur in den verschiedenen System log's (/var/log/ ...). Dies mir nur durch Zufall aufgefallen, als der "Openhab playSound" nicht funktionierte. Erst als ich in den verschiedenen Linux System-logs suchte, fand ich eine Fehlermeldung die mir half das Problem beseitigen. Obwohl der Openhab-User sudo-Rechte hatte fehlten Zugriffsrechte auf die Sound-Datei.

Viele Grüsse

 

Stefan

 

[MiRo]

Hallo Erik,

ich habe heute den Umstieg von Tinkerforge Binding V1 auf Dein neues Binding V2 "gewagt". Es hat alles sehr gut geklappt und alle meine Bricklets funktionieren so weit sehr gut.

Danke für dieses schöne Binding.

Ich habe gesehen, dass es im Maven Repository eine neue Version 2.1.27 gibt. In Deinem Post ist noch die Version 2.1.26 verlinkt. Ich habe aber bis jetzt kein ChangeLog/ReleaseNote gesehen für Deine Versionen.

Noch habe ich die 2.1.26, was ist denn neu in 2.1.27?

Danke Michael

[rtrbt]

Moin,

15 hours ago, MiRo said:

Es hat alles sehr gut geklappt und alle meine Bricklets funktionieren so weit sehr gut.

Das klingt gut

Die Java-Bindings 2.1.27 haben neue API für das Industrial Dual Analog In 2.0 Bricklet und das Barometer Bricklet hinzugefügt. Die openhab-Bindings benutzen die API aber noch nicht, deshalb habe ich die Abhängigkeit noch nicht aktualisiert.

Gruß,
Erik

[MiRo]

Hallo Erik,

danke.

Dann bleibe ich bei der 2.1.26. Ich habe ja auch gar kein Auto ... ich meine Analog In Bricklets.

Schönen Tag noch.

[EvenParity]

Guten Tag,

ich weiss nicht, ob ich hier off Topic bin, da ich in Sachen Openhab ein Newby bin, meine Frage sich aber auf das neue Binding bezieht.

Ich habe einen Raspi 2 Modell B mit Openhab 2.5.5-1 aufgesetzt, inzwischen schon zum 2 x weil ich dachte mit dem TF 1 Binding das Setup für das neue Binding zerorgelt zu haben. Meine Hardware besteht aus einem HAT Brick, einem Multi Touch Bricklet 2.0 und einem Analog in Bicklet 3.0 mit deinen Ich mein Wohnmobil automatisieren möchte.

In dem Verzeichnis /usr/share/openhab2/addons habe ich die Tinkerforge.jar und die tinkerforge-2.1.27.jar hinterlegt, beide mit openhab:openhab jedoch ohne execute Rechte.

Die Tinkerforge.cfg habe ich nicht angefasst, der Brickd ist installiert und zeigt mir über den Brickv von meinem Windows Rechner die Komponenten an. 
Trotzdem sehe ich über die Inbox keinerlei Binding, Items was auch immer. Ich wäre für ein wenig Hilfe sehr dankbar.

Danke und Grüße 

[rtrbt]

Moin,

Spontan sehe ich da zwei Probleme:

• Die openHAB-Bindings hängen im Moment noch von der Version 2.1.26 der Java-Bindings ab. Die 2.1.27 wird von den openHAB-Bindings ignoriert.
• Danach musst du erst über die Inbox manuell den Brick Daemon als Thing hinzufügen, danach sollten die angeschlossenen Bricks und Bricklets automatisch gefunden werden.

[EvenParity]

Moin rbrbt,

nun bin ich einen Schritt weiter, danke für deine Hilfe. Die Java Bindings habe ich auf Version 2.1.26 geändert. Gibt es einen weg zu kontrollieren, ob die Jars aus dem Addon Verzeichnis eingebunden wurden?

Den Brickd habe ich dahingehend geändert, dass er nun mit der Authentifizierung und einem Websocket Port versehen ist.

Ich verstehe jeoch noch nicht, wie ich über die Inbox manuell den Brick Daemon als Thing hinzufüge.

Bedeutet dies den Brick Daemon über eine Konfigurationsdatei manuel einzurichten oder ihn über das Plus Icon in der PaperUI einzubinden (hier sehe ich jedoch nichts, was sich einbinden läßt). Freue mich über konstruktive Hilfe.

 

[rtrbt]

Moin,

Den Websocket-Port solltest du eigentlich nicht brauchen.

Du kannst testen, ob die Jars geladen werden, indem du in der openHAB-Karaf-Konsole folgendes eingibst:

bundle:list | grep Tinkerforge

Bei mir sieht die Ausgabe dann so aus:

203 │ Active │  80 │ 2.5.3.202005191321      │ openHAB Add-ons :: Bundles :: Tinkerforge Binding
211 │ Active │  80 │ 2.1.26                  │ Tinkerforge API Bindings

Wenn das fehlt, hat openHAB die Jars aus irgendeinem Grund nicht geladen. Dann wäre es hilfreich, wenn du das openHAB-Log (die Datei logs/openhab.log im openHAB-Ordner) hier anhängst.

Du kannst auch in der PaperUI nachsehen, ob das Binding installiert ist: Dann sollte es unter Configuration->Bindings aufgeführt sein.

Wenn das alles klappt, solltest du über das Plus in der Inbox das Tinkerforge Binding und dann den Brick Daemon auswählen können. Da musst du dann für die Authentication auf Show More gehen, die Authentication aktivieren und das Passwort eingeben.

[EvenParity]

Moin rbrbt,

kaum macht mann es richtig schon funktionierts. Ich hatte das falsche Openhab Binding im Addons Verzeichnis, nach der Korrektur hat alles bestens funktioniert.

Vielen, vielen Dank für deine Hilfe.

 

[Dainara]

Huhu,

ich hatte schon mal alleds am laufen bis zum letzten Update und bis ich den Server mal komplett abgebaut habe, seit dem geht es nicht mehr, hab auch diesen Brick Deamon (UNINITIALIZED) entfernt, wollte den neu installieren aber geht nicht, der wird in der Inbox nicht mehr gefunden, in der Log Datei steht nur folgendes
 

2020-07-12 11:31:29.105 [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 [257]
  Unresolved requirement: Import-Package: org.openhab.core.automation.annotation; resolution:="optional"
  Unresolved requirement: Import-Package: com.tinkerforge; version="[2.1.0,3.0.0)"

evtl hat wer nen Rat?

 

BB

Dainara

[rtrbt]

Moin,

Die aktuelle Beta braucht neben den openHAB-Bindings auch die Java-Bindings in Version 2.1.26 (findest du hier). Die Jar kannst du einfach neben die der openHAB-Bindings selbst legen, dann sollte es funktionieren.

Gruß,
Erik

Edit: Die Java-Bindings aus der Zip und die aus den openHAB-Bindings unterscheiden sich subtil. In den openHAB-Bindings liegt die korrekte Version, die ein Maven-Bundle ist.

[StefanOHAN]

Hallo Eric,

kurze Frage das Beta-Binding ist doch noch die Version 23, oder ? Nur das Java-Binding hat die Nummer 26, oder ?

viele Grüsse

Stefan

[rtrbt]

Moin,

Das stimmt, mein Satz klingt etwas verwirrend, ich meinte "neben" im Sinne von "Im Ordner daneben liegend" nicht "neben den openHAB-Bindings Version 2.1.26....". Beta 23 ist die aktuelle openHAB-Bindings-Version.

[rwblinn]

Hallo,

erhalte den gleichen fehler wie schon gemeldet:

2020-07-20 15:52:08.462 [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 [133]

  Unresolved requirement: Import-Package: org.openhab.core.automation.annotation; resolution:="optional"

  Unresolved requirement: Import-Package: com.tinkerforge; version="[2.1.0,3.0.0)"

Im Verzeichnis \usr\share\openhab2\addons befinden sich die beiden jar Dateien:

ls /usr/share/openhab2/addons
org.openhab.binding.tinkerforge-2.5.6-SNAPSHOT.jar
tinkerforge-2.1.26.jar
[16:05:57] openhabian@openhab:~$ 

Raspberry Pi mit openhab2 version stable 2.5.6-2