Betaversion der openHAB-Bindings

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.

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

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

Hallo Erik,

danke für die schnelle Antwort

Es wird auf jedem Fall dann Theo die Arbeit erleichtern

viele Grüsse

Stefan

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

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

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.

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

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

Super Sache!

Vermisst wird immer noch das GPS sowie das LED Stripe Bricklet.

Liebe Grüsse

C'mon translate that to english, I'm waiting for those proper binding for months.

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

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.

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

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!

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

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.

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.

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

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) [?:?]

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

Vielen Dank für deine Erklärung. Ich vermute es ist das selbe für Motion Detector Bricklet 2.0?

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.

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

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 ?