Tinkerunity

Deutsch => Allgemeine Diskussionen => Topic started by: rtrbt on September 05, 2019, 14:25:43

Title: Betaversion der openHAB-Bindings
Post by: rtrbt on September 05, 2019, 14:25:43
Moin,

Ich habe die letzten Monate daran gearbeitet, unseren Binding-Generator so aufzubohren, dass auch openHAB-Bindings generiert werden können. Die elfte Beta findet sich hier (https://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta11.zip).

Edit: Beta 11 mit Backlight-Channel für das LCD 128x64.

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 Bricklets 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 Bricklets
    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.
   
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)
   
    Für Displays: Aktuell ist nur Textausgabe, Clearen des Displays und
    Kontrolle des Backlights möglich. Weitere Funktionen wie GUI und Anzeigen
    von Bildern (also Setzen von Pixel) sind in Arbeit: Der Generator
    unterstützt zur Zeit noch keine Actions.
   
    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:
    Brickletkonfiguration 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:
    DC Brick
    Master Brick
    RED Brick
    Servo Brick
    Silent Stepper Brick
    Stepper Brick
    CAN Bricklet
    CAN 2.0 Bricklet
    DMX Bricklet
    E-Paper 296x128 Bricklet
    NFC Bricklet
    NFC-RFID Bricklet
    One Wire Bricklet
    Piezo Buzzer Bricklet
    Piezo Speaker Bricklet
    Piezo Speaker 2.0 Bricklet
    Remote Switch Bricklet
    Remote Switch 2.0 Bricklet
    RS232 Bricklet
    RS232 2.0 Bricklet
    RS485 Bricklet

Nur teilweise unterstützte Geräte:
    IO4 2.0 Bricklet # PWM Support fehlt. Modellierung? (Frequenz/Duty Cycle als Channel, Konfiguration oder komplexer Channel mit Parsing wie bei Displays, eventuell Action?)   
    LCD 16x2 Bricklet # Siehe Display-Bricklets-Abschnitt
    LCD 20x4 Bricklet # Siehe Display-Bricklets-Abschnitt
    LCD 128x64 Bricklet # Siehe Display-Bricklets-Abschnitt
    OLED 64x48 Bricklet # Siehe Display-Bricklets-Abschnitt
    OLED 128x64 Bricklet # Siehe Display-Bricklets-Abschnitt
    OLED 128x64 2.0 Bricklet  # Siehe Display-Bricklets-Abschnitt
   
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 06, 2019, 09:07:03
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
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 06, 2019, 09:22:40
Moin,

Der Generator ist dieser hier (https://github.com/Tinkerforge/generators). 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
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 06, 2019, 09:58:13
Hallo Erik,


danke für die schnelle Antwort
Es wird auf jedem Fall dann Theo die Arbeit erleichtern

viele Grüsse
Stefan
Title: Re: Betaversion der openHAB-Bindings
Post by: piwo2 on September 09, 2019, 16:09:28
!!!!!!!!!!!!! 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
Title: Re: Betaversion der openHAB-Bindings
Post by: maxico on September 10, 2019, 11:53:19
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
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 10, 2019, 12:10:16
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.
Title: Re: Betaversion der openHAB-Bindings
Post by: maxico on September 10, 2019, 16:58:02
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...
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 10, 2019, 17:09:11
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 ;)
Title: Re: Betaversion der openHAB-Bindings
Post by: Jerome on September 10, 2019, 19:22:01
Super Sache!

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

Liebe Grüsse
Title: Re: Betaversion der openHAB-Bindings
Post by: xsherlock on September 11, 2019, 19:03:18
C'mon translate that to english, I'm waiting for those proper binding for months.
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 11, 2019, 21:29:13
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
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 12, 2019, 11:47:09
Moin,
Hier (https://download.tinkerforge.com/_stuff/tinkerforge_openhab_bindings_2_0_0_beta3.zip) 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 (https://www.tinkerunity.org/forum/index.php/topic,5098.msg28083.html#msg28083).
Title: Re: Betaversion der openHAB-Bindings
Post by: andreasOH on September 12, 2019, 21:24:15
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
Title: Re: Betaversion der openHAB-Bindings
Post by: maxico on September 12, 2019, 21:34:02
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!
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 13, 2019, 07:29:22
Hallo Erik

zu Deiner Frage,
Quote
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 .......
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 13, 2019, 17:10:24
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.
Title: Re: Betaversion der openHAB-Bindings
Post by: Jerome on September 14, 2019, 19:47:41
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.
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 15, 2019, 18:01:22
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
Title: Re: Betaversion der openHAB-Bindings
Post by: maxico on September 15, 2019, 21:34:44
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) [?:?]

Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 16, 2019, 11:43:08
@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 (https://community.openhab.org/t/oh2-read-property-of-a-thing-in-rule/20412)) 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.
Title: Re: Betaversion der openHAB-Bindings
Post by: Jerome on September 16, 2019, 17:47:53
Vielen Dank für deine Erklärung. Ich vermute es ist das selbe für Motion Detector Bricklet 2.0?
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 16, 2019, 18:14:08
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.
Title: Re: Betaversion der openHAB-Bindings
Post by: maxico on September 16, 2019, 22:14:34
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
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 17, 2019, 09:28:09
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.
Quote
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 ?
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 17, 2019, 11:42:47
@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.
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 17, 2019, 18:13:21
Beta 6 ist jetzt im Post oben.
Title: Re: Betaversion der openHAB-Bindings
Post by: KlausGünther on September 17, 2019, 19:25:36
Dann setze ich auf die Wunschliste das Outdoor Weather Bricklet (Ja habe gelesen das das schwierig ist und bereits auf der To-Do Liste).
Title: Re: Betaversion der openHAB-Bindings
Post by: maxico on September 17, 2019, 20:12: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.



Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 18, 2019, 09:51:32
Das IO16 kann nur auf den ersten beiden Pins Flanken zählen, deshalb siehst du nur die beiden Channel. Das ist hier (https://www.tinkerforge.com/de/doc/Software/Bricklets/IO16_Bricklet_Java.html#BrickletIO16::setEdgeCountConfig__short-.short-.short-) (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)
Title: Re: Betaversion der openHAB-Bindings
Post by: BusinessTux on September 18, 2019, 18:12:18
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
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 19, 2019, 11:22:35
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.
Title: Re: Betaversion der openHAB-Bindings
Post by: BusinessTux on September 19, 2019, 11:24:00
Danke. Dann hoffe ich mal, dass 2.5 bald stable wird.
Title: Re: Betaversion der openHAB-Bindings
Post by: maxico on September 19, 2019, 14:29:06
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
Title: Re: Betaversion der openHAB-Bindings
Post by: BusinessTux on September 19, 2019, 17:16: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 (https://www.tinkerunity.org/forum/index.php/topic,5107.0.html)

Danke
Ulf
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 20, 2019, 16:22:05
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.
Title: Re: Betaversion der openHAB-Bindings
Post by: Jerome on September 21, 2019, 12:49:41
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:

Code: [Select]
Colorpicker item=LEDIndoor label="LED Light Indoor" icon="colorwheel"
In der Items List folgendes:

Code: [Select]
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.
Title: Re: Betaversion der openHAB-Bindings
Post by: BusinessTux on September 21, 2019, 17:10:33
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:
Code: [Select]
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
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 22, 2019, 21:08:57
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)
Quote
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
Quote
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

Quote
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  :D
Title: Re: Betaversion der openHAB-Bindings
Post by: BusinessTux on September 23, 2019, 09:20:26
Hallo Stefan,

die Konfiguration der Output-Channels habe ich in der Konfiguration des IO16 in der PaperUI gefunden:
(https://cloud.edvnet-uk.com/index.php/s/P2EmjnwHmZZ4WBG/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:
Code: [Select]
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:
(https://cloud.edvnet-uk.com/index.php/s/tkMBKHC9bn9mTy3/preview)

Code: [Select]
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:
(https://cloud.edvnet-uk.com/index.php/s/3jMFmrdzAkjz8pZ/preview)

Viele Grüße
Ulf
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 23, 2019, 10:28:45
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
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 23, 2019, 14:51:31
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
Title: Re: Betaversion der openHAB-Bindings
Post by: BusinessTux on September 23, 2019, 17:12:43
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
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 23, 2019, 17:20:26
Beta 8 ist im Post oben. Diesmal ohne neue Bricklets, das Outdoor Weather Bricklet braucht noch etwas Überzeugungsarbeit. Der Channelrekonfigurationsbug sollte aber behoben sein.
Title: Re: Betaversion der openHAB-Bindings
Post by: BusinessTux on September 23, 2019, 18:15:59
Daaanke. Jetzt sind keine Fehler mehr im Log, die Ports lassen sich auf Output umstellen und schalten auch. Weitere Testergebnisse gibt es morgen.
Title: Re: Betaversion der openHAB-Bindings
Post by: maxico on September 23, 2019, 21:52:59
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
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 24, 2019, 09:09:01
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
Quote
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
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 24, 2019, 09:38:13
Moin,

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

Quote from: 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 (https://community.openhab.org/t/what-is-itemstatepredictedevent/52387/2) nennen. Der Hintergrund ist wohl, dass openHAB vorhersagt, das Zustandsänderungen funktionieren werden, falls das entsprechende Thing nicht offline ist. Das wird hier (https://github.com/eclipse/smarthome/pull/5011) 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.
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 24, 2019, 10:33:12
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.
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 24, 2019, 17:08:31
Beta 9 mit Support für das Outdoor Weather Bricklet ist jetzt im Post oben.
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 25, 2019, 08:36:36
Hallo Erik,
Heute habe ich mit dem Beta9 Binding weiter getestet.

Leider funktioniert jetzt der Motion-Dedector nicht mehr. Ich habe Ihn aus der Konfiguration entfernt, dann das System neu gestartet und erneut als Thing hinzugefügt, aber er reagiert nicht mehr. (nach abgeschlossenen Test habe ich das Beta7 Binding wieder eingespielt und der Motion-Dedector funktionierte wieder).

Fehlermeldung im Log:

Quote
2019-09-24 19:39:53.633 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler@88e18a': null
java.lang.NullPointerException: null
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.buildChannel(DeviceHandler.java:206) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.configureChannels(DeviceHandler.java:238) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.initialize(DeviceHandler.java:117) ~[?:?]
        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.201909190301]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [133:org.openhab.core:2.5.0.201909190301]
        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) [?:?]
==> /var/log/openhab2/events.log <==
2019-09-24 19:39:53.682 [hingStatusInfoChangedEvent] - 'tinkerforge:motiondetectorv2:b0b51208:Hz1' changed from INITIALIZING to UNINITIALIZED (HANDLER_INITIALIZING_ERROR)
==> /var/log/openhab2/openhab.log <==
2019-09-24 19:39:53.685 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'tinkerforge:motiondetectorv2:b0b51208:Hz1': null
java.lang.NullPointerException: null
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.buildChannel(DeviceHandler.java:206) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.configureChannels(DeviceHandler.java:238) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.initialize(DeviceHandler.java:117) ~[?:?]
        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.201909190301]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [133:org.openhab.core:2.5.0.201909190301]
        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) [?:?]

Weiter im Test:

Test 16-Fach-IO output
nach Rekonfiguration und Anpassen des Verlinkten-Channel in der ITEM-Datei, konnte ich über die PaperUI/config den Switch für den Port betätigen und eine kleine LED ein und ausschalten.

Test Outdoor Weather Bricklet / Outdoor Weather Temperature/Humidity Sensor TH-6148 :

Über „Bridge Selection“ konnte ich meinen Sensor Typ TH-6148 hinzu fügen. Anschließend habe ich in der ITEM-Datei die 3 sichtbaren Channel verlinkt. Die Temperatur / Luftfeuchte und die letzte Änderung wurden sauber angezeigt.

Frage zum Outdoor Weather Temperature/Humidity Sensor TH-6148 :
Erik, ist es möglich auch noch einen „Batterie“ Status anzeigen zu lassen ?

Im laufe der Woche werde ich das 128x64 LED Testen.

Erik noch eine Frage zum NFC-Bricklet, was planst Du alles für diese Bricklet ?
- Ich würde es gerne für Security Themen verwenden, wenn ich das richtig verstanden habe muss dazu aber auf einen gesicherten Bereich zugegriffen werden.

@ Ulf, @ Max, wie wollen wir das mit den Beispielen machen ? Was hättet Ihr für Vorschläge ?



Viele Grüsse Stefan
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 25, 2019, 12:04:26
Leider funktioniert jetzt der Motion-Dedector nicht mehr.
Da ich habe beim Umbauen der Channelrekonfiguration eine Feinheit für Trigger-Channel übersehen, das wird mit Beta 10 (heute Nachmittag) wieder funktionieren.
Frage zum Outdoor Weather Temperature/Humidity Sensor TH-6148 :
Erik, ist es möglich auch noch einen „Batterie“ Status anzeigen zu lassen ?
Nein, da das der Sensor selbst nicht meldet.
Erik noch eine Frage zum NFC-Bricklet, was planst Du alles für diese Bricklet ?
- Ich würde es gerne für Security Themen verwenden, wenn ich das richtig verstanden habe muss dazu aber auf einen gesicherten Bereich zugegriffen werden.
Geplant ist, für das NFC-Bricklet die API für einfache Anwendungsfälle zu erweitern und dann mit openHAB diese API zu verwenden, da die aktuelle API zu komplex ist um sie abbilden zu können. Das wird aber noch eine Weile dauern.
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 25, 2019, 17:16:35
Beta 10 ist jetzt im Post oben.
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 26, 2019, 08:58:00
Hallo Erik

Test mit Binding 10

der Motion-Dedector funktioniert wieder.

Zum „Weather Temperature/Humidity Sensor TH-6148“
Erik Du schreibst dass dieser Sensor nicht den Batteriezustand liefern kann. Ich konnte auf Euer Website keine Information finden in welchen Zeitintervallen der Sensor Daten übermittelt. Wenn nun der Sensor immer in gleichen (oder fast gleichen) Intervallen die Daten übermittelt, könnte ich eine Rule schreiben die einfach eine Warnung aus gibt wenn der Sensor eine gewisse Zeit keine Daten übermittelt hat.
Frage: Liefert der Sensor immer in gleichen Zeitintervallen Daten, oder nur wenn sich die Werte ändern ?

Weiter mit dem Test

Test LCD 20x4
das Verlinken der verschieden Channel hat funktioniert.
Die Button-Taster melden im Log „triggered PRESSED / RELEASED“

Einschalten und Ausschalten des Backlight sowie Clear des Display über eine Rule (durch betätigen eines der Button), hat problemlos funktioniert.

Probleme hatte ich anfangs mit der Formatierung des String für die Textausgabe auf dem Display.
Mit etwas Testen habe ich dann erkannt, dass der gesamte Ausdruck in Hochkomma gesetzt werden muss.

Quote
rule "LCD20x4 Text schreiben"
    when
        Channel "tinkerforge:lcd20x4:b0b51208:abc:LCD20x4Button1" triggered
    then
    LCD20x4_text.sendCommand("1,1,Test new" + " addon")
end

Zum LCD 128x64: (hier habe ich noch nicht alles getestet)
Gibt es für das Backlight nur eine feste "Konfigurationsmöglichkeit, also nicht über Channel‘s. Ist das korrekt ?
Wenn ja, könnte Du bitte für das Backlight einen Channel einbauen (ähnlich wie beim LCD20x4). Es ist etwas unpraktisch wenn das Backlight nicht direkt angesteuert und verändert werden kann.

Noch einen Frage zum MasterBrick:
Nachdem ich in meiner grössten Installation 3 MasterBick-Stapel (die alle über USB angeschlossen sind) nutze, dachte ich mir, es wäre gut wenn man die Master-Brick's per Rule überwachen kann. Nachdem ich in Zukunft auch die RS485 Extention nutzen will wäre diese Funktion sehr hilfreich.
Frage: Sieht Du die Möglichkeit eines Channel (online/offline) für den MasterBrick die per Trigger in einer Rule verarbeitet werden kann ?

Grüsse

Stefan
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 26, 2019, 10:17:56
Frage: Liefert der Sensor immer in gleichen Zeitintervallen Daten, oder nur wenn sich die Werte ändern ?
Der Sensor liefert alle 45 Sekunden Daten. Ich habe das mal an die Channel-Dokumentation angehangen. Da das Outdoor-Weather-Bricklet handgeschrieben ist, erscheint das aber noch nicht in meinem improvisierten Dokumentationsgenerator.
Mit etwas Testen habe ich dann erkannt, dass der gesamte Ausdruck in Hochkomma gesetzt werden muss.
Stimmt, der Channel will StringTypes, in Regeldateien brauchst du deshalb die Anführungszeichen.
Zum LCD 128x64: (hier habe ich noch nicht alles getestet)
Gibt es für das Backlight nur eine feste "Konfigurationsmöglichkeit, also nicht über Channel‘s. Ist das korrekt ?
Wenn ja, könnte Du bitte für das Backlight einen Channel einbauen (ähnlich wie beim LCD20x4).
Hm, das sehe ich mir mal an, eigentlich sollte das ein Channel sein.
Frage: Sieht Du die Möglichkeit eines Channel (online/offline) für den MasterBrick die per Trigger in einer Rule verarbeitet werden kann ?
Das könnte eventuell gehen. Rausfinden, ob ein Master Brick offline ist, ist nicht ganz trivial, aber da kann ich eventuell was bauen.
Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on September 27, 2019, 15:13:47
Beta 11 ist jetzt im Post oben. Das LCD 128x64 hat jetzt einen Backlight-Channel. Außerdem können jetzt Decimal, Quantity oder PercentTypes in Channel gegeben werden, die Zahlen erwarten (wie z.b. den Backlight-Channel).

Ich bin erstmal zwei Wochen im Urlaub, werde aber immer mal in den Thread sehen, falls Fragen auftauchen.
Title: Re: Betaversion der openHAB-Bindings
Post by: KlausGünther on September 28, 2019, 11:35:29
So, ich bin wieder aus dem Urlaub zurück:

Getestet mit Beta 11 (Auf OH 2.5M3)
Luftfeuchtigkeit (jeweils 2.0), alles ohne Probleme.
Particular Matter ebenfalls ohne Probleme.

Barometer 2.0
Der Druck von 1.0 bar kommt als ein Wert von 10.0 an, liegt das an mit oder stimmt da was nicht ?

UV 2.0
Bei dem Index steht jetzt bei mir in der Sitemap "one" wo die Einheiten stehen. Das Ding ist natürlich ohne Einheit, is klar, aber ist das ein OH Fehler oder kommt das vom Binding so mit ?
Title: Re: Betaversion der openHAB-Bindings
Post by: rak on September 29, 2019, 11:58:05
Hallo zusammen,

Ich versuche mich an der Installation. Mein OH läuft im Docker. Aktuell in der v2.5.0.M1. Ich habe das binding im addons folder entzipt.

In karaf sehe ich folgende Fehlermeldung.

11:37:31.810 [ERROR] [.core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-tinkerforge'

Habt ihr einen Tipp für mich?

Mit 2.5.0.M3 habe ich das selbe Verhalten.

Danke.
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on September 29, 2019, 13:39:23
Hallo Erik,

erst mal schönen Urlaub für Dich :-)

Beim LCD 128x64 funktioniert jetzt das Backlight :-)
Text schreiben und Display-clear funktionieren analog zum LCD 20x4.
Den Draw-Channel hab ich aus Ideen-Mangel noch nicht getestet.

Jetzt werde ich erst mal ein paar zusätzlichen TF Bricklets bestellen.

@ rak
kurze Frage, hast Du über die karaf-console erst das alte Binding entfernt ?
Ich entpacke den Zip immer auf einen anderen PC (ich nutze einen RasPi 3b ; OS = Openhabian v1.5 ; Openhab = 2.5.0-SNAPSHOT Build #1673), deinstalliere über die karaf-Console das alte Binding, stoppe Openhab und anschließend kopiere ich das Binding in das Addon-Verzeichnis. Nach dem Restart von Openhab funktioniert es wieder.

viele Grüsse Stefan
Title: Re: Betaversion der openHAB-Bindings
Post by: rak on September 30, 2019, 22:43:40
@Stefan, danke. In M3 konnte ich das TF jetzt installieren. Ein Brick ist angeschlossen, aber wurde nicht erkannt. Mir war nicht klar, dass man zusätzlich zum Binding auch noch den Brick Daemon installieren muss
https://www.tinkerforge.com/de/doc/Embedded/Raspberry_Pi.html (https://www.tinkerforge.com/de/doc/Embedded/Raspberry_Pi.html).

Macht eigentlich Sinn ,-). Mea culpa. Geht jetzt.

Grosses Lob! Automatische Erkennung geht. Items erstellen war dann ein NoBrainer
Title: Re: Betaversion der openHAB-Bindings
Post by: Wannes on October 04, 2019, 08:08:00
Hello,
I think ran into a bug.
Setup:
-raspi 3B
-openhab 2.5 snapshot
-tinker binding version 11 loaded as .jar
-maserbrick with dual relay brick and industrial in 4 brick.

After power loss on my tinker stack and a power up again the commands from openhab don't seem to come true anymore.
Only after restart of the binding my relais and inputs work again in openhab.
The bricks seem to reconnect fine.
I added a debug log disconnecting and reconnecting again.

regards,
j.
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on October 08, 2019, 08:54:33
Hello Wannes,

What do you mean with
Quote
After power loss on my tinker stack and a power up again the commands from openhab don't seem to come true anymore.

Does it mean you can't send command with rules to the Stack ?

I want to reconfigure my Test-System and try if I even get the same Problem.



with regards Stefan
Title: Re: Betaversion der openHAB-Bindings
Post by: MacDuff on October 08, 2019, 16:23:45
Ich probiere nun auch die 2.5 Bindings -- mit gemischten Resultaten.
Nach vollständigem Start von openhab (auf einem Jetson Nano) soll eine Meldung auf dem LCD20x4 erscheinen:

Code: [Select]
rule "STARTUP"
when
System started
then
logInfo("System Startup", "now")
LCDBacklight.sendCommand(ON)
LCD.sendCommand("1,1, OpenHab started")
end

LCD und Backlight sind als Items so definiert:
Code: [Select]
String LCD "LCD" (t47, tinkerforge){channel="tinkerforge:lcd20x4:71e71e18:rXd:LCD20x4Text"}

Switch LCDBacklight "LCDBacklight" (t47, tinkerforge) {channel="tinkerforge:lcd20x4:71e71e18:rXd:LCD20x4Backlight"}

Das Backlight kann ich im PaperUI Control ein-/ausschalten; auch über den Switch im Basic UI. Den gewünschten Effekte beim Hochfahren des Maschinchens hatte ich bisher nur zweimal (von vielleicht zwei Dutzend Versuchen.) Auch das Beschreiben des LCDs ist in anderen Konstellationen fehlgeschlagen. Ah ja, und öfters heißt es bei den TF-Komponenten "OFFLINE-BRIDGE_OFFLINE".
Was ist hier faul?
merci, macduff
Title: Re: Betaversion der openHAB-Bindings
Post by: Wannes on October 08, 2019, 19:50:10
Hi Stefan,

I will try to explain a bit more:

1) I start with everything working fine...
2) When i switch of and on the power on my tinker forge bricks, (with system running fine)
3) Everyting "tinker-like" item seems to disconnect and reconnect fine according the logs?
4) BUT! when i toggle any switch(thing) in openhab to command a tinker output , nothing happens? and no error is logged?
5) After a restart of the openhab tinkerforge binding(reloading the .rar file), it all works again.


So basically, the connection between openhab and my tinker outputs gets lost after a power of/on of the tinkerforge bricks.

So if the power on my bricks is interrupted during the day, my garage does not open when i come home :)

Kind regards,
Wannes

Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on October 08, 2019, 21:16:13
Hello Wannes,

I changed my configuration

Now I have Stack2 with
-step-down Power Supply
-RS485 Extention Slave (connected with the RS485 Extention on Stack1)
-Masterbrick 2.1
 ->Dualrelais V2
 ->Industrial In V2

at Stack2
-RS485 Extenion Master
-Masterbrick 2.1 (is via USB conneted with the Raspberry)
 ->IO-16 V2

One Port of the 16-IO (Port 0 = Item Pin0) is at the ITEM-File configured as an Input.

If I switch the DualRelais"0" ON, the Idustrial-IN geht on Port3 5V power.

with that Rule I can switch on/off DualRelais"0"
Quote
rule "test dualrelais "
    when
        Item Pin0 changed to ON
    then
   
    if (DualRelay1.state != ON ) { DualRelay1.sendCommand (ON) } else { DualRelay1.sendCommand (OFF) }
end

During my test I was switch 4 Time on/off the Powersupply at Stack2.

But I get no error, the rule was working and via the rule I could swith on/off the DualRelais"0" and even the Industrial-IN Port3 was switching to on/off if the Rule switched the DualRelais on/off.

maybe there is an other difference between our configurations

Greetings Stefan
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on October 08, 2019, 21:27:55
Hallo MacDuff

ich habe Deine Rule kopiert und angepasst (Item-Namen) und bei mir funktioniert es.

Einziger unterschied ist, dass Dein ITEM-Name ausschließlich aus Grossbuchstaben besteht.
Wenn ich mich dunkel erinnere, gibt es eine Syntax für ITEMs
"Das erste Zeichen muss ein Grossbuchstabe sein, aber es drüfen nicht alle Zeichen Grossbuchstaben sein."

Probier mal, ob bei Anpassung der ITEM-Namen-Syntax das Problem behoben ist

Meine Item/Channel verlinkung  sieht wie folgt aus
Quote
String LCD20x4_text "LCD20x4 [%s]" (TestTF) { channel="tinkerforge:lcd20x4:b0b51208:abc:LCD20x4Text"}

Grüsse Stefan
Title: Re: Betaversion der openHAB-Bindings
Post by: Wannes on October 09, 2019, 06:12:58
Hi Stefan,

”-Masterbrick 2.1 (is via USB conneted with the Raspberry)“

There is a difference in setup !
My tinkerstack is connected with openhab true a wifi extension (v2)
Probably the problem lies there.
My firmware(s) is up to date since installed binding 2.5 v 11
I do not get errors in my log when i activate a switch after powering back on tinkerforge.

Kind regards.
Wannes
Title: Re: Betaversion der openHAB-Bindings
Post by: MacDuff on October 09, 2019, 18:40:03
@ StefanOHAN
Danke für den Tipp. Es macht tatsächlich einen Unterschied, ob Item-Namen nur Großbuchstaben sind oder nicht.
Die Doku ist ungenau:
"Every word of the Item name starts with an uppercase letter"
-- und auch das ist nur eine "recommendation".
Sie geben sogar das Beispiel:
"Names that reoccur frequently, such as the names of rooms or appliances, may be abbreviated to reduce overall name length. (Example: Bathroom = BR)"
Und damit hätte man sich wohl ins Knie geschossen...
Versuch & Irrtum...
md
Title: Re: Betaversion der openHAB-Bindings
Post by: StefanOHAN on October 13, 2019, 17:39:16
Hallo Erik,

ich hoffe Du hattest einen erholsamen Urlaub :-)

Ich hab mal alle mir verfügbaren Bricklets und MasterExtentions in meine Konfiguration integriert.
Um nicht Altlasten aus den vorhergehenden Test versehentlich zu übernehmen, wurde das System  komplett zurückgesetzt.
Aktuell nutze ich Dein Beta11 Binding.

Zwei Punkte sind mir aufgefallen

Punkt 1)

Nachdem ich über „PaperUI“ / Inbox das LCD 128x64 erneut hinzu gefügt hatte, und die Channel-Verlinkung über der Item-Datei eingetragen habe, ist mir aufgefallen dass der Channel-String nach dem zurücksetzten von Openhab sich verändert hatte. (siehe unten)

Quote
vor dem Rücksetzten
Number LCD128x64_BL   "LCD128x64 Backlight [%s]" (TestTF)  {channel="tinkerforge:lcd128x64:f80007d9:HQJ:LCD128x64Backlight" }

Nach dem Rücksetzten
Number LCD128x64_BL   "LCD128x64 Backlight [%s]" (TestTF)  {channel="tinkerforge:lcd128x64:b0b51208:HQJ:LCD128x64Backlight" }

Es unterscheiden sich die Zeichen in der 3ten Gruppe (alt „f80007d9b“ neu „b0b51208“)

Warum ist dies so ? Kann dies verhindert werden ?
Was würde passieren wenn ich das System neu aufsetzte ? Müsste ich immer alle Channels neu verlinken ? (wäre es möglich einfach die Item - Datei mit dem verlinkten Channel in das neue System zu kopieren ohne diese ändern zu müssen ?)

Punkt 2)
Ich habe in Summe 3 x IO-16 angeschlossen.
2 x IO 16 sind an dem Materbrick (Stack1) angeschlossen der direkt per USB mit dem Raspberry Pi verbunden ist. 1 x 16-IO ist an dem Masterbrick (Stack2) angeschlossen der per RS485 Extention mit dem Masterbrick des Stack1 verbunden ist.
Stack2 verfügt über eine eigene Spannungsversorgung durch ein StepDown Power-Supply.

Beim Starten von Openhab (egal ob beide Stack‘s Spannungslos waren oder ob nur Openhab neu gestartet wurde) verhält sich das 16-IO das am Stack2 über die RS485 Extention angebunden ist, anders als die 2x16-IO die am Stack1 mit direkter USB-Verbindung am Pi angeschlossen sind.

Die als Input konfigurierten Ports am Stack1 (direkt per USB angeschlossen) werden richtig initialisiert, d.h. es wird angezeigt ob der Input-Kontakt offen oder geschlossen ist.

Die als Input konfigurierten Ports am Stack2 bleiben nach dem Starten von Openhab in einem undefinierten Zustand (NULL) solange bis der Input Kontakt 1x betätigt wurde.
Es ist auch egal ob nun während des Starten von Openhab ein Input-Kontakt geschlossen ist oder nicht.

Dies ist etwas unschön, denn wenn man über den „remote“ Stack2, Fenster oder Türkontakte (IO-16) einbinden will, hat man nach dem Starten von OpenHab keine klare Aussage ob eine Rule nun starten soll oder nicht. Diese Problem könnte man umgehen wenn man den Status eines Channel abfragen könnte, geht dies mit Deinem Binding ? Wenn nein, was kann man da machen ?

Beispiel: „Die Lüftung soll eingeschaltet sein wenn das Fenster geschlossen ist“ nach dem Startup von Openhab kann das Fenster auf oder zu sein, die Rule wird nicht reagieren.
Auf dem Bild siehst die Du Konfiguration (Brickviewer & PaperUI/Control) man kann erkennen dass das IO-16 (mit ID WiP) nur "ausgegraute" Switch-Symbole hat.
Mir ist momentan unklar wie ich diese Problem umgehen kann, dass meine Input-Item auch direkt nach dem Start den korrekten Status anzeigen.


Ein Punkt ist mir noch aufgefallen, einmal erschien im Log die Meldung dass das Hat länger zum Initialisieren benötigte. Ist dies ein Problem ?

Quote
2019-10-13 07:38:57.070 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'tinkerforge:hat:b0b51208:JYv' takes more than 5000ms.


Viele Grüsse

Stefan

Title: Re: Betaversion der openHAB-Bindings
Post by: rtrbt on October 14, 2019, 10:06:49
Barometer 2.0
Der Druck von 1.0 bar kommt als ein Wert von 10.0 an, liegt das an mit oder stimmt da was nicht ?
Das sehe ich mir mal an, sollte so nicht sein.
UV 2.0
Bei dem Index steht jetzt bei mir in der Sitemap "one" wo die Einheiten stehen. Das Ding ist natürlich ohne Einheit, is klar, aber ist das ein OH Fehler oder kommt das vom Binding so mit ?
one ist eine der "Einheitenlos"-Einheiten, wie auch z.B. Prozent oder PPM, das ist so korrekt. Ich kann aber mal nachsehen, ob man das nicht sinnvollerweise ganz ohne Einheit rausgibt.

After power loss on my tinker stack and a power up again the commands from openhab don't seem to come true anymore.
Only after restart of the binding my relais and inputs work again in openhab.
The bricks seem to reconnect fine.
I added a debug log disconnecting and reconnecting again.
I was on vacation the last two weeks, but will take a look at this soon.

Hallo Erik,

ich hoffe Du hattest einen erholsamen Urlaub :-)
Hatte ich, danke :D

Es unterscheiden sich die Zeichen in der 3ten Gruppe (alt „f80007d9b“ neu „b0b51208“)

Warum ist dies so ? Kann dies verhindert werden ?
Was würde passieren wenn ich das System neu aufsetzte ? Müsste ich immer alle Channels neu verlinken ? (wäre es möglich einfach die Item - Datei mit dem verlinkten Channel in das neue System zu kopieren ohne diese ändern zu müssen ?)
Das ist der (automatisch generierte) Name des Brick Daemons. D.h. wenn du dem Daemon beim Anlegen einen festen Namen gibst, sollten den alle Items als dritte Gruppe haben.

Punkt 2)
Die als Input konfigurierten Ports am Stack2 bleiben nach dem Starten von Openhab in einem undefinierten Zustand (NULL) solange bis der Input Kontakt 1x betätigt wurde.
Es ist auch egal ob nun während des Starten von Openhab ein Input-Kontakt geschlossen ist oder nicht.

Dies ist etwas unschön, denn wenn man über den „remote“ Stack2, Fenster oder Türkontakte (IO-16) einbinden will, hat man nach dem Starten von OpenHab keine klare Aussage ob eine Rule nun starten soll oder nicht. Diese Problem könnte man umgehen wenn man den Status eines Channel abfragen könnte, geht dies mit Deinem Binding ? Wenn nein, was kann man da machen ?
Das sollte natürlich prinzipiell nicht notwendig sein, aber du kannst mit smarthome:send [itemname] REFRESH ein Refresh-Command schicken, dann sollte der Zustand aktualisiert werden.

Ein Punkt ist mir noch aufgefallen, einmal erschien im Log die Meldung dass das Hat länger zum Initialisieren benötigte. Ist dies ein Problem ?

Quote
2019-10-13 07:38:57.070 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'tinkerforge:hat:b0b51208:JYv' takes more than 5000ms.
Das ist etwas seltsam, weil der HAT-Handler eigentlich nicht viel tut, aber wenn das Initialisieren klappt, sollte das kein Problem sein. Hast du die aktuelle Firmware (2.0.1) auf dem HAT?

PS: Danke für die Urlaubsvertretung ;)