FHEM Forum

Hallo liebes Forum,

ich habe seit dem 1.8.2014 massive Fehlermeldungen im Logfile. Das File ist heute schon auf 437MB angewachsen und der FHEM Server auf meiner FB 7390 reagiert, wohl deswegen auch nicht mehr gut.
Was kann ich tun, bzw. wo liegt das Problem? Ich bitte um Hilfe.

Auszug aus dem Log:

Use of uninitialized value $hn in string ne at fhem.pl line 1627.
Use of uninitialized value in pattern match (m//) at fhem.pl line 1628.
Use of uninitialized value in pattern match (m//) at fhem.pl line 1628.
Use of uninitialized value in pattern match (m//) at fhem.pl line 1628.
Use of uninitialized value in pattern match (m//) at fhem.pl line 1628.
Use of uninitialized value in pattern match (m//) at fhem.pl line 1628.
Use of uninitialized value in numeric eq (==) at ./FHEM/10_CUL_HM.pm line 6530.
Use of uninitialized value $hn in hash element at fhem.pl line 1612.
Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 1622.
Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 1622.

LG Andy

Hallo,

Zitatund der FHEM Server auf meiner FB 7390 reagiert,

Und dann kommt der Beitrag in den Homematic-Bereich  ???
Aber sorry das ich dir bei deiner Frage nicht helfen kann ausser - versuch mal einen restart der FB.

Grüße

Falsch dies der falsche Ort ist, dann bitte verschieben.

Ich habe schon einen Restart der FB gemacht, da die FHEM Webseite nicht mehr reagiert hat. Das hat leider nichts geholfen. Das Log vom Juli sieht total sauber aus und hat diese Einträge nicht.

du solltest unbedingt speicher freimachen, sonst steht fhem bald ganz still. schmeiss das log runter, dann wird ein neues file angelegt.  du hast doch sicherlich auch noch mehr logs.

gruss frank

Ein speicherproblem - das klingt plausibel, wie verhält sich fhem bzw das betriebssystem diesbezüglich?

Nehmen wir mal an - während des Monats läuft das logfile so voll das der Speicherplatz des Systems beim endgültigem speichern und neu File generierung nicht mehr ausreicht...

So könnten die Meldungen die oft vorkommen beim Monatswechsel doch entstehen, oder?

Ein Neustart des kompletten Systems sollte dir auch helfen - das monatswechsel problem ist bekannt aber bis jetzt noch nicht identifiziert...

Hallo,

Zitat von: AndyOne am 06 August 2014, 19:27:53
Falsch dies der falsche Ort ist, dann bitte verschieben.

Ja ist es.
Die FritzBox hat nichts mit Homematic zu tun - was eigentlich logisch sein müsste zumal es im Forum einen eigenen Homematic-Bereich gibt (na wofür der wohl gut sein könnte  ;D ).

Leider schreibst du aber auch nicht ob du die AVM-Labor verwendest oder die fhem.de-Version.
Welche FHEM_Version du hast und welche Geräte du verwendest.
Daher erstmal das
http://forum.fhem.de/index.php/topic,16311.0.html (http://forum.fhem.de/index.php/topic,16311.0.html)
durchlesen - sonst kann das noch in eine Rateschlacht ausarten.
Danke.

Grüße
P.S.: @martin
Kannst du den Beitrag bitte in den FritzBox-Bereich verschieben - danke.

Edith: Beitrag bearbeitet da der Zeile mit CUL_HM.pm in der Meldung zuwenig Beachtung geschenkt - aber ich lern gern dazu  :-X

Ich hatte bis gestern eine sehr ähnliche Fehlermeldung im Log. Ursache war meines Erachtens der fehlende Eintrag IOgrp bei der VCCU. Nach
attr vccu IOgrp CUL
lief alles wie gewohnt ohne Fehlermeldung.

Hast du ggf. auch eine VCCU am Laufen, Andy?

ZitatUrsache war meines Erachtens der fehlende Eintrag IOgrp bei der VCCU.

achtung! völlig falsch.
dieses attribut gehört an die devices und eingetragen wird die vccu.

eventuell meintest du attr IOList. hier werden die io eingetragen.

Also bei mir wird über FHEMWEB das Attribut IOgrp im Drop Down für die vccu angezeigt, nicht aber beim CUL. Und seit ich das Attribut gesetzt habe ist auch die Fehlermeldung weg. IOList ist aber ebenfalls als Attribut für die vcci gesetzt.
IOList CUL

siehe commandref:

ZitatIOgrp
can be given to devices and shall point to a virtual CCU. As a consequence the CCU will take care of the assignment to the best suitable IO. It is necessary that a virtual CCU is defined and all relevant IO devices are assigned to it. Upon sending the CCU will check which IO is operational and has the best RSSI performance for this device.
Optional a prefered IO can be added. In case this IO is operational it willge selected regardless of rssi values.
Example:

    attr myDevice1 IOgrp vccu
    attr myDevice2 IOgrp vccu:prefIO

eine virtuelle ccu verwaltet die io, die du ihr mit attr IOList zuordnest. jetzt kannst du einem device, zb einem thermostat, statt wie bisher mit attr IODev nur ein io zuzuweisen, eine ganze gruppe io mit dem attr IOgrp zuordnen. die gruppe wird durch die vccu representiert. IOgrp ersetzt IODev, wenn es vorhanden ist.

gruss frank

Hallo Frank,


vielen Dank für die Erklärung, das bringt mir das Thema vccu wieder ein Stück näher ;-)


Ich habe "meine" Fehlermeldungen noch mal aus dem archivierten Log geholt:

Zitat
Use of uninitialized value $hn in hash element at fhem.pl line 1615.
Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 1625.
Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 1625.
Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 1625.
Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 1625.
Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 1625.
Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 1625.
Use of uninitialized value $hn in string ne at fhem.pl line 1630.
Use of uninitialized value in pattern match (m//) at fhem.pl line 1631.
Use of uninitialized value in pattern match (m//) at fhem.pl line 1631.
Use of uninitialized value in pattern match (m//) at fhem.pl line 1631.
Use of uninitialized value in pattern match (m//) at fhem.pl line 1631.
Use of uninitialized value in pattern match (m//) at fhem.pl line 1631.
Use of uninitialized value in numeric eq (==) at ./FHEM/10_CUL_HM.pm line 6762.
Use of uninitialized value $ioCCU in hash element at ./FHEM/10_CUL_HM.pm line 6768.

Durch Zuweisung des Attributes IOgrp zur vccu waren diese Meldungen dann aber definitiv weg. Ich muss meinen vorherigen Eintrag aber korrigieren:
attr vccu IOgrp vccu:CUL
brachte dann die Abhilfe.


Viele Grüße,
Christoph

ah..
hattest du der vccu eventuell virtuelle channel definiert und kein attr IODev festgelegt?
aber dennoch eine seltsame angelegenheit. du ordnest einer gruppe io (vccu) sich selbst (vorzugsweise cul) zu. die kennen sich wohl nicht.  8)

ggf ein list der vccu schicken

Der Tip mit dem Löschen des Logs war erfolgreich, nach einem Restart tauchen diese Fehler nicht mehr auf und es funktioniert wieder alles normal.
Ich hoffe nur, dass das zum nächsten 1. nicht wieder passiert.
Danke Euch für die rege Teilnahme.

Andy