Jump to content

Betaversion der openHAB-Bindings


rtrbt
 Share

Recommended Posts

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?

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

Edited by StefanOHAN
  • Like 1
Link to comment
Share on other sites

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

Edited by StefanOHAN
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...