Jump to content

MiRo

Members
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    26

  • Benutzer seit

  • Letzter Besuch

 Inhaltstyp 

Posts erstellt von MiRo

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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?

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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 (io16_Error_Check.thumb.JPG.9af16f7c61214623bb0f1db5b197cb6b.JPGseht 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 io16_Error_Check_Detail.thumb.JPG.4864767812b25c865a578a573cf7492d.JPG

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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>

     

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben · bearbeitet von MiRo
    Auch ohne Fehler in der Sitemap - wird das log geflutet.

    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

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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 KonfigBrickViewer_io2.JPG.e0aebef1e42298885c586260395cdfac.JPG

    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

     

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben · bearbeitet von MiRo
    typo

    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

     

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Hallo

    • ich habe 2 "Stapel"
    • 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 :-).

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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

     

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben · bearbeitet von MiRo
    test mit brickd restart heute gemacht

    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

     

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    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

    OpenHab binding erweitern um IO16_v2 Bricklet

    in Software, Programmierung und externe Tools

    Geschrieben

    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.

    IO16 Bricklets "verschwinden"

    in Hardware

    Geschrieben

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

    Setup.JPG.8374a3b09dbe7593059d0e142d2baef9.JPG

    io16-pressed.JPG.d4900ac7e39c338b0c22ae4c93b5ac2b.JPG

    io16.JPG.fd920722b688dfca21fc24e3c884aac5.JPG

    Setup_Danach.JPG.e9f0ea1348c62d9384a4023132baf62e.JPG

    example_enumerate.py

    Setup_PowerOff.JPG.d470f341a3f7b4084c3aeaebe2c4ae7f.JPG

×
×
  • Neu erstellen...