rtrbt Posted May 19, 2020 at 01:59 PM Author Share Posted May 19, 2020 at 01:59 PM 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. Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted May 20, 2020 at 07:16 AM Share Posted May 20, 2020 at 07:16 AM (edited) 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 Edited May 20, 2020 at 01:00 PM by StefanOHAN Quote Link to comment Share on other sites More sharing options...
Tamino Posted May 20, 2020 at 03:32 PM Share Posted May 20, 2020 at 03:32 PM 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 Quote Link to comment Share on other sites More sharing options...
rasby Posted May 24, 2020 at 10:38 AM Share Posted May 24, 2020 at 10:38 AM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted May 25, 2020 at 01:24 PM Author Share Posted May 25, 2020 at 01:24 PM 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 Quote Link to comment Share on other sites More sharing options...
sihui Posted May 29, 2020 at 04:42 PM Share Posted May 29, 2020 at 04:42 PM 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. Quote Link to comment Share on other sites More sharing options...
Tamino Posted May 31, 2020 at 08:56 AM Share Posted May 31, 2020 at 08:56 AM 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 Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted June 1, 2020 at 07:31 PM Share Posted June 1, 2020 at 07:31 PM 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 Quote Link to comment Share on other sites More sharing options...
Tamino Posted June 3, 2020 at 07:21 AM Share Posted June 3, 2020 at 07:21 AM 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 Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted June 4, 2020 at 06:34 AM Share Posted June 4, 2020 at 06:34 AM 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 Quote Link to comment Share on other sites More sharing options...
Tamino Posted June 6, 2020 at 12:01 PM Share Posted June 6, 2020 at 12:01 PM 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 Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted June 7, 2020 at 08:59 AM Share Posted June 7, 2020 at 08:59 AM 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 Quote Link to comment Share on other sites More sharing options...
MiRo Posted June 7, 2020 at 04:12 PM Share Posted June 7, 2020 at 04:12 PM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted June 8, 2020 at 07:29 AM Author Share Posted June 8, 2020 at 07:29 AM 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 Quote Link to comment Share on other sites More sharing options...
MiRo Posted June 10, 2020 at 05:36 PM Share Posted June 10, 2020 at 05:36 PM 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. Quote Link to comment Share on other sites More sharing options...
EvenParity Posted June 20, 2020 at 06:39 AM Share Posted June 20, 2020 at 06:39 AM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted June 22, 2020 at 07:56 AM Author Share Posted June 22, 2020 at 07:56 AM 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. Quote Link to comment Share on other sites More sharing options...
EvenParity Posted June 22, 2020 at 09:48 PM Share Posted June 22, 2020 at 09:48 PM 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. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted June 23, 2020 at 07:08 AM Author Share Posted June 23, 2020 at 07:08 AM 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. Quote Link to comment Share on other sites More sharing options...
EvenParity Posted June 23, 2020 at 08:16 PM Share Posted June 23, 2020 at 08:16 PM 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. Quote Link to comment Share on other sites More sharing options...
Dainara Posted July 12, 2020 at 09:46 AM Share Posted July 12, 2020 at 09:46 AM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted July 13, 2020 at 07:11 AM Author Share Posted July 13, 2020 at 07:11 AM 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. Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted July 13, 2020 at 03:55 PM Share Posted July 13, 2020 at 03:55 PM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted July 14, 2020 at 06:47 AM Author Share Posted July 14, 2020 at 06:47 AM 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. Quote Link to comment Share on other sites More sharing options...
rwblinn Posted July 20, 2020 at 02:07 PM Share Posted July 20, 2020 at 02:07 PM 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 Quote Link to comment Share on other sites More sharing options...
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.