Jump to content

MiRo

Members
  • Gesamte Inhalte

    26
  • Benutzer seit

  • Letzter Besuch

Alle erstellten Inhalte von MiRo

  1. Hello @rtrbtI will test it - when I'm home again. Thanks for the fast solution
  2. 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?
  3. 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
  4. 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.
  5. 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
  6. 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
  7. @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.
  8. 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>
  9. 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.
  10. 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
  11. 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
  12. 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
  13. 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 :-).
  14. 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
  15. Hallo beide, gestern und heute ist es wieder passiert. Nach rund 3 Tagen (und dann heute morgen gleich wieder) - diesmal mit 263 │ Active │ 80 │ 2.1.26 │ Tinkerforge API Bindings ging wieder keines meiner io16/io16v2 bricklets mehr. Ich werde jetzt mal auf OH 2.5.9 updaten - und das hue.binding deaktivieren. Ich habe keine Ahnung, ob das hilft, aber mein Bacuchgefühl sagt mir nach der Hue Installation kam das häufiger vor. Ich habe noch mal meine rpi Auslastung geprüft, kam aber im Durchschnitt nicht über 5% für java. Noch eine Idee was ich prüfen kann, oder logs die ich aktivieren kann? Danke.
  16. @StefanOHANund @rtrbt Danke für die Rückmeldung. Noch eins. Meistens geht es auch richtig gut. Aber so nach 2-10Tagen dann leider nicht mehr. @rtrbt: Ich werde es mal mit dem "alten" 2.1.26 binding versuchen. Danke. Rückmeldung kann leider etwas dauern :-).
  17. Hallo Tinkerforge, ich habe gelegentlich ein Problem mit dem Binding, das meine brickletio16v2/brickletio16 keine Änderung an den Eingängen mehr an OH2.5.8 melden. Meine brickletindustrialdigitalout4 wiederum haben keine Probleme, updates an die Bricklets weiter zugeben. Alle brickletio16/v2 sind an einem MasterBricklet und sind als Input/Pull-up konmfiguriert und hängen an LichtSchaltern. Alle brickletindustrialdigitalio4 sind an mehreren (3) anderen MasterBricklets. Im Brick Viewer werden die Änderungen der io16 richtig angezeigt. Mit dem C/C++ Programm "example_input.c" sehe ich die Änderungen auch - nur im OH kommen diese nicht an. Das habe ich versucht: Binding Neustart - hilft nicht bundle:restart org.openhab.binding.tinkerforge bundle:restart com.tinkerforge brickd neustart - hilft nicht sudo systemctl restart brickd.service Neustart OH - ging wieder sudo systemctl restart openhab2.service Kennen Sie das Problem schon? Was soll ich sonst - beim nächsten Mal noch an Infos sammeln. Danke. Setup: HW: Raspberry 4 SW: rasbian buster + OH 2.5.8 openhab> bundle:list -s | grep ink 203 │ Active │ 80 │ 2.5.6.202005191348 │ org.openhab.binding.tinkerforge 204 │ Active │ 80 │ 2.1.28 │ com.tinkerforge Firmware: UID: tinkerforge:brickmaster:6KT6Pg Type: tinkerforge:brickmaster Label: MasterBrick out 0 - 6KT6Pg Status: ONLINE Bridge: tinkerforge:brickd:17b059d0 Properties: tinkerforge_minimum_firmware_version : 2.4.2 serialNumber : 6KT6Pg modelId : 13.0 vendor : Tinkerforge GmbH hardwareVersion : 2.1.0 firmwareVersion : 2.4.10 UID: tinkerforge:brickletio16v2:io4 Type: tinkerforge:brickletio16v2 Label: Tinkerforge IO16 4 - io4 Status: ONLINE Bridge: tinkerforge:brickd:17b059d0 Properties: tinkerforge_minimum_firmware_version : 2.0.0 serialNumber : io4 modelId : 2114.0 vendor : Tinkerforge GmbH hardwareVersion : 1.0.0 firmwareVersion : 2.0.2 UID: tinkerforge:brickletio16:io1 Type: tinkerforge:brickletio16 Label: Tinkerforge IO16 1 - io1 Status: ONLINE Bridge: tinkerforge:brickd:17b059d0 Properties: tinkerforge_minimum_firmware_version : 2.0.3 serialNumber : io1 modelId : 28.0 vendor : Tinkerforge GmbH hardwareVersion : 1.1.0 firmwareVersion : 2.0.6
  18. Hallo Erik, danke. Dann bleibe ich bei der 2.1.26. Ich habe ja auch gar kein Auto ... ich meine Analog In Bricklets. Schönen Tag noch.
  19. Hallo Erik, ich habe heute den Umstieg von Tinkerforge Binding V1 auf Dein neues Binding V2 "gewagt". Es hat alles sehr gut geklappt und alle meine Bricklets funktionieren so weit sehr gut. Danke für dieses schöne Binding. Ich habe gesehen, dass es im Maven Repository eine neue Version 2.1.27 gibt. In Deinem Post ist noch die Version 2.1.26 verlinkt. Ich habe aber bis jetzt kein ChangeLog/ReleaseNote gesehen für Deine Versionen. Noch habe ich die 2.1.26, was ist denn neu in 2.1.27? Danke Michael
  20. Hallo Theo, kein Problem - ich kann auch Deutsch . Danke für die Antwort. Ich schau mir Deinen Thread einfach mal an, und probiere Dein neues Binding aus.
  21. Hi, I just got a new IO-16 Bricklet 2.0 (https://www.tinkerforge.com/de/doc/Hardware/Bricklets/IO16_V2.html) but this is not detected in my OpenHab (running on Raspberry) my old IO-16 Bricklet (https://www.tinkerforge.com/de/doc/Hardware/Bricklets/IO16.html) work great. I had a short look into the sources and could see that the new bricklet is not yet integrated. Are these your sources or is someone else supporting the tinkerforge binding (https://www.openhab.org/addons/bindings/tinkerforge1/) for you? Thanks.
  22. Hallo Bastian, heute war es wieder so weit. Ich bekomme keine Änderung meiner Eingänge mehr im OpenHab (über Raspberry 3, Openhabian 2.3 und tinkerforge binding) als Events. Vor dem Reset: der MasterBrick ist sichtbar (Setup.JPG) die Status LED blinkt (geht all 20-30 sec für 0.5 sec aus) lässt sich aber über den BrickViewer schalten [*]die 16-IO Bricklets sind auch sichtbar [*]ich sehe mit meinem TestScript (von oben) auch eine Änderung der Pins [*] und im BrickViewer auch Nach dem Reset (über Brickview) sind io1 und io3 "verschwunden" (Setup_Danach.JPG) auch in Eurem python script (example_enumerate.py) tauchen io1 und io3 nicht mehr auf Die Status LED kann ich weiterhin schalten io2 und io4 gehen jetzt in OpenHab (leider habe ich nicht geprüft ob das vor dem Reset auch noch ging) Ein Reset über den ResetSchalter bring auch keine anderen Ergebnisse Nach Power Off/On einmal kurz USB Verbindung zum Raspberry getrennt (Setup_PowerOff.JPG) und alle wieder da :-) Ich hoffe das hilft weiter. example_enumerate.py
  23. Hallo Bastian, ja versuche ich - wenn es wieder vorkommt.
  24. Hallo Bastian, Danke für die Antwort, aber ich kann nicht mehr Prüfen ob sich die Eingänge noch ändern. Ich sehe die nicht mehr am Raspberry (OpenHab) und auch nicht mehr im BrickViewer. Ich versuche es das nächste mal mit einem Script auf dem Raspberry. Und frage ein paar Parameter ab. Was soll ich denn prüfen? - VerbindungsStatus - PortStatus - ?? tinkerforge_16io_input_example.py
×
×
  • Neu erstellen...