Hallo zusammen,
ich habe seit geraumer Zeit folgendes Problem: Mein HMLAN Adapter geht ständig in den STATE=overload.
Meine FHEM ist auf dem neuesten Stand und auch die firmware auf dem HMLAN wurde letztens auf 0.964 geupdated. Ich habe etwa 9 Raumthermostate vom Typ HM-TC-IT-WM-W-EU angebunden, die - soweit ich das aus den Logs beurteilen kann - den Löwenanteil des Funkverkehrs verursachen.
Jetzt meine Fragen: Was kann ich tun, damit die Thermostate nicht so oft ihre Readings verschicken? Oder liegt das am Setup des ActionDetectors? Im Logfile sehe ich sehr oft Messages mit einer 000000 (ID des ActionDetectors):
zum Beispiel: HMLAN_Parse: HMLAN1 R:E2D5E70 stat:0000 t:02AE1C00 d:FF r:FFB7 m:3B 865A 2D5E70 000000 A8DD45
Meine fhem.cfg sieht wie folgt aus:
# HMLAN:
# --------------------
define HMLAN1 HMLAN [theIP]
attr HMLAN1 hmId [theID]
attr HMLAN1 hmKey [theKey]
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 room HWRaum
attr HMLAN1 group Hardware
attr HMLAN1 alias HM Lan Adapter
attr HMLAN1 icon hm_lan
attr HMLAN1 devStateIcon opened:rc_GREEN .*:rc_RED
attr HMLAN1 wdTimer 25
attr HMLAN1 logIDs all,sys
# ActionDetector
# --------------------
define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 001:00
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector
attr ActionDetector room HWRaum
attr ActionDetector group System
attr ActionDetector alias Action Detector
# Beispiel für einen Raumfühler
# -----------------------
define Raumfuehler CUL_HM [theID]
attr Raumfuehler .devInfo 03FFFF
attr Raumfuehler .stc 58
attr Raumfuehler IODev HMLAN1
attr Raumfuehler actCycle 001:00
attr Raumfuehler actStatus alive
attr Raumfuehler autoReadReg 4_reqStatus
attr Raumfuehler burstAccess 0_off
attr Raumfuehler expert 2_full
attr Raumfuehler firmware 1.0
attr Raumfuehler model HM-TC-IT-WM-W-EU
attr Raumfuehler msgRepeat 1
attr Raumfuehler serialNr [theSerialNo]
attr Raumfuehler subType thermostat
attr Raumfuehler webCmd getConfig:clear msgEvents
attr Raumfuehler room [theRoom]
attr Raumfuehler group Heizung
attr Raumfuehler alias Raumfühler
attr Raumfuehler icon temperature_humidity
attr Raumfuehler verbose 4
define Raumfuehler.Weather CUL_HM [theID]01
attr Raumfuehler.Weather model HM-TC-IT-WM-W-EU
attr Raumfuehler.Weather peerIDs 00000000,
attr Raumfuehler.Weather room hidden
define Raumfuehler.Climate CUL_HM [theID]02
attr Raumfuehler.Climate event-on-update-reading measured-temp,humidity,desired-temp
attr Raumfuehler.Climate model HM-TC-IT-WM-W-EU
attr Raumfuehler.Climate peerIDs 00000000,
attr Raumfuehler.Climate room hidden
define Raumfuehler.WindowRec CUL_HM [theID]03
attr Raumfuehler.WindowRec model HM-TC-IT-WM-W-EU
attr Raumfuehler.WindowRec peerIDs 00000000,
attr Raumfuehler.WindowRec room hidden
attr Raumfuehler.WindowRec stateFormat last:trigLast
define Raumfuehler.remote CUL_HM [theID]06
attr Raumfuehler.remote model HM-TC-IT-WM-W-EU
attr Raumfuehler.remote peerIDs 00000000,
attr Raumfuehler.remote room hidden
define Raumfuehler.SwitchTr CUL_HM [theID]07
attr Raumfuehler.SwitchTr model HM-TC-IT-WM-W-EU
attr Raumfuehler.SwitchTr peerIDs 00000000,
attr Raumfuehler.SwitchTr room hidden
# Notify wenn Temperaturen/Luftfeuchte sich ändern
# ----------------------------------------------------
define RaumNotify Raumfuehler.Climate:((measured|desired)-temp).* { roomClimateControl(\"theRoom\", \$NAME.\":\".\$EVENT);; }
attr RaumNotify room [theRoom]
attr RaumNotify group Heizung
attr RaumNotify alias EZR-Programm
attr RaumNotify icon edit_settings
Vielen Dank!
Sven
ZitatIch habe etwa 9 Raumthermostate vom Typ HM-TC-IT-WM-W-EU angebunden, die - soweit ich das aus den Logs beurteilen kann - den Löwenanteil des Funkverkehrs verursachen.
overload bekommst du nur, wenn der hmlan zuviel sendet, also deine zentrale. ohne logs kann das keiner erkennen. mit get hminfo msgStat/protoEvents siehst du vielleicht an wen wann zuviel gesendet wird.
was macht das notify?
Hallo Frank, danke für die rasche Antwort.
Habe mal get HMInfo MsgStat gemacht und folgendes erhalten:
|-------------------------------------------------------------------->*
receive hour :| 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23
HMLAN1 :|489|433|441|429|436|435|596|711|586|495|472|435|449|428|456|432|454|396|561|536|475|420|472|440
send hour :| 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23
HMLAN1 :|128| 69| 69| 70| 59| 65|104|109| 67|103| 76| 72| 68| 72| 72| 71| 83| 92| 85| 93| 70| 64| 86| 67
|-------------------------------------------------------------------->*
receive day :| Mon| Tue| Wed| Thu| Fri| Sat| Sun|# 24h
HMLAN1 :|11017| 0| 0| 0| 0|4636|11052|#11477
send day :| Mon| Tue| Wed| Thu| Fri| Sat| Sun|# 24h
HMLAN1 :|2011| 0| 0| 0| 0| 969|1908|#1914
Daran kann man sehen, dass mein HMLAN sehr viel mehr Messages empfängt (~460/h) als aussendet (~80/h). Das heißt ich sollte die ausgehenden Messages reduzieren?
Um deine Frage zu beantworten: Der Notify ist dazu da, die events "event-on-update-reading measured-temp,humidity,desired-temp" des Climate Channels des Raumfühlers zu "catchen" und dann eine Funktion aufzurufen (roomClimateControl), in welcher:
- mehrere Dummys via Value() abgefragt werden und via "fhem('set ...')" gesetzt werden
- die aktuelle Temp (measured-temp) des Fühlers über ReadingsValue() abgefragt wird
- der aktuelle Sollwert (desired-temp) des Fühlers über ReadingsValue() abgefragt wird
- der aktuelle Wert des Fußbodenheizungsventils via Value() abgefragt wird
- das Fußbodenheizungsventil - nur wenn nötig - entweder auf oder zu gemacht wird via "fhem('set ... on/off')"
Diese Funktion wird also doch sehr häufig aufgerufen (bei 9 Thermostaten so ein paar mal pro Minute).
Im Anhang findest du auch noch den aktuellen FHEM log (letzte paar Minuten). 26EBE3 ist die HMId von HMLAN1.
Vielen Dank!
ZitatMessages empfängt
ist kein Problem,
die 1% Regel bezieht sich nur auf das senden vom HMLAN
mach doch event on change an jeden thermostat
Hallo Hary,
du meinst "event-on-change-reading" anstatt "event-on-update-reading". Ja das wäre eine Möglichkeit. Ich probier's mal aus.
Aber Frank hat mich auf eine andere Idee gebracht. Was genau macht eigentlich die Funktion: ReadingsVal()? Schick man damit etwa auch einen Command via HMLAN zum Fühler? Ich bin immer davon ausgegangen, dass diese Funktion nur den letzten Wert im FHEM-Memory abruft. Und nicht extra ein neues Reading am Gerät anfordert.
Sven
2015.11.17 17:26:52.477 3: CUL_HM set Gaestebad.Beleuchtung.Decke statusRequest
2015.11.17 17:26:52.481 0: HMLAN_Send: HMLAN1 S:S16453410 stat: 00 t:00000000 d:01 r:16453410 m:78 A001 26EBE3 500000 010E
hier gibt es bestimmt probleme. was sind das für devices mit den id's 4/5/6/700000? wer fordert den statusrequest? poste mal ein list.
ausserdem gibt es 2 devices (2D5E51, 2D5E70), von den fhem was will, die aber nicht antworten. nicht gepaired? was ergibt hminfo configcheck? edit: jedes vergebliche senden "kostet" 3%. ist hier ausserdem burst im spiel?
readingsval macht keine probleme.
Hallo,
bin zwar nicht sicher, aber auf den ersten Blick springt mir
attr Raumfuehler actCycle 001:00
ins Auge. Ich habe das Attribut nicht gesetzt, finde auch auf die schnelle nirgends etwas , wie die Formatierung ist (hhh:mm oder mmm:ss...), aber im Zweifel könnte man es als 1 mal pro Minute lesen.
Einen versuch wär's ja mal Wert, das Attribut zu löschen.
Gruß
Frank
Es ist hhh:mm. Der Actiondetector erwartet in der angegebenen Zeit ein Lebenszeichen vom Device, ansonsten wird es auf dead gesetzt.
Vielen Dank für die vielen Antworten!
Hary: Das Umstellen von event-on-update-reading auf event-on-changed-reading hat schon mal viel gebracht. Seit gestern Abend habe ich keinen overload mehr im HMLAN gesehen. Auch die msgStat scheinen dies (zumindest auf den ersten Blick) zu bestätigen (siehe ab 18 Uhr bis heute 8 Uhr):
|------------------------------------>*
receive hour :| 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23
HMLAN1 :|450|452|430|427|427|457|555|667|635|133|472|435|449|428|456|432|454|696|645|625|467|463|453|430
send hour :| 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23
HMLAN1 :| 54| 33| 33| 34| 34| 41| 59| 94| 65| 38| 76| 72| 68| 72| 72| 71| 83|127| 85| 72| 54| 49| 57| 37
|------------------------------------>*
receive day :| Mon| Tue| Wed| Thu| Fri| Sat| Sun|# 24h
HMLAN1 :|11017|11956| 0| 0| 0|4636|11052|#11538
send day :| Mon| Tue| Wed| Thu| Fri| Sat| Sun|# 24h
HMLAN1 :|2011|1838| 0| 0| 0| 969|1908|#1480
Frank: Ich werde mir mal die 2 Devices anschauen, die nicht acken. Wenn das tatsächlich immer 3% Traffic ausmacht, ist das natürlich schon ein Problem für die HMLAN. Die 500000/600000/700000 sind noch nicht gepairte (oder noch nicht existente) Devices von denen ich noch keine HMId habe. War bisher einfach zu faul, die anzubinden. Werde nochmal berichten, wenn diese beiden Probleme behoben sind und dann auch nochmal die neuen Traffikzahlen hier posten.
stromer-12 und Nepomuk: Ja, das Format für den actCycle ist hhh:mm, das heißt, dass bei mir der Action Detector von jedem Raumfühler einmal die Stunde eine Rückmeldung braucht, um das Device nicht auf "dead" zu setzen. Das müsste so ok sein und dürfte keinen besonderen Traffic verursachen.
Grüße
Sven
Schon einmal
Set hm protevents
Angesehen?