Probleme mit tempList restore -> 100% CPU Load

[DerBodo]

Hallo zusammen,

ich wollte heute meine HM-TC-IT-WM-W-EU mit den Wochenprofilen über die tempList.cfg versorgen.
Versorgt werden sollen 6 Wandthermostate mit 2 Temperaturlisten

Beispiel für ein Thermostat

Code Auswählen Erweitern


entities:Hz.Thermostat_DG_Studio_Climate
R_P1_0_tempListSat> 11:00 15.0 22:30 20.0 24:00 15.0
R_P1_1_tempListSun> 11:00 15.0 22:30 20.0 24:00 15.0
R_P1_2_tempListMon> 19:30 15.0 22:30 20.0 24:00 15.0
R_P1_3_tempListTue> 19:30 15.0 22:30 20.0 24:00 15.0
R_P1_4_tempListWed> 19:30 15.0 22:30 20.0 24:00 15.0
R_P1_5_tempListThu> 19:30 15.0 22:30 20.0 24:00 15.0
R_P1_6_tempListFri> 15:00 15.0 22:30 20.0 24:00 15.0
R_P2_0_tempListSat> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_1_tempListSun> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_2_tempListMon> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_3_tempListTue> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_4_tempListWed> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_5_tempListThu> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_6_tempListFri> 11:00 15.0 23:00 20.0 24:00 15.0


Ein vorheriges verify sagt mir auch, dass die Config zur derzeitigen mehrere mismatches aufweist.
Wenn ich nun ein "set hm tempList restore" mache sehe ich dass die Thermostate zuerst auf CMDs Pending gehen und danach geht nichts mehr.

Im TOP sehe ich dann dass die CPU auf 100% Last geht, dann hilft nur noch der Reboot des Systems.

Was kann ich tun ?

Update wurde vorhin durchgeführt um auszuschliessen, dass ich eine alte Version einsetze.

Gruß

Bodo

[martinp876]

hm - hatte ich noch nie.
die CPU oder das OS sollte das können.
was sagt TOP? Vermutlich nur FHEM? oder zeigt es ein IO device?
was macht apptime?

[DerBodo]

Top sagt dass Fhem alles von einem CPU Core des Cubietrucks verbraucht.
Apptime suche ich später mal raus.

Wenn ich die Templisten versuche über Funktionen aus meiner MyUtils zu setzen kann ich auch nur ein Thermostat auf einmal machen, sonst rauscht mir der HMLAN sofort in den Overload.
Wenn ich die 6 Thermostate über den Zeitraum von 30 Minuten mache geht es....
Ich denke daher nicht, dass das Problem beim tempList restore sondern eher am HMLAN liegt.

Im vergangenen Winter habe ich die RT's direkt über FHEM betankt (über die MyUtils), da gab es kein Problem bei 9 RTs gleichzeitig.

Gruß

Bodo

[DerBodo]

Das Problem mit der CPULoad hat sich erledigt ich habe keine Ahnung warum....

Allerdings kann ich die Listen nicht setzen, da mir der HMLAN immer in den Overload rennt.
Die Listen scheinen bei manchen Devices anzukommen allerdings stehen diese dann auf "set" und nicht auf "verified".

Ich werde nun erstmal suchen wo der richtige Ansatzpunkt ist.

[martinp876]

Du solltest darauf achten burst nicht im attribut gesetzt zu haben. Schau dir das device dazu an. 
Ggf. Schicke rohmessages.
Falls burst genutzt wird belastet das sehr. I h empfehle, burst nur manuell zu senden, wenn notwendig
,

[DerBodo]

Hallo Martin,

ich gehe davon aus, dass du das Register "burstRx" meinst oder ?

Code Auswählen Erweitern


   Readings:
     2014-10-28 10:09:30   Activity        alive
     2014-10-27 23:04:20   CommandAccepted yes
     2014-08-17 21:23:00   D-firmware      1.1
     2014-08-17 21:23:00   D-serialNr      LEQ0418064
     2014-10-25 20:27:47   PairedTo        0x25756B
     2014-10-25 20:27:47   R-btnLock       off
     2014-10-25 20:27:47   R-burstRx       on
     2014-10-25 20:27:47   R-cyclicInfoMsg on
     2014-10-25 20:27:47   R-cyclicInfoMsgDis 0
     2014-10-25 20:27:47   R-globalBtnLock off
     2014-10-25 20:27:47   R-localResDis   off
     2014-08-17 21:23:08   R-lowBatLimitRT 2.2 V
     2014-10-25 20:27:47   R-modusBtnLock  off
     2014-10-25 20:27:47   R-pairCentral   0x25756B
     2014-10-25 20:27:47   RegL_00:        01:01 02:01 09:01 0A:25 0B:75 0C:6B 0F:00 11:00  12:16 16:00 18:00 19:00 1A:00 00:00
     2014-10-28 20:24:48   batteryLevel    2.8
     2014-10-28 20:24:48   desired-temp    22.0
     2014-10-28 20:24:48   measured-temp   21.0
     2014-10-28 19:09:17   state           CMDs_done
     2014-10-28 19:09:17   time-request    -

Attributes:
   IODev      HMLAN1
   actCycle   000:10
   actStatus  alive
   autoReadReg 0_off
   expert     2_full
   firmware   1.1
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       CUL_HM
   serialNr   LEQ0418064
   subType    thermostat
   webCmd     getConfig:clear msgEvents


