Author Topic: Betaversion der openHAB-Bindings  (Read 9037 times)

Wannes

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Betaversion der openHAB-Bindings
« Reply #60 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.

StefanOHAN

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
Re: Betaversion der openHAB-Bindings
« Reply #61 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

MacDuff

  • Jr. Member
  • **
  • Posts: 65
    • View Profile
Re: Betaversion der openHAB-Bindings
« Reply #62 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
« Last Edit: October 08, 2019, 16:30:13 by MacDuff »

Wannes

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Betaversion der openHAB-Bindings
« Reply #63 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


StefanOHAN

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
Re: Betaversion der openHAB-Bindings
« Reply #64 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

StefanOHAN

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
Re: Betaversion der openHAB-Bindings
« Reply #65 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
« Last Edit: October 08, 2019, 21:33:55 by StefanOHAN »

Wannes

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Betaversion der openHAB-Bindings
« Reply #66 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

MacDuff

  • Jr. Member
  • **
  • Posts: 65
    • View Profile
Re: Betaversion der openHAB-Bindings
« Reply #67 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

StefanOHAN

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
Re: Betaversion der openHAB-Bindings
« Reply #68 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

« Last Edit: October 13, 2019, 17:44:32 by StefanOHAN »

rtrbt

  • Tinkerforge Staff
  • Administrator
  • Full Member
  • *****
  • Posts: 131
    • View Profile
Re: Betaversion der openHAB-Bindings
« Reply #69 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 ;)