openhab Integration

StefanOHAN · April 4, 2019 at 06:26

Hallo Theo,

ich komme momentan nicht weiter (LCD20x4)

Gestern habe ich den Simply-Mode deaktiviert und versucht über die WEB-GUI die Buttons0-3 mit ITEM's aus meiner "ITEMS" Datei zu verlinken.

Es wird mit dann nur angeboten

"Raw Button Toggle (System:rawbutton-toggle-Switch)

Den kann ich aber nur mit einem Switch-ITEM verlinken (habe ich auch ausgeführt). Ich sehe jedoch im Log keine Nachrichten wenn ich die Buttons betätige (auch keine Fehler Meldungen).

Das Verlinken mit dem Backlight Channel zu einem Switch-ITEM hat funktioniert und ich konnte dann auch das Backlight mit meinem Switch-ITEM ein und ausschalten.

Bei den Buttons habe ich anschließend versucht direkt die Channel mit dem ITEM zu verklinken, auch ohne Erfolg (ich habe es mit Switch und Contact versucht)

Contact TestButton0 "Testbutton 0" {channel="hier steht der Link aus Thing"}

Es kamen aber auch keine Fehlermeldungen.

Anschließend habe ich mich nochmal dem 16fach IO gewidmet. Bei meinen bisherigen Test's mit dem 16fach IO habe ich immer den "Simple-Mode" verwendet und somit keine Verlinkung mit meinen ITEMS aus der ITEMS-Datei getestet. Hier funktionierte sowohl Switch als auch Contact.

Ein Test mit abgeschalteten "Simple-Mode" einen als INPUT konfigurierten Channel zu verlinken war auch Erfolglos.

Wenn ich das Verlinken über die WEB-GUI versuche werden mir immer nur SWITCH ITEMS angeboten, auch wenn ich über "Things/Configure Channel" den Channel als INPUT deklariert habe.

Das ist für mich ein echtes Problem, da ich in meine Rules das 16-FachIO als Contact nutze.

Bei großen Konfigurationen ist die WEB-GUI-CONFIG einfach zu unübersichtlich. Wenn ich über die ITEM-Datei die Channel zuweisen kann, ist es aus meiner Sicht einfacher zu lesen ob und was ich mit einem ITEM verlinkt habe, auch wenn ich mehr Schreibarbeit habe.

Frage: (ich möchte vermeiden den Simple-Mode nutzen zu müssen)

>> Wie müsste für die Button & String Channel des LCD20x4 die richtige Channel Zuweisung in der ITEM-Datei aussehen ?

>> Wie müsste für das 16fach IO für switch und contact die richtige Channel-Zuweisung in der ITEM-Datei aussehen ?

(wenn für das 16-Fach-IO und die Button0-3 des LCD20x4 kein Contact-ITEM in der Verlinkung über die GUI sichtbar ist)