Dann würde ich das mal bei allen rausnehmen.
Bei den RTs kann ich es ja eigentlich drinlassen, da ich an denen eigentlich nichts einstelle.
Hier habe ich die Climate und Weather Channels entpsrechend mit denen des TC-ITs gepeert.

Gruß

Bodo

[martinp876]

das register schaltet "aufwachen bei burst" am Device ein. Es ermöglicht das device zu wecken, wann man will. Mehr: Bei einem burst (egal von wem) wachen alle burst-sensitive devices auf und verbrauchen Batterie.

das Register würde ich immer einschalten, weil mir die Batterie hier "egal" ist.

Der Zentrale kostet dies erst einmal keine performance auf der Funkstrecke

Nun kann die Zentrale Kommandos per burst senden - das kostet dann schon. Insbesondere wenn der Empfänger nicht antwortet und der burst wiederholt wird.
Mit attr burstAccess kannst du einschalten, dass alle Kommandos sofort durch burst gesendet werden. Das solltest du ausschalten, das kostst ggf wirklich viel
mit kommando burstXmit kannst du das versenden wartender Kommandos sofort starten. das macht sinn - sollte aber nur gezielt eingesetzt werden.

schau einmal nach dem Attribut.

[DerBodo]

Hallo Martin,

Burst habe ich nun auf "0_off" gestellt bei allen.
Zum Test habe ich vorhin bei allen meinen RT-DN die Templisten mit einer Dummy Liste überschrieben (15.0 Grad den ganzen Tag).
Das hat soweit beim restore auch Funktioniert.

Wenn ich nun versuche die Listen für die TC-IT zu setzen verabschiedet sich der HMLAN quasi sofort.
Nachdem Fhem nicht mehr reagiert (100%) anbei ein tail des Fhem Logs.

Code Auswählen Erweitern

2014.11.03 21:52:52 1: HMLAN_Parse: HMLAN1 new condition init
2014.11.03 21:53:06 1: HMLAN_Parse: HMLAN1 new condition ok
2014.11.03 21:53:58 1: 192.168.200.7:1000 disconnected, waiting to reappear (HMLAN1)
2014.11.03 21:53:58 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.11.03 21:53:58 1: 192.168.200.7:1000 reappeared (HMLAN1)
2014.11.03 21:53:58 1: HMLAN_Parse: HMLAN1 new condition init
2014.11.03 21:57:30 1: FBDECT: unknown message type 00
2014.11.03 21:57:30 1: FBDECT: unknown message type 00
2014.11.03 21:57:30 1: FBAHA: resetting buffer as we are out of sync (0)
2014.11.03 22:02:24 1: FBAHA: resetting buffer as we are out of sync (0)
2014.11.03 22:12:11 1: HMLAN_Parse: HMLAN1 new condition ok
2014.11.03 22:12:11 1: FBAHA: resetting buffer as we are out of sync (0)


Was kann ich noch tun ? Es wäre ja kein Problem wenn die Listen nur langsam gesetzt werden...

Gruß

Bodo

[martinp876]

ist das wirklich das log der rohmessages?
es kommt ein init ohne dass etwas anderes vorher gekommen ist?

kannst du das verifizieren?

[DerBodo]

Loglevel ist einfach das normale FHEM Log mit Verbose 3.
Rawmessages suche ich mal wie ich die anfertigen kann. Ein einfaches global verbose 5, bringt hier zuviel von den anderen sachen mit rein....

Edit: Anleitung gefunden... Rawmessages mache ich später noch und hänge sie an.

[martinp876]

Schau in wiki hm sniffen

[DerBodo]

Hallo Martin,

ich habe heute ein tempList restore angestossen und die Messages aufgezeichnet.
Auffällig sind die vielen Delay Meldungen.

Die Deives dahinter sind die Wandthermostate

Code Auswählen Erweitern


2B317D Hz.Thermostat_OG_Gaestezimmer
2B3180 Hz.Thermostat_EG_Wohnzimmer
2B3156 Hz.Thermostat_OG_Bad
286A2B Hz.Thermostat_DG_Studio
286CD3 Hz.Thermostat_UG_Keller_Flur
2B317B Hz.Thermostat_OG_Schlafzimmer
286CDB Hz.Thermostat_EG_Flur
286C99 Hz.Thermostat_UG_Keller_2
2B3195 Hz.Thermostat_UG_Keller_1


Irgendwas scheine ich bei der Einrichtung gehörig verbockt zu haben ....

Gruß

Bodo

[martinp876]

stelle am HMLAN
attr xxx hmLanQlen 1_min
ein - passeirt es immer noch?

[DerBodo]

War bereits so gesetzt.
Entweder ist es der Default Wert beim Define oder ich hatte damals anhand eines Wiki/Forum Artikels es gleich so gemacht.

Was mir noch eingefallen ist, über das Jahr sind ein paar HM Devices dazu gekommen.
Könnte hier die allgemeine Menge ein Problem sein ?

Derzeit sind im Einsatz:

2x Außentemp Sensoren
11x RT-DN
9x TC-IT
4x HM-ES-PMSw1-Pl
4x Fensterkontakte (1x SC2, 3x SCO)
1x Feuchtigkeitsmelder
1x HM-SCI-3-FM

Verteilt über 4 Etagen mit einem HMLAN

Gruß

Bodo

[franky08]

Hallo, an der Anzahl der devices liegt es mit Sicherheit nicht. Ich habe auf meiner Hauptinstanz 143 devices laufen und über 2 F2F sind noch zwei fhem Instanzen mit der Hauptinstanz verbunden, dass läuft völlig problemlos.

VG
Frank