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

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. 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 viele Grüße Stefan

Hallo Erik, danke für Deine Antwort. Das ist ja ein genialer Vorschlag, das werde ich am Wochenende gleich mal versuchen. 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

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

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

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

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

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, 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

Hallo Eric wow die neue Simple NFC Read Funktionalität mit den 3 Items ist super genial und einfach zu nutzen.👍 Funktioniert extrem flott und ohne Rule 👍 Danke :-) Ich wünsch Dir und dem Tinkerforge Team ein frohes Fest und ein gesundes neues Jahr viele Grüße Stefan

Hallo Eric, kurzes Feedback. Die Action Reset funktioniert beim LCD (was ein Punkt an der falschen Stelle für Auswirkungen haben kann). Soweit ich es bis jetzt beurteilen kann, funktionieren meine angepassten Rule mit dem neuen Binding. Einzig meine Rule für das NFC bringen noch Fehler im LOG, obwohl der TAG ausgelesen wird. Hier muss ich vermutlich die Rule komplett überarbeiten. Frage: Du schreibst Wie wird/soll dies aussehen ? Ich werde über die Feiertage meine Rules etwas entmisten und versuchen soviel als mögliche Funktionen der Bricklets zu testen. Eine Frage noch, wird eigentlich der neue V3.1 Masterbrick auch von dem neuen Binding unterstützt ? (ich hab noch keinen, daher meine Frage). Viele Grüße Stefan P.S. mein System läuft jetzt mit OpenHAB 2.5.12

Hallo Eric, danke für die schnelle Antwort. Wie es schein hat mein Openhab-Update gestern nicht so richtig funktioniert, ich bin jetzt wieder bei v 2.5.8 Ich führe gerade einen weiteren Openhab Update durch (ich hoffe nur dass ich mir jetzt das Testsystem nicht zerlege). Sobald mein System wieder verfügbar ist, werde ich den Reset Testen. viele Grüsse Stefan

Hallo Eric, ich habe dieses Wochenende mit dem testen des neuen Binding begonnen, ich bin noch nicht komplett fertig da ich noch nicht alle Rules auf die Änderungen angepasst habe. Soweit ich es bis sehe, werde alle Input-Kanäle (IO-4 / IO-16 / Dual-Button / Digital-IN / Multi Touch …) in der Thing / Configuration GUI auch mit CONTACT als Hinweis dargestellt und reagieren im LOG auch mit einer Meldung CLOSED/OPEN Um sicher zu stellen dass nicht die alte Binding Konfiguration Probleme bereitet habe ich → alle Rules deaktiviert → alle Things über die GUI gelöscht → alle Brick Daemons über die GUI gelöscht → das Binding über die openhab-cli console das Binding deinstalliert → einmal das System gebootet → den cache über openhab-cli clean-cache bereinigt → System einen init 6 ausgeführt → update des openHAB System (jetzt 2.5.12 ) ausgeführt (wird von mir nochmal geprüft) → beide neuen Binding eingefügt und THINGS mit Anpassung der Items neu angelegt. Folgendes ist mir nach dem „ERSTEN“ Start mit Rule aufgefallen → nach dem umstellen und reaktivieren der Rule die für das LCD128x64 kam beim „anpassen“ des Display Backlight mit LCD128x64_BL.sendCommand(90) folgende Fehlermeldung. Nach einem reboot erschien diese Meldung nicht mehr, und das Display funktionierte soweit. Ich hab das System jetzt mehrfach gebootet, der Fehler erschien nicht mehr. Keine Ahnung warum diese Fehlermeldung nach dem ersten Start der Rule kam. Jetzt zum eigentlichen warum ich vorab schon hier poste Ich habe Deinen Change-Log Eintrag für die Beta24 so verstanden, dass ein „soft-reset“ der Bricklets jetzt möglich ist Zitat: In Deiner OpenHab-Doku fand ich keinen Hinweis wie ich (z.B. ) für das LCD128x64 einen Reset ausführen kann. In der JAVA API Beschreibung fand ich → void BrickletLCD128x64.reset() Ich versuchte dann wie folgt einen Reset des LCD über eine Rule zu starten dies ging aber total in die Hose, folgende Fehlermeldung bekam ich Es macht auch keinen Unterschied ob ich Klein / Großschreibung nutzte. Wenn ich die Zeile „lcdActions128x64.BrickletLCD128x64.reset()“ aus kommentiere, erscheint keine Fehlermeldung. Frage: wo liegt mein Fehler ? Andere Action des Display scheinen zu funktionieren (Slider / Button / Tab ) Viele Grüße Stefan

Hallo Eric, danke für das "Weihnachtsgeschenk" :-) Ich werde gleich dieses WE mit dem Testen beginnen. Nochmal vielen Dank für Deine / Eure tolle Unterstützung Viele Grüße Stefan

Hallo Eric das hört sich für mich auch gut an. Danke viele Grüsse Stefan

Hallo Batti, danke für Deine Ausführungen. Auch wenn ich jetzt nicht darauf warten würde dass von Euch in nächster Zeit ein OH3 taugliches Binding bereit gestellt wird, würde ich jedoch bitten dass Eric das OH2 Binding finalisiert. So wie ich das in Erinnerung habe, ist da nicht mehr soviel zu tun (z.B Einbau der Soft-Reset-Funktion der Bricklets ...). Die Erfahrung aus meinem OH2 Testsystem zeigen, dass das "spezial-Binding" (Eric weiß was ich meine -> Thema Auto Check bei Betrieb von mehr als einem Brick-Dämon) bis auf ein paar Kleinigkeiten stabil läuft ( Kleinigkeit = z.B LCD128x64 funktioniert nach einer gewissen Laufzeit die TAB nicht mehr, daher auch das Soft-Reset für die Bricklets). Dies würde zumindest die Möglichkeit geben, Eure Komponenten noch "einfach" in einer OH2 Installation zu nutzen. Ich wäre mit dieser Notlösung nicht glücklich, aber man müsste nicht den komplizierten Weg über MQTT nutzen, oder gar schlimmer das Entsorgen von all den beschafften Komponenten. viele Grüße Stefan