rtrbt Posted January 26, 2020 at 02:38 PM Author Share Posted January 26, 2020 at 02:38 PM Sorry, das hatte ich übersehen. Du kannst die Repeats mit der brickletRemoteSwitchSetRepeats Action einstellen. 1 Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted January 26, 2020 at 06:25 PM Share Posted January 26, 2020 at 06:25 PM (edited) 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 Edited January 26, 2020 at 06:31 PM by StefanOHAN Quote Link to comment Share on other sites More sharing options...
omiT Posted January 26, 2020 at 10:58 PM Share Posted January 26, 2020 at 10:58 PM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted January 27, 2020 at 11:14 AM Author Share Posted January 27, 2020 at 11:14 AM 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 Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted January 27, 2020 at 06:36 PM Share Posted January 27, 2020 at 06:36 PM (edited) 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 Edited January 27, 2020 at 06:47 PM by StefanOHAN 1 Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted January 27, 2020 at 06:43 PM Share Posted January 27, 2020 at 06:43 PM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted January 28, 2020 at 08:42 AM Author Share Posted January 28, 2020 at 08:42 AM 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). Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted January 29, 2020 at 05:55 AM Share Posted January 29, 2020 at 05:55 AM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted January 30, 2020 at 03:36 PM Author Share Posted January 30, 2020 at 03:36 PM 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. Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted January 31, 2020 at 09:56 AM Share Posted January 31, 2020 at 09:56 AM 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 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted January 31, 2020 at 10:28 AM Author Share Posted January 31, 2020 at 10:28 AM 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. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted January 31, 2020 at 03:00 PM Author Share Posted January 31, 2020 at 03:00 PM 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 Quote Link to comment Share on other sites More sharing options...
Maxicko Posted February 1, 2020 at 03:39 PM Share Posted February 1, 2020 at 03:39 PM 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 Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted February 2, 2020 at 03:04 PM Share Posted February 2, 2020 at 03:04 PM (edited) 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 Edited February 2, 2020 at 03:08 PM by StefanOHAN Quote Link to comment Share on other sites More sharing options...
omiT Posted February 2, 2020 at 03:19 PM Share Posted February 2, 2020 at 03:19 PM @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 Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted February 3, 2020 at 05:50 AM Share Posted February 3, 2020 at 05:50 AM (edited) 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 Edited February 3, 2020 at 05:51 AM by StefanOHAN Quote Link to comment Share on other sites More sharing options...
rtrbt Posted February 3, 2020 at 10:30 AM Author Share Posted February 3, 2020 at 10:30 AM 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. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted February 3, 2020 at 10:51 AM Author Share Posted February 3, 2020 at 10:51 AM 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. Quote Link to comment Share on other sites More sharing options...
Maxicko Posted February 3, 2020 at 09:44 PM Share Posted February 3, 2020 at 09:44 PM 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 Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted February 4, 2020 at 07:24 AM Share Posted February 4, 2020 at 07:24 AM (edited) 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 Edited February 4, 2020 at 07:44 AM by StefanOHAN Quote Link to comment Share on other sites More sharing options...
rtrbt Posted February 4, 2020 at 12:41 PM Author Share Posted February 4, 2020 at 12:41 PM 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. Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted February 4, 2020 at 12:56 PM Share Posted February 4, 2020 at 12:56 PM (edited) 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 Edited February 4, 2020 at 01:00 PM by StefanOHAN Quote Link to comment Share on other sites More sharing options...
rtrbt Posted February 4, 2020 at 01:18 PM Author Share Posted February 4, 2020 at 01:18 PM 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. Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted February 5, 2020 at 05:49 AM Share Posted February 5, 2020 at 05:49 AM (edited) 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 Edited February 5, 2020 at 05:56 AM by StefanOHAN Quote Link to comment Share on other sites More sharing options...
rtrbt Posted February 10, 2020 at 02:38 PM Author Share Posted February 10, 2020 at 02:38 PM 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.