Betaversion der openHAB-Bindings

[MiRo]

Hello @rtrbt,

I was wondering why the load on my RPI was so high when I had my 4 io16_v2 bricklets added to my OH2.5.12 setup.

I wrote a small python script with your great Python-API binding and found that the callback configuration was set

```

           BrickletIO16V2.set_input_value_callback_configuration(200, false)

```

Why do you do this. I changed it to

```

           BrickletIO16V2.set_input_value_callback_configuration(200, true)

```

and now only get callbacks if something is really changing.

Can you change the binding to also only generate the callback if the status of a io16(_v2) port is changing?

[Martin]

Hallo,

kann jemand einen Link zu den OpenHAB2-Tinkerforge-Binding Beispielen posten?
Unter https://www.tinkerunity.org/topic/4909-beta-version-of-the-openhab-bindings/ und
https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html finden sich
Hinweise, aber bezugnehmend auf

Zitat

The ZIP file for the bindings contains:
[...]
in examples/ example DSL rules for some Bricks and Bricklets
[...]

finde ich weder für die dort verlinkte beta23 als auch für die neuere https://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta24.zip einen examples-Ordner.
Die Hinweise im readme_de.txt (und readme_en.txt) scheinen ähnlich zur o.g. Seite.

Schon bei der "Konfiguration" wird aber z.B. nicht beschrieben, wo die IP-Adressen der Tinkerforge-Geräte angeben werden. (Beim OpenHAB1-Binding war das die services/tinkerforge.cfg Datei und es gab keinen Bezug der IP-Adressen zu den zugehörigen Bricks/Bricklets.)

(Noch scheint das OpenHAB2-Tinkerforge-Binding (beta24) hier aber sowieso noch nicht so recht zu laufen...)

Danke,
 Martin

 

[StefanOHAN]

Hallo Erik,

ich habe jetzt meine Rule‘s angepasst und mit allen mir zur Verfügung stehenden Brickles getestet.

Der Test erfolgte auf einem neu installieren System→ openHAB 2.5.12-1. Rule / ITEM wurden alle über entsprechende Text-Dateien erstellt (nicht über die GUI).

Folgendes wurde getestet

→ anlegen des Brick-Dämon (in meiner Conf laufen wieder 3 Brick-Dämons)

• → 1x IP für WIFI-Modul
• → 1x IP für Raspi2 an dem per USB / HAT-Brick Brickles aktiv sind
• → 1x localhost Raspi3 auf dem die eigentliche Openhab Installation läuft (der Raspi3 verfügt noch über ein HAT-Zero-Brick)

→ Sichtbarkeit der Tinkerforge Things in der Paperui/inbox

→ übernehmen aus der Inbox nach paperui/configuration/things

→ Individual- Konfiguration von Things z.B Ports des IO-16 als input oder Output

→ verlinken der Channel mit ITEMS (soweit für die Channel ein Item vorgesehen ist)

→ prüfen ob Zustandsänderungen im Log angezeigt werden (z.B. Veränderung Temperatur)

→ prüfen ob Rules auf Trigger reagieren (abhängig ob als ITEM oder Channel)

Die Testkonfiguration verfügt über Masterbrick-2.1, HAT-Brick, HAT-Zero-Brick, Isolator-Bricklet, RS485-Extention, WIFI-Brick, und 25 verschiedene andere Bricklets.

Action habe ich nur für einige Bricklets getestet (LCD128x64, NFC, e-Paper, Piezo-Speaker), soweit ich es bis jetzt beurteilen kann funktioniert alles. Bei Bedarf kann ich per PN eine Tabelle der eingebunden Bricklets übermitteln (teilweise Test für die neuen & alten Bricklets z.B. IO-16 V1 oder IO-16-V2)

 

Als Addon habe ich ebenfalls folgendes getestet

• → Reset des LCD128x64 über Rule und ACTION (funktioniert)
• → Konfiguration eines Thing über die THING-Datei (für Temp-V1, Rotary-Poty, IO-16). (funktioniert) wobei mir nicht ganz klar ist, ob und wie man die einzelnen Ports des IO-16 auch über die THING Datei konfigurieren kann (analog dem OHA-V1 Binding vom Theo). Hier wäre ein Beispiel für die Port Konfig des IO-16, oder Industrial-Quadrelais hilfreich, oder einer Liste der Key-Word analog der "UID" ...
• → Ansprechen der Openhab2 Tinkerforge-Items über Openhab3 mit dem Remote-Binding. Die Kommunikation funktioniert in beide Richtungen und es können Rules auf beiden Systemen getriggert werden.

Nachdem ich die Nachricht von MiRo gelesen habe, habe ich am PI3 (Openhab2) und am PI2 (nur BrickDämon-Linux) die CPU-Last per HTOP angeschaut. Die Konfigurierten IO-16 (sind alle bis auf eines als Input konfiguriert) dort haben keine angeschlossenen Endschalter, somit Contact→Open.

Am PI3 liegt die Load bei 15-25%, am Pi2 20-40% pro Core. Zur Zeit laufen allerdings wenige Rules, daher ist dies mehr als Grundlast zu betrachten. Wie sich die Systeme bei vielen gleichzeitig aktiven Rules verhalten kann ich allerdings nicht sagen.

@Miro, I have connected my 25 Bricklets to a PI2 via Masterbrick including 2x IO16 (there is no Openhab installed). The Openhab installation is on a Raspberry PI3 and the Brick-Daemon communicate with the PI2. On the PI2 I have a load of 15-40% per core on the PI3 15-25%. 

Question: are many rules active at the same time ? (via a trigger event). My test system has only few trigger events, maybe this is the reason for this lower load.
 

@Martin,

Zitat

zu Deiner Frage : „Schon bei der "Konfiguration" wird aber z.B. nicht beschrieben, wo die IP-Adressen der Tinkerforge-Geräte angeben werden. “

Bis jetzt habe ich den Brick-Daemon nur über das Webfrontend angelegt. Für die IP des Host, an dem Deine TF Komponenten angebunden sind, gibt es in dessen Konfig-Sub-Menü ein Eingabe-Feld.

Einen Brick-Dämon über die Thing-Datei anzulegen, habe nicht getestet. Eric hatte dazu ein Beispiel gepostet. Wie weit bist Du in der Basis-Konfiguration gekommen ? Ich fahre momentan einen Mix, aus Text-File-Konfig (z.B. für die Rule und Items) und nutzen der GUI (z.B. Daemon anlegen und Things konfigurieren)

Viele meiner alten OHA-1 Rule konnte ich übernehmen, bei einigen muss ich den Rule-Trigger von ITEM auf Channel umstellen. Für die Action in Rules gibt es ein paar Beispiel für das LCD128x64 und das NFC Bricklet von Erik. 

Mein Eindruck vom aktuelle Beta ist bis jetzt sehr gut.

Viele Grüße

Stefan

bearbeitet December 30, 2021 at 18:47 von StefanOHAN

[rtrbt]

@MiRo

Please test the attached version of the bindings. For some reason "value has to change" was indeed set to true for the IO 4 2.0 and IO 16 2.0 Bricklets (and only those).

tinkerforge_openhab_bindings_2_0_0_beta24_io16fix.zip

[MiRo]

vor 5 Stunden schrieb rtrbt:

@MiRo

Please test the attached version of the bindings. For some reason "value has to change" was indeed set to true for the IO 4 2.0 and IO 16 2.0 Bricklets (and only those).

tinkerforge_openhab_bindings_2_0_0_beta24_io16fix.zip 5 MB · 0 downloads

Hello @rtrbtI will test it - when I'm home again.

Thanks for the fast solution

[StefanOHAN]

Hallo Erik,

ich habe jetzt ebenfalls das Beta24-gefixed getestet. In meiner config befinden sich u.A. 1x IO-4-V2 + 1x IO-16-V2 + 1xIO-16-V1.

Es scheint so zu sein, dass auch bei meinem System die CPU-Last jetzt geringer ist. Die Last meines PI3 liegt jetzt unter 15%.

 

@Martin, aus Interesse habe ich, analog Eriks Beispiel,  den Openhab-Thinkerforge-Dämon als Thing über die entsprechende TEXT-Thing-Datei konfiguriert  (mit localhost-IP-127.0.0.1). Das hat einwandfrei funktioniert, meine per USB am PC angeschossenen Bricks / Bricklets wurden alle erkannt. 

@Erik hast Du ein Beispiel wenn ich die verschiedenen Ports des IO-16 mal als Input mal als Output über die Thing-Datei konfigurieren möchte ? Bis jetzt habe ich es nur geschafft das IO-16 als ganzes (alle Ports als INPUT) als Thing in der Thing-Datei zu konfigurieren. (ein Eintrag analog Deines Beispiels)

viele Grüße

 

Stefan

bearbeitet January 9, 2022 at 13:52 von StefanOHAN

[rtrbt]

Moin,

Bridge tinkerforge:brickd:local [host="127.0.0.1"]

Thing tinkerforge:brickletio16v2:ioA "Meine IO16" (tinkerforge:brickd:local) [uid="ioA", pinConfiguration0=1, pinConfiguration1=0]

Funktioniert bei mir und setzt Pin 0 auf Output (Initial high) und Pin 1 auf Output (Initial low). Das interessante ist natürlich, wie man das rausbekommt. Ich bin folgendermaßen vorgegangen:

• Die Konfigurationsparameter-Namen sind in headlessCamelCase, also erster Buchstabe klein und dann immer der erste eines Wortes in groß. Typischerweise ist das einfach 1:1 der Anzeigename.
• Die Werte sind meistens selbsterklärend, kompliziert ist es bei Choice-Inputs. Um z.B. rauszubekommen, dass 0 für Output (Initial high) steht, musste ich in der Konfiguration nachschlagen. Die Konfiguration ist aber etwas unleserlich weil es im Endeffekt einfach Python mit einem großen Haufen impliziter Ableitungen ist.

Da das etwas knifflig ist, werde ich eventuell den Dokumentationsgenerator noch etwas aufbohren, damit die Konfigurationsnamen und Werte, so wie sie in die Textdateien einzutragen sind, angezeigt werden. Bei den Channels zeige ich ja auch die UIDs an.

[StefanOHAN]

Hallo Erik,

Danke für die Rückmeldung.

Ich habe gestern gleich mal mit den 4 möglichen Config Parametern für das IO-16 (V1) ein Thing über die TEXT Thing-Datei angelegt und getestet.

-> Eingang mit Pull-Up 

-> Eingang ohne Pull-Up

-> Ausgang initial high

-> Ausgang initial low

Die Ports wurden alle gemäß Definition in PaperUi dargestellt.

Für eine Test-Rules habe ich Eingang mit Pull-Up und Ausgang initial low zum testen verwendet.

Hat alles funktioniert, super, danke.

 

Viele Grüße

Stefan

[StefanOHAN]

Hallo Erik, 

ich habe in den letzten Tagen etwas mit der Option gespielt verschiedenste Bricklet über die "Thing-Datei" Anstelle über die GUI zu konfigurieren.

Das generelle anlegen in der Thing Datei hat immer geklappt.

Um auch Initial Parameter mit zu übergeben habe ich in den Generator config nachgeschaut. 

Bei allen Bricklet die ich konfiguriert fand ich verschiedene Konfigurationsparameter-Namen und dessen Typ (z.B. Integer) Die Anpassungen in der Thing-Datei wurde auch übernommen.

-> Temerpatur V1 (z.B. i2cMode)

-> Humidity V2 (z.B. sampleRate / humidityMovingAverageLength)

->LCD 20x4 (z.B. showCursor=)

->NFC (z.B. mode=) 

->DualButton (z.B rightLEDState=3)

Einzig beim Piezospeaker V2 stoße ich an meine Grenzen. Ich schaffte ich es nicht, die Initial-Konfiguration für den Beep als auch für den Alarm zu verändern. Ich vermute hier muss man man die Konfigurationsparameter-Namen, abhängig ob es um den Beep oder den Alarm handelt, noch erweitern. (ich würde hier bei beiden die Duration und Volumen ändern wollen).

Ein einfaches vorsetzten von beep oder alarm und anpassen auf headlessCamelCase hat nicht geholfen.

Hast Du für mich einen Tipp wie diese Konfigurationsparameter-Namen aussehen müssten ?

Viele Grüße

Stefan

[rtrbt]

Moin Stefan,

Ich habe kurz in der Config nachgesehen, die Parameternamen sollten wie folgt sein:

Für Beep:

• defaultFrequency
• defaultVolume
• duration

Für Alarm:

• startFrequency
• endFrequency
• stepSize
• stepDelay
• defaultVolume
• duration

Das Problem ist aber, dass das Konfigurationen der Channels, nicht des Things sind. Du musst also vermutlich den Channel von Hand definieren, wie hier: https://v2.openhab.org/docs/configuration/things.html#defining-channels dokumentiert. Mir ist da spontan nicht klar, ob du bei eigenen Channel-Typen die Konfiguration setzen kannst. Die Channeltypen sind BrickletPiezoSpeakerV2Beep bzw BrickletPiezoSpeakerV2Alarm.

[StefanOHAN]

Hallo Erik

gestern habe ich  in den verschiedenen Openhab Foren gestöbert und eigentlich sollte das übergeben von Parameter bei selbst definierten channel funktionieren. Ich hatte aber keinen Erfolg (gilt nur für den Piezo) . Das Thing mit den selbst definierten channel behält die„initial“ Parameter.

Ich gestehe aber, dass ich nicht tief genug in der Openhab-Core-Basis drin bin.

Zitat

Bridge tinkerforge:brickd:thingdateilocalhost [host="127.0.0.1"]

Thing tinkerforge:brickletpiezospeakerv2:R8y "TForge Piezo Speaker Bricklet 2.0 R8y-Thing-Datei" (tinkerforge:brickd:thingdateilocalhost) @ "pannel" [uid="R8y" , statusLEDConfig=0]  {

  Channels:

       Type BrickletPiezoSpeakerV2Beep : beep "Beep"     [defaultFrequency=125 , defaultVolume=5 , duration=1000 ]

       Type BrickletPiezoSpeakerV2Alarm : alarm "Alarm"  [defaultVolume=5 , duration=1000 ]

}

Frage: Wie erhalten die Things die Initial-Parameter, über Dein Openhab Binding oder die Pyton Konfigurations-Dateien ?

Wäre es für Dich möglich die Initial Parameter so zu ändern dass für den Piezo Speaker Volumen und Duration nicht auf den Wert 0 stehen ?

Wenn das zu aufwändig ist, ist das nicht schlimm. Die Masse meiner Bricklets kann ich über die Thing-Datei konfigurieren und Initial-Parameter anpassen. Wenn ich den Piezo über die GUI hinzufüge/konfiguriere oder nur über Aktion auf Ihn zugreife, ist das ok.

 

Eine technische Frage habe ich noch: Wenn man per Action regelmäßig (1-2 x am Tag)  einen Reset für ein Bricklet ausführt, wirkt sich dies dann negativ auf die Lebenszeit aus ? (z.B. weil beim Rekonfigurieren durch das Binding Werte in den nichtflüchtigen Speicher geschrieben werden …)

Bis jetzt läuft Dein Binding bei mir ohne Probleme, daher bin ich auch dabei die Migration meines Prodsystem vorzubereiten.

Viele Grüße

Stefan

bearbeitet February 9, 2022 at 10:58 von StefanOHAN

[riro]

zum Thema "aktuelles OpenHAB 3 Binding"

So ein Binding ist natürlich was Feines ... leicht einzurichten, viele Informationen (z.B. SensorLastUpdate usw.) usw.

Aber ich denke, mit einem GUT DOKUMENTIERTEN MQTT Binding von der Tinkerforge Seite käme man genauso weit. Auch würden dann damit auch andere (Smarthome-) Systeme klar kommen. Das ist einfach universeller.

Ich selbst habe schon unzählige Stunden mit Try&Error wegen schwacher Dokumentation, Konversion von shell und Regex System auf MQTT mit Jsonpath Transformation und dann zum OpenHAB2 Binding und jetzt mit OpenHAB3 wieder zum MQTT System verbracht. Das nervt tierisch und ich war auch schon kurz davor mich von Tinkerforge abzuwenden. (Als dann noch die Sache mit der Wallbox aufkam, dachte ich schon, das war es jetzt ...)

