Betaversion der openHAB-Bindings

rtrbt · January 26, 2020 at 14:38

Sorry, das hatte ich übersehen. Du kannst die Repeats mit der

brickletRemoteSwitchSetRepeats

Action einstellen.

StefanOHAN · January 26, 2020 at 18:25

Hallo Erik

heute habe ich mal versucht alle meine angeschlossenen Bricklets mit dem B16-Binding zu testen (aber nicht alle möglichen Actions).

Folgendes ist mir dabei aufgefallen.

>>„Industrial Digital In 4 Bricklet 2.0“

Frage: Kann es sein, dass Du keine Action für „getEdgeCount(int channel, boolean resetCounter)“ mehr vorgesehen hast ?

Bei den IO-16-V1 / IO-16-V2 / IO-4-V2 & „Industrial Digital In 4 V2“ hatte der mit dem EdgeCount verlinkte Number-Item immer den Werte 0

Ich vermute es ist noch das Problem das Du in Deinem Post vom 28.10.2019 beschrieben hast, oder ?

Zitat

Zitat: „Das funktioniert leider noch nicht automatisch, da der Edge Count kein Callback hat, ich also den Getter benutzen muss. Der wird aber nur ausgeführt, wenn du dem Item ein Refresh-Command schickst. Solche Werte automatisch zu aktualisieren steht noch auf der TODO-Liste. „

Die Action getEdgeCount funktionierte für das IO-4 V2 und das IO-16-V2 (es wurde ein Wert ausgegeben), für das IO-16 V1 hingegen nicht.

Basis der Rule war ein Vorschlag den Du am 15.11.2019 auf meine Frage zur getEdgeCount Action gemacht hast.

Diesen habe ich entsprechend für die 3 verschieden IO-Bricklets angepasst

Hier das Beispiel für das IO-16-V1

Zitat

val ioActions16v1 = getActions("tinkerforge" , "tinkerforge:brickletio16:D8e")

val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(0, false).get("count") as int

Ich bekomme (nur) für das IO-16 V1 folgende Fehlermeldung im Log

Zitat

2020-01-26 16:55:19.065 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Dual-Relais2': An error occurred during the script execution: Cannot convert number literal to typejava.lang.Short

Technische Daten zu meinem IO-16-V1

Zitat

hardwareVersion

1.1.0

modelId

28.0

Zum den Action (Alarm) des Piezo Speaker V2 hätte ich eine Frage

Die Grundkonfiguration für den Beep und den Alarm sind doch unabhängig von Action‘s „brickletPiezoSpeakerV2SetBeep“ und brickletPiezoSpeakerV2SetAlarm, oder ?

Ich habe mit dem „brickletPiezoSpeakerV2SetAlarm“ in den Rules ein Problem. Aber komischerweise nur mit dem Alarm nicht mit dem Beep.

Wenn ich in einer Rule über brickletPiezoSpeakerV2SetAlarm versuche den Alarm zu verändern, ändert sich nur kurz die „Startfrequenz“ auf dem Wert den ich mit der Action übergebe, aber nach ca 0,1-0,2 Sekunden kommt der Alarm so wie er über der Thing „Configure channel“ voreingestellt ist.

Zitat

rule "Dummy-interner-Alarm-mit Piezo"

when

    Item P0Ig7y changed to ON

then

    val piezoActions = getActions("tinkerforge", "tinkerforge:brickletpiezospeakerv2:KGL")

    if (PiezoAlarm.state == OFF ) {

        PiezoAlarm.sendCommand(ON)

  piezoActions.brickletPiezoSpeakerV2SetAlarm(1000,2500,100,1000,2,10000)

    }

end

Ich hätte einen Alarm mit 1000Hz Startfrequenz, der jede Sekunde in 100 Hz Schritten bis 2500 Hz ansteigt und dies 10 Sekunden lang andauert. Es kommt aber nur ein kurzer 1000 Hz Ton dann fällt er wieder auf die Channel-Konfiguration zurück (Startfrequenz = 200Hz, Endfrequenz = 1000Hz, StepSize = 100 , StepDelay = 100 , DefaultVolumen = 1 , Duration = 5000)

Wo liegt der Fehler in meiner Rule ?

Einen Frage zu den Channel des MultiTouch V2

Generell funktionieren bei mir die mit ITEM-Verlinken Channel, diese kann ich auch problemlos in Rules verwenden.

Kann es sein, dass die Channel nicht direkt in einer Rule als Trigger genutzt werden können ?

Ich sehe auch im Log keine Meldung wenn ich eine der Tasten berühre (ich nutze Eurer 3x4 Tastenfeld).

Ich habe in der Rule Channel verwendet die mit einem Item verlinkt waren und Channel die nicht mit einem Item verlinkt waren.

Zitat

rule "Dummy-Multitouch&E-Paper2"

when

Channel "tinkerforge:brickletmultitouchv2:KyQ:BrickletMultiTouchV2Electrode0" triggered

then

logInfo("Multitouch", "1TEST----------------------------------------TEST")

logInfo("Multitouch", "2TEST----------------------------------------TEST")

logInfo("Multitouch", "3TEST----------------------------------------TEST")

logInfo("Multitouch", "4TEST----------------------------------------TEST")

end

Was ich auch echt gut finde ist die Firmware/Update und HW Info die das neue Binding bereitstellt.

Viele Grüße

Stefan

Anbei meine Testliste

Binding Version B16
Typ	Item-Channel-Verlinkung	Item in Rule	Channel in Rule	Action in Rule
E-Paper296x128	ok	nicht getestet	nicht getestet	FillDisplay / DrawText
Multitouch V2	ok	ok	*keine Funktion*	nicht getestet
Rotary Poti V2	ok	ok	nicht getestet	nicht getestet
Rotary Encoder V2	ok	ok	nicht getestet	nicht getestet
Humidity Bricklet V2	ok	ok	nicht getestet	nicht getestet
Outdoor Weather Bricklet	ok (mit 2 x TH6148)	ok	nicht getestet	nicht getestet
Motion Detector V2	ok	ok	ok	nicht getestet
LCD 128x64	ok	ok	ok	verschiedene
LCD 20x4	ok	ok	ok	brickletLCD20x4ClearDisplay
Dual Relay V2	ok	ok	nicht getestet	nicht getestet
Industrial QuadRelay V2	ok	ok	nicht getestet	nicht getestet
Industrial Digital In4 V2	ok	ok	nicht getestet	kein getEdgeCount ?
IO-16 V1	ok	ok	nicht getestet	Problem mit getEdgeCount
IO-16 V2	ok	ok	nicht getestet	getEdgeCount
IO-4 V2	ok	ok	nicht getestet	getEdgeCount
Piezo Speaker V2	ok	ok	nicht getestet	Problem PiezoSpeakerV2SetAlarm

bearbeitet January 26, 2020 at 18:31 von StefanOHAN

omiT · January 26, 2020 at 22:58

Hallo zusammen,

kann jemand die Nutzung des Motion Detector Bricklet 2.0 erklären?
Ich nutze die Beta 16.

In OH Control wird für Top Left, Top Right und Bottom Indicator immer 0 angezeigt. Muss das so sein?

Wie nutzt ihr denn den Motion Detected Channel und Detection Cycle Ended als Trigger? Hat da jemand Beispiele wie man da Regeln aufbaut?

Vielen Dank und Liebe Grüße 🙂

Timo

rtrbt · January 27, 2020 at 11:14

Moin,

@StefanOHAN

15 hours ago, StefanOHAN said:

>>„Industrial Digital In 4 Bricklet 2.0“

Frage: Kann es sein, dass Du keine Action für „getEdgeCount(int channel, boolean resetCounter)“ mehr vorgesehen hast ?

Hm, die fehlt. Mir ist dabei ein strukturelles Problem aufgefallen: Eigentlich sind nur die Teile der Java-API als Actions rausgeführt, die den Zustand des Bricks/Bricklets nicht ändern (mit Ausnahme einiger Bricklets wie z.b. der Remote-Switches, die nicht gut auf das Channel-Modell mappen), damit nicht die openHAB-Sicht des Bricklets und der tatsächliche Zustand auseinanderlaufen. Ich hatte jetzt den Gedanken, dass ich Actions, die den Zustand ändern erlauben kann, wenn ich im Generator hinterlege, welche Channels dann aktualisiert werden müssen. Da muss ich die API nochmal durchgehen, aber in dem Zuge wird dann die getEdgeCount-Action kommen.

16 hours ago, StefanOHAN said:

Ich bekomme (nur) für das IO-16 V1 folgende Fehlermeldung im Log

Quote

2020-01-26 16:55:19.065 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Dual-Relais2': An error occurred during the script execution: Cannot convert number literal to typejava.lang.Short

Das liegt daran, dass ich im Moment die Java-Bindings unverändert benutze. Die wiederum haben aus Legacy-Gründen bei älteren Bricklets andere Parameter- und Rückgabetypen. Die IO-16 gibt dir da einen Short (also eine 16-Bit-Zahl) zurück. Wenn du das so machst:

val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(0, false).get("count") as short

sollte es eigentlich funktionieren.

16 hours ago, StefanOHAN said:

Ich hätte einen Alarm mit 1000Hz Startfrequenz, der jede Sekunde in 100 Hz Schritten bis 2500 Hz ansteigt und dies 10 Sekunden lang andauert. Es kommt aber nur ein kurzer 1000 Hz Ton dann fällt er wieder auf die Channel-Konfiguration zurück (Startfrequenz = 200Hz, Endfrequenz = 1000Hz, StepSize = 100 , StepDelay = 100 , DefaultVolumen = 1 , Duration = 5000)

Wo liegt der Fehler in meiner Rule ?

Ist PiezoAlarm das Item mit dem du den Alarm-Channel benutzt? Dann passiert in deiner Rule folgendes: Du schickst das Command an den Alarm-Channel, das ist etwas langsam, weil die Nachricht einmal quer durch openHAB muss. Direkt danach startest du einen weiteren Alarm von Hand (die Action heißt zwar SetAlarm, aber konfiguriert nicht nur, sondern löst den Alarm auch direkt aus). Das geht schneller, weil die Action direkt an die Java-Bindings gekoppelt ist. Der zweite Alarm geht jetzt los, danach kommt das Command am Channel an, der intern auch SetAlarm benutzt und damit den Alarm aus deiner Rule überschreibt.

16 hours ago, StefanOHAN said:

Einen Frage zu den Channel des MultiTouch V2

Generell funktionieren bei mir die mit ITEM-Verlinken Channel, diese kann ich auch problemlos in Rules verwenden.

Kann es sein, dass die Channel nicht direkt in einer Rule als Trigger genutzt werden können ?

Stimmt, da ist die Modellierung nicht gut: Das ist im Moment ein normaler Channel mit State pro Elektrode, mit dem Switch-Typ. Sinnvoller ist ein Trigger-Channel. Das konfiguriere ich mal um.

@omiT

12 hours ago, omiT said:

In OH Control wird für Top Left, Top Right und Bottom Indicator immer 0 angezeigt. Muss das so sein?

Das sind die LEDs die auf dem Bricklet verbaut sind. Du kannst da Zahlen bis 255 reingeben, dann leuchten die LEDs entsprechend hell. Ich baue eventuell noch ein, dass auch PercentType-Kommandos akzeptiert werden, dann kann ich das in der PaperUI schöner anzeigen.

Mal wieder danke für's Testen!
Erik

StefanOHAN · January 27, 2020 at 18:36

Hallo omiT

anbei mein Beispiel für den Motion Detector V2 Test

Die LED habe ich über eine ITEM-Datei verlinkt, ich nutze diese in meiner Test-Rule für die Anzeige wann einen Bewegung erkannt wurde und diese wieder beendet wurde.

Eintrag in "meiner" Item-Datei

Zitat

Number MDLED_links       "SignalLED links Bewegungsmelder innen [%s]" (TestTF) {channel="tinkerforge:brickletmotiondetectorv2:Hz1:BrickletMotionDetectorV2TopLeftIndicator"}

Number MDLED_rechts      "SignalLED rechts Bewegungsmelder innen [%s]" (TestTF) {channel="tinkerforge:brickletmotiondetectorv2:Hz1:BrickletMotionDetectorV2TopRightIndicator"}

Number MDLED_unten       "SignalLED unten Bewegungsmelder innen [%s]" (TestTF) {channel="tinkerforge:brickletmotiondetectorv2:Hz1:BrickletMotionDetectorV2BottomIndicator"}

