[gelöst]ActionDetector erkennt einige Devices nicht

[RalfRog]

HMConfig.pm = 13
10_CUL_HM.pm = 16

Und was hilft Dir das jetzt weiter?

Ne stimmt schon das hilft nicht weiter, aber irgenwas ist Martin da passiert.
1- wenn bewusst --> was ist der Hintergrund
2- wenn unbewusst --> lässt es sich vermutlich "reparieren"

Versionen bei mir:
$Id: HMConfig.pm 19226 2019-04-20 06:54:28Z martinp876 $
$Id: 10_CUL_HM.pm 19880 2019-07-21 12:14:49Z martinp876 $


Korrektur hatte wohl ein etwas älteres Backup zurückgespielt:
$Id: HMConfig.pm 19119 2019-04-05 15:52:43Z martinp876 $
$Id: 10_CUL_HM.pm 19069 2019-03-30 06:20:52Z martinp876 $

Damit war es noch fehlerhaft. Habe gerade ein Update gemacht und nun sind wieder alle Batteriedevices da = 9.
Versionen:
$Id: HMConfig.pm 19226 2019-04-20 06:54:28Z martinp876 $
$Id: 10_CUL_HM.pm 19889 2019-07-23 05:59:50Z martinp876 $

Somit stimmt es wieder.
Für die per Stromnetz versorgten Devices teste ist das Attributs actCycle nochmal


Gruß Ralf

Update2
Attribut actCycle funktioniert wie erwartet.
Wenn man es nachträgt entsteht das Attribut actStatus (=alive) sowie das Reading Activity (=alive)

[nuccleon]

Ich hab auch noch einen Kandidaten, der zwar zyklische Messages verschickt, aber nicht im ActionDetector auftaucht.

Code: [Auswählen]

,"00F9" => {name=>"HM-SEC-SIR-WM"           ,st=>'siren'             ,cyc=>''      ,rxt=>'c:b'    ,lst=>'1,3'          ,chn=>"Sen:1:2,Panic:3:3,Arm:4:4",}


Bei mir ist mit dem Update vom 12.08. HM-SEC-SIR-WM wieder aus dem Actiondetector verschwunden.

Der Startup Log am 11.08. sah noch so aus:

Code: [Auswählen]

2019.08.11 22:27:45 3: Device ftk_eg0_wohnzimmer added to ActionDetector with 002:50 time
2019.08.11 22:27:45 3: Device ftk_eg1_wohnzimmer added to ActionDetector with 002:50 time
2019.08.11 22:27:45 3: Device ftk_eg2_haustuere added to ActionDetector with 002:50 time
2019.08.11 22:27:45 3: Device ftk_eg5_kueche added to ActionDetector with 002:50 time
2019.08.11 22:27:45 3: Device ftk_eg4_kueche added to ActionDetector with 002:50 time
2019.08.11 22:27:47 3: Device ftk_eg3_wc added to ActionDetector with 002:50 time
2019.08.11 22:27:47 3: Device ftk_og0_bad added to ActionDetector with 002:50 time
2019.08.11 22:27:47 3: Device HM_Sirene added to ActionDetector with 001:00 time
2019.08.11 22:27:48 3: Device ftk_kg1_technikraum added to ActionDetector with 002:50 time
2019.08.11 22:27:48 3: Device ftk_kg0_hobbyraum added to ActionDetector with 002:50 time
2019.08.11 22:27:48 3: Device dts_aussen added to ActionDetector with 012:00 time
2019.08.11 22:27:48 3: Opening rgbww_kueche device 192.168.178.200:9090
2019.08.11 22:27:48 3: Opening rgbww_steinwand device 192.168.178.202:9090
2019.08.11 22:27:48 3: WEBFLEX: port 8084 opened
2019.08.11 22:27:49 3: Opening rgbww_markise device 192.168.178.203:9090
2019.08.11 22:27:50 1: Including /mnt/nfs/nas/fhem/log/fhem.save
2019.08.11 22:27:50 3: Device dts_aussen added to ActionDetector with 012:00 time
2019.08.11 22:27:50 3: Device ftk_eg0_wohnzimmer added to ActionDetector with 002:50 time
2019.08.11 22:27:50 3: Device ftk_eg1_wohnzimmer added to ActionDetector with 002:50 time
2019.08.11 22:27:50 3: Device ftk_eg2_haustuere added to ActionDetector with 002:50 time
2019.08.11 22:27:50 3: Device ftk_eg3_wc added to ActionDetector with 002:50 time
2019.08.11 22:27:50 3: Device ftk_eg4_kueche added to ActionDetector with 002:50 time
2019.08.11 22:27:50 3: Device ftk_eg5_kueche added to ActionDetector with 002:50 time
2019.08.11 22:27:50 3: Device ftk_kg0_hobbyraum added to ActionDetector with 002:50 time
2019.08.11 22:27:50 3: Device ftk_kg1_technikraum added to ActionDetector with 002:50 time
2019.08.11 22:27:50 3: Device ftk_og0_bad added to ActionDetector with 002:50 time
2019.08.11 22:27:51 3: Opening hm_uart_lgw device gatewaypi:2000
2019.08.11 22:27:51 0: Featurelevel: 5.9

