Nur weil andere Funktionen dadurch beeinträchtigt wurden habe ich gemerkt, dass das LacrosseGateway eine hohe Systemlast erzeugt wenn es im Zustand disconnected ist weil das Gateway nicht erreichbar ist.
In apptime taucht dann LaCrosseGateway_Ready sehr häufig und mit langen Laufzeiten auf.
Vielleicht kann das noch optimiert werden.
Das list ist aus dem Zustand nachdem es wieder connected war:
Internals:
Alive 2019-04-24 20:39:00
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF lacrossegateway:81
DeviceName lacrossegateway:81
FD 82
FUUID 5c432752-f33f-a4cf-4864-a9ca3349c83b027c
FVERSION 36_LaCrosseGateway.pm:0.182910/2019-01-17
NAME lgw
NR 433
NTFY_ORDER 50-lgw
PARTIAL
RAWMSG OK 22 84 187 3 222 240 0 0 3 252 47 0 1 5 226 0 0 37 230 1 0
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
lgw_MSGCNT 951
lgw_TIME 2019-04-24 20:39:49
model LaCrosseITPlusReader.Gateway.1.31
nextOpenDelay 2
settings (1=RFM69 f:868300 r:20000) + (2=RFM69 f:868300 r:9579) {IP=192.168.2.51}]
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:LaCrosse ^(\S+\s+9 |OK\sWS\s)
4:EMT7110 ^OK\sEMT7110\s
5:Level ^OK\sLS\s
6:KeyValueProtocol ^OK\sVALUES\s
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2019-04-24 20:39:49 state initialized
helper:
bm:
LaCrosseGateway_Notify:
cnt 395
dmx -1000
dtot 0
dtotcnt 0
mTS 24.04. 20:38:42
max 0.000694990158081055
tot 0.0298061370849609
mAr:
HASH(0x5845c50)
HASH(0x3b30f38)
LaCrosseGateway_Read:
cnt 1571
dmx -1000
dtot 0
dtotcnt 0
mTS 24.04. 20:25:52
max 0.139161109924316
tot 9.08447313308716
mAr:
HASH(0x5845c50)
LaCrosseGateway_Set:
cnt 3
dmx -1000
dtot 0
dtotcnt 0
mTS 24.04. 20:30:52
max 0.000214099884033203
tot 0.000422954559326172
mAr:
HASH(0x5845c50)
lgw
?
Attributes:
alias LaCrosseGateway
comment 2xRFM69: 1. EC3000 2.EMT7110
group Funk
icon tradfri_gateway@blue
initCommands 20000#1r v
room System->Hardware
timeout 60
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
verbose 1
watchdog 300
Ja, ist mir auch schon aufgefallen, war sogar schon mal dran.
Es gab aber leider nach dem Umbau von DevIo_OpenDev auf non blocking Probleme, drum hatte ich es zurückgerudert.
Habe es auf alle Fälle auf dem Radar.
Aktuelle Notlösung:
Wenn das LGW länger gewollt nicht da ist, kann man das Attribut disable auf 1 setzen, dann wird kein connect versucht und es entsteht keine Last.