Jump to content
rtrbt

Betaversion der openHAB-Bindings

Recommended Posts

Moin,

 

Ich habe die letzten Monate daran gearbeitet, unseren Binding-Generator so aufzubohren, dass auch openHAB-Bindings generiert werden können. Die 13. Beta findet sich hier.

 

Edit: Beta 13 mit Support für:

    - DC Brick

    - Master Brick

    - RED Brick

    - Servo Brick

    - Silent Stepper Brick

    - Stepper Brick

    - DMX Bricklet

    - E-Paper 296x128 Bricklet

    - One Wire Bricklet

    - Piezo Buzzer Bricklet

    - Piezo Speaker Bricklet

    - Piezo Speaker 2.0 Bricklet

, vervollständigtem Support für

    - IO4 2.0 Bricklet

    - LCD 16x2 Bricklet

    - LCD 20x4 Bricklet

    - LCD 128x64 Bricklet

    - OLED 64x48 Bricklet

    - OLED 128x64 Bricklet

    - OLED 128x64 2.0 Bricklet

, sowie kleineren Bugfixes und Actions für alle unterstützte Geräte.

 

Hier der Inhalt der README:

Installation:

    Die Bindings benötigen eine openHAB 2.5.0 Milestone/Snapshot Installation.

    Zum Installieren reicht es, die JAR 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. Nicht unterstützte Geräte haben "This

    device is not supported yet." in der Beschreibung. Zwecks Übersicht können

    diese versteckt werden.

 

    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 im doc-Unterordner der Bindings. Dort sind pro Gerät die

    unterstützten Konfigurationsparameter und Channel mit Beschreibung

    aufgelistet.

 

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]:[brick Daemon UID]:[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", das am Brick Daemon "8e8df7e6" angeschlossen ist eine graphische Oberfläche an:

   

    rule "startrule"

    when

        System started

    then

        var lcdActions = getActions("tinkerforge", "tinkerforge:lcd128x64:8e8df7e6:HQ6")

        lcdActions.clearDisplay()

        lcdActions.removeAllGUI();

        lcdActions.setGUIButton(0, 0, 0, 60, 20, "button");

        lcdActions.setGUISlider(0, 0, 30, 60, 0, 50);

        lcdActions.setGUIGraphConfiguration(0, 1, 62, 0, 60, 52, "X", "Y");

        lcdActions.setGUIGraphData(0, newArrayList(0, 10, 20, 40, 20, 15));

        lcdActions.setGUITabConfiguration(3, false);

        lcdActions.setGUITabText(0, "Tab A");

        lcdActions.setGUITabText(1, "Tab B");

    end

   

    Die Parameter und Rückgabewerte der Actions entsprechen denen der jeweiligen Funktionen der

    Java-Bindings https://www.tinkerforge.com/de/doc/Software/API_Bindings_Java.html

    Java-Bindings-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:lcd128x64:8e8df7e6:HQ6")

        pixels = lcdActions.readPixels(0, 0, 127, 63).get("pixels")

        val inverted = pixels.map[p | !p]

        lcdActions.writePixels(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. Ausgenommen sind nur Operationen,

    die den Zustand von Channel stören, hierfür müssen dem Channel zugeordnete Items mit .sendCommand

    verwendet werden. Außerdem nicht unterstützt werden Operationen, die EEPROM- oder Flash-Speicher

    der Geräte schreiben würden. Auch hier sollen unnötige Schreibzyklen vermieden werden.

   

    Die verfügbaren Actions pro Gerät werden im doc-Verzeichnis der Bindings aufgelistet,

    die Namen entsprechen denen der Java-Bindings, in denen sich genauere Dokumentation findet.

   

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)

       

    Manche Channel (z.B. Sensor Connected der PTC-Bricklets) aktualisieren

    ihren Wert nur, wenn ein RefreshCommand gesendet wird. Das ist aktuell

    nicht dokumentiert.

 

Bekannte Bugs:

    Gerätekonfiguration zeigt Bridge Selection an, aber nicht den

    (bereits konfigurierten) Brick Daemon. Editieren wirft Fehler.

 

    Display Bricklets zeigen auf der Übersichtsseite, solange noch kein Text

    gesendet wurde, '-' als Text an, wenn darauf geklickt wird NULL.

   

    Die Displayübersetzung benutzt im Moment für alle Displays das

    Character-Set vom LCD 20x4.

 

    PaperUI zeigt die Description von Channel(Typen) und

    Konfigurationsparameter-Gruppen nicht an. -> Sind im docs-Unterorder pro

    Gerät aufgeführt.

 

    Löschen von nicht angeschlossenen Geräten funktioniert nur manchmal: Der

    DeviceHandler versucht aufzuräumen, z.b. Callbacks zu deaktivieren. Falls

    das Gerät nicht erreicht wird, fliegen hier Timeouts. Das wird aktuell

    nicht korrekt behandelt.

 

    Generierter Code muss noch verbessert werden. Kompilieren erzeugt viele

    Warnungen, Listener(de)registrierungen werden teilweise dupliziert.

 

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.

 

Noch nicht unterstützte Geräte:

    CAN Bricklet

    CAN 2.0 Bricklet

    NFC Bricklet

    NFC-RFID Bricklet

    Remote Switch Bricklet

    Remote Switch 2.0 Bricklet

    RS232 Bricklet

    RS232 2.0 Bricklet

    RS485 Bricklet

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...