Seit dem 12.08. sieht er nun so aus:

Code: [Auswählen]

2019.08.12 08:32:04 3: Device dts_aussen added to ActionDetector with 012:00 time
2019.08.12 08:32:04 3: Device ftk_eg0_wohnzimmer added to ActionDetector with 002:50 time
2019.08.12 08:32:04 3: Device ftk_eg1_wohnzimmer added to ActionDetector with 002:50 time
2019.08.12 08:32:04 3: Device ftk_eg2_haustuere added to ActionDetector with 002:50 time
2019.08.12 08:32:04 3: Device ftk_eg3_wc added to ActionDetector with 002:50 time
2019.08.12 08:32:04 3: Device ftk_eg4_kueche added to ActionDetector with 002:50 time
2019.08.12 08:32:04 3: Device ftk_eg5_kueche added to ActionDetector with 002:50 time
2019.08.12 08:32:04 3: Device ftk_kg0_hobbyraum added to ActionDetector with 002:50 time
2019.08.12 08:32:04 3: Device ftk_kg1_technikraum added to ActionDetector with 002:50 time
2019.08.12 08:32:04 3: Device ftk_og0_bad added to ActionDetector with 002:50 time
2019.08.12 08:32:04 3: Opening hm_uart_lgw device gatewaypi:2000
2019.08.12 08:32:04 0: Featurelevel: 5.9
2019.08.12 08:32:04 0:

HM_Sirene wird nun nicht mehr erkannt.

Auffällig ist, dass am 11.08. die Device Detektion Sequenz 2x abgearbeitet wurde. Beim ersten Durchlauf wurde HM_Sirene erkannt, beim zweiten nicht.

Seit dem 12.08. wird die Sequenz nur noch einmal durchlaufen, ohne HM_Sirene zu erkennen.

[frank]

Code: [Auswählen]

10_CUL_HM.pm                         18776 2019-03-03 08:48:20Z martinp876
mit dieser version funktioniert bei mir der AD bestens. diverse tests mit einem HM-LC-SW1-FM (attr actCycle: ändern, löschen und neu setzen, ebenso attr actAutoTry: on und off). auch alle änderungen ohne fhem restart.

nach fhem update gestern abend hat es mich nun auch erwischt.

5 devices (switch, dimmer), die per default kein attr actCycle haben, wurden aus dem actiondetector rausgeschmissen.

zusätzlich wird sogar bei 2 devices (1x defekt, 1x zum testen mit attr dummy=1), die per default attr actCycle haben, bei denen ich das attribut aber gezielt gelöscht habe, bei jedem fhem restart das attr actCycle neu gesetzt.
diese geben nun leider ständig alarm, da sie nicht mehr beim actiondetector "abgemeldet" werden können.

@martinp876
könntest du bitte mal nachschauen?


edit: das ausschliessen der devices vom actiondetector funktioniert bestens mit "attr actCycle off". das überlebt auch ein fhem restart.