Zum spielen gibt es 2 Rules, eine die bei Bewegung „erkannt“ die LED erst mit 25% dann mit 100% Leistung einschaltet. Und eine die bei „Ende“ Bewegung die LED in umgekehrter Reihenfolge wieder auf Leistung 0% abschaltet.

Der Thread::sleep(100) dient nur dazu, dass ich erkennen kann ob ein Unterschied zwischen 25% und 100% Leistung bei den LED zu erkennen ist.

Der sleep ist hier etwas uncool, da Du Gefahr läufst, dass die erste Rule noch einen Sleep abwartet während bereits ein Trigger für die zweite Rule gestartet wurde. Aber zum testen geht´s 😉

Zitat

rule "motionDedect-on-t"

    when

        Channel "tinkerforge:brickletmotiondetectorv2:Hz1:BrickletMotionDetectorV2MotionDetected" triggered

    then

        MDLED_links.sendCommand(25)

        Thread::sleep(100)

        MDLED_rechts.sendCommand(25)

        MDLED_links.sendCommand(100)

        Thread::sleep(100)

        MDLED_unten.sendCommand(25)

        MDLED_rechts.sendCommand(100)

        Thread::sleep(100)

        MDLED_unten.sendCommand(100)

end

rule "motionDedect-off-t"

    when

        Channel "tinkerforge:brickletmotiondetectorv2:Hz1:BrickletMotionDetectorV2DetectionCycleEnded" triggered

    then

        LCD20x4_light.sendCommand(OFF)

        MDLED_links.sendCommand(0)

        Thread::sleep(100)

        MDLED_rechts.sendCommand(0)

        Thread::sleep(100)

        MDLED_unten.sendCommand(0)

end

Die Channel-Information für

BrickletMotionDetectorV2MotionDetected / DetectorV2DetectionCycleEnded

findest Du wie die channel‘s für die LED‘s unter paperui / Configuration / Things / MotionDetector

Wenn Du die Items & Rule‘s entsprechende Deinen Channel-Thing-Daten anpasst, sollte es klappen.

Grüsse Stefan

bearbeitet January 27, 2020 at 18:47 von StefanOHAN

StefanOHAN · January 27, 2020 at 18:43

Hallo Erik

zum getEdgeCount IO-16 V1 ich habe mal versucht mit short das ganze zu testen. Es kommt aber noch immer der Fehler. .

Zitat

val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(0, false).get("count") as short

Zitat

2020-01-27 19:07:11.513 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Dual-Relais2': An error occurred during the script execution: Cannot convert number literal to typejava.lang.Short

Um sicher zu gehen, dass mir kein Config Fehler unterlaufen ist, habe ich noch mal unter Things geprüft, wie der korrekte Channel / Port lautet.

Zitat

„ val ioActions16v1 = getActions("tinkerforge" , "tinkerforge:brickletio16:D8e")“

Thing Eintrag >> tinkerforge:brickletio16:D8e:BrickletIO16EdgeCountPin0

Mit long hatte ich gestern anstelle von int getestet, das hat auch nicht geklappt.

Zum Piezo Alarm,

Ja das Item „PiezoAlarm“ nutze ich für den Alarm Channel.

Kaum habe ich den SendCommand für das Einschalten des AlarmChannel entfernt und nur die SetAlarm Action in der Rule aufgerufen, hat es wunderbar geklappt.

Ich dachte, ich muss den Alarm erst über den AlarmChannel „einschalten“, das war mein Fehler

Super jetzt passt meine Rule

Abschalten einer laufenden Alarm-Action geht einfach indem ich den AlarmChannel per SendCommand auf OFF setzte.

Frage, kann ich eigentlich abfragen ob gerade eine „Alarm“-Action aktiv ist ? Oder muss ich mir selber über Variablen einen Merker setzten ?

Viele Grüße Stefan

rtrbt · January 28, 2020 at 08:42

Moin,

Die IO-16-Geschichte sehe ich mir gleich nochmal an, das sollte eigentlich funktionieren (die letzten Worte des Informatikers )

Beim Piezo kannst du die getAlarm-Action benutzen, die gibt nicht nur die Gesamt-Duration des aktuellen Alarms zurück, sondern auch durationRemaining, also wie lange der aktuelle Alarm noch läuft (falls einer läuft).

StefanOHAN · January 29, 2020 at 05:55

Hallo Erik

Die Abfrage der Alarm-Action mit GetAlarm und der Auswertung des Value mit .get("durationRemaining") as long hat wunderbar geklappt.

Mir ist allerdings zufällig aufgefallen das der Brick-Dämon der für die per USB angeschlossen Masterbricks und des HAT zuständig ist kurz ausgefallen ist.

Aufgefallen ist mir das nur, da eine meiner Test Rule‘s ohne mein Zutun das DualRelais on und off schaltet.

Ich vermutet es hing damit zusammen dass alle Button des LCD128x64 „triggerd RELEASED meldeten

Zitat

2020-01-29 05:22:01.647 [vent.ChannelTriggeredEvent] - tinkerforge:brickletlcd128x64:HQJ:BrickletLCD128x64GUIButton0 triggered RELEASED

alle Bricklets die über diesen Dämon angesprochen werden, meldeten dass Sie wieder online gingen

Zitat

2020-01-29 05:22:00.670 [hingStatusInfoChangedEvent] - 'tinkerforge:brickd:f80007d9' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Connection lost. Trying to reconnect. 2020-01-29 05:22:00.846 [hingStatusInfoChangedEvent] - 'tinkerforge:brickd:f80007d9' changed from OFFLINE (COMMUNICATION_ERROR): Connection lost. Trying to reconnect. to ONLINE

Dieser Effekt ist nicht so schön, denn es könnte sich auf Rules auswirken. (z.B. es reagierte auch die Rule die als Channel-Trigger die TouchPosition nutzt)

Gesehen habe ich dies bis jetzt nur einmal.

Im Event-Log der letzten 2 Tage (in diesem Zeitraum habe ich das System nicht gebootet) fand ich keine weitere Meldung für dieser Art des brick-Dämon.

Frage: gibt es irgend einen TimeOut der evlt. zu schnell reagierte und daher diesen Fehler verursachte ? Wenn du den Zeitstempel anschaust ist das gerade mal im 200ms Bereich abgelaufen.

Viele Grüße

Stefan

rtrbt · January 30, 2020 at 15:36

Moin,

Du hast da zwei unabhängige Probleme:
1. ist meine Reconnectlogik da anscheinend zu aggresiv, das muss ich mir nochmal ansehen.
2. versuche ich, wenn ein Device initialisiert wird, alle Channel in einen definierten Zustand zu bringen, indem ich ein REFRESH-Command schicke. Das sollte ich aber nur bei nicht-Trigger-Channels machen, damit es nicht so aussieht als gäbe es Zustandswechsel, die nicht wirklich da sind. Das habe ich hier gerade mal testweise eingebaut und es scheint zu funktionieren. Kommt in die nächste Beta.

StefanOHAN · January 31, 2020 at 09:56

Hallo Erik

danke für das Feedback

Eine kleine Unschärfe ist mich noch aufgefallen (nichts schlimmes)

Für „Dual Relay V2“ kann ich die Status-LED nicht abschalten (paperui / Configuration / Things ) umschalten auf Heartbeat geht, nur das ausschalten nicht.

Beim Stöbern in Eurem Shop ist mir das „Isolator-Bricklet“ aufgefallen und ich stellte mir die Frage ob ich es etwas zweckentfremden kann.

Frage:

1) funktionieren mit Deinem Binding Bricklets, die über das Isolatro-Bricklet angeschlossen sind ?

2) lassen sich nur die Bricklets an das IsolatorBricklet anschließen die als Beispiel in Euer Doku genannt werden , oder können generell alle Bricklets (7-polige V2-Versionen) angeschlossen werden ?

3) gibt es eine Einschränkung der verwendeten Leitungslängen ? Also Zuleitung und Ableitung je 2 Meter ?

Hintergrund der Fragen ist, dass ich noch immer versuche einen etwas schwierig zu erreichenden Masterbrick ab zu lösen.

Könnte ich das Istolator-Bricklet evlt zur „Leitungsverlängerung“ nutzen ?

Viele Grüße

Stefan

rtrbt · January 31, 2020 at 10:28

Moin,

mit dem Dual Relay V2 meinst du das Industrial Dual Relay? Sehe ich mir mal an.

27 minutes ago, StefanOHAN said:

1) funktionieren mit Deinem Binding Bricklets, die über das Isolatro-Bricklet angeschlossen sind ?

Jupp

28 minutes ago, StefanOHAN said:

2) lassen sich nur die Bricklets an das IsolatorBricklet anschließen die als Beispiel in Euer Doku genannt werden , oder können generell alle Bricklets (7-polige V2-Versionen) angeschlossen werden ?

Das geht mit allen 7-Pol-Bricklets.

28 minutes ago, StefanOHAN said:

3) gibt es eine Einschränkung der verwendeten Leitungslängen ? Also Zuleitung und Ableitung je 2 Meter ?

Nein, da kannst du die vollen 4 (also 2+2) Meter benutzen.

28 minutes ago, StefanOHAN said:

Könnte ich das Istolator-Bricklet evlt zur „Leitungsverlängerung“ nutzen ?

Ja, und das hat gegenüber der Variante zwei Kabel zu schlachten den Vorteil, dass es wie ein Repeater wirkt, also das Signal aufgefrischt. Du kannst aber nicht, falls du noch längere Kabel brauchst, zwei Isolatoren hintereinander benutzen, das würde den Master Brick verwirren.

rtrbt · January 31, 2020 at 15:00

Moin,

Beta 17 ist jetzt im Post oben.

Die Remote Switch Bricklets sind jetzt deutlich einfacher benutzbar: Es gibt, ähnlich wie beim Outdoor Weather Bricklet jetzt eigene Devices für die Typ-A bis C Dosen und Typ-B Dimmer, die auf die entsprechende Adresse usw. konfiguriert werden können. Der Handler stellt dabei automatisch sicher, dass immer nur ein Schaltvorgang gleichzeitig stattfindet. Das ganze funktioniert ohne Rules schreiben zu müssen, die Actions werden aber alle weiterhin unterstützt.

Damit Rules einfacher zu schreiben sind, habe ich mal das Java-Typ-Schema umgebaut: Bisher hatte ich die Java-Bindings unverändert benutzt, weshalb für ältere Bricklets die Actions oft byte und short für Parameter und Rückgabewerte verwendet haben. Das habe ich rausgeschmissen, jetzt werden nur noch int und long verwendet. Das ist jetzt erstmal etwas verwirrend, da die Java-Doku nicht mehr passt, behebt sich dann aber wenn ich dazu komme einen richtigen openHAB-Doku-Generator zu schreiben. Für die Übergangszeit: alles was short oder byte war ist jetzt int, man kann aber in den Rules anscheinend auch einfach "as Number" casten, das sollte immer gehen.

Die minimale Firmware-Version wird jetzt anhand der von den Bindings verwendeten Features gesetzt, das dürfte aber nicht auffallen, weil mit der Information im Moment nichts angefangen wird.

Die Bindings sollten jetzt robuster sein, wenn die Verbindung zum Brick Daemon oft verloren geht, da fehlte eine Neuinitialisierung der Devices, weshalb dann manchmal Callbacks nicht mehr ankamen.

@StefanOHAN
Deine Rules sollten jetzt nicht mehr beim Initialisieren oder wenn die Verbindung wiederhergestellt wird triggern. Die IO16-Sache hatte ich hier nochmal getestet, das funktionierte. Ist das mit der neuen Beta bei dir noch kaputt?

Gruß,
Erik

Maxicko · February 1, 2020 at 15:39

Am 31.1.2020 um 16:00 schrieb rtrbt:

Die Remote Switch Bricklets sind jetzt deutlich einfacher benutzbar: Es gibt, ähnlich wie beim Outdoor Weather Bricklet jetzt eigene Devices für die Typ-A bis C Dosen und Typ-B Dimmer, die auf die entsprechende Adresse usw. konfiguriert werden können. Der Handler stellt dabei automatisch sicher, dass immer nur ein Schaltvorgang gleichzeitig stattfindet. Das ganze funktioniert ohne Rules schreiben zu müssen, die Actions werden aber alle weiterhin unterstützt.

