MiRo

Hello @rtrbtI will test it - when I'm home again. Thanks for the fast solution

Hello @rtrbt, I was wondering why the load on my RPI was so high when I had my 4 io16_v2 bricklets added to my OH2.5.12 setup. I wrote a small python script with your great Python-API binding and found that the callback configuration was set ``` BrickletIO16V2.set_input_value_callback_configuration(200, false) ``` Why do you do this. I changed it to ``` BrickletIO16V2.set_input_value_callback_configuration(200, true) ``` and now only get callbacks if something is really changing. Can you change the binding to also only generate the callback if the status of a io16(_v2) port is changing?

Moin mal wieder, "leider" läuft mein System gerade sehr stabil. Der Counter ist bei 23k - nach einem Restart wegen eines Updates (bei 56k). Also keine neuen Traces. Aber gestern habe ich durch Zufall das in meinem Log (log.txt) gefunden. 2020-12-07 08:53:07.659 [vent.ItemStateChangedEvent] - tinkerforge_Io16_mod3_ina0 changed from OFF to ON 2020-12-07 08:53:07.679 [vent.ItemStateChangedEvent] - tinkerforge_Io16_mod3_ina1 changed from OFF to ON 2020-12-07 08:53:07.687 [vent.ItemStateChangedEvent] - tinkerforge_Io16_mod3_ina2 changed from OFF to ON 2020-12-07 08:53:07.691 [vent.ItemStateChangedEvent] - tinkerforge_Io16_mod3_ina3 changed from OFF to ON Mitten aus dem "Nichts" werden kurzfrisig sehr viele - aber auch nicht alle - Ports auf ON gesetzt und ganz kurz später wieder auf OFF. Aber einige Ports bleiben ON tinkerforge_Io16_mod3_ina0 tinkerforge_Io16_mod3_ina1 tinkerforge_Io16_mod3_ina3 tinkerforge_Io16_mod3_ina5 Da alle diese Ports aber als FensterKontakte dienen, können die in echt nicht wechseln - zumal zu dieser Zeit gar keiner zu Hause war. Vielleicht gibt das ja eine Idee. Schönen Gruß Michael

Danke. Ich bleibe dran.

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.

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

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

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>

Moin, ja das mit dem Trace ist machmal viel, läßt sich ja aber wieder abschalten :-). Ja, das mit den hue-Lampen kenne ich, das ist aber eher ein Problem von OH - in der hue-App gehen die Lampen auch dann, wenn OH meint sie wären Offline. Das mit den TImeouts, habe ich gar nicht gesehen. Das werde ich mir ansehen, wenn es mal wieder vorkommt. Ich denke das die fallende Flanke fehlt. Alle Taster haben losgelassen den Status "Low" und gedrückt den Status "High". Damit ergibt sich im funktionierenden Fall dieser Trace: I'm logging something ... to 27461240 2: 2020:09:28 20:54:22.162 2: Port: a 2: Interrupt Mask: 0x1 2: Value Mask: 0x1 2: 2020:09:28 20:54:22.711 2: Port: a 2: Interrupt Mask: 0x1 2: Value Mask: 0x0 2: 2020:09:28 20:54:28.591 2: Port: a 2: Interrupt Mask: 0x1 2: Value Mask: 0x1 2: 2020:09:28 20:54:29.079 2: Port: a 2: Interrupt Mask: 0x1 2: Value Mask: 0x0 Wenn alle Taster losgelassen werden, ist der Wert 0x00. Im Fehlerfall liegt der Wert aber - in obigem Beispiel bei 0xa0 = 0b1010 0000 bzw. 0x44=0x0100 0100 für "2" gibt es nur historische Werte 2: 2020:09:27 09:21:17.590 2: Port: b 2: Interrupt Mask: 0x8 2: Value Mask: 0xa8 2: 2020:09:27 09:21:18.380 2: Port: b 2: Interrupt Mask: 0x8 2: Value Mask: 0xa0 für "3" habe ich wärend der Aufzeichnung den Schalter gedrückt und unten stehende Ausgabe kam, beim Loslassen kam aber nichts. 3: 2020:09:27 09:21:00.122 3: Port: b 3: Interrupt Mask: 0x80 3: Value Mask: 0x44 Also bei (je) 2 Schaltern wurde die steigende Flanke erkannt, die Fallende aber nicht - erst bei einem REFRESH wurde der Status wieder aktualisiert. Meines Erachtens darf es nie andere Werte als 0x00 geben, nachdem der Taster wieder losgelassen wurde. Umkonfiguriert habe ich nichts - erst mal nur aufgezeichnet was als Events kommt. Ich werde weiter tracen. Danke.

Ich habe heute Abend noch was gesehen, das fluten des Logs beginnt mit einer Fehlermeldung von der Sitemap - wo einige items fehlen: Ich habe mal 2 Versuche angehängt:log_flooding_start.zip UPDATE: Auch ohne Fehler (Start_of_logging_flooding_3.txt) kommt es zum Start des LogFlutens wenn ich (um 19:38:03) die Sitemaop aufmache: Hier auch noch mal die Sitemap(home.sitemap) ------- Und - immer mal hilfreich - ein StartupTraceStartup.7z

