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!

vor 20 Stunden schrieb roben:

... und ich nicht länger auf das Update warten will

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.

vor 9 Stunden schrieb StefanOHAN:

Ein NOGO für mich wäre, wenn ich keine Rule als Text-File anlegen könnte, denn das wäre für mich ein absoluter Kontrollverlust. So wie ich das verstanden ist dies aber in Openhab3 weiterhin möglich.

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.

vor 6 Stunden schrieb StefanOHAN:

Wenn ich mein Prod-System umstelle, würde ich auch soweit als möglich auf Config-Dateien zurückgreifen und die GUI nur dann nutzen wenn es nicht anders geht

 

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.

vor 19 Stunden schrieb rtrbt:

Das wird wie gesagt aber noch etwas dauern, sorry.

Danke für die Bemühungen.

vor 2 Stunden schrieb rtrbt:

ob ich das Binding zumindest erstmal so bauen kann

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

Danke.

Am 30.9.2020 um 13:37 schrieb rtrbt:

Frage an die künftigen Nutzer (auch @StefanOHAN ) Plant ihr dann eher schnell auf openHAB 3 zu wechseln oder eher auf openHAB 2.5 zu bleiben?

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]

Am 30.9.2020 um 13:37 schrieb rtrbt:

Frage an die künftigen Nutzer (auch @StefanOHAN ) Plant ihr dann eher schnell auf openHAB 3 zu wechseln oder eher auf openHAB 2.5 zu bleiben?

openHAB3.

Am 2.10.2020 um 14:17 schrieb rtrbt:

 

Ich habe mein Produktivsystem vor einigen Wochen auf die 23. Beta des 2.5 Bindings umgestellt und keinerlei Probleme.

Besten Dank!

Am 30.9.2020 um 21:47 schrieb MiRo:

ich habe jetzt gerade wieder den Fall, dass es nicht so richtig funktioniert

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.

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.

Am 31.1.2020 um 16:00 schrieb rtrbt:

Die Remote Switch Bricklets sind jetzt deutlich einfacher benutzbar: Es gibt, ähnlich wie beim Outdoor Weather Bricklet jetzt eigene Devices für die Typ-A bis C Dosen und Typ-B Dimmer, die auf die entsprechende Adresse usw. konfiguriert werden können. Der Handler stellt dabei automatisch sicher, dass immer nur ein Schaltvorgang gleichzeitig stattfindet. Das ganze funktioniert ohne Rules schreiben zu müssen, die Actions werden aber alle weiterhin unterstützt.

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 .... 😀

Am 26.12.2019 um 17:38 schrieb sihui:

@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.

Gibt es zu dem Thema Repeats eine Lösung?

Am 19.12.2019 um 15:44 schrieb rtrbt:

Support für die Remote Switch Bricklets ist jetzt drin

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.

vor 18 Stunden schrieb rtrbt:

Funktionieren tuts ja anscheinend auch so.

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.

vor 18 Stunden schrieb rtrbt:

Versuch mal

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

vor 21 Stunden schrieb rtrbt:

Support für die Remote Switch Bricklets ist jetzt drin

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 🌲

vor 21 Stunden schrieb rtrbt:

nur die Remote Switches fehlen noch (sind aber schon implementiert, kommen mit der nächsten Beta).

Das hört sich extrem gut an, vielen Dank.

Ich werde dann spätestens mit den nächsten Beta wieder beim Testen einsteigen.

Beta 13 ist jetzt im Post oben.

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.

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 

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!

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,

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

Auch wenn in diesem Fall der Switch als Input (Status) dient, ist er bedienbar.

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.

Also wenn der "Switch" (Physik des GPIO, als input konfiguiert) über die basicui / Sitemap betätigt wird

Es ist ein Input, wieso sollte man diesen aktiv per Switch ändern?

Du musst den Switch nicht als Schalter sehen, sondern als Status.

Wenn ich das richtig verstehe, kann ich das nicht über eine Status-Abfrage des channel ausführen, oder ?

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.

Weißt Du wie sich das System beim Hochlaufen verhält ?

Ich meine wird eine Art Initialer Status übermittelt ?

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.

Ist das auch in der neuen Version möglich ? oder kann ich nur auf channel-Änderungen reagieren ?

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 hab zu dem Channel Trigger im Netz gesucht, aber nicht so richtig was gefunden (für die oben genannten "Unschärfen" )

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.

Um ehrlich zu sein, mich hat das Switch-Symbol irritiert.

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.

Es gibt aber noch immer den Effekt, dass ich über paperui/Control

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.

die Zustandsänderung über basicui/app eben nicht sehe, da behalten die ITEMS Ihren Zustand.

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.