StefanOHAN

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

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 ?

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 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 ?? 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 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 ? Generelle Frage: Wie kann ich in einer Rule den Status eines Channel‘s abfragen ? Bei einem ITEM habe ich bisher dessen Status abfragen können, wie würde Status-Abfrage eines Channel aussehen ? 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 > Fehlermeldung im LOG Die Wert-Änderung des Number-ITEM wird jedoch im LOG und auch auf der "basicui" angezeigt 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 Auch hier die Frage: Wie muss die Trigger-Bedinung lauten, dass ich eine Rule direkt über die Änderung der Channel-Werte ansteuern kann ? 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.

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

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)

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

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

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

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

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

Hallo Theo, gestern habe ich erste Test‘s mit dem LCD 128x64 und dem LCD20x4 gestartet. Vorerst nur auf Rule-Ebene und noch nicht über Item-Channel Zuweisungen. Zum Test mit dem LCD128x64 Ich nutzte Dein Rule-Beispiel des LCD128x64 für Button & Slider und fügte die writeLine action hinzu. Sowohl Slider als auch Button wurden dargestellt. Die Werte des Slider oder Betätigung des Button hab ich noch nicht ausgelesen. (kommt im nächsten Test) getestete action‘s: >> .setGUIButton(0, 0, 0, 60, 20, "button0") OK (erzeugt einen bedienbaren Button am Display) >> .setGUISlider(0, 30, 30, 50, 0, 0) OK (erzeugt einen bedienbaren Slider am Display) >> .writeLine (0,0, Hello) OK (schreibt Text Hello) >> .removeAllGUI() OK (löscht Slider und Button) >> .clearDisplay () OK (löscht den Text aus writeLine) Ich hab nochmal intensiv die Tinkerforge Beispiele (auf die Du verwiesen hast) angeschaut, aber nichts gefunden wie ich die Display Helligkeit verändern/ausschalten kann. (bin kein Java-Fachmann) Zum Test mit dem LCD20x4 Für diesen Test habe ich Deine Rule des LCD128x64 erneut angepasst . auf das Thing des LCD20x4 sowie den Slider und Button Befehl entfernt. Die writeLine action und Deine If-Anweisung habe ich behalten. Dies hat leider nicht Funktioniert :-( Log-Meldung: Nach entfernen der Return-Anweisung Deiner Rule, bekam ich folgende Fehlermeldung Ich hab nochmal überprüft ob ich den richtigen Chanel/Thing nutzte (der unter Thing‘s angezeigt wird). Ich fand aber den Fehler nicht. Auch mit dem Channel backlight des LCD20x4 hatte ich keinen Erfolg. Ich kann zwar über das Webfrontend das Backlight ein und ausschalten, aber ich kann das Item (über SimplyMode erzeugt) nicht in einer Rule nutzen (es wird der ITEM Name nicht erkannt). Keine Ahnung was ich da falsch mache, es ist das erste mal dass ich ein Item in einer Rule nutzte, das über den SimplyMode erstellt wurde. Auch die LCD20x4 Button0-3 konnte ich nicht nutzen. Hierzu wandelte ich meine Test-Rule des Multi-Touch ab und nutze die Channel0-3 mit Ohne Erfolg. Ich bin jetzt etwas ratlos, wie gesagt, die Trigger Rule funktioniert beim Multi-Touch aber nicht bei den LCD20x4 Button‘s Nachdem ich bisher mit Channel‘s nur indirekt gearbeitet habe, fehlt mir sicher KnowHow. Nach ca. 2 Stunden Suche in den OpenHab-Foren (Thema Channel) hab ich das ganze frustriert abgebrochen. Heute Abend werde ich die LCD20x4 Button‘s und das Backlight über das Web-Frontend mit einem Item aus meiner Item-Datei verlinken und auch versuchen in der Item-Datei direkt die Channels mit einem Item zu verlinken. Folgende Fragen stellen sich mir jetzt 1) Wie kann ich vermeiden, dass ich in den verschieden Rule‘s immer die Channel's mit deren Bezeichnung einbinden muss ? Da ich das Entwickeln der Rule's in einer eigene Landschaft ausführe, müsste ich alle Rule‘s nach dem Testen auf die UID's der Produktiv Bricklets umstellen. (In meiner OHA 1.9x Version nutze ich in den Rules nur Items) Momentan sehe ich da nur folgende Möglichkeiten (seht Ihr andere?) A) Holzhammer-Methode : Die UID‘ der Brickles in der Testumgebung per Brick-Viewer auf die UID‘s der Produktiv umstellen (gefällt mir nicht) B) Den „Button“/“SLIDER“-Channel einem passenden Contact / Switch / Number Item in der ITEM-Datei zuweisen. Für Display Action‘ einen String-Item die Channel Werte zuweisen und dann in der Rule den String einem Value übergeben (so wie in Theo‘s LCD128x64 Beispiel-Rule). 2) Wie gehe ich mit dem channels des 16-Fach IO um? Ein verlinken über die Webgui ist für das Testen ok, aber nicht wenn man große/viele Rules schreibt die dann von der Test-Konfiguration in die Produktiv-Umgebung übertragen werden. Frage: Kann ich die Channel als input oder output über die Item-Datei einem Item zuweisen ? Muss ich wie bei Openhab 1.x eine Config-Datei für Tinkerforge Komponenten anlegen (vermutlich eine Datei im Thing Verzeichnis) und wie muss diese aufgebaut sein ? Ich hoffe heute Abend mehr Erfolg zu haben. (werde aber erst nochmal Deine Links zu dem Channels nachlesen) ------------------------------------------------- ------------------------------------------------- Hallo onkelKalle hast du schon versucht das alte Binding über die openhab-cli console“ erst zu entfernen ? Ich hatte da auch schon Probleme. Nach deinstallation über die Console und anschließenden Neutstart von Openhab, hat alles funktioniert.

