sihui

Da TF Hardware auch in der Bucht nicht zu einem akzeptablen Preis zu verticken gewesen ist habe ich alle Bauteile als Elektroschrott entsorgt und bin auf andere Hardware umgestiegen. Jetzt ist alles wieder gut und openHAB3 läuft und läuft und läuft ... Danke TF für NICHTS!

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.

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.

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.

Danke für die Bemühungen.

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

Laut dem englischen Forum sind bereits viele Nutzer dabei auf openHAB3 umzusteigen (es gibt inzwischen einen Milestone 3), so habe ich es auch gerade getan. Leider musste ich wieder zurück auf openHAB2 da das Tinkerforge Binding nicht starten möchte. Gibt es eine grobe Timeline wann Tinkerforge openHAB3 kompatibel wird? Die beim Test verwendete Version ist die 23. Beta. 2020-11-28 12:29:48.257 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/opt/openhab/addons/org.openhab.binding.tinkerforge-2.5.6-SNAPSHOT.jar org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.tinkerforge [278] 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.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]

openHAB3.

Ich habe mein Produktivsystem vor einigen Wochen auf die 23. Beta des 2.5 Bindings umgestellt und keinerlei Probleme. Besten Dank! Wenn ich das richtig mitgelesen habe geht es hier um ein IO16 Version 1. Dieses Bricklet habe ich ebenfalls und es gibt bei mir keine Probleme damit.

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.

Gerade mit der Beta 18 und einem Remote Switch Bricklet V1 getestet: funktioniert einwandfrei. Allerbesten Dank. Dann kann ich jetzt bald mein Produktionssystem auf das neue Tinkerforge Binding umstellen .... 😀

Gibt es zu dem Thema Repeats eine Lösung?

Der Vollständigkeit halber hier jeweils ein Beispiel für Typ A und Typ B (Typ C habe ich leider nicht): rule "remoteswitch socket A" when Item Socket_A received command then val remoteActions = getActions("tinkerforge", "tinkerforge:brickletremoteswitch:master:abc") if (receivedCommand==ON) { remoteActions.brickletRemoteSwitchSwitchSocketA(12 as short, 2 as short, 1 as short) } else { remoteActions.brickletRemoteSwitchSwitchSocketA(12 as short, 2 as short, 0 as short) } end rule "remoteswitch Socket B" when Item Socket_B received command then val remoteActions = getActions("tinkerforge", "tinkerforge:brickletremoteswitch:master:abc") if (receivedCommand==ON) { remoteActions.brickletRemoteSwitchSwitchSocketB(123456, 3 as short, 1 as short) } else { remoteActions.brickletRemoteSwitchSwitchSocketB(123456, 3 as short, 0 as short) } end @rtrbt, vielen Dank! Falls du nach den Feiertagen mal ein wenig Zeit übrig hast: wie kann ich die Anzahl der Schaltwiederholungen (Repeats) erhöhen? Mein Remoteswitch Bricklet braucht immer statt 5 etwa 10 Wiederholungen um sauber zu schalten. Besten Dank.

Ja, ohne Probleme bis jetzt. Falls ich ein wenig mehr Zeit habe die nächsten Tage werde ich mal das neue Binding in meiner Produktionsumgebung einsetzen.

Jawohl, funktioniert 👍 Beim Speichern der Rule gibt es noch eine kleine Info, sonst ist aber alles paletti: 2019-12-21 07:47:45.821 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'tf.rules', using it anyway: The method brickletRemoteSwitchSwitchSocketA(ThingActions, short, short, short) from the type BrickletRemoteSwitchActions refers to the missing type Object