Hallo, heute hatte ich einige neue "Erkenntnisse". Ich habe das program example_interrupt.c so erweitert, dass alle 4 (io16/io16v2) abgefragt werden konnten. Ich hatte nämlich heute gesehen, dass einige io16 noch gehen, andere aber nicht. Im BrickViewer sah alles wieder gut aus. Aber im OH kamen Events z.B. von io16(UID-io2) nicht mehr an, wohl aber von io16(UID-io1). Hier mal die Ausgaben von example_interrupt mit Kommentaren: Es fehlen bei einem Port die fallenden Flanken (Taster gedrückt Low->High, Taster losgelassen High->Low). Wenn das System in dem Zustand ist, kommt nach dem erstmaligen "Verpassen" das HIGH->LOW interrupts. Kein Interrupt mehr für den PIN (oder ganzen PORT?). 1: 2020:09:27 09:20:30.703 1: Port: a 1: Interrupt Mask: 0x4 1: Value Mask: 0x4 1: 2020:09:27 09:20:31.201 1: Port: a 1: Interrupt Mask: 0x4 1: Value Mask: 0x0 Michael: -> OK 3: 2020:09:27 09:21:00.122 3: Port: b 3: Interrupt Mask: 0x80 3: Value Mask: 0x44 Michael: -> hier fehlt die fallende Flanke 2: 2020:09:27 09:21:15.733 2: Port: b 2: Interrupt Mask: 0x8 2: Value Mask: 0xa8 2: 2020:09:27 09:21:16.617 2: Port: b 2: Interrupt Mask: 0x8 2: Value Mask: 0xa0 Michael: -> OK 2: 2020:09:27 09:21:17.590 2: Port: b 2: Interrupt Mask: 0x8 2: Value Mask: 0xa8 2: 2020:09:27 09:21:18.380 2: Port: b 2: Interrupt Mask: 0x8 2: Value Mask: 0xa0 Michael: -> OK 3: 2020:09:27 09:22:00.271 3: Port: b 3: Interrupt Mask: 0x80 3: Value Mask: 0xc4 3: 2020:09:27 09:23:00.105 3: Port: b 3: Interrupt Mask: 0x80 3: Value Mask: 0x44 Michael: -> OK 3: 2020:09:27 09:24:00.257 3: Port: b 3: Interrupt Mask: 0x80 3: Value Mask: 0xc4 3: 2020:09:27 09:25:00.089 3: Port: b 3: Interrupt Mask: 0x80 3: Value Mask: 0x44 Michael: -> OK 3: 2020:09:27 09:26:00.100 3: Port: b 3: Interrupt Mask: 0x80 3: Value Mask: 0xc4 3: 2020:09:27 09:27:00.077 3: Port: b 3: Interrupt Mask: 0x80 3: Value Mask: 0x44 Michael: -> OK Hier noch mal der ScreenShot der io2 Konfig Hier noch mal die Traces von der Zeit vor 27.09 - 9:34 - openhab.log und event.log (io16_error_error_log.7z) Ein REFRESH funktioniert übrigens (io16_error_REFRESH.7z): 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 ON openhab> smarthome:send tinkerforge_Io16_mod2_ina0 REFRESH Command has been sent successfully. openhab> smarthome:status tinkerforge_Io16_mod2_ina0 OFF und die ThreadListe thread_List_Error.txt

Kleines ZwischenUpdate: Ich bekomme seit einiger Zeit diese Traces von "TinkerforgeChannelTypeProvider", aber die beziehen sich jetzt alle auf Homematic: TinkerforgeChannelTypeProvider.txt. Das kommt jede Sekunde einmal. Alle Things sind aber Online und die Items kann ich auch abfragen: smarthome:things list | grep GATE homematic:GATEWAY-EXTRAS-3014F711A061A7D70992B1AC:3014F711A061A7D70992B1AC:GWE00000000 (Type=Thing, Status=ONLINE, Label=GATEWAY-EXTRAS, Bridge=homematic:bridge:3014F711A061A7D70992B1AC) smarthome:items list | grep NeueFirm Homematic_UpdateRequired2 (Type=SwitchItem, State=OFF, Label=HomeMatic Variable NeueFirmware, Category=homematic, Groups=[gHomeMatic]) smarthome:items list | grep Reload Homematic_ReloadAllFromGateway2 (Type=SwitchItem, State=OFF, Label=Reload all from Gateway, Category=homematic, Groups=[gHomeMatic]) Das Programm läuft fleißig weiter, und noch geht auch alles :-). Geprüft wird der pin tinkerforge_Io16_mod3_inb7 2020:09:25 17:06:00.078 Port: b Interrupt Mask: 0x80 Value Mask: 0xc4 2020:09:25 17:07:00.159 Port: b Interrupt Mask: 0x80 Value Mask: 0x44 2020:09:25 17:08:00.099 Port: b Interrupt Mask: 0x80 Value Mask: 0xc4 2020:09:25 17:09:00.043 Port: b Interrupt Mask: 0x80 Value Mask: 0x44 2020:09:25 17:10:00.155 Port: b Interrupt Mask: 0x80 Value Mask: 0xc4 2020:09:25 17:11:00.136 Port: b Interrupt Mask: 0x80 Value Mask: 0x44 2020:09:25 17:12:00.096 Port: b Interrupt Mask: 0x80 Value Mask: 0xc4

Hallo ich habe 2 "Stapel" den einen mit 3 Master Brick 2.1 mit je 4 Industrial Digital Out 4 Bricklet bricklets mit einem Step-Down Power Supply den anderen mit einem Master Brick 2.1 und 4 IO-16 Bricklet beide sind per USB an den Raspi4 angebunden siehe damit nein - die IO-16 Bricklets sind an einem anderen Stapel als die Out4 Bricklets ich habe den level TRACE aktiviert, (log:set TRACE org.openhab.binding.tinkerforge) kommt mehr raus als vorher :-) 21:03:28.857 [DEBUG] [rforge.internal.handler.DeviceHandler] - Checking reachability of io3 21:03:28.857 [DEBUG] [rforge.internal.handler.DeviceHandler] - Checking reachability of io2 21:03:28.856 [DEBUG] [rforge.internal.handler.DeviceHandler] - Checking reachability of io1 21:03:28.856 [DEBUG] [rforge.internal.handler.DeviceHandler] - Checking reachability of do9 21:03:28.863 [DEBUG] [rforge.internal.handler.DeviceHandler] - io2 is not in bootloader mode. 21:03:28.861 [DEBUG] [rforge.internal.handler.DeviceHandler] - io3 is not in bootloader mode. 21:03:28.869 [DEBUG] [rforge.internal.handler.DeviceHandler] - Done checking reachability of io2 21:03:28.868 [DEBUG] [rforge.internal.handler.DeviceHandler] - do9 is not in bootloader mode. 21:03:28.872 [DEBUG] [rforge.internal.handler.DeviceHandler] - io2 was already online. Will not reinitialize. 21:03:28.870 [DEBUG] [rforge.internal.handler.DeviceHandler] - Done checking reachability of io3 21:03:28.878 [DEBUG] [rforge.internal.handler.DeviceHandler] - Checking reachability of do1 21:03:28.870 [DEBUG] [rforge.internal.handler.DeviceHandler] - io1 is not in bootloader mode. 21:03:28.879 [DEBUG] [rforge.internal.handler.DeviceHandler] - io3 was already online. Will not reinitialize. 21:03:28.875 [DEBUG] [rforge.internal.handler.DeviceHandler] - Done checking reachability of do9 interessant ist das hier - was hat denn ein Homematic trace hier zu suchen? 21:05:00.050 [DEBUG] [ternal.TinkerforgeChannelTypeProvider] - Could not find device info for channelTypeUID homematic:GATEWAY-EXTRAS-3014F711A061A7D70992B1AC_1_CommWdOpenHab: null. ich hänge den Trace an - wenn der Fehler wieder auftritt. Das mit dem REFRESH probiere ich aus hier schon mal die ThreadList - wenn es geht thread-list-OK.txt Das Program mache ich noch schnell hier noch mal die Bundle-Listbundle-list.txt Danke schon mal für die schnellen Antworten :-).

Ich habe jetzt mal einen HITL test eingebaut. Ich toggle einen out4 Pin den ich mit einem io16 Pin verbunden habe. Jetzt sehe ich wie lange es genau geht, und wann genau der io16 nicht mehr reagiert. Hier kurz die beiden Regeln: // toggle out4 pin (tinkerforge_out4_modA_3) to check if io16 is still able to read via port tinkerforge_Io16_mod3_inb7 rule "IO16 bricklet check - set" when Time cron "0 0/1 * 1/1 * ? *" // every minute then logInfo("cron.rules", "check io16 bricklet - set :" + iocheck) sendCommand(tinkerforge_out4_modA_3, transform("MAP", "toggle.map", tinkerforge_out4_modA_3.getState().toString)) iocheck = iocheck + 1 if (iocheck > 3) { logError("cron.rules", "Io check failed") sendCommand(Do_Restart, ON) } end rule "IO16 bricklet check - check" when Item tinkerforge_Io16_mod3_inb7 changed then logInfo("cron.rules", "check io16 bricklet - check :" + iocheck) iocheck = 0 end bisher alles super - nach dem Neustart: 2020-09-23 23:19:00.012 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - set :0 2020-09-23 23:19:00.123 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - check :1 2020-09-23 23:20:01.271 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - set :0 2020-09-23 23:20:03.735 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - check :1 2020-09-23 23:21:00.008 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - set :0 2020-09-23 23:21:00.106 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - check :1 2020-09-23 23:22:00.027 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - set :0 2020-09-23 23:22:00.110 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - check :1 2020-09-23 23:23:00.004 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - set :0 2020-09-23 23:23:00.056 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - check :1 2020-09-23 23:24:00.014 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - set :0 2020-09-23 23:24:00.106 [INFO ] [se.smarthome.model.script.cron.rules] - check io16 bricklet - check :1