>> Wie müsste eine Tinkerforge.Things Konfiguration aussehen um diese nicht mehr über die WEB-GUI ausführen zu müssen ? (Diese Frage stellt sich nur wenn es nicht möglich ist CONTACT-ITEM entweder per Channel in der ITEM-DATEI zu verknüpfen oder ein CONTACT-ITEM über die GUI einem Input-Channel des 16-Fach IO oder Button0-3-LCD20x4 zu verlinken.

sihui · April 5, 2019 at 07:29

Wenn ich das Verlinken über die WEB-GUI versuche werden mir immer nur SWITCH ITEMS angeboten, auch wenn ich über "Things/Configure Channel" den Channel als INPUT deklariert habe.

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.

Wenn ich das Verlinken über die WEB-GUI versuche werden mir immer nur SWITCH ITEMS angeboten, auch wenn ich über "Things/Configure Channel" den Channel als INPUT deklariert habe.

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.

Wie müsste eine Tinkerforge.Things Konfiguration aussehen um diese nicht mehr über die WEB-GUI ausführen zu müssen ?

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

StefanOHAN · April 5, 2019 at 12:37

Hallo sihui

Danke für Deine Antwort.

Ich hab meine Fragestellung nachgebessert, ich saß morgens um 6:15Uhr im Zug als ich den Text schrieb.

Nein ich will nicht die Vorteile des Autodiscovery verlieren. Mir geht es nur darum, dass ich einfach die Contact-Channel (ungleich Simple-Mode) des 16-Fach-IO und des LCD20x4-Button's (hier ging es auch im Simple-Mode nicht) nicht zum laufen bekommen habe.

Auch wenn es mehr Tipp-Arbeit ist, würde ich es bevorzugen über die ITEM-Datei die Channels den passenden ITEM zu zu weisen.

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.

Zu Deiner Aussage von oben, ich will auch nicht einen ITEM CONTACT in einen ITEM SWITCH ändern, das eine ist eindeutig ein Eingang und das andere ist ein AUSGANG. Und da liegt auch das Problem, in der GUI wird mir beim 16-FACH IO immer ein AUSGANG-ITEM (Switch) angeboten auch wenn es als EINGANG konfiguriert ist. Ähnlich war es beim den Buttons des LCD20x4. Dort wir auch nur in Switch-ITEM angeboten obwohl von der Logik es doch ein INPUT (CONTACT) sein müsste.

In meiner Channel-Zuweisung in der ITEM-Datei habe ich Channel-Bezeichung aus dem GUI Kopiert und 1:1 in die Zuweisung der ITEM Datei eingefügt.

Auszug aus der ITEM-Datei
Version1
Contact LCD20x2_C0 "dummy Contact 0" (TFhw) {channel="tinkerforge:lcd20x4:f4a5fb45:vyU:button0"}

Version2
Switch LCD20x2_C0 "dummy Switch 0" (TFhw) {channel="tinkerforge:lcd20x4:f4a5fb45:vyU:button0"}

Jetzt mit dem Backlight
Switch LCD20x2_S0 "dummy Switch 0" (TFhw) {channel="tinkerforge:lcd20x4:f4a5fb45:vyU:backlight"}

bei 16-FachIO (über Configuration/Things/BrickletIO16UID nur als Input-konfiguriert)

Contact Ipuput_gpio1 "Taster-GPIO1" (TFhw) {channel=tinkerforge:io16:f4a5fb45:D8e:gpio1}

nichts hat geholfen. Ich vermute mal dass ich bei den Channel-Text was vergessen habe. Ich schau mir mal die JsonDB an ob da nicht durch die viele Test sich etwas verhakt hat (danke für den Tip)

Was mir aber noch unklar ist warum das schreiben auf das LCD20x4 nicht ging (über Rule) hier habe ich Theo's Rule für das LCD128x64 angepasst.

andiikaa · April 5, 2019 at 18:06

Hallo,

kann man ich der Entwicklung des OH2 Binding irgendwie beitragen?

Ich bin leider erst spät auf diesen Thread gestoßen und hatte in der Zwischenzeit schon ein paar neue Bricklets dem OH1 Binding hinzugefügt, da ich davon ausging, dass das OH2 Binding keine Fortschritte macht (ich war auch derjenige, welcher damals gefragt hat ).

Nun benötige ich für ein Projekt Bricklets, die scheinbar nur vom OH2 Binding unterstützt werden. Leider fehlen bei diesem wieder andere Bricklets, welche ich dem OH1 Binding hinzugefügt habe. Die in OH1 fehlenden Bricklets (LCD128x64 + OLED128x64V2) jetzt noch in das OH1 Binding hinzuzufügen, wäre ja weiter verschwendete Zeit.

Wie könnte ich jetzt aktiv Bricklets zum OH2 Binding hinzufügen?

Ich habe gesehen es existiert ein tinkerforge-client, welcher über CodeGen erzeugt wird? Wie müsste ich vorgehen? Ist das überhaupt gewünscht?

Das OH1 und OH2 Binding gleichzeitig zu verwenden ist sicher keine gute Idee, vermute ich.

Im OH2 fehlt (für mich) aktuell:

- Dual Button V2

- RGB LED Button

- NFC (mit entsprechender Dekodierung der Tags)

Diese habe ich auch schon implementiert (im OH1 Binding).

Für das NFC Bricklet habe ich das so gemacht, dass jeweils für die Tag ID, den Text Record und den Uri Record, ein Item existiert, welches (mit entsprechendem Inhalt) geupdatet wird, falls der gescannte Tag den jeweiligen Record enthält.

Gruß

André

StefanOHAN · April 6, 2019 at 19:15

Hallo andiikaa

Theo ist gerade dabei die verschieden neuen und alten Tinkerforge Bricklets in ein openhab2 taugliches Binding zu integrieren.

Anbei der Link zu Theo's Liste der aktuell unterstützen Bricklets

https://github.com/theoweiss/openhab-tinkerforge2-configuration-examples/blob/master/README.md

Die von Dir benötigten Brickles (RGB LED Button/Dual Button V2 / NFC>>noch in Arbeit) scheinen noch nicht dabei zu sein.

Das letzte Binding Update hat Theo am 28.3.2019 gepostet (dort sind die OLED enthalten).

theo
« Reply #443 on: March 28, 2019, 20:31:26 »
Ein neuer Snapshot ist da: https://bintray.com/theoweiss/generic/download_file?file_path=org.openhab.binding.tinkerforge-2.5.0-12-SNAPSHOT.jar

Ob und wie Du beim Bau des Binding helfen kannst, musst Du mit Theo abstimmen. (Diesen Monat hat er nicht so viel Zeit, da er gerade renoviert)

viele Grüsse Stefan

andiikaa · April 7, 2019 at 08:52

Danke für die Antwort.

Das entsprechende Repo habe ich schon gefunden. Ich bräuchte evtl. eine Übersicht oder Anleitung, wie generell vorzugehen ist, um neue Bricklets hinzuzufügen.

Im Github ist das (sicher auch bedingt, durch den frühen Status) nicht genauer dokumentiert (Client, Client Code-Gen, Binding).

Leider habe ich aktuell auch nicht viel Zeit, bis die Bricklets integriert sein müssen (19.4), weshalb ich mich nicht selbst in den kompletten Code von Theo einlesen kann und daher etwas "Guidance" benötige.

Falls das zeitl. bei Theo gerade nicht passt, würde ich die beiden (O)LED Displays erstmal noch in das OH1 Binding einfügen. Das wäre für mich persönlich der schnellste und einfachste Weg (leider dann mit wenig Nutzen für Andere).

Auf die Bricklets habe ich leider auch nur zeitl. begrenzten Zugriff bis ca. Ende Mai.

Viele Grüße

André

theo · April 9, 2019 at 19:56

Ich bin gerade auf meiner Hausbaustelle versumpft ich versuche am Wochenende ein bisschen Zeit für Developer Doku freizuschaufeln.

Jerome · April 9, 2019 at 20:37

Danke Theo das wäre super!

Eine Anleitung wie man ein einzelnes Bricklet ansteuert wäre auch noch super.

Das MotionDetectorBricklet V2 kriege ich nicht zum laufen...

Contact MotionSensor "Motion [MAP(en.map):%s]" <motion> { channel="tinkerforge:motiondetectorV2:bab35439:HyR:motiondetected" }

Das BarometerV2 Bricklet liefert noch einen falschen Wert bei der Höhe. Anstatt zum Beispiel 490m liefert es 4900m.

Danke für Eure Hilfe

StefanOHAN · April 17, 2019 at 05:51

Hallo Jerome,

Frage: Geht das MotionDedectorV2 Bricklet generell nicht ?

Bei mir funktioniert die "Motiondedection" des V2, ich habe es allerdings nicht als Channel sonder über das Verlinken per WebGUI (CONFIGURTION/THINKs) mit einem ITEM meiner ITEM Datei ausgeführt.

Was noch nicht funktioniert ist das schalten und dimmen der LED's. (Soweit ich weiß ist da Theo noch dran)

viele Grüsse

sihui · April 17, 2019 at 06:05

ich habe es allerdings nicht als Channel sonder über das Verlinken per WebGUI (CONFIGURTION/THINKs) mit einem ITEM meiner ITEM Datei ausgeführt.

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)