Perfekt, danke! Ich habe folgende Konfiguration in meiner Rule (openHAB Snapshot 3.0.0 #1780): val remoteActions = getActions("tinkerforge", "tinkerforge:brickletremoteswitch:master241:ooc") remoteActions.brickletRemoteSwitchSwitchSocketA(28, 1, 1) Housecode 28, Receivercode 1, die letzte "1" steht ja für ON. Mein Log: 2019-12-20 12:40:29.580 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'remoteswitch': An error occurred during the script execution: Cannot convert number literal to typejava.lang.Short Dies ist die Konfig für die Steckdose in der Version 1 vom Binding: rs_rcs_1000n_1.uid=ooc rs_rcs_1000n_1.subid=rcs_1000n_1 rs_rcs_1000n_1.type=remote_switch_a rs_rcs_1000n_1.houseCode=28 rs_rcs_1000n_1.receiverCode=1 Habe ich irgendetwas übersehen? Euch allen ebenfalls ein Frohes Fest und Guten Rutsch 🌲

Das hört sich extrem gut an, vielen Dank. Ich werde dann spätestens mit den nächsten Beta wieder beim Testen einsteigen.

Habe momentan leider keine Zeit zum Testen, versuche es aber nächste Woche zu schaffen. Zwei Fragen zu allgemeinen Themen habe ich aber dennoch: 1) Wie sieht es mit dem Support im Binding für ältere TF Hardware aus? Ich habe z.B. noch ein Remote Switch Bricklet V1 mit dem ich meine ganzen Baumarkt Steckdosen schalte (Weihnachten steht vor der Tür). Ich bin über TF überhaupt erst zur Hausautomation gekommen, das ist jetzt fast fünf Jahre her und es wäre schade wenn die älteren Bricklets jetzt aus dem Binding rausfallen. 2) Ist geplant das Binding in das offizielle openHAB Repository einzubringen? Auch wenn das manuelle Installieren ohne Probleme klappt, es wäre jedoch schöner wenn man das Binding über den üblichen Weg installieren könnte.

Da schaut man mal eine Weile nicht in diesen Thread und dann sowas 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!

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

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

Wie schon geschrieben: als Text Item in die Sitemap einfügen, nicht als Switch, dann ist er nicht mehr bedienbar und dient ausschließlich als Statusanzeige.

Es ist ein Input, wieso sollte man diesen aktiv per Switch ändern? Du musst den Switch nicht als Schalter sehen, sondern als Status. Ich glaube das geht nicht. Allerdings habe ich es auch noch nie versucht. Der Channel Trigger ist ein momentaner Trigger und hat eigentlich in dem Sinne keinen Status. Beim booten sind alle Zustände NULL oder UNDEF. Wenn du direkt nach dem Booten einen Status benötigst nimmt man dazu die Persistence und ein restoreOnStartup: https://www.openhab.org/docs/configuration/persistence.html#predefined-strategies Allerdings berücksichtigt das natürlich keine Änderungen des Zustandes während der Down Zeit von openHAB. Grundsätzlich funktioniert openHAB2 genauso wie openHAB1, nur die Channels sind an Things gebunden und nicht mehr an Items. Ich habe ein Update direkt nach dem Restart noch nie gebraucht (openHAB ist ja mal höchstens für 2 Minuten offline beim booten), deshalb kann ich dir nur ein paar grundsätzliche Hinweise geben: System started Trigger: https://www.openhab.org/docs/configuration/rules-dsl.html#system-based-triggers in Zusammenhang mit einer Refresh Abfrage: import org.eclipse.smarthome.core.types.RefreshType ... sendCommand(ITEM_NAME, RefreshType.REFRESH) Ob diese "org.eclipse.smarthome.core..." Imports allerdings noch in neueren Versionen von openHAB2 funktionieren weiß ich leider nicht, eventuell heißen diese jetzt wie früher "org.openhab.core..." In der englischen Community gibt es massig Beispiele um offene Fenster oder Türen anzuzeigen, eine Variante wäre: https://community.openhab.org/t/rule-to-count-open-windows/49919/8

Ich kenne bis jetzt nur zwei Bindings die das unterstützen, Amazon Dash und Astro. Ob Theo das bei jedem Bricklet eingebaut hat oder es vom Binding generell unterstützt wird kann ich nicht sagen. Zu deiner "Status"-Frage: https://www.openhab.org/docs/configuration/rules-dsl.html#channel-based-triggers Es gibt keinen fortlaufenden Status bei einem Channel Trigger. Der Trigger löst etwas aus und danach wird kein Status mehr upgedated.

In der Sitemap statt Switch item=deinSwitchItemtype einfach Text item=deinSwitchItemtype schreiben, dann ist es weg. Programmiertechnisch in den Rules ist es ja egal ob man auf OPEN/CLOSED bei einem Contact Itemtype oder ON/OFF bei einem Switch Itemtype triggert. PaperUI ist eine reine Administrationsoberfläche und nicht für den täglichen Gebrauch gedacht, vor allen Dingen nicht das Control Tab. Das sieht man schon daran das ein Item mit einem Channel verlinkt sein muss um dort angezeigt zu werden. Items an sich ohne Verlinkung erscheinen dort erst gar nicht. Das passiert manchmal und normalerweise kann man das beheben in dem man eine der folgenden Aktionen versucht: 1. openHAB neu starten 2. den Server neu starten 3. tmp und cache Ordner leeren 4. in den logs nach Fehlern suchen weil man irgendwo doch einen bisher Unentdeckten hat. Manchmal reicht schon Punkt 1. zur Behebung.