Hi Erik,

erst mal auch von mir vielen vielen Dank für die Arbeit, die du in das Binding steckst!

Ich habe das Remoteswitch-Bricklet bisher über einen Workaround genutzt und wollte es nun über die neue Funktion einbauen.
Leider klappt das noch nicht so ganz.

Was mir dabei aufgefallen ist, der Channel "Command" für die TypeA-Things wird mit Typ "String" und nicht mit "Switch" angegeben. Ist das so korrekt?

Vielen Dank und Gruß
Max

StefanOHAN · February 2, 2020 at 15:04

Hallo Erik

für das Beta 17 habe ich alles zurück gesetzt, alle Things entfernt, alle Dämon‘s gelöscht, das alte Binding über Console entfernt, sowie einen Update meines Openhabian-System ausgeführt.

Beim StartUp des System mit dem neuen Binding ist mir folgende Meldung aufgefallen

Zitat

2020-02-01 16:07:55.220 [INFO ] [ernal.TinkerforgeChannelTypeProvider] - Failed to download latest versions: null

Frage: ist das eine Funktion die noch nicht aktiv ist ? Oder welche Aufgabe hat diese ?

Bis jetzt funktionieren alle meine Test-Rules (zumindest konnte ich keine Error-Meldungen im Log finden).

Einzig für EdgeCount der „per Channel mit einem Item“ verlinkt ist, bekomme ich noch immer 0 als Ergebnis, kann aber daran liegen dass ich diesen evlt. falsch nutze.

Der EdgeCount den ich über die Action aufrufe, hat für das „IO-16 Bricklet V1“ , „IO-16 Bricklet 2.0“ , „IO-4 Bricklet 2.0“ und „Industrial Digital In 4 Bricklet 2.0“ einwandfrei funktioniert.

(Wie von Dir empfohlen hab ich für das „IO-16 Bricklet V1“ von „short“ auf „int“ umgestellt)

Einen komischen Effekt habe ich beim „Multi Touch Bricklet 2.0“ (mit der alten V1 Version habe ich es nicht getestet), egal welche Elektroden-Taste ich berühre, es kommt immer für alle (die nicht berührt wurden) Elektroden die Meldung „triggered RELEASED. Ist das so gewollt ? (ich verwende Euer Key-Pad 3x4)

Zitat

2020-02-01 21:06:13.636 [vent.ChannelTriggeredEvent] - tinkerforge:brickletmultitouchv2:KyQ:BrickletMultiTouchV2Electrode0 triggered RELEASED

Frage: Meinst Du es würde zu viel Last verursachen wenn ich die für das IO-16 / IO-4 den „Update Interval“ von 1000ms auf 250ms verkürze ? Wenn ich diese als Input für angeschlossene „Taster“ zum Lichtschalten verwende sind 1000ms etwas lange. Ich würde maximal dies für 2 x IO-16 anwenden.

ausgeführte Test‘s siehe unten

viele Grüße Stefan

PS: werde heute das Isolator / Remote Switch / Energy Monitor / Dual-Button Bricklets für weiter Test bestellen

Test 2 Februar 2020
System	Raspberry Pi 3 Model B Rev 1.2
OS-Version	Linux OPENHABBIANPI3 4.19.93-v7
OpenHAB Version	openHAB 2.5.1-2
Tinkerforge-Binding	B17
technische Daten Brick / Bricklets				ausgeführte Test‘s
Typ	HW Version	Modell ID	FW Version	Item Channel-Verlinkung	Rule über Item Trigger	Rule über Channel Trigger	Action in Rule
E-Paper 296x128	1.0.0	2146.0	2.0.1	ok	nicht getestet	nicht getestet	FillDisplay / DrawText
Multi Touch2.0	1.0.0	2129.0	2.0.0	ok	ok	ok	nicht getestet
Rotary Poti 2.0	1.0.0	2140.0	2.0.0	ok	ok	nicht getestet	nicht getestet
Rotary Encoder 2.0	1.0.0	294.0	2.0.4	ok	ok	nicht getestet	nicht getestet
Humidity 2.0	1.0.0	283.0	2.0.6	ok	ok	nicht getestet	nicht getestet
Outdoor Weather Bricklet	1.0.0	288.0	2.0.4	ok (mit 2 x TH6148)	ok	nicht getestet	nicht getestet
Motion Detector 2.0	1.0.0	292.0	2.0.2	ok	ok	ok	nicht getestet
LCD 128x64	1.0.0	298.0	2.0.7	ok	ok	TouchGesture	DrawText / SetGUITabText / SetGUIButton / SetGUISlider / SetGUITabSelected / RemoveGUITab / RemoveGUIButton / RemoveGUISlider / RemoveAllGUI / ClearDisplay / GetTouchPosition
LCD 20x4	1.2.0	212.0	2.0.6	ok	ok	ok	ClearDisplay
Industrial Dual Relay	1.0.0	284.0	2.0.3	ok	ok	nicht getestet	nicht getestet
Industrial Quad Relay 2.0	1.0.0	2102.0	2.0.3	ok	ok	nicht getestet	nicht getestet
Digital In 4 (2.0)	1.0.0	2100.0	2.0.2	ok	ok	nicht getestet	getEdgeCount
IO-16 Bricklet	1.1.0	28.0	2.0.6	ok	ok	nicht getestet	getEdgeCount
IO-16 Bricklet 2.0	1.0.0	2114.0	2.0.2	ok	ok	nicht getestet	getEdgeCount
IO-4 V2	1.0.0	2111.0	2.0.4	ok	ok	nicht getestet	getEdgeCount
Piezo Speaker 2.0	1.0.0	2145.0	2.0.2	ok	ok	nicht getestet	SetAlarm / GetAlarm / SetBeep / GetBeep / UpdateFrequency / UpdateVolume
Tinkerforge HAT Brick	1.0.0	111.0	2.0.1	nicht getestet	nicht getestet	nicht getestet	nicht getestet
Tinkerforge Master Brick	2.1.0	13.0	2.4.10	nicht getestet	nicht getestet	nicht getestet	nicht getestet

bearbeitet February 2, 2020 at 15:08 von StefanOHAN

omiT · February 2, 2020 at 15:19

