StefanOHAN

Hallo Erik, Danke für die schnelle Antwort Gut zu wissen, dann werde ich bei der nächsten Bestellung ein RedBrick in den Warenkorb legen. 😀 viele Grüsse

Hallo Erik, wie sieht Eure Planung bezüglich des RedBrick aus ? Ihr stellt doch momentan noch die Openhab 1.8x version für Ihn bereit, oder ? (ich meine diese schönen kleine Funktion über den Brickviewer Openhab zu aktivieren) Wenn Dein neues Binding mal fertig ist, plant Ihr dann auch die Openhab 2.x Version für den RedBrick so bereit zu stellen ? Ich hätte ein mini Projekt, da wäre RedBrick & Masterbrick ideal (klein und kompakt) viele Grüsse Stefan

Hallo Erik, nachdem ich Deinen Post zu dem Rule-Engine Problem gelesen habe, dachte ich mir nur mal so zum Spaß, es mit anderen Bricklet-Actions zu testen. Bei mir hat sich das IO-16 und IO-4 angeboten denn beide haben die getValue action. Also wenn ich mich nicht vertippt habe, kann ich mit der getValue Action Deine Erkenntnis zur Auswirkung des RuleEngine Problem bestätigen. Interessant war, als ich anfangs nur die IO-16 actions nutze (ohne dass ich für das IO-4 getAction in der Rule hatte), die IO-16 getValue action funktionierte. Erst als ich dann beim zweiten Versuch ebenfalls getAction für das IO-4 in der rule hatte, kam es immer zur Fehlermeldung. Auch als ich anschließend aus der Rule das getAction und getvalue für das IO-4 entfernte, blieb es bei der Fehlermeldung für das IO-4 wenn ich für das IO-16 das getValue nutzte. Ich bin ja gespannt was Du als Antwort auf Deinen Post bei den Openhab Entwicklern bekommst (ob es ein bekanntes Problem ist, oder nicht) Fehlermeldung wenn für das IO16 die getValue Action in der Rule enthalten ist. viele Grüße Stefan

Hallo Erik das Thema mit dem 6 Stunden Zyclus des off und online gehen der WIFI-Extension hat sich jetzt geklärt. Es liegt an einer Funktion der AVM, der "Optimierung der genutzten WLAN Kanäle". Kurz die AVM optimiert die WLAN Kanäle, daher kann es vorkommen dass die WLAN Devices ab und wieder angemeldet werden. Nachdem ich im AVM Log noch die Zusatzinformationen für WLAN aktiviert habe, konnte ich folgende zusammenhänge auslesen ---LogMeldung der Basis-Station AVM7590 ---LogMeldung Repeater ----LogMeldung Openhab Der Zeitliche Ablauf in den verschiedenen Logfile zeigt dass diese Optimierungs-Funkion der "Übeltäter" ist. Leider hatte ich nicht den vollen Logging-Umfang in der AVM aktiviert, daher konnte ich erst nachträglich den Zusammenhang erkennen 😞 Sorry viele Grüsse Stefan

