Genutzte Credits als reading

Begonnen von Jam2, 19 Juni 2020, 20:54:06

Vorheriges Thema - Nächstes Thema

Jam2

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ß
FHEM / Intel NUC / 8xMAX Fensterkontakte + 16xMAX Thermostate + fakewt + CUL / 20x Technoline TX29 / Hue Bridge / duefern / fbdect / mysensors / homekit
RasPi ser2net CUL
FHEM / RasPi PI / buderus logamatic / temperatursensoren

KyleK

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
FHEM on Raspberry Pi 3B+
CUL868
7x MAX! Thermostat, 8x MAX! Fensterkontakte
Conbee II + deConz, TradFri Lampen, Osram Smart+ Steckdosen

Wzut

viel zu umständlich, das Attribut debug am CULMAX Device auf 1 setzen dann hat es ein Reading CULNAME_credit10ms :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jhohmann

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.
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Wzut

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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jhohmann

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?
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Wzut

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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher