Betaversion der openHAB-Bindings

rtrbt · September 17, 2019 at 09:42

@maxico:

Das mit dem Averaging war ein Copy-Paste-Fehler, das Analog In 2 hat einen Moving Average, Version 1 einen "normalen" Durchschnitt. Das hatte ich irgendwie übersehen.

Du kannst die Channel selbst in der PaperUI auch konfigurieren, die meisten (wie auch das Analog In) haben ein Update Interval. Mit dem Bugfix gestern habe ich das Speichern der Channelkonfiguration aber zerlegt, heute Nachmittag kommt dann Beta 6, die das wieder repariert, sorry dafür.

@StefanOHAN:

Actions kann der Generator noch nicht, d.h. die GUI kannst du mit den Bindings noch nicht benutzen. Das steht noch auf meiner TODO-Liste.

Die Fragen nerven nicht, im Gegenteil, das Feedback ist immer hilfreich. Ich teste immer mit der PaperUI, das geht schneller. Du kannst aber auch Rule-Dateien verwenden, die Items würde ich aber über die UI anlegen, das spart Tipp-Arbeit.

rtrbt · September 17, 2019 at 16:13

Beta 6 ist jetzt im Post oben.

KlausGünther · September 17, 2019 at 17:25

Dann setze ich auf die Wunschliste das Outdoor Weather Bricklet (Ja habe gelesen das das schwierig ist und bereits auf der To-Do Liste).

maxico · September 17, 2019 at 18:12

Hallo Erik,

Beta 6 Test:

- IO16 (1.0): Alle auf Output konfigurierten Pins haben Monoflop. Passt. Edge Count haben nur Pin0 und Pin1, obwohl ich keinen Unterschied in der Konfig zu anderen auf Input konfigurierten Pins sehe...

- AnalogIn (1.0): Thing aus PaperUI Inbox erstellen klappt, Channel aus Thing erstellen nicht (über "Create Bridge" Schaltfläche bei "Edit Thing"). Im Log erscheint kein Fehler, nur in PaperUI erscheint ein kurzes Popup mit "500 - Internal Server Error". Der Standardchannel Voltage ist aber vorhanden und kann jetzt editiert werden mit dem Update Interval in ms. Passt.

rtrbt · September 18, 2019 at 07:51

Das IO16 kann nur auf den ersten beiden Pins Flanken zählen, deshalb siehst du nur die beiden Channel. Das ist hier (etwas notdürftig) dokumentiert.

Das Analog In hat nur den Voltage-Channel. Die Sache mit dem Create Bridge-Button ist kaputt, aber darüber sollten keine Channels angelegt werden, den kannst du also ignorieren. (Den gibt es bei jedem Gerät und er tut nichts)

BusinessTux · September 18, 2019 at 16:12

Hallo rtrbt,

ich stehe aktuell vor der Frage, ob das openHAB v1-Binding ein IO16 (v1) auch initialisiert (Ports auf out setzt), da nach einem Stromausfall meins nicht initialisiert wurde, und dadurch die Regeln in openHAB nicht mehr gegriffen haben.

Alternativ, gibt es eine v2-Version des Bindings, dass ich mit openHAB 2.4.0 testen kann?

Version: 2.4.0 (Build)

User: openhab (Active Process 421)

User Groups: openhab

Directories: Folder Name | Path | User:Group

------------------------ | ---- | ----------

OPENHAB_HOME | /usr/share/openhab2 | openhab:openhab

OPENHAB_RUNTIME | /usr/share/openhab2/runtime | openhab:openhab

OPENHAB_USERDATA | /var/lib/openhab2 | openhab:openhab

OPENHAB_CONF | /etc/openhab2 | openhab:openhab

OPENHAB_LOGDIR | /var/log/openhab2 | openhab:openhab

OPENHAB_BACKUPS | /var/lib/openhab2/backups | root:root

URLs: http://192.168.1.10:8080

https://192.168.1.10:8443

Danke

Ulf

rtrbt · September 19, 2019 at 09:22

Wegen dem openHAB v1-Binding musst du Theo fragen, da bin ich nicht im Thema.

