HM-Overload strategie, conditional Burst (RT, TC und andere) sowie daten-update

[unimatrix]

was meinst du denn genau mit Reboot? den HMLAN stromlos zu machen?

oder wird bei dir FHEM neu gestartet - das würde ja genau dazu führen dass eine Menge Funkverkehr entsteht, da ja - je nach Setting von AutoReadReg alle Devices dann abgefragt werden.

Ich habe bei mir ca. 40 HM Devices ...ein FHEM-Start mit AutoReadREg auf 4 bei allen Devices verbraucht ca. 40% des HMLAN-Kontingents. Wenn man an was bastelt und aus welchen Gründen auch immer FHEM in kurzer Zeit mehrfach neu startet geht es dann natürlich nicht weiter. Seitdem ich aber den HMLAN automatisch kurz vom Strom trenne, gibts das Problem nicht mehr. Das Trennen ist auch nicht ohne Nachteile, aber für mich so besser.

Bei einer bestimmten Größe braucht man ggf. trotzdem 2 Devices.

Sendet denn HM auf dem zweiten IODevice automatisch, wenn das 1. im Overload ist oder nicht connected ist?

[Groby]

Mit reboot meine ich fhem "shutdown restart".

Ich habe z. Zt. 56 HM devices mit nur 1 HMLan. Darunter 11 HK Thermostate, 1 Wetterstation sowie Bewegungsmelder, Feuchtigkeitsmesser, Rauchmelder und Fenstergriffe. Die Frage ist braucht man denn den "burst-modus" oder jeden "getConfig"?

Bei mir schalten Fensterkontakte die HK's in den WindowOpen Modus. Ich verwende autoReadReg = 4_ReqStatus für die Switches und 8_ReqState für die Rauchmelder wo ich wirklich wissen will wie der Status ist. Alles andere kann m.E. warten und hat deswegen nur autoReadReg = 0_off. Bei Bedarf frage ich "getConfig" einfach selber ab...

Deswegen denke ich ein Highload nach diversen fhem "shutdown restart"s innerhalb kürzester Zeit völlig in Ordnung und ist sollte eher die Ausnahme sein...

Ich habe gerade noch einen "shutdown restart" bei msgLoadEst: 1hour:0% mit folgendem Ergebnis gemacht:

Code Auswählen Erweitern


    IODevs:HML:opened pending=0 condition:ok
    msgLoadEst: 1hour:9% 10min steps: 9/0/0/0/0/0


PS: Overload kenn ich gar nicht!!!

[martinp876]

gute Frage, was eine größere Installation ist.
Wenn du kein overload bekommst ist das ok.
Nach reboot von FHEM kann es sein, dass einige Stati abgefragt werden. Das automatische Abfragen wird verzögert, sollte highload "erscheinen".
Nach reboot kann es demnach zu erhöhter lost kommen

[Depechem]

Hallo,

ich habe mir hier alle Nachrichten durchgelesen.
Ich habe seit gestern ein Problem mit dem HMUSB und cond:ERROR-Overload

Ich besitze im Moment nur 8 HM Aktoren und 2 HM Fernbedienungen(HM-RC-Sec4-2). Von einem Tag zum anderen hat der HMUSB nun fast durchgänging Overload...
Diese habe ich nach lesen dieser Nachrichten bei allen HM gesetzt(autoReadReg 0_off; burstAccess 0_off) > keine Änderung

An was kann dieses Problem liegen? Ich kann ja somit keinerlei Aktoren mehr Schalten wenn Overload ist.
Ich bin noch relativer Anfänger mit FHEM und HM.

Ich hoffe mir kann irgendwer weiterhelfen
Viele Grüße
Thomas

[Depechem]

Hie rnoch meine LOG von der letzten Zeit des OVERLOAD

[martinp876]

A) rohmessages loggen
B) hminfo protevents ansehen . ggf ein clear machen um besser zählen zu können. Dann nachsehen, wer etwas bekommt

C) keine Bilder sondern logs schicken

[frank]

der hmusb benötigt fw 0.967 und einen aktuellen hmland, damit die aktuelle load ermittelt werden kann.

[Depechem]

der hmusb benötigt fw 0.967 und einen aktuellen hmland, damit die aktuelle load ermittelt werden kann.

so den HMUSB habe ich nun auf die aktuelle FW 0.967 gebracht.
und HMLAND müsste mit Version (hmland 0.102-git) nun auch aktuell sein oder?

Wo wird nun "die aktuelle load ermittelt" > wo erkenne ich dies und was muss ich damit machen?

A) rohmessages loggen

bedeutet dies ich mache ein FileLog vom HMUSB?
define FileLog_HMUSB FileLog ./log/HMUSB-%Y.log HMUSB
attr FileLog_HMUSB logtype text
attr FileLog_HMUSB room HMUSB

da wird im Moment immer nur "2016-01-04_19:05:20 HMUSB loadLvl: low" angezeigt.
Oder was meinst du damit?

Vielen Dank für eure Infos
Gruß Thomas

[martinp876]

Siehe wiki hm sniffen

[Depechem]

Siehe wiki hm sniffen

Danke habe ich getan.
Ich habe einen Verdacht:
Ich habe vor ein paar Tagen einen HM Batterie-Aktor angelernt(HM-LC-SW1-BA-PCB) nach dem anlernen erst mal wieder stromlos in die Kiste gepackt. autoReadReg war bei ihm auf 4_reqStatus
Ich habe ihn gerade wieder(ohne ihm Strom zu geben) von 0_reqStatus auf 4_reqStatus gesetzt. Nun erscheinen im Log mehrfach Nachrichten wie:

2016.01.04 19:51:11.426 0: HMLAN_Parse: HMUSB V:03C7 sNo:MEQ0232631 d:372DDE O:372DDE t:004D1063 IDcnt:0008 L:18 %
2016.01.04 19:51:13.382 0: HMLAN_Parse: HMUSB R:R0DFA93E3 stat:0008 t:00000000 d:FF r:7FFF     m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:13.382 0: HMLAN_Parse: HMUSB no ACK from 39224D
2016.01.04 19:51:16.099 0: HMLAN_Send:  HMUSB S:S0DFAA654 stat:  00 t:00000000 d:01 r:0DFAA654 m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:17.923 0: HMLAN_Parse: HMUSB R:R0DFAA654 stat:0008 t:00000000 d:FF r:7FFF     m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:17.924 0: HMLAN_Parse: HMUSB no ACK from 39224D
2016.01.04 19:51:21.866 0: HMLAN_Send:  HMUSB S:S0DFABCDB stat:  00 t:00000000 d:01 r:0DFABCDB m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:23.683 0: HMLAN_Parse: HMUSB R:R0DFABCDB stat:0008 t:00000000 d:FF r:7FFF     m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:23.684 0: HMLAN_Parse: HMUSB no ACK from 39224D
2016.01.04 19:51:26.627 0: HMLAN_Send:  HMUSB S:S0DFACF75 stat:  00 t:00000000 d:01 r:0DFACF75 m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:28.452 0: HMLAN_Parse: HMUSB R:R0DFACF75 stat:0008 t:00000000 d:FF r:7FFF     m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:28.453 0: HMLAN_Parse: HMUSB no ACK from 39224D
2016.01.04 19:51:31.296 0: HMLAN_Send:  HMUSB S:S0DFAE1B1 stat:  00 t:00000000 d:01 r:0DFAE1B1 m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:33.125 0: HMLAN_Parse: HMUSB R:R0DFAE1B1 stat:0008 t:00000000 d:FF r:7FFF     m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:33.126 0: HMLAN_Parse: HMUSB no ACK from 39224D

könnte es daran gelegen haben sowie die ältere HMUSB FW.!?
Bis jetzt läuft der HMUSBB noch.

Sollte ich meine HM-Geräte wieder auf 4_reqStatus setzten oder alle dauerhaft auf 0_reqStatus lassen?

[martinp876]

meine Devices stehen alle auf Status 5. Ich will immer und automatisch korrekte Daten.

Burst Devices kann/sollte man auf msgRepeat 0 setzen. Ist das Device nicht und wird getestet sendet FHEM einen Burst - HMLAN wiederholt 1-mal.
Das kann man 100 mal in 1 h machen.
Wenn du nun msgRepeat auf 3 stehen hast geht es nur noch 30 mal. Das kann schon problematisch sein.
Aber ich empfehle hier

get hm protoEvents

Das sollte man sowieso im Auge behalten. (alternativ im Status des hminfo - hier unbedingt autoUpdate aktivieren)

[Depechem]

meine Devices stehen alle auf Status 5. Ich will immer und automatisch korrekte Daten.

Burst Devices kann/sollte man auf msgRepeat 0 setzen. Ist das Device nicht und wird getestet sendet FHEM einen Burst - HMLAN wiederholt 1-mal.
Das kann man 100 mal in 1 h machen.
Wenn du nun msgRepeat auf 3 stehen hast geht es nur noch 30 mal. Das kann schon problematisch sein.

Eine Frage noch meine Fernbedienungen HM-RC-4-2 sollte ich nun auch auf
autoReadReg 5_off
burstAccess 0_off < deleteattr
msgRepeat 0
setzen!?
oder anders?

[martinp876]

Die mache kein burst. Das burst hatte ist demnach egal. Leider kann man Attribute nicht einschränken.
Msgrepeat ist nicht wichtig. Fhem stoppt wenn es nicht klappt.
Gesendet wird in diesem Fall nach einem press.
Ein overload ist nicht zu erwarte da ist vie Luft.
Aber prüfen es doch einfach