Hallo,
ich habe gerne meine genutzten Credits im Blick - gerade am Anfang zum debuggen und später zur Lastverteilung (mehrere CUL).
14_CUL_MAX.pm
readingsSingleUpdate($hash, $io_name.'_creditsused', ReadingsVal($name, $io_name.'_creditsused', 0) + $necessaryCredit, 1);
Mit einem AT setze ich die Readings stündlich zurück.
Gibt es eine Möglichkeit das update-sicher zu gestalten?
Gruß
Ich mach das mit einem at welches minütlich die credits vom CUL abfragt und in ein log schreibt.
Dazu gibts noch einen SVG Plot der das Ganze grafisch darstellt.
defmod CUL0_credit10ms_Aktualisierung at +*00:01:00 get CUL_0 credit10ms
defmod FileLog_CUL0 FileLog ./log/CUL0-%Y-%m-%d.log CUL_0:credit10ms:.*
attr FileLog_CUL0 nrarchive 5
attr FileLog_CUL0 room Logs
viel zu umständlich, das Attribut debug am CULMAX Device auf 1 setzen dann hat es ein Reading CULNAME_credit10ms :)
Nettes Feature, aber bei mir nicht sehr zuverlässig (wobei ich es gestern aktiviert habe).
Mein CUL_868 meldet durch ein at alle 5 Minuten seine credits und sie werden protokolliert. Der CULMAX schreibt nun auch diesen neuen Wert ins Log. Aber über Nacht habe ich ein großes Loch vom CULMAX ohne Werte.
2020-06-20_21:47:30 CULMAX0 none_retry: 5
2020-06-20_21:47:33 CULMAX0 CUL_868_cmd_last_h: 13
2020-06-20_21:47:33 CULMAX0 CUL_868_credit10ms: 2294
2020-06-20_21:47:34 CULMAX0 CUL_868_cmd_last_h: 14
2020-06-20_21:47:34 CULMAX0 CUL_868_credit10ms: 2186
2020-06-20_21:50:26 CULMAX0 CUL_868_cmd_last_h: 15
2020-06-20_21:50:26 CULMAX0 CUL_868_credit10ms: 2249
2020-06-20_21:50:36 CULMAX0 CUL_868_cmd_last_h: 16
2020-06-20_21:50:36 CULMAX0 CUL_868_credit10ms: 2150
2020-06-21_12:06:15 CULMAX0 CUL_868_cmd_last_h: 17
2020-06-21_12:06:15 CULMAX0 CUL_868_credit10ms: 3600
Der CUL_868 schreibt durchgehend. Manchmal anscheinend auch selbst, ohne das mein at hier eine Rolle spielt.
2020-06-20_21:47:34 CUL_868 credit10ms: 2186
2020-06-20_21:50:26 CUL_868 credit10ms: 2249
2020-06-20_21:50:36 CUL_868 credit10ms: 2150
2020-06-20_21:52:11 CUL_868 credit10ms: 2136
2020-06-20_21:57:11 CUL_868 credit10ms: 2436
2020-06-20_22:02:11 CUL_868 credit10ms: 2737
2020-06-20_22:07:11 CUL_868 credit10ms: 3037
2020-06-20_22:12:11 CUL_868 credit10ms: 3338
2020-06-20_22:17:11 CUL_868 credit10ms: 3600
2020-06-20_22:22:11 CUL_868 credit10ms: 3596
2020-06-20_22:27:11 CUL_868 credit10ms: 3600
2020-06-20_22:32:11 CUL_868 credit10ms: 3600
2020-06-20_22:37:11 CUL_868 credit10ms: 3600
2020-06-20_22:42:11 CUL_868 credit10ms: 3600
...
Hier die Lists meiner Geräte:
Internals:
CMDS ABCEeFfGiKlMNRTtUVWXxYZ
CUL_868_MSGCNT 14420
CUL_868_TIME 2020-06-21 14:12:27
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400 0000
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400
FD 41
FHTID 0000
FUUID 5c822521-f33f-98e0-51bb-c6112116609df5ed
NAME CUL_868
NR 131
NR_CMD_LAST_H 2
PARTIAL
RAWMSG Z0E540202026283029FA70001180029E5
RSSI -87.5
STATE Initialized
TYPE CUL
VERSION V 1.26.04 a-culfw Build: private build (unknown) nanoCUL868 (F-Band: 868MHz)
initString X21
Zr
Za03b7d0
Zw111111
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-06-19 14:57:06 cmds A B C E e F f G i K l M N R T t U V W X x Y Z
2020-06-21 14:12:11 credit10ms 3600
2020-05-12 10:19:33 raw No answer
2020-06-21 14:12:27 state Initialized
2020-05-12 14:10:07 version V 1.26.04 a-culfw Build: private build (unknown) nanoCUL868 (F-Band: 868MHz)
XMIT_TIME:
1592733975.57763
1592733985.72423
Attributes:
icon cul_868
maxid 03b7d0
rfmode MAX
room System
Internals:
CULMAX0_MSGCNT 1
CULMAX0_TIME 2020-06-20 11:39:50
CUL_868_MAXID 03b7d0
CUL_868_MSGCNT 14426
CUL_868_RAWMSG Z0EFF0202020D7203C7CB0001180029
CUL_868_RSSI -47
CUL_868_TIME 2020-06-21 14:13:26
DEF 03b7d0
FUUID 5ee63580-f33f-98e0-d255-bb3e7245b3bd44e0
IODev CUL_868
LASTInputDev CUL_868
MSGCNT 14427
NAME CULMAX0
NR 285
STATE CUL_868:ok
SVN 22175
TYPE CUL_MAX
addr 03b7d0
cnt 0
pairmode 0
retryCount 0
sq 0
READINGS:
2020-06-21 12:06:25 CUL_868_cmd_last_h 1
2020-06-21 12:06:25 CUL_868_credit10ms 3501
2020-06-20 21:47:30 none_retry 5
2020-06-21 14:13:26 state CUL_868:ok
sendQueue:
Attributes:
IODev CUL_868
debug 1
event-on-change-reading .*
fakeSCaddr 222222
fakeWTaddr 111111
icon cul_max
room System
Wobei ich irgendwann untersuchen muss, warum hier überhaupt credits verbraten werden, da mein CUL nur parallel zum MAXLAN lauschen soll.
a. keine Werte = keine Änderung. Das Reading wird nur angefasst wenn es etwas zum senden gibt.
b. dafür das dein CUL nur lauschen soll ist er aber rechtt aktiv , was am zum einen an den Credits sieht zum anderen am cmd_last_h Reading.
Du solltest unbedingt mal das CUL_MAX Device auf verbose 5 stellen und schauen was er meint so von sich geben zu müssen.
Ich vermute etliche unsinnigen Telegramme wenn CUL & CUL_MAX mit der gleichen MAXID arbeiten wie den Cube !
Zum reinen Mithören sollte die ID eine andere sein, denn sie muß nur beim senden stimmen und genau das willst du ja nicht.
b) lasse ich jetzt mal außen vor, da es hier ja um die credits gehen soll und nicht mein "verkorkstes" System ;). Das werde ich gesondert untersuchen und dann in einem eigenen Thread oder an anderer Stelle Fragen stellen.
Zu a):
an den beiden unterschiedlichen Logs (CULMAX und CUL) kann man aber erkennen, dass sich die credits im Laufe der Nacht direkt am CUL geändert haben.
Der CULMAX hat davon aber nichts mitbekommen. Und das über 13 Stunden lang.
Eventuell, weil er selbst da nichts zu senden hatte und deshalb nicht von sich aus mit dem CUL "gesprochen" hat?
Zitat von: jhohmann am 23 Juni 2020, 10:53:53
deshalb nicht von sich aus mit dem CUL "gesprochen" hat?
sag ich doch, das Reading ist ein Abfallprodukt da vor dem senden immer die Credits geprüft werden und bei zuwenigen das Paket in der Queue bleibt.