StefanOHAN · April 17, 2019 at 16:00

Hallo sihui,

ich gebe Dir recht, meine Variante ist nicht elegant (sie ist aber zum Testen schnell).

Ich hätte erwähnen sollen, dass ich dies immer nur zum Testen des Binding nutze. Wie ich einen meiner "Vorangegangen" Post schon einmal sagte, würde ich das Verlinken über Channel in der ITEM Datei bevorzugen. (Du kennst ja meinen Hilferuf bezüglich LCD20x4 und 16-Fach IO, und verlinken der Channel über die ITEM-TEXT-DATEI)

Über die autodiscover Funktion lasse ich die Komponenten suchen und anschließend das Thing über in der GUI anlegen.

Nachdem bis heute morgen noch keiner auf den Post von Jerome reagiert hatte, wollte ich eigentlich nur sagen, dass das MotionDedection V2 Modul (in Teilen) bei mir funktioniert.

Wenn Theo nach dem renovieren wieder zeit hat, würde ich Ihn daher bitten auch die Channel-Verlinkung in der ITEM-TEXT-DATEI in seiner Doku (abhängig vom TF Bricklet) nochmal kurz zu beschreibt.

Wie es auf generischer Ebene funktioniert ist mir bekannt hat auch bei einigen TF Bricklets funktioniert.

