FHEM - Hausautomations-Systeme > Homematic

[CUL_HM] patches Oktober 2021 - die Zweite

<< < (24/25) > >>

Benni:

--- Zitat von: frank am 01 November 2021, 11:08:04 ---edit: martin erlaubt explizit gemischtes io handlinghttps://forum.fhem.de/index.php/topic,122107.0.html

--- Ende Zitat ---

Ob das aber wirklich sinnvoll ist?
Ich denke ein IO, das über eine vccu verwaltet wird, sollte dem User nicht mehr als IO für die explizite Zuweisung per Att IODev zur Verfügung stehen. Dazu wäre dann ja das prefered-IO in IOgrp zu verwenden.

Ein IO, das nicht mehr unter der Verwaltung einer vccu steht, natürlich schon!
Das wäre dann übrigens bei mir der Fall gewesen: Das IO hat in der FHEM-Installation ja noch existert (dummy=1 / physikalisch nicht mehr vorhanden) und war dem Device per Attr IODev zugewiesen. Also hätte hier gar keine IO-Zuweisung stattfinden müssen.
Auch dann hätte ich wahrscheinlich die Fehlkonfiguration schnell gefunden denn das entsprechende Device hätte einfach nicht mehr funktioniert.

Allerdings hätte dann schon früher, als das IO noch unter Verwaltung der vccu stand, die Fehlkonfiguration in vccu auffallen können. Hätte sogar stillschweigend korrigiert werden können, indem IODev gelöscht und IOgrp entsprechend mit vccu und prefered IO gesetzt worden wäre.

gb#

Gisbert:
Hallo Beta-User,

ich hatte den HMLAN vor längerer Zeit außer Betrieb genommen, da sich ein disconnect ans andere reihte.
Nachdem ich ein Update beim 00_HMLAN.pm (?), genau weiß ich es nicht mehr, gemacht hatte, lief es sehr gut.

In den letzten Tagen, insbesondere mit der aktuellen Version, kommen wieder häufiger disconnects.

Viele​ Grüße​ Gisbert​

Beta-User:

--- Zitat von: Gisbert am 02 November 2021, 07:53:16 ---Nachdem ich ein Update beim 00_HMLAN.pm (?), genau weiß ich es nicht mehr, gemacht hatte, lief es sehr gut.

In den letzten Tagen, insbesondere mit der aktuellen Version, kommen wieder häufiger disconnects.

--- Ende Zitat ---
Bin etwas ratlos, welche Version du denn wann jetzt genau im Einsatz hattest. Die aktuelle svn-Version ist ja schon recht alt, und eventuell hattest du den in der im ersten Thread auch eingeflossenen patch angewendet?


Wie dem auch sei, ich bin jetzt mal über die letzten Fassungen von HMLAN und CUL_HM drüber und hätte wieder mal Testversionen im Angebot - bislang von meiner Seite nur grob angetestet.

Änderungen HMLAN:- use DevIo; (wg. pre-commit hooks?)
- ansonsten bisherige patch-Fassung, aber ohne Instanz-Hash-:Clients:, also insbesondere (hoffentlich) weiter verbessertes reconnect/reboot-Verhalten.

Änderungen CUL_HM:
- :Clients:-Erkennung so umgestellt, dass man es in HMLAN nicht braucht (vereinfachte Fassung per einfacher alternativer Abfrage auf TYPE=HMLAN). Die Aktualisierung von HM_LAN ist damit nicht mehr verpflichtend, sondern nur noch empfolen;
- Counter für die IO-Geschichte eingebaut (mAn. ist die aktualisierte Logik schneller als die alte! Es wird nur einmal ein (um den Device-Namen erweiterter) Log-Eintrag erzeugt). In dem Zusammenhang: Die alte Logik war eigentlich nur erst mal ein erster Versuch, um irgendwelchen Missmatches überhaupt auf die Spur zu kommen, und von daher auch noch nicht bis ins letzte durchdacht und ausgereift...
- gg. der bisherigen patch-Fassung etwas vereinfachte Logik für das automatisierte Anlegen von Devices (nur noch hmPair aktiv?-Abfrage).
- Manche der von Benni in https://forum.fhem.de/index.php/topic,123744.msg1183485.html#msg1183485 geschilderten warnings müßten beseitigt sein. Allerdings ist mir nicht ganz klar, wie die überhaupt entstanden sind... Da scheint auch sonst noch irgendwas kaputt gewesen zu sein.
- "proposed"-Ermittlung aus Reading ist entsprechend Martins Wünschen draußen, kann sein, dass damit auch ein Teil der Mismatches in der Zuweisung entfällt (oder was dazukommt ::) ). Auch von daher macht das mit dem Counter m.E. mehr Sinn.

Für die key-Zuweisung bei AES, wenn man neue IO's in die VCCU-IOList aufnimmt (?) habe ich derzeit noch keine Idee.

Werde es bei Gelegenheit auch selbst wieder im Echtsystem testen, aber die bisherige Geschwindigkeit kann ich nicht mehr leisten. Nach dem Selbsttest gibt es dann vermutlich einen "November"-Patches-Thread ;) .

Über die Änderungen an den anderen Dateien habe ich weiter nur überschlägig geschaut.

mumpitzstuff:
Ich habe keine Ahnung ob ich hier richtig bin, aber nachdem ich heute ein "update all" angestoßen habe, sind alle meine Feuermelder (HM-SEC-SD) im state: unreachable. Hat jemand eine Idee woran das liegen könnte?


--- Code: ---Internals:
   DEF        23457F
   FUUID      5c4b8852-f33f-55cb-ee36-49cbe6bf5a10d383
   FVERSION   10_CUL_HM.pm:0.251580/2021-10-30
   IODev      MapleWifi868
   NAME       SMOKE_SCHLAFZIMMER
   NR         31
   NTFY_ORDER 48-SMOKE_SCHLAFZIMMER
   STATE      unreachable
   TESTNR     1
   TYPE       CUL_HM
   chanNo     01
   disableNotifyFn 1
   peerList   self01
   protCmdDel 1
   protResnd  1 last_at:2021-11-02 19:26:19
   protResndFail 1 last_at:2021-11-02 19:26:24
   protSnd    1 last_at:2021-11-02 19:26:14
   protSndB   2 last_at:2021-11-02 19:26:19
   protState  CMDs_done_Errors:1
   sdTeam     sdLead
   READINGS:
     2021-11-02 19:35:52   Activity        alive
     2021-09-01 16:12:28   D-firmware      1.0
     2021-09-01 16:12:28   D-serialNr      KEQ0709128
     2021-11-02 19:26:14   IODev           MapleWifi868
     2021-11-02 11:01:52   PairedTo        0x26E92F
     2021-09-01 16:33:43   R-pairCentral   0x26E92F
     2021-11-02 11:01:52   RegL_00.        00:00 02:01 0A:26 0B:E9 0C:2F
     2021-11-02 11:01:48   battery         ok
     2021-11-02 11:02:53   cfgState        ok
     2021-11-02 19:26:24   commState       CMDs_done_Errors:1
     2021-10-28 08:32:45   eventNo         0C
     2021-11-02 11:01:48   level           0
     2021-11-02 19:25:52   peerList        self01
     2021-11-02 11:01:47   powerOn         2021-11-02 11:01:47
     2021-10-28 08:32:32   recentAlarm     vccu
     2021-11-02 11:01:48   recentStateType info
     2021-10-28 08:32:45   smoke_detect    none
     2021-11-02 19:26:34   state           unreachable
     2021-10-28 08:30:40   teamCall        from vccu:2
     2020-07-18 21:10:39   trigLast        SMOKE_SCHLAFZIMMER:short
     2020-07-18 21:10:39   trig_SMOKE_SCHLAFZIMMER Short_4
     2021-10-28 08:30:40   trigger         Short_2
     2021-10-28 08:32:46   trigger_cnt     12
   helper:
     HM_CMDNR   170
     cSnd       ,0126E92F23457F010E
     fkt        sdLead1
     mId        0042
     peerFriend peerSD
     peerIDsState complete
     peerOpt    p:smokeDetector
     regLst     0
     rxType     2
     cmds:
       TmplKey    self01:no:1635877552.36656
       TmplTs     1635877552.36656
       cmdKey     1:1:0:sdLead1:SMOKE_SCHLAFZIMMER:0042:01:self01
       cmdLst:
         alarmOff   noArg
         alarmOn    noArg
         assignHmKey noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|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})]
         peerSmart  -peerOpt-
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         statusRequest noArg
         teamCall   noArg
         teamCallBat noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         tplSet_self01 -tplPeer-
         unpair     noArg
       lst:
         condition  Smoke Alarm,no alarm,tone off
         peer       self01
         peerOpt    SMOKE_AUSSEN,SMOKE_BAD,SMOKE_KINDERZIMMER,SMOKE_WOHNZIMMER,VIRTUAL_ACTOR_Btn1,vccu
         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        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +23457F,00,00,00
       nextSend   1635877579.19009
       rxt        0
       vccu       vccu
       p:
         23457F
         00
         00
         00
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
       00000000   broadcast
       23457F01   self01
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
     shadowReg:
     tmpl:
Attributes:
   IOgrp      vccu
   actCycle   099:00
   actStatus  alive
   alarmDevice Actor
   alarmSettings |set SMOKE_SCHLAFZIMMER alarmOn;define at_SMOKE_SCHLAFZIMMER at +00:05:00 set SMOKE_SCHLAFZIMMER alarmOff|set SMOKE_SCHLAFZIMMER alarmOff|00:21
   autoReadReg 4_reqStatus
   devStateIcon off:secur_smoke_detector .*:secur_smoke_detector@red
   expert     defReg,rawReg
   firmware   1.0
   model      HM-SEC-SD
   msgRepeat  1
   peerIDs    00000000,23457F01
   room       SCHLAFZIMMER
   serialNr   KEQ0709128
   subType    smokeDetector
   webCmd     statusRequest:teamCall:alarmOn:alarmOff
--- Ende Code ---

Ich bin mir eigentlich fast sicher, das es vor dem Update noch nicht so war, kann aber auch gern noch mal ein Backup einspielen, um das zu überprüfen...

PS: Nach einem statusRequest steht der state erst auf MISSING ACK und wenig später wieder auf unreachable. Das ist jetzt durchgängig bei allen Rauchmeldern so, einen Hardware Defekt kann ich also ausschliessen.
PSPS: Bei meinen Fenstersensoren oder Heizungsreglern sind mir übrigens keine Unregelmäßigkeiten aufgefallen.

Timmäää:
Hi Mumpitzstuff,

diese Updates hier sind nicht im SVN, sondern gehen darüber hinaus. Dein Problem hatte ich letztens auch, dachte es liege an dem hier bezogenen HMLAN-Update, aber nach einem Reboot des FHEM-Servers ging es bei mir wieder und ich habe keine weitere Analyse betrieben.

Es war wie bei dir: Bei allen Geräten unreachable und/oder Missing_ACK.

Gruß,
Tim

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln