Umstellung auf VCCU => wirre Readings aller Homematic Komponenten

[Otto123]

irgendwie komm ich nicht richtig mit. Aber:

• Deine alte SSD läuft generell, aber Du kannst sie an einem anderen Gerät nicht mounten.
• Die neue SSD kannst Du an einem anderen System mounten? Aber das restore von FHEM erzeugt das gleiche Bild mit undefinierten langen Pausen beim Start?

Klingt so oder so nach einer langwierigen Aufgabe. Du müsstest ja nach jeder Änderung schauen ob das Verhalten beim Start noch so ist.

[Wernieman]

Das hört sich nach einem defekt der SSD an. Wahrscheinlich war sie vorher schon defekt, nur durch den Neustart ist es aufgefallen. Wenn kein Linux-Rechner mounten kann, sehe ich "schwarz".

Was steht denn den "übliche Verdächtigen", also kern.log/syslog, wenn Du versuchst die SSD zu mounten ?

[MadMax-FHEM]

Wenn kein Linux-Rechner mounten kann, sehe ich "schwarz".

Wobei mal die Frage: geht kein "Automount" oder auch kein manueller mount?

Manche SSD mss ich auch manuell mounten, dann geht es aber...

Also wie geschrieben: nur zur Sicherheit gefragt

Gruß, Joachim

[Wernieman]

Ich korrigiere mich gerne: Wenn kein Linux Rechner als root angestoßenes mount durchführen kann ....

(Meinte eigentlich NICHT den automatischen Mount)

[frank]

Da ich hier nicht weiter gekommen bin habe ich auf der neuen SSD nun das aktuellste PI OS installiert, alle Updates etc gemacht und Fhem mit allen Paketen istalliert. Dann das frisch erstellte Backup eingespielt. Somit waren auf der SSD nur das OS und Fhem, nichts anderes.
Fhem konnte ich nach etwas über 60 minuten erreichen. Habe leider vergessen die Logs zu kopieren. Auf den ersten Blick habe ich jedoch keine Unterschiede gesehen, außer, dass natürlich einiges gefehlt hat, da nicht installiert.

ich würde fhem mal mit der demo fhem.cfg starten.
ausserdem auch die dblog entfernen.

[LuckyDay]

Server started with 13425 defined entities

13425 Definitionen ist schon eine Menge

Ich würde an deiner Stelle mal mit
attr global verbose 5
loggen , da wird dann ALLES ins Logfile geschrieben und das Logfile wird richtig groß.

Mit einem Editor dann durchsuchen, du kennst ja die Stelle wo deine Stunde Pause ist bei Verbose 3

umstellen auf verbose 3 nicht vergessen!

[Otto123]

Server started with 13425 defined entities

was sagt da fheminfo eigentlich zu den Typen der entities?

[DonCornuto]

Deine alte SSD läuft generell, aber Du kannst sie an einem anderen Gerät nicht mounten.

Richtig

Die neue SSD kannst Du an einem anderen System mounten? Aber das restore von FHEM erzeugt das gleiche Bild mit undefinierten langen Pausen beim Start?

Richtig


Und wie ich heute festgestellt habe ist das auch kein Wunder. Ich habe einen NVME M.2 USB Adapter bestellt und eine NVME SSD. Keine SATA... Wie blöd ich auch bin... habe da gar nicht drauf geachtet. Man man man...

Nun habe ich jedenfalls einen richtigen passenden SATA Adapter und habe via DiskDump "DD" unter Debian Live die alte auf die neue SSD geklont. Einwandfreier zugriff, ohne Probleme.

Jetzt hängt die neue SSD am PI, aber wie nicht anders zu erwarten wieder ein extrem langer Start von FHEM. 15:06 Uhr Pi gestartet, 16:35 Uhr war FHEM erreichbar.

was sagt da fheminfo eigentlich zu den Typen der entities?

Hier die fheminfo

Code Auswählen Erweitern

System Info
ConfigType: configFile
SVN rev: 28330
OS: linux
Perl: 5.32.1
uniqueId: f25...
 
Modules Model Count
ABFALL 1
Alarm 1
CUL_HM
HM-SEC-SIR-WM 3
CCU-FHEM 1
HM-ES-PMSW1-PL 12
HM-PB-2-WM55 3
HM-RC-2-PBU-FM 3
HM-TC-IT-WM-W-EU 4
HM-RC-KEY4-3 3
HM-LC-DIM1TPBU-FM 2
HM-LC-SW4-WM 1
HM-WDS30-OT2-SM 5
HM-CC-RT-DN 24
HM-ES-TX-WM 2
HM-LC-DIM1T-DR 1
Calendar 1
DOIF
FHEM 12
Perl 4
DbLog
MYSQL 1
DbRep
Client 1
FHEMWEB 3
FileLog 110
HMUARTLGW
Revilo-HM-LGW 1
HM-MOD-UART 1
HMinfo 1
HTTPMOD 1
HTTPSRV 1
HUEBridge 1
HUEDevice 15
ConBee II 1
LWB010 2
HG06337 2
lumi.vibration.aq1 1
ZB-CL01 2
lumi.sensor_wleak.aq1 2
440400982841 1
lumi.weather 15
TS011F 2
PHDL00 1
Plug 01 10
IPCAM 4
MQTT2_CLIENT 1
MQTT2_DEVICE 1
RandomTimer 1
SVG 62
SYSMON 1
TelegramBot 1
WeekdayTimer 6
allowed 4
at 11
autocreate 1
dummy 10
eventTypes 1
notify 30
readingsGroup 1
weblink 2

Mich wundert nur gerade, dass bei CUL_HM nicht alle Homematic Geräte aufgeführt sind...




Das mit dem verbose 5 werde ich demnächst nachholen.

[Otto123]

In meinem fhemlog steht beim Start ...702 entities. Wenn ich fheminfo aufrufe stehen dort in Summe 496 ...
Ok, eine Diskrepanz, ich habe keine Ahnung wer wie zählt.
Aber:
Bei Dir zeigt fheminfo eine Summe von 395 und im fhemlog stehen 13425 entities - das übersteigt jetzt meine Größenordnung von Diskrepanz Das ist ne völlig andere Nummer. werden da beim Start 10000 definitionen aussortiert?

[DonCornuto]

Hier noch einmal ein Start mit Verbose 5

18:40 Uhr Pi komplett herutergefahren, Strom ab.
18:45 Uhr Pi eingeschaltet
gegen 20:11 Uhr war Fhem wieder erreichbar, könnte auch etwas früher gewesen sein.


Da zu viel Text, als rar im Anhang.Ich habe nur ein paar Passwörter mit Suchen/Ersetzen gelöscht.

[Beta-User]

Hmmm, also den Zeitsprung könnte man mit dem Fhem-Neustart erklären, aber irgendwie sind das gefühlt zu wenig Daten, die an der Stelle (für 5 Minuten!) stehen. Da scheint was verloren zu gehen?!?

Code Auswählen Erweitern

2024.02.08 18:41:50 5: Cmd: >define unknown_7248AB CUL_HM 7248AB<
2024.02.08 18:46:44 5: Cmd: >setuuid unknown_7248AB 64e3a1fc-f33f-46f3-8e73-ae54e0b1b3e74a3c<
Generell: Du hast ja jetzt eine VCCU, aber eine näherungsweise unendliche Zahl von "ignored" CUL_HM-Devices. Die könnte man m.E. nach Einrichtung der VCCU alle löschen! Dass die vorhanden sind, verzögert jedenfalls das zeitnahe Parsen von CUL_HM-Messages gewaltig.

Aber auch ansonsten ist das Log gefühlt sehr zäh. Speicher zu voll => der PI swapt?

[DonCornuto]

Da scheint was verloren zu gehen?!?

Jein. Ich habe vor dem Neustart noch ein "set VCCU defIgnUnknown" durchgeführt. Dabeio hängt das System einige Minuten. Ich würde das darauf schieben.
Vieleicht hab ich den Pi auch etwas zu früh abgeschaltet und daher fehlt da was.

Ja mit diesen Unknown Dingern hab ich mich auch schon einmal befasst. Da kommen stündliche einige hinzu. Woher das kommt hab ich noch nicht herausgefunden. Schade nur, dass man die nicht permanent deaktivieren kann. Ich gehe meist einmal im Monat dabei und führe diesen Ignore Befehl aus, damit es nicht aus dem Ruder läuft.

Im Vergleich zu dem verbose 3 Log gibt es aber nach dem Start nahezu keine "Pause". Mir sieht es danach aus, dass der Start vorwiegend durch diese Masse an Unknown ausgebremst wird?

der PI swapt?

Bisher noch nie gesehen.

[Beta-User]

Mir sieht es danach aus, dass der Start vorwiegend durch diese Masse an Unknown ausgebremst wird?

Genau das war auch mein Eindruck, und von daher glaube ich, dass der Weg über "defIgnUnknown" genau der falsche für dein Umfeld zu sein scheint. Ich würde die unknown-Devices alle löschen und auch gelöscht lassen. Lieber viele Readings in der VCCU wie diese Handbremse...

Und dann mal forschen, wo die vielen unknown-Devices denn herkommen...?!? Vielleicht (?) von der speziellen Variante deines HMLGW?

Habe jedenfalls bisher noch nirgends eine VCCU gesehen mit derartig vielen "kaputten" messages (es werden ja kaum alle 200 Nachbarn BidCoS im Einsatz haben...).

[DonCornuto]

Das heißt ich mache jetzt was?

"defignunknown" hatte ich in jetzt schon das ein oder andere mal ausgeführt. Kann / Soll ich das rückgängig machen? Wann ja wie? Die Doku hiflt mich da nicht so sehr weiter.

Ich würde die unknown-Devices alle löschen und auch gelöscht lassen. Lieber viele Readings in der VCCU wie diese Handbremse.

Ich habe ja keine Unknown-Devices ? Ich habe nur dioe Readings in der VCCU

Woher die alle kommen / kommen könnten ist schwierig einzugrenzen. Hatte jahrelang nur das myhmuart als Gateway und da gab es das ja nie.
Auch ohne Langateway sammelt die VCCU die Unknown Devices. Daher würde ich das ausschließen.

[Beta-User]

Der Befehl macht aus Readings an der VCCU Devices und setzt die dann auf ignore. Genau diese Devices bremsen dein System aus, also diese alle löschen und dann auch nicht wieder erstellen.