Die v2-Bindings brauchen openHAB 2.5. Es hat sich zuviel in den Schnittstellen getan (u.A. ist ja das Eclipse Smarthome-Projekt gestorben), als dass es sich lohnen würde, die Bindings rückzuportieren.

BusinessTux · September 19, 2019 at 09:24

Danke. Dann hoffe ich mal, dass 2.5 bald stable wird.

maxico · September 19, 2019 at 12:29

Hallo Ulf,

wie hast Du das OH 1er Binding konfiguriert? Über tinkerforge.cfg? Zeig doch mal Deine Konfig, dann läßt es sich besser verstehen und vielleicht helfen.

Hast Du die Beschreibung im Link beachtet?

https://www.openhab.org/addons/bindings/tinkerforge1/#io-16-bricklet

Bei mir funktioniert auch nach einem Stromausfall die Konfiguration wieder.

Gruß

Max

BusinessTux · September 19, 2019 at 15:16

Hallo Max,

danke für Deine Reaktion. Um diesen Thread nicht zu sprengen, habe ich dafür mal einen eigenen angelegt: https://www.tinkerunity.org/forum/index.php/topic,5107.0.html

Danke

Ulf

rtrbt · September 20, 2019 at 14:22

Moin,

Beta 7 ist jetzt im Post oben. Das Readme listet jetzt die noch nicht unterstützten Geräte auf, die Liste ist kürzer.

Jerome · September 21, 2019 at 10:49

Danke vielmals für die neue Beta.

Soweit wird alles erkannt und funktioniert.

Eine Frage zu dem LED 2.0 Bricklet. Was ist genau der Eintrag um die LED's zu kontrollieren via openhab?

In der Sitemap habe ich folgenden Eintrag:

Colorpicker item=LEDIndoor label="LED Light Indoor" icon="colorwheel"

In der Items List folgendes:

Color LEDIndor "LED Indoor" <colorpicker> { channel="tinkerforge:ledstripv2:0c06d0bb:KvP:LEDStripV2LEDValues" }

Passieren tut aber nix.

Via Brickv kann ich den LED Bricklet 2.0 sauber ansteuern und alles mögliche machen mit dem LED Stripe.

BusinessTux · September 21, 2019 at 15:10

Hallo,

ich habe mir heute mein Prod-System geklont auf 2.5 aktualisiert. Dazu habe ich die Beta 7 geladen.

Den Masterbrick konnte ich anlegen und es wurden auch die Bricklets gefunden. Der IO16 wurde eingelesen, hat aber alle Ausgänge auf Input gesetzt, obwohl sie tlw. als Output konfiguriert waren.

Wenn ich den IO16 in der PaperUI auf Output-Ports stellen möchte, bekomme ich in der Anzeige kurz ein HTTP-500-Popup und im openhab.log folgende Meldung:

2019-09-21 17:03:08.295 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/tinkerforge:io16:b13811f0:CDP/config'
java.util.NoSuchElementException: No value present
        at java.util.Optional.get(Optional.java:135) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.lambda$10(DeviceHandler.java:217) ~[?:?]
        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:218) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.initialize(DeviceHandler.java:111) ~[?:?]
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.handleConfigurationUpdate(BaseThingHandler.java:144) ~[?:?]
        at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.updateConfiguration(ThingRegistryImpl.java:91) ~[?:?]
        at org.eclipse.smarthome.io.rest.core.internal.thing.ThingResource.updateConfiguration(ThingResource.java:438) [152:org.openhab.core.io.rest.core:2.5.0.M3]
        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.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [124:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [124:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [124:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [124:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [124:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [124:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [125:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [122:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [122:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [122:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [122:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [122:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [20:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873) [90:org.eclipse.jetty.servlet:9.4.18.v20190429]
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542) [90:org.eclipse.jetty.servlet:9.4.18.v20190429]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [193:org.ops4j.pax.web.pax-web-jetty:7.2.10]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [87:org.eclipse.jetty.security:9.4.18.v20190429]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1700) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [193:org.ops4j.pax.web.pax-web-jetty:7.2.10]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) [90:org.eclipse.jetty.servlet:9.4.18.v20190429]
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1667) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [193:org.ops4j.pax.web.pax-web-jetty:7.2.10]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.server.Server.handle(Server.java:505) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) [89:org.eclipse.jetty.server:9.4.18.v20190429]
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) [80:org.eclipse.jetty.io:9.4.18.v20190429]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [80:org.eclipse.jetty.io:9.4.18.v20190429]
        at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [80:org.eclipse.jetty.io:9.4.18.v20190429]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [92:org.eclipse.jetty.util:9.4.18.v20190429]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [92:org.eclipse.jetty.util:9.4.18.v20190429]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [92:org.eclipse.jetty.util:9.4.18.v20190429]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [92:org.eclipse.jetty.util:9.4.18.v20190429]
        at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [92:org.eclipse.jetty.util:9.4.18.v20190429]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:698) [92:org.eclipse.jetty.util:9.4.18.v20190429]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:804) [92:org.eclipse.jetty.util:9.4.18.v20190429]
        at java.lang.Thread.run(Thread.java:748) [?:?]

Gibt es eigentlich schon ein Beispiel für die Konfiguration per things-Datei?

Danke

Ulf

StefanOHAN · September 22, 2019 at 19:08

Hallo Erik

heute habe ich in der „ITEM.item“ verschiedene Channel mit Items verlinkt.

Unter Configuration/System ist bei „Item Linking“ der Simple-Mode abgeschaltet.

Als Binding kam Deine Beta 6 zum Einsatz.

Test Industrial Quadrelay v2:

Das Verlinken in der Item-Datei hat funktioniert, das Relais konnte über die PaperUi bedient werden.

Test MotionDetector V2:

die 3 LED‘s habe ich über Number-Items mit den Channels verlinkt. Über zwei Rules die Trigger-Channel „MotionDetected“ und „DetectionCycleEnded“ zum ein und ausschalten der 3 LED genutzt. Hat ohne Probleme funktioniert.

Test 16-Fach-IO V2

Das Konfigurieren eines „Input-Channel“ des 16-Fach-IO hat wunderbar geklappt

So sieht mein Eintrag in der „ITEM.item“ Datei aus. Der Port reagiert als Öffner (wenn GND mit B0 verbunden wird)

Switch Pin8 "16fach B0 input [%s]" (TestTF) {channel = "tinkerforge:io16v2:b0b51208:HHb:IO16V2InputPin8"}

Allerdings bin ich beim Output konfigurieren gescheitert :'(

Laut Deiner kurz Doku

Zitat

Pin Configuration 0/A0 (choice): Configures the direction of pin 0/A0. Inputs without pull-up will be floating if nothing is connected. Outputs can have an initial state of low or high.

Hätte ich vermutet dass unter ../Configuration/Things/ eine Auswahl bezüglich input und output getroffen kann. Ist aber nicht so.

Ich habe es dann auf Gut-Glück mit folgender Verlinkung versucht (einfach Input durch Output ersetzt), dies funktionierte nicht (es kam auch eine entsprechende Fehler Meldung im LOG) Update: Frage der Konfiguration hat sich erledigt

Switch Pin9 "16fach B1 out [%s]" (TestTF) {channel = "tinkerforge:io16v2:b0b51208:HHb:IO16V2OutputPin9"}

Mit den anderen Optionen für das 16-Fach IO kann ich nichts anfangen, da diese mir nichts sagen.

Zwei Fragen hätte ich:

1) für was nutze ich den „Edge Count Pin 1/A1“ nachdem er Item-Typ Number hat, kann er doch nur zum Zählen genutzt werden, oder ?

2) wie müsste mein Verlinken in der ITEM-Datei aussehen wenn ich einen Output konfigurieren möchte. Und muss ich unter ../Configurations/Things noch etwas anpassen ? Update vom 23.09.2019 dank Ulf's (Business Tux) hat sich diese Frage erledigt

Weiter Bricklets werde ich im laufe der Woche über die Item-Datei mit den Channel‘s verlinken und testen.

Viele Grüße

Stefan

P.S. meine Hw-Konfiguration: Raspi3 mit „HAT Brick“ daran angeschlossen Multi-Touch / LCD-128x64 / LCD 20x4 sowie ein Master-Brick Nr1 (v2.1) über USB an dem RaspPi angeschlossen. Im Stapel des Master-Brick Nr1 befindet sich eine RS485 Extension, die die Verbindung zum Master-Brick Nr2 (v2.1) herstellt. Der Master-Brick Nr2 wird durch ein separates Netzteil mit Spannung versorgt. Am Master-Brick Nr2 ist der Motion-Dedector V2 sowie ein 16-Fach-IO (V2) angeschlossen.

Bisher hatte ich immer Probleme mit dieser Konfiguration, da nach einem Restart nicht immer alle Bricklets am Stapel des Master-Brick Nr2 online gingen. Ich habe heute mehrfach das Openhab System als auch den Pi neu gestartet, und es gingen immer all Bricklets online

BusinessTux · September 23, 2019 at 07:20

Hallo Stefan,

die Konfiguration der Output-Channels habe ich in der Konfiguration des IO16 in der PaperUI gefunden:

Wenn man es dort den Port aber auf Output umstellt, gibt es aber noch Fehlermeldungen im openhab.log.

Wenn ich den IO16 in der PaperUI auf Output-Ports stellen möchte, bekomme ich in der Anzeige kurz ein HTTP-500-Popup und im openhab.log folgende Meldung:

@Erik: Bei Starten von openHAB kommen die Fehlermeldungen aus meinem vorherigen Thread auch:

2019-09-23 09:14:16.232 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler@3153b9f7': No value present
java.util.NoSuchElementException: No value present
        at java.util.Optional.get(Optional.java:135) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.lambda$10(DeviceHandler.java:217) ~[?:?]
        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:218) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.initialize(DeviceHandler.java:111) ~[?:?]
        at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source) ~[?:?]
        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.M3]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [133:org.openhab.core:2.5.0.M3]
        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) [?:?]