Hallo Theo, diese Wochenende habe ich endlich mein LCD 128x64 erhalten. Leider hatte ich am Wochenende nicht viel Zeit zum Testen und hab nur geprüft ob mit dem neuen 2.5.0-12 Binding das LCD128x64 und das LCD20x4 in der Konfiguration sichtbar sind. Beide LCD Display sind unter Things sichtbar und beim LCD20x4 konnte ich auch die Hintergrundbeleuchtung per Switch-Item ein und ausschalten. Frage: Wird beim LCD128x64 die Hintergrundbeleuchtung und der Kontrast auch per Chanel geregelt ? Ich hab in Deinen Unterlagen auf Github nichts dazu gefunden (bin kein Java Fachmann und hab in den Tinkerforge Infos hierzu nichts erkennen können). Gleich nachdem am Masterbrick die Spannung an liegt, schaltet sich die Hintergrundbeleuchtung des LCD128x64 ein. Ein Item wie beim LCD20x4 habe ich unter Things nicht gesehen. Ich hoffe mich diese Woche mit dem Chanels intensiver beschäftigen zu können, dass ich dann das Daten übertragen / auslesen der Buttons & Touchscreen Buttons der beiden LCD testen kann. Danke für das neue Binding und viele Grüsse Stefan

Hallo Theo, danke für Deine Antwort. Das mit dem NFC-Daten auslesen per Action wäre für mich absolut ok und gehört momentan auch nur zu den "nice to have" Themen. Ich hab nur mal so in blaue überlegt was man machen könnte. So heute kommt mein LCD 128x64 dann gehts mit dem testen weiter. Ich wünsche Dir auch gutes Gelingen beim Renovieren viele Grüsse Stefan

Hallo onkelKalle, wenn ich das richtig in Erinnerung habe ist das OLED noch nicht im Binding. (bin mir da aber nicht mehr sicher) Am Sonntag hat Theo ein Binding bereit gestellt im das LCD 128x64 unterstützt wird (hat mehr Funktionen). Theo hat in seinem post vom #430 am: März 21, 2019, 08:55:49 neben dem link zum neuen (Test) Binding auch Beispiele für die Nutzung des LCD in Rules eingefügt. (hilft dir aber vermutlich bei Deiner Frage nicht weiter) Hast Du in Deiner Openhab Config auch andere Tinkerforge Komponenten ?

Hallo Theo wie ich gerade lese, hat peter.boehm teilweise seinen NFC Bricklet zum laufen bekommen. (ich dachte das NFC ist noch in Arbeit) Bei mir funktioniert das auch mit dem aktuellen Binding 2.5.0-11 nicht. Mein System läuft gerade mit dem Openhab Snapshot Version 2.5.0 Build 1558 Frage: Ist das NFC-Bricklet im aktuellen Binding funktionsfähig ? Ich habe zum Testen von Tinkerforge die NFC Scheckkarte Typ2 (NTAG216) mit 888 Byte und den Anhänger Typ2 (NXP NTAG203) mit 168 Byte. Auf beide reagiert das System nicht (über den Tinkerforge Brickviewer bekomme ich aber die TAG ID's und die beschriebenen "Page"-Werte, immer 3 Byte weise) Mach ich was falsch ? Ich hab den NFC über PaperView im Simple Mode eingebunden und es, bekomme aber keine Rückgabewerte dargestellt. ----- Theo zum Thema Rückgabewerte der ausgelesenen NFC Tags hätte ich eine weitere Frage. Was hast Du geplant welche Informationen ausgelesen werden sollen ? Nur die TAG ID des NFC Chip oder auch die Werte die in den "Page's" hinterlegt sind (wenn ich den Brickviewer schaue sehe ich neben der TAG-ID auch "Page" 0-n in denen immer 3 Byte hinterlegt sind. Allerdings wäre das uncool wenn man immer 3Byte Rückmeldungen bekommt. Schöner wären 2 oder 3 Text-Items die sich auf die Bytes des Tag verteilen.) Ich bin so am überlegen ob man mit den Rückgabewerten (neben der TAG-ID auch die Werte aus den Pages 0 - n) eine Art 2-teilige Berechtigung machen könnte. Anbieten würde sich über "sha256sum" einen Hash-Rückgabe-Werte erzeugen den man nutzen kann. Spontan würde ich das wie folgt aufbauen: Die TAG-ID dient nur zum prüfen ob der TAG generell zugelassen ist. Ein Wert(Text-Item) beim Auslesen dient als User-ID, der zweite Wert (Text-Item) als Basis-Passwort mit min 12 Zeichen/Stellen. Das Basis-Passwort auf der NFC Karte in Verbindung mit einer Eingabe (z.B. über das Mulit-Touch) werden dann an sha256sum übergeben um den Passwort-Hash zu erzeugen. Diesen könnte man dann zum verifizieren nutzt um bestimmte Rules zu starten ......) viele Grüsse Stefan

Hallo Theo, ich hab heute das neue Binding eingespielt und mein openhab auf 2.5 Snapshot umgestellt. Bis jetzt laufen läuft alles das was bisher gelaufen ist. Ich werde gleich mal das 128x64 LCD Bestellen dass ich es auch testen kann. viele Grüsse Stefan

Hallo andreasOH ich habe in meiner Testumgebung das HumidityV2 im Einsatz. Zur Zeit setzte ich OpenHAB 2.4.0-1 und das org.openhab.binding.tinkerforge-2.5.0-10-SNAPSHOT ein. Ich nutze (zurzeit zwar) keine Channel sondern wie Du in deinem Zweiten Test "Simple Mode" Item Linking in der PaperUI, hab aber bis jetzt noch keine Fehler im Log gesehen (ich hab heute morgen die Log der letzten 2 Tag kurz durch gescrollt) Im log werden nur die Änderungen der Sensoren-Werte aufgelistet. Das dürfte Theo's Vermutung bestätigen dass es evlt. an der älteren OpenHab version liegt. Gruss Stefan

So sieht mein Bedienfeld aus Basis: 1x Materbrick 1x Multi-Touch 1x 20x4 LCD 1x Temperatur-Bricklet (nicht sichtbar) 1x Humidity-Bricklet (nicht sichtbar) In der 4-ten Zeile sieht man die Menue-Punkte die beim Einschalten des Display angezeigt werden. Weiter werden noch einige System Informationen, wie Innen / Außentemperatur & Luftfeuchte .... angezeigt.

Hallo Theo, hallo Tinkerforge Openhab Freunde :-) mit dem neuen Binding (16-Fach IO und dem upgrade für das RS485) läuft bei mir bis jetzt alles super :-) Ich bin gerade im Zug und hab etwas im Tinkerforge Shop gestöbert, da ist mir das LCD 128x64 Bricklet aufgefallen. Laut laut Beschreibung kann es auch 8 x 22 Zeichen darstellen (ohne den Grafikmodus zu bemühen) weiter hat es einen Touchscreen. Ich hab Dir ja in meiner Projektvorstellung schon die "Herausforderung" , ein Menue auf dem LCD 20x4 sinnvoll abzubilden, beschrieben. Es wäre natürlich einfacher wenn man 8 Zeilen hätte. Meinst du (in irgend einer späteren Version des Binding) könnte dieses neue Display auch eingebunden sein ? Ich hoffe Du bist jetzt nicht genervt von den vielen wünschen die ich laufen äußere ;-) Ich bin auf jedem Fall ein großer FAN Deiner Arbeit viele Grüsse Stefan

