rtrbt Posted September 30, 2020 at 11:37 AM Author Share Posted September 30, 2020 at 11:37 AM Darüber habe ich die Tage auch nachgedacht. Soweit ich das sehe wäre das Portieren auf openHAB 3 ein eher überschaubarer Aufwand. Da meines Wissens damit die alte Rule-Engine rausfliegt hätte das sogar diverse Vorteile, da ich viel Code und redundante Namen sparen könnte. Die Actions könnten dann z.b. rgb.getColor() anstelle von rgb.brickletRGBLEDButtonGetColor() bekommen. Die Frage wäre dann eher was ich mit openHAB 2 mache. Zwei Versionen warten kommt nicht in Frage, das heißt man könnte das ganze entweder als openHAB 2 Binding lassen, das auch in openHAB 3 funktioniert, oder eben alternativ openHAB 2 Support verwerfen und die ganzen Vereinfachungen die sich dann ergeben mitnehmen. Ich habe aber noch auf absehbare Zeit (lies mindestens den nächsten Monat) noch andere Aufgaben die dringender sind, d.h. es eilt nicht da eine Entscheidung zu treffen. Frage an die künftigen Nutzer (auch @StefanOHAN ) Plant ihr dann eher schnell auf openHAB 3 zu wechseln oder eher auf openHAB 2.5 zu bleiben? Quote Link to comment Share on other sites More sharing options...
MiRo Posted September 30, 2020 at 07:47 PM Share Posted September 30, 2020 at 07:47 PM Hallo, ich habe jetzt gerade wieder den Fall, dass es nicht so richtig funktioniert - 2 Tage ging es wieder gut. Erst mal alle "timeouts" im BrickViewer stehen auf 0. Ich habe dieses mapping im trace "io1->1:", "io2->2:", usw. io1/io2/io3 sind io16 ("alt"), io4 ist io16_v2 ("neu"). An io4 sind aber im wesentlichen Fenster- und TürSchalter dran, und da ändert sich eigentlich fast nie was. Deshalb tauchen die im Trace auch fast nie auf. Ich bekomme jetzt auch interrupts - jedenfall für io1:Port B:Pin 4 (2mal drücken und wieder loslassen) 1: 2020:09:30 20:44:54.012 1: Port: b 1: Interrupt Mask: 0x8 1: Value Mask: 0x0 1: 2020:09:30 20:45:12.887 1: Port: b 1: Interrupt Mask: 0x8 1: Value Mask: 0x8 1: 2020:09:30 20:45:13.815 1: Port: b 1: Interrupt Mask: 0x8 1: Value Mask: 0x0 1: 2020:09:30 20:45:13.815 1: Port: b 1: Interrupt Mask: 0x8 1: Value Mask: 0x0 oder io2:Port A:Pin 0 2: 2020:09:30 20:54:46.505 2: Port: a 2: Interrupt Mask: 0x1 2: Value Mask: 0x1 2: 2020:09:30 20:54:47.547 2: Port: a 2: Interrupt Mask: 0x1 2: Value Mask: 0x0 2: 2020:09:30 20:55:12.383 2: Port: a 2: Interrupt Mask: 0x1 2: Value Mask: 0x1 2: 2020:09:30 20:55:14.911 2: Port: a 2: Interrupt Mask: 0x1 2: Value Mask: 0x0 Mit richtigen Werten für die ValueMask - aber keine Event im OH 2020-09-30 20:44:29.937 [DEBUG] [forge.internal.handler.DeviceHandler] - 6RPncX was already online. Will not reinitialize. 2020-09-30 20:44:29.939 [DEBUG] [forge.internal.handler.DeviceHandler] - io4 is not in bootloader mode. 2020-09-30 20:44:29.941 [DEBUG] [forge.internal.handler.DeviceHandler] - Done checking reachability of io4 2020-09-30 20:44:29.943 [DEBUG] [forge.internal.handler.DeviceHandler] - io4 was already online. Will not reinitialize. 2020-09-30 20:45:00.038 [INFO ] [pse.smarthome.model.script.hue.rules] - checking illumination consistency for driveway 2020-09-30 20:45:00.052 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - set :457/0 2020-09-30 20:45:00.086 [ERROR] [se.smarthome.model.script.cron.rules] - Io check failed 2020-09-30 20:45:23.007 [ERROR] [arthome.model.script.hue_thing.rules] - hue_bulb2 Status:OFFLINE 2020-09-30 20:45:23.014 [ERROR] [arthome.model.script.hue_thing.rules] - hue_bulb2 StatusDetail:NONE 2020-09-30 20:45:23.021 [ERROR] [arthome.model.script.hue_thing.rules] - hue_bulb2 StatusDescription:@text/offline.light-not-reachable 2020-09-30 20:45:43.113 [ERROR] [arthome.model.script.hue_thing.rules] - hue_bulb5 Status:OFFLINE 2020-09-30 20:54:00.024 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - set :466/0 2020-09-30 20:54:00.045 [ERROR] [se.smarthome.model.script.cron.rules] - Io check failed 2020-09-30 20:54:25.675 [INFO ] [arthome.model.script.hue_thing.rules] - hue_bulb2 Status:ONLINE . . . 2020-09-30 20:55:00.023 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - set :467/0 2020-09-30 20:55:00.027 [INFO ] [pse.smarthome.model.script.hue.rules] - checking illumination consistency for driveway 2020-09-30 20:55:00.042 [ERROR] [se.smarthome.model.script.cron.rules] - Io check failed 2020-09-30 20:55:00.347 [DEBUG] [forge.internal.handler.DeviceHandler] - io4 is not in bootloader mode. 2020-09-30 20:55:00.348 [DEBUG] [forge.internal.handler.DeviceHandler] - Done checking reachability of io4 2020-09-30 20:55:00.349 [DEBUG] [forge.internal.handler.DeviceHandler] - io4 was already online. Will not reinitialize. 2020-09-30 20:56:00.019 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - set :468/0 2020-09-30 20:56:00.040 [ERROR] [se.smarthome.model.script.cron.rules] - Io check failed 2020-09-30 20:56:26.270 [ERROR] [arthome.model.script.hue_thing.rules] - hue_bulb2 Status:OFFLINE 2020-09-30 20:56:26.275 [ERROR] [arthome.model.script.hue_thing.rules] - hue_bulb2 StatusDetail:NONE 2020-09-30 20:56:26.281 [ERROR] [arthome.model.script.hue_thing.rules] - hue_bulb2 StatusDescription:@text/offline.light-not-reachable Die Ausgaben > check io16 bricklet - set :468/0 zeigen, dass seit hier 468sec der Wechsel des io3:Port B:Pin 7 nicht erkannt wurde. 3: 2020:09:30 20:55:00.108 3: Port: b 3: Interrupt Mask: 0x80 3: Value Mask: 0xc4 3: 2020:09:30 20:56:00.103 3: Port: b 3: Interrupt Mask: 0x80 3: Value Mask: 0x44 Jetzt sehe ich übrigens auch, dass ich hier einigen Müll erzählt habe - entschuldige vielmals. Der io3 hat einige unbelegte (offene) Pins deshalb stehen da einige Ports auf High. Da habe ich leider einen total falschen Trace genommen. Da kam im Trace wohl leider genau in dem Moment wo ich den Schalter betätigt habe ein anderes Event. Du hast natürlich vollkommen Recht. In dem von mir fälschlicherweise erwähnten Trace ist es eine fallende Flanke. Und es ist halt leider auch noch genau der besagte Pin io3:PortB:Pin7 den ich selber permanent toggeln lasse. Also - die Interrupts scheinen alle super zu funktionieren. Aber die events im OH kommen nicht. Ich habe noch mal das mit dem REFRESH probiert und einen Trace gemacht. VersuchsAufbau: Schalter: Switch tinkerforge_Io16_mod2_ina0 "Küche [MAP(en.map):%s]" {channel="tinkerforge:brickletio16:io2:BrickletIO16InputPin0", expire="10s,state=OFF"} OH-trace example_interrupt trace Ausgangszustand: io2:A0=Offen=LOW Versuch: io2:A0->getStatus io2:A0->drücken=Schliessen io2:A0->getStatus REFRESH senden io2:A0->getStatus --------------------------------- io2:A0->loslassen=Öffnen io2:A0->getStatus REFRESH senden io2:A0->getStatus Hier das Ergebnis: KuechenTest.zip. Jetzt habe ich gesehen, dass das Event vom Loslassen (HIGH->LOW) (tinkerforge_Io16_mod2_ina0 changed from ON to OFF) eher kam als das REFRESH event. Daher habe ich den Versuch noch mal wiederholt - aber nur bis Schritt 8. KuechenTest2.zip - aber das Event "tinkerforge_Io16_mod2_ina0 changed from ON to OFF" wird sehr wahrscheinlich vom ExpireBinding getriggered - und nicht vom TinkerforgeBinding. Immer exakt 10sec nach OFF->ON. Also habe ich das Item tinkerforge_Io16_mod2_ina0 geändert in Switch tinkerforge_Io16_mod2_ina0 "Küche [MAP(en.map):%s]" {channel="tinkerforge:brickletio16:io2:BrickletIO16InputPin0" und den Versuch ein 3. Mal wiederholt: KuechenTest3.zip. Und jetzt sieht man auch, dass die ON->OFF transition erst nach dem REFRESH kommt. Hier noch mal die caraf-KommandoZeile von Versuch 3 - leider ohne Zeitstempel. openhab> smarthome:status tinkerforge_Io16_mod2_ina0 OFF openhab> smarthome:status tinkerforge_Io16_mod2_ina0 OFF openhab> smarthome:send tinkerforge_Io16_mod2_ina0 REFRESH Command has been sent successfully. openhab> smarthome:status tinkerforge_Io16_mod2_ina0 ON openhab> smarthome:status tinkerforge_Io16_mod2_ina0 ON openhab> smarthome:send tinkerforge_Io16_mod2_ina0 REFRESH Command has been sent successfully. openhab> smarthome:status tinkerforge_Io16_mod2_ina0 OFF openhab> Quote Link to comment Share on other sites More sharing options...
KlausGünther Posted October 1, 2020 at 06:15 AM Share Posted October 1, 2020 at 06:15 AM Ich hatte mal für mich so überlegt, zwischen Weihnachten und Neujahr mal die Speicherkarte zu klonen und dann testweise mal auf OH3 umzusteigen sollte es bis dahin verfügbar sein. Und dann wird es mit der neuen Rule Engine eh spannend bis das alles läuft.... Quote Link to comment Share on other sites More sharing options...
rtrbt Posted October 1, 2020 at 01:56 PM Author Share Posted October 1, 2020 at 01:56 PM 7 hours ago, KlausGünther said: Und dann wird es mit der neuen Rule Engine eh spannend bis das alles läuft.... Soweit ich das verstanden habe kannst du bei der neuen Engine die alten Rules weiterverwenden, die werden dann übersetzt. Stecke in den Details aber nicht drin. @MiRo Das sieht dann wirklich nach einem reinen openHAB-Problem aus. Ich habe bei mir mal folgenden Aufbau hingestellt: Ich schalte einmal pro Sekunde per Rule jeweils Pin 0, lese das auf Pin 1 zurück (das läuft dann über das Callback, also ohne expliziten REFRESH) und schalte mit dem Ergebnis die LED auf Pin 4. Falls das hängt kann ich mit den Schaltern nochmal versuchen Ereignisse auszulösen zum debuggen. Das ganze sind eine IO16 2.0, zwei IO16 1.2 und eine IO16 1.1 an einem Master Brick 2.1 an einem Pi auf dem openHAB läuft. Ich melde mich, wenn ich damit etwas rausbekomme. Quote Link to comment Share on other sites More sharing options...
MiRo Posted October 1, 2020 at 06:30 PM Share Posted October 1, 2020 at 06:30 PM @rtrbt: Super Danke. Ich habe jetzt als NotLösung erst mal einen Restart eingebaut, wenn ich 3min lang keine Änderung auf dem IO16 sehe. Schönes Wochenende. Quote Link to comment Share on other sites More sharing options...
Jerome Posted October 1, 2020 at 08:13 PM Share Posted October 1, 2020 at 08:13 PM On 9/30/2020 at 1:37 PM, rtrbt said: Frage an die künftigen Nutzer (auch @StefanOHAN ) Plant ihr dann eher schnell auf openHAB 3 zu wechseln oder eher auf openHAB 2.5 zu bleiben? Wenn möglich würde ich auf openHab 3 wechseln. Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted October 2, 2020 at 09:18 AM Share Posted October 2, 2020 at 09:18 AM (edited) Hallo Erik, sorry dass ich erst jetzt auf Deine Frage Antworte. Ich bin der Meinung von Jerome, dass es das Beste wäre gleich auf Openhab 3 zu wechseln. Mein Prod-System habe ich noch nicht auf OH2.5 migriert, daher würde ich es gleich auf OH3 umstellen. Ich plädieren wie Jerome dafür, dass Du gleich das Binding dann OH-3 konform umstellst (Bitte kurze Info wenn das 2.5 Binding dann nicht mehr zum download bereit steht, dass ich mir ein Backup ziehen kann) Frage: Du hast mir ja die spezial-Version wegen meines Recconect Problem der 2-Dämon's bereitgestellt. Baust Du diese Korrektur noch in das 2.5 Binding ein (oder erst in die 3) ? Planst Du auch noch das Thema der IO-Brickets die als Input konfiguriert sind wieder als "Contact" und nicht mehr als Switch in das 2.5-Binding einzubauen bevor Du dann nach 3.x umstellst ? Es wäre gut wenn beides noch im 2.5-Beta integriert wird. viele Grüsse Stefan Edited October 2, 2020 at 09:26 AM by StefanOHAN 1 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted October 2, 2020 at 12:17 PM Author Share Posted October 2, 2020 at 12:17 PM 2 hours ago, StefanOHAN said: Du hast mir ja die spezial-Version wegen meines Recconect Problem der 2-Dämon's bereitgestellt. Baust Du diese Korrektur noch in das 2.5 Binding ein (oder erst in die 3) ? Der Fix sollte automatisch in der nächsten Beta landen, er ist schon im Repository. 2 hours ago, StefanOHAN said: Planst Du auch noch das Thema der IO-Brickets die als Input konfiguriert sind wieder als "Contact" und nicht mehr als Switch in das 2.5-Binding einzubauen bevor Du dann nach 3.x umstellst ? Das ist ein interessanter Punkt über den ich so noch nicht nachgedacht hatte. Das hängt ja daran, dass ich nochmal alle (Generator-)Konfigurationen durchgehe und die deutsche Doku schreibe usw. Das heißt es ist vermutlich sinnvoll, wenn ich den Wechsel auf openHAB-3-Only möglichst spät mache, damit möglichst viel was noch auf meiner Liste steht es in eine 2.5er Beta schafft. Werde ich auf jeden Fall berücksichtigen. Quote Link to comment Share on other sites More sharing options...
KlausGünther Posted October 4, 2020 at 07:32 AM Share Posted October 4, 2020 at 07:32 AM Am 2.10.2020 um 14:17 schrieb rtrbt: Das heißt es ist vermutlich sinnvoll, wenn ich den Wechsel auf openHAB-3-Only möglichst spät mache, damit möglichst viel was noch auf meiner Liste steht es in eine 2.5er Beta schafft. Werde ich auf jeden Fall berücksichtigen. Können wir Dich bis dahin noch irgendwie unterstützen ? Quote Link to comment Share on other sites More sharing options...
roben Posted October 4, 2020 at 12:01 PM Share Posted October 4, 2020 at 12:01 PM On 10/2/2020 at 11:18 AM, StefanOHAN said: Planst Du auch noch das Thema der IO-Brickets die als Input konfiguriert sind wieder als "Contact" und nicht mehr als Switch in das 2.5-Binding einzubauen bevor Du dann nach 3.x umstellst ? Oh man, danke für diesen Hinweis! Ich habe meinen Garagentorsensor seit der Umstellung auf OH2.5 / Beta-Binding nicht mehr an Laufen bekommen und es lag einfach nur daran, dass ich vom alten Binding noch "Contact" stehen hatte. DAS wäre definitiv noch ein guter Punk für die Doku, zumindest zum Umstieg vom alten Binding. Quote Link to comment Share on other sites More sharing options...
StefanOHAN Posted October 5, 2020 at 05:56 AM Share Posted October 5, 2020 at 05:56 AM Hallo Erik, ich hatte diese WE einen eigenartigen Effekt für das "Tinkerforge Remote Switch Bricklet 2.0". Diese steuert eine Funksteckdose vom Typ A. Bisher hat es immer gut funktioniert (wobei ich ehr selten die Dose ansteuerte). Gestern konnte ich über Openhab und über den Brickviewer die Steckdose nicht mehr ein und aus schalten. Über die zugehörige Fernbedienung konnte ich die Steckdose jedoch schalten. Auch konnte ich im Openhab-Log keine Meldung sehen wenn das "Tinkerforge Remote Switch Bricklet 2.0" eigentlich ein Signal von der Fernbedienung hätte empfangen sollen. Es waren aber auch keine Fehlermeldungen im Log zu sehen. Das Thing "Tinkerforge Remote Switch Bricklet 2.0" war online. Alles andere funktionierte (IO / Sensoren / Piezo .... / LCD 128x64 / .. ) soweit ich es sehen konnte Als ich dann über den Brickviewer das Bricklet zurück setzte, funktionierte alles wieder und die Steckdose schaltete sich mehrfach ein und aus, als ob alle "aufgestauten" KDO für die Steckdose von Bricklet abgearbeitet wurden. Nach dem Reset sah ich im Log auch wieder Meldungen wenn ich die Fernbedienung betätigte. Frage kann es sein dass sich hier das Bricklet selber aufgehängt hat ? viele Grüsse Stefan Quote Link to comment Share on other sites More sharing options...
sihui Posted October 9, 2020 at 05:18 PM Share Posted October 9, 2020 at 05:18 PM (edited) Am 2.10.2020 um 14:17 schrieb rtrbt: Ich habe mein Produktivsystem vor einigen Wochen auf die 23. Beta des 2.5 Bindings umgestellt und keinerlei Probleme. Besten Dank! Am 30.9.2020 um 21:47 schrieb MiRo: ich habe jetzt gerade wieder den Fall, dass es nicht so richtig funktioniert Wenn ich das richtig mitgelesen habe geht es hier um ein IO16 Version 1. Dieses Bricklet habe ich ebenfalls und es gibt bei mir keine Probleme damit. Edited October 9, 2020 at 05:20 PM by sihui 1 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted October 12, 2020 at 12:14 PM Author Share Posted October 12, 2020 at 12:14 PM Sorry für die späte Antwort, war im Urlaub. On 10/4/2020 at 9:32 AM, KlausGünther said: Können wir Dich bis dahin noch irgendwie unterstützen ? Im Moment nur durch Bug-Reports. Ich bin leider immer noch mit anderen Projekten beschäftigt. On 10/4/2020 at 2:01 PM, roben said: Oh man, danke für diesen Hinweis! Ich habe meinen Garagentorsensor seit der Umstellung auf OH2.5 / Beta-Binding nicht mehr an Laufen bekommen und es lag einfach nur daran, dass ich vom alten Binding noch "Contact" stehen hatte. DAS wäre definitiv noch ein guter Punk für die Doku, zumindest zum Umstieg vom alten Binding. Wenn du jetzt auf Switch umstellst, musst du aber daran denken, eventuell in ein paar Monaten wieder auf Contact zu wechseln. Langfristig werden reine Inputs wieder Contacts sein. On 10/5/2020 at 7:56 AM, StefanOHAN said: Als ich dann über den Brickviewer das Bricklet zurück setzte, funktionierte alles wieder und die Steckdose schaltete sich mehrfach ein und aus, als ob alle "aufgestauten" KDO für die Steckdose von Bricklet abgearbeitet wurden. Nach dem Reset sah ich im Log auch wieder Meldungen wenn ich die Fernbedienung betätigte. Frage kann es sein dass sich hier das Bricklet selber aufgehängt hat ? Hm da hast du einen interessanten Bug getroffen. Anscheinend passiert folgendes: Ich habe ja die Remote Switch Bricklets von Hand implementiert, damit sie Bridges sind für die Funksteckdosen usw. Ich habe da eine Warteschlange von Tasks (z.b. Schalte die Dose xyz), eine Funktion die die Tasks abarbeitet und eine Variable über die ich mir merke, ob das Bricklet gerade schaltet (Die Funktion darf dann keinen neuen Schaltvorgang auslösen, wenn die Variable gesetzt ist). Diese Variable wird über das isSwitchingDone-Callback des Bricklets zurückgesetzt. Du hattest da jetzt anscheinend das Pech, dass das Callback verloren gegangen ist, also die Variable nie zurückgesetzt wird und deshalb keine Tasks mehr abgearbeitet werden. Der Reset über den Brick Viewer führt dazu, dass openHAB das Device neu initialisiert, da wird auch die Variable zurückgesetzt, die Warteschlange aber nicht geleert, deshalb die aufgestauten Schaltvorgänge. Ich baue mal einen Fix dafür, indem ich einfach ~alle 2 Sekunden explizit den Schaltzustand des Bricklets abfrage und darüber die Variable zurücksetze, falls es fertig ist. Dann kann dieses Problem nicht mehr auftreten. @MiRo Der Aufbau von oben lief bei mir seit dem 2.10. durch und die LEDs blinken noch. Falls sich das ganze doch aufhängt melde ich mich nochmal. Quote Link to comment Share on other sites More sharing options...
MiRo Posted October 18, 2020 at 09:27 AM Share Posted October 18, 2020 at 09:27 AM Hallo @sihuiund @rtrbt, ich habe es jetzt mal einige Zeit mit meiner HIL-"Analyse" laufen lassen. ich toggle einmal pro Minute einen Port des IndustrialOut4 der Port ist einem Inout des IO16_v1 verbunden jetzt sollte ein Event für den IO16_v1 Port generiert werden Wenn das Event kommt zähle ich den OKCounter hoch Wenn das 3mal nicht geht zähle ich den FailureCounter hoch und starte OH neu. Hier (seht Ihr mal wie das die letzten 7 Tage aussieht: Manchmal geht das "lange" gut. Manchmal wird der Fehler schon nach knapp 2 Stunden erkannt - siehe DetailBild Quote Link to comment Share on other sites More sharing options...
rtrbt Posted October 19, 2020 at 08:49 AM Author Share Posted October 19, 2020 at 08:49 AM Moin, Interpretiere ich den Graphen richtig, dass sich die Kommunikation mit dem Bricklet nicht mehr komplett aufhängt? Wenn du jede Minute den Pin änderst müsste ja ansonsten der FailureCounter ab diesem Punkt jede Minute um eins wachsen. Es sind aber in beiden Graphen Zeitabschnitte deutlich größer eine Minute bis der Zähler weiter hochspringt. Quote Link to comment Share on other sites More sharing options...
KlausGünther Posted October 21, 2020 at 07:41 PM Share Posted October 21, 2020 at 07:41 PM Hallo Zusammen, ich beobachte zur Zeit bzw. schon etwas länger einen spannenden Fehler. Nach "einiger Zeit" des Betriebes fangen einige Komponenten an zu - ich sage einfach mal - spinnen. Vielleicht noch mal als Info, ich Betreibe im Garten eine Wetterstation u.a. mit Luftrucksensor und 2 Stationen für Windgeschwindigkeit + Regen (Jeweils getrennt auf 2 Sender). Der Luftdruck bildet irgendwann eine Art Sägezahn aus: Was ja nicht sein kann wenn man an den Luftdruck an sich denkt. und dann passieren so Dinge wie mit der Windgeschwindigkeit: Da bleiben dann auf einmal die Messwerte aus. Könnten natürlich die Batterien leer sein, aber wenn man das zum dritten mal innerhalb von 4 Monaten macht nimmt die wahrscheinlichkeit für Batterien die in der frischen Packung leer waren eher ab. Im Brick Viewer wird dann zum Beispiel nur eine Station gefunden die auch sehr lange "Last Change" Zeiten hat, was ja eigentlich nicht sein sollte. (An dem Sender hängt kein Wind Sensor, dass stimmt also). Denn zweiten Sender an dem dann nur der Windmesser u Windrichtung hängt, findet er gerade gar nicht. Neu gestartet habe ich alles mal. Was kann das sein ? Quote Link to comment Share on other sites More sharing options...
rtrbt Posted October 22, 2020 at 02:28 PM Author Share Posted October 22, 2020 at 02:28 PM Moin, Das sieht von außen nicht openHAB-spezifisch aus. Passiert das auch, wenn du (je nachdem was einfacher ist) das Bricklet aus openHAB entfernst und oder openHAB kurz runterfährst, dann das Bricklet neustartest und mit dem Brick Viewer nachsiehst? Das würde das Debugging schonmal immens erleichtern, wenn es kein openHAB-Problem ist ;) Quote Link to comment Share on other sites More sharing options...
KlausGünther Posted October 22, 2020 at 03:11 PM Share Posted October 22, 2020 at 03:11 PM (edited) Scheint wirklich kein OH Problem zu sein, daher habe ich das ganze mal in einem neuen Thread aufgemacht. Edited October 23, 2020 at 09:25 AM by KlausGünther Quote Link to comment Share on other sites More sharing options...
sihui Posted October 26, 2020 at 07:17 PM Share Posted October 26, 2020 at 07:17 PM Am 30.9.2020 um 13:37 schrieb rtrbt: Frage an die künftigen Nutzer (auch @StefanOHAN ) Plant ihr dann eher schnell auf openHAB 3 zu wechseln oder eher auf openHAB 2.5 zu bleiben? openHAB3. Quote Link to comment Share on other sites More sharing options...
MiRo Posted November 4, 2020 at 06:14 PM Share Posted November 4, 2020 at 06:14 PM Am 19.10.2020 um 10:49 schrieb rtrbt: Moin, Interpretiere ich den Graphen richtig, dass sich die Kommunikation mit dem Bricklet nicht mehr komplett aufhängt? Wenn du jede Minute den Pin änderst müsste ja ansonsten der FailureCounter ab diesem Punkt jede Minute um eins wachsen. Es sind aber in beiden Graphen Zeitabschnitte deutlich größer eine Minute bis der Zähler weiter hochspringt. Hallo, entschuldige die späte Antwort. Nein OH wird einem neu gebootet (sudo systemctl restart openhab2.service). Dann geht es wieder eine Weile. Der FailureCounter ist in Fakt der RebootCounter. Der Zähler des eigentlichen Fehlers - das ich kein ChangeEvent vom IO16 bekomme - ist im Grafen nicht zu sehen. Der ist auch eigentlich uninterressant - immer 0 - bis es nicht mehr geht. - dann zählt er minütlich bis auf 3 Ich habe nie gesehen, dass er z.B. nur bis 2 zählt und dann das ChangeEvent wieder kommt. Gruß Michael Quote Link to comment Share on other sites More sharing options...
rtrbt Posted November 9, 2020 at 09:50 AM Author Share Posted November 9, 2020 at 09:50 AM Moin, Hänge mal bitte die Rules an mit denen du den Test machst, also die mit der du den Pin setzt und die mit der du auf die ChangeEvents wartest und die (Fehler)-Zähler setzt usw. Dann kann ich das hier mal genauso nachbauen wie du das hast. Mein Aufbau läuft übrigens immer noch. Der funktioniert aber anders, da ich die IO16s selbst benutze um einen Pin zu setzen. Quote Link to comment Share on other sites More sharing options...
MiRo Posted November 22, 2020 at 06:09 PM Share Posted November 22, 2020 at 06:09 PM Hallo @rtrbt, wieder mal eine lange Zeit - bis zu meiner Antwort - entschuldige. Hier die Regelncron.rules. Und Items rule_test.items und tinkerforge_digital_out_4.items, tinkerforge_io16.items DIe Files sind reduziert auf die Elemente die für den Test wichtig sind. Jetzt lief es bei mir auch wieder perfekt. Bis ich heute ein Update gemacht habe und IO neu gestartet wurde. Sehr komisch. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted November 25, 2020 at 07:49 AM Author Share Posted November 25, 2020 at 07:49 AM Moin, ich habe das hier mal nachgebaut, bisher (seit gestern ~ 16 Uhr) hat es immer geklappt. Wie üblich: Ich gebe Bescheid wenn sich etwas tut. Quote Link to comment Share on other sites More sharing options...
MiRo Posted November 26, 2020 at 05:05 PM Share Posted November 26, 2020 at 05:05 PM Danke. Ich bleibe dran. Quote Link to comment Share on other sites More sharing options...
sihui Posted November 28, 2020 at 03:36 PM Share Posted November 28, 2020 at 03:36 PM (edited) Am 30.9.2020 um 13:37 schrieb rtrbt: Frage an die künftigen Nutzer (auch @StefanOHAN ) Plant ihr dann eher schnell auf openHAB 3 zu wechseln oder eher auf openHAB 2.5 zu bleiben? Laut dem englischen Forum sind bereits viele Nutzer dabei auf openHAB3 umzusteigen (es gibt inzwischen einen Milestone 3), so habe ich es auch gerade getan. Leider musste ich wieder zurück auf openHAB2 da das Tinkerforge Binding nicht starten möchte. Gibt es eine grobe Timeline wann Tinkerforge openHAB3 kompatibel wird? Die beim Test verwendete Version ist die 23. Beta. 2020-11-28 12:29:48.257 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/opt/openhab/addons/org.openhab.binding.tinkerforge-2.5.6-SNAPSHOT.jar org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.tinkerforge [278] Unresolved requirement: Import-Package: org.eclipse.smarthome.config.core at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?] at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.6.4] at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.6.4] at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4] at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4] Edited November 28, 2020 at 03:37 PM by sihui 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.