Aber daraus eine funktionierende Ableiten wie ich die Channel in der ITEM-TEXT-DATEI für die EINGÄNGE (nicht die Ausgänge) des 16-FACH-IO oder die 4 Buttons des 20x4LCD erstellen muss ist mir nicht gelungen. Eventuell hat Jerome ähnliche Probleme mit dem Motiondedector V2.

Viele Grüsse

Stefan

sihui · April 17, 2019 at 16:08

Aber daraus eine funktionierende Ableiten wie ich die Channel in der ITEM-TEXT-DATEI für die EINGÄNGE (nicht die Ausgänge) des 16-FACH-IO

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.

Jerome · April 17, 2019 at 17:12

Hallo Jerome,

Frage: Geht das MotionDedectorV2 Bricklet generell nicht ?
Bei mir funktioniert die "Motiondedection" des V2, ich habe es allerdings nicht als Channel sonder über das Verlinken per WebGUI (CONFIGURTION/THINKs) mit einem ITEM meiner ITEM Datei ausgeführt.
Was noch nicht funktioniert ist das schalten und dimmen der LED's. (Soweit ich weiß ist da Theo noch dran)

viele Grüsse

Also es läuft schon im BrickViewer, aber im Openhab macht es nicht so viel. Es wird auch nicht erwähnt in den Logs. Im Things wird es als Online angezeigt und daher denke ich es funktioniert schon aber nicht mit der Zeile die ich gesetzt habe.

Er wird als Switch angezeigt, müsste doch eher ein Contact sein, oder?

sihui · April 17, 2019 at 18:29

Er wird als Switch angezeigt, müsste doch eher ein Contact sein, oder?

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.

sihui · April 17, 2019 at 19:57

Ich rede nie vom Switch-Item sondern vom Contact-Item.

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

StefanOHAN · April 17, 2019 at 21:08

Hi Sihui,

ok verstanden, um es zu rekapitulieren, Du hast über paperui Configuration / Things / BrickletIO16 einen gpio als Input konfiguriert und dann die Verlinkung über die ITEM-TEXT-Datei durchgeführt. Habs gerade so getestet und ging.

Ich habe mich vorhin auf das Motion und den Multitouch zum testen beschränkt, den 16fach habe ich nicht mehr angefasst.

Um ehrlich zu sein, mich hat das Switch-Symbol irritiert. Ein Contact ist ein Item dass ich nicht über die Website bedienen kann, den Switch kann man aber bedienen. Was ich sagen will, auf einmal ist ein gpio Input unabhängig von seinem technischen Zustand über die Website bedienbar. Also kann man den Item-Zustand ändern (die logische Sicht) auch wenn die Technik dahinter eben nicht eine Änderung des Zustand erfahren hast. Ist das Sinnvoll ?

Spontan fällt mir ein Fensterkontakt ein. Das Fenster ist geschlossen, also hat das ITEM einen definierten Zustand (über den INPUT des GPIO), nun bediend jemand auf der Website das Switch-ITEM für den Fensterkontakt (dieser lässt sich auch vom Zustand ändern, hab es gerade getestet) und das Fenster wäre dann offen obwohl es geschlossen ist ? (müsste also eine Rule einführen die bei Zustandsänderung den realen Zustand prüft)

Es gibt aber noch immer den Effekt, dass ich über paperui/Control die Zustandsänderung des GPIO (Verbinde GPIO mit GND) und des Motiondedector (bewege Hand) sehe aber die Zustandsänderung über basicui/app eben nicht sehe, da behalten die ITEMS Ihren Zustand. An was kann das liegen ? (könnte das auch das Problem von Jerome sein ?)

(hab meinen alten Thread gelöscht um andere nicht mit meiner Fehlinterpretation zu verwirren)

sihui · April 18, 2019 at 05:01

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.

StefanOHAN · April 18, 2019 at 05:55

Guten Morgen sihui

danke für die Tip's ich werde am Oster WE eine neue TestSession inclusive einbinden in Rules (hab ich momentan nur bei einigen Bricklets ausgeführt) starten.

Viele Grüsse

Stefan

StefanOHAN · April 22, 2019 at 19:27

Hallo sihui, hallo Theo

Sihui, Du hattest recht, das Darstellungsproblem in der basicui war nach dem Neustart von Openhab2 behoben (ein Boot war nicht notwendig)

Aufgrund meiner Fehlinterpretation der letzten Tage, habe ich nochmal verschiedene Bricklets mit dem aktuellen Binding (2.5.0-12) getestet. Dieses mal nur über die Verlinkung der Channels in der ITEM-Text-Datei und das Einbinden in Rules. Als Trigger-Event in den Rules dient teilweise die Channels und teilweise die ITEM's

Die Vorgehensweise war immer die gleiche

1) Things über über die autodiscover Funktion suchen lassen

2) Things über "paperui > Configuration/Things/ konfiguriert" (soweit nötig)

3) Channels über die ITEM-TEXT-Datei mit einem passenden Item verlinkend

Ich weiß es ist wiedermal viel zu lesen, aber ich wollte Missverständnisse vermeiden.

MotionDedectorV2:

ITEM (Channel-Verlinkung über die ITEM-Text-Datei)

Switch-Item in der Item-Text-Datei mit dem (Switch) Channel verlinkt.

Bei Bewegung vor dem MotionDedector, änderte sich der ITEM-Status von OFF nach ON >> Funktion OK

Dimmer-Item in der Item-Text-Datei mit dem (Dimmer) Channel verlinkt.

Keine Funktion der LED bei betätigen des Dimmer ITEM (über basicui)

Es wird jedoch der veränderte %-Wert des ITEMS im Log und über „basicui“ angezeigt

>>2019-04-22 20:01:42.691 [nt.ItemStatePredictedEvent] - MotionDV2dr predicted to become 50<<

Rule

Version1: mit einem Item arbeiten, das über die ITEM-Text-Datei mit dem Channel verlinkt wurde >> Funktion OK

Version2: In einer Rule direkt mit dem Channel arbeiten (keine Funktion)

>>FRAGE: wie gehe ich in einer Rule mit dem Switch Channel des MotionDedectorV2 um, wenn ich den Zustand ON oder OFF auslesen will ??

when
Channel "tinkerforge:motiondetectorV2:f4a5fb45:Hz1:motiondetected" triggered [<triggerEvent>] ??
then

wie würde das Argument für das Trigger-Event lauten ?

ON/OFF und PRESSED/RELEASED haben nicht funktioniert (auch keinen Fehler im Log verursacht)

Die „Dimmer-Funktion“ der LED-ITEM's habe ich nicht mehr per Rule getestet, nachdem schon das Bedienen über die "basicui" nicht funktionierte

Multi-Touch

ITEM (Channel-Verlinkung über die ITEM-Text-Datei)

>>Switch-Item in der Item-Text-Datei mit einen den Channel(Switch) verlinken, hat funktioniert (verhält sich wie ein Switch, nicht wie ein Contact)

Rule: mit

>>when Channel "tinkerforge:multitouch:f4a5fb45:zvv:electrode0" triggered PRESSED then <<

wird eine Rule aufgerufen, funktioniert

Anmerkung zum Multi-Touch: Ich würde im Produktiv-System nur die Channel in den Rules verwenden, jedoch keine ITEM in der ITEM-Text-Datei verlinken. Diente hier nur zum Test.

16-FachIO

ITEM (hier wurde vorher über paperui / Configuration/Things/BrickletIO16 der GPIO als Input konfiguriert)

>>Switch-Item in der Item-Text-Datei mit einen der GPIO (Switch) Channel verlinkt, funktioniert

(beim Verbinden des GPIO Kontakt am Bricklet mit dem GND-Kontakt >> Änderung des Status ON/OFF)

Rule

Version1: mit einem Item arbeiten, das über die ITEM-Text-Datei mit dem GPIO-Channel verlinkt wurde >> Funktion OK

Version2: In einer Rule direkt mit dem Channel arbeiten (keine Funktion)

>>Frage: wie gehe ich in einer Rule mit einem (Switch) GPIO-Channel des des 16fach-IO um, wenn ich den Zustand ON oder OFF auslesen will (wenn dieser als INPUT konfiguriert ist) ?? Wie müsste das Channel-Argument lauten ?

when
Channel "tinkerforge:io16:f4a5fb45:D8e:gpio0" triggered [<triggerEvent>] ??
then

Generelle Frage: Wie kann ich in einer Rule den Status eines Channel‘s abfragen ?

Bei einem ITEM habe ich bisher

>>if (ITEM.state != ON)<<

dessen Status abfragen können, wie würde Status-Abfrage eines Channel aussehen ?

>>if (channel?? !=ON)<<

LCD128x64

ITEM (Channel-Verlinkung über die ITEM-Text-Datei) , je zwei Button, Slider, (TAB war mir nicht klar wie es unter paperui / Configuration/Things/ konfiguriert werden muss)

>> Slider >> ITEM-Typ Number >> über den Touchscreen können Wert des Number-ITEM verändert werden

>> Button >> ITEM-Typ Switch >> bei einmaligen betätigen kam im Log die Meldung Presses gefolgt von Released.

Das ITEM behielt auf "basicui" den Zustand ON, nach erneuten Betätigen änderte sich der ITEM-Status auf OFF (analoges Verhalten wie beim Multitouch)

Rule Teil1

Sowohl der Channel (Button) als auch der über die ITEM-Datei zu einem ITEM (Switch) verlinke Channel können als "Trigger" für die Rule eingesetzt werden.

Es wurden Button0 & Button1 & Slider0 sowie ein Text (Hello World) auf dem LCD128x64 erzeugt.

Bei betätigen der unterschiedlichen Button's konnten verschiedene Rule's ausgelöst werden

Getestete action des LCD128x64

clearDisplay (löscht nur den Text)

writeLine (schreibt einen Text)

removeAllGUI (löscht alle Button & Slider)

setGUIButton (erzeugt einen Button)

setGUISlider (erzeugt einen Slider)

setGUITabText (hier war mir nicht klar wie ich ihn unter Things konfigurieren muss, nicht getestet)

FRAGE: "Wie verändere ich die Helligkeit der Background-Beleuchtung ? Im Tinkerforge BrickViewer wird dies per Slider ausgeführt, kann es sein dass dieser noch fehlt ?

Rule Teil2

Gedanke: Sobald sich der Slider-Wert (ITEM-Typ-Number) verändert, sollte eine Rule gestartet werden, schlug aber fehl

>>"Number LCD128x64_SL0 "LCD128x4 Slid0 [%s]" (TestTF) {channel="tinkerforge:lcd128x64:f4a5fb45:HQJ:slider0" }" in ITEM-TEST-DATEI

>

>"when Item LCD128x64_SL0 changed then ..." >> in Rule

Fehlermeldung im LOG

2019-04-22 19:33:04.510 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'LCD164-Slider': An error occurred during the script execution: index=0, size=0

Die Wert-Änderung des Number-ITEM wird jedoch im LOG und auch auf der "basicui" angezeigt

>>2019-04-22 19:36:17.164 [vent.ItemStateChangedEvent] - LCD128x64_SL0 changed from 8 to 31<< Log

Frage: Wo könnte hie der Fehler liegen ?

HumidityV2

ITEM (Channel-Verlinkung über die ITEM-Text-Datei) für den Humidity-Wert (Number-Item), Temperatur-Wert (Number-Item), Heater (Switch-ITEM) war erfolgreich

Rule: Bei Änderung des Item-Number Value wurde eine Rule gestartet

" when Item HumV2H changed then..."

der Wert des Number-Item kann genutzt werden

(>> logInfo("Humv2", "Hum aenderung" + HumV2H.state ) <<)

Auch hier die Frage: Wie muss die Trigger-Bedinung lauten, dass ich eine Rule direkt über die Änderung der Channel-Werte ansteuern kann ?

>> when Channel "tinkerforge:humidityV2:f4a5fb45:Dfm:humidity" triggered [<triggerEvent>] then ..."

hier sollte auf die Änderung reagiert werden

Ich hoffe mein Wording ist soweit verständlich

Vieles hat funktioniert, bei einigem (vor allem das Nutzen von Channels als Trigger-Event funktionierte nicht immer). Ich hab zu dem Channel Trigger im Netz gesucht, aber nicht so richtig was gefunden (für die oben genannten "Unschärfen" )

viele Grüsse

Stefan

P.S.

Ich hab begonnen das LCD20x4 analog dem LCD128x64 zu testen, ich bin noch nicht fertig. Nur soweit, bis jetzt konnte ich weder einen Button nutzen, noch Text auf das Display schreiben. Einzig die Background-Beleuchtung konnte ich per Switch ein und aus schalten.

sihui · April 23, 2019 at 04:59

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.

StefanOHAN · April 23, 2019 at 06:22

Hallo sihui,

danke für Deine Antwort zum Thema Channel.

Ich hatte die Überlegung dass ich über eine Rule das Verhalten des 16-Fach-IO (als Input konfiguriert) aus openhab 1.x nachbaue. Also wenn der "Switch" (Physik des GPIO, als input konfiguiert) über die basicui / Sitemap betätigt wird, wird der Status des GPIO überprüft und nur wenn wirklich der Zustand des GPIO mit dem des Switch (auf der basicui) übereinstimmt wird dieser beibehalten, ansonsten geändert.

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

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

Ich meine wird eine Art Initialer Status übermittelt ?

Hintergrund der Frage ist das Beispiel eines Fensterkontakt.

Wenn das System gestartet wird, checke ich in der alten (1.9) Version alle Fensterkontakte und übermittle eine Nachricht auf mein Smartphone mit dem Hinweis dass das System neu gestartet wurde und ob alles Fenster geschlossen sind.

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

sihui · April 23, 2019 at 06:52

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

StefanOHAN · April 24, 2019 at 06:11

Hallo sihui

danke für Deine Antworten.

Ich habe gestern mal kurz mit dem Refresh Beispiel von dir gespielt, es erscheint im Log die Meldung (wie Du vermutet hast) dass der Import nicht mehr benutzt wird. Es kommt aber beim Aufruf in einer Rule keine weiter Fehlermeldung.

Eines konnte ich beobachten, beim starten von Openhab werden die Items die mit den GPIO's Channels des 16-Fach IO verlinkt sind, initialisiert. Das muss ich aber nochmal genauer testen.

Du hast geschrieben:

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