@StefanOHAN und @rtrbt kann man die LEDs am Motion Detector nur leuchten lassen in verschiedenen Stärken (0-255) oder kann man diese auch blinken lassen?

Danke und liebe Grüße

Timo

StefanOHAN · February 3, 2020 at 05:50

Hallo Erik

kurzer Update zu meinem Test von Gestern, heute Morgen (3.2.2020, ab 5:23Uhr) ging wieder kurzfristig die Verbindung zu den per USB Angeschlossenen Masterbrick‘s & dem HAT verloren. (die Dämon‘s habe ich nach dem einspielen des Beta 17 neue eingerichtet). Die beiden Masterbrick sind per RS485-Extention miteinander verbunden (ist aber seit Beginn der Testreihen so). Der Dämon der für das WIFI angebundene Masterbrick zuständig ist, ist nicht ausgefallen.

Zitat

2020-02-03 05:23:23.104 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6DzXrA' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Device is unreachable.

2020-02-03 05:23:23.122 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6dLEow' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Device is unreachable.

2020-02-03 05:23:30.630 [hingStatusInfoChangedEvent] - 'tinkerforge:brickhat:JYv' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Device is unreachable.

2020-02-03 05:24:23.140 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6DzXrA' changed from OFFLINE (COMMUNICATION_ERROR): Device is unreachable. to OFFLINE (BRIDGE_OFFLINE)

2020-02-03 05:24:23.270 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6dLEow' changed from OFFLINE (COMMUNICATION_ERROR): Device is unreachable. to OFFLINE (BRIDGE_OFFLINE)

2020-02-03 05:24:23.250 [hingStatusInfoChangedEvent] - 'tinkerforge:brickhat:JYv' changed from OFFLINE (COMMUNICATION_ERROR): Device is unreachable. to OFFLINE (BRIDGE_OFFLINE)

2020-02-03 05:24:23.380 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6DzXrA' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE

2020-02-03 05:24:23.411 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6dLEow' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE

2020-02-03 05:24:24.238 [hingStatusInfoChangedEvent] - 'tinkerforge:brickhat:JYv' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE

Im Log konnte ich keine weiteren Ausfälle feststellen, allerdings läuft das System erst ca 20 Stunden ohne einen Reboot.

Ich werde heute Abend in jede Rule eine Event-loginfo Meldung einbauen, dann sehe ich ja ob es öfters vorkommt.

Diese Mal haben keine Rules die per Channel Trigger angesteuert werden reagiert, allerdings haben sich die Background Beleuchtung des LCD 128x64 & LCD 20x4 eingeschaltet.

Kannst Du das mit dem Connetion Lost bitte nochmal checken ?

Viele Grüße

Stefan

@omiT

das mit dem Blinken der LED kann ich nicht beantworten, hier ist Erik der Spezialist

bearbeitet February 3, 2020 at 05:51 von StefanOHAN

rtrbt · February 3, 2020 at 10:30

Moin,

19 hours ago, StefanOHAN said:

Frage: ist das eine Funktion die noch nicht aktiv ist ? Oder welche Aufgabe hat diese ?

Das ist der FirmwareProvider, der holt sich von downloads.tinkerforge.com die aktuellen Firmwareversionen ab und zeigt Updates an. Ich habe das bei mir auch gerade im Log, sehe ich mir mal an. Das null sollte eigentlich eine hilfreichere Fehlermeldung sein, aber da fliegt scheinbar eine Exception, die keine Nachricht hat.

19 hours ago, StefanOHAN said:

Einzig für EdgeCount der „per Channel mit einem Item“ verlinkt ist, bekomme ich noch immer 0 als Ergebnis, kann aber daran liegen dass ich diesen evlt. falsch nutze.

Benutzt du zum Auslesen dann den Channel? Falls ja, musst du aktuell immer mal REFRESH-Commands schicken, damit der Wert sich bewegt.

19 hours ago, StefanOHAN said:

Einen komischen Effekt habe ich beim „Multi Touch Bricklet 2.0“ (mit der alten V1 Version habe ich es nicht getestet), egal welche Elektroden-Taste ich berühre, es kommt immer für alle (die nicht berührt wurden) Elektroden die Meldung „triggered RELEASED. Ist das so gewollt ? (ich verwende Euer Key-Pad 3x4)

Das liegt daran, dass ich die Elektroden jetzt als Trigger-Channel behandle, aber das Bricklet selbst nur ein Callback für alle Elektroden hat, dieses aber bei jeder Änderung auslöst. Da muss ich mir mal was einfallen lassen.

19 hours ago, StefanOHAN said:

Frage: Meinst Du es würde zu viel Last verursachen wenn ich die für das IO-16 / IO-4 den „Update Interval“ von 1000ms auf 250ms verkürze ? Wenn ich diese als Input für angeschlossene „Taster“ zum Lichtschalten verwende sind 1000ms etwas lange. Ich würde maximal dies für 2 x IO-16 anwenden.

Das sollte kein Problem sein, da die Callbacks alle nur auslösen sollten, wenn sich Werte ändern.

19 hours ago, omiT said:

kann man die LEDs am Motion Detector nur leuchten lassen in verschiedenen Stärken (0-255) oder kann man diese auch blinken lassen?

Das kannst du z.B. mit einer Rule und einem time-based-trigger machen.

4 hours ago, StefanOHAN said:

Kannst Du das mit dem Connetion Lost bitte nochmal checken ?

Sehe ich mir nochmal an. Du kannst mal in der Karaf-Konsole

log:set TRACE org.eclipse.smarthome.binding.tinkerforge

ausführen. Dann sollten im Log alle 90 Sekunden solche Ausgaben erscheinen:

[DEBUG] [rforge.internal.handler.DeviceHandler] - Checking reachability of 6esErP
[DEBUG] [rforge.internal.handler.DeviceHandler] - Done checking reachability of 6esErP
Falls da was schiefgeht kommen eventuell hilfreiche Informationen raus.

rtrbt · February 3, 2020 at 10:51

Sorry, deinen Post hatte ich übersehen.

On 2/1/2020 at 4:39 PM, Maxicko said:

Leider klappt das noch nicht so ganz.

Was mir dabei aufgefallen ist, der Channel "Command" für die TypeA-Things wird mit Typ "String" und nicht mit "Switch" angegeben. Ist das so korrekt?

