rtrbt Posted September 5, 2019 at 12:25 PM Share Posted September 5, 2019 at 12:25 PM Moin, Ich habe die letzten Monate daran gearbeitet, unseren Binding-Generator so aufzubohren, dass auch openHAB-Bindings generiert werden können. Die 24. Beta findet sich hier. Edit: Beta 24 mit folgenden Änderungen: - Reset-Action für Koprozessor-Bricklets hinzugefügt - Simple Mode für NFC hinzugefügt - Neue API als Actions durchgereicht - I2C-Modus für Barometer Bricklet hinzugefügt - Unterstützung folgender Bricklets hingefügt: Industrial Dual AC Relay Industrial PTC IMU 3.0 - Frame Started Channel von LED Strip Bricklets abschaltbar gemacht - Clear Error LED Channel für Bricklets mit Error LED hinzugefügt - Binärinputs von Switch auf Contact gewechselt - Work-Around für nicht funktionierende Actions nach Neustart eines Addons hinzugefügt - Firmware-Updates repariert - Heartbeat-Mechanismus für mehr als 4 Brick Daemons repariert - Die Bindings kompilieren gegen die Java-Bindings 2.1.26. Das heißt, dass zur Installation die Jar mit den Java-Bindings aus der Zip neben die neue openHAB-Bindings-Jar in das addons-Verzeichnis gelegt werden muss. - Online-Dokumentation (vorerst nur auf Englisch) Hier der Inhalt der README: Installation: Die Bindings benötigen eine openHAB 2.5.0 Installation. Zum Installieren reicht es, die beiden JARs in das addons-Verzeichnis zu kopieren. Nachdem openHAB das Addon geladen hat (das kann einen Moment dauern), kann über die Inbox ein Brick Daemon hinzugefügt werden. Konfiguration: Nachdem der Brick Daemon hinzugefügt wurde, werden angeschlossene Geräte automagisch in die Inbox gelegt. Sowohl Geräte als auch Channels können Konfiguration haben: Channels typischerweise die Aktualisierungsrate (Default: 1s). Die Brickletkonfiguration kann Channels anzeigen/verstecken, z.b. erzeugt die Pinkonfiguration der IO-4/16 Input/Output-Channels je nachdem, ob ein Pin auf Input oder Output konfiguriert wurde. Die PaperUI braucht manchmal eine Aktualisierung per F5, damit neue Channels angezeigt werden. Es kann nur Konfiguration gesetzt werden, die im RAM des Geräte gespeichert wird. Persistente Konfiguration muss extern (z.b. mit dem Brick Viewer) gesetzt werden, da openHAB diese jedes Mal schreiben würde, wenn openHAB startet, oder die Verbindung zum Brick Daemon wiederhergestellt wurde usw. Das kostet zu viele Flash-Schreibzyklen. Weitere Dokumentation: Findet sich hier: https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html#api-bindings-openhab (vorerst nur auf Englisch) Actions in Rules: Es werden für alle unterstützten Geräte Actions zur Verwendung in Rules zur Verfügung gestellt. Um in einer Rule auf die Actions eines Gerätes zuzugreifen, müssen diese zunächst mit var devActions = getActions("tinkerforge", "tinkerforge:[Gerätetyp]:[Device UID]") geladen werden. Danach können sie mit devActions.[actionname]([parameter]) verwendet werden. Zum Beispiel zeigt die folgende Rule auf einem LCD 128x64 Bricklet mit der UID "HQ6" eine graphische Oberfläche an: rule "startrule" when System started then var lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQ6") lcdActions.brickletLCD128x64ClearDisplay() lcdActions.brickletLCD128x64RemoveAllGUI(); lcdActions.brickletLCD128x64SetGUIButton(0, 0, 0, 60, 20, "button"); lcdActions.brickletLCD128x64SetGUISlider(0, 0, 30, 60, 0, 50); lcdActions.brickletLCD128x64SetGUIGraphConfiguration(0, 1, 62, 0, 60, 52, "X", "Y"); lcdActions.brickletLCD128x64SetGUIGraphData(0, newArrayList(0, 10, 20, 40, 20, 15)); lcdActions.brickletLCD128x64SetGUITabConfiguration(3, false); lcdActions.brickletLCD128x64SetGUITabText(0, "Tab A"); lcdActions.brickletLCD128x64SetGUITabText(1, "Tab B"); end Funktionen, die Arrays erwarten, können in openHAB-Regeln auch mit Listen verwendet werden, wie dies im Beispiel von setGUIGraphData gezeigt wurde. Rückgabewerte werden als eine Map<String, Object> zurückgeben, diese kann wie folgt verwendet werden: rule "otherrule" when Item Enx_Button changed to OFF then val lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd128x64:HQ6") pixels = lcdActions.brickletLCD128x64ReadPixels(0, 0, 127, 63).get("pixels") val inverted = pixels.map[p | !p] lcdActions.brickletLCD128x64WritePixels(0, 0, 127, 63, inverted) end Die Rule wird ausgelöst, wenn das Item Enx_Button auf OFF geändert wird (d.h. wenn der zugehörige RGB LED Button losgelassen wird). Sie liest gesamten Pixel des LCD Bricklets aus, invertiert diese und zeichnet die invertierten Pixel wieder auf das LCD. Über Actions kann fast die gesamte API der Geräte genutzt werden. Actions die den Zustand von Channels ändern, aktualisieren diese automatisch. Nicht unterstützt werden Operationen, die EEPROM- oder Flash-Speicher der Geräte schreiben würden. Auch hier sollen unnötige Schreibzyklen vermieden werden. Display-Bricklets: Text wird auf folgende Weise gesetzt: [line],[position],[text]. Weitere ',' nach den ersten beiden werden als Teil des Textes behandelt. Der Text kann mit \x[zwei Hex-Ziffern] das Character-Set des Displays verwenden. Zusätzlich werden Unicode-Zeichen so gut es geht auf das Display-Character-Set abgebildet, wie das auch in den Code-Beispielen passiert, siehe z.B. hier: https://www.tinkerforge.com/de/doc/Software/Bricklets/LCD20x4_Bricklet_Java.html#unicode Beispielsweise gibt 1,2,Hallo, opεnH\xE0B! auf einem LCD 20x4 in Zeile 1, Spalte 2 aus: Hallo, opεnHαB! Das kleine Epsilon wurde von Unicode in das LCD-Character-Set übersetzt, 0xE0 (224) entspricht dem kleinen Alpha. Die PaperUI scheint Leerzeichen am Rand des Commands abzuschneiden. Um (Teile) einer Zeile zu löschen kann also nicht ein Befehl wie 1,2,[Leerzeichen] verwendet werden. Stattdessen kann 1,2,\xFE\xFE\xFE benutzt werden um in Zeile 1, Spalte 2 drei Zeichen zu löschen. Fehlende Features: Channels akzeptieren nur einen CommandTypen, d.h. z.B. LED des RGB LED Button Bricklets nimmt nur HSBType an, nicht die anderen, die von openHAB erwartet werden (wie PercentType wenn die Brightness geändert wird) Bekannte Bugs: Display Bricklets zeigen auf der Übersichtsseite, solange noch kein Text gesendet wurde, '-' als Text an, wenn darauf geklickt wird NULL. PaperUI zeigt die Description von Channel(Typen) und Konfigurationsparameter-Gruppen nicht an. Unbekannte Bugs: Falls ein anderer Bug auftritt, bitte das openHAB-Log mit anhängen. Das Log findet sich im userdata/logs-Verzeichnis der openHAB-Installation. Falls der Bug reproduzierbar ist, kann mit log:set TRACE org.openhab.binding.tinkerforge (in der Karaf-Konsole) das LogLevel erhöht werden, dann erscheinen eventuell weitere hilfreiche Informationen im Log. Außerdem hilfreich ist log:exception-display. Falls Fehler in der PaperUI angezeigt werden, können diese mit der Netzwerkanalyse der Web-Entwickler-Tools untersucht werden. Dann mit laufender Analyse die Seite neuladen und die Antworten von Anfragen mit Statuscode 500 ansehen. Eventuell hilft hier auch log:exception-display. Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted September 6, 2019 at 07:07 AM Share Posted September 6, 2019 at 07:07 AM Hallo rtrbt das hört sich interessant an. Kurze Frage hätte ich, ist dieser "Binding-Generator" dazu gedacht dass sich jeder dann sein eigenes Binding erstellen kann in dem er den Generator auf dem System installiert auf dem Openhab läuft ? Viele Grüsse Stefan Quote Link to comment Share on other sites More sharing options...
rtrbt Posted September 6, 2019 at 07:22 AM Author Share Posted September 6, 2019 at 07:22 AM Moin, Der Generator ist dieser hier. Er erzeugt die API-Bindings für alle unterstützten Programmiersprachen und jetzt auch für openHAB. Den kannst du theoretisch bei dir ausführen, aber zur Zeit ist es noch etwas Handarbeit, die openHAB-Bindings zu kompilieren. Erik Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted September 6, 2019 at 07:58 AM Share Posted September 6, 2019 at 07:58 AM Hallo Erik, danke für die schnelle Antwort Es wird auf jedem Fall dann Theo die Arbeit erleichtern viele Grüsse Stefan Quote Link to comment Share on other sites More sharing options...
piwo2 Posted September 9, 2019 at 02:09 PM Share Posted September 9, 2019 at 02:09 PM !!!!!!!!!!!!! grossartige nachricht !!!!!!!!!!!!!!! ich forsche schon seit wochen nach frameworks & deren möglichkeiten, anpassungen/workarounds in richtung tinkerforge UND andere (z.b. ebus, knx) unter einen hut zu bringen .... als einziger ansatz ist mir bisher seitens tf der mqtt-proxy via einer eigens zu schreibenden "übersetzungs-middleware" eingefallen .... eigene bindings würden nun openhab definitiv als integrationsschicht der ersten wahl anbieten ! bin echt gespannt & aufgeregt. endlich nägel mit köpfen. lg wp Quote Link to comment Share on other sites More sharing options...
maxico Posted September 10, 2019 at 09:53 AM Share Posted September 10, 2019 at 09:53 AM Danke, klingt erstmal vielversprechend. Ist geplant weitere Bricklet-Bindings "generieren" zu lassen? Konkret (Theos Binding hat die): Analog In Analog In 2.0 Industrial Digital Out Industrial Digital In 4 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted September 10, 2019 at 10:10 AM Author Share Posted September 10, 2019 at 10:10 AM Moin, Geplant ist möglichst alle Bricks und Bricklets generieren zu lassen. Ich habe für die Beta nur erstmal die, die Theos Bindings unterstützen genommen, da das ja scheinbar die sind, an denen openHAB-User am wahrscheinlichsten interessiert sind. Die vier auf deiner Liste habe ich beim spontanen Codedurchsuchen in Theos aktuellen Bindings nicht gefunden, ich setze sie mir aber trotzdem mal auf der TODO-Liste nach oben. Quote Link to comment Share on other sites More sharing options...
maxico Posted September 10, 2019 at 02:58 PM Share Posted September 10, 2019 at 02:58 PM Danke fürs Anpassen der TODO-LIste :-) teste dann gerne Was meinst Du mit Theos "aktuellen Bindings"? Bin nicht sicher, aber es gibt das OH1 Binding (offizielles Addon, von Theo): https://www.openhab.org/addons/bindings/tinkerforge1/ Und es gibt Theos Beta des nativen OH2 Bindings (jar Datei). Das unterstützt weniger, aber auch andere, neuere Bricklets... Quote Link to comment Share on other sites More sharing options...
rtrbt Posted September 10, 2019 at 03:09 PM Author Share Posted September 10, 2019 at 03:09 PM Ich meinte die OH2 Bindings. Ich editiere gleich den Post oben auf einen Link zur Beta 2. Die unterstützt die vier Bricklets auf deiner Liste und das Joystick V2. Vom Analog In (1) und Industrial Digital In 4 habe ich hier keins mehr gefunden, die kannst du ja mal testen Quote Link to comment Share on other sites More sharing options...
Jerome Posted September 10, 2019 at 05:22 PM Share Posted September 10, 2019 at 05:22 PM Super Sache! Vermisst wird immer noch das GPS sowie das LED Stripe Bricklet. Liebe Grüsse Quote Link to comment Share on other sites More sharing options...
xsherlock Posted September 11, 2019 at 05:03 PM Share Posted September 11, 2019 at 05:03 PM C'mon translate that to english, I'm waiting for those proper binding for months. Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted September 11, 2019 at 07:29 PM Share Posted September 11, 2019 at 07:29 PM Hallo Erik, ich habe heute Dein Binding "2.5.0.201909101456" in meiner Openhab2 Entwicklungsumgebung eingespielt. HW = RasPi 3b OS = Openhabian v1.5 Openhab = 2.5.0-SNAPSHOT Build #1673 Leider habe ich momentan nicht viel Zeit und nur mal kurz gecheckt was bei mir angezeigt wird. Ich konnte alle angeschlossenen brick's / brickletes / HAT-Brick unter "paperui/index.html#/inbox" sehen. Unter paperui/index.html#/configuration/things wurden IO-16 / IO-16 2.0 ; Humidity 2.0 ; Industrial Quad Relais 2.0 ; LCD 128x64 ;LCD 20x4 ; Multi-Touch ; Motion Detector 2.0 erkannt. Als not supported yet angezeigt wurden ->Tinkerforge Master Brick ->Tinkerforge Outdoor Weather Bricklet ->Tinkerforge NFC Bricklet ->Tinkerforge HAT Brick Also auf meiner Wunschliste wäre diese 4 weiteren Komponenten :-) Mit Rules / Channel usw. hab ich noch nichts getestet, nur 3 x den Openhab-Service durchgestartet, um zu schauen ob nach dem Restart auch wieder alle Komponenten als Online angezeigt wurden, da hatte ich in letzter Zeit öfters mal Probleme. Es wurden immer alle Komponenten wieder als Online angezeigt. Eine paar Fragen hätte ich: Wie haben Du und Theo das zukünftige Vorgehen geplant ? Wer wird das Binding pflegen ? Wen soll man ansprechen wenn man Erweiterungen möchte ? Wen soll / kann ich durch Testen des Binding unterstützen ? viele Grüße Stefan Quote Link to comment Share on other sites More sharing options...
rtrbt Posted September 12, 2019 at 09:47 AM Author Share Posted September 12, 2019 at 09:47 AM Moin, Hier ist Beta 3 mit Support für die LED Strip und GPS Bricklet. @StefanOHAN: Was hast du mit dem Master Brick und openHAB vor? Bin mir da noch unschlüssig was sinnvoll abzubilden ist. Outdoor Weather und NFC stehen noch aus, da sie aber schwieriger umzusetzen sind, wird das noch etwas dauern. Das Outdoor Weather Bricklet werde ich voraussichtlich als eine Bridge abbilden, die gefundenen Sensoren und Stationen als Einzeldevices. Beim NFC muss ich die State-Machine implementieren. HAT Brick nehme ich mir mal für Beta 4 vor. Zu deinen weiteren Fragen: Geplant ist, dass die openHAB-Bindings bezüglich Wartung und Weiterentwicklung genauso behandelt werden wie die für alle unterstützten Programmiersprachen. Ich weiß nicht, ob Theo vor hat, seine Variante der Bindings weiterzuentwickeln. Vorteil der generierten Bindings ist, dass sie offiziell von uns unterstützt werden, also kannst du bei Feature-Wünschen und Bugreports immer ins Forum posten. @xsherlock: I've translated the readme, everything else is english anyway. I will post a thread in the General Discussion in a moment. Edit: done. Quote Link to comment Share on other sites More sharing options...
andreasOH Posted September 12, 2019 at 07:24 PM Share Posted September 12, 2019 at 07:24 PM Hallo Erik auch von mir ein Seufzer der Erleichterung. Ich habe TF PoE Nodes für meine Heimautomation aufgeplant, mit OpenHAB. Jetzt ist der Krimi für die Unterstützung hoffentlich bald vorbei. Ich glaube, wenn ein stabiles Binding verfügbar ist, werden viele den Weg über TF gehen für Sensorik/Aktorik im Bereich „Smart Home“ #buzzword Off-Topic: wie sieht es bei Node RED aus, kommt da noch eine Unterstützung von TF für die aktuellen Sachen? Danke schon mal, Gruß Andreas Quote Link to comment Share on other sites More sharing options...
maxico Posted September 12, 2019 at 07:34 PM Share Posted September 12, 2019 at 07:34 PM N'abend HW: RPi4b 2GB OS: Openhabian 1.5 OH: openHAB 2.5.0 Build #1686 Binding: Beta 3 Neuer Pi als Testumgebung kam erst vorhin an, die letzte wurde zu Volumio. Testergebnisse: Hinzufügen von zwei Brick Deamons in PaperUI mit unterschiedlichen IPs funktioniert. Beide Online. Auf den ersten Blick wurden alle Bricks und Bricklets (beider Stapel) erkannt und konnten als Thing hinzugefügt werden: 1x Analog IN (1.0) 2x IO-16 Bricklet (1.0) 1x Industrial Digital In 4 Bricklet (1.0) 9x Industrial Quad Relay Bricklet (1.0) 9x Industrial Digital Out 4 Bricklet (1.0) 1x Industrial Digital Out 4 Bricklet (2.0) Kurzer Blick in die Things: Alle komplett. Monoflops bei den Aktorbricklets als Channel anzubieten ist super! Das spart enorm rules! Nach Neustart alle Things wieder online. Mit den Things etwas "machen", konnte ich aus Zeitmangel noch nicht. Erstmal Danke! Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted September 13, 2019 at 05:29 AM Share Posted September 13, 2019 at 05:29 AM Hallo Erik zu Deiner Frage, Was hast du mit dem Master Brick und openHAB vor? Bin mir da noch unschlüssig was sinnvoll abzubilden ist. Ich versuche ausschließlich mit Tinkerforge / AVM / Openhab eine Hausautomation zu realisieren (für ein kleines Wochenendhäuschen), als ich nun mit Deinem Binding die Masterbrick's in der Inbox sah, kam mir die Idee auch über Openhab prüfen zu lassen ob es neue FW gibt. Wenn man nun den Masterbrick direkt mit OpenHAB über einen Text-String nach seiner FW abfragen könnte, könnt man auch entsprechende Rules bauen. Das war allerdings ein Gedanke den ich noch nicht so ganz durchdacht habe Viele Grüsse Stefan P.S. Mit openhab1 und Tinkerforge-Komponenten läuft seit 2016 diese Hausautomation im dem Wochenendhäuschen. InnenLicht, Außenlicht, Gartensteckdosen, Pumpensteuerung, Frostschutz für Pflanzen, abschalten Steckdosen / Innen und Außenbeleuchtung wenn das Gebäude abgeschlossen wird, Alarmmeldung wenn die Glasbruch-Sensoren anschlagen, Bewegungsmelder für den Terrassenbeleuchtung nur wenn Gebäude aufgesperrt ist, Raumlüftung abhängig von der Absoluten innen und außen Luftfeuchte, einschalten Innenbeleuchtung wenn dunkel und Gebäude aufgesperrt wird ....... Quote Link to comment Share on other sites More sharing options...
rtrbt Posted September 13, 2019 at 03:10 PM Author Share Posted September 13, 2019 at 03:10 PM Moin, Ich habe mal wieder den Post editiert, Beta 4 mit vielen neuen unterstützten Bricklets ist veröffentlicht. @andreasOH: Node-RED ist derzeit nicht geplant, aber du kannst die MQTT-Bindings benutzen und dann von Node-RED aus MQTT sprechen. @StefanOHAN: Ich habe mal eingebaut, dass die Geräte ihre installierte Firmware bei der Discovery melden. openHAB zeigt das dann in den Thing-Eigenschaften an. Quote Link to comment Share on other sites More sharing options...
Jerome Posted September 14, 2019 at 05:47 PM Share Posted September 14, 2019 at 05:47 PM Vielen Dank für die neue Beta. Gerade getestet. GPS funktioniert super. Wie wird nun das Motion Bricklet angesteuert? Vielen Dank für deine Hilfe. Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted September 15, 2019 at 04:01 PM Share Posted September 15, 2019 at 04:01 PM Hallo Erik, ich habe eben Dein neues Binding (Version4) eingespielt, der HAT ist jetzt sichtbar und ich kann die Versorgungsspannung ablesen und die Bricklet-Spannung abschalten (echt cool). Die FW habe ich bei den Thing-Eigenschaften gefunden, muss aber gestehen dass ich jetzt nicht so recht weiß wie ich diese dann automatisiert auswerten kann, da der Gedanke eventuell die FW als Text-String auslesen zu können. Wenn es anders geht, würde mir das aber auch reichen. Dieser Punkt ist aber als "Nice to have" zu sehen, es gibt momentan wichtigere Punkte. Kurze Frage, wo finde ich nochmal die Informationen wo und was ich Konfigurieren kann ? Beispiel Analog wie Theo die Channel/Things für das 128x64 beschrieben hat. Momentan sehe ich für das 128x64 nur die Channels Text/Clear Display /Draw Buffertd Frame. Hast Du da irgendwo eine Beschreibung ? Ich hätte auch Fragen zum 16-fach IO, wie muss ich „Measured Level (Pin 0/A0)“ und „Edge Count Pin 0“ verstehen ? Kann ich das 16-fach IO weiterhin entweder als Eingang oder als Ausgang konfigurieren ? (Eingang z.B. für einen Endschalter eines Fenster/Tür, Ausgang zum ansteuern einer kleine LED Kontroll-Leuchte). Danke für das neuen Bindings :-) Viele Grüße Stefan Quote Link to comment Share on other sites More sharing options...
maxico Posted September 15, 2019 at 07:34 PM Share Posted September 15, 2019 at 07:34 PM Hi Erik, gerade Beta 4 getestet, mit openHAB 2.5.0 Build #1689: Kann es sein dass die bestehende Konfig von z.B. IO16 als Output Initial Low beim "discovery" mit Input überschrieben wird? Habe das IO16 Thing per PaperUI bei 3 Pins wieder auf Output Initial Low editiert. Jetzt kommt beim Initialisieren des IO16 beim Neustart von OH ein Fehler: 2019-09-15 21:26:40.207 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler@cd5941': No value present java.util.NoSuchElementException: No value presentat java.util.Optional.get(Optional.java:135) ~[?:?]at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.lambda$10(DeviceHandler.java:209) ~[?:?] at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:?]at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:?]at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) ~[?:?]at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) ~[?:?] at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) ~[?:?]at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) ~[?:?]at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566) ~[?:?]at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.configureChannels(DeviceHandler.java:210) ~[?:?]at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.initialize(DeviceHandler.java:110) ~[?:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [133:org.openhab.core:2.5.0.201909150302]at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [133:org.openhab.core:2.5.0.201909150302] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]at java.lang.Thread.run(Thread.java:748) [?:?] Quote Link to comment Share on other sites More sharing options...
rtrbt Posted September 16, 2019 at 09:43 AM Author Share Posted September 16, 2019 at 09:43 AM @Jerome: Wenn du ein Motion Detector 1.0 hast, gibt es zwei Trigger-Channel: Motion Detected löst aus, wenn eine Bewegung bemerkt wurde, Detection Cycle Ended, wenn ein Bewegungserkennungszyklus beendet ist. Der Motion Detector 2.0 hat zusätzlich noch Channel für die LEDs, da kannst du jeweils Zahlen von 0 (aus) bis 255 (volle Helligkeit) reingeben und die Empfindlichkeit ist konfigurierbar. @StefanOHAN: Hm die Firmwareversion scheint man (laut diesem Thread) nicht in einer Rule auslesen zu können. Aber wie du schon sagst, ist das eher was für die Nice-to-have-Liste. Doku findest du in der Zip im Ordner Docs. Das sind die Beschreibungen usw. für Channel und Parameter, die zeigt die PaperUI selsamerweise nicht an, deshalb erstmal so. Measured Level und Edge Counter sind die Channel, die die IO-16 dir gibt, wenn ein Pin auf Input konfiguriert ist. Measured Level ist einfach der aktuelle Wert (0 oder 1), Edge Counter kannst du als Flankenzähler benutzen. Wenn du einen Pin als Output konfigurierst (lies diesbezüglich auch den @maxico-Teil), bekommst du stattdessen Set Level- (das ist der Wert (0 oder 1) den du ausgeben möchtest) und Monoflop-Channel. @maxico: Bei der Discovery (genau genommen erst wenn du in der Inbox den Haken anklickst um das Thing hinzuzufügen) setzen die Bindings das jeweilige Gerät auf einen Standardzustand. Bei der IO-16 ist das alle Pins auf Input zu setzen. Unabhängig davon war aber ein Bug in der Pinkonfiguration, der dazu geführt hat, dass man die Pins nicht auf Output konfigurieren kann. Es gibt dann heute noch Beta 5, bei der das funktioniert. Quote Link to comment Share on other sites More sharing options...
Jerome Posted September 16, 2019 at 03:47 PM Share Posted September 16, 2019 at 03:47 PM Vielen Dank für deine Erklärung. Ich vermute es ist das selbe für Motion Detector Bricklet 2.0? Quote Link to comment Share on other sites More sharing options...
rtrbt Posted September 16, 2019 at 04:14 PM Author Share Posted September 16, 2019 at 04:14 PM Vielen Dank für deine Erklärung. Ich vermute es ist das selbe für Motion Detector Bricklet 2.0? Ja. Beta fünf ist im Post oben. Quote Link to comment Share on other sites More sharing options...
maxico Posted September 16, 2019 at 08:14 PM Share Posted September 16, 2019 at 08:14 PM Hi Erik, danke für Beta 5. Soeben getestet mit: Analog In (1.0): In den Paper UI "Configuration Parameters" gibt es den Measurement Range und den Moving Average Length. 1. Letzteres kann man in PaperUI nicht über 50 stellen, im brick viewer schon. 2. Theo hatte hier im 1er Binding noch eine callbackPeriod, das hat sehr geholfen dass OH nicht mit Werten geflutet wird, da standardmäßig jede Änderung ankommt. Das sind echt viele... mV Zappeln... IO 16 (1.0): Die Konfig. der Pins als Output funktioniert jetzt. Gruß Max Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted September 17, 2019 at 07:28 AM Share Posted September 17, 2019 at 07:28 AM Hallo Erik, danke erstmal für die neue Beta. Zu meiner Frage zum LCD128x64, das LCD hat ja eine Touchscreen und hier hatte Theo die Funktionen über actions verfügbar gemacht. Channels Display (textcommand) Button 0-11 (system.rawbutton => TriggerChannel) Slider 0-5 (DecimalValue 0-42) Tab 0-9 (TriggerChannel) z.B. actions.setGUIButton(0, 0, 0, 60, 20, "MeinButton0") Das habe ich jetzt so nicht in der Doku Deines ZipFile gefunden Oder sind die Action analog zu Theos Beschreibung schon verfügbar da diese über ander API bereit gestellt werden ? (komme leider erst am Sonntag dazu, das zu tesen). Und wenn ja wo finde ich diese Information Viele Grüsse Stefan P.S. Ich hoffe Dich nerven meine Fragen nicht. Ich vermute dass viele Informationen bereits irgendwo bei Tinkerforge zu finden sind. Bisher hatte hier Theo auf Git Kurzbeispiele für Openhab abgelegt, die das ganze etwas einfacher zu verstehen machten. Ich vermute Du testest die Funktionen der Bricklets in Openhab, wie sehen Deine Test so aus ? Item-Datei mit Item & Channel usw ? Rule-Datei mit Actions ? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.