Jump to content

MiRo

Members
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

0 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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
  3. 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
  4. @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.
  5. 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.
  6. 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: 2
  7. 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
  8. 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
  9. 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=SwitchIte
  10. 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]
  11. 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"
  12. 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 k
  13. @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 :-).
  14. 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_
×
×
  • Create New...