Ein Traum wäre es, die Wetterstation und die Sensoren (Outdoor Weather Bricklet) würden direkt verwendbare Werte (Luftdruck in mBar, Regenmenge in mm, Temperatur in C) als MQTT Payload senden. Das spart eine spätere Transformation der Werte. Eventuell sogar eigene Topics pro Wert. Schön macht das das zigbee2mqtt System, da kann man per Config einstellen, wie der Payload  (raw, json) aussieht. (Wie gut und standardisiert diese Homie Autodetect Funktion ist, weiss ich nicht). Sind wir dann nicht schon ganz nah an der Funktionnalität eines Bindings?

Traum2: dazu noch Beispiele für Openhab (wobei da gerade das Problem ist, welche Sprache für Rules verwendet werden), wie ein Item mit "LastSensorUpdate" oder "SensorOnOFFline) realisiert werden kann.

Ist das nicht weniger Aufwand und spricht gleichzeitig mehr Systeme (aus der Sicht von Tinkerforge: mehr Kunden!) an?

Ich bin mir sicher, eine gute Dokumentation, ein breit aktzeptierter Standard (MQTT) wird von Kunden schnell wahrgenommen und führt auch zu Kaufentscheidungen. Nicht ist schlimmer, als irgendwelche Hardware die nur kryptisch zu bedienen ist und auch noch nach wenigen Jahren wegen fehlendem Support oder auslaufenden Updates nur noch ausrangiert werden kann. Das ist der Weg ...

[rtrbt]

@StefanOHAN Sorry den Post hatte ich gelesen und dann vergessen zu antworten.

On 2/9/2022 at 11:56 AM, StefanOHAN said:

Wie erhalten die Things die Initial-Parameter, über Dein Openhab Binding oder die Pyton Konfigurations-Dateien ?

Sowohl als auch: Die Python-Konfigurationsdateien werden vom Generator benutzt um das openHAB-Binding zu erstellen. (Die Beta-Zip-Dateien fallen aus dem Generator raus) D.h. aus Sicht von openHAB werden die vom Binding gesetzt, das Binding "weiß" die Werte aber aus der Python-Config.

On 2/9/2022 at 11:56 AM, StefanOHAN said:

Wäre es für Dich möglich die Initial Parameter so zu ändern dass für den Piezo Speaker Volumen und Duration nicht auf den Wert 0 stehen ?

Hm man könnte da eventuel einen "Standard"-Alarm vordefinieren, ja.

Ich habe aber noch etwas anderes rausgefunden: Die PaperUI schreibt, wenn du Things hinzufügst nach [dein-openhab-ordner]/userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json. Darin kannst du die Konfigurationswerte pro Channel setzen (such mal nach brickletpiezospeakerv2).

Im Gegensatz zu den "offiziellen" Konfigurationsdateien werden Änderungen da aber nicht zur Laufzeit übernommen und eventuell schreibt PaperUI das parallel, wenn du darin rumeditierst. Du könnteste aber alle Things (oder auch nur den Piezo Speaker) über die PaperUI anlegen, konfigurieren und diese Datei als dein Text-Backup verwenden.

On 2/9/2022 at 11:56 AM, StefanOHAN said:

Eine technische Frage habe ich noch: Wenn man per Action regelmäßig (1-2 x am Tag)  einen Reset für ein Bricklet ausführt, wirkt sich dies dann negativ auf die Lebenszeit aus ? (z.B. weil beim Rekonfigurieren durch das Binding Werte in den nichtflüchtigen Speicher geschrieben werden …)

Das sollte kein Problem sein, nach einem Reset sollten höchstens Werte gelesen werden.

 

@riro

On 2/12/2022 at 1:48 PM, riro said:

Aber ich denke, mit einem GUT DOKUMENTIERTEN MQTT Binding von der Tinkerforge Seite käme man genauso weit. Auch würden dann damit auch andere (Smarthome-) Systeme klar kommen. Das ist einfach universeller.

Welche Probleme hast du denn mit der MQTT-Dokumentation? Das kann man alles verbessern, aber nur wenn man weiß wo es klemmt.

[StefanOHAN]

Hallo Erik,

danke für Deine Antwort.

vor 4 Stunden schrieb rtrbt:

Im Gegensatz zu den "offiziellen" Konfigurationsdateien werden Änderungen da aber nicht zur Laufzeit übernommen und eventuell schreibt PaperUI das parallel, wenn du darin rumeditierst. Du könnteste aber alle Things (oder auch nur den Piezo Speaker) über die PaperUI anlegen, konfigurieren und diese Datei als dein Text-Backup verwenden.

Das ist ja ein genialer Vorschlag, das werde ich am Wochenende gleich mal versuchen.

 

vor 4 Stunden schrieb rtrbt:

Hm man könnte da eventuel einen "Standard"-Alarm vordefinieren, ja

Wie gesagt wenn der Aufwand nicht all zu hoch ist, wäre das schön.

Wobei Dein Vorschlag von oben mehr Potential hat, denn mir geht es wirklich nur darum, dass ich im Recover-Fall einfach und schnell das System wieder am laufen habe (mit OH2 werden es ca 30 Bricklets sein)

 

Viele Grüße 

Stefan

bearbeitet February 15, 2022 at 15:37 von StefanOHAN

[StefanOHAN]

Hallo Erik,

Ich glaub ich hab meinen Syntax-Fehler für das Piezo-Bricklet in der Thing-Datei gefunden.

Als ich gestern Abend die Datei …./userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json

angeschaut habe, ist mir aufgefallen, dass der Name des channel-type und der Name der channel-id identisch sind.

 

Zitat

 

"channels": [
{
"acceptedItemType": "Switch",
"kind": "STATE",
"uid": {
"segments": [
"tinkerforge",
"brickletpiezospeakerv2",
"KGL",
"BrickletPiezoSpeakerV2Beep"
]

"channelTypeUID": {
"segments": [
"tinkerforge",
"BrickletPiezoSpeakerV2Beep"

 

Auf gut Glück habe ich in der Thing-Datei den Namen der channel-Id umgestellt und das System hatte (nach einem Restart) die Parameter übernommen.

Aufpassen muss man beim Channel-Type. Wenn man Parameter eines Channel (über Binding Definition) anpassen will, muss der channel-Typ der channel des Thing sein.

Nachdem das Thing schon (in der Thing-Datei) konfiguriert war, wurden die geänderten Parameter erst nach einem Restart übernommen.

Ich werde das ganz nochmal mit einem Bricklet (mit mehr als einem Channel) verifizieren, dass noch nie an meinem Migrations-System angeschlossen war (AirQuallity-Bricklet).

Das edieren in der Datei org.eclipse.smarthome.core.thing.Thing.json hat auch funktioniert, also könnte ich im Migrations-System alles über die GUI anlegen/Konfigurieren und dann einfach die Datei ins Prodsystem (mit angepassten ID’s) kopieren.

So sieht nun meine Thing-Konfiguration für den Piezo-Speaker aus

Zitat

 

Bridge tinkerforge:brickd:thingdateilocalhost [host="127.0.0.1"]

Thing tinkerforge:brickletpiezospeakerv2:R8y "TForge Piezo Speaker Bricklet 2.0 R8y-Thing-Datei" (tinkerforge:brickd:thingdateilocalhost) @ "pannel" [uid="R8y" , statusLEDConfig=0]

{  Channels:

Type  BrickletPiezoSpeakerV2Beep  :  BrickletPiezoSpeakerV2Beep     "Beep"       [ duration = 500 , defaultFrequency = 1250 , defaultVolume = 5 ]

Type  BrickletPiezoSpeakerV2Alarm :  BrickletPiezoSpeakerV2Alarm   "Alarm"       [ duration = 10000 , stepSize = 1 , endFrequency = 750 , defaultVolume = 5 , startFrequency = 125 , stepDelay = 2 ]

}

 

 

viele Grüße Stefan

 

[StefanOHAN]

Hallo Erik,

das Konfigurieren der Bricklets über die Thing-Datei incl. Parameteranpassung für Channel der Things hat wunderbar geklappt.

Für das  Humidity-V2, Piezo-V2, Air-Quallity, Rotary-Encoder-V2 habe ich dies getestet, ging ohne Probleme.

Jeder kann somit für sich entscheiden ob er Thing über die GUI anlegt oder über die Thing-Datei.

viele Grüsse

 

Stefan