Betaversion der openHAB-Bindings

[rtrbt]

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?

[MiRo]

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:

1. io2:A0->getStatus
2. io2:A0->drücken=Schliessen
3. io2:A0->getStatus
4. REFRESH senden
5. io2:A0->getStatus
6. ---------------------------------
7. io2:A0->loslassen=Öffnen
8. io2:A0->getStatus
9. REFRESH senden
10. 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>

 

[KlausGünther]

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

[rtrbt]

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.

[MiRo]

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

[Jerome]

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.

[StefanOHAN]

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

bearbeitet October 2, 2020 at 09:26 von StefanOHAN

[rtrbt]

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.

[KlausGünther]

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 ?

[roben]

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.

[StefanOHAN]

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

[sihui]

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.

 

 

 

bearbeitet October 9, 2020 at 17:20 von sihui

[rtrbt]

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.

[MiRo]

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

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

[KlausGünther]

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 ?

 

[rtrbt]

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 ;)

[KlausGünther]

Scheint wirklich kein OH Problem zu sein, daher habe ich das ganze mal in einem neuen Thread aufgemacht.

bearbeitet October 23, 2020 at 09:25 von KlausGünther

[sihui]

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.

[MiRo]

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

[rtrbt]

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.

[MiRo]

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.

[rtrbt]

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.

[MiRo]

Danke. Ich bleibe dran.

[sihui]

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]

 

bearbeitet November 28, 2020 at 15:37 von sihui