[frank]

nach etwas testen, sieht es aktuell folgendermassen aus:

scheinbar ist zur zeit die korrekte initialisierung des actiondetector beim start von fhem defekt.
devices, die nicht zyklisch senden (dimmer, switches, ...) werden beim start nicht zum AD hinzugefügt, obwohl das attr actCycle gesetzt ist.

wenn fhem läuft werden durch erneutes setzen des attributes actCycles die devices zum AD hinzugefügt.
nach fhem restart bleiben die status_-readings bei mir als "leichen" erhalten, wodurch ein korrektes verhalten vorgetäuscht wird. die summe der devices im state reading ist aber kleiner als die anzahl der status_ readings.

folgendes notify (code für DEF) kann als workaround zum automatischen erneuten setzen der attribute genutzt werden. die namen der devices in der liste müssen natürlich angepasst werden.

Code: [Auswählen]

global:INITIALIZED {
foreach my $dev ("HM_3913D3","DimUP01","SwitchPBU01","SwitchUP01","SwitchUP02") {
fhem("attr ".$dev." actCycle ".AttrVal($dev,"actCycle","000:00"));
}
}

edit: list nach restart mit 5 reading "leichen":

Code: [Auswählen]

Internals:
   DEF        000000
   FUUID      5c4ce2ed-f33f-09c4-df1e-95380d131d3c5290
   NAME       ActionDetector
   NOTIFYDEV  global
   NR         558
   NTFY_ORDER 50-ActionDetector
   STATE      alive:23 dead:0 unkn:0 off:2
   TYPE       CUL_HM
   chanNo     01
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .attrtocr:
     .*
   READINGS:
     2019-09-19 12:04:06   state           alive:23 dead:0 unkn:0 off:2
     2019-09-19 10:28:50   status_DimUP01  alive
     2019-09-18 18:04:05   status_Fenster.Bad alive
     2019-09-19 10:28:50   status_HM_3913D3 alive
     2019-09-18 18:04:05   status_SD.AZ    alive
     2019-09-18 18:04:05   status_SD.SZ    alive
     2019-09-18 18:04:05   status_SD.WZ    alive
     2019-09-18 18:04:05   status_SwitchES01 alive
     2019-09-19 10:28:50   status_SwitchPBU01 alive
     2019-09-19 10:28:50   status_SwitchUP01 alive
     2019-09-19 10:38:37   status_SwitchUP02 alive
     2019-09-18 18:04:05   status_Thermostat.AZ alive
     2019-09-18 18:04:05   status_Thermostat.Bad alive
     2019-09-18 18:04:05   status_Thermostat.Bad.OG alive
     2019-09-18 18:04:05   status_Thermostat.GZ alive
     2019-09-18 18:04:05   status_Thermostat.Keller alive
     2019-09-18 18:04:05   status_Thermostat.Kueche alive
     2019-09-18 18:04:05   status_Thermostat.OZ alive
     2019-09-18 18:04:05   status_Thermostat.SZ alive
     2019-09-18 18:04:05   status_Thermostat.WZ alive
     2019-09-18 18:04:05   status_Tuer.SZ  alive
     2019-09-18 18:04:05   status_Tuer.WZ.Terrasse alive
     2019-09-18 18:04:05   status_Ventil.AZ.Nord alive
     2019-09-18 18:04:05   status_Ventil.AZ.West alive
     2019-09-18 18:04:05   status_Ventil.Bad alive
     2019-09-18 18:04:05   status_Ventil.Kueche alive
     2019-09-18 18:04:05   status_Ventil.SZ alive
     2019-09-18 18:04:05   status_Ventil.WZ alive
     2019-09-18 18:04:05   status_Wetter.Nord switchedOff
     2019-09-18 18:04:05   status_Wetter.Sued alive
     2019-09-18 18:04:05   status_test     switchedOff
   helper:
     HM_CMDNR   191
     actCycle   600
     mId        no
     peers      123456,1936FF,193A9A,1BF81B,1BFC52,1C1BE3,1C4E25,1CE9F5,1D252E,1DE620,1DF7C6,1DFC2F,1DFDA5,1F91AA,206219,206278,206487,2064CB,20DFE1,24AF1D,52BB90,52BB9D,52C4DF,6869B6,83765A
     123456:
       start      2019-09-19 12:04:06
     1936FF:
       start      2019-09-19 12:04:04
     193A9A:
       start      2019-09-19 12:04:05
     1BF81B:
       start      2019-09-19 12:04:05
     1BFC52:
       start      2019-09-19 12:04:05
     1C1BE3:
       start      2019-09-19 12:04:04
     1C4E25:
       start      2019-09-19 12:04:05
     1CE9F5:
       start      2019-09-19 12:04:06
     1D252E:
       start      2019-09-19 12:04:05
     1DE620:
       start      2019-09-19 12:04:05
     1DF7C6:
       start      2019-09-19 12:04:05
     1DFC2F:
       start      2019-09-19 12:04:05
     1DFDA5:
       start      2019-09-19 12:04:05
     1F91AA:
       start      2019-09-19 12:04:05
     206219:
       start      2019-09-19 12:04:05
     206278:
       start      2019-09-19 12:04:04
     206487:
       start      2019-09-19 12:04:05
     2064CB:
       start      2019-09-19 12:04:05
     20DFE1:
       start      2019-09-19 12:04:05
     24AF1D:
       start      2019-09-19 12:04:04
     52BB90:
       start      2019-09-19 12:04:04
     52BB9D:
       start      2019-09-19 12:04:04
     52C4DF:
       start      2019-09-19 12:04:04
     6869B6:
       start      2019-09-19 12:04:06
     83765A:
       start      2019-09-19 12:04:06
     io:
       prefIO     
       vccu       
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       vrt        1
     tmpl:
Attributes:
   .mId       no
   actAutoTry 1_on
   event-on-change-reading .*
   model      ACTIONDETECTOR
   room       90_Technik,99_System
   subType    virtual
   timestamp-on-change-reading .*

[martinp876]

ist korrigiert

[frank]

jetzt werden wieder alle devices dem actiondetector zugewiesen.

dafür funktioniert nun nicht mehr "attr actAutoTry". nach actCycle sind die switches nun dead.

ein test mit 5min actcycle und restart test zeigt, dass doch alles ok ist. seltsam.
waren die eventuell schon zu lange tot?
der dead termin war nämlich schon vor diesem update.

[pwlr]

Moin,

bei mir ist auch wieder alles ok.   

Vielen Dank, Martin !
Moin
Bernd

[gromeck]

Hallo,
ich muss dieses Thema nochmal aufwärmen. Ich habe auf dem SW-Stand featurelevel 6.0/fhem.pl:23373/2020-12-17 genau das oben beschriebene Problem, d.h. nach dem Starten ist zwar in allen HM-Devices actCycle gesetzt, aber der AD interessiert sich für diese nicht. Setze ich das Attribut actCycle nochmal während FHEM bereits läuft, funktioniert der AD.
Die Lösung die actCycle Attribute erst mit dem Event global:(INITIALIZED|REREADCFG) zu setzen hat nicht geholfen -- das wahr wohl immer noch zu früh. Ein sleep hat dort auch nicht funktioniert (vermutlich weil FHEM durch den sleep geblockt ist).

Mein Workaround sieht nun so aus:

Code: [Auswählen]

define Trigger.Reset.actCycle notify global:(INITIALIZED|REREADCFG) { \
        Log 1,"Trigger.Reset.actCycle: NAME=$NAME  EVENT=$EVENT";; \
        fhem "define Trigger.Reset.actCycle.Helper at +00:00:10 attr NAME=(AB|KG|EG|OG|DG)\..*:FILTER=TYPE=CUL_HM:FILTER=DEF=.{6} actCycle 024:00";; \
    } \

[frank]

irgend was ist bei dir faul, das sollte auch ohne workaround funktionieren.
zeig mal die ausgabe von version, also alles.

startest du fhem mit rereadcfg?
oder hast du vielleicht kein hminfo definiert?