Hallo,
ich habe die beta-version der MAX-Software installiert (und evtl. folgende Updates ebenso).
Seit dem hängt sich die MAX-Umgebung häufig auf. (mehrmals täglich bis 4 Tage)
Helfen tut ein "set CUL868 reopen".
An der CUL-Firmware habe ich nichts geändert.
Auffällig ist, dass "NR_CMD_LAST_H" ständig Werte (14-22) enthält.
Früher waren dort nur Werte drin, wenn ein Endgerät ein Problem hatte und nicht an der Kommunikation teilnahm.
Hat jemand ähnliches beobachtet?
Ich würde als Nächstes mal versuchen die "alten" Versionen einzuspielen und zu vergleichen.
hmm schon komisch, ich setze meine Beta Version sowohl auf meinem aktiven FHEM als auch bei meiner Testinsel ein und konnte noch kein Problem feststellen.
U.a. schicke ich dem CUL auch nicht irgendwelche "neuen" Telegramme, da hat sich weder am Inhalt noch am Verfahren etwas geändert.
Aber hilf mir mal auf die Sprünge mit "NR_CMD_LAST_H" wo ist der Wert zu finden ?
Ich habe erst noch mal den ganzen Server + CUL heruntergefahren und stromlos gemacht. Mal sehen, ob es Besserung bringt.
Das NR_CMD_LAST_H findet man direkt am CUL ... aber auch nur, wenn Werte da sind. Sonst ist das internal nicht da.
Internals:
CMDS ABCEeFfGiKlMNRTtUVWXxZ
CUL868_1_MSGCNT 405
CUL868_1_TIME 2019-12-22 16:59:33
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400 1234
DeviceName /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400
FD 15
FHTID 1234
FUUID 5c44d125-f33f-ed2c-3871-55e86594f0fe3891
NAME CUL868_1
NR 85
NR_CMD_LAST_H 20
PARTIAL
RAWMSG Z0C7204420F31F4000000002AAA04
RSSI -72
STATE verfügbare Credits "3600" von 3600 Wartend: "20"
TYPE CUL
VERSION V 1.26.03 a-culfw Build: private build (unknown) nanoCUL868 (F-Band: 868MHz)
initString X21
Die Definition des CUL:
defmod CUL868_1 CUL /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400 1234
attr CUL868_1 DbLogInclude credit10ms
attr CUL868_1 icon cul_868
attr CUL868_1 model nanoCUL
attr CUL868_1 rfmode MAX
attr CUL868_1 room 8.1_CUL/MAX
attr CUL868_1 stateFormat verfügbare Credits "credit10ms" von 3600 Wartend: "Warteschlange"
attr CUL868_1 userReadings tmp:credit10ms.* { \
if(ReadingsVal("$NAME","credit10ms",0) eq "No answer" ) { \
fhem("set PostIt add AlarmLevel5 CUL-MAX-no Answer");;\
return "n.A."\
};; \
if(ReadingsVal("$NAME","credit10ms",0) < 1000 ) { \
fhem("set PostIt add AlarmLevel3 MAX-Credits low");;\
return "low"\
};; \
fhem("set PostIt remove AlarmLevel3 MAX-Credits low");;\
fhem("set PostIt remove AlarmLevel5 CUL-MAX-no Answer");;\
return "ok";;\
},\
\
Warteschlange {InternalVal("$NAME","NR_CMD_LAST_H",0)},
attr CUL868_1 verbose 0
Zitat von: dirk.k am 22 Dezember 2019, 17:10:05
Das NR_CMD_LAST_H findet man direkt am CUL ... aber auch nur, wenn Werte da sind. Sonst ist das internal nicht da.
ahh THX, kannte ich noch gar nicht :( Aber ein Blick in 00_CUL.pm bringt da schnell Klarheit :
Beim Init ist es nicht vorhanden, dann später aber min 1 und steigend
00_CUL.pm: delete($hash->{NR_CMD_LAST_H});
00_CUL.pm: $hash->{NR_CMD_LAST_H} = 1;
00_CUL.pm: $hash->{NR_CMD_LAST_H} = int(@b);hier hat 00_CUL nochmal selbst ein Auge auf das 1% Sende Limit ganz unabhängig vom CUL internen Zähler selbst -> get <name> credit10ms
Ich werde mal schauen wie ich die Werte noch in 14_CUL_MAX sinnvoll unterbringe und transparent beim loggen sichtbar machen kann.
Denn für andere Protokolle als HM und MAX gibt 00_CUL da beim überschreiten selbst Meldungen aus.
Update : Ich habe den aktuellen Wert jetzt mit ins MAX Logging gepackt, er sagt eigentlich direkt nur aus wievele Kommandos dieser CUL in der letzten Stunde verschickt hat, d.h. es kommt halt auch darauf an wie viel man macht bzw. was der CUL so zu tun hat. Bei den anderen Protokollen greigt die CUL Meldung wenn der Wert von 163 überschritten wurde.