Hallo Erik, also 2 Punkte haben sich geklärt 1) die Action lcdActions.drawText(0,55,6,true,“Hallo“) hatte echt nur ein Problem mit den falschen Hochkommas. Nach der Korrektur klappt es perfekt. (Problem war das hin und her kopieren) 2) der verlinkte Channel des LCD128x64SelectedGUITab übermittelt den richtigen Wert des berührten Tab. Es war mein Fehler, denn ich hab nicht ins Log geschaut nur aufs Display und einen Denkfehler in der Rule. Nach Korrektur der Rule funktioniert auch der Output richtig. Anders sieht es mit der lcdActions.clearDisplay() action aus, die macht noch immer Probleme So sieht meine Rule aus (sobald ich .clearDisplay() entferne läuft alles ohne Probleme) In Deinem Beispiel setzt Du hinter den Kommandos ein Semikolon, das ist soweit mir bekannt in Openhab nur notwendig wenn man mehre Kommando pro Zeile hat um diese zu trennen. Ich schreibe aus Übersichtlichkeit nur ein Kommando pro Zeile. Hab das mal mit Semikolon wie in Deinem Beispiel probiert, ändert nichts. Jetzt wo Du es schreibst ist mir erst aufgefallen, dass die Fehlermeldung auf das LCD20x4 verweist (eines ist angeschlossen siehe unten). Um sicher zu gehen, dass ich nicht einen Fehler verursacht habe, habe ich nochmal >>val lcdActions = getActions("tinkerforge", "tinkerforge:lcd128x64:f80007d9:HQJ")<< überprüft und den Wert per copy und paste aus PaperUI/Configuration/Things neu eingetragen (war aber korrekt). (es ist auch die ID des LCD128x64 und nicht die des LCD20x4) Die aktuelle Konfiguration ist #OS = openHABian v1.5-533(c7ac00c) >> auf aktuellen Stand (Sonntag ein Update laufen lassen) ## Basis = Raspbian GNU/Linux 10 (buster) ### Kernel = Linux 4.19.75-v7+ ### openHAB 2.5.0~S1749-1 (Build #1749) HW: Raspberry Pi 3 Model B Rev 1.2 (der Pi wird über das HAT-Brick mit Spannung versorgt, Notebook Netzteil 14V 4,5A) >>TF-Hat-Brick >> 1x LCD128x64 (FW 2.0.7) >> 1x MultiTouch V2 (FW 2.0.0) >>1x Motion Detector V2 (FW2.0.2) >>1x Rotary Encoder V2 (FW 2.0.4) >>1x Rotary Poti V2 (FW 2.0.0) >>1x Humidity V2 (FW 2.0.6) >>1x Piezo Speaker (FW2.0.2) >>1x Outdoor Weather (FW 2.0.4) 1xMasterbrick (HW-Rev2.1 / FW 2.4.10) per USB an den Pi angeschlossen >>1x LCD20x4 (FW 2.0.6) >>1x IO-4 V2 (FW 2.0.4) >>1x IO-16 V1 (FW 2.0.6) >>1xRS485 Extention (Master) 1xMasterbrick (HW-Rev2.1 / FW 2.4.10) per RS485 mit ersten Stapel verbunden >>1x IO-16 V1 (FW 2.0.6) >>1x IO-16 V2 (FW 2.0.2) >>2x Indust Quad Relays V2 (FW 2.0.3) >>1xRS485 Extention (Slave) >>Step Down PowerSupply (Industrie Netzteil VerteilerEinbau 24V 2,5A) Ich hab über die letzten 2 Monate die TF HW ein paar mal umgebaut, aber danach meist das OpenHab System zurück gesetzt (über die Openhabian Configurations-Console). Letztes Rücksetzten war So 10.11.2019. ---------- Zur WiFi Master-Extention, hat einen eigene Dämon in Openhab konfiguriert, läuft gemeinsam mit dem Dämon für das HAT / Masterbrick in der gleichen Openhab Konfiguration 1xMasterbrick (HW-Rev2.1 / FW 2.4.10) per WIFI mit AVM (über WLAN Repeater 1750) verbunden >> e-Paper 296x128 (FW 2.0.1) >> WIFI Extention V2 (FW 2.1.3) >>Step Down PowerSupply (Industrie Netzteil VerteilerEinbau 24V 2,5A) Die Signal-Stärke am Wifi ist laut BrickViewer 87/88 dB (am 18.11 abends) und 67 db (am 19.11 morgens) Im AVM 7590 Log als auch im Repeater Log finde ich keine Infos (weder am 18.11 abends noch am 19.11 morgens). Ich habe jetzt (19.11.2019 6Uhr) über den BrickViewer das logging im Debugg Modus gestartet, mal schaun was abends dort zu lesen ist. Den Log-Auszug von Openhab lade ich mit hoch. Es ist momentan nicht viel los auf meinem Openhab-System, daher kann man diesen 6 Stunden Zyklus gut sehen. Ich werde mal die Tage meine Konfig ändern und ein 16-fach IO an den Stapel mit der WiFI Extension hängen um zu schauen was passiert wenn während eines "disconnect" und reconnect ein Port (input) von offen nach geschlossen oder umgekehrt wechselt (Frage ob der Status des Port nach dem reconnect stimmt) Ich hoffe ich hab jetzt nichts vergessen. Viele Grüsse Stefan P.S Das Forum-System hat das Icon meiner eventlog-datei mitten in den Text rein geklebt. Ich konnte nach dem Logoff die Datei auch nicht mehr öffnen. Update: ich hab den Logfile gerade gelöscht, siehe Auszug Log im Post von mir am 20.11.2019 6:50Uhr

Hallo Erik, heute habe ich für 3 Bricklets einige Actions getestet. E-Paper, LCD128x64 und PiezoSpeaker. Bisher hatte ich immer Probleme mit den LCD128x64 Actions. Das lag aber nicht an meiner Konfiguration sondern ausschließlich an der Actions „clearDisplay()“. Nachdem ich diese Action in allen LCD128x64 Rules an erster Stelle eingebaut hatte, konnte ich nicht erkennen dass die anderen Actions des LCD128x64 funktionierten. Frage : habe ich bei der Schreibweise einen Fehler übersehen ? getestete Actions LCD128x64: lcdActions.clearDisplay() KO erzeugt einen Fehler im Log lcdActions.removeAllGUI() OK >> löscht alle Button / Tab usw. lcdActions.setGUIButton(0, 0, 0, 60, 20, "button1") OK >> erzeugt einen Button für (ID 0) lcdActions.setGUIButton(1, 68, 0, 60, 20, "CLEAR") OK >>erzeugt einen Button für (ID 1) lcdActions.setGUISlider(0, 0, 30, 60, 0, 50) OK >> erzeugt einen Slider (für ID 0) lcdActions.setGUITabText(0,“Tab A“) OK, >> erzeugt einen „Tab A“ Frage: zu drawText wie wird diese Action benutzt ? Ich hatte keine Reaktion am Display, erwartet hätte ich einen Text Schriftgröße 2x32 , Schriftfarbe schwarz. Muss ich ähnlich wie beim e-Paper noch eine weitere Actions ausführen ? weiter im Test: Wenn der verlinkte Channel des Slider betätigt wird, reagiert die Rule >> OK Wenn die erzeugten Button „button1“ oder „CLEAR“ betätigt werden reagiert die Rule >> OK Frage: Was kann ich mit dem Channel „LCD128x64SelectedGUITab“ anfangen ? Ich hätte vermutet, dass das mit dem Channel verlinkte Number-Item, die „ID“ des berührten TAB erhält (ich erhalte immer „1“ als Rückgabe Wert) Frage: Slider Number-Wert Das mit dem LCD128x64GUISlider1 verlinkte Number-Item hat bei mir einen Wert von 0-52. Kann man den Maximal Wert konfigurieren ? Wenn der Slider am Ende seiner Skala ist z.B. einen Wert 10 hat oder auch 100 hat ? weiter mit dem e-Paper Nachdem ich fehlende Action „ePaper.draw()“ in die Rule einfügte wurde der Text geschrieben >> OK Test mit Action PiezoSpeaker piezoActions.updateVolume(int) OK >> verändert beim aktiven Beep/Alarm die Lautstärke piezoActions.updateFrequency(int) OK >> verändert beim aktiven Beep die Frequenz piezoActions.setAlarm(75,1500,1,5,5,10000) OK >> verändert den Alarm (auch auch während eines aktiven Alarms) Das war heute ein echt erfolgreicher Test 🙂 Eine Frage hätte ich noch zur WIFI-V2 Extension: Sie läuft soweit gut, ich sehe nur so ziemlich genau alle 6 Stunden einen kurzen Verbindungsabbruch im OpenHab Log. Nach ca. einer Minute steht die Verbindung auch wieder und zugehörige Dämon ist wieder online. Kann es sein, dass diese Master-Extension Zyklisch (müsste ich da evtl. was rekonfigurieren ?) einen Verbindungsabbau / Aufbau ausführt ? Oder meinst Du es liegt an der Konfiguration meines WLAN-Router ? (AVM 7590). Das ist nicht schlimm, es ist nur aufgefallen als ich heute morgen mal die Logs kontrollierte. Danke für Deine Hilfe / Tipps und das Erstellen des Bindings 🙂 viele Grüße Stefan

Sorry Erik, aber die neue Forum Funktion dass man einen Post nur 2x "bearbeiten" oder einen älteren Post nicht mehr bearbeiten kann, finde ich absolut "unschön". Bitte richte dies Eurem Forum Admin aus. Stefan

Update zu meinem Post von gestern. Leider finde ich im neuen Design des Forum nicht mehr den Button zum Editieren des Beitrages. (kann es sein dass man älter Beiträge nicht ändern kann ?) Ich habe nach dem ich den Post abgesendet habe noch mal etwas an den Rules rumgespielt. Ich glaub nicht dass es an meiner Konfiguration liegt, denn die action für das IO-4 V2 funktionieren (zumindest das zurücksetzten des EdgeCount) Das Item Pin0IO4V2Count (Pin0 input) des IO-4 ist in der Item-Datei als „IO4V2EdgeCountPin0 " verlinkt. Mit der Rule prüfe ich einfach ob der Wert von Pin0IO4V2Count grösser 10 ist, wenn ja wird per Action der EdgeCount zurück gesetzt. Vor und nach der if-Anweisung wird auf dem LCD128x64 der Wert es EdgeCount ausgegeben. Ich habe auch nochmal in Eurer Doku „lcd-128x64-bricklet-java-examples“ nachgeschaut ob ich evlt noch einen Parameter für die LCD128x64 lcdActions.clearDisplay() benötige, aber nichts gefunden. Zumindest kann ich für das LCD128x64 mit getActions den Value auslesen. Nur die eigentliche action lcdActions.clearDisplay() führt zum Abruch der Rule und der Fehlermeldung im Log. Ich hoffe nur dass ich nicht wieder so betriebsblind bin und wieder ein Zeichen oder Kommando vergessen / übersehen habe. Mit dem e-Paper bin ich nicht weiter gekommen Viele Grüsse Stefan

Hallo Erik, irgend wie stehe ich jetzt auf dem Schlauch Zum Problem mit dem Log-Fehlermeldungen für die LCD128x64 Action Du schreibst : Frage: Wie kann ich das Binding im laufenden Betrieb aktualisieren ? Bisher ist meine Vorgehensweise entweder anschließend restart openhab2 oder Bundle deinstallieren openHAB herunter fahren das alte Binding durch das neue ersetzen und openhab neu starten. Diese Vorgänge hab ich jetzt 2x wiederholt, aber ohne dass ich die action zum laufen bekommen habe. Wie ist Deine Vorgehensweise beim aktualisieren des Binding ? Zumindest zwei Erfolg hatte ich heute: Das Stapel der über die WiFi-V2 MasterExtention angebunden ist, war zum Test für ca 10 Stunden Spannungslos. Nach dem anschließen der Spannungsversorgung ging mit leichter Verzögerung der Dämon (WiFi) und das angeschlossene Bricklet, wieder in OpenHab online. und das Update mit dem EdgeCount per ItemName.sendCommand(REFRESH) hat funktioniert. Was ich nicht verstehe ist Euro Doku „io4-v2-bricklet-java-examples“ Zitat: Meine Interpretation war, dass ich eben mit der „action“ getEdgeCount(Channel0 , false) eben nicht den Counter reset ausführe. Zum Abschluss wollte ich noch das E-Paper-Display per Rule testen. Hat nicht funktioniert, kann aber sein, daß es das gleiche Problem wie beim LCD128x64 ist. Frage: Wenn ich per Rule einen Text auf das E-Paper schreiben wollte, wären dann folgende Zeilen in der Rule richtig (Font24x32 , Farbe weiss, horizontal )? Ich habe allerdings den Channel tinkerforge:epaper296x128:wifi2test:Jyc:EPaper296x128DrawStatus nicht mit einem Item verlinkt. Was aber echt komisch ist, die Fehlermeldung im Log, bekomme ich nur für Das LCD128x64 nicht aber für das ePaper. Momentan bin ich etwas Ratlos. Viele Grüße Stefan

Hallo Erik Am Samstag ist die WIFI-Extetion V2 sowie das e-Paper Display gekommen. Das einbinden des WIFI über einen zweiten Dämon hat wunderbar geklappt. Jetzt läuft ein Dämon für die USB (incl. RS485 angebunden Bricklets) und einer für WIFI2-Extention. Das über das WIFI angebundene e-Paper Display ist über PaperUI / Things erreichbar (habe aber noch keine Rules für hierfür geschrieben). Frage: Hast Du die Möglichkeit auch Things der WIFI-Extention einzubinden ? Man kann ja neben dem Client auch den AccesPoint Mode nutzen, da wäre es schön wenn man den AccesPoint Mode ein und ausschalten könnte. Weiter habe heute etwas mit den actions getested, komme aber leider nicht so richtig zurecht. Beim LCD128x64 nutzte ich Dein Rule-Beispiel von Seite 1 (mit angepassten ID/DämonID) und es erscheint gleich beim Startup im LOG Im zweiten Schritt habe ich nur „eine“ action Deines LCD-Beispiel genutzt „lcdActions.clearDisplay()“ auch hier kam die gleiche Fehlermeldung. Die ClearDisplay Rule sieht wie folgt aus rule "startrule" when System started or Channel "tinkerforge:lcd20x4:f90009d9:vwU:LCD20x4Button2" triggered then var lcdActions = getActions("tinkerforge", "tinkerforge:lcd128x64:f90009d9:HhJ") lcdActions.clearDisplay() end Anschließend habe ich Dein Beispiel zum Löschen des EdgeCount genutzt (mit dem IO-4 V2). val ioActions = getActions("tinkerforge", "tinkerforge:io4v2:f90009d9:g7y") ioActions.getEdgeCount(1, true) Hier kam zwar auch die „missing Objekt Meldung“ aber keine weitere Fehlermeldung. Mein letzer Versuch war nur den Value per Action auszulesen ohne den EdgeCount nach dem auslesen zu löschen, so wie in der Eurer JAVA Doku beschrieben „ioActions.getEdgeCount(0, false)“ Der EdgeCounter hatte immer den Wert „0“ behalten, egal wie oft ich den Pin0 (input) mit GND verbunden habe. Zur Kontrolle habe ich mir den Wert am Display ausgeben lassen. Frage : „hast Du das Problem mit dem Zählen des EdgeCount schon anpassen können ? oder habe ich die action falsch verwendet ?“ Eines ist mir aufgefallen, in dem LCD-Beispiel nutzt Du beim EdgeCount Beispiel eigentlich solle es keinen Unterschied machen ob nun variable oder value genutzt wird, oder ? Momentan bin ich etwas ratlos weil ich nicht erkenne wo der Fehler liegt. Leider bin ich diese Woche bis Mittwoch nur sporadisch online, daher kann ich vor nächsten WE nicht weiter testen. Viele Grüße Stefan P.S. Großes Lob an Euren Warenversand, ich habe am Freitag Morgen bestellt und am Samstag war schon alles da.

Hallo Erik, die Zählerfunktion ist interessant daher würde ich den Zähler nur per Action zurücksetzte wenn definierte Bedingungen erfüllt sind. Die Action werde ich am Sonntag mit Rules Testen viele Grüsse Stefan

Hallo Erik Ich habe gerade die Rule nochmal angeschaut, die Warnmeldung wird von einer alten Rule ausgelöst, in der ich versuchte per sendCommand den EdgeCount auf "0" zu setzten. Link des Channel Rule ==> /var/log/openhab2/openhab.log <== Das Rücksetzten des EdgeCounter wird so nicht funktionieren (man kann ja auch den Number-String eines ThermoBricklet nicht per sendCommand ändern), oder ? Per Action ? Viele Grüsse Stefan

Hallo Erik, danke für die schnelle Antwort und das neue Binding. Ich habe heute Abend noch kurz den Piezo Speaker getestet. Ich kann den Beep und Alarm starten. Am Wochenende werde ich mal per Rule die Frequenz und das Volumen verändern testen. Die neue Action Funktion konnte ich noch nicht testen. Frage: Hast Du im neuen Binding etwas am Edge Count für das IO-16 V2 verändert ? Ich hab eine Warnmeldung im Log. Ich werde es aber am WE nochmal in aller ruhe Checken. viele Grüsse Stefan P.S Werde die Tage noch das E-Paper und die WiFi-Extention 2.0 zum testen bestellen

Hallo Erik ich hab mal etwas bei Euch im Shop gestöbert um zu schauen welche Komponenten für mich von Interesse sein könnten. Ich hätte da ein paar Fragen. Ist es möglich, dass ich Bricklets die über eine Kombination von Ethernet Master Extention / WIFI Master Extention 2.0 und über USB / Hat angeschlossenen sind, gleichzeitig nutzen kann ? Ich bin am überlegen ob ich mir die WIFI Master Extention oder die Ethernet Master Extention zulegen soll. Im Shop bei Euch gibt es das E-Paper Bricklet, ich bin mir zwar noch nicht sicher ob ich eine sinnvolle Anwendung in OpenHAB habe, wollte aber fragen ob Du planst diese auch in das Binding einzubinden. viele Grüsse Stefan

Hallo Erik, oh man ist mir das jetzt peinlich. Dass ich ein "n" in Command übersehen habe ist mir echt nicht aufgefallen. Man sollte nicht einfach Zeilen kopieren ohne diese zu prüfen Nachdem ich die fehlerhaften Befehle korrigiert hatte, funktionierte alles. Die Monoflop Trigger per Rule bei den IO-16 V1/V2 und IO-4 V2. Auch den Reset-Counter zum Rücksetzten des "Count-Channel" des Rotary Encoder konnte ich per Rule ausführen. Nochmal Sorry, dass ich meine eigenen Fehler in der Rule nicht gesehen habe, Asche auf mein Haupt. Danke für das schnelle Feedback viele Grüsse Stefan

Hallo Erik, danke für die neue Beta, ich habe heute mit Ihr getestet. Der Init des 16fach-IO V1 scheint jetzt sauber zu klappen. Weiter habe ich die „Edge Count“ Zählfunktion und die Trigger „Monoflop“ Funktion des IO-16-V1 / IO-16-V2 / IO-4-V2 getestet. Bei beiden Funktionen hatte ich aber Probleme. Für den „Edge Count“ hab ich immer Pin 0 als Input konfiguriert und verlinkt. Edge-Count Verlinkung in der Item-Datei Frage: Sollte das Number-Item sich nicht um 1 erhöhen wenn ich den als Input konfigurierten Pin betätige ? Bei mit behält das Number-Item den Wert „0“ Trigger Monoflop IO-16 / 4 Wie muss ich den Trigger für die Monoflop Funktion in den Rules benutzen ? Einfach per sendCommad einen String-Wert dem String-Item zuweisen ? Dies habe ich per Rule versucht, aber ohne Erfolg. Wenn ich über die Web-Site PaperUI/Control den Trigger Button betätige, schaltet er den als Output konfigurierten Pin ein und anschließend wieder aus . Es ist egal ob ich das für das IO16-V1 / V2 oder das IO-4 V2 ausführe, der Trigger per PaperUi/Control funktioniert, per Rule funktioniert es nicht. Monoflop Verlinkung in der Item-Datei Meine Rule (sind für die IO16-V1 / V2 und das IO4-V2 immer gleich aufgebaut) Nur das I0-4 V2 erzeugt eine Fehlermeldung (die IO-16 V1 / V2 nicht) Was mache ich falsch ? Weiter im Test Neu : Tinkerforge Rotary Poti Bricklet 2.0 Verlinken klappt wunderbar, der Wert des Number-Item verändert sich bei drehen des Poti. Mit dem Item kann eine Rule angesteuert werden. Neu : Tinkerforge Rotary Encoder Bricklet 2.0 Verlinken klappt wunderbar, der Wert des Number-Item verändert sich bei drehen des Poti. Mit dem Number-Item und dem Channel des „Push-button“ kann eine Rule angesteuert werden. Einzig mit dem „Reset Counter“ Channel hatte ich Probleme. Frage: Wie kann ich den "Count-Channel" Number-Wert zurück setzten ? Ich habe vermutet, wenn ich dem String-Item des "Reset Counter" (verlinkter Channel) per sendCommand einen beliebigen String-Wert zuweise, wird der Wert des "Count"-Channel auf 0 gesetzt, es kam aber nur eine Fehlermeldung im Log. Verlinkung in der Item Datei Befehl in der Rule Fehlermeldung im Log war: Wo liegt der Fehler ? Mir ist heute mit dem neue Binding aufgefallen, dass im Log sich sehr oft diese Meldung für die verschiedenen Bricklets wiederholt. Ist dies Absicht ? Nachtrag zum Piezo-Speaker: Nachdem ich heute sah, was alles über den BrickViewer machbar ist, würde ich sagen: Beiden Funktionen „Play-Beep“ und „Play-Alarm“ mit Ihren Parametern sollten so in OpenHAB nutzbar sein. Allerdings sollte die „Beep-Duration“ und „Alarm-Duration“ länger als 1000msec einstellbar sein (minimum 30sec). Was auch sinnvolle wäre, wenn zum aktivieren des Beep / Alarm Play ein Switch zum Einsatz kommen würde, der nach Ablauf der „Duration“ wieder vom ON in den OFF Status wechselt. Dadurch könnte man andere „Items“ die nur „ON“ sein sollen solange ein Ton ertönt, steuern. Das abschalten des Beep/Alarm Play soll auch vor Ablauf der Duration möglich sein. Demnächst werde ich per Rule mal den Trigger Monoflop für die „Tinkerforge Industrial Quad Relay Bricklet 2.0 „ testen ob ich da ähnliche Probleme habe wie bei den IO-16 / IO-4 viele Grüße Stefan

Hallo Erik kein Problem, es reicht klar wenn es mit der nächsten Binding-Version gefixt wird. Den Piezo Speaker würde ich als Signalgeber für Hinweise / Warnungen / Alarme / Störungen, einsetzten wollen. Es wäre es gut, wenn man zwischen einem Dauerton und einem Pipton unterscheiden kann. Unten so eine Idee, wie man den PiezoSpeaker über Openhab ansteuern könnte. >> Channel für das Ein und Ausschalten (Switch) >> Channel für die Tonfrequenz (Number) >> Channel für die Intensität der Lautstärke (Number 0-100 ?) >> Channel für die Anzahl der PipTöne pro Sekunde (Number 0-20 ?) und wenn dieser Wert 0 ist, gibt es einen Dauerton. Wenn der Switch des Speaker auf ON steht, sollte es dennoch möglich sein, die Werte für Frequenz und Intensität verändern zu können. So könnten man auch ein Anschwellen des Ton oder einen Frequenzwechsel ermöglichen. viele Grüsse Stefan Udate: Hallo Erik ich habe gestern meinen PiezoSpeaker erhalten und gesehen wie groß dieser ist. Ich hätte da eine Frage: Meinst Du, es ist machbar, dass man über das Binding den PiezoSpeaker (wenn er über das "Hat" angeschossen ist), als "SystemSpeaker" für den Raspi mit nutzen könnte ? Auch wieder nur um Signal Töne/ mini MP3 ausgeben zu können (openhab Funktion "playSound(String filename)". (diese Frage ist vom Typ Nice-to-have)

Hallo Erik so jetzt laufen seit 2 Tagen die neuen Rules die das Initialisierungs-Verhalten der 3 angeschlossenen IO-16 nach dem starten des System überprüfen. Das Initialisierungsproblem scheint ein generelles IO-16 V1 (10pol Stecker) (HW-Release 1.2) zu sein. Es ist egal ob am Stack mit der direkten USB-Verbindung zum Pi oder über den Stack mit der RS485 Extention angeschlossen sind. Grüsse Stefan

Hallo Erik, ich hätte noch ein Bicklet für den Binding-Wunschzettel. Das Piezo Speaker Bricklet. Wenn Dein OK kommt, würde ich es bestellen. Grüsse Stefan

Hallo Erik, danke für die Rückmeldung. Zum Thema HAT : Ja es ist die aktuelle FW installiert, es hat auch immer funktioniert. Nachdem es nur eine Warnmeldung war, war ich mir nicht sicher ob es was zu bedeuten hat. Name des Brick-Daemon: Test war erfolgreich, ich konnte beim Konfigurieren des Daemon einen eigenen Namen angeben. Danke für den Hinweis Zum Thema Initialisierungs Verhalten vom IO-16 das über RS485 angeschlossen ist. Ein Refresh Befehl über die Konsole hat auch nichts geändert. Siehe Log Über eine kleine Rule fragte ich ab, ob die ITEM den Status NULL haben. Ich habe vergessen zu erwähnen dass, das IO-16 das hier rum zickte eine HW-Version 1.2 hat, als noch zu den V1 Bricklets mit den 10pol Stecker gehört (hat aber die aktuelle FW). Aus Interesse habe ich dann mein IO-16 V2 (mit dem 7Pol Stecker) zusätzlich an dem Stack2 (der über RS485 angebunden ist) angeschlossen. Anschließen habe ich das System heruntergefahren, an beiden Stack die Spannung abgeschaltet und anschließen neu gebootet. Der V2 IO-16 hat sich sauber Initialisiert. Dort waren 14 Ports als Input und 2 als Output konfiguriert. Alle!! 14 Input-Ports hatten den korrekten Staus (OFF). Ich hatte gestern allerdings nicht mehr Zeit um es mehrfach zu testen. Heute werde ich mal einen Überwachungs-Rule für alle IO-16 schreiben um das Verhalten über einen längeren Zeitpunkt beobachten zu können. FRAGE: Kann es sein dass die Kombination "Verbindung über RS485 Masterextention und alte V1 IO-16 diese Eigenart verursachen ?" Evtl kann ja im Binding nochmal auf den Teil für das alte IO-16 schauen. Jetzt noch ein zwei Frage zum Verständnis: im Konfigurations Punkt der verschiedenen Bricklets findet man immer den Menu-Punkt Bridge Selection CREATE BRIDGE Was ist die Funktion zur erstellen einer "Bridge" ? Nochmal einen Frage zur Sample Rate des Humidity V2 Bricklet Du schreibst ich hatte meine Konfiguation wie unten eingestellt, bekam aber dennoch alle 10 sec einen Wert im Log Averaging Humidity Moving Average Length 20 Temperature Moving Average Length 20 Sample Rate 0.1 SPS hätte da nicht alle 200 Sekunden nur werte erscheinen dürfen ? Viele Grüsse Stefan

Hallo Erik, ich hoffe Du hattest einen erholsamen Urlaub :-) Ich hab mal alle mir verfügbaren Bricklets und MasterExtentions in meine Konfiguration integriert. Um nicht Altlasten aus den vorhergehenden Test versehentlich zu übernehmen, wurde das System komplett zurückgesetzt. Aktuell nutze ich Dein Beta11 Binding. Zwei Punkte sind mir aufgefallen Punkt 1) Nachdem ich über „PaperUI“ / Inbox das LCD 128x64 erneut hinzu gefügt hatte, und die Channel-Verlinkung über der Item-Datei eingetragen habe, ist mir aufgefallen dass der Channel-String nach dem zurücksetzten von Openhab sich verändert hatte. (siehe unten) Es unterscheiden sich die Zeichen in der 3ten Gruppe (alt „f80007d9b“ neu „b0b51208“) Warum ist dies so ? Kann dies verhindert werden ? Was würde passieren wenn ich das System neu aufsetzte ? Müsste ich immer alle Channels neu verlinken ? (wäre es möglich einfach die Item - Datei mit dem verlinkten Channel in das neue System zu kopieren ohne diese ändern zu müssen ?) Punkt 2) Ich habe in Summe 3 x IO-16 angeschlossen. 2 x IO 16 sind an dem Materbrick (Stack1) angeschlossen der direkt per USB mit dem Raspberry Pi verbunden ist. 1 x 16-IO ist an dem Masterbrick (Stack2) angeschlossen der per RS485 Extention mit dem Masterbrick des Stack1 verbunden ist. Stack2 verfügt über eine eigene Spannungsversorgung durch ein StepDown Power-Supply. Beim Starten von Openhab (egal ob beide Stack‘s Spannungslos waren oder ob nur Openhab neu gestartet wurde) verhält sich das 16-IO das am Stack2 über die RS485 Extention angebunden ist, anders als die 2x16-IO die am Stack1 mit direkter USB-Verbindung am Pi angeschlossen sind. Die als Input konfigurierten Ports am Stack1 (direkt per USB angeschlossen) werden richtig initialisiert, d.h. es wird angezeigt ob der Input-Kontakt offen oder geschlossen ist. Die als Input konfigurierten Ports am Stack2 bleiben nach dem Starten von Openhab in einem undefinierten Zustand (NULL) solange bis der Input Kontakt 1x betätigt wurde. Es ist auch egal ob nun während des Starten von Openhab ein Input-Kontakt geschlossen ist oder nicht. Dies ist etwas unschön, denn wenn man über den „remote“ Stack2, Fenster oder Türkontakte (IO-16) einbinden will, hat man nach dem Starten von OpenHab keine klare Aussage ob eine Rule nun starten soll oder nicht. Diese Problem könnte man umgehen wenn man den Status eines Channel abfragen könnte, geht dies mit Deinem Binding ? Wenn nein, was kann man da machen ? Beispiel: „Die Lüftung soll eingeschaltet sein wenn das Fenster geschlossen ist“ nach dem Startup von Openhab kann das Fenster auf oder zu sein, die Rule wird nicht reagieren. Auf dem Bild siehst die Du Konfiguration (Brickviewer & PaperUI/Control) man kann erkennen dass das IO-16 (mit ID WiP) nur "ausgegraute" Switch-Symbole hat. Mir ist momentan unklar wie ich diese Problem umgehen kann, dass meine Input-Item auch direkt nach dem Start den korrekten Status anzeigen. Ein Punkt ist mir noch aufgefallen, einmal erschien im Log die Meldung dass das Hat länger zum Initialisieren benötigte. Ist dies ein Problem ? Viele Grüsse Stefan

Hallo MacDuff ich habe Deine Rule kopiert und angepasst (Item-Namen) und bei mir funktioniert es. Einziger unterschied ist, dass Dein ITEM-Name ausschließlich aus Grossbuchstaben besteht. Wenn ich mich dunkel erinnere, gibt es eine Syntax für ITEMs "Das erste Zeichen muss ein Grossbuchstabe sein, aber es drüfen nicht alle Zeichen Grossbuchstaben sein." Probier mal, ob bei Anpassung der ITEM-Namen-Syntax das Problem behoben ist Meine Item/Channel verlinkung sieht wie folgt aus Grüsse Stefan

Hello Wannes, I changed my configuration Now I have Stack2 with -step-down Power Supply -RS485 Extention Slave (connected with the RS485 Extention on Stack1) -Masterbrick 2.1 ->Dualrelais V2 ->Industrial In V2 at Stack2 -RS485 Extenion Master -Masterbrick 2.1 (is via USB conneted with the Raspberry) ->IO-16 V2 One Port of the 16-IO (Port 0 = Item Pin0) is at the ITEM-File configured as an Input. If I switch the DualRelais"0" ON, the Idustrial-IN geht on Port3 5V power. with that Rule I can switch on/off DualRelais"0" During my test I was switch 4 Time on/off the Powersupply at Stack2. But I get no error, the rule was working and via the rule I could swith on/off the DualRelais"0" and even the Industrial-IN Port3 was switching to on/off if the Rule switched the DualRelais on/off. maybe there is an other difference between our configurations Greetings Stefan

Hello Wannes, What do you mean with Does it mean you can't send command with rules to the Stack ? I want to reconfigure my Test-System and try if I even get the same Problem. with regards Stefan

Hallo Erik, erst mal schönen Urlaub für Dich :-) Beim LCD 128x64 funktioniert jetzt das Backlight :-) Text schreiben und Display-clear funktionieren analog zum LCD 20x4. Den Draw-Channel hab ich aus Ideen-Mangel noch nicht getestet. Jetzt werde ich erst mal ein paar zusätzlichen TF Bricklets bestellen. @ rak kurze Frage, hast Du über die karaf-console erst das alte Binding entfernt ? Ich entpacke den Zip immer auf einen anderen PC (ich nutze einen RasPi 3b ; OS = Openhabian v1.5 ; Openhab = 2.5.0-SNAPSHOT Build #1673), deinstalliere über die karaf-Console das alte Binding, stoppe Openhab und anschließend kopiere ich das Binding in das Addon-Verzeichnis. Nach dem Restart von Openhab funktioniert es wieder. viele Grüsse Stefan