Jump to content

BusinessTux

Members
  • Gesamte Inhalte

    19
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von BusinessTux

  1. Ich würde hier gerne mal einhaken, weil ich gerade vor dem selben Problem stehe. Mit Brick Viewer 2.3.XX konnte ich mit meiner Proxy-Konfiguration noch die Downloadserver erreichen. Der Viewer hat mir nämlich angezeigt, dass Updates für die Brick(s,lets) anstehen. Daher habe ich den Viewer zuerst upgedatet. Leider habe ich danach keinen Zugriff mehr auf den Download-Server. Weder mit Proxy-URL, noch mit statischem Proxy, noch mit Automatischer Suche des Proxys in Windows 10 (1903). Ich sehe immer nur die Blockierungen der direkten Zugriffe in der Firewall.

    Die Umstellung auf https, kann dafür eigentlich nicht der Grund sein. https wird normalerweise genauso über den Proxy geleitet, wie http.

    Gibt es eine Proxy-Option für den Brick Viewer?

    Danke

    Ulf

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

  3. Hallo Stefan,

     

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

    preview

     

    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:

    preview

     

    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:

    preview

     

    Viele Grüße

    Ulf

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

  5. Die Zeilen aus der events.log in dem Zeitraum habe ich angehängt.

     

    Setze ich die Ports dann über den Brickviewer, bekommt openHAB das auch direkt mit und es funktioniert alles wieder.

    openhab.log:

    2019-09-20 13:19:14.940 [iNFO ] [thome.model.script.Paketkasten.rules] - Rule: <Proxy Item LED Fach unten aktualisieren>, triggeringItem: PaketkastenLedUntenGruen (Type=SwitchItem, State=ON, Label=LED unten grün, Category=null, Groups=[gPaketkasten])
    2019-09-20 13:19:14.947 [iNFO ] [thome.model.script.Paketkasten.rules] - Rule: <Proxy Item LED Fach oben aktualisieren>, triggeringItem: PaketkastenLedObenGruen (Type=SwitchItem, State=ON, Label=LED oben grün, Category=null, Groups=[gPaketkasten])
    2019-09-20 13:19:14.955 [DEBUG] [thome.model.script.Paketkasten.rules] - Rule: <Proxy Item LED Fach oben aktualisieren>, Variable: LedFachObenFarbe, Wert: 2, Typ: java.math.BigDecimal
    2019-09-20 13:19:14.962 [DEBUG] [thome.model.script.Paketkasten.rules] - Rule: <Proxy Item LED Fach oben aktualisieren>, Item: PaketkastenLedFachOben (Type=NumberItem, State=2, Label=LED Fach oben, Category=shield, Groups=[gPaketkasten]), State-Typ: org.eclipse.smarthome.core.types.UnDefType
    2019-09-20 13:19:14.969 [DEBUG] [thome.model.script.Paketkasten.rules] - Rule: <Proxy Item LED Fach unten aktualisieren>, Variable: LedFachUntenFarbe, Wert: 2, Typ: java.lang.Integer
    2019-09-20 13:19:14.979 [DEBUG] [thome.model.script.Paketkasten.rules] - Rule: <Proxy Item LED Fach unten aktualisieren>, Item: PaketkastenLedFachUnten (Type=NumberItem, State=2, Label=LED Fach unten, Category=shield, Groups=[gPaketkasten]), State-Typ: org.eclipse.smarthome.core.library.types.DecimalType
    

     

    events.log:

    2019-09-20 13:19:13.435 [vent.ItemStateChangedEvent] - PaketkastenLedObenGruen changed from OFF to ON
    2019-09-20 13:19:13.451 [vent.ItemStateChangedEvent] - PaketkastenLedUntenGruen changed from OFF to ON
    2019-09-20 13:19:14.963 [vent.ItemStateChangedEvent] - PaketkastenLedFachOben changed from NULL to 2
    2019-09-20 13:19:14.977 [vent.ItemStateChangedEvent] - PaketkastenLedFachUnten changed from NULL to 2
    

     

    openHAB und TF-Stack sind in zwei separaten Netzwerk-Segmenten untergebracht. Vom openHAB-Server zum TF-Stack sind die Ports TCP/4280 und TCP/4223 freigegeben (falls das relevant ist).

     

    Danke

    Ulf

    events.log

  6. Hallo Theo,

     

    danke für den Hinweis mit dem Testing-Zweig. Den habe ich noch nicht entdeckt gehabt. Ich habe gerade erst angefangen.

     

    Ich habe die Situation jetzt mal nachgestellt. openHAB angehalten, den TF-Stack stromlos gemacht und wieder angeschlossen, openHAB gestartet. Danach sind die B-Ports standardmäßig wieder als Input konfiguriert:

    preview

     

    Hier die Logs nach dem Start.

    openhab.log:

    2019-09-20 13:05:46.302 [iNFO ] [egram.internal.TelegramActionService] - Bot ukopenhabbot loaded from config file
    2019-09-20 13:05:46.339 [iNFO ] [egram.internal.TelegramActionService] - Bot ukopenhabdebugbot loaded from config file
    2019-09-20 13:05:47.376 [WARN ] [.jetty.internal.ServerControllerImpl] - SSL password and SSL keystore password must be set in order to enable SSL.
    2019-09-20 13:05:47.380 [WARN ] [.jetty.internal.ServerControllerImpl] - SSL connector will not be started
    2019-09-20 13:05:48.223 [iNFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Europe/Berlin'.
    2019-09-20 13:05:48.235 [iNFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to 'XX.XXXXXXX,X.XXXXXXX'.
    2019-09-20 13:05:48.237 [iNFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to 'de_DE'.
    2019-09-20 13:05:48.309 [iNFO ] [ebuilder.internal.HomeBuilderServlet] - Started Home Builder at /homebuilder
    2019-09-20 13:05:48.520 [iNFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
    2019-09-20 13:05:52.075 [iNFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = XXXXXXXX-c53d-4943-93c6-XXXXXXXXXXX, base URL = http://localhost:8080)
    2019-09-20 13:05:56.153 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Gaestezimmer.items'
    2019-09-20 13:05:56.293 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'GaesteWC.items'
    2019-09-20 13:05:56.367 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Haus.items'
    2019-09-20 13:05:56.467 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Paketkasten.items'
    2019-09-20 13:05:56.563 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'sonos.items'
    2019-09-20 13:05:56.635 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Dreambox.items'
    2019-09-20 13:05:56.666 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Wohnzimmer.items'
    2019-09-20 13:05:56.732 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Keller.items'
    2019-09-20 13:05:56.795 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Astro.items'
    2019-09-20 13:05:56.818 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Kueche.items'
    2019-09-20 13:05:56.836 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Schlafzimmer.items'
    2019-09-20 13:05:56.883 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Arbeitszimmer.items'
    2019-09-20 13:05:56.935 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Wetter.items'
    2019-09-20 13:05:57.520 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mapdb.persist'
    2019-09-20 13:06:02.159 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Astro.rules'
    2019-09-20 13:06:03.732 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Paketkasten.rules'
    2019-09-20 13:06:07.817 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Rolllaeden.rules'
    2019-09-20 13:06:07.896 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Waschkueche.rules'
    2019-09-20 13:06:07.985 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Dreambox.rules'
    2019-09-20 13:06:08.120 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'Waschkueche.rules' is either empty or cannot be parsed correctly!
    2019-09-20 13:06:08.285 [iNFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
    2019-09-20 13:06:08.737 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Administration.sitemap'
    2019-09-20 13:06:08.821 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Haussteuerung.sitemap'
    2019-09-20 13:06:09.101 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mqtt.things'
    2019-09-20 13:06:09.372 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'sonos.things'
    2019-09-20 13:06:09.717 [iNFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'astro:sun:local' to inbox.
    2019-09-20 13:06:09.738 [iNFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'astro:moon:local' to inbox.
    2019-09-20 13:06:10.096 [iNFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:moon:local
    2019-09-20 13:06:10.423 [iNFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:local
    2019-09-20 13:06:10.444 [iNFO ] [ding.astro.handler.AstroThingHandler] - Scheduled Positional job astro:sun:local every 300 seconds
    2019-09-20 13:06:10.606 [iNFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:local
    2019-09-20 13:06:10.681 [iNFO ] [ding.astro.handler.AstroThingHandler] - Scheduled Positional job astro:sun:local every 300 seconds
    2019-09-20 13:06:11.130 [iNFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.1.10:8080
    2019-09-20 13:06:11.132 [iNFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.1.10:8443
    2019-09-20 13:06:11.389 [iNFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
    2019-09-20 13:06:11.891 [iNFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '10.0.7.80' with clientid openHABsv020 and file store '/var/lib/openhab2/mqtt/10.0.7.80'
    2019-09-20 13:06:11.999 [iNFO ] [b.core.service.AbstractActiveService] - HTTP Refresh Service has been started
    2019-09-20 13:06:12.812 [iNFO ] [b.core.service.AbstractActiveService] - Tinkerforge Refresh Service has been started
    

    Laut letzter Zeile scheint alles in Ordnung zu sein.

     

  7. Hallo zusammen,

     

    ich habe bei mir einen Brick

    preview

    mit einem IO16 laufen, um meinen Paketkasten zu steuern (LEDs, Türöffner, Türkontakte). Diese habe ich per openHAB-Binding v1 in meine openHAB-Installation (2.4.0) eingebunden.

     

    Ich hatte vorletzte Nacht einen Stromausfall, der länger war, als die USV überbrücken konnte (der Brick wird über PoE versorgt). Nachdem der Strom wieder da war, wurden die B-Ports aber nicht auf Out gesetzt, so dass die angeschlossenen LEDs (RGB) nicht korrekt leuchteten (B0 - B2 = LED1 R-G-B, B3 - B5 = LED2 R-G-B).

     

    Wenn ich das mit 1er-Binding noch hinbekäme, wäre das auch super. Das Tinkerforge v2-Binding funktioniert erst mit openHAB 2.5, was noch nicht released und damit nicht als Debian-Paket verfügbar ist.

     

     

    Meine tinkerforge.cfg sieht wie folgt aus:

    # IP addresses / Hostnames  of the hosts running the brickd (optional port 
    # separated by a colon, defaults to 4223) 
    # hosts=
    hosts=paketkasten.han.edvnet-uk.com::XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    
    paketkasten_tempe.uid=zbX
    paketkasten_tempe.type=bricklet_temperature
    paketkasten_tempe.slowI2C=False
    
    paketkasten_relay_1.uid=EcL
    paketkasten_relay_1.subid=relay1
    paketkasten_relay_1.type=dual_relay
    paketkasten_relay_2.uid=EcL
    paketkasten_relay_2.subid=relay2
    paketkasten_relay_2.type=dual_relay
    
    paketkasten_io16.uid=CDP
    paketkasten_io16.type=bricklet_io16
    paketkasten_io16.debouncePeriod=100
    
    paketkasten_io16_a0.uid=CDP
    paketkasten_io16_a0.subid=ina0
    paketkasten_io16_a0.type=iosensor
    paketkasten_io16_a0.pullUpResistorEnabled=true
    paketkasten_io16_a1.uid=CDP
    paketkasten_io16_a1.subid=ina1
    paketkasten_io16_a1.type=iosensor
    paketkasten_io16_a1.pullUpResistorEnabled=true
    paketkasten_io16_a2.uid=CDP
    paketkasten_io16_a2.subid=ina2
    paketkasten_io16_a2.type=iosensor
    paketkasten_io16_a2.pullUpResistorEnabled=true
    paketkasten_io16_a3.uid=CDP
    paketkasten_io16_a3.subid=ina3
    paketkasten_io16_a3.type=iosensor
    paketkasten_io16_a3.pullUpResistorEnabled=true
    
    
    paketkasten_io16_b0.uid=CDP
    paketkasten_io16_b0.subid=outb0
    paketkasten_io16_b0.type=io_actuator
    paketkasten_io16_b1.uid=CDP
    paketkasten_io16_b1.subid=outb1
    paketkasten_io16_b1.type=io_actuator
    paketkasten_io16_b2.uid=CDP
    paketkasten_io16_b2.subid=outb2
    paketkasten_io16_b2.type=io_actuator
    paketkasten_io16_b3.uid=CDP
    paketkasten_io16_b3.subid=outb3
    paketkasten_io16_b3.type=io_actuator
    paketkasten_io16_b4.uid=CDP
    paketkasten_io16_b4.subid=outb4
    paketkasten_io16_b4.type=io_actuator
    paketkasten_io16_b5.uid=CDP
    paketkasten_io16_b5.subid=outb5
    paketkasten_io16_b5.type=io_actuator

     

    Es geht um die B-Kanäle, die als Ausgang definiert sein sollen.

     

    Wenn die Ports einmal korrekt konfiguriert sind, funktioniert auch die openHAB-Regeln zum Schalten der LED-Farben.

     

    Sollte das Tinkerforge-Binding die Ports auch bei der Initialisierung korrekt setzen?

     

    Danke

    Ulf

    TinkerforgeBrick.png.e2296624364830d642baae55f64ab3a0.png

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

  9. Hallo zusammen,

     

    ich glaube ich habe es mit den Vorwiderständen noch nicht richtig verstanden :-(.

    Ich möchte zwei RGB-LEDs über einen IO-16 mit eingeschalteten 3,3 V betreiben. Da Blau und Grün mit 3,3 V arbeiten und nur Rot mit 1,95 V, brauche ich doch nur für die rote LED einen Vorwiderstand, oder? Die zwei anderen kann ich direkt anschließen, oder?

     

    Da jeder Port des IO-16 20 mA liefert, sollten die LEDs mit 20 mA auch funktionieren?

     

    Wenn eine Steinigung notwendig ist, last Euch nicht von abbringen ;D

     

    Danke

    Ulf

  10. Hallo Equinox,

     

    ja, Callback hört sich besser an. Der Begriff ist mir in den letzten Tagen auch schon mal in irgendeinem HowTo untergekommen. Das wird das Ziel sein.

     

    Wenn ich die API-Bindings richtig verstanden habe, registriert sich mein Programm dann an der API des Masters Bricks und warte auf Callbacks, die von den Sensoren ausgelöst werden. Dann passt ja auch wieder Deine erste Aussage mit dem entgegennehmen.

     

    Danke. Dann werde ich mal bestellen.

    Viele Grüße

    Ulf

  11. Hallo Equinox,

     

    danke für die Infos und sorry, dass ich mich nicht gemeldet habe. STandardmäßig wird man nach der Neuregistrierung leider nicht benachrichtigt. Das habe ich gerade umgestellt.

     

    Was fehlt, ist ein Rechner, auf dem dein Programm läuft, d.h., der die Werte des IO-4 Bricklets entgegennimmmt und deinen Webservice aufruft. Dafür kannst du z.B. den Tinkerforge RED Brick nehmen oder einen Raspberry Pi.

    Ok. Mich verwirrt gerade noch den Begriff "entgegennimmt". Ich hatte es bisher so verstanden, der Netzwerk-Master-Brick die angeschlossen Bricklet-Daten als API per Netzwerk-Schnittstelle bereitstellt. Also würde ich ein Programm auf einem Rechner laufen lassen, dass die API-Bindings nutzt und die Daten ständig ausliest und den Aufruf des Webservices macht, oder? Da ich sowieso eine openHAB-Installation machen will, kann ich das ja darauf machen. Der MiniPC sollte dafür ja problem herhalten.

     

    Inzwischen habe ich vor das WLAN-Modul und die Powerbank durch die Ethernet-PoE-Masterbrick zu ersetzen. Dann brauche ich mich nicht auch noch um das Akku-Monitoring zu kümmern.

     

    Für welche Situationen setzt man lieber den IR- bzw. den US-Distance-Sensor ein? Bei mir sollen ja eher kleine Abstände mit großem Winkel gemessen/überwacht werden.

     

    Dann werde ich mal noch ein bisschen Dokus lesen.

     

    Danke

    Ulf

  12. Hallo zusammen,

     

    nachdem ich mich die letzten Tage hier auf Tinkerforge eingelesen habe, möchte ich mich an einem kleine Projekt mit Tinker-Modulen versuchen. Ich wäre aber sehr dankbar, wenn ihr mir kurz antworten könntet, ob das wahrscheinlich machbar ist.

     

    Ziel:

    Ich möchte drei Reed-Kontakte aus meinem Paketkasten überwachen und bei Auslösung einen (später zwei) Webservice-Aufrufe starten um mich benachrichtigen zu lassen.

     

    Planung Einkaufs-/Teileliste

    • Powerbank als Stromversorgung
    • Masterbrick
    • WIFI Master Extension 2.0
    • IO-4 Bricklet
    • Bricklet Kabel
    • Befestigungsset

     

    Wenn ich das richtig verstanden habe, sollte diese Zusammenstellung selbständig laufen, wenn sie einmal eingestellt ist.

     

    Was ich noch nicht richtig verstanden habe ist, wie die Aktionen ausgelöst werden. Ich baue also die Teile zusammen und kann mit dem Brickviewer die Werte der per IO-4 Bricklet angeschlossenen Kontakte auslesen. Ich muss mir ein Mini-Programm erstellen, dass aus der Änderung dann einen Webservice-Aufruf macht, um meine Zentrale zu informieren. Als Zentrale werde ich anfangs einen Webservice des Paketkastenherstellers nutzen. Später möchte ich eine Homeautomation mit OpenHAB (oder ähnlich) aufbauen und dahin den Webservice aufrufen.

     

    Evtl. möchte ich noch Abstandssensoren (z.B. Distance US Bricklet) an den Masterbrick anschließen, die messen sollen, ob das Paket-/Brieffach aktuell gefüllt ist oder nicht.

     

    Dann bin ich mir noch unsicher, wie ich das ganze montieren kann. Ich habe zwar gelesen, dass man die Stapel zusammenstecken und auch verschrauben kann, als Gehäuse habe ich aber nur Einzelgehäuse pro Sensor oder die MakerBeam-Profile gefunden. Ich würde Master- und WIFI-Brick schon gerne in ein abgeschlossenes Gehäuse stecken. Die MakerBeam-Profile sind ja auf allen Seiten offen. Muss ich mir das irgendwie selber anfertigen oder gibt es dafür Empfehlungen von Euch?

     

    Eine Menge Fragen, ich weiß. Aber bevor ich etwas kaufe, wäre ich sehr froh über ein paar Rückmeldungen von Euch. Erfahrungstechnisch bin ich Handwerker und Linux-Administrator.

     

    Danke

    Ulf

×
×
  • Neu erstellen...