Kontinuierliches Speicherwachstum von FHEM

[pte]

Ich stelle fest, dass meine FHEM Installation täglich mehr Speicher in Anspruch nimmt (täglich so um die 2...3%).
Über

Code Auswählen Erweitern

{ use Data::Serializer }
{ my $ds = Data::Serializer->new();; join("\n", map { "$_:".length($ds->serialize($defs{$_})) } sort keys %defs) }

habe ich festgestellt, das z.B. meine HM-CC-RT-DN im Weather-Channel ständig mehr Speicher beanspruchen.
Per

Code Auswählen Erweitern

{Dumper($defs{VentilEGKueche_Weather})} stelle ich weiterhin fest, dass dieser Channel im hash ein array namens "CHANGED" enthält, welches eine große Anzahl von Einträgen enthält

Code Auswählen Erweitern

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2017.07.27 16:40:07 =~=~=~=~=~=~=~=~=~=~=~=
{Dumper($defs{VentilEGKueche_Weather})}
{
  'READINGS' => {
                  'measured-temp' => {
                                       'TIME' => '2017-07-27 16:39:11',
                                       'VAL' => '20.7'
                                     },
                  'R-sign' => {
                                'TIME' => '2014-11-04 20:13:54',
                                'VAL' => 'off'
                              },
                  '.RegL_01.' => {
                                   'TIME' => '2016-03-19 11:37:39',
                                   'VAL' => '08:00 00:00'
                                 },
                  '.peerListRDate' => {
                                        'TIME' => '2016-03-19 11:37:38',
                                        'VAL' => '2016-03-19 11:37:38'
                                      },
                  'state' => {
                               'TIME' => '2017-07-27 16:39:11',
                               'VAL' => '20.7'
                             }
                },
  'DEF' => '28B89701',
  'NOTIFYDEV' => 'global',
  'helper' => {
                'tmpl' => {},
                'expert' => {
                              'tpl' => 0,
                              'def' => 1,
                              'raw' => 0,
                              'det' => 1
                            },
                'role' => {
                            'chn' => 1
                          }
              },
  'NR' => 1318,
  'CHANGEDWITHSTATE' => [],
  'NAME' => 'VentilEGKueche_Weather',
  'CFGFN' => 'EG.KU.cfg',
  'TYPE' => 'CUL_HM',
  'chanNo' => '01',
  'CHANGED' => [
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',
                 'measured-temp: 22.6',
                 '22.6',

und so weiter. in wenigen Tagen an die 10.000 Stück.

Hat jemand eine Idee, woher diese entstehen?

[pte]

scheine der Ursache näher zu kommen.
Die betroffenen Geräte (channel) haben bei mir ein "do_not_notify".
Meine Vermutung: Events werden in der Geräteinstanz in "CHANGED" zwischengespeichert und eigentlich durch den Ereignismanager von dort verarbeitet. Letzteres erfolgt bei "do_not_notify" nicht und damit füllt sich das Array.
Ob dies jetzt nur bei Homatic Geräten der Fall ist, oder auch andere Gerätetypen betrifft, habe ich noch nicht geprüft.

Kann Martin sich der Sache einmal annehmen?

[martinp876]

ich kann erst einmal nicht erkennen, das CUL_HM hier etwas anderes macht.
Es muss Aufgabe des kernal sein die events zu löschen.
Rudi muss sich
DoTrigger($$@)
in fhem.p ansehen.

Code Auswählen Erweitern

  my $max = int(@{$hash->{CHANGED}});
  return "" if(defined($attr{$dev}) && defined($attr{$dev}{do_not_notify}));
  my $now = TimeNow();

ist m.E.  falsch.

[betateilchen]

Code Auswählen Erweitern

  return "" if(defined($attr{$dev}) && defined($attr{$dev}{do_not_notify}));

Ein solches Konstrukt ist mir schon mehrfach in FHEM negativ aufgefallen.

Es ist völlig egal, welchen Wert das Attribut "do_not_notify" hat, es reicht schon seine bloße Existenz, um ggf. ein falsches Verhalten auszulösen.

Wenn ich "do_not_notify" auf 0 setze, erwarte ich, dass es abgeschaltet ist. Das sollte eigentlich für alle Attribute gelten, die als "Schalter" gedacht sind. Nur weil ein Schalter existiert, heißt das noch lange nicht, dass er immer angeschaltet ist.

[rudolfkoenig]

Habs gefixt, kurz getestet und eingecheckt, bitte um Feedback.
Und betateilchen hat auch Recht