sihui

Mein Switch Item ist als Eingang konfiguriert, ich habe doch geschrieben es ist eine Büroklammer drin (=Taster). Büroklammer raus = Taster nicht gedrückt, Switch ist ON Büroklammer rein = Taster ist gedrückt, Switch ist OFF

Nein, hatte ich weiter unten schon mal versucht zu erklären, bitte durchlesen. Ich habe jetzt mal auf die Schnelle mein IO16 per fliegender Verdrahtung angeschlossen, hier eine Kurzanleitung: Voraussetzung: brickd ist korrekt als Thing eingerichtet, Simple Mode ist aus. IO16 autodiscovern lassen, Thing anschauen, sieht dann so aus: Den markierten Teil wie folgt in eine Items Datei kopieren: Switch IO16_A1 { channel="tinkerforge:io16:master_240:baY:gpio0" } Switch IO16_A2 { channel="tinkerforge:io16:master_240:baY:gpio1" } Switch IO16_A3 { channel="tinkerforge:io16:master_240:baY:gpio2" } Eine simple Sitemap erstellen, die Switche einfügen: sitemap tinkerforge label="Tinkerforge Testing" { Frame { Switch item=IO16_A1 Switch item=IO16_A2 Switch item=IO16_A3 } } Dann die BasicUI aufrufen (oder wenn es sein muss den Control Tab von PaperUI), dann sieht man so etwas: A1 ist mit einer Büroklammer gerade kurzgeschlossen, deshalb low, deshalb OFF. Die anderen beiden sind offen, also high, also ON. Have fun.

Ich würde mal sagen so wie bei allen anderen Channels auch: einfach aus PaperUI kopieren und in die Items Datei eintragen. Mir ist heute die Zeit weggelaufen, ich hätte eigentlich mein IO16 final anschließen wollen weil es das Digital IN ersetzen soll, vielleicht schaffe ich es morgen.

