Grenzen von FHEM auf einem System !?

[rr725]

Ich habe das Gefühl, ich komme langsam aber sicher an die Grenzen von FEHM auf EINEM Raspi !?
Ich habe in letzter Zeit so aufgrüstet, dass mir nun vermehrt auffällt, dass mein Homematic USB Stick sehr oft "overload" anzeigt.
Div. IT-Bewegungsmelder zwar reagieren, aber FHEM das wohl nicht mitbekommt, weil es noch mit etwas anderem beschäftig ist, obwohl der Raspi von der Auslastung sich eigentlich langweilt. Evtl. blockiert Homemtaic den Empfang, b.z.w. die Abarbeitung, weil Overload ?!

Bei wieviel Devices ist eigentlich schluss auf einem System mit FHEM (Empfehlungswerte ?!)

Code Auswählen Erweitern

Fhem info:
  Release  : 5.7 FeatureLevel: 5.7
  OS       : linux
  Arch     : arm-linux-gnueabihf-thread-multi-64int
  Perl     : v5.14.2
  uniqueID : 61ffc00b82fc9358c86dd7f4192f40b5
  upTime   : 00:00:17

Defined modules:
  CUL          : 2
  CUL_FHTTK    : 3
  CUL_HM       : 43
  CUL_HOERMANN : 2
  CUL_TCM97001 : 1
  CUL_TX       : 3
  CUL_WS       : 8
  DOIF         : 82
  FHEMWEB      : 3
  FS20         : 25
  FileLog      : 19
  HMLAN        : 1
  HMS          : 2
  HUEBridge    : 1
  HUEDevice    : 7
  IT           : 28
  JeeLink      : 1
  LaCrosse     : 2
  PRESENCE     : 5
  Pushbullet   : 1
  SVG          : 14
  THRESHOLD    : 1
  Weather      : 1
  allowed      : 4
  at           : 8
  autocreate   : 1
  dewpoint     : 1
  dummy        : 18
  eventTypes   : 1
  notify       : 54
  telnet       : 1
  watchdog     : 14
  weblink      : 1
  yowsup       : 5

Defined models per module:
  CUL_FHTTK    : FHT80TF
  CUL_HM       : ActionDetector,HM-CC-RT-DN,HM-LC-SW1-BA-PCB,HM-LC-SW4-BA-PCB,HM-LC-SW4-WM
  CUL_TCM97001 : Unknown
  FS20         : FS20di,fs20st
  HUEDevice    : LLC010,LLC011,LST002
  IT           : itswitch
  JeeLink      : [LaCrosseITPlusReader.10.1e @AutoToggle 30 Seconds / 868300 kHz]

[marvin78]

Ich würde das ganze an deiner Stelle einmal mit den üblichen Mitteln apptime, perfmon und Log analysieren. Dann kannst du die "Übeltäter" finden und schauen, was du gegen das Blockieren machen kannst. Natürlich ist es so, dass man irgendwann an die Grenzen eines Systems stößt, wenn man immer weiter aufrüstet. Insbesonderer ein hoher Grad an Automatisierung fordert das System. Oft kann man jedoch duch ein paar kleine Änderungen (Events einschränken etc.) Wunder bewirken.

[rudolfkoenig]

Man kann nicht allgemein sagen, wo die Grenze auf einem bestimmten Hardware ist, es haengt sehr stark von den eingesetzten Modulen ab.

Was in deiner Liste _mir_ auffaellt:
- 82x DOIF, 54 notify und 19 FileLog bedeutet, dass jedes Event potentiell 155-mal geprueft wird. Ich wuerde versuchen die Anzahl zu reduzieren. notify/FileLog Instanzen stoeren in dieser Zaehlung dann nicht, falls der Regexp nur ein Geraet betrifft. Das erkennt man daran, dann NOTIFYDEF gesetzt ist, siehe "list .* NOTIFYDEV". DOIF beherrscht diesen Feature mWn nicht.
- die 19 Plots stoeren, falls plotfork nicht gesetzt ist, bzw. wenn es ein Rpi1 ist.

Natuerlich koennen auch andere Ursachen eine Rolle spielen, diese kann man (wie marvin78 das geschrieben hat) mit den ueblichen Mitteln analysieren. Oder man kauft besseren Hardware.

[frank]

Ich habe in letzter Zeit so aufgrüstet, dass mir nun vermehrt auffällt, dass mein Homematic USB Stick sehr oft "overload" anzeigt.

mit deinen 43 entities bei cul_hm sollte overload eigentlich nicht vorkommen.

gründe könnten sein:
1. fw von hmusb ist nicht 0.967 und/oder hmland nicht aktuell => aktualisieren.
2. konfigurationsprobleme deiner devices => get hminfo configCheck und abarbeiten.
3. ungeschickte umsetzung von temperatur-wochen-plänen bei den rt.
4. exzessive burst nutzung, besonders wenn 1., 2. und 3. zutrifft.