Hilfe erbeten: zwei Türmelder peeren sich automatisch

[curt]

Nein, das stimmt nicht.
Alles hat gestimmt, alles war in Ordnung, auch restart.

Dann habe ich die letzte von Dir gestellte Aufgabe erledigt - DIREKT danach waren die Register weg usw.

[pc1246]

Moin
Kueche ist auf jeden Fall nicht gepairt! Und bitte zeige auch noch mal ein list der beiden Anderen!
Gruss Christoph

[LuckyDay]

Autor: pc1246
« am: Heute um 06:40:53 »

    Zitat einfügen


Moin
Kueche ist auf jeden Fall nicht gepairt!

Die Küche ist gepaired lt lastMsg 

lastMsg    No:12 - t:41 s:32FB4C d:FF1312 011100

[curt]

Ich merkte, dass die angeblich nicht gepairten Melder wieder als gepairt angegeben werden, wenn ich das zugehörige Fenster einmal öffne. Danach blieben die fehlenden Register der einzelnen Melder: getConfig und Knöpfchen drücken. Manche zierten sich ein wenig. Die Übung macht stramme Waden und schlanke Figur.

Aktueller Stand:

Code Auswählen Erweitern


configCheck done:

peer list incomplete. Use getConfig to read it.
    incomplete: Haustuer:
    incomplete: Terrassentuer:


Das habe ich nicht gemacht. - Wo kommt das nun wieder her? Ich befürchte, dass die beiden schon wieder heiraten wollen.

Die beiden zugehörigen Listings:

Code Auswählen Erweitern


Internals:
   DEF        3301C1
   FUUID      5c61e0f3-f33f-769b-cdc5-5e480d015a8b96a5
   IODev      myHmUART
   NAME       Haustuer
   NOTIFYDEV  global
   NR         976
   NTFY_ORDER 50-Haustuer
   STATE      closed
   TYPE       CUL_HM
   READINGS:
     2019-02-12 19:05:05   Activity        alive
     2019-02-11 21:54:12   CommandAccepted yes
     2019-02-12 00:09:53   D-firmware      2.4
     2019-02-12 00:09:53   D-serialNr      LEQ0893196
     2019-02-12 00:09:53   PairedTo        0xFF1312
     2019-02-12 00:09:53   R-cyclicInfoMsg off
     2019-02-12 00:09:53   R-eventDlyTime  0 s
     2019-02-12 00:09:53   R-pairCentral   0xFF1312
     2019-02-12 00:09:53   R-sabotageMsg   on
     2019-02-12 00:09:53   R-sign          off
     2019-02-12 00:09:53   RegL_00.        00:00 02:01 09:00 0A:FF 0B:13 0C:12 10:01 14:06
     2019-02-12 00:09:53   RegL_01.        00:00 08:00 20:60 21:00 22:64 30:06
     2019-02-12 00:12:17   alive           yes
     2019-02-12 18:28:16   battery         ok
     2019-02-12 18:28:16   contact         closed (to VCCU)
     2019-02-12 00:12:17   recentStateType info
     2019-02-12 00:12:17   sabotageError   off
     2019-02-12 18:28:16   state           closed
     2019-02-12 18:28:16   trigger_cnt     101
   helper:
     HM_CMDNR   123
     mId        00B1
     regLst     ,0,1,4p
     rxType     4
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +3301C1,00,00,00
       rxt        0
       vccu       VCCU
       p:
         3301C1
         00
         00
         00
       prefIO:
         myHmUART
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     tmpl:
Attributes:
   Fenster_Status structure_Fenster
   IODev      myHmUART
   IOgrp      VCCU:myHmUART
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   battery_change 2018-12-03
   devStateIcon open:fts_door_open@red closed:fts_door@green
   expert     2_raw
   firmware   2.4
   model      HM-SEC-SC-2
   room       Unsorted
   serialNr   LEQ0893196
   subType    threeStateSensor
   userattr   Fenster_Status Fenster_Status_map structexclude


Code Auswählen Erweitern


Internals:
   DEF        3301D3
   FUUID      5c61e312-f33f-769b-982e-446f8b676d2630c2
   IODev      myHmUART
   NAME       Terrassentuer
   NOTIFYDEV  global
   NR         977
   NTFY_ORDER 50-Terrassentuer
   STATE      closed
   TYPE       CUL_HM
   READINGS:
     2019-02-12 19:05:06   Activity        alive
     2019-02-11 22:03:15   CommandAccepted yes
     2019-02-12 00:10:02   D-firmware      2.4
     2019-02-12 00:10:02   D-serialNr      LEQ0893214
     2019-02-12 00:10:03   PairedTo        0xFF1312
     2019-02-12 00:10:03   R-cyclicInfoMsg off
     2019-02-12 00:10:03   R-eventDlyTime  0 s
     2019-02-12 00:10:03   R-pairCentral   0xFF1312
     2019-02-12 00:10:03   R-sabotageMsg   on
     2019-02-12 00:10:03   R-sign          off
     2019-02-12 00:10:03   RegL_00.        00:00 02:01 09:00 0A:FF 0B:13 0C:12 10:01 14:06
     2019-02-12 00:10:03   RegL_01.        00:00 08:00 20:60 21:00 22:64 30:06
     2019-02-12 00:12:41   alive           yes
     2019-02-12 00:12:44   battery         ok
     2019-02-12 00:12:44   contact         closed (to VCCU)
     2019-02-12 00:12:41   recentStateType info
     2019-02-12 00:12:41   sabotageError   off
     2019-02-12 00:12:44   state           closed
     2019-02-12 00:12:44   trigger_cnt     52
   helper:
     HM_CMDNR   79
     mId        00B1
     regLst     ,0,1,4p
     rxType     4
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +3301D3,00,00,00
       rxt        0
       vccu       VCCU
       p:
         3301D3
         00
         00
         00
       prefIO:
         myHmUART
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     tmpl:
Attributes:
   Fenster_Status structure_Fenster
   IODev      myHmUART
   IOgrp      VCCU:myHmUART
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   battery_change 2018-04-22
   devStateIcon open:fts_door_open@red closed:fts_door@green
   expert     2_raw
   firmware   2.4
   model      HM-SEC-SC-2
   room       Unsorted
   serialNr   LEQ0893214
   subType    threeStateSensor
   userattr   Fenster_Status Fenster_Status_map structexclude

[pc1246]

Moin curt
Das Peering wird im device hinterlegt, da es ja die direkte Kommunikation zwischen Devices beschreibt. Ein getConfig bewirkt also nur, dass von den Devices alle noch nicht bekannten Infos abgeholt werden. Wenn dann also wieder das Peering auftaucht, dann hast Du das da irgendwann reingeschrieben, und musst es dementsprechend loeschen!
BTW: Es ist sehr schwierig Dir zu folgen, da man nicht immer genau weiss, was Du machst/gemacht hast, und Deine Saetze manchmal auch nicht vollstaendig sind!
Gruss Christoph

[Pfriemler]

Ich beobachte hier eine seltsame Form der Vergesslichkeit.
Wenn ein getConfig auf ein Gerät die Register von anderen unbeteiligten vergessen macht, liegt da woanders der Hase im Pfeffer.
Dann fehlen sämtliche Infos, vom Pairing-Status bis zu allen Registerwerten. Erstere werden natürlich von allein restauriert, sobald sich ein Kontakt wieder bei der Zentrale meldet, eben nach Betätigung.

Speicherkarte intakt, fhem.save (das Statefile) wird richtig geschrieben?

Eher sehr unwahrscheinlich, aber dennoch: Wurden mal hm-templates angewendet, deren Vorgaben FHEM vielleicht ständig wiederherzustellen versucht?

[frank]

es wurde wahrscheinlich mindestens ein fhem restart gemacht, da protokoll infos und io infos in den internals fehlen.

wird denn beim restart immer grundsätzlich automatisch das statefile gesichert?

[Pfriemler]

wird denn beim restart immer grundsätzlich automatisch das statefile gesichert?

Normalerweise schon, ich habe mich noch nie darum gekümmert und der Zeitstempel ist immer aktualisiert.

[pc1246]

Ok, das beantwortet den Punkt, der mir vorhin unklar blieb: Wo/wie "save" zu machen sei.

Ich bin mir nicht sicher, ob auch wirklich immer ein "save" mit im Spiel war. Deswegen schrieb ich ja auch, dass man nicht so richtig verfolgen kann, was gemacht wurde.
Gruss Christoph

[LuckyDay]

warum fehlt bei dem Device
Haustuer und Terrassentuer

das Attr < >peerIDs    00000000,

bei der Kueche ist es vorhanden, im Übrigen , bei meinen eigenen Device ist es auch vorhanden.

bei einem shutdown, bzw shutdown restart -->wird immer ein statefile bzw. die Datei fhem.save geschrieben, es sei denn du hättest es bei global entfernt.

[martinp876]

So isses. Ein getconfig liest das device aus. Es schreibt und setzt nichts. Danach sollte bei entities welche gepeert werden können zumindest ein 00000000 auftauchen. Das zeigt dass das Lesen abgeschlossen ist.
Sollte also nach einem getconfig ein cmds_done erscheinen aber kein peers 00000000 dann ist etwas schief gelaufen.

Peers sind immer an einen Kanal gebunden, nicht an das device ( siehe Unterscheidung in den Grundlagen).

Device welche gepairt sind peeren nur noch über die Zentrale. Also nur über deine Kommandos. Automatisch geht nix.
Und wenn du nicht lesen läst (getconfig) wirst du den Zustand nicht erfahren

[curt]

warum fehlt bei dem Device
Haustuer und Terrassentuer

das Attr < >peerIDs    00000000,

Nach Erstellung war das vorhanden, siehe #13. Dann waren die Reg aller anderen weg. Als ich die mühselig wieder mit getConfig geholt hatte, waren die beiden peerIDs weg.

bei einem shutdown, bzw shutdown restart -->wird immer ein statefile bzw. die Datei fhem.save geschrieben, es sei denn du hättest es bei global entfernt.

Dort steht "attr global statefile ./log/fhem.save".

* # $Id: 10_CUL_HM.pm 18184 2019-01-08 20:43:59Z martinp876 $
* ls -l 10_CUL_HM.pm
   -rw-r--r-- 1 fhem dialout 590655 Jan 23 00:19 10_CUL_HM.pm

Ich habe mich exakt an das gehalten, was Du mir vorgegeben hast. Natürlich kann ich nicht völlig ausschließen, dass da ein Linux-Reboot dazwischen war, möchte das aber verneinen.

Frage: Warum wird sowas nicht sofort gespeichert?

Frage: Bei den beiden Türen nun getConfig? (Und die Hoffnung, das die nicht wieder untereinander "heiraten" ...)

[Pfriemler]

Nach Erstellung war das vorhanden, siehe #13. Dann waren die Reg aller anderen weg. Als ich die mühselig wieder mit getConfig geholt hatte, waren die beiden peerIDs weg.

Und eben das kommt normalerweise nie vor. Was vorkommt ist, dass ein unvollständiger Registersatz zu einem Gerät nach einem weiteren Leseversuch noch unvollständiger ist, weil die Register immer "am Stück gelesen" und alte Einstellungen verworfen werden. Nur mit einem fehlerfreien Leseversuch sind die Daten vollständig zu bekommen. Aber das ein fehlgeschlagener oder erfolgreicher Leseversuch die Daten anderer Geräte in Mitleidenschaft zieht, kommt normalerweise nie vor.

Hast Du zwischendurch mal ein "clear msgEvents" am IO bzw. der VCCU gemacht? Wenn alte misslungene Konfigurations- oder Leseversuche den Queue verstopfen, ist das in aller Regel der Fälle kontraproduktiv.

Frage: Warum wird sowas nicht sofort gespeichert?

Änderungen an der FHEM-Konfiguration werden (default) auch nicht sofort gespeichert.
Registerdatensätze können übrigens auch separat gespeichert werden...

(Und die Hoffnung, das die nicht wieder untereinander "heiraten" ...)

Ich sag's letztmalig: Fehlen FHEM die Registerdaten, dann kann es auch keine Kanäle als gepeert anzeigen. Tauchen nach einem Auslesen die Geräte als gepeert auf, ist der naheliegende Schluss daher nicht, dass sie sie wieder "geheiratet" haben, sondern dass sie nie "geschieden" wurden.

[curt]

Aber das ein fehlgeschlagener oder erfolgreicher Leseversuch die Daten anderer Geräte in Mitleidenschaft zieht, kommt normalerweise nie vor.

Bei mir kann man das ja besichtigen.

Hast Du zwischendurch mal ein "clear msgEvents" am IO bzw. der VCCU gemacht? Wenn alte misslungene Konfigurations- oder Leseversuche den Queue verstopfen, ist das in aller Regel der Fälle kontraproduktiv.

Nein, habe ich nicht. Ich habe den Satz nicht richtig verstanden: Soll ich das machen? Wann genau?

Frage: Warum wird sowas nicht sofort gespeichert?

Änderungen an der FHEM-Konfiguration werden (default) auch nicht sofort gespeichert.

Bei der FHEM-Konfiguration leuchtet mir das ein. Aber aus welchem Grund wird das bei HM nicht sofort gespeichert?

Registerdatensätze können übrigens auch separat gespeichert werden...

Den Satz habe ich nicht verstanden.

Tauchen nach einem Auslesen die Geräte als gepeert auf, ist der naheliegende Schluss daher nicht, dass sie sie wieder "geheiratet" haben, sondern dass sie nie "geschieden" wurden.

Bei beiden gab es ein Hardware-Reset. Aber mich würde nichts mehr wundern.

[pc1246]

Bei beiden gab es ein Hardware-Reset. Aber mich würde nichts mehr wundern.

Moin
Wie sieht denn ein HW-reset bei Dir aus?
Gruss Christoph