[CUL_HM] patches Oktober 2021 - die Zweite

[MadMax-FHEM]

Na ja, in einem Testsystem kann eigentlich nicht viel schiefgehen, und dann wüßten wir immerhin, ob das "autocreate-feature" weg ist...
Schlimmstenfalls schmiert FHEM ab .

Na dann...

Spiele ich demnächst mal alle Module von vorne und das hier ein...

EDIT: nix abgestürzt Und kein rotes Fragezeichen (auf dem anderen Testsystem ohne die neueste Version: erneut rotes Fragezeichen)

EDIT: im Log des "gepatchten" Systems steht aber nun gar nichts zu dem Vorgang...

EDIT: Patch läuft nun auf beiden testsystemen. Hauptsystem folgt... Dauert aber noch ein wenig...

Gruß, Joachim

[Beta-User]

Danke für die Rückmeldung.

Anmerkungen:
- Kein Log-Eintrag ist m.E. jedenfalls dann ok, wenn es eine VCCU gibt, wir wollen ja nicht "unknown - help me II" haben, oder? (eine verbose-4 könnte man in einem else-Zweig unterbringen, wenn es sein muss...)
- Interessant ist v.a. der Fall, das autocreate aus ist, aber ein pairing angestoßen wurde. Soll wäre: Device wird dann angelegt, der User will es ja eigentlich ausdrücklich so. Weiß aber nicht, ob das jetzt noch erfolgt, die Sprünge, die da im Code sind, sind "etwas unübersichtlich"...
Falls nein, ist vermutlich etwas mehr Nacharbeit gefragt, um den VCCU- bzw. IODev-Status betr. Pairing abzufragen.

[frank]

Kein Log-Eintrag ist m.E. jedenfalls dann ok, wenn es eine VCCU gibt, wir wollen ja nicht "unknown - help me II" haben, oder? (eine verbose-4 könnte man in einem else-Zweig unterbringen, wenn es sein muss...)

genau, joachims testsystem ist ja quasi wie ein unbeteiligter nachbar.

der darf ja keine infos kriegen und schon gar nicht ein definiertes device, das laut logs sogar dazwischen quatcht und getconfig absetzt! kein wunder, wenn manche höllische probleme beim anlernen hatten.

Code: [Auswählen]

2021.09.14 07:30:26 3: CUL_HM set HM_614B9A getConfig noArg

Interessant ist v.a. der Fall, das autocreate aus ist, aber ein pairing angestoßen wurde.

pairing wurde nicht angestossen, sage ich. nur ein anlegen, denn mit diesen daten (PairForSec: off):

Code: [Auswählen]

2021.10.22 12:27:38 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
sollte der pairingcode wegen zeile 3928 nicht abgearbeitet werden:

Code: [Auswählen]

    if ( $hmPair ){# pairing is active
alle 3 systeme melden angriffe von AFFE11, AFFE22 und AFFE33, da ja die attack erkennung auch nicht richtig funktioniert. siehe https://forum.fhem.de/index.php/topic,120459.0.html
nach den gesendeten befehlen ist AFFE1 jedenfalls das hauptsystem.

[MadMax-FHEM]

Korrekt: AFFE11 ist das Hauptsystem

Und ja, bei den weiteren "Versuchen" vorgestern (nicht gepostet, kann/könnte ich aber nachreichen) und heute wurde nur der Knopf am Drehgriffsensor gedrückt.

Bzw. falsch, vorgestern mit pairForSecs am Hauptsystem, damit der Drehgriffsensor die (vergessene) Zentrale wieder einlernt...
(ist aber für die Testsysteme dasselbe!?)

Logs müssen nicht sein, wollte nur mitteilen, dass halt nix drin war

Wenn ich noch was testen kann: einfach melden.

Ansonsten steht noch aus die neuesten Patches ins Hauptsystem zu spielen...
...aber wohl erst morgen...

Danke noch mal, Joachim

[frank]

Ansonsten steht noch aus die neuesten Patches ins Hauptsystem zu spielen...
...aber wohl erst morgen...

und da dann am besten noch mal richtig pairen, ob das auch noch funktioniert.
vorher möglichst auch das device löschen mit speichern und restart, damit das system vor dem pairen keine ahnung hat. vielleicht auch noch "set vccu clear unknownDev".

[MadMax-FHEM]

und da dann am besten noch mal richtig pairen, ob das auch noch funktioniert.
vorher möglichst auch das device löschen mit speichern und restart, damit das system vor dem pairen keine ahnung hat. vielleicht auch noch "set vccu clear unknownDev".

Jep, mach ich.
Aber dann definitiv erst morgen

Gruß, Joachim

[frank]

@beta-user
vermutlich hat martin autocreate absichtlich verbannt, weil zu viele es abgeschaltet hatten. 

[Beta-User]

@beta-user
vermutlich hat martin autocreate absichtlich verbannt, weil zu viele es abgeschaltet hatten. 

Man kann es zwar verbannen und auch für aktiviertes pairing einen Sonderweg gehen, aber wie hier gesehen, hat das Nebenwirkungen, über die man m.E. nicht so einfach weggehen sollte...

Nachdem das jetzt auch bei mir im Hauptsystem läuft, ist der letzte Stand samt patch wieder im ersten Beitrag zu finden. Das größte "Risiko", das ich im Moment dabei sehe ist, dass man autocreate wieder anschalten muss. Halte ich derzeit für das kleinere Übel, zumal sich viele wohl nicht über die Nebenwirkungen des Ausschaltens bewußt sind...

Kurzfassung für Augenreiber: anlassen und ungewolltes Zeug auf "ignore" stellen ist der von Rudi vorgesehene Weg und programmablauftechnisch der effektivere!

Dann ist mir noch was aufgefallen, was ich vermutlich in HMLAN leider verbastelt hatte, bitte aktualisieren!

[Benni]

@beta-user
vermutlich hat martin autocreate absichtlich verbannt, weil zu viele es abgeschaltet hatten. 

Ah! Damit erklärt sich auch, warum es mir beim Pairing einiger Fensterkontakte vor ein paar Tagen, die neu angelegten Devices partout nicht in den, in autocreate (aktiv!) definierten Raum verschieben wollte.

Das Pairing ansonsten hat allerdings astrein auf anhieb funktioniert!

gb#

[MadMax-FHEM]

Jep, mach ich.
Aber dann definitiv erst morgen

Gruß, Joachim

So, ausgeführt.

Also Module aus 1tem Post eingefügt, Device gelöscht, save, shutdown restart, autocreate aktiviert , Drehgriffsensor neu gepaired...

Dann öfters mal das Knöpfchen gedrückt (kenne ich ja   ) und auch mal getConfig (und wieder Knöpfchen)...

Was mich gewundert hat (aber vielleicht muss das so), dass cfgState auf "updating" blieb, obwohl cmds_done war.
Daher habe ich auch (unnötigerweise?) weitere getConfig angestoßen...
Und auch mal autoReadReag auf "readMissing" gestellt...
Irgendwann war dann cfgState auf ok
(einfach so)

Hat etwas gedauert, was man auch am list sieht, cmds_done deutlich VOR cfgState ok...

Hier das list:

Code: [Auswählen]

Internals:
   CFGFN     
   DEF        614B9A
   FUUID      6173cb59-f33f-753d-4988-a29f86511b742921
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     33
   NAME       HM_614B9A
   NR         2186
   NTFY_ORDER 48-HM_614B9A
   STATE      ???
   TYPE       CUL_HM
   chanNo     01
   disableNotifyFn 1
   hmusb_MSGCNT 33
   hmusb_RAWMSG E614B9A,0000,1CD311C6,FF,FFCA,298400614B9A0000002400304F45513230343730313780910101
   hmusb_RSSI -54
   hmusb_TIME 2021-10-23 10:47:56
   lastMsg    No:29 - t:00 s:614B9A d:000000 2400304F45513230343730313780910101
   protLastRcv 2021-10-23 10:47:56
   protRcv    22 last_at:2021-10-23 10:47:56
   protSnd    19 last_at:2021-10-23 10:47:25
   protState  CMDs_done
   rssi_at_hmusb cnt:34 min:-58 max:-53 avg:-55.61 lst:-54
   READINGS:
     2021-10-23 10:45:18   CommandAccepted yes
     2021-10-23 10:47:56   D-firmware      2.4
     2021-10-23 10:47:56   D-serialNr      OEQ2047017
     2021-10-23 10:47:24   IODev           hmusb
     2021-10-23 10:47:24   PairedTo        0xAFFE11
     2021-10-23 10:45:18   R-cyclicInfoMsg off
     2021-10-23 10:45:19   R-eventDlyTime  0 s
     2021-10-23 10:45:19   R-ledOnTime     0.5 s
     2021-10-23 10:45:19   R-msgRhsPosA    closed
     2021-10-23 10:45:19   R-msgRhsPosB    open
     2021-10-23 10:45:19   R-msgRhsPosC    tilted
     2021-10-23 10:45:18   R-pairCentral   0xAFFE11
     2021-10-23 10:45:18   R-sabotageMsg   on
     2021-10-23 10:45:19   R-sign          off
     2021-10-23 10:45:18   R-transmDevTryMax 6
     2021-10-23 10:45:19   R-transmitTryMax 6
     2021-10-23 10:47:24   RegL_00.         00:00 02:01 09:00 0A:AF 0B:FE 0C:11 10:01 14:06
     2021-10-23 10:47:24   RegL_01.         00:00 08:00 20:6C 21:00 22:64 30:06
     2021-10-23 10:49:15   cfgState        ok
     2021-10-23 10:47:25   commState       CMDs_done
   helper:
     HM_CMDNR   80
     cSnd       01AFFE11614B9A01040000000001,01AFFE11614B9A0103
     cfgStateUpdt 0
     lastMsgTm  1634978876.26244
     mId        0030
     peerFriend peerAct,peerVirt
     peerIDsRaw ,00000000
     peerIDsState complete
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     20
     supp_Pair_Rep 1
     cmds:
       TmplKey    :no:1634978993.79073
       TmplTs     1634978993.79073
       cmdKey     1:1:0::HM_614B9A:0030:01:
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerChan   -btnNumber- -actChn- [({single})] [({set}|unset)] [actor|remote|both]
         peerSmart  -peerOpt-
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sign       [(on|{off})]
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         trgEventL  -peer- -condition-
         trgEventS  -peer- -condition-
         trgPressL  [(-peer-|{all})]
         trgPressS  [(-peer-|{all})]
         unpair     noArg
       lst:
         condition  closed,open,tilted
         peer       
         peerOpt
...
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        1
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +614B9A,00,00,00
       nextSend   1634978876.36191
       rxt        2
       vccu       vccu
       p:
         614B9A
         00
         00
         00
       prefIO:
     mRssi:
       mNo        29
       io:
         hmusb:
           -48
           -48
     peerIDsH:
       00000000   broadcast
     prt:
       bErr       0
       sProc      0
       rspWait:
       tryMsg:
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rssi:
       at_hmusb:
         avg        -55.6176470588235
         cnt        34
         lst        -54
         max        -53
         min        -58
     shadowReg:
     tmpl:
Attributes:
   IOgrp      vccu:hmusb
   autoReadReg 5_readMissing
   expert     allReg,rawReg
   firmware   2.4
   model      HM-SEC-RHS
   peerIDs    00000000
   serialNr   OEQ2047017
   subType    threeStateSensor

Was mich wundert (ich aber nicht wirklich deuten kann, aber eigentlich denke da fehlen Infos/Register ist:

     2021-10-23 10:47:24   RegL_00.         00:00 02:01 09:00 0A:AF 0B:FE 0C:11 10:01 14:06
     2021-10-23 10:47:24   RegL_01.         00:00 08:00 20:6C 21:00 22:64 30:06

Dachte evtl. "aufbohren" des Attributs "expert", hat aber nicht geholfen...
EDIT: was mich wundert, dass ein "get hm configCheck" da nichts "anmosert"...
EDIT: hatte mir ja das alte Device als raw kopiert, da waren die REGL auch schon drin. Liegt also nicht an diesen Versionen, außer ich hab mal nachgelesen etc. und erst dann kam das... Laut Datum des Raw sind die auch neuer...

Code: [Auswählen]

setstate Fenster_WoZi_Griff 2021-10-21 11:46:59 .RegL_00.  00:00 02:01 09:00 0A:AF 0B:FE 0C:11 10:01 14:06
setstate Fenster_WoZi_Griff 2021-10-21 11:47:00 .RegL_01.  00:00 08:00 20:6C 21:00 22:64 30:06
Was das bedeutet: leider keine Ahnung

EDIT: REGL-Einträge sind jetzt weg Sieht alles gut aus!

Log (noch) "normale" verbose-Einstellungen:

Code: [Auswählen]

2021.10.23 10:44:01 3: CUL_HM set vccu hmPairForSec 60
2021.10.23 10:44:10 1: CUL_HM Unknown device HM_614B9A is now defined
2021.10.23 10:44:10 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: on PairSerial:
2021.10.23 10:44:10 3: CUL_HM pair: HM_614B9A threeStateSensor, model HM-SEC-RHS serialNr
2021.10.23 10:44:10 3: CUL_HM set HM_614B9A getConfig noArg
2021.10.23 10:45:17 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 10:45:45 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 10:45:45 3: CUL_HM set HM_614B9A getConfig noArg
2021.10.23 10:46:11 3: CUL_HM set HM_614B9A getConfig noArg
2021.10.23 10:46:18 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 10:47:15 3: CUL_HM set HM_614B9A getConfig noArg
2021.10.23 10:47:23 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 10:47:56 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 10:48:25 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$
2021.10.23 10:49:12 3: HMinfo hm get:configCheck :

Auf den anderen Systemen ebenfalls die Module eingespielt, shutdown restart...
Dort ist autocreate deaktiviert...
-> kein rotes Fragezeichen

Weiß nicht, ob das hilft...

Wenn ich noch was tun kann/testen soll: einfach melden, ich sehe dann mal.

Ansonsten würde ich jetzt mal cycligMsgInfo aktivieren (um zu sehen, ob das geht)...
(hat der dumme Sensor wohl auch "vergessen" beim Batteriewechsel / oh, also ich hab jetzt den Sensor nicht zurückgesetzt, hätte ich sollen?)
EDIT: nach einigem Knöpfchen drücken (und wieder cmds_done -> cfgState updating / noch mal [und noch mal] Knöpfchen drücken dann cfgState ok) dann endlich übernommen
und das Log dazu:

Code: [Auswählen]

2021.10.23 11:28:33 3: CUL_HM set HM_614B9A regSet exec cyclicInfoMsg on
2021.10.23 11:28:33 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$
2021.10.23 11:29:11 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 11:29:33 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$
2021.10.23 11:30:04 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 11:30:04 3: CUL_HM set HM_614B9A getConfig noArg
2021.10.23 11:31:05 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$

EDIT: was mir noch aufgefallen ist (aber für mich nicht schlimm   Ich kann mir ja behelfen ): "früher" wurden die neu angelegten HM-Devices in den Raum CUL_HM "verfrachtet" und auch ein FileLog-Device dazu angelegt... Das ist jetzt nicht passiert... Allerdings wohl auch schon nicht mehr mit den Versionen davor, also beim "Erstanlegen" des Fensterdrehgriffs letzten Monat (mit CUL_HM-Modulen, die bestimmt noch [viel] älter waren)...

Gruß, Joachim

[MadMax-FHEM]

Was mir noch aufgefallen ist, seit ich mit den Versionen hier "rumspiele":

ich habe ein notify, welches mir ein disconect des hmusb meldet.
Das hat bislang immer ausgelöst, bei shutdown restart (klar) und mir eine Nachricht gesendet.

Mit den Versionen hier aus dem Post ist das nicht mehr so.

EDIT: ich habe auch das 00_HMUARTLGW.pm aus dem verlinkten Thread eingespielt (18.10.)...

Ich bekomme nur mehr Meldungen beim Starten (die sind gleich geblieben).

Alte Abfolge bei shutdown restart:

Code: [Auswählen]

Neuer Status bei hmusb cond: disconnected

Neuer Status bei hmusb Xmit-Events: ok:1 disconnected:2 init:1

FHEM-System restarted!

Neuer Status bei hmusb cond: ok

Neuer Status bei hmusb Xmit-Events: ok:1 init:1 disconnected:1

Neue Abfolge:

Code: [Auswählen]

FHEM-System restarted!

Neuer Status bei hmusb cond: ok

Neuer Status bei hmusb Xmit-Events: ok:1 disconnected:1 init:1

Das ist seit dem 18.10. so...

Hier noch das notify dazu:

Code: [Auswählen]

Internals:
   DEF        hmusb:Xmit-Events.*|hmusb:cond.* set TeleBot message Neuer Status bei hmusb $EVENT
   FUUID      5fd8d700-f33f-753d-c989-e0059c0228104791
   NAME       nHMUSB
   NOTIFYDEV  hmusb
   NR         1982
   NTFY_ORDER 50-nHMUSB
   REGEXP     hmusb:Xmit-Events.*|hmusb:cond.*
   STATE      2021-10-23 10:41:20
   TRIGGERTIME 1634978480.64945
   TYPE       notify
   READINGS:
     2021-10-23 10:41:05   state           active
Attributes:

Wäre jetzt doof, wenn ich disconnected nicht mehr mitbekäme.
Da ich das schon mal hatte und dann so einiges nicht gut war, würde ich das schon gerne "wieder" wollen

Gruß, Joachim

P.S.: erst hatte ich mich nur gewundert und gedacht och naja, verschluckt... Aber jetzt schon das 2te Mal, da ist dann doch wohl was anders...

[MadMax-FHEM]

GANZ WICHTIG: die vielen "kleinfieseligen" Anmerkungen/"Fehler" nicht übel nehmen!!

Ich bin mit der/den aktuellen Versionen (bislang) sehr zufrieden!!!

Aber ich denke je ausführlicher "Fehler"/"Unschönheiten" etc. berichtet/beschrieben werden, desto besser die "Hilfe" (so hoffe ich)...
...also weniger als "Kritik" verstehen mehr als meine "Methode" zu helfen.
(mehr kann ich ja leider nicht groß beisteuern)

Danke noch mal für die Mühen!!

Gruß, Joachim

[frank]

Was mich gewundert hat (aber vielleicht muss das so), dass cfgState auf "updating" blieb, obwohl cmds_done war.

immer 60s nach dem ersten abarbeiten eines cmds. dann kommt die prüfung:

Code: [Auswählen]

2021.10.23 10:48:25 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$=> und das configcheck-icon in hm.js/HMinfoTools.js wechselt von orange nach grün (ok) oder rot (fehler).

Ansonsten würde ich jetzt mal cycligMsgInfo aktivieren (um zu sehen, ob das geht)...
(hat der dumme Sensor wohl auch "vergessen" beim Batteriewechsel / oh, also ich hab jetzt den Sensor nicht zurückgesetzt, hätte ich sollen?)

wenn schon, denn schon, oder?
=> ein template für die lieblings konfiguration mit hm.js zusammenklicken, definieren und zuweisen.
damit überwacht gonfigcheck auch die registereinstellungen und mit einem cmd lassen sich alle register wieder herstellen. 

[MadMax-FHEM]

immer 60s nach dem ersten abarbeiten eines cmds. dann kommt die prüfung:

Code: [Auswählen]

2021.10.23 10:48:25 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$=> und das configcheck-icon in hm.js/HMinfoTools.js wechselt von orange nach grün (ok) oder rot (fehler).

wenn schon, denn schon, oder?
=> ein template für die lieblings konfiguration mit hm.js zusammenklicken, definieren und zuweisen.
damit überwacht gonfigcheck auch die registereinstellungen und mit einem cmd lassen sich alle register wieder herstellen. 

Jaja, ich weiß.
Steht schon lange auf der LANGEN Liste was ich mir unbedingt mal anschauen wollte

Aber aktuell viele andere (wichtigere) "Baustellen" und (leider) nicht nur in/mit fhem...

Danke, Joachim

[frank]

Aber aktuell viele andere (wichtigere) "Baustellen" und (leider) nicht nur in/mit fhem...

für den anfang: nur 2 dateien kopieren und über attribute aktivieren.
spart dann wahrscheinlich ganz automatisch immer wieder zeit ein, da vieles ganz offensichtlich wird.
mittelfristig hast du also mehr zeit für andere dinge.