Was klappt dabei noch nicht? Die Command-Channels sind Strings statt Switches, da es keinen Rückkanal von den Steckdosen gibt: openHAB kann nicht abfragen, ob eine Dose gerade an oder aus ist, also kann ich bei einem Switch nicht den Initialzustand setzen. Command-Channels (die in der PaperUI Buttons erzeugen) sind intern String-Channels. Du kannst z.b. aus Rules StringCommands "ON" oder "OFF" schicken um die Dose zu schalten.

Maxicko · February 3, 2020 at 21:44

vor 10 Stunden schrieb rtrbt:

Was klappt dabei noch nicht? Die Command-Channels sind Strings statt Switches, da es keinen Rückkanal von den Steckdosen gibt: openHAB kann nicht abfragen, ob eine Dose gerade an oder aus ist, also kann ich bei einem Switch nicht den Initialzustand setzen. Command-Channels (die in der PaperUI Buttons erzeugen) sind intern String-Channels. Du kannst z.b. aus Rules StringCommands "ON" oder "OFF" schicken um die Dose zu schalten.

Hab bisher die Items alle selber erstellt und nicht über das PaperUI. Hatte aus Gewohnheit das Item als Switch erstellt. Musste das somit nur als String definieren und schon gehts es!

Vielen Dank und Gruß
Max

StefanOHAN · February 4, 2020 at 07:24

Hallo Erik

heute Abend (3.2.2020) habe ich wie von dir empfohlen über die Karaf-Konsole den erweiterten Log aktiviert.

Zitat

„log:set TRACE org.eclipse.smarthome.binding.tinkerforge“

Eine parallel Überprüfung der „Logs“ nach Error und Brickmaster, zeigten keine verdächtigen Einträge.

Ich habe mir noch mal überlegt was ich in den letzten Tagen alles geändert haben.

Die Hardware Konfiguration der über UBS/HAT angeschlossenen Masterbricks / Bricklets hat sich seit Anfang November nicht geändert. Erstmals aufgefallen ist mir das offline gehen des Dämon ab dem Binding 16.

Mal schau‘n was der Trace für Ergebnisse bringt.

Thema EdgeCount per Channel Link

Danke für den Hinweis, wenn ich in der Rule vorher einen REFRESH auf das ITEM des verlinkten EdgeCount ausführe, kommt ein Ergebnis.

Zitat

Number P0Countg7y "Pin0 IO4 Counter IO4-V2 [%s]" (TestTF){ channel="tinkerforge:brickletio4v2:G7y:BrickletIO4V2EdgeCountPin0"}

>>

P0Countg7y.sendCommand(REFRESH)

Beim EdgeCount Test ist mir zufällig folgende DEBUG-Meldung aufgefallen, die immer erscheint wenn ich einen der BUIButton des LCD128x64 betätigte.

Hat dies einen Bedeutung ? (die Rule funktioniert auf jedem Fall)

Zitat

2020-02-03 20:04:06.957 [DEBUG] [ernal.TinkerforgeChannelTypeProvider] - Could not find device info for channelTypeUID system:rawbutton: null.

Ansonsten lief das System tagsüber ohne Störung

Erste Error Meldungen ab 20:33Uhr

Meldungen aus dem Log

Zitat
2020-02-03 20:33:41.423 [DEBUG] [forge.internal.handler.DeviceHandler] - Failed checking reachability of 6kMKrA: Did not receive response in time for function ID -1

2020-02-03 20:33:41.434 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6kMKrA' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Device is unreachable. 2020-02-03 20:35:38.854 [hingStatusInfoChangedEvent] - 'tinkerforge:brickmaster:6kMKrA' changed from OFFLINE (COMMUNICATION_ERROR): Device is unreachable. to OFFLINE (BRIDGE_OFFLINE)
020-02-03 20:36:46.009  - 'tinkerforge:brickmaster:6kMKrA' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE

von 20:32Uhr bis 20:40Uhr kamen mehrfach diese Meldungen, leider konnte ich keine weiteren Kommentare im Log finden, 
die etwas aufschlussreicher gewesen wären. Die restliche Nacht lief alles ohne Ausfall.

Heute morgen das gleich Spiel erst geht die Bridge kurz offline und dann wieder online, 
und nach einigen Minuten ein längere Ausfall der soweit führte, dass sich die Background Light des LCD128x64 
und LCD20x4 einschlaten (ohne dass eine Rule auf die Displays neue werte schreiben)

Die relevanten teile der Logfile Auszuge hänge ich als txt Datei an (ich hoffe er ist lesbar), leider ist er nicht besonder aussagekräftig

Es ist immer nur der Dämon betroffen der für das HAT-Brick und den per USB angeschlossenen Masterbrick zuständig ist.

Kann es sein dass die Kombination

Raspi -> USB->Masterbrick1->RS485->Masterbrick2

Raspi -> HAT-Brick

Probleme bereiten kann ? Diese Konfiguration läuft aber schon mindestens 3-4 Monate.

Der Masterbrick der per WIFI-Extention angebunden ist, ist nicht betroffen.

Benötigst Du einen Detail Info zur Konfiguration ? Haben Masterbrick / HAT-Brick logfile die nutzbar wären ?

Macht es Sinn zu testen ob mit einer älteren Binding Version ähnliche Fehler auftauchen ?

viele Grüsse

Stefan

20200203-openhab&event-Log

bearbeitet February 4, 2020 at 07:44 von StefanOHAN

rtrbt · February 4, 2020 at 12:41

5 hours ago, StefanOHAN said:

Beim EdgeCount Test ist mir zufällig folgende DEBUG-Meldung aufgefallen, die immer erscheint wenn ich einen der BUIButton des LCD128x64 betätigte.

Hat dies einen Bedeutung ? (die Rule funktioniert auf jedem Fall)

Quote

2020-02-03 20:04:06.957 [DEBUG] [ernal.TinkerforgeChannelTypeProvider] - Could not find device info for channelTypeUID system:rawbutton: null.

Das kannst du ignorieren, die Ausgabe kommt, weil openHAB immer alle ChannelTypeProvider nach ChannelTypes fragt, selbst wenn die ChannelTypeUID offensichtlich nichts mit dem Binding zutun hat. Der TinkerforgeChannelTypeProvider (den ich für das dynamische Anlegen von Channels brauche) beschwert sich da nur, dass er mit dem system:rawbutton-Typ nichts anfangen kann, das ist ja einer von openHAB selbst.

