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

Hallo Eric, hallo Batti ich muss Piwo2 recht geben. Bis heute habe ich über 76 TF Brick/Bricklets/Extetions ... beschafft (allein ca. 10 Masterbrick) und einen Betrag deutlich über 1500€ investiert. Wenn ich Kabel und Zubehör mit berücksichtige, wird sich der Betrag um einige Hundert Euro erhöhen. Wenn mir klar gewesen wäre, dass TF hier nicht konsequent die Binding Entwicklung durchziehen will, hätte ich keinen Cent in mein 2tes OpenHab-Projekt mit Tinkerforge Technik investiert. Ich vermute dass ca 2/3 meiner bisherigen Ausgaben in das zweite Projekt geflossen sind (das ich bis heute noch nicht abgeschlossen habe). Wenn über MQTT aus TF Sicht Eure Module zu integrieren sind, dann hättet Ihr das bitte schon vor einem Jahr sagen sollen. Dementsprechend hätte man sich eine alternative Strategie überlegen können. Wenn ich über „Umwege“ die Komponenten ansprechen / auslesen muss, hätte ich mich nie für TF entschieden. Bitte entschuldigt diese direkten Worte, aber ganz persönlich bin ich extrem enttäuscht über diese Wendung. viele Grüße Stefan

Hallo Eric, kürzlich habe ich für das LCD 128x64 die neue Firmware eingespielt (2.0.10) leider ist das Problem mit dem Tab noch immer nicht behoben. Nach einer gewissen Zeit reagieren diese nicht mehr und nur ein Reset über den Brick Viewer schafft Abhilfe Meine Bitte wäre, wenn Du wieder Zeit hast am Binding zu arbeiten, eine Art "Rest-Funktion" mit einzubauen. Dies sollte doch möglich sein oder ? Über den Brick Viewer kann man ja einen Rest für das Bricklet ausführen. Viele Grüße Stefan

Hallo Eric, kein Problem, das ist jetzt nicht so dringend. Wenn es geht wären Beispiele für folgende Bricklets optimal - IO 16, als Input & Output - LCD 20x4 incl Button - Industrial Quadrelais - Temperatur - Humidity den Rest versuche ich mir daraus abzuleiten. Aber was anderes, ich hab noch immer das sporadisch auftretende Problem mit den Tabs des LCD128x64. Per Rule kann ich das Thing off und online zu setzten, das ändert aber nicht am Problem, meine Hoffnung war dass dies wie ein Reset wirkt. Gleichzeitig lass ich mir per lcdActions128x64.brickletLCD128x64GetSPITFPErrorCount() die Errors anzeigen, bis jetzt kam immer 0,0,0,0. Einzig ein Reset über den BrickViewer hilft. Frage: Wie kann ich den Reset auslösen ohne den Brickviewer nutzen zu müssen (per Befehl oder Openhab) ? Viele Grüße Stefan

Hallo Eric, Ich würde gerne einmal ein System mit einer tinkerforge.cfg testen und die Autoerkennung nicht nutzen. Du hast ja bereits geschrieben, dass bei Dir die Things dann immer doppelt angezeigt wurden, das stört mich aber momentan nicht. Kannst Du mir bitte bei Gelegenheit ein Muster, wie diese Datei für ein IO-16 / LCD Display aussehen müsste, zukommen lassen ? Danke im Voraus viele Grüße Stefan

Hallo Eric, danke für die schnelle Antwort. viele Grüsse

Hallo Eric, ich wollte nur am Fragen ab wann Du wieder Zeit hast das OH2 Binding zu finalisieren und dann das ganze Binding OH3 tauglich umzustellen ? viele Grüße Stefan

Hallo Eric, es war etwas unglücklich von mir formuliert, ich meinte dass sich beim berühren eines Tab die Ihm umranden Linie nach oben nicht „öffnet“ (und im Log keine Meldung erscheint, welcher Tab berührt wurde). Somit wird mit Deinen Worten die Tab-Leiste "nicht" korrekt gezeichnet, oder ? Ansonsten reagiert das Display wie erwartet, die Rules scheiben Zeichen in verschiedener Größe ... usw. Der Slider reagiert in der Form, dass der "Schieber" des Slider mit der Fingerbewegung sich an die Stelle bewegt auf dem der Finger ihn hin schiebt. Beim Betätigen des Button hab ich jetzt nicht aufgepasst ob sich optisch was ändert, der Button hat auf jedem Fall die passende Rule an getriggert. Viele Grüße Stefan

Hallo Eric, zu Deinen Fragen: Ja die Button und Slider sind mit Rule verknüpft und diese funktionieren auch. Neben den 3xTab sind auf dem „Startbildschirm“ des LCD128x64 2xButton konfiguriert. Der eine Button ruft eine Rule zum Neuaufbau des LCD-Screen auf. Dieser wird dadurch komplett gelöscht und anschließend 2xSlider konfiguriert (dies funktioniert). Die beiden Slider zeigen Ihre Rückgabewerte auf dem LCD128x64 an. Wenn die Slider von rechts nach links bewegt werden, werden die entsprechend geänderten Rückgabe-Werte am Display angezeigt. Einzig die Tabs reagieren nicht. Folgendes ist aktuell auf dem OpenHAB-System (PI3) konfiguriert: openHAB 2.5.8-1 (Release Build) 3 x OpenHAB-Tinkerforge-Dämon (Spezial-Version 23b) >> Ja es sind 3 Dämon konfiguriert Linux armhf Tinkerforge Brick-Dämon 2.4.1 (19.12.2019) Kernel = Linux 5.4.51-v7+ Der aktuelle Testaufbau sieht wie folgt aus: PI3 mit Zero-Head-Brick, hier läuft das Openhab-System PI2 mit Head-Brick sowie ein Stapel von 3xMasterbrick und 2xRS485-Extemtion die per USB angeschlossene sind. Auf dem PI2 läuft nur Linux und der Linux-Tinkerforge-Dämon, kein Openhab Masterbrick per WIFI Extention angebunden Du schreibst: Frage: Kann es sein, dass man das LCD-Thing nicht im Log sieht, da es am PI2 über ein HeadBrick angeschlossen ist (und nicht am "OpenHAB"-Pi3), und dieser PI2 über das Netzwerk mit dem zugehörigen BrickDämon auf dem "OpenhHab"-PI3 kommuniziert ? An dem PI3 (auf dem das OpenHab-System läuft) ist aktuell nur ein Zero-Brick-Head aufgesteckt an dem ein Clock-Bricklet angeschlossen ist, mehr nicht. Ich füge eine Zeichnung der Konfiguration bei, ich hoffe dass es dadurch etwas übersichtlicher wird. (siehe PDF, hier sind auch Details zu den TF-Brick-Dämon Versionen und den konfigurierten Bricklets enthalten.) Aktuell bin ich mir jetzt nicht sicher, es kann aber durchaus sein, dass die Probleme mit den LCD-Tabs erst aufgetreten sind, nachdem ich im letzten Jahr die Konfiguration auf die 2 verschiedene PI3 / PI2 aufgesplittet habe. Heute habe ich auf dem PI3 und dem PI2 einen Update des Linux-armhf-Brick-Dämon auf die neueste Version 2.4.3 ausgeführt und anschließend beide neue gebootet. Für das Linux und Openhab-System habe ich keinen Update ausgeführt. Frage: Nachdem das LCD nicht an dem PI3 mit der OpenHab-Installation angeschlossen ist, gibt es andere Log-Quellen des PI2 die Dir helfen könnten ? Hinweis: In diesem etwas kleinteiligen OpenHab Aufbau (PI3 + PI2 + WIFI-Extention) versuche ich die möglichen Grenzen auszutesten. Wenn ich mein Prod-System umstelle, wird das System wieder einfacher aufgebaut sein (die WIFI-Extention wird keine Verwendung finden, ggf. werden auch wieder alle Bricklets an dem OpenHab-Pi angeschlossen da ein P4 dafür vorgsehen ist. Beibehalten werde ich aber die RS485 Extention). viele GrüßSkizze-konfig-202101.pdfe Stefan

Hallo Eric, heute (09.02.2021) hatte ich wieder den Effekt, dass am LCD128x64 die Tab‘s nicht mehr auf Berührung reagierten. Egal welchen TAB ich berührte (es sind 3 Stück konfiguriert), es änderte sich nichts an der Darstellung auf dem Display. Beim berühren werden mit im Log die Koordinaten angezeigt aber nicht ob ein Tab berührt wurde. Die Buttons und die Slider funktionieren noch. Auch das Löschen des Display‘s per Rule funktioniert. Wie es scheint funktionieren alle anderen Rules / Bricklets. In den Log's sehe ich keine Fehlermeldung bezüglich des Display. Ich füge mal die Thread aus der Console an. Nachdem ich über den BrickViewer einen Reset für das LCD-Bricklet ausführte, funktionierten die Tabs wieder. Viele Grüße Stefan P.S. ich arbeite noch immer mit Deinem Spezial-Binding 202102210-21Uhr.txt

Hallo Erik, ja es ist noch Deine Spezial Version. Seit ich von Dir diese Version bekommen habe, habe ich das System nicht neu konfiguriert / installiert. Bisher hatte ich nur den reconnect des WIFI Dämons (hier hatte ich mit Deiner Spezial-Version keine Probleme), in der letzten Woche war aber mal das komplette Netzwerk für ein paar Stunden nicht verfügbar, da ich meine Verkabelung vom Router zu den Switchen auf LWL umgestellt habe. Das ist der einzige Unterschied der ich zur damaligen Situation hatte. viele Grüße Stefan