Ein sehr ungewöhnlicher Weg. Allerdings sind die Begrifflichkeiten bei beiden Varianten, egal ob GUI Konfiguration oder Text Konfiguration, identisch. Das bedeutet, auch das Anlegen einer Konfiguration über GUI ist ein "linken eines Channels mit dem Item", nicht nur die textbasierte Variante. Um das noch etwas auszuführen: die meisten User von openHAB nutzen folgende Variante bei Bindings der Version 2: Das Thing wird über GUI, z.B. PaperUI angelegt. Meistens kann es sogar nach Installation autodiscovered werden. Anschließend sieht man alle verfügbaren Channels grafisch, nun öffnet man seine Items Datei und verlinkt den ersten verfügbaren Channel dieses Things mit einem Item: itemtype itemname "labeltext [stateformat]" <iconname> (group1, group2, ...) ["tag1", "tag2", ...] {bindingconfig} Die andere einigermaßen stringente Variante: Thing per PaperUI autodiscovern, Items über GUI anlegen, mit dem Channel per GUI verlinken. Deine Variante würde ich noch mal überdenken: du legst ein Thing per GUI an, legst dann das Item über ein Textfile an und verlinkst dann den Channel über GUI mit dem Item. Die schlechteste Variante von allen ist übrigens der "Simple Mode", da man hier keinerlei weitere Kontrolle über seine Konfiguration hat und die Itemnamen zu kryptisch sind um sie vernünftig in Rules und Sitemaps verwenden zu können. Allerdings für das Testen vom Tinkerforge Binding in einer Testumgebung von openHAB ist Simple Mode ideal geeignet: mal eben schnell schauen ob es funktioniert, danach die JsonDB löschen und mit dem nächsten Snapshot in einer sauberen openHAB Installation wieder von vorne starten (mit löschen der JsonDB werden auch alle Einstellungen der GUI's gelöscht)

Zum deinem LCD kann ich nichts sagen da ich keines besitze. Mein IO16 ist zur Zeit nicht mehr angeschlossen, deshalb die grundsätzliche Vorgehensweise an einem IndustrialQuadRelay: Du nimmst die Channel Definition aus deinem Simple Mode Switch (also den Teil der über dem "Switch" steht und fügst diesen wie jeden anderen Channel in einer Items Datei ein: Switch TestSwitch { channel="tinkerforge:industrialquadrelay:brick_241:r5M:relay0" } Bei dem Wechsel von Simple Mode auf manuellen Mode musst du natürlich die ganzen automatisch verlinkten Teile mühsam wieder löschen. Ggf. ist der schnellere Weg gleich die ganze JsonDB zu löschen, vor allen Dingen dann wenn du den Simple Mode in deiner Produktivumgebung später gar nicht mehr nutzen möchtest. Du kannst in openHAB2 nicht mehr frei wählen welchen Itemtype du verwenden möchtest, das openHAB Core gibt dir das vor. Wenn also bei einem Simple Mode angelegten Itemtype Switch angeboten wird kannst du nicht auf Contact wechseln. Jedenfalls ist das bei Zwave so. Würde mich sehr wundern wenn das bei Tinkerforge anders wäre. Theo wird bestimmt etwas dazu sagen können wenn er seine Renovierung abgeschlossen hat Alternativ könntest du über Mapping (State Mapping, nicht Label Mapping) den Status ON/OFF auf OPEN/CLOSED wechseln, aber der Aufwand wäre mir zu hoch. Ich habe nicht einmal in der Doku eine Anleitung dazu gefunden, man findet aber etwas dazu im englischen Forum. Mit dem Visual Studio Code Editor ist das Anpassen der Rules doch in wenigen Sekunden erledigt. Echt? Du willst diesen genialen Vorteil des Autodiscovery von openHAB2 wieder auf die limitierte Funktion aus openHAB 1 zurückführen? Würde ich mir gut überlegen. Die meisten User wenden das wie folgt an: Thing über Autodiscovery automatisch erkennen lassen, schauen welche Channels verfügbar sind und dann in einer Items Datei die Channels mit den Item verknüpfen. Wenn du tatsächlich so viele Things hast (ich rede hier über dreistellige Zahlen) dass das zu lange dauert: die Things können auch in der JsonDB kopiert werden, man muss nur höllisch aufpassen die Klammern richtig zu setzen. https://www.openhab.org/docs/administration/jsondb.html#jsondb-storage

Ja. Am besten nimmst du den Milestone Build 1 (2.5M1 in der "testing" repo). Das ist allerdings ungewöhnlich. Denn das "Installieren" ist ja schon mit dem kopieren in den addons Ordner abgeschlossen. Ich habe bis einschl. Tinkerforge Snapshot -11 das Binding ohne Probleme mit 2.4 nutzen können, habe aber jetzt mit Snapshot -12 umgestellt auf openHAB 2.5 Snapshot.

Funktioniert weiterhin ohne Probleme Falls das auf das LCD128x64 bezogen ist kann ich dazu nichts sagen, da ich das nicht besitze. Ansonsten habe ich das Frühlings Snapshot unter 2.4 Stable getestet und es funktioniert, keine Fehler im Log. Ich werde meine Testumgebung aber jetzt auf 2.5 Snapshot umstellen, 2.4 Stable nutze ich nämlich sonst auch nicht

Mit dem neuesten Snapshot konnte ich jetzt zusätzlich mein IO16 in Betrieb nehmen. Es hängt testweise an einem Master Brick über eine WIFI Master Extension 1.0. Null Probleme, alles funktioniert. Tausend Dank, Theo.

Ja, diese von openHAB1 herrührende Variante der manuellen Konfigurationsdateien kann man nutzen, komfortabler geht es aber über das Autodiscovery. Jein. Für den reinen Channel Trigger benötigst du kein Item, geschweige denn einen Channel der darauf verlinkt ist. Ich habe leider kein Multitouch, deshalb kann ich dir kein aktuelles Beispiel liefern. Zur weiteren Erläuterung am Astro Binding: Wenn du ein Astro Thing (egal ob über Autodiscovery oder manueller Things Datei) angelegt hast, steht dir direkt der Range Event Channel als Channel Trigger zur Verfügung. Du erkennst das auch daran dass dieser Channel keinen blauen Kreis hat, sondern es ist grau hinterlegt. Man KANN es also gar nicht mit einem Item verknüpfen. Ein Item brauchst du nur anlegen, wenn du die Channels für Startzeit/Endzeit/Dauer usw. benötigst, z.b. zur Anzeige in der Sitemap. Logischerweise muss man dann auch das Item mit einem dieser Channels verknüpfen.

Diese Channel Triggers kennst du bestimmt schon vom Astro Binding, auch das Amazon Dash Button Binding nutzt diese: Hier sind noch weitere Infos dazu: https://www.openhab.org/docs/configuration/rules-dsl.html#channel-based-triggers rule "Dash button pressed" when Channel "amazondashbutton:dashbutton:ac-63-be-62-be-f5:press" triggered then logInfo("EXTRA","DASHBUTTON: The dash button has been pressed") ... end rule "Twilight" when Channel 'astro:sun:local:set#event' triggered START then logInfo("EXTRA", "DAYTIME: rule Twilight") ... end Bei der Nutzung benötigt man keine Items.

Die erste Zeile sollte so bleiben können, die zweite Zeile sollte man ersetzen durch Aufruf von openhabian-config, darüber kann man dann neu installieren. Ist aber nur angelesen, selbst genutzt habe ich openHABian noch nicht.

+1

Fachmann ist vielleicht etwas hoch gegriffen Da ich eine manuelle Installation fahre habe ich noch nicht einmal Zugriff auf die CLI ... Fakt jedoch ist: man muss nach einem Binding Wechsel im addons Folder das tmp und cache Verzeichnis löschen. Wenn ich mich nicht täusche wir das über den genannten Befehl in der CLI dann automatisch erledigt. Dies hat eine lange Zeit bei einer Development Version des Zwave Bindings zu vielen Irritationen geführt. Allerding blieb dabei der Dateiname immer gleich. Bei Theo ändert sich der Dateiname durch die angehängte Versionsnummer. Lange Rede, kurzer Sinn: die Überreste eines älteren Bindings müssen aus den temporären Verzeichnissen raus, entweder über die CLI oder manuell die Inhalte der beiden Verzeichnisse löschen. IO16 finde ich übrigens auch gut, wenn ich in meinem Bastelkarton das Teil wiederfinde wird es sofort an einen freien Port angeschlossen :-)

Fast: du findest die diversen Einstellungen im Bearbeitungsmodus des jeweiligen Channels.

Nach dem ersten Test ist das wohl eine Punktlandung, Respekt! Alle drei bis jetzt (bei mir) unterstützten Bricklets wurden sofort erkannt, alle Statuswerte werden übertragen, die Relais lassen sich schalten. Logfile ist sauber, keinerlei Fehlermeldungen. Ports lassen sich zuordnen, auch mein nicht default Port 4222 funktioniert. Ich habe mal bei den sehr geschwätzigen Luftdruckwerten die CallBack Period geändert, wird ebenfalls sauber umgesetzt. Dann können wir demnächst ja wieder ohne Sorgen Tinkerforge Produkte kaufen

Der Brick Daemon ist vereinfacht gesagt der Treiber für dein Betriebsystem wenn du den Masterbrick per USB an deinen PC anschließt. Näheres zur Installation und die verschiedenen Betriebssysteme findest du hier: https://www.tinkerforge.com/de/doc/Software/Brickd.html#brickd Um die korrekte Funktion lokal (ohne openHAB) erst einmal zu testen empfiehlt sich ebenfalls die Installation des Brick Viewers. Erst wenn du dort Daten von deinen Bricklets empfangen kannst solltest du die Einbindung in openHAB vornehmen. https://www.tinkerforge.com/de/doc/Software/Brickv.html#brickv

Hier sind meine Testergebnisse: Hardware: VirtualBox VM auf Debian 9 Software: Zulu openjdk version "1.8.0_202", openHAB Snapshot 2.4 Stable, TF Snapshot 2.5.0-7 Tinkerforge: 2 x Masterbrick mit jeweils einer Ethernet Extension im lokalen Netzwerk, Authentifizierung ausgeschaltet Nr. 1 mit 192.168.2.240:4223, angeschlossen Industrial Digital IN 4 und Industrial Quad Relay Nr. 2 mit 192.168.2.241:4222, angeschlossen Industrial Quad Relay, Barometer, Remote Switch Beide Master werden gefunden, beide sind online. Das Industrial Quad Relay am Master Nr. 1 wird autodiscovered, alle Bricklets am Master Nr. 2 nicht. Nach manuellem Hinzufügen der beiden Bricklets für Master Nr. 2 gehen beide (Industrial Quad und Barometer) Bricklets nicht online. Da Master Nr. 1 auf dem Default Port 4223 läuft, Master Nr. 2 aber auf 4222, habe ich jeweils an die IP Adresse den Port angefügt, keine Veränderung. Das temporäre Herunterfahren des Produktivsystems (mit Tinkerforge 1.x Binding) verändert das Testergebnis nicht. Ein weiterer Test mit der aktuellen openHAB Snapshot # 1512 hat zu dem gleichen Ergebnis geführt. So sieht es visuell aus:

Gute Besserung. Wenn es ans Schreiben der Doku geht ... du weißt ja

Gerade entdeckt, geilomatenmäßig, da bin ich wieder mit im Boot