Hallo zusammen,
ich nutze seit einiger Zeit FHEM (Ver. 5.8 ) mit etlichen Homematic-Komponenten zusammen. Die Homematic-Komponenten sind über ein HMLAN und ein HMUART an FHEM angebunden. FHEM läuft bei mir neben ein paar anderen Dingen auf einem Raspberry PI 3. Die Konfiguration ist mittels configDB in einer MySQL-Datenbank gespeichert. Ich habe einen zweiten Raspberry PI 3 auf dem ebenfalls FHEM (auch mit configDB, alles möglichst gleich) läuft und ich Sachen ausprobiere bevor diese neuen Dinge mein "produktives System" zerschießen...
In der Logdatei des Hauptsystems ist mir jetzt aufgefallen, dass dort Meldungen auftauchen, die ich nicht "einsortieren" kann.
Hier ein Auszug aus meiner Logdatei direkt nach einem Neustart
2018.02.18 14:17:36 0: Featurelevel: 5.8
2018.02.18 14:17:36 0: Server started with 218 defined entities (fhem.pl:16204/2018-02-17 perl:5.024001 os:linux user:fhem pid:4240)
2018.02.18 14:17:37 3: telnetForBlockingFn_1518959857.07168: port 40151 opened
2018.02.18 14:17:37 1: HMLAN_Parse: HMLAN new condition ok
...
[StatusRequestanfragen von Rauchmeldern rausgekürzt]
...
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Die Meldung "Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.":
- Wo kommt das her?
- Warum ist kein Zeitstempel dabei?
- Wie kann ich das abstellen?
Die motd-Meldung bei diesem System nach einem Neustart ist "1" (s. angehängten Screenshot). Hängt das evtl. zusammen? Wo kommt die motd=1 her?
Die Suche liefert zu "Dateideskriptor" leider keine passenden Treffer. Deshalb habe ich diesen Thread gestartet. Für jeden Hinweis bedanke ich mich im Voraus.
Viele Grüße,
matrois.
Suche nach der Ausgabe doch mal in den FHEM Dateien.
Hallo CoolTux,
danke für Deinen Tipp.
Was genau meinst Du mit "nach der Ausgabe"? Mir fällt auf, dass ich vergaß zu erwähnen, dass die Meldungen nach jedem Start im Log auftauchen. Also kann ich quasi sofort nach dem Start von FHEM suchen, oder meintest Du etwas anderes?
Ich weiß allerdings nicht wo und nach was ich suchen soll. Im FHEM Verzeichnis finde ich keinen Dateideskriptor...
Viele Grüße,
matrois.
Vergiss was ich gesagt habe. Die Meldung kommt nicht aus FHEM sondern vom Linuxsystem. Gib die Meldung mal bei Google ein dann findest Du so einiges.
Hat Dein FHEM Server ein X-Window System aktiv?
@CoolTux:
Spricht es nicht dagegen, dass es vom Linuxsystem kommt, dass es in der FHEM Logdatei ist?
Wenn Du diese Suchergebnisse meinst:
https://www.google.de/search?q=%22Dateideskriptor%2C+der+auf+die+Konsole+verweist%2C+konnte+nicht+gefunden+werden.%22&oq=%22&aqs=chrome.0.69i59j69i57j69i59.1599j0j7&sourceid=chrome&ie=UTF-8 (https://www.google.de/search?q=%22Dateideskriptor%2C+der+auf+die+Konsole+verweist%2C+konnte+nicht+gefunden+werden.%22&oq=%22&aqs=chrome.0.69i59j69i57j69i59.1599j0j7&sourceid=chrome&ie=UTF-8)
Die hatte ich auch schon gesehen, aber es ist kein X-Window System aktiv und auch keins installiert. Zugriff auf den Raspi habe ich nur über ssh (headless Betrieb auf der Basis von Raspbian Lite). Daran kann es leider auch nicht liegen.
Nicht unbedingt. Die Fehlermeldung kommt nicht von FHEM kann aber FHEM betreffen. Ich meine damit das die Meldung nicht aktiv als Logausgabe in einem Modul steht.
Gibt es eine Möglichkeit herauszufinden von welchem Modul die Meldung kommt? Bei einer Logmeldung wie
2018.02.18 14:17:37 3: CUL_HM set sd_buero statusRequest
ist es klar von welchem Modul die Meldung kommt und durch den Timestamp ist auch klar wann die Meldung entstand. Die "Dateideskriptor"-Meldungen stehen genau so wie oben (ohne Timestamp und ohne weitere Hinweise im FHEM-Log).
Wie gesagt die Meldung kommt nicht aus einem Modul heraus, es kann aber sein das ein Modul diese Meldung welche vom System kommt aus löst. Leider weiß ich nicht wie man das raus finden kann.
Ich probiere auch mit apptime und habe dabei bemerkt, dass die Meldung "Dateideskriptor" nicht direkt nach dem Start kommt. Ich habe nach einem Neustart als erstes recht zügig den Befehl "apptime" abgesetzt. Danach habe ich dieses Log:
2018.02.18 20:55:10 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 42.
2018.02.18 20:55:10 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 151.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Apptime hat auch noch Fehlermeldungen übrig...
update check sagt
fhem
nothing to do...
fhemtabletui
nothing to do...
Wann hast Du Update genacht? Heute im laufe des Tages oder gestern?
Mach mal bitte einen kompletten neustart des Servers.
Kann er nicht mit stacktrace schauen, wer die Meldung verursacht?
Ich glaube ich habe die Lösung gefunden. HMUART greift auf /dev/ttyAMA0 zu, welches man als Dateideskriptor bezeichnen kann. Die Berechtigungen von ttyAMA0 sind root:dialout bei 660. Der fhem-Benutzer war nicht in der Dialoutgruppe... Seit einem
addgroup fhem dialout
taucht die Dateideskriptor-Meldung nicht mehr im Log auf.
Nach ein paar Neustarts taucht die Meldung wieder auf... :-(
Zitat von: Amenophis86 am 19 Februar 2018, 06:26:29
Kann er nicht mit stacktrace schauen, wer die Meldung verursacht?
Ich denke eher nicht. Aber ein Versuch ist es auf alle Fälle Wert.
Also einmal bitte stacktrace aktivieren
Hier ist ein Logauszug mit stacktrace 1 beim Objekt global:
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
2018.02.19 07:43:23 0: Server shutdown
looking for table: fhembinfilesave
testing: #1
found: `fhem`.`current`
found: `fhem`.`fhemb64filesave`
found: `fhem`.`fhemconfig`
found: `fhem`.`fhemstate`
found: `fhem`.`fhemversions`
found: `fhem`.`history`
table not found
2018.02.19 07:43:27 1: HMLAN_Parse: HMLAN new condition disconnected
2018.02.19 07:43:27 1: HMLAN_Parse: HMLAN new condition init
2018.02.19 07:43:32 1: usb create starting
2018.02.19 07:43:32 1: usb create end
2018.02.19 07:43:32 0: Featurelevel: 5.8
2018.02.19 07:43:32 0: Server started with 218 defined entities (fhem.pl:16204/2018-02-17 perl:5.024001 os:linux user:fhem pid:11118)
2018.02.19 07:43:33 1: HMLAN_Parse: HMLAN new condition ok
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
Kann es sein, dass die Systemkonsole noch auf serial0 zugreift (neben dem PI-Modul)?
Lt. Wiki (ist noch Jessie, dürfte aber auf Stretch auch passen):
ZitatIn der Datei /boot/cmdline.txt diesen Eintrag löschen:
console=serial0,115200
In der /boot/cmdline.txt steht bei beiden Systemen (ein System mit Dateideskriptor-Meldungen und eins ohne) statt
console=serial0,115200
der Eintrag wie im Wiki hier beschrieben: https://wiki.fhem.de/wiki/HMUARTLGW
console=tty1
Nach (fast) 24 Stunden habe ich die Meldung nicht wieder gesehen. Ich denke den letzten Ausschlag hat ein Neustart des gesamten Systems nach der Änderung der Gruppenzugehörigkeit des fhem-Users
und Änderung der Berechtigung der dev-Files (standen auf root:root, geändert auf root:dialout) gegeben.
Ich muss dieses Thema leider nochmal "aufwärmen", weil es leider doch noch nicht gelöst ist. Mittlerweile weiß ich warum die Meldung "Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden." nicht noch einmal erschien, bzw. jetzt wieder erscheint. Ich kann den Fehler jetzt reproduzieren.
Der Fehler taucht immer dann auf, wenn ich beim HMInfo Modul auf "update" und danach auch "configCheck" gehe. Die Anzahl der Fehlermeldungen (der Fehler erscheint dann 29x im Log) entspricht genau der Anzahl der Fenstersensoren... (?)
list homematic_info:
...
Attributes:
autoArchive 1
configDir FHEM
group FHEM
room System
sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
sumStatus battery,sabotageError,powerError,motor
webCmd update:protoEvents short:rssi:peerXref:configCheck:models
Beispielhafter Fenstersensor:
Internals:
CFGFN
DEF 5BDC27
HMLAN_MSGCNT 1
HMLAN_RAWMSG E5BDC27,0000,047DFC73,FF,FFD3,9EA6105BDC27A1B2C306010000
HMLAN_RSSI -45
HMLAN_TIME 2018-02-24 17:23:29
IODev vccu
LASTInputDev HMLAN
MSGCNT 1
NAME tss_kueche_links
NOTIFYDEV global
NR 140
NTFY_ORDER 50-tss_kueche_links
STATE closed
TYPE CUL_HM
lastMsg No:9E - t:10 s:5BDC27 d:A1B2C3 06010000
protLastRcv 2018-02-24 17:23:29
rssi_at_HMLAN min:-45 max:-45 cnt:1 avg:-45 lst:-45
READINGS:
2018-02-24 17:06:28 Activity alive
2018-01-14 08:47:35 CommandAccepted no
2018-01-18 20:13:10 D-firmware 1.0
2018-01-18 20:13:10 D-serialNr OEQ0703846
2018-02-24 16:24:01 PairedTo 0xA1B2C3
2018-01-07 20:56:53 R-cc_windowrec_kueche-expectAES set_off
2018-01-07 20:56:53 R-cc_windowrec_kueche-peerNeedsBurst set_on
2018-01-07 20:56:13 R-cc_windowrec_wozi_nord-expectAES set_off
2018-01-07 20:56:13 R-cc_windowrec_wozi_nord-peerNeedsBurst set_on
2018-01-07 20:56:30 R-cc_windowrec_wozi_west-expectAES set_off
2018-01-07 20:56:30 R-cc_windowrec_wozi_west-peerNeedsBurst set_on
2018-01-07 18:20:28 R-cyclicInfoMsg on
2018-01-07 18:20:29 R-eventDlyTime 0 s
2018-01-07 18:20:28 R-pairCentral 0xA1B2C3
2018-01-07 18:20:28 R-sabotageMsg on
2018-01-07 18:20:29 R-sign on
2018-01-07 20:56:43 R-tc_windowrec_wozi-expectAES set_off
2018-01-07 20:56:43 R-tc_windowrec_wozi-peerNeedsBurst set_on
2018-02-24 16:24:01 RegL_00. 02:01 09:01 0A:A1 0B:B2 0C:C3 10:01 14:06 00:00
2018-02-24 16:24:01 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2018-01-07 21:16:12 aesCommToDev ok
2018-01-07 21:16:12 aesKeyNbr 00
2018-02-24 17:23:29 alive yes
2018-02-24 17:23:29 battery ok
2018-02-24 17:23:29 contact closed (to vccu)
2018-02-24 17:23:29 recentStateType info
2018-01-28 22:57:06 sabotageAttack_ErrIoAttack cnt 1
2018-02-24 17:23:29 sabotageError off
2018-02-24 17:23:29 state closed
2018-01-16 21:22:36 trigDst_cc_dev_kueche noConfig
2018-01-16 21:22:38 trigDst_cc_dev_wozi_nord noConfig
2018-01-16 21:22:35 trigDst_cc_dev_wozi_west noConfig
2018-01-16 21:22:35 trigDst_tc_dev_wozi noConfig
2018-01-16 21:22:38 trigger_cnt 16
helper:
HM_CMDNR 158
mId 00C7
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5BDC27,00,00,00
nextSend 1519489409.223
prefIO
rxt 2
vccu vccu
p:
5BDC27
00
00
00
mRssi:
mNo 9E
io:
HMLAN:
-45
-45
prt:
bErr 0
sProc 0
sleeping 1
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rssi:
at_HMLAN:
avg -45
cnt 1
lst -45
max -45
min -45
shadowReg:
tmpl:
Attributes:
IODev vccu
IOgrp vccu
actCycle 012:00
actStatus alive
autoReadReg 5_readMissing
devStateIcon closed:fts_window_1w@green opened:fts_window_1w_open@red
expert 2_defReg+raw
firmware 1.0
group fenster
icon fts_window_1w
model HM-SEC-SCo
peerIDs
room EG_Küche
serialNr OEQ0703846
subType threeStateSensor
Ich denke nicht das es die Fenstersensoren sind. Hast du zufällig auch genau so viele Thermostate?
Nein, Thermostate habe ich nur 17. Es ist schon komisch, dass es genau 29 Meldungen sind und die Zahl 29 nur auf die Anzahl der Fenstersensoren passt...
Ist vielleicht jemand hier, der mir einen Tipp geben kann wo (vielleicht eine Logdatei, die ich noch nicht kenne) ich noch nach einem Ansatz suchen kann? Die Fehlermeldung im Log taucht genau 29x wie folgt auf
Dateideskriptor, der auf die Konsole verweist, konnte nicht gefunden werden.
, wenn das Modul CUL_HM aktiv ist oder ich ein "set HMInfo update" absetze.
Die Zahl 29 deutet auf meine Fenstersensoren hin. Und zwar scheint es da genau um die optischen Fenstersenoren (HM-SEC-SCo habe ich genau 29 Stück) zu gehen, denn einen weiteren magnetischen Fenstersensor (HM-SEC-SC) missbrauche ich hinter einem Bild als Gast-WLAN-Schalter.
Mein HMInfo sieht so aus:
define homematic_info HMinfo
attr homematic_info autoArchive 1
attr homematic_info configDir FHEM
attr homematic_info group FHEM
attr homematic_info room System
attr homematic_info sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
attr homematic_info sumStatus battery,sabotageError,powerError,motor
attr homematic_info webCmd update:protoEvents short:rssi:peerXref:configCheck:models
Ein beispielhafter Fenstersensor sieht so aus:
define tss_wozi_sued CUL_HM 5B6363
attr tss_wozi_sued IODev HMLAN
attr tss_wozi_sued IOgrp vccu:HMLAN
attr tss_wozi_sued actCycle 012:00
attr tss_wozi_sued actStatus unknown
attr tss_wozi_sued autoReadReg 5_readMissing
attr tss_wozi_sued devStateIcon closed:fts_door_slide@green open:fts_door_slide_open@red
attr tss_wozi_sued expert 2_defReg+raw
attr tss_wozi_sued firmware 1.0
attr tss_wozi_sued group fenster
attr tss_wozi_sued icon fts_door_slide
attr tss_wozi_sued model HM-SEC-SCo
attr tss_wozi_sued peerIDs 00000000,63469603,
attr tss_wozi_sued room EG_WoZi
attr tss_wozi_sued serialNr OEQ0709689
attr tss_wozi_sued subType threeStateSensor
Vielen Dank für jeden Tipp im Voraus.
Ich wünsche euch noch eine schönen Restsonntag.
Da es laut deiner Aussage mit CUL_HM zutun haben könnte, könntest du mal im HomeMatic Forum fragen bzw den Beitrag nach dort verschieben. Habe allerdings jetzt nicht den kompletten Thread gelesen.
@Amenophis86: Danke für den Hinweis, daran hatte ich auch schon gedacht und habs jetzt mal gemacht...