Hallo Theo, es freut mich dass Dir mein Projekt gefällt. Zu Deinen Fragen: Die Ports der beiden 16-Fach-IO dienen als Eingänge (elektrotechnisch) für Öffner / Schließer von Lichttastern, Fenster und Türkontakten, Schwimmerschalter … Somit kann Licht auch ohne APP oder Webbrowser ein und ausschalten … Der PTC dient zum Messen der Außentemperatur. Immer ein Humidity -Bricklet und ein „Temperatur“-Bricklet (im Gebäude der normale Temperatur -Bricklet, außerhalb ist es der PTC) liefern die Daten um die Absolute Luftfeuchte (innen und außen) zu berechnen. Meine jetzige Konfiguration hat einen Schönheitsfehler (dieser ist mir erst in der Testphase aufgefallen). Der PTC Temperatur Fühler und das Temperatur Briklet liefern teilweise Werte mit bis zu 1 Grad unterschied. In der aktuellen Version habe ich dies per Holzhammer gelöst in dem ich einen festen Offset hinterlegt habe. Ähnlich verhält es sich auch bei den Humidty Bricklets. In der V2 soll dies über eine „Kalibrierfunktion“ genauer gelöst werden. Bei Berechnung der absoluten Luftfeuchte als Basis für die Luft-Entfeuchtung Steuerung muss hier korrigierend eingegriffen werden. Menü-Funktion mit dem LCD 20x4: Ursprünglich war der Plan alle Funktionen über die 4 Tasten des LCD 20x4 zu steuern. Der erste Taster (links) des Display dient dazu um in die Menü-Hauptfunktion zu gelangen. Wenn man sich noch im Startmenü befindet erreicht man mit den restlichen 3 Tasten die wichtigsten Menüpunkte / Funktionen wie Frostschutz / Lüftung ….. Wenn man die „Menü-Taste“ betätigt gelangt man in die verschiedenen Submenüs (z.B. Alarmsystem, …..) Nachdem ich im Laufe der Entwicklung immer mehr veränderbare Variablen bedienen wollte, stieß ich an die Grenzen des LCD 20x4 mit seinen 4 Tasten. Um das ganze auch wieder besser bedienen zu können, führte ich eine direkte Menüauswahl per Nummer ein (Menü 00-13). Die Eingabe erfolgte über das Multi-Touch. Um eine „versehentliche“ Bedienung zu verhindern, muss man erst das Display mit einer der 4 Tasten des LCD 20x4 aktivieren (die Hintergrundbeleuchtung des Display dient als „boolean“ ob Eingaben des Multi-Touch genutzt werden sollen oder nicht). Für die Hintergrundbeleuchtung läuft ein Timer der sich verlängert wenn eine Taste betätigt wird. Wenn ca 20 Sekunden keine Eingabe erfolgt, wird das Display abgeschaltet und somit auch keine Eingaben des Multi-Touch mehr ausgewertet. Die 12 Channel des Multi-Touch belegen die Ziffern 0-9 und die Zeichen * und #. Zum bestätigen einer Zahlen/Zifferneingabe muss man 2 x die * - Taste betätigen. Soll das letzte Zeichen der Eingabe gelöscht werden muss 1 x die # - Tastet betätigt werden. Wenn die komplette Eingabe gelöscht werden soll, muss man 2 x die # Taste betätigen. Je nach Menü und dessen Funktion, können verschieden lange (und auch im Wert begrenze) Zahlen eingegeben werden. Beispiel : Bei Änderung der Raumtemperatur können nur 2-Stellige Werte in einer Range von 5-20 (Grad Celsius) eingegeben werden. Hingegen bei die Pin-Eingabe (System-Parameter oder Alarmsystem) kann eine bis zu 18 Stellige Zahl eingegeben werden. Randbemerkung: Bei Fehleingabe der Pin wird immer ein stiller Alarm ausgelöst Zum Thema Github: Für mich ist es das erste mal, daß ich aktiv in einem Forum „Poste“, daher möchte ich das ganze langsam angehen lassen. viele Grüsse Stefan

Hallo Theo Unter Projektvorstellungen Mit Tinkerforge und OpenHAB zum SmartHome findest Du die "Kurz" Beschreibung. Ich gehe da jetzt nicht zu sehr ins OpenHAB Detail sondern zeige nur Ur-Gedanke und Umfang auf. Für die verschiedenen Rules gibt es vieeeeeeeeeeele Gedanken und Überlegungen, das hätte den Rahmen gesprengt. Beispiel: Die Rule die für die Lüftung / Luft-Entfeuchtung zuständig ist, steuert auch Lüften per Taster&Timer oder Verhalten wenn Fenster auf. Es kann auch eine Stufe 1 und Stufe 2 der Lüftung aktiviert werden. Auch die Stellung der Lüfterklappenflügel werden darüber überwacht oder wie sich beim Lüften verhalten werden soll, wenn die Absolute Luftfeuchte durch das Lüften Ansteigt... Wenn an bestimmten Themen Interesse besteht einfach melden. P.S. das mit dem Text unter Things des 16-Fach IO ist nicht notwendig, war nur so einen Frage. Wenn ich später die Rule schreibe werde ich die Verlinkung über die Item-Datei machen (sofern das da möglich ist.) P.P.S. Ich habe über 6 Stunden den 2-Stapel (der über die RS485 Extension angebunden ist) Spannungslos gelassen. Es wurde kein Offline für dessen Bricklets unter Things angezeigt. Nach dem Einschalten der Spannungsversorgung funktionierten aber alle Komponenten.

Theo der hier unter openhab Integration seine Arbeit zur Erstellung der OpenHAB Tinkerforge Binding vorstellt, hat mich angeregt mein Tinkerforge & Openhab Projekt ebenfalls hier vorzustellen. Aufgabenstellung: Ist es möglich mit Tinkerforge Komponenten und OpenHAB ein „Smart-Home“ zu realisieren ? (JA) Nachdem ich mir nicht sicher war ob alles so funktioniert wie ich es mir vorstellte suchte ich ein Objekt an dem ich meinen Ideen umsetzen konnte. Da meine ca. 60 Jahre alten Gartenhauses dringend elektrisch modernisiert werden musste, war klar dass dies meine Smart-Home Spielwiese werden wird. Dort läuft nun seit Sommer 2016 eine Smart-Home-Steuerung die Hauptsächlich auf Tinkerforge Komponenten beruht. Vorab machte ich mir eine Anforderungsliste um eine „Materialschlacht“ zu vermeiden >> alle Leitungen müssen so verlegt sein dass bei scheitern des Projektes andere Komponenten eingesetzt werden können. >> alle Lichttaster-Leitungen werden zu einem Sammelpunkt (großer Abzweigkasten) geführt >> Beleuchtung im Gebäude und der Terrasse 12V LED >> alle Leuchten-Zuleitungen werden zu einem Sammelpunkt (großer Abzweigkasten) geführt >> alle gesteuerten 230V Verbraucher werden zu eine Sammelpunkt geführt (Verteilerkasten) >> ein 12V Netzteil (100VA, Kurzschluss Sicher, > 90% Wirkungsgrad) für Steuerung und Innenbeleuchtung um später einfacher eine USV integrieren zu können. >> separate Sicherungen für 12V Beleuchtung und Steuerung >> GANZ WICHTIG, getrennte Verteiler für 12V Steuerung und 230V Lastverbraucher !!! >> 230V Verbraucher werden über Koppelrelais 12V/ 230V angesteuert >> es dürfen keine Komponenten eingesetzt werden die einen Cloud-Zwang des Hersteller voraussetzten (ich bin kein Fan von Cloudzwang ) >> das System meldet Event von innen nach außen (kein direkter Remotezugriff von außen) >> die zur Umsetzung benötigte Technik muss energiesparend sein >> alle Basiskomponenten (z.B. Licht) müssen auch ohne App oder Browser bedienbar sein >> die verschiedenen Komponenten sollen Event abhängig gesteuert werden (z.B. Gartenlicht schaltet sich ein wenn es dunkel ist und das Gebäude abgeschlossen wird, gleichzeitig sollen alle nicht mehr benötigten Verbraucher abschalten werden) Lösung: - Steuerrechner = Pi 3 - Netzwerk&Internetzugang = AVM 7390 - Technische Schnittstelle zur Smart-Home-Software & Pi = Tinkerforge (siehe Komponentenliste) - Smart-Home Software = OpenHAB 1.9 - Kommunikation nach außen Telegram-App & Mail (beides sind Funktionen die per Binding in OpenHAB eingebunden werden können) Tinkerforge Stückliste: 1 x Industrial Digital In 4 Bricklet 5 x Industrial Quad Relay Bricklet 2 x IO-16 Bricklet 1 x LCD 20x4 Bricklet 1 x Temperature Bricklet 2 x Humidity Bricklet 1 x PTC Bricklet 1 x Multi Touch Bricklet 1 x Motion Detector Bricklet 2 x Dual Relay Bricklet 6 x Master Brick 1 x Step-Down Power Supply Veränderung zum Ursprünglichen Konzept Während der frühen Produktivphase kam es zu einigen Problemen, daher wurde noch im Sommer 2016 einige Anpassungen durchgeführt. 1) trennen der Spannungsversorgung von Steuerung (PI & Tinkerforge), Innenlicht & Koppelrelais auf 1x20VA Netzteil für Steuerung und PI, und 1x100VA Netzteil für Beleuchtung & Koppelrelais. 2) Austausch der Feinsicherungen der 12V Beleuchtung durch Sicherungsautomaten (spezielle Bauform für Verteiler Aufreihklemmen 12V) Ursprünglicher Funktionsumfang der Smart-Steuerung (OpenHAB) 1) Steuerung aller Leuchten innerhalb und außerhalb des Gebäude (im Gebäude 12V, außerhalb über Koppelrelais 230V), mit automatischen Abschalten der Beleuchtung / Musik / Gartensteckdosen wenn das Gebäude abgesperrt wird. Wenn zum Zeitpunkt des absperren bereits die „Dämmerung angebrochen ist, soll per Timer das Terrassenlicht und Gartenwegbeleuchtung eingeschaltet werden (variabel konfigurierbare Zeit). Oder umgekehrt, wenn die Gebäudetüre aufgesperrt wird und es noch dunklen ist, automatisches Einschalten der Vorraumbeleuchtung. Die Dämmerung wird über einen astronomischen Kalender in OpenHAB ermittelt. 2) Lüftung/Frostschutz: Wenn die Raumtemperatur über einen variabel definierter Wert steigt und die Außentemperatur (an der Nordseite, dort befindet sich die Lüfter-klappe für an Ansaugluftstutzen) kühler ist. Wird die Lüftung ein oder ausgeschaltet. Wenn die Luftfeuchte (Absolut) im Gebäude höher ist als außerhalb des Gebäude und die Luftfeuchte innen einen variabel definierten Wert überschreitet. Wird die Lüftung ein oder ausgeschaltet. Sollte die Innen Luftfeuchte den Schwellwert überschreiten jedoch die Absolute Luftfeuchte Außen höher als Innen sein, wird nicht der Lüfter sonder ein elektrischer Luftfeuchter aktiviert. Für die Berechnung der Absoluten Luftfeucht habe ich eine Konzept-Idee aus dem KNX Forum angepasst. Die Lüftungsdauer variiert mit der Außentemperatur, um ein zu starkes auskühlen des Gebäude zu verhindern. Maximale Lüftungsdauer pro Stunde = 30 min (Hintergrund hierfür, es dauert ca. 30 min bis sich die Luft nach dem Lüften wieder gesättigt hat.) Wenn die Außentemperatur unter 5 Grad liegt und im Gebäude der variabel einstellbarer Schwellwert für die maximale Luftfeuchte überschritten wird, wird ein kleiner elektrischer Luftfeuchter einschalten (ist zwar technisch vorgesehen, der elektrische Luftfeuchter ist nicht angeschlossen) Frostschutz: Wenn die Raumtemperatur unter 8 Grad fällt wird ein Frostwächters aktiviert um die Temperatur nicht zu stark abfallen zu lassen. Wenn das Gebäude nicht abgesperrt ist, kann die Raumtemperatur auch höher eingestellt werden (über das Bedienfeld). Bei Abschließen des Gebäude werden wieder die Frostschutz Parameter aktiviert (8 Grad Celsius). Um Parameter für Luftfeuchte / Temperatur innen …. ohne PC oder App verändern zu können, wurde das LCD 20x4 und das Multi-Touch (mit 3x4 Tastenfeld) als Bedienfeld konfiguriert. Über diese Bedienfeld können auch verschiedene Andere Parameter über unterschiedliche Menüpunkte verändert werden. Erweiterungen die sich aus dem Funktionsumfang den vorhandenen Tinkerforge - Komponenten und verschiedener Funktionen innerhalb von OpenHAB ergaben. 1) Alarmanlage mit Fenster, Türkontakten & Glasbruchsensoren, sowie innen Bewegungsmelder. Alarmmeldung über Telegram-Messenger und Email, Alarmhorn und Signallicht Außen . Das Alarmsystem wird über das Bedienfeld in Standby versetzt und über einen Kontakt bei abschließen der Eingangstüre aktiviert. Wenn nicht alle Fenstern geschlossen sind, kann das Alarmsystem nicht aktiviert werden (dann erfolgt ein Warnton). Mit dem „scharf-schalten des Alarmsystem wird auch eine Videoüberwachung mit Bewegungserkennung aktiviert, diese läuft momentan als eigenständiges System über MotionEyOS das auch auf eine Pi installiert ist. Das "scharf-schalten" des Alarmsystem wird durch eine Nachricht per Telegram-App bestätigt. Das Ausschalten des Alarmsystem kann nur über Pin-Eingabe am Bedienfeld erfolgen. Wenn das Alarmsystem online ist und ein Fenster / Tür / Glasbruchkontakt oder der Bewegungsmelder aktiviert werden, wird ein Voralarm per Telegram-Messenger ausgelöst. Wenn nicht binnen einer definierten Zeit die Anlage per Pin deaktiviert wird löst der Laut Alarm aus und es folgen weiter Telegram Nachrichten. Pin-Fehleingaben führen zu weiteren Telegram Meldungen. Nach einem Stromausfall schaltet sich das Alarmsystem automatisch ein auch hier wird eine Telegram Nachricht gesendet. 2) Ein 12V Rauchmelder mit Wechsler-Kontakt signalisiet über das „Industrial Digital In 4“ Bricklet dem OpenHAB System den Feueralarm. Über eine Rule wird dann lauter Alarm ausgelöst und Telegram & Mail-Nachrichten versendet. Hinweis: Wenn OpenHab als Service auf einem Linux-System läuft und es eine MP3 Datei abgespielt werden soll, müssen die entsprechenden User (Service Accounts) sudo rechte besitzen. 3) täglicher Statusreport (dieser diente Ursprünglich zur Kontrolle ob das System Störungsfrei läuft), liefert Daten wie „Status Alarmsystem“, Status Rauchmelder, Aktuelle Temperatur / Luftfeuchte Innen & Außen, tägliche Maximal&Minimal Temperatur&Luftfeuchte innen und außen (immer gerechnet von einer Statusmeldung zur nächsten). Die Statusmeldung wird immer zum Zeitpunkt des Astronomischen Sonnenuntergangs gesendet. Die Max-Min Werte werden nicht über über simpel Variablen gespeichert. 4) Temperaturüberwachung des Pi: Im original OpenHAB-Forum habe ich eine Anleitung gefunden wie man die GPU und CPU Temperatur des Pi auslesen kann. Abgefragt wird dies per EXEC-Binding durch OpenHAB. Bei Schwellwert Überschreitung wird ein Mini-Lüfter eingeschaltet und einen Alarmmeldung per Telegram gesendet. Bedienung des System ohne Webschnittstelle oder App möglich: Licht kann entweder per WebInterface oder klassisch über die Lichttaster ein und ausgeschaltet werden. Gartensteckdosen und Wasserpumpe können nur per Taster und nicht per Web-Interface geschaltet werden (Hintergrund ist, dass hier verschiedene Rule's Einfluss auf diese Komponenten haben und eine Fehlbedienung verhindert werden soll (z.B. Wasserpumpe und Außensteckdose müssen abgeschaltet sein wenn die Alarmanlage online ist, wird auch über diverse Rule's laufend überwacht). Es ist aus Sicherheitsgründen nicht möglich über das Webinterface die Alarmanlage ein oder aus zu schalten, daher sind alle hierfür benötigten „Items“ nicht auf der Webinterface sichtbar. Das war jetzt eine Übersicht was in den ca 1,5 Jahren zwischen der Idee und dem Einbau im Sommer 2016 so alles an Smart-Home Rule entstanden sind. Für ein Gartenhaus sicher ein technischer Overkill, mir ging es aber darum, was machbar ist. Ein Gartenhaus ist sicher kein Wohnhaus, aktuell Teste ich mit Openhab2 und der RS485 Master Extension ob und wie man auch mit dezentral aufgebauten Komponenten Arbeiten kann (mit der LAN Extension ist es auf jedem Fall möglich. Das Openhab System ist im Sommer 2016 im Gebäude produktiv genommen worden und läuft seit gut 2,5 Jahren ohne Änderung stabil und ohne Ausfälle. Das ganz hat mich ermutigt ein weiteres Projekt zu starten, hier geht es um Alarm-Meldung der Heizung und einer Kellerlüftung Aktuell ist dies jedoch auf hold bis das Bindings für die neue Openhab2 Version alle Tinkerforge Komponenten unterstützt die ich benötige. Ebenfalls in Planung ist Umstellung der aktive Openhab 1.9 Installation im Gartenhaus auf die Version 2. Dies wird auch dazu dienen die Ganzen Rule's zu konsolidieren und zu vereinfachen. Sollte Euch meine Projekt gefallen haben und Ihr noch weiter Informationen wünscht meldet Euch einfach.

Hallo Theo, ich kann nur sagen WOW wie schnell du einen Update hier rein gestellt hast, Danke Jetzt verhält sich das System etwas anderes, anfangs hatte ich folgende Konfiguration am 2-Stapel (der über das RS485) angebunden ist. 1x Masterbrick 1x RS485 Masterextention 1x Multitouch 1x Outdoor-Weather 1x 20x4 Display 1x NFC nachdem das 20x4 Display noch nicht im Binding ist und das NFC und das Outdoor Weather noch nicht richtig funktioniert, hatte ich nur das Multitouch zum testen. Da sich das Outdoor-Weather irgendwie unmotiviert verhalten hat (es ging immer auf uninitialisierten Status), habe ich es durch den Motion-Dedector V2 ersetzt. In diese Konfiguration konnte ich die Spannung am 2-Stapel entfernen und als ich nach ca 1 Minute diesen wieder mit Spannung versorgte konnte ich ich das Multitouch und den Motion-Dedector wieder nutzen. Jedoch sind weder der Multitouch noch der Motion-Dedector im Menue "Configuration / Things" je als offline dargestellt worden, sie waren immer mit Status online. Nur im Log konnte ich einer Meldung lesen dass der Multitouch nicht erreichbar war. 2019-03-02 19:46:29.860 [ERROR] [evices.multitouch.MultiTouchBricklet] - setting configuration failed com.tinkerforge.TimeoutException: Did not receive response in time for function ID 4 Ich könnte mir vorstellen dass es eventuell damit zusammenhängt, wie der Masterbrick der per USB an den Pi angeschlossen ist die Gesamtkonfiguration Managed. Mir reicht es aber völlig aus, wenn nach dem wieder Spannung am 2-Stapel anliegt alles wieder nutzbar ist. Ich werde heute Nacht einmal den 2 Stapel spannungslos machen und dann morgen schauen wie der Status ist (online oder offline). Was ich durch das eintauschen des Motion-Dedector V2 gesehen habe, ist dass Du die 3 LED jetzt als Schalter (dimmbar) in der Konfiguration hast Leider haben die 3 LED bei ein oder ausschalten nicht reagiert (blieben dunkel) auch wenn die die Dimmung verstellt habe. Zum Thema Mulittouch ich hab zum Testen als Notlösung eine Taste als "rawbutton-toggle-switch" über ein vorhandenes Item aus meiner Item Datei verlinkt (siehe Bild). Hat gut funktioniert, verhält sich halt wie ein Tastschalter. Ich versuche nächste Woche mal das ganze rawchannel Thema am Mulittouch über eine rule zu testen. Ich will mal schauen ob es so in der Art funktioniert wie "Item changed to ON" .... also als richtiger Taste und nicht als Tastschalter. Update folgt.

Hallo Theo Super dass Du schon die nächste Binding-Version zum Testen bereitgestellt hast. Ich habe das neue Binding gerade kurz getestet, meine beiden 16-fach IO werden erkannt. Ich konnte die Channel‘s als Switch oder Contact konfigurieren und bei einem kurzen Test hat sich die Switch (mini LED mit 5v/3mA hat sich schalten lassen) als auch die Contact Funktion nutzen lassen. Ich werde das ganze noch mal intensiver testen (baue mir nur eine Tasterleiste ) Theo, Frage ist es möglich in der Paper-UI-View „Configuration / Things / BrickletIO16“ den Text abhängig ob der GPIO es als Switch oder Contact konfiguriert ist, mit „Switch“ oder Contact GPIO (0-15) einzutragen ? (aktuell steht immer Switch, was das überprüfen der Konfiguration schwieriger macht, da man alle anklicken muss um nach zu schauen was sie sind. (siehe Bild) Leider bin ich diese Woche etwas im Stress gewesen und konnte das mit dem rawchannel nicht richtig testen. Ich hab mal rum gespielt und konnte dann doch einen rawchannel mit einem Switch-Item verknüpfen, dann reagriet der Switch im Grunde wie ein Taster. 1x berührt = ein, ein weiteres mal berührt = aus. Ich werde es aber auf jedem Fall ohne Umwege (über Item) mit dem Rules probieren wie es sihui sagte. Eine Sache ist mir jedoch aufgefallen, ich weiß nicht ob es nun am Binding oder am Tinkerforge Masterbrick liegt. Ich habe unter der Woche meine Testkonfiguration umgebaut. Jetzt Stapel1: 2 x Masterbrick und 1x RS485-Extention (hiervon ist ein Masterbrick über USB an den Pi angeschlossen) Stapel2: 1 x Masterbrick und 1 x RS485-Extention (hier wird nur der Masterbrick mit Strom versorgt, die Daten Kommunikation läuft über die Busverlängerung durch das RS485. Stapel-1 und Stapel-2 sind über den RS485 Bricklet verbunden. Test Szenario 1: a) Anschließen des Masterbrick Stapel-1 an den Pi >> der MotionDedector V2 wurde erkannt b) Spannungsversorgung des Stapel-2 angeschlossen >> die Weather und der NFC-Bricklet wurden erkannt. Test Szenario 2: a) "nur" am Stapel 2 wird die Spannungsversorgung deaktiviert >> Weather & NFC Bricklet gehen offline b) am Stapel 2 wird wieder Spannung angelegt >> Weahter & NFC Bricklet bleiben weiter offline Um das ganze wieder zum laufen zu bekommen, musste ich Openhab durchstarten. Wenn ich ohne RS485 Verbindung zwischen beiden Stapeln arbeite und den zweiten Stalpel auch USB an den Pi anschließe, geht beim gleichen Test nach dem wieder einstecken des Stapel-2 Weather und NFC wieder online. (hier ist kein durchstarten notwendig) Wenn ich gleiches Spiel nun BrickViewer mache (also wieder beide Stapel über RS485 gekoppelt und nur Stapel-1 per USB am PC angeschlossen), erkennt der Viewer automatisch nach der Wiederherstellung der Spannungsversorgung die Komponenten des zweiten Stapel (hier wieder mit der Datenkommunikation über den RS485).

Hallo sihui Du hast Recht über das Astro-Binding hab ich schon mit Channel gearbeitet, aber über einen vermutlich komplizierten weg 1) erstelle ein Thing der "Datei xxx.thing" z.B. >>Thing astro:sun:abc .....<< 2) weise einem Item in der Item-Datei einen Channel des Thing "astro:sun:abc" zu damit hab ich dann in rules gearbeitet. Mit dem Tipp von Dir dürfte das alles einfacher werden da ich nicht so viele Abhängigkeiten habe. Danke für den Tipp