10_CUL_HM.pm 23421 2020-12-26 15:11:46Z martinp876
Obwohl zwei Devices des Status unknown haben liefert ein
get ActionDetector listDevice unknown
keine Ausgabe.
Das gilt auch für alle anderen Varianten von listDevice
Internals:
DEF 000000
FUUID 5c432730-f33f-a4cf-19a6-4d2594a2c4273180
NAME ActionDetector
NOTIFYDEV global
NR 40
NTFY_ORDER 50-ActionDetector
STATE alive:10 dead:0 unkn:2 off:0
TYPE CUL_HM
chanNo 01
READINGS:
2021-01-02 13:08:06 state alive:10 dead:0 unkn:2 off:0
2021-01-02 13:08:06 status_ar_Fenster alive
2021-01-02 13:08:06 status_az_Fenster_links alive
2021-01-02 13:08:06 status_az_Fenster_rechts alive
2021-01-02 13:08:06 status_bd_Fenster_links alive
2021-01-02 13:08:06 status_bd_Fenster_rechts alive
2021-01-02 13:08:06 status_bk_Aussentemp alive
2021-01-02 13:08:06 status_ku_Fenster unknown
2021-01-02 13:08:06 status_sz_Fenster_links alive
2021-01-02 13:08:06 status_sz_Fenster_rechts unknown
2021-01-02 13:08:06 status_wz_Fenster alive
2021-01-02 13:08:06 status_wz_Tuer_links alive
2021-01-02 13:08:06 status_wz_Tuer_rechts alive
helper:
HM_CMDNR 64
actCycle 600
peerFriend
peerOpt -:-
peers 033AB2,21E45C,21E4E0,25FB24,27A05A,28BF11,28BF46,594213,771DAA,CAD0A1,CE6115,E7B15D
regLst 0
rxType 1
033AB2:
start 20210102123805
21E45C:
start 20210102123805
21E4E0:
start 20210102123805
25FB24:
start 20210102123804
27A05A:
start 20210102123804
try 901
28BF11:
start 20210102123804
28BF46:
start 20210102123804
594213:
start 20210102123805
771DAA:
start 20210102123804
CAD0A1:
start 20210102123804
CE6115:
start 20210102123804
E7B15D:
start 20210102123805
try 901
cmds:
TmplKey :no:1609588604.20174
TmplTs 1609588604.20174
cmdKey 0:1:1::ActionDetector::00:
cmdLst:
assignHmKey noArg
clear (readings|all)
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getDevInfo noArg
raw -data- [...]
reset noArg
tplSet_0 -tplChan-
unpair noArg
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
listDevice [({all}|alive|unknown|dead|notAlive)]
param -param-
status noArg
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
event-on-change-reading .*
model ACTIONDETECTOR
room System->Homematic
subType virtual
[code]
bei mir ist "attr subType no".
"get listDevice ..." sieht passend aus.
allerdings sind bei mir gerade alle devices alive.
Also bei mir ist subtype auch "virtual" und bei mir kommt auch nichts...
Habe ich aber nie bemerkt, weil nie genutzt ;)
Also das get listDevice...
Ich reagiere auf Events (wie es sich gehört ;) )...
Allerdings kann ich das Attribut nicht anders setzen...
Ein modelForce (wie "vorgeschlagen") auf ACTIONDETECTOR ? will ich nicht machen, weil eigentlich tut alles wie soll :)
Evtl. "spiele" ich da auf meinem Testsystem mal rum. Aber da hab ich grad nicht wirklich Devices/Geräte dran hängen...
EDIT: da haben wir's schon. Auf einem Testsystem (noch gar) keinen ActionDetector und auf dem abderen Testsystem keine Devices/Geräte... ;)
EDIT: eben einen neu angelegt (da wo bislang keiner war) und der hat auch subtype "virtual"... Bzgl. Geräten/Devices muss ich mal schauen... ;)
Gruß, Joachim
ich würde zunächst probieren, attr subtype zu löschen. vielleicht repariert es sich selbst.
ansonsten fhem.cfg editieren. :)
den einsatz von modelforce verstehe ich hier nicht.
bei mir steht ebenfalls subType "no" drin.
bevor ihr in der cfg rumdoktert -->erst mal
set ActionDetector clear all
danach
set ActionDetector update
danach nochmal kontrollieren
get ActionDetector listDevice alive unknown usw...
Nach
set ActionDetector clear all
set ActionDetector update
hat sich das Verhalten bei mir nicht geändert.
Ich nutze das um mir einmal am Tag eine Übersicht über ausgefallene Geräte zuzuschicken.
Dafür sind die Events nicht so nützlich.
Nach Löschen des Attributs subType und ausführen der obigen Kommandos steht subType wieder auf virtual.
Das Kommando modelForce steht gar nicht in der set Auswahlliste.
nach HMConfig.pm gibt es beide subType, aber jeweils mit unterschiedlichem "attr .mId".
für subType=virtual dann .mId=0000
für subType=no dann .mId=no
,"0000" => {name=>"ACTIONDETECTOR" ,st=>'virtual' ,cyc=>'' ,rxt=>'' ,lst=>'' ,chn=>"",}
,"no" => {name=>"ACTIONDETECTOR" ,st=>'no' ,cyc=>'' ,rxt=>'' ,lst=>'' ,chn=>"",}
Attributes:
.mId no
event-on-change-reading .*
model ACTIONDETECTOR
room HM_IO
subType no
ich wollte es gerade schreiben
dsa attr .mid muss no sein , bzw fehlt bei dir
.mId kann man nicht manuell setzen, es wird dann wieder auf modelForce verwiesen was aber auch nicht funktioniert.
Ich habe es dann direkt in der fhem.cfg geändert.
Danach ist .mId aber wieder weg und subType steht wieder auf virtual.
Allerdings funktioniert jetzt get listDevice wieder.
Das verstehe ich nicht wirklich.
Mal sehen, ob dieser Zustand jetzt erhalten bleibt.
Es geht auch ohne das get: https://forum.fhem.de/index.php/topic,101121.msg1099997.html#msg1099997
So kommt man an alle Readings eines Devices (auch ActionDetector) und dann kann man ja prüfen etc.
Ich lasse meine ActionDetectoren mal wie sie sind ;)
Gruß, Joachim
Zitat von: kaihs am 02 Januar 2021, 15:49:26
.mId kann man nicht manuell setzen, es wird dann wieder auf modelForce verwiesen was aber auch nicht funktioniert.
Ich habe es dann direkt in der fhem.cfg geändert.
Danach ist .mId aber wieder weg und subType steht wieder auf virtual.
Allerdings funktioniert jetzt get listDevice wieder.
Das verstehe ich nicht wirklich.
Mal sehen, ob dieser Zustand jetzt erhalten bleibt.
Ich hatte mir meinen ACTIONDETECTOR jetzt auch geschlachtet.
nach einem shutdown restart :D
und er auf subtype virtuel stand. >:(
die HMConfig.pm geändert mit der --> #
# ,"0000" => {name=>"ACTIONDETECTOR" ,st=>'virtual' ,cyc=>'' ,rxt=>'' ,lst=>'' ,chn=>"",}
,"no" => {name=>"ACTIONDETECTOR" ,st=>'no' ,cyc=>'' ,rxt=>'' ,lst=>'' ,chn=>"",}
dann geht es auch wieder richtig ! mit attr subtype no
Ich habe aktuell auch Probleme mit dem ActionDetector,
ich habe mir ein paar neue Geräte gekauft und diese tauchen nun in der Liste nicht auf.
Im Actiondetector habe ich ein "clear all" und "update" gemacht. die neuen Geräte tauchen aber immernoch nicht auf.
in den Devices sind
autoReadReg 5_readMissing
expert defReg,rawReg
gesetzt und
R-cyclicInfoMsg on
taucht in den Readings auf.
Habe ich irgendetwas vergessen, oder hat das damit nichts zu tun?
Gruß
Ist das Attribut actCycle gesetzt?
Ohne das interessiert sich der ActionDetector nicht dafür...
Was sind das denn für Geräte?
Wie wäre es denn (wie üblich) mit einem list gewesen?
Statt ein paar Attribute zu posten (die mit der Frage/Problem [verm.] nichts zu tun haben)...
Gruß, Joachim
Hallo Joachim,
trotz meiner mageren Angaben hast du mit deiner Glaskugel ins schwarze getroffen.
Werde mich bessern und versuchen immer ein List mit dabei zu packen.
Das Attribut actCycle war in allen Geräten nicht gesetzt. Nun sind alle neuen Geräte da.
Herzlichen Dank, Joachim.
BTW. Anderes Thema: Jetzt werde ich mich mit meinen anderen Problemen weiter beschäftigen, irgendwie habe ich das Gefühl ich drehe mich beim beheben der Fehler von "ConfigCheck im Kreis"
ZitatDas Attribut actCycle war in allen Geräten nicht gesetzt. Nun sind alle neuen Geräte da.
dann hast du die devices vermutlich manuell angelegt, oder?
Ich habe die Geräte Anfang der Woche bekommen und dann in Fhem angelegt in der VCCU mit HmPairforSec. Dort wurden dann das Device und die Kanäle generiert. Danach habe ich die Namen mit "rename" angepasst. und die Verknüpfungen gemacht. Habe ich da einen Fehler gemacht?
Bitte ein list. Dann werde ich die Szenarien probieren.
Das Problem der ausbleibenden Antwort habe ich hoffentlich gefunden.
Morgen im Update
Hallo Martin,
sorry das ich mich jetzt erst melde. Hatte viel zu tun. Werde das Update installieren und dann nochmal testen, wenn mehr weiß, melde ich mich hier