Ich sehe das so, ein Programm muss immer so geschrieben sein, dass eine Fehlbedienung nicht möglich ist. Auch wenn in diesem Fall der Switch als Input (Status) dient, ist er bedienbar. Ich kann sicher Items nicht in Gruppen aufnehmen und sie dadurch unsichtbar lassen, oder alles nur über die SiteMap darstellen in der ich ITEMs anders darstellen kann. Es bleibt aber nur eine "Hilfslösung".

Meine vielen Fragen und Hinweise sollen Theo als Feedback bei seiner Binding Entwicklung helfen und auch einen anderen Blickwinkel auf die Nutzbarkeit eröffnen. Jetzt besteht noch die Möglichkeit Funktionen anzupassen.

Zum Thema "Status-Abfrage". Wenn ich die Tinkerforge Komponenten über MasterExtentions (IP / RS485) kopple kann es durchaus vorkommen dass es kurzfristig zu einem Verbindungsabbruch kommt (Teste dies ja gerade mit der RS485 Extention) wenn die Spannungsversorgung an der "Remote" angebundenen Extention weg bricht. Genau für diese Situation ist es aber schon wichtig zu wissen ob ich einen Status aktiv abfragen kann oder nicht.

Die PersistenzDB hilft hier nur wenig (ist ja ein Blick in die Vergangenheit).

Du kennst ja mein Ziel "100%" Hausautomation mit Tinkerforge und Openhab2, hierzu muss ich aber mit Remote-Angebunden Master-Bricks Arbeiten und auch sowas wie "Kommunikations-Ausfälle" abfangen.

Ich würde sagen vorerst kann nur Theo sagen wie er mit diesen Punkten umgegangen ist und wie seine Sichtweise ist.

viele Grüsse

Stefan

sihui · April 24, 2019 at 06:14

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.

theo · May 5, 2019 at 19:25

Hallo Stefan, Sigi, André und Jerome,

immerhin habe ich es jetzt geschafft eure Postings zu lesen. Leider ist meine Baustelle von Entrümpeln + Streichen zu einer Kernsanierung mutiert. Daher werde ich in nächster Zeit weniger zu TF + openHAB kommen als mir lieb ist, es wird aber weiter gehen.

Ein großes Problem scheinen mir die Trigger-Channels zu sein. Diese sind eine tolle Sache, da man sich die üblichen Rules sparen kann, die z.B. einen Schalter mit einer Lampe verbinden. Die Zauberworte sind hier "Profile" und "Multichannel Linking" und "Channel Type". Die "Channel Types" die ich im Binding für TriggerChannels verwende sind soweit ich mich erinnere alles system.rawbutton. Doku und ein Beispiel zu TriggerChannels findet ihr hier: https://www.openhab.org/docs/configuration/items.html#profiles

Ein konkretes Beispiel wäre: du willst mit einem Button am LCD Bricklet dessen Backlight an/aus schalten. Dazu musst du nur ein Item für die Hintergrundbeleuchtung anlegen (nicht für den Button, das geht mit TriggerChannels gar nicht!) und in dessen Item-Konfiguration sowohl den Backlight-Channel als auch den ButtonChannel referenzieren. Dazu kommt noch eine passende "profile" Konfiguration, z.B. "rawbutton-toggle-switch". Beim Doku Link findet ihr dieses Beispiel, dass ihr einfach auf das LCD-Bricklet übertragen könnt:

Color Bedroom_Light { channel="hue:0210:1:bulb1:color", channel="serialbutton:button:mybutton:button" [profile="rawbutton-toggle-switch"] }

Gruß,

Theo

Anmelden

openhab Integration

Recommended Posts

StefanOHAN

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

theo

Posted Images

sihui

StefanOHAN

andiikaa

StefanOHAN

andiikaa

theo

Jerome

StefanOHAN

sihui

StefanOHAN

sihui

Jerome

sihui

sihui

StefanOHAN

sihui

StefanOHAN

StefanOHAN

sihui

StefanOHAN

sihui

StefanOHAN

sihui

theo

Join the conversation

theo

Umsehen

Aktivitäten