Bezüglich der Ausfälle: Ich vermute, dass das Binding da noch zu aggressiv ist, wenn mal einzelne Pakete verloren gehen. Das habe ich mal etwas entschärft, kommt mit der nächsten Beta.

5 hours ago, StefanOHAN said:

Benötigst Du einen Detail Info zur Konfiguration ? Haben Masterbrick / HAT-Brick logfile die nutzbar wären ?

Macht es Sinn zu testen ob mit einer älteren Binding Version ähnliche Fehler auftauchen ?

Interessant wäre, welche Bricklets du an den Master Bricks und dem HAT hast. Bei dem Aufbau meinst du, dass sowohl HAT als auch Master Brick am selben Raspberry Pi hängen?

In den alten Versionen den Fehler zu suchen dürfte nichts bringen, das Verhalten habe ich sowieso mehrfach umgeworfen.

StefanOHAN · February 4, 2020 at 12:56

Hallo Erik,

nur ganz kurz.

Ja beim Aufbau meinte ich, dass auf meinem Raspberry Pi das HAT-Brick aufgesteckt ist und ein Masterbrick über den USB-Port mit dem gleichen Raspberry verbunden ist (eigentlich sind es zwei Masterbrick da über eine RS485 Extention ein weiter Masterbrick im Verbund ist).

Ich versuche heute Abend mal einen Snapshot aus dem Brickviewer zu machen da dürfte man schön sehen was alles angebunden ist.

Du schreibst

Zitat

Bezüglich der Ausfälle: Ich vermute, dass das Binding da noch zu aggressiv ist

Frage: Hast du in den letzten Bindings die "aggressivität" der Überwachung verändert ?

viele Grüsse

Stefan

bearbeitet February 4, 2020 at 13:00 von StefanOHAN

rtrbt · February 4, 2020 at 13:18

16 minutes ago, StefanOHAN said:

Frage: Hast du in den letzten Bindings die "aggressivität" der Überwachung verändert ?

Ja, zumindest die Auswirkungen davon: Da Timeouts auftreten können, während ein Device konfiguriert wird, muss ich, wenn ein Device wieder online geht, es neu konfigurieren.

Das ist dann auch der Grund, weshalb bei dir das Backlight angeht. Das bekommst du dann in den Griff, indem du die Default-Helligkeit auf aus stellst und nur wieder an machst, wenn du es brauchst.

StefanOHAN · February 5, 2020 at 05:49

Hallo Erik,

anbei die Konfiguration (ist analog der Brickviewer Ansicht).

Ich hoffe dass man erkennen kann dass der zweite Masterbrick über RS485 Extention mit dem ersten Masterbrick verbunden ist.

Brick-Dämon1 , direkt am Raspberry Pi angeschlossen			Position	FW	HW	Modell-ID
HAT-Brick	*Raspi GPIO*			2.0.1	1.0.0	111.0
	LCD128x64		A	2.0.7	1.0.0	298.0
	Multi Touch 2.0		B	2.0.0	1.0.0	2129.0
	Motion Detector 2.0		C	2.0.2	1.0.0	292.0
	Rotary Encoder 2.0		D	2.0.4	1.0.0	294.0
	Humidity Brickelt 2.0		E	2.0.6	1.0.0	283.0
	Frei		F
	Rotary Poti 2.0		G	2.0.0	1.0.0	2140.0
	Outdoor Weather		H	2.0.4	1.0.0	288.0
Master Brick 2.1	*Per USB*		0	2 . 4 . 10	2.1.0	13.0
	IO-16		A	2.0.6	1.1.0	28.0
	IO-4		B	2.0.4	1.0.0	2111.0
	LCD20x4 Bricklet 1.2		C	2.0.6	1.2.0	212.0
	Frei		D

	Master Brick 2.1	per RS485 verbunden	0	2 . 4 . 10	2.1.0	13.0
		IO-16 2.0	A	2.0.2	1.0.0	2114.0
		IO-16	B	2.0.6	1.1.0	28.0
		Indust Quad Relay 2.0	C	2.0.3	1.0.0	2102.0
		Indust Quad Relay 2.0	D	2.0.3	1.0.0	2102.0
		RS485 Extention (Slave)	Ext0
im Stapel des MB	RS485 Extention (Master)		Ext0



Brick-Dämon-2 / per WLAN über AVM mit Raspberry verbunden			Position	FW	HW	Modell-ID
Master Brick 2.1			0	2 . 4 . 10	1.0.0	2145.0
	Piezo Speaker 2.0		A	2.0.2	1.0.0	284.0
	Indust Dual Relay		B	2.0.3	284.0	2.0.3
	E-Paper 296x128		C	2.0.1	1.0.0	2146.0
	Indust Digital In-4 2.0		D	2.0.2	1.0.0	2100.0
	WIFI Extentision 2.0		Ext0

Aktuell noch nicht ist das NFC und der Remote-Switch Bricklet angeschlossen

Sollte die Konfiguration nicht lesbar/verständlich sein, sag bitte bescheit, dann werde ich einen Screenshot des Brickviewer posten.

viele Grüsse

Stefan

P.S. hatte gestern/heute morgen 3 mal den Reconnect

bearbeitet February 5, 2020 at 05:56 von StefanOHAN

rtrbt · February 10, 2020 at 14:38

Moin,

Beta 18 ist jetzt im Post oben. Es sollte damit nicht mehr nötig sein, Channels Refresh-Commands zu schicken. Falls das doch irgendwo noch hängt, bitte einmal Bescheid sagen.

@StefanOHAN In der neuen Beta habe ich mehr Debug-Meldungen eingebaut, mit denen wir hoffentlich deinen Verbindungsproblemen auf den Grund gehen können. Außerdem habe ich noch ein paar Bugs in die Richtung behoben, vielleicht funktioniert es ja jetzt einfach. Lass das ganze bitte nochmal mit log:set TRACE org.eclipse.smarthome.binding.tinkerforge laufen.

Gruß,
Erik

Betaversion der openHAB-Bindings

Recommended Posts

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

rtrbt

StefanOHAN

StefanOHAN

Posted Images

Join the conversation