2019-09-23 09:14:16.295 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'tinkerforge:io16:b13811f0:CDP': No value present
java.util.NoSuchElementException: No value present
        at java.util.Optional.get(Optional.java:135) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.lambda$10(DeviceHandler.java:217) ~[?:?]
        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:218) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.initialize(DeviceHandler.java:111) ~[?:?]
        at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source) ~[?:?]
        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.M3]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [133:org.openhab.core:2.5.0.M3]
        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) [?:?]

Dadurch geht das IO16 auch gar nicht online:

sv021:~# openhab-cli info

Version:     2.5.0.M3 (Build)

User:        openhab (Active Process 5076)
User Groups: openhab tty dialout audio

Directories: Folder Name      | Path                        | User:Group
             -----------      | ----                        | ----------
             OPENHAB_HOME     | /usr/share/openhab2         | openhab:openhab
             OPENHAB_RUNTIME  | /usr/share/openhab2/runtime | openhab:openhab
             OPENHAB_USERDATA | /var/lib/openhab2           | openhab:openhab
             OPENHAB_CONF     | /etc/openhab2               | openhab:openhab
             OPENHAB_LOGDIR   | /var/log/openhab2           | openhab:openhab
             OPENHAB_BACKUPS  | /var/lib/openhab2/backups   | root:root

URLs:        http://192.168.1.9:8080
             https://192.168.1.9:8443

Mein Stack:

Viele Grüße

Ulf

StefanOHAN · September 23, 2019 at 08:28

Hall Ulf, hallo Erik

Ulf danke für den Hinweis, ich konnte zwar die Config jetzt umstellen (danke Deines Hinweises) Aber wie bei Dir, kommt die gleiche Fehlermeldung im Log und das Bricklet hat den Status "UNINITIALIZED-HANDLER_INITALIZING_ERROR" unter ../Configuration/Things.

Allerdings ploppt bei mir eine PopUp-Fenster hoch.

Ulf kurze Frage: Kontest Du mit dem Output arbeiten ? Bei mir hat das ganze 16-Fach IO den Betrieb eingestellt.

Ich habe mich dunkel daran erinnert, dass Theo's 1er-Binding nur funktionierte wenn mann alle A oder B Ports entweder auf Input oder auf Output konfiguriert Ein Mix von Input und Output im in einem Port (A oder B) funktionierte nicht.

Ich stelle dann alle Pins des A-Port auf Output, ohne Erfolg. Auch eine Konfiguration aller Pins auf OUTPUT funktioniert nicht.

Jetzt mal so eine Frage in die Runde, wäre hätte den Lust gemeinsam mit mir hier in einem separation Post Konfigurations-Beispiele zu pflegen ?

Ich glaub es wäre auch für Neueinsteiger etwas einfacher wenn wir hier und nicht unter Openhab soetwas pflegen würden, oder was meint Ihr ?

viele Grüsse

Stefan

rtrbt · September 23, 2019 at 12:51

Moin,

@Jerome: Das LED Strip Bricklet hat einen LED Values-Channel, in den du Text geben kannst (also StringCommands). Der Text muss eine Komma-separierte Liste von Zahlen sein, dabei ist die erste Zahl die erste LED die du steuern möchtest, danach folgen die Farben für die LEDs als RGB oder RGBW (also drei oder vier Zahlen jeweils von 0 bis 255), je nachdem ob du RGB oder RGBW-LEDs hast. Zum Beispiel kannst du mit 2,255,0,0,0,255,0,0,0,255 die zweite angeschlossene LED auf rot, die dritte auf grün und die vierte auf blau setzen. Wenn du das mit einem ColorPicker steuern willst, musst du dir eine Regel schreiben, die vom HSBCommand, dass der ColorPicker ausgibt, auf so einen String übersetzt.

@Stefan, Ulf: Die Fehler beim Umkonfigurieren der IO-16-Pins treten, zumindest bei mir, nur auf, wenn zwischen dem Hinzufügen des Bricklets zu openHAB und der Konfiguration ein openHAB-Neustart liegt. Was da passiert ist, dass die Bindings vergessen, welche Channel unterstützt werden und dann beim umkonfigurieren nicht die "neuen" Channel findet. Ich habe die ganze Channelrekonfiguration mal umgebaut, das kommt nachher in Beta 8 und fixt hoffentlich alle Pinkonfigurationsprobleme die aufgelaufen sind.

1) für was nutze ich den „Edge Count Pin 1/A1“ nachdem er Item-Typ Number hat, kann er doch nur zum Zählen genutzt werden, oder ?

Genau, damit kannst du Flanken zählen, z.B. wie oft eine 10ml-Schaufel an einem selbstgebauten Regenzähler auslöst, damit du dann ausrechnen kannst, wie viel Regen gefallen ist oder sowas.

Gruß,

Erik

BusinessTux · September 23, 2019 at 15:12

Hallo Stefan,

Allerdings ploppt bei mir eine PopUp-Fenster hoch.

das ploppt bei mir auch hoch.

Ulf kurze Frage: Kontest Du mit dem Output arbeiten ? Bei mir hat das ganze 16-Fach IO den Betrieb eingestellt.

Es ist nach dem Neustart auch vollständig außer Gefecht.

Jetzt mal so eine Frage in die Runde, wäre hätte den Lust gemeinsam mit mir hier in einem separation Post Konfigurations-Beispiele zu pflegen ?
Ich glaub es wäre auch für Neueinsteiger etwas einfacher wenn wir hier und nicht unter Openhab soetwas pflegen würden, oder was meint Ihr ?

Da bin ich dabei. Ich muss meine 1er-Konfiguration sowieso noch umschreiben.

@Stefan, Ulf: Die Fehler beim Umkonfigurieren der IO-16-Pins treten, zumindest bei mir, nur auf, wenn zwischen dem Hinzufügen des Bricklets zu openHAB und der Konfiguration ein openHAB-Neustart liegt. Was da passiert ist, dass die Bindings vergessen, welche Channel unterstützt werden und dann beim umkonfigurieren nicht die "neuen" Channel findet. Ich habe die ganze Channelrekonfiguration mal umgebaut, das kommt nachher in Beta 8 und fixt hoffentlich alle Pinkonfigurationsprobleme die aufgelaufen sind.

Danke.

Ulf

rtrbt · September 23, 2019 at 15:20

Beta 8 ist im Post oben. Diesmal ohne neue Bricklets, das Outdoor Weather Bricklet braucht noch etwas Überzeugungsarbeit. Der Channelrekonfigurationsbug sollte aber behoben sein.

BusinessTux · September 23, 2019 at 16:15

Daaanke. Jetzt sind keine Fehler mehr im Log, die Ports lassen sich auf Output umstellen und schalten auch. Weitere Testergebnisse gibt es morgen.

maxico · September 23, 2019 at 19:52

Hallo,

Test Beta 8 mit openHAB 2.5.0 Build #1690

IO16 (1.0): Hinzufügen des Things klappt, Channel konfigurieren auf Output auch. Ansteuern auch.

Industrial Digital Out 4 (1.0): Monoflop Channel konfigurieren (Zeit) funktioniert. Ansteuern auch. (Die Standardzeit von 1000ms finde ich persönlich bisschen viel, aber ist im BrickViewer ja auch so. Dafür kann mans ja ändern.) Im Log ist beim Triggern des Monoflop Channels folgendes zu sehen:

2019-09-23 21:49:42.785 [ome.event.ItemCommandEvent] - Item 'RD9_MonoflopPin3' received command TRIGGER

2019-09-23 21:49:42.792 [nt.ItemStatePredictedEvent] - RD9_MonoflopPin3 predicted to become TRIGGER

"PredictedEvents" habe ich sonst keine. Ist das normal?

OH-TF-Konfig-Beispiele kann ich gerne beisteuern. Ein einheitliches, universelles Format wäre sicher hilfreich.

Gruß

Max

StefanOHAN · September 24, 2019 at 07:09

Hallo Erik

Gestern habe ich weitere Funkionen und Bricklets per Channel-Verlinken getestet.

Noch mit Binding Beta7, Beta8 werde ich heute Abend testen (output 16-Fach-IO)

Test Tinkerforge Humidity Bricklet 2.0

Humidity / Temperatur konnte ich problemlos mit Number-Items verlinken, den Heater mit einem Switch-ITEM.

Die „sampel-rate“ habe ich auf 0.1 eingestellt, hat auch wunderbar funktioniert.

Temperatur und Luftfeuchte werden sauber angezeigt, wenn ich das Heater-Switch-Item betätige sieht man dass sich die Werte für Luftfeuchte und Temperatur verändern, somit dürfte der Heater funktionieren.

Frage: Mit „Humidity Moving Average Length“ habe ich doch Einfluss auf das Messverhalten bei Schwankungen, wie muss ich diese Werte interpretieren ? z.B. „10“ bedeutet nur Schwankungen > 0.1 ? (in der Werte Auflösung sehe ich 2 Nachkommastellen, daher meine Vermutung)

Test Tinkerforge Multi Touch Bricklet:

Alle Electroden-Channel konnte ich mit Switch-Item verknüpfen, beim berühren haben die Switch-Item den Status auf ON und wieder auf OFF gewechselt.

Test Tinkerforge Industrial Quad Relay Bricklet 2.0

Hier habe ich jetzt noch ein String-Item für das Monoflop Relay0 verlinkt und wenn ich über die „PaperUi / Control“ Website den „trigger“ betätigte hat das zugehörige Relais auf ON und anschließend wieder auf OFF gewechselt. Hat gut funktioniert.

Hierzu hätte ich eine Frage:

Ich habe anschließende per Rule die Trigger-Funktion auslösen lassen. Ich hätte vermutet dass ich dem String des verlinkten Monoflop dem Werte „triggerd“ oder „TRIGGER“ zuweisen muss.

Dies hat auch funktioniert, das zum Monoflop zugehörige Relay hat sich ein und anschließend wieder ausgeschaltet.

Frage: „Ist es egal welchem Wert man dem String zuweist ?“ Ich hab mit verschieden Schreibweisen gearbeitet und es hat immer geklappt.

Meine Rule

rule "monoflop-Industrial RelaisR0"
when
Item Pin0 changed to ON
then
QuadV1MF.sendCommand(„TRIGGER“)
end

letzter Test des Tage „Spannungs-Ausfall am Remote-Master-Brick-Stapel“

Mein Master-Brick Nr2 ist über eine RS485 Extension mit Master-Brick Nr1 verbunden. Master-Brick Nr 1 ist über USB mit dem Pi verbunden.

Am Master-Brick Nr2 ist ein 16-FACH-IO angeschlossen, für diese habe ich einen INPUT Channel mit einem Switch-ITEM verlinkt. An diesem ist ein Schließer-Taster angeschlossen.

Test Spannungsabfall am Remote-Stapel

Bei Ausfall der Versorgungsspannung behält das ITEM seinen Status, wenn während der Zeitspanne zwischen Spannungsausfall und Wiederherstellen der Spannungsversorgung der Zustand des „Realen-Taster“ verändert wird, hat nach Wiederherstellen der Spannungsversorgung das ITEM einen entsprechenden Update erhalten.

Auch dieser Test war aus meiner Sicht erfolgreich

Viele Grüße

rtrbt · September 24, 2019 at 07:38

Moin,

Freut mich, dass so viel schon funktioniert. Danke nochmal für die rigorosen Tests

[quote name="maxico

2019-09-23 21:49:42.792 [nt.ItemStatePredictedEvent] - RD9_MonoflopPin3 predicted to become TRIGGER

"PredictedEvents" habe ich sonst keine. Ist das normal?

Das ist ein "fancy new feature" wie es die openHAB-Entwickler hier nennen. Der Hintergrund ist wohl, dass openHAB vorhersagt, das Zustandsänderungen funktionieren werden, falls das entsprechende Thing nicht offline ist. Das wird hier genauer erklärt. Das muss ich mir nochmal genauer ansehen, ob das für alle Geräte eine gute Idee ist, oder ich es eventuell im Generator wegkonfiguriere.

Frage: „Ist es egal welchem Wert man dem String zuweist ?“

Ja, das ist egal. Hintergrund ist, dass ich ein StringItem mit CommandOptions benutze, da damit in der PaperUI Buttons erzeugt werden. Für Channel, bei denen es nur eine mögliche Aktion gibt ist mir dann aber egal, was der genaue Text ist, sobald ein Item reinkommt, löst die Aktion aus.

rtrbt · September 24, 2019 at 08:33

Tinkerforge Humidity Bricklet 2.0
Frage: Mit „Humidity Moving Average Length“ habe ich doch Einfluss auf das Messverhalten bei Schwankungen, wie muss ich diese Werte interpretieren ? z.B. „10“ bedeutet nur Schwankungen > 0.1 ? (in der Werte Auflösung sehe ich 2 Nachkommastellen, daher meine Vermutung)

Ah die Frage hatte ich übersehen. Du kannst ja beim Humidity Bricklet die Sample-Rate konfigurieren, wenn die wie bei dir auf 0.1 steht, dann misst das Bricklet alle 10 Sekunden. Damit weniger Rauschen auf den Daten ist, gibt das Bricklet aber nicht den Rohwert aus, sondern mittelt die letzten n Werte. Dieses n ist der Humidity Moving Average Length. Standardmäßig sind das 5, d.h. das Bricklet gibt den Durchschnitt über die letzten 5 Messwerte, also 50 Sekunden aus. Wenn du das Bricklet auf eine so niedrige Sample-Rate stellst, ist es vermutlich sinnvoll, die Durchschnittsberechnung abzuschalten (also den Moving Average auf 1 zu setzen), damit der Wert nicht ganz so träge ist.

rtrbt · September 24, 2019 at 15:08

Beta 9 mit Support für das Outdoor Weather Bricklet ist jetzt im Post oben.

Betaversion der openHAB-Bindings

Recommended Posts

Link zu diesem Kommentar

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

rtrbt

StefanOHAN

StefanOHAN

Posted Images

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Join the conversation