Betaversion der openHAB-Bindings

[rtrbt]

2 hours ago, StefanOHAN said:

Das System läuft jetzt seit über einen Tag ohne Ausfallerscheinungen des Astro/NTP/Exces, alle FT Komponenten funktionieren, die Rules laufen, und das Masterbrick(WIFI) wurde mehrfach ohne Probleme reconneted.

Das klingt doch gut. Dann baue ich das in die nächste "offizielle" Beta ein.

Falls du in nächster Zeit nochmal mitbekommst, dass der Master Brick gerade wieder reconnected, wäre ich nochmal an der shell:threads Ausgabe interessiert. Das ist nicht kritisch aber eventuell sehe ich da noch ein paar interessante Effekte.

[StefanOHAN]

Guten Morgen Erik,

Update: Jetzt ist das ganze System problemlos über das komplette Wochenende gelaufen.

Ich hatte pro Tag mehrfach die Reconnect des MasterBrick/WIFI.

Frage: den shell:threads, soll der unmmittelbar nach dem connection-Lost oder dem reconnect sein ? Dann würde ich mal einen reconnect provozieren um den die Info zur passenden Situation zu bekommmen.

viele Grüsse

 

Stefan

[rtrbt]

Moin,

Interessant wäre direkt nach dem Verbindungsverlust.

Wie üblich danke für die Tests!

Erik

[StefanOHAN]

Guten Morgen Erik

ich habe gestern 4 shell:thread erzeugt

Nr1-20200831-shell_threads-vor-ausfall >> hier war alles noch funktionsfähig

Nr2-20200831-shell_threads-connection_lost-1 >> Status kurz nach Ausfall WIFI, erste Meldungen im Log dass Things nicht erreichbar sind

Nr3-20200831-shell_threads-connection_lost-2 >> Status ca 2-3 min nach Ausfall WIFI, jetzt sind auch über "paperui/index.html#/configuration/things" die Things als offline markiert

Nr4-20200831-shell_threads-reconnect >> Status nach erfolgreichen reconnect, alle Things in "paperui/index.html#/configuration/things" wieder online, die Rules der betroffen Bricklets funktionieren wieder ,keine weiteren Fehlermeldungen im Log

 

Das System läuft weiterhin ohne Ausfall des Astro/Ntp/Exec Binding

 

Viele Grüsse

Stefan

 

 

Nr1-20200831-shell_threads-vor-ausfall.txt Nr2-20200831-shell_threads-connection_lost-1.txt Nr3-20200831-shell_threads-connection_lost-2.txt Nr4-20200831-shell_threads-reconnect.txt

[rtrbt]

Moin,

Das sieht soweit gut aus. In Nr2 sind die ThingHandler mit den Erreichbarkeits-Checks beschäftigt. Da war ich erst verwirrt, weil zwei Threads den Heartbeat ausführen, aber du hast ja mehrere Verbindungen zu Brick Daemons, deshalb ergibt das Sinn.

Danke nochmal!
Erik

[StefanOHAN]

Hallo Erik,

was meist Du mit "du hast ja mehrere Verbindungen zu Brick Daemons" ?

 

aktuell habe ich folgenden Aufbau

1x BrickDämon USB/HAT, über diesen Dämon sind die  Masterbrick die über USB an den Pi angeschlossen sind und das HAT-Brick das auf dem selben Pi aufgesteckt ist , erreichbar.

1x BrickDämon der per WIFI-Extention für die Anbindung einen Masterbrick zuständig ist.

viele Grüsse

Stefan

bearbeitet September 1, 2020 at 08:14 von StefanOHAN

[rtrbt]

18 minutes ago, StefanOHAN said:

1x BrickDämon USB/HAT

und

18 minutes ago, StefanOHAN said:

1x BrickDämon der per WIFI-Extention

Genau die beiden meine ich.

Ich war wie gesagt erst verwirrt, weil in der zweiten Datei zwei der ThingHandler-Threads gerade dabei sind einen heartbeat auszuführen, hatte dann aber gesehen, dass es auch zwei Disconnect-Prober-Threads gibt (die werden jeweils von der IP-Connection zum Brick Daemon erzeugt). Daraus konnte ich dann schließen, dass du mindestens zwei Brick Daemons in openHAB hinzugefügt hast, weil zwei IP-Connections laufen und es deshalb nicht schlimm ist, dass auch zwei heartbeats gleichzeitig laufen.

Wenn aus einem Brick Daemon heraus zwei ThingHandler-Threads den heartbeat ausgeführt hätten, dann wäre mein Fix für das Problem das du hattest nicht gut genug gewesen, weil ich ja genau das verhindern muss (sonst starten irgendwann alle 5 ThingHandler-Threads den heartbeat und kein Thread ist frei um ihn tatsächlich abzuarbeiten)

[StefanOHAN]

Ah ok, verstehe. 

Mein Prodsystem hat aktuell nur USB-Masterbrick und nach dem Umbau auf Openhab2 USB-Masterbrick und Hatbrick.

Nur das TestSystem Openhab2 hat diese beiden Anbindungs-Versionen.

Ich bin gerade am überlegen ob ich das WIFI komplett aus der TestKonfig raus schmeiße, das HatBrick und die USB-MasterBrick's über einen PI2 anbinden. Das Openhab-System würde dann auf einen Pi3/4 laufen an dem kein MasterBrick/Hat-Brick direkt angeschlossen ist. Ich würde die Dämonen dann Remote mit dem PI2 verbinden.

(ob das mit dem PI2 als Remote-Server sauber funktioniert muss ich noch testen)

Ich könnte mir aber auch vorstellen dass ich HAT&USB MasterBrick über den PI2 anbinde und den WIFI in der Konfig lassen. Dann hätte ich zwei Dämons die über das Netz-Angebunden sind.

Was meist Du was für das Test-System besser ist (es sollen ja passenden Test-Rückmeldungen für Dich erzeugt werden) ?

 

Grüsse

Stefan

 

 

[rtrbt]

21 hours ago, StefanOHAN said:

Was meist Du was für das Test-System besser ist (es sollen ja passenden Test-Rückmeldungen für Dich erzeugt werden) ?

Bau im Zweifelsfall das was näher an deinem Produktivsystem sein wird. Ich habe hier auch noch einige Testaufbauten zu testen.

[MiRo]

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

 

bearbeitet September 13, 2020 at 06:57 von MiRo
test mit brickd restart heute gemacht

[StefanOHAN]

Hallo Erik,

ich habe jetzt meine Konfiguration umgestellt und nochmal erweitert und bin bei meinem neuesten Bricklet (realtime-Clock) auf einen eigenartigen Effekt gestoßen.

 

Config neu (die Bricklets sind nicht umgesteckt worden)

Raspberry Pi 2b

→ hat das HAT-Brick aufgesteckt und die MasterBrick die per USB angeschlossen sind

→ es ist dort nur ein minimal Raspian installiert sowie der brickd Dämon, kein openhab

Raspberry Pi3b

→ hat ein Hat-Zero-Brick (neu) aufgesteckt

→ an dem Hat-Zero ist nur die Realtime-Clock 2.0 (neu) angeschlossen

→ es ist der brickd Dämon und Openhab installiert

→ openhab/Things hat  1x Brickdämon lokal (des Pi3 für HAT-Zero), 1xBrickdämon remote (Pi2 mit HAT-Brick), 1xBrickdämon für WIFI-Extention.

WIFI-Extention mit 1xMasterBrick

→ die Konfiguration hat sich hier nicht verändert (das WIFI wird später kein Bestandteil des Prod-System sein)

 

Soweit läuft das System, jedoch hab ich zur RealtimeClock eine Frage.

Ich hab Zeit & Datum über den BrickViewer eingestellt. Wenn ich jedoch über Openhab das ITEM für Zeit/Datum anschaue, sehe ich dass dort +2 Stunden zu der Zeit die ich eingestellt habe angezeigt werden.

Auf dem Pi-OS (openhabian) ist der NTP-Zeitservice deaktiviert. Der Pi hat unter System-timezone > Europa/Berlin eingestellt. (hat auch den gleichen Effekt wenn der NTP-Zeitservice dort aktiv ist)

In Openhab ist der NTP-Zeitservice aktiv, weiter ist dort Timezone=Europa/Berlin (GTM+1) konfiguriert.

Die Zeiten des OpenHab NTP sowie die per Exec abgefragte Zeit des Pi, weisen ein Delta von 2 Stunden zu dem der Realtime-Clock auf.

Woher kann diese Delta von 2 Stunden kommen ? Was und wo müsste ich in der Config noch ändern ?

viele Grüsse Stefan

 

P.S mit Deinem Spezial-Binding ist bis jetzt der Fehler mit  dem hängenden Astro & NTP Binding nicht mehr aufgetreten.

[StefanOHAN]

Hallo MiRo,

als ich Deine Nachricht sah, habe ich heute mal schnell auf meinen Testsystem geprüft ob meine IO16 & IO16V2 Status-Änderungen von Openhab dargestellt werden. Meine HW / FW der Bricklets & Masterbrick ist Identisch, nur nutze ich als OS-Openhabian ebenfalls mit OH 2.5.8. 

Die Status Änderungen werde bei mir beim betätigen der Taster angezeigt und die entsprechenden Rules reagieren.

Ich sehe momentan bei mir einen Unterschied wenn ich openhab> bundle:list -s | grep ink ausführe erhalte ich 

Zitat

58 x Active x  80 x 2.1.26                  x com.tinkerforge

Du hast bei Dir eine Version 2.1.28.

Ich bin mir aber nicht sicher ob das mit dem Binding zu tun hat, das mir Erik zum testen gab als ich Probleme in meiner Konfig hatte.

Hast Du schon mal versucht den cache über die Konsole zu löschen, dann dauert zwar das nächste laden etwas länger aber das hat bei mir oft wunder bewirkt.

viele Grüsse

Stefan

[rtrbt]

Moin,

@MiRo Das Problem ist mir neu. Versuche erstmal die Bindings 2.1.26 zu verwenden, ich versuche in den nächsten Tagen mal das hier nachzustellen.

@StefanOHAN Dein RTC-Verhalten kommt daher, dass ich die in openHAB immer auf UTC stelle und die Zeitzone dann in openHAB darauf verrechne. Das ist typischerweise das Standardvorgehen bei sowas. Wenn du die Uhr aber händisch im Brick Viewer schon mit Zeitzone stellst, rechnet openHAB dann nochmal die Zeitzone drauf und du hast dieses Offset. (Funfact: Das selbe Problem bekommt man wenn man Windows und Linux per dual-boot auf einem PC hat, Windows stellt die RTC auf localtime, Linux auf UTC)

Gruß,
Erik

[MiRo]

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

[MiRo]

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.

[MiRo]

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

 

[rtrbt]

Moin,

Ich habe dazu folgenden Satz Fragen:

• Was ist der komplette Aufbau? Also wie viele Stapel, sind die per USB, Ethernet oder Wifi angeschlossen, usw. Mach am besten mal einen Brick Viewer Screenshot
• Die anderen Bricklets, die noch funktionieren sind am selben Stapel?
• Siehst du etwas interessantes, wenn du das Logging hochdrehst? (mit log:set TRACE org.openhab.tinkerforge, dann bekommst du potentiell viel Ausgabe, aber lass das mal so laufen bis das Problem wieder auftritt) Durch deine Rule solltest du den Zeitpunkt, wann es kaputt ist ja finden, da würden mich die Log-Zeilen ab ~ 3 Minuten davor interessieren.

Probiere außerdem mal folgende Dinge, wenn das System gerade in dem kaputten Zustand ist:

• Die Ausgabe von shell:threads (in der openHAB-Konsole) könnte interessant sein.
• Was passiert, wenn du eine Aktualisierung mit

  smarthome:send Item_Name REFRESH

  erzwingst? Siehst du dann den neuen Zustand?

• Wenn du ein C-Programm nimmst, das sich auf das Input-Callback des IO16v2 registriert, aber das Aktivieren des Callbacks weglässt, kommen dann Callbacks an? (Du kannst z.b. das Interrupt-Beispiel nehmen, aber musst die Zeile mit

  io16_v2_set_input_value_callback_configuration

  weglassen): Ich gehe im Moment davon aus, dass die Callback-Aktivierung aus irgendeinem Grund verloren gegangen ist, wenn das Testprogramm jetzt die Callbacks wieder aktiviert, sehen wir nicht mehr ob das das Problem war.

[MiRo]

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

[MiRo]

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

 

bearbeitet September 25, 2020 at 15:48 von MiRo
typo

[MiRo]

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

 

[MiRo]

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

bearbeitet September 27, 2020 at 17:55 von MiRo
Auch ohne Fehler in der Sitemap - wird das log geflutet.

[rtrbt]

Moin,

On 9/25/2020 at 5:13 PM, MiRo said:

Ich bekomme seit einiger Zeit diese Traces von "TinkerforgeChannelTypeProvider", aber die beziehen sich jetzt alle auf Homematic: TinkerforgeChannelTypeProvider.txt. Das kommt jede Sekunde einmal.

Das ist normal und erwartet, openHAB fragt alle existierenden ChannelTypeProvider nach allen ChannelTypes bis einer sagt "den kenne ich". Dabei wird nicht darauf geachtet, welches Binding für welche ChannelTypen ist, deshalb fragt openHAB meinen Provider ob er den ChannelType kennt, was er nicht tut.

Daher kommt auch die Log-Flut: Im events.log z.B. ab 2020-09-27 09:00:00 siehst du, dass die Hue-Lampen andauernd offline und online gehen. Anscheinend werden die Channel-Typen jedes Mal wenn eine Lampe wiederkommt neu angelegt und landen dann aber auch bei meinem ChannelTypeProvider, der dann meckert weil er die Typen nicht kennt. Ich muss mal einbauen, dass er auch die Debug-Meldung nur ausgibt wenn der ChannelType mit "tinkerforge:" anfängt, sorry dass ich dir das Log so zumülle.

On 9/27/2020 at 9:48 AM, MiRo said:

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

Das ist denke ich der interessante Teil. In deinem Brick Viewer Screenshot sehe ich Timeouts, werden das mit der Zeit mehr wenn du in dem Zustand bist?

Fehlt in der example_interrupt-Ausgabe nicht eher die steigende Flanke? Ich sehe erst 0x44 und später 0xc4 0x44, da beim ersten Mal fehlt die Ausgabe die das höchste Bit gesetzt hat. Hat sich später wenn du die 0xc4 wieder bekomsmt das Problem von alleine gelöst oder hast du da das Callback neu konfiguriert o.Ä.?

Im Log selbst habe ich im Fehlerfall nichts relevantes gefunden, den Spam vom ChannelTypeProvider konnte man zum Glück gut per Regex rauswerfen.

Die Threadlisten usw. sehen soweit okay aus.

[MiRo]

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.

[rtrbt]

Bezüglich der Flankenverwirrung: Ich kenne dein Setup nicht genau, hier mein Verständnis davon, bitte korrigiere mal was falsch ist:

• Die IO-16-Bricklets haben alle relevanten Pins als Input mit Pull-Up konfiguriert
• Du hast da Taster/Schalter angeschlossen, die ganze Zeit den IO-Pin mit Ground verbinden und wenn du schaltest, trennen sie die Verbindung, weshalb der Pull-Up auf HIGH zieht.
• Dann ergibt z.B.

  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

  Sinn weil du erst das Ereignis "Pin 1 hat sich geändert, ist jetzt HIGH" hast und dann das Ereignis "Pin 1 hat sich geändert, ist jetzt LOW"
• Was mich verwirrt ist dann

  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

  denn die Interrupt Mask sagt ja "Pin 7 hat sich geändert" und die Value Mask sagt "Pin 6 und 2 sind HIGH, der Rest LOW". Das würde danach wie ich deinen Aufbau verstehe aber ja das Ereignis Pin 7 HIGH -> LOW sein, also wenn du den Schalter losläst, nicht wenn du ihn drückst.

Zusatzfragen: Die erste Ziffer der Ausgabe ist die Nummer des IO-16-Bricklets? Du hast ja zwei alte und zwei neue, erzeugst du bei den neuen Interrupt und Value Mask selbst? Die Callbacks funktionieren da ja anders.

[KlausGünther]

Mal in die Zukunft geschaut:

Ende Dezember soll es ja openhab 3 geben, was wird denn dann aus dem TF Binding ?