Betaversion der openHAB-Bindings

[StefanOHAN]

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:

 

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

[rtrbt]

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.

[rtrbt]

Beta 10 ist jetzt im Post oben.

[StefanOHAN]

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.

 

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

 

[rtrbt]

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.

[rtrbt]

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.

[KlausGünther]

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 ?

[rak]

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.

 

[StefanOHAN]

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

[rak]

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

 

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

 

Grosses Lob! Automatische Erkennung geht. Items erstellen war dann ein NoBrainer

 

[Wannes]

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.

TinkerLog.txt

[StefanOHAN]

Hello Wannes,

 

What do you mean with

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

 

[MacDuff]

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:

 

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:

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

 

[Wannes]

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

 

 

[StefanOHAN]

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"

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

[StefanOHAN]

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

String LCD20x4_text "LCD20x4 [%s]" (TestTF) { channel="tinkerforge:lcd20x4:b0b51208:abc:LCD20x4Text"}

 

Grüsse Stefan

[Wannes]

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

[MacDuff]

@ 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

 

[StefanOHAN]

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)

 

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 ?

 

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

 

[rtrbt]

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

 

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 ?

 

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

[StefanOHAN]

Hallo Erik,

 

danke für die Rückmeldung.

 

Zum Thema HAT : Ja es ist die aktuelle FW installiert, es hat auch immer funktioniert. Nachdem es nur eine Warnmeldung war, war ich mir nicht sicher ob es was zu bedeuten hat.

 

Name des Brick-Daemon:

Test war erfolgreich, ich konnte beim Konfigurieren des Daemon einen eigenen Namen angeben. Danke für den Hinweis

 

Zum Thema Initialisierungs Verhalten vom IO-16 das über RS485 angeschlossen ist.

Ein Refresh Befehl über die Konsole hat auch nichts geändert. Siehe Log

 

2019-10-15 06:52:45.145 [ome.event.ItemCommandEvent] - Item 'Pin1In' received command REFRESH

 

2019-10-15 06:52:56.940 [ome.event.ItemCommandEvent] - Item 'Pin2In' received command REFRESH

 

==> /var/log/openhab2/openhab.log <==

 

2019-10-15 06:53:28.483 [iNFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'Test.rules'

 

==> /var/log/openhab2/events.log <==

 

2019-10-15 06:53:36.267 [iNFO ] [marthome.model.script.System Startup] - now

 

==> /var/log/openhab2/events.log <==

 

2019-10-15 06:53:36.300 [iNFO ] [lipse.smarthome.model.script.myRules] - check wip IO-16 V1 >> Kein INIT PIN1=Pin1InNULL Pin2In=NULL

 

Über eine kleine Rule fragte ich ab, ob die ITEM den Status NULL haben.

 

Ich habe vergessen zu erwähnen dass, das IO-16 das hier rum zickte eine HW-Version 1.2 hat, als noch zu den V1 Bricklets mit den 10pol Stecker gehört (hat aber die aktuelle FW).

Aus Interesse habe ich dann mein IO-16 V2 (mit dem 7Pol Stecker) zusätzlich an dem Stack2 (der über RS485 angebunden ist) angeschlossen. Anschließen habe ich das System heruntergefahren, an beiden Stack die Spannung abgeschaltet und anschließen neu gebootet. Der V2 IO-16 hat sich sauber Initialisiert. Dort waren 14 Ports als Input und 2 als Output konfiguriert. Alle!! 14 Input-Ports hatten den korrekten Staus (OFF). Ich hatte gestern allerdings nicht mehr Zeit um es mehrfach zu testen.

Heute werde ich mal einen Überwachungs-Rule für alle IO-16 schreiben um das Verhalten über einen längeren Zeitpunkt beobachten zu können.

 

FRAGE: Kann es sein dass die Kombination "Verbindung über RS485 Masterextention und alte V1 IO-16 diese Eigenart verursachen ?" Evtl kann ja im Binding nochmal auf den Teil für das alte IO-16 schauen.

 

Jetzt noch ein zwei Frage zum Verständnis:

 

im Konfigurations Punkt der verschiedenen Bricklets findet man immer den Menu-Punkt

Bridge Selection

CREATE BRIDGE

 

Was ist die Funktion zur erstellen einer "Bridge" ?

 

Nochmal einen Frage zur Sample Rate des Humidity V2 Bricklet

Du schreibst

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.

 

ich hatte meine Konfiguation wie unten eingestellt, bekam aber dennoch alle 10 sec einen Wert im Log

Averaging

Humidity Moving Average Length 20

Temperature Moving Average Length 20

Sample Rate 0.1 SPS

 

2019-10-15 06:57:43.298 [vent.ItemStateChangedEvent] - Hum1 changed from 48.36 to 48.37

 

2019-10-15 06:57:53.255 [vent.ItemStateChangedEvent] - Hum1 changed from 48.37 to 48.39

 

hätte da nicht alle 200 Sekunden nur werte erscheinen dürfen ?

 

Viele Grüsse

 

Stefan

 

[rtrbt]

Zum Thema HAT : Ja es ist die aktuelle FW installiert, es hat auch immer funktioniert. Nachdem es nur eine Warnmeldung war, war ich mir nicht sicher ob es was zu bedeuten hat.

Nur, dass die Initialisierung mehr als 5 Sekunden gedauert hat. Ansich sollte das deutlich schneller gehen, was openHAB auch erwartet, deshalb die Warnung. Kannst du also ignorieren.

 

FRAGE: Kann es sein dass die Kombination "Verbindung über RS485 Masterextention und alte V1 IO-16 diese Eigenart verursachen ?" Evtl kann ja im Binding nochmal auf den Teil für das alte IO-16 schauen.

Möglich. Das sehe ich mir nochmal an.

 

 

im Konfigurations Punkt der verschiedenen Bricklets findet man immer den Menu-Punkt

Bridge Selection

CREATE BRIDGE

 

Was ist die Funktion zur erstellen einer "Bridge" ?

Das kannst du ignorieren, die Bridge der Things ist der Brick Daemon. Aus irgendeinem Grund zeigt die PaperUI das dort aber nicht korrekt an, steht schon auf meiner TODO-Liste rauszufinden, was da kaputt ist.

 

Nochmal einen Frage zur Sample Rate des Humidity V2 Bricklet

Du schreibst

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.

 

ich hatte meine Konfiguation wie unten eingestellt, bekam aber dennoch alle 10 sec einen Wert im Log

Averaging

Humidity Moving Average Length 20

Temperature Moving Average Length 20

Sample Rate 0.1 SPS

 

2019-10-15 06:57:43.298 [vent.ItemStateChangedEvent] - Hum1 changed from 48.36 to 48.37

 

2019-10-15 06:57:53.255 [vent.ItemStateChangedEvent] - Hum1 changed from 48.37 to 48.39

 

hätte da nicht alle 200 Sekunden nur werte erscheinen dürfen ?

Das ist etwas subtil, es gibt (ältere) Bricklets, bei denen wäre das so, da sie nicht einen gleitenden Mittelwert (= Moving Average) sondern einfach nur einen Mittelwert (= Average) ausgeben. Das Humidity berechnet aber einen gleitenden Mittelwert. Das heißt, dass das Bricklet die letzten "Moving Average Length" Werte speichert, bei dir also 20 pro Messwert und dann pro neuem Messwert, bei dir alle 10 Sekunden, den jeweils letzten Wert vergisst, den neuen dazu nimmt, den Durchschnitt berechnet und dann ausgibt. Dadurch hast du alle 10 Sekunden einen neuen Wert, der aber über die letzten 20 echten Messwerte geglättet wurde.

 

Bezüglich der ganzen Dinge, die so aufgelaufen sind: Ich muss mich in der Firma gerade noch um ein paar andere Dinge kümmern, d.h. die nächste Beta wird vermutlich noch ein paar Tage dauern.

[StefanOHAN]

Hallo Erik,

 

ich hätte noch ein Bicklet für den Binding-Wunschzettel.

Das Piezo Speaker Bricklet.

 

Wenn Dein OK kommt, würde ich es bestellen.

 

Grüsse

 

Stefan

 

 

[StefanOHAN]

Hallo Erik

 

so jetzt laufen seit 2 Tagen die neuen Rules die das Initialisierungs-Verhalten der 3 angeschlossenen IO-16 nach dem starten des System überprüfen.

 

Das Initialisierungsproblem scheint ein generelles IO-16 V1 (10pol Stecker) (HW-Release 1.2) zu sein.

Es ist egal ob am Stack mit der direkten USB-Verbindung zum Pi oder über den Stack mit der RS485 Extention angeschlossen sind.

 

 

Grüsse

 

Stefan

 

 

[rtrbt]

@Wannes:

The problem with the WiFi Extension seems to be, that openHAB does not notice the lost connection caused by the restart of the stack. openHAB then still assumes, that the connection is established, but the Wifi Extension has no open connection because of the restart. Currently the Tinkerforge Protocol has no heartbeat mechanism, so to fix this, I have to query the device state periodically in the openHAB bindings (this will fail if the connection was lost) and then try to restablish lost connections. I think this fix will be in the next beta version.

 

@StefanOHAN

Das IO-16-Problem lag an einer fehlerhaften Konfiguration, die Getter, die openHAB für REFRESH-Commands verwenden sollte, hatte ich als Callback eingetragen, was dann später von den richtigen Callbacks überschrieben wurde. Deshalb funktionierte nur das initiale Abfragen des Zustands nicht, die Aktualisierungen aber schon. Brauchst du den Fix dringend oder reicht es, wenn ich den in die nächste Version packe?

 

Bezüglich dem Piezo Speaker: Support dafür kommt auf jeden Fall noch, ich bin mir nur noch unschlüssig, wie ich den modelliere. Was wäre dein Anwendungsfall dafür/Welche Features hättest du gerne?