Fensterkontakte - Meldung pro Stunde?

[Talkabout]

Hallo zusammen,

irgendwo habe ich mal gelesen, dass die MAX Fensterkontakte bei korrektem Pairing sich jede Stunde bei ihrer Basis melden um den Status zu übermitteln. Dies passiert bei mir nicht, obwohl ich der Meinung bin, dass die Kontakte korrekt gepaired sind. Ist diese Tatsache, dass ich die Meldungen nicht erhalte, ein Indiz dafür, dass meine Fensterkontakte nicht korrekt mit FHEM "verheiratet" sind?

Danke!

Gruss

[Rince]

Mach doch mal ein list von dem Device.

Code Auswählen Erweitern

list <devicename>

[Talkabout]

Mach doch mal ein list von dem Device.

Code Auswählen Erweitern

list <devicename>

Bitte sehr:

Code Auswählen Erweitern

Internals:
   CULMAX0_MSGCNT 13
   CULMAX0_TIME 2015-07-23 06:56:14
   DEF        ShutterContact 0a7ffd
   IODev      CULMAX0
   LASTInputDev CULMAX0
   MSGCNT     13
   NAME       WZFensterkontakt03
   NR         351
   RSSI       -46
   STATE      opened
   TYPE       MAX
   addr       0a7ffd
   rferror    0
   type       ShutterContact
   Readings:
     2015-07-23 06:56:14   RSSI            -46
     2015-07-23 06:56:14   battery         ok
     2015-03-02 16:42:46   firmware        1.4
     2015-03-02 16:42:46   groupid         0
     2015-03-02 16:42:46   msgcnt          8
     2015-07-23 06:56:14   onoff           1
     2015-07-23 06:56:14   state           opened
     2015-03-02 16:42:46   testresult      15
   Internals:
     interfaces switch_active;battery
Attributes:
   IODev      CULMAX0
   alias      Rechtes Fenster
   devStateIcon {WindowDevStateIcon("WZFensterkontakt03");}
   event-on-change-reading .*
   fp_Erdgeschoss 143,201,0,
   group      Fenster Wohnzimmer
   room       Wohnzimmer
   roomNameForSentence im Wohnzimmer
sieht für mich eigentlich ok aus.

Gruss

[Rince]

Tut es auch.

event-on-change-reading .*

Ich schätze, das ist die Ursache...

[Talkabout]

Tut es auch.

Ich schätze, das ist die Ursache...

Würde ich verstehen, wenn sich die ausbleibende Meldung lediglich auf Events beziehen würde. Aber es müsste ja zumindest in den Readings der Zeitstempel aktualisiert werden, wenn sich der Fensterkontakt regelmässig meldet, korrekt? Die letzte Aktualisierung fand aber gestern statt...

Gruss

[Rince]

Lösch doch mal das attr.
Dann weißt du es gleich. Das List sieht völlig ok aus.

[Talkabout]

Hallo zusammen,

jetzt habe ich einen weiteren Anhaltspunkt. Wenn ich ein Fenster öffne, bekomme ich nach ca. 1 Stunde eine solche Meldung im Log:

Code Auswählen Erweitern

2015-07-24_22:04:09 SCC868SlowRf UNKNOWNCODE 0B9106300A8AEC123456001024
2015.07.24 22:04:09 2: SCC868SlowRf: unknown message 0B9106300A8AEC123456001024

Über den Namen des Empfängers bitte keine Gedanken machen. Ich verwende Stackable Transceiver und der SlowRf liegt ganz unten.

Für mich bedeutet das, nachdem ich das Öffnen/Schliessen des Fenster in FHEM sehen kann, dass der Fensterkontakt den Status zwar stündlich meldet, FHEM diese Meldung allerdings nicht interpretieren kann. Hier wäre es toll wenn sich der Modul-Verantwortliche mal anschauen könnte, was an der Nachricht nicht passt. Vielleicht hat er einen Tipp, was bei mir falsch läuft.

Danke!

Gruss

[Rince]

Du meinst die Änderungen vom damals http://forum.fhem.de/index.php/topic,31838.0.html haben nicht geholfen?

[Talkabout]

Du meinst die Änderungen vom damals http://forum.fhem.de/index.php/topic,31838.0.html haben nicht geholfen?

Doch, diese Änderung hat für das initiale Pairing durchaus geholfen, vorher ging ja gar nichts

Es scheint aber so zu sein, dass die regelmäßige stündliche Meldung vom meinem SCC nicht interpretiert werden kann. Vielleicht gibt es dort auch noch eine Einschränkung auf "nur CUL"...

Gruss

[Matthias Gehre]

0B9106300A8AEC123456001024 scheint nicht vom Fensterkontakt zu kommen, denn dessen Adresse 0a7ffd kommt nicht drin vor.

[Talkabout]

0B9106300A8AEC123456001024 scheint nicht vom Fensterkontakt zu kommen, denn dessen Adresse 0a7ffd kommt nicht drin vor.

Hallo Matthias,

dies war nur ein Beispiel-Auszug. Ich habe insgesamt 12 Fensterkontakte und kann die fehlerhaften Nachrichten nicht zu den jeweiligen Geräten mappen. Wenn Du mir sagt, in welcher Form die ID in der Nachricht "versteckt" ist, dann kann ich noch mal prüfen.

Danke!

Gruss

[Matthias Gehre]

Die genaue Position weiß ich nicht aus dem Kopf, aber die id müsste original in der Nachricht vorkommen.
In 0B9106300A8AEC123456001024 sehe ich z.B. die Adresse 123456. Möglicherweise ist der Block davor
0A8AEC die Adresse des Geräts.