Hallo Zusammen,
ich würde gerne verstehen welche Schritte ich durchführen kann um die Aktivität meiner Devices zu monitoren.
Auslöser dafür ist, das ich vor Monaten schon einige HM-CC-RT-DN installiert und in Betrieb genommen habe und jetzt vor der Aufgabe stehe Ihre Tastensperrfunktion wieder zu lösen, die Geräte aber nicht reagieren. Ich bin dann auf die Suche gegangen und sehe das ich zum einen ständig Errors bei den CMD_Pendings bekommen und zum anderen der Parameter acticity dead als Wert besitzt.
Ich weiß das es so etwas wie ein eingestellte Response Time gibt, ich weiß aber nicht wie ich diese sehe und wie ich diese einstellen kann. Gerne würde ich einen Weg finden an dem ich messen kann ob das Gerät überhaupt mit meinem Sender Kommuniziert und gerne würde ich den Fehler finden warum die CMDs auf Fehler laufen.
Würde mich freuen wenn jemand da so etwas wie ein kleines Howto für mich hat. Bin nicht der versierteste Perl Mensch.
Danke
Hallo,
also von einzustellenden Responsezeiten kenne ich nichts.
Außer du meinst: das Attribut actCycle
Das legt aber nur fest ob und in welchem Zyklus der ActionDetector prüft.
Dieser legt dann auch den Status: unknown/alive/dead "fest".
Wenn du öfter "dead" hast, die Geräte aber noch reagieren, kannst du das "Prüfintervall" ja höher setzen...
Heißt aber auch: es wird später festgestelt, dass wirklich etwas nicht passt...
(ich habe es allerdings bei einigen wo evtl. doch mal ein Telegramm "flöten geht" den actCycle auch höher gestellt)
Geräte mit actCycle solltes du so finden können:
list actCycle=..*
Du kannst ein notify auf ActionDetector:dead basteln und dich benachrichtigen lassen:
defmod nSignalDeadDevice notify ActionDetector.status_.*:dead {"Sende Nachricht"}
ungetestet da ich das in anderer Form einsetze. Aber prinzipiell sollte es so gehen...
Und (hoffentlich klar): "Sende Nachricht" musst du nat. entsprechend "ersetzen" mit dem was passieren soll, wenn ein Gerät vom ActionDetector als "dead" erkannt/festgelegt wird!! "Sende Nachricht" geht NATÜRLICH NICHT! ;)
Bzgl. nicht reagierender Geräte und msg_pending:
Welches "Funkmodul"?
Poste doch mal ein list davon und auch mal ein list (mind.) eines der Geräte die nicht "reagieren"...
Gruß, Joachim
hminfo bietet viele möglichkeiten zum erkennen von problemen.
ergänzend empfehle ich HMinfoTools.js im angepinnten thread.
Mir ist nicht klar, ob diene Frage beantwortet wurde - ich habe etwas anderes verstanden.
- du willst ein Kommando absetzen (bspw Tastensperre umstellen) und wunderst dich über den Ablauf.
- Das Problem-device ist ein RT
1) der RT ist ein Batterie-device und somit nicht dauernd "ansprechbar". Das Device meldet sich zyklisch (mit Jitter) so etwa alle 2,5min.
1a) man kann kommandos an das Device schicken welche dann gequeued werden. Wenn das Device aufwacht werden die Kommandos geschickt
1b) man kann auch ein Senden erzwingen indem man die Kommandos wie normal "in die Queue" stellt und dann ein Burst auslöst (an das Device oder den Kanal - das ist egal). "set <rt> burstXmit". Das kann man ein paar mal machen, kostet Batterie (verkraftbar) und belastet sehr den Funk. Macht man das 100 mal in 1h sendet das IO nicht mehr. Sollten fehler aufgreten kann man nur 30mal . Kann man also gerne probieren - nicht für den typischen Gebrauch.
wie schon beschrieben siehst du am actCycle und damit im ActionDetector sowie in hmInfo ob das Device lebt.
2) Zustand der Command-queue: im Device "internals" siehst du die "prot" eingräge, welche dir hier einen Status anzeigen. protState ist der zusammengefasste Status. "done" vs "pendig" indiziert das die Queue leer ist oder dass kommandos (besser messages) auf abschicken warten. Sollten fehler aufgetreten sein werden diese hier signalisiert.
2a) der Ablauf ist, dass Kommandos in messages übersetzt werden. Ein Kommando kann aus mehreren Messages bestehen (beispielsweise das Setzen der Register). Eine Kommand-queue ist nicht implementiert, sondern eine message-queue!. Messages werden je nach device-typ im Fehlerfall automatisch wiederholt - 3 mal. Ist das nicht erfolgreich wird das Kommando verworfen. Da unklar ist, ob die Sequenz der Messages "zwingend" war wird auch der Rest der Queue gelöscht. Man bekommt die Anzahl der gelöschten Messages im Status. Die Zähler sind kumulativ und können vom User gelöscht werden (set clear msgErrors). Somit entgeht einem kein Fehler
2b) HMInfo biehtet hier eine Systemübersicht (get hm protEvents) und erlaubt das Löschen aller message errors (set hm clearG msgErrors)
2c) im Device oder in HMInfo kann man die Message-queue löschen, falls es zu problemen kommt (set <def> clear msgEvents oder set hm clearG msgEvents)
3) die Fehler: jetzt wird es kompliziert. was könnte ein Fehler sein?
3a) timing - das muss man sniffen und "tief" auswerten. HM Devices verlangen ein striktes timing. Siehe Sniffen zum aufzeichnen
3b) das Device verweigert die Annahme - "NACK". das sollte in command not acceptes sichtbar sein
3c) das Device empfängt oder reagiert nicht
=> prüfe HMInfo protoEvents - das ist m.E. die beste Übersicht
=> debuggen gibt es nicht "generell"
=> typisch sollten die Kommandos funktionieren
4) Register, also die remanente Device-konfiguration, wird/sollte nach dem Schreiben besser rückgelesen werden. Nun kannst du dir merken, was du gesezt haben willst und vergleichen, was du setzen wolltest. Den "gewünschten" Registersatz kannst du als Template hinterlegen (siehe Template). Dann kann fhem prüfen, ob soll und ist übereinstimmen. Vorteil: wenn nach den Setzen sich die register ändern (durch nochmaliges peeren, programmieren am Device,...) wird dies erkannt und kann behoben werden.
Hallo,
man, ich habe durch die Einträge eine ganze Menge gelernt und habe tatsächlich das Gefühl das hier jetzt besser zu verstehen. Vielen Dank dafür.
Ggf. habe ich auch ein weiteres Problem gefunden. Wenn ich meine protoEvents ansehe. Scheint es so als ob mein HMLAN disconnected ist. Ich verwende einen HM-CFG-LAN LAN Konfigurations-Adapter. Ich nehme wohl an das dieser nicht auf disconnect stehen sollte. Habe im Anhang auch das protoEvent gestellt. Habe dazu auch recht viel in den Foren gelesen, aber das hat mich eher verwirrt.
protoEvents send to devices done:
name :State |CmdPend |Snd |Resnd #CmdDel |ResndFail |Nack |IOerr
HT_UG_BA_01 : - | - | - | - # - | - | - | -
HT_UG_WZ_Li : - | - | - | - # - | - | - | -
HT_UG_WZ_Mi : - | - | - | - # - | - | - | -
HT_UG_WZ_Re : - | - | - | - # - | - | - | -
WT_01_UG : done_Errors:1 | - | - | - # 16 | - | - | 1
==========================================================================================================
sum 0 |0 |0 |0 #16 |0 |0 |1
CUL_HM queue length:0
requests pending
----------------
autoReadReg : WT_01_UG
recent : none
status request :
autoReadReg wakeup : HT_UG_BA_01 HT_UG_WZ_Re
status request wakeup:
autoReadTest : HT_UG_BA_01_remote HT_UG_WZ_Re_WindowRec WT_01_UG_SwitchTr WT_01_UG_Climate HT_UG_WZ_Li_Clima WT_01_UG_remote HT_UG_BA_01_WindowRec HT_UG_WZ_Mi_Weather HT_UG_WZ_Re_Weather HT_UG_WZ_Re_Climate HT_UG_BA_01 HT_UG_BA_01_Climate HT_UG_WZ_Re_ClimaTeam HT_UG_WZ_Li HT_UG_WZ_Mi_Clima HT_UG_WZ_Mi HT_UG_BA_01_Weather HT_UG_WZ_Re_Clima HT_UG_BA_01_Clima WT_01_UG_Weather HT_UG_WZ_Re WT_01_UG_WindowRec HT_UG_BA_01_ClimaTeam HT_UG_WZ_Re_remote WT_01_UG
IODevs:HMLAN1:disconnected pending=0 condition:disconnected
msgLoadCurrent: 0
also das io/gateway checken.
bitte ein list vom hmlan posten.
(das lässt sich am besten lesen, wenn man es mit code-tags formatiert; #-button)
netzwerk/ip ok?
Hallo,
hier die List vom HMLAN1
Internals:
DEF 192.168.178.42:1000
DeviceName 192.168.178.42:1000
FUUID 5fc2d2b3-f33f-7ff2-3f89-7d19dcd42e1a4680
NAME HMLAN1
NEXT_OPEN 1606686441.15952
NR 40
NTFY_ORDER 50-HMLAN1
PARTIAL
STATE disconnected
TYPE HMLAN
XmitOpen 0
assignedIDsCnt 5 report:0
msgKeepAlive
msgLoadCurrent 0
owner
READINGS:
2018-11-17 12:18:10 D-HMIdAssigned 379C25
2018-11-17 12:18:10 D-HMIdOriginal 379C25
2018-11-17 12:18:10 D-firmware 0.964
2018-11-17 12:18:10 D-serialNr MEQ0314088
2020-11-29 00:17:21 Xmit-Events dummy:2 disconnected:1
2020-11-29 00:17:21 cond dummy
2018-11-24 11:01:35 loadLvl low
2020-11-29 00:17:07 prot_disconnected last
2020-11-29 00:17:21 prot_dummy last
2018-11-23 00:05:04 prot_init last
2018-11-23 00:05:04 prot_ok last
2016-12-17 11:08:41 prot_timeout last
2020-11-29 22:46:21 state disconnected
helper:
assIdCnt 5
assIdRep 0
cnd:
253 1
ids:
43F9D8:
cfg +43F9D8,00,00,00
name HT_UG_WZ_Re
43F9E5:
cfg +43F9E5,00,00,00
name HT_UG_WZ_Mi
43FC8A:
cfg +43FC8A,00,00,00
name HT_UG_BA_01
473D2C:
cfg +473D2C,00,00,00
name WT_01_UG
4A6F21:
cfg +4A6F21,00,00,00
name HT_UG_WZ_Li
k:
BufMin 30
DlyMax 0
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x25038c8)
q:
HMcndN 253
answerPend 0
hmLanQlen 1
loadLastMax 0
loadNo 0
scnt 0
ald:
0
0
0
0
0
0
0
0
0
0
0
0
apIDs:
Attributes:
group Zentraleinheit
hmId 379C25
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
du hast den hmlan scheinbar selbst mit attr dummy disconnected.
versuche also zb "set open" oder reopen oder restart.
dann solltest du schnellstens fw 0.965 flashen.
Hallo,
ja das ist richtig. Ich hatte gestern Abend schon mit dem Gedanken gespielt die Version zu flashen und wollte deshalb das I/O Device deaktivieren. Hatte es dann wohl nicht mehr zurück gestellt.
Jetzt habe ich mit dem Befehl "deleteattr <myHMLAN> dummy" das Attribut wieder entfernt und FHEM Neu gestartet. Dabei kommt die untere List raus bei dem das Gerät immer noch disconnected ist. Sagt mir bitte das dies nicht mit der Version zu tun haben kann. Bisher ging die Kommunikation ja auch und ich habe seit damals nichts geändert außer vielleicht das persönliche Körpergewicht :)
DEF 192.168.178.42:1000
DeviceName 192.168.178.42:1000
FUUID 5fc2d2b3-f33f-7ff2-3f89-7d19dcd42e1a4680
NAME HMLAN1
NEXT_OPEN 1606766843.00947
NR 40
NTFY_ORDER 50-HMLAN1
PARTIAL
STATE disconnected
TYPE HMLAN
XmitOpen 0
assignedIDsCnt 5 report:0
msgKeepAlive
msgLoadCurrent 0
owner
READINGS:
2018-11-17 12:18:10 D-HMIdAssigned 379C25
2018-11-17 12:18:10 D-HMIdOriginal 379C25
2018-11-17 12:18:10 D-firmware 0.964
2018-11-17 12:18:10 D-serialNr MEQ0314088
2020-11-30 21:05:16 Xmit-Events disconnected:1
2020-11-30 21:05:16 cond disconnected
2018-11-24 11:01:35 loadLvl low
2020-11-30 21:05:16 prot_disconnected last
2020-11-30 21:01:18 prot_dummy last
2018-11-23 00:05:04 prot_init last
2018-11-23 00:05:04 prot_ok last
2016-12-17 11:08:41 prot_timeout last
2020-11-30 21:06:23 state disconnected
helper:
assIdCnt 5
assIdRep 0
cnd:
253 1
ids:
43F9D8:
cfg +43F9D8,00,00,00
name HT_UG_WZ_Re
43F9E5:
cfg +43F9E5,00,00,00
name HT_UG_WZ_Mi
43FC8A:
cfg +43FC8A,00,00,00
name HT_UG_BA_01
473D2C:
cfg +473D2C,00,00,00
name WT_01_UG
4A6F21:
cfg +4A6F21,00,00,00
name HT_UG_WZ_Li
k:
BufMin 30
DlyMax 0
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x112a550)
q:
HMcndN 253
answerPend 0
hmLanQlen 1
loadLastMax 0
loadNo 0
scnt 0
ald:
0
0
0
0
0
0
0
0
0
0
0
0
apIDs:
Attributes:
group Zentraleinheit
hmId 379C25
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
Zitatbitte.....
(das lässt sich am besten lesen, wenn man es mit code-tags formatiert; #-button)
Zitatversuche also zb "set open" oder reopen oder restart.
Hi
danke für die Infos so erstmal. So langsam komme ich dahinter.
Leider verstehe ich nicht ganz was du meinst mit das (lässt sich am besten lesen, wenn man es mit code-tags formatiert; #-button) kannst du das kurz erläutern. Will ja das man mich versteht?
Meint ihr das Problem hängt mit einem firmware Update zusammen?
Danke
Naja indem du Ausgaben wie lists oder Logauszüge etc. eben postest und dabei das '#' aus dem Menü verwendest (siehe Anhang)...
[ code ]
Hier die Ausgabe...
[ /code ]
dann sieht es so aus:
Hier die Ausgabe...
Gruß, Joachim
Naja so ist das aber nicht wirklich besser...
Normalerweise stehen die Angaben "untereinander" bei list...
Und genauso wäre es hilfreich hier zu haben...
Wie kopierst du / fügst du ein?
(Browser, OS, ...)
Gruß, Joachim
So, ich habe es jetzt vorher noch mal kur in einen Editor gepackt um unerwünschte Satzzeichen zu eliminieren. Scheint jetzt besser zu sein.
Internals:
DEF 192.168.178.42:1000
DeviceName 192.168.178.42:1000
FUUID 5fc2d2b3-f33f-7ff2-3f89-7d19dcd42e1a4680
NAME HMLAN1
NEXT_OPEN 1607802902.38936
NR 40
NTFY_ORDER 50-HMLAN1
PARTIAL
STATE disconnected
TYPE HMLAN
XmitOpen 0
assignedIDsCnt 5 report:0
msgKeepAlive
msgLoadCurrent 0
owner
READINGS:
2018-11-17 12:18:10 D-HMIdAssigned 379C25
2018-11-17 12:18:10 D-HMIdOriginal 379C25
2018-11-17 12:18:10 D-firmware 0.964
2018-11-17 12:18:10 D-serialNr MEQ0314088
2020-11-30 21:05:16 Xmit-Events disconnected:1
2020-11-30 21:05:16 cond disconnected
2018-11-24 11:01:35 loadLvl low
2020-11-30 21:05:16 prot_disconnected last
2020-11-30 21:01:18 prot_dummy last
2018-11-23 00:05:04 prot_init last
2018-11-23 00:05:04 prot_ok last
2016-12-17 11:08:41 prot_timeout last
2020-12-12 20:54:02 state disconnected
helper:
assIdCnt 5
assIdRep 0
cnd:
253 1
ids:
43F9D8:
cfg +43F9D8,02,00,00
name HT_UG_WZ_Re
43F9E5:
cfg +43F9E5,02,00,00
name HT_UG_WZ_Mi
43FC8A:
cfg +43FC8A,02,00,00
name HT_UG_BA_01
473D2C:
cfg +473D2C,00,00,00
name WT_01_UG
4A6F21:
cfg +4A6F21,02,00,00
name HT_UG_WZ_Li
k:
BufMin 30
DlyMax 0
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x112a550)
q:
HMcndN 253
answerPend 0
hmLanQlen 1
loadLastMax 0
loadNo 0
scnt 0
ald:
0
0
0
0
0
0
0
0
0
0
0
0
apIDs:
Attributes:
group Zentraleinheit
hmId 379C25
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended