Hallo stelle das mal hier unter Anfängerfragen rein :)
Wie gehe ich es an FHEM zu tunen?
Welche Möglichkeiten habe ich rauszufinden wo meine Leichen in FHEM begraben sind?
Habe zwei "Probleme" Das starten von FHEM dauert richtig lange, da werkelt der schon mal 3 Minuten (ist ein Docker Image, das normalerweise in vermutlich paar sekunden da sein müsste - wenn ich es mit anderen Images wie Grafana, MariaDB, TVHeadEnd und co vergeliche)
Und während dem Betrieb sind auch immer wieder mal oft einige Delays/Hänger drinnen, merkt man dann oft, wenn ich die FHEM Seite reloade dann dauerts paar sekunden bis der reagiert.
Also, die echten hänger, wenn das System blockiert solltest du Mal damit angehen
https://fhem.de/commandref_DE.html#freezemon
Ansonsten schau doch Mal dem Event-Monitor zu. Brauchst du wirklich alle Events die dort durchrattern?
Nein die Event werde ich sicher nicht alle brauchen, die werden zwar alles auf der SSD gespeichert aber vermute einfach das laufen an sich wird schon zeit brauchen oder?
Habe eben auch einige Timer die im sekunden intervall irgendwelche Sachen lesen/prüfe und dann schreiben.
Die dann teils auch weils eben schnell gehen musste auch Logs einfach so schreiben ;) - die werde ich mal eliminieren und das Freezmon mal installieren.
Gibt es auch einen Ansatz wie ich drauf kommen kann warum das starten so lange dauert?
ich tippe mal ins blaue ..
attr initialUsbCheck disable 1
ansonsten schau dir mal die Größe der Datei fhem.save an (in letzter Zeit werden immer wieder Schwierigkeiten bei Verwendung des MQTT2-Servers in Verbindung mit retain gemeldet
Auf die fhem.save hätte ich jetzt auch getippt.
Brauchst Du wirklich Trikker im Sekundentakt? Das sehe ich dann eher als "schlechtes Design". Wenn man so schnell reagieren muß, ist eine Umstellung auf Eventbasiert besser ....
Zitat von: Wernieman am 23 Dezember 2022, 09:03:35
Auf die fhem.save hätte ich jetzt auch getippt.
Brauchst Du wirklich Trikker im Sekundentakt? Das sehe ich dann eher als "schlechtes Design". Wenn man so schnell reagieren muß, ist eine Umstellung auf Eventbasiert besser ....
Ja das mit dem Sekundenticker wirst schon recht haben, nur in dem einen Fall ist das halt schneller als Event basiert, da ich da auf die Daten (MQTT) vom PV wechslerichter/Akku und co schaue, um im sekunden intervall den AC Output berechne, wenn ich da auf Eventbasiert umstelle, dann habe ich da mehr Events als 1 pro Sekunde.
Auf was muss ich in der fhem.save achten? Die hat 17647 Zeilen. Wie bekomme ich da sachen raus wenn das zuviel ist?
Zb Homematic Thermostat hat da teilweise sehr viele Einträge.
Oder ein Dummy Device von mir (PV Forecast) hat auch sehr viele Einträge
UniFi Geräte sehr viele alte Einträge.
Das
attr initialUsbCheck disable 1
brauche ich nur wenn ich neue USB Geräte angehängt habe oder?
Die bestehenden USB Sache ignoriert mir das teil?
Nein das Initialusbcheck kannst du getrost deaktivieren, das ist idR unnötig,auch wenn die Funktion sicher Mal einen Sinn hatte, aktuell hab ich noch keine Installation gesehen die das benötigt hatte. Versuch macht kluch...
Zur fhem.save ... Wie groß ist die Datei? Setzt du mqtt2-server ein?
Wie und warum zum Teufel benötigst du sekündlich den Output vom Wechselrichter? Genau durch solchen Unfug erzeugst du doch unnötig Last , die Berechnung wird dann vermutlich auch noch blockierend ablaufen, weil du das im notify machst und damit im Hauptprozess?
Ok das initusb ist mal raus.
die fhem.save hat eben ca 18000 zeilen und ist 1306kB groß.
MQTT2 Server verwende ich zwei einmal einen externen mosquitto server der eigenständig im docker läuft, und einem der Wechselrichter hat selber einen MQTT2 Server der seine daten schickt.
Berechnen muss ich es so schnell, weil ich im sekundentakt die Daten von der PV Speicher und Verbrauch bekomme und ich dann den ACOutput schreiben muss an den MQTT2 Server.
Leider geht da es nicht anders. Wenn ich zb will, das der Speicher nur mit 4000 Watt gladen wird, und der Rest der PV soll ins Netz gehen, dann muss ich eben sekündlich rechnen wieviel überschuss da ist (PV Produktion - Verbrauch) da dann die 4000 Watt weg und alles an Rest geht ins Netz. - das geht leider nicht anders.
Bzw im Moment entleere ich den Speicher über den Tag, da will ich auch das der Speicher nur mit 4000 Watt entleert wird, dazu eben auch die Rechnung ACOutput (ins Netz) = PV+4000 - Verbrauch
M.E. ein guter Thread, um sich einzulesen: https://forum.fhem.de/index.php/topic,117075.0/all.html (https://forum.fhem.de/index.php/topic,117075.0/all.html)
Zitat von: sn0000py am 23 Dezember 2022, 09:39:25
Ja das mit dem Sekundenticker wirst schon recht haben, nur in dem einen Fall ist das halt schneller als Event basiert, da ich da auf die Daten (MQTT) vom PV wechslerichter/Akku und co schaue, um im sekunden intervall den AC Output berechne, wenn ich da auf Eventbasiert umstelle, dann habe ich da mehr Events als 1 pro Sekunde.
Das ist auch ziemlich sicher eine Folge von einem Wust an nicht komplett durchdachten Event-Filtern. Es würde vermutlich reichen, passende "thresholds" bei event-on-change-reading" zu setzen. Dann noch schauen, ob das "event-loops" sind, oder Einzelevents...
ZitatAuf was muss ich in der fhem.save achten? Die hat 17647 Zeilen. Wie bekomme ich da sachen raus wenn das zuviel ist?
Zb Homematic Thermostat hat da teilweise sehr viele Einträge.
Da na, die Zahl der Zeilen ist vermutlich weniger interessant wie die Länge einzelner Zeilen. Einfach mal mit etwas kritischem Blick drübergehen. Die Thermostate sind vermutlich (!) nicht das Problem, eher (einmal mehr) die "Kommunikationsstatus im Sub-Device"-Thematik (aber an einer anderen Stelle!).
ZitatOder ein Dummy Device von mir (PV Forecast) hat auch sehr viele Einträge
Auch da kommt es eben darauf an, ob das überhaupt in der Form gebraucht wird. Aber ohne Details kann man schlecht helfen. "dummy" ist aber immer verdächtig und vermutlich (!) nicht die beste mögliche Läösung.
Zitatattr initialUsbCheck disable 1
brauche ich nur wenn ich neue USB Geräte angehängt habe oder?
Die bestehenden USB Sache ignoriert mir das teil?
Lösche (!!!!) es einfach... (völlig unnötige Diskussion)
Und du nutz offenbar NICHT (!) MQTT2_SERVER, sondern MQTT2_CLIENT! Wenn wir als Helfer Unschärfen dieser Qualtität ausfiltern müssen, ist es echt schwierig!
Ok danke für den Thread werde ich mir nun in den Feiertagen mal durchlesen
Aber nein diesen einen Timer muss ich jede Sekunde durchlaufen lassen, weil sich eben die PV und der Verbrauch oft sehr schnell ändern, und ich auf diese schnellen Änderungen auch schnell reagieren muss - eventuell wäre hier ein zweiter fhem vielleicht hilfreich für diese Regelaufgabe - oder ganz was anderes?
fhem.save
wie bekomme ich die einträge da raus?
Ich habe zb ein dummy Device, das eben einige readings hat, die ich nur zum berechnen und nachschauen brauche, sprich die daten werden nur zur Laufzeit benötigt und brauchen niemals gespeichert werden.
mqtt2-server
ja da hast recht verwende nur mqtt2-client, ich dachte die frage war ob ich generell einen mqtt2 server verwende
Zitat von: sn0000py am 23 Dezember 2022, 10:38:36
Aber nein diesen einen Timer muss ich jede Sekunde durchlaufen lassen, weil sich eben die PV und der Verbrauch oft sehr schnell ändern, und ich auf diese schnellen Änderungen auch schnell reagieren muss - eventuell wäre hier ein zweiter fhem vielleicht hilfreich für diese Regelaufgabe - oder ganz was anderes?
Du wirst vermutlich schon wissen warum du so wehement darauf bestehst, dass du mit Sekundenwerten rechnen willst, dann mach das halt. Aber zeig doch mal deine Berechnung und vor allem das userreading und das notify, welches die Berechnung triggert. Selbst eine sekündliche Berechnung sollte einem System nicht derartig zusetzen. Ich hab da aber eine Vermutung und würde die gern prüfen....
Zitat von: sn0000py am 23 Dezember 2022, 10:38:36
Aber nein diesen einen Timer muss ich jede Sekunde durchlaufen lassen, weil sich eben die PV und der Verbrauch oft sehr schnell ändern, und ich auf diese schnellen Änderungen auch schnell reagieren muss
Wenn du genau nur dann reagierst, wenn sich entweder die PV-Leistung (halbwegs sgnifikant) oder der Verbrauch (halbwegs sgnifikant) ändern, muss das nicht unbedingt jede Sekunde sein. Und wenn es schneller wirklich signifikante Änderungen gibt, kann man doch auch gleich reagieren und muss nicht eine Sekunde warten.
Bin mit Wernieman einig: das ist und bleibt tendenziell schlechtes design.
Zitatfhem.save
wie bekomme ich die einträge da raus?
Ich habe zb ein dummy Device, das eben einige readings hat, die ich nur zum berechnen und nachschauen brauche, sprich die daten werden nur zur Laufzeit benötigt und brauchen niemals gespeichert werden.
Dann frage uch mich, warum man die überhaupt braucht. "Nachschauen" klingt eher danach, als würdest du deinen Codes nicht vertrauen. Aber Readings (triggernd) zu schreiben, ist m.E. nicht "best practice", sondern verschärft im Zweifel die Probleme. ($data ist bekannt?)
Zitat
mqtt2-server
ja da hast recht verwende nur mqtt2-client, ich dachte die frage war ob ich generell einen mqtt2 server verwende
Du verwendest ein MQTT2-IO, aber die Server sind "normale" MQTT-Server (das mit dem "2" ist nur eine FHEM-interne Unterscheidung zu der alten Modulgeneration, das Protokoll ist und bleibt MQTT...).
Nur meine 2ct..
Ok das mit dem $data schaue ich mir mal an, generell einem Reading zu sagen es soll nicht in fhem.save gepseichert werden und dort ignoriert werden gibt es nicht? (eine schnelle (und schmutzige) Möglichkeit das zu regeln)
der Code der zumindest im Moment sekündlich ausgeführt wird:
sub victron_recalc($$) {
my ($device, $event) = @_;
# Log 1, $device." ... ".$event;
my $DCtoAC = ReadingsVal("victron", "PowerChargerA", 0)+ReadingsVal("victron", "PowerChargerB", 0);
my $FroniusToAC = ReadingsVal("victron", "PowerPVFronius", 0);
my $consume = ReadingsVal("victron", "PowerConsumeL1", 0)+ReadingsVal("victron", "PowerConsumeL2", 0)+ReadingsVal("victron", "PowerConsumeL3", 0);
my $BatteryLoadMode = ReadingsVal("SolCast", "Battery.loadMode", 0);
my $lastSetPoint = ReadingsVal("victron", "ESSAcPowerSetPoint", 0);
my $setPoint = $lastSetPoint;
# 110 Batterie in Warteposition fürs entleeren
# 111 Batterie wird geladen
# 112 Batterie wird entleert
if ($BatteryLoadMode == 100) { $setPoint = -10; }
elsif ($BatteryLoadMode == 99) { $setPoint = -100; }
elsif ($BatteryLoadMode == 110) {
my $thisTime = time();
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($thisTime);
# zwischen 8 und 13 uhr, wenn genug Leistung von der PV da ist, den Akku vollständig ins Netz entleeren
if ( ($hour >= 8) && ($hour <= 13) && (($FroniusToAC + $DCtoAC) > 2000) && ( ($FroniusToAC + $DCtoAC - $consume) > 1000) ) {
victron_speicher_entleeren();
# Danach wird BatteryLoadMode auf 112 gesetzt
}
}
elsif ($BatteryLoadMode == 111) { $setPoint = 100; }
elsif($BatteryLoadMode == 112) {
my $BatterySOC = ReadingsVal("victron", "BatterySOC", 0);
# Ausrechnen wieviel Watt noch raus müssen
my $BatteryNeeds = ($BatterySOC-10) * 30800/100;
my $batteryDischarge = 4000;
my $thisTime = time();
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($thisTime);
if ($BatterySOC < 9) {
$batteryDischarge = 100;
$batteryDischarge = 0 if ($FroniusToAC + $DCtoAC < $consume);
}
elsif ($BatterySOC < 10) {
$batteryDischarge = 500;
$batteryDischarge = 0 if ($FroniusToAC + $DCtoAC < $consume);
}
else {
my $hoursLeft = (14 - $hour);
$hoursLeft = 1 if ($hoursLeft < 1);
$batteryDischarge = $BatteryNeeds / $hoursLeft;
$batteryDischarge = 3000 if ($batteryDischarge < 3000);
$batteryDischarge = 4000 if ($FroniusToAC + $DCtoAC < $consume);
}
# Log 1, "Fronius $FroniusToAC + $DCtoAC - $consume";
if ( ($hour >= 16) && (($FroniusToAC + $DCtoAC) < 1500) && ( ($FroniusToAC + $DCtoAC - $consume) < -50) ) {
# nach 16 Uhr, wenn nur mehr 1500 Watt von PV kommen, und bereits mindesten 50Watt aus dem Netz gekauft wird, kann der Akku wieder geladen werden aus dem Netz
victron_speicher_laden();
}
$setPoint = -$FroniusToAC - $DCtoAC + $consume - $batteryDischarge; # Ins Netz sollte alles vom FRonius + DC + 4kw von Batterie - verbrauch
}
else {
#if ($BatteryLoadMode == 1) { $DCtoAC = $DCtoAC / 2; }
#if ($BatteryLoadMode == 2) { $DCtoAC = 0; }
$setPoint = -($FroniusToAC + $DCtoAC - $consume);
if ($setPoint > -100) { $setPoint = -100; }
}
# $setPoint = -($FroniusToAC + $DCtoAC - $consume);
$setPoint = floor($setPoint);
if (abs($setPoint - $lastSetPoint) > 50) {
# fhem "setreading victron setESSAcPowerSetPoint $setPoint";
#Log 1, "SetPoint auf $FroniusToAC - $consume + $DCtoAC = $setPoint ($lastSetPoint) = ".(abs($setPoint - $lastSetPoint))." BatteryLoadMode $BatteryLoadMode";
fhem "set victron ESSAcPowerSetPoint $setPoint";
}
# Log 1, "PowerdDC $PowerDC, Fronius : $PowerFronius, Consum : $consume";
}
und schon wieder sorry, es ist doch kein timer mit einer sekunde, aber er wird vermutlich so oft ausgeführt
[code]define victron.calc.PowerSetPoint notify victron.PowerChargerA.*|victron.PowerChargerB.*|victron.PowerPVFronius|victron.PowerConsume.* { victron_recalc($NAME, $EVENT)}
attr victron.calc.PowerSetPoint room PV
# DEF victron.PowerChargerA.*|victron.PowerChargerB.*|victron.PowerPVFronius|victron.PowerConsume.* { victron_recalc($NAME, $EVENT)}
# FUUID 62285943-f33f-1e88-5677-6dd3f746a560acf0
# FVERSION 91_notify.pm:0.258880/2022-03-27
# NAME victron.calc.PowerSetPoint
# NR 353
# NTFY_ORDER 50-victron.calc.PowerSetPoint
# REGEXP victron.PowerChargerA.*|victron.PowerChargerB.*|victron.PowerPVFronius|victron.PowerConsume.*
# STATE 2022-12-23 11:48:36
# TRIGGERTIME 1671792516.03357
# TYPE notify
# READINGS:
# 2022-12-22 08:54:28 state active
# 2022-12-23 11:48:36 triggeredByDev victron
# 2022-12-23 11:48:36 triggeredByEvent PowerConsumeL3: 1374.0998172763811
#
setstate victron.calc.PowerSetPoint 2022-12-23 11:48:36
setstate victron.calc.PowerSetPoint 2022-12-22 08:54:28 state active
setstate victron.calc.PowerSetPoint 2022-12-23 11:48:36 triggeredByDev victron
setstate victron.calc.PowerSetPoint 2022-12-23 11:48:36 triggeredByEvent PowerConsumeL3: 1374.0998172763811
[/code]
Zitat von: sn0000py am 23 Dezember 2022, 11:49:22
Ok das mit dem $data schaue ich mir mal an, generell einem Reading zu sagen es soll nicht in fhem.save gepseichert werden und dort ignoriert werden gibt es nicht? (eine schnelle (und schmutzige) Möglichkeit das zu regeln)
Vielleicht kann man auf das "global:SAVE" reagieren und löschen, keine Ahnung, das ist zumindest gefühlt einfach ein übles Gewürge, mit dem ich mich nicht näher beschäftigen mag...
Zitat
der Code der zumindest im Moment sekündlich ausgeführt wird:
sub victron_recalc($$) {
my ($device, $event) = @_;
Variablen zu übergeben, die man nicht braucht, ist lustig... vielleicht solltest du einfach mal einen Zähler einbauen und schauen, wie oft das WIRKLICH ausgeführt wird. Meine Vermutung: noch deutlich öfter als 1 Hz...
Zitat
define victron.calc.PowerSetPoint notify victron.PowerChargerA.*|victron.PowerChargerB.*|victron.PowerPVFronius|victron.PowerConsume.* { victron_recalc($NAME, $EVENT)}
attr victron.calc.PowerSetPoint room PV
# DEF victron.PowerChargerA.*|victron.PowerChargerB.*|victron.PowerPVFronius|victron.PowerConsume.* { victron_recalc($NAME, $EVENT)}
# FUUID 62285943-f33f-1e88-5677-6dd3f746a560acf0
# FVERSION 91_notify.pm:0.258880/2022-03-27
# NAME victron.calc.PowerSetPoint
# NR 353
# NTFY_ORDER 50-victron.calc.PowerSetPoint
Ahh, Weiterlesen hilft, und siehe da, NOTIFYDEF ist auch nicht gesetzt, und ab da wird es ziemlich sicher (nicht) "lustig"....
juppp, sowas hatte ich erwartet ;)
mach mal an dein notify das Attribute disabledAfterTrigger mit dem Wert 1....
Ich bin mir sicher, dass dein Notify innerhalb kürzester Zeit dreimal getriggert wird ;)
Die Ergebnisse werden übrigens auch jedesmal anders sein, da du mittels readingsval verschiedene Werte zusammen sammelst, die je nach Zeitpunkt noch alt sein können ...
Zitat von: bartman121 am 23 Dezember 2022, 12:00:44
mach mal an dein notify das Attribute disabledAfterTrigger mit dem Wert 1....
Nicht imnmer gleich einen workaround vorschlagen! Das Problem sitzt in mehrfacher Hinsicht tiefer!
Zitat
Ich bin mir sicher, dass dein Notify innerhalb kürzester Zeit dreimal getriggert wird ;)
...wenn es nur 3x wäre...
Zitat von: Beta-User am 23 Dezember 2022, 11:59:34
Vielleicht kann man auf das "global:SAVE" reagieren und löschen, keine Ahnung, das ist zumindest gefühlt einfach ein übles Gewürge, mit dem ich mich nicht näher beschäftigen mag...
Variablen zu übergeben, die man nicht braucht, ist lustig... vielleicht solltest du einfach mal einen Zähler einbauen und schauen, wie oft das WIRKLICH ausgeführt wird. Meine Vermutung: noch deutlich öfter als 1 Hz...
Ahh, Weiterlesen hilft, und siehe da, NOTIFYDEF ist auch nicht gesetzt, und ab da wird es ziemlich sicher (nicht) "lustig"....
Was genau wäre das NOTIFYDEF dazu finde ich irgendwie nichts?
Diese readings in den fhem.save von dem dummy device, werden auch "nur" alle 30 minuten geladen - es ist halt praktisch im zweifelsfall dann die letzten werte zu sehen (Das sind die forecast PV Werte von einer Homepage)
Zitat von: sn0000py am 23 Dezember 2022, 12:34:57
Was genau wäre das NOTIFYDEF dazu finde ich irgendwie nichts?
Habe jetzt auch keine Lust zum suchen, wann das gesetzt wird, ist hier erklärt: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#notifyRegexpChanged. Die Kurzfassung: Ohne gesetztes NOTIFYDEF reagiert dieses notify eben auf ALLE Events des gesamten Systems... Würdest du dann direkt im Code prüfen, ob was "interessantes" dabei ist, wäre "nur" (ca.) 30% Performance vergeudet, aber so wird dann immer auch noch komplett durchgerechnet und weiterverteilt. Das kann in dieser Kombination m.E. nicht effektiv sein...
Zitat
Diese readings in den fhem.save von dem dummy device, werden auch "nur" alle 30 minuten geladen - es ist halt praktisch im zweifelsfall dann die letzten werte zu sehen (Das sind die forecast PV Werte von einer Homepage)
Na ja, dürfte nicht "kriegsentscheidend" sein, aber auch da fragt man sich, warum das kein HTTPMOD oder jsonMod ist, sondern (vermutlich) irgendeine andere Krücke am werkeln ist, die diese Aufgabe und Infos auf mehrere Devices verteilt... Klingt einfach nach einem schlecht wartbaren System.
Zitat von: Beta-User am 23 Dezember 2022, 13:57:38
Habe jetzt auch keine Lust zum suchen, wann das gesetzt wird, ist hier erklärt: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#notifyRegexpChanged. Die Kurzfassung: Ohne gesetztes NOTIFYDEF reagiert dieses notify eben auf ALLE Events des gesamten Systems... Würdest du dann direkt im Code prüfen, ob was "interessantes" dabei ist, wäre "nur" (ca.) 30% Performance vergeudet, aber so wird dann immer auch noch komplett durchgerechnet und weiterverteilt. Das kann in dieser Kombination m.E. nicht effektiv sein...
Na ja, dürfte nicht "kriegsentscheidend" sein, aber auch da fragt man sich, warum das kein HTTPMOD oder jsonMod ist, sondern (vermutlich) irgendeine andere Krücke am werkeln ist, die diese Aufgabe und Infos auf mehrere Devices verteilt... Klingt einfach nach einem schlecht wartbaren System.
Ok danke, das mit dem NOTIFY werde ich mir noch anschauen.
Das dummy mit den vielen Readings kommt indirekt von nem jsonMOD, bzw es sind 3 jsonMOD die eben Daten vom webservice abgreifen, und dann werden diese 3 jsonMod in 2 dummy device aufgeteilt
(Konkret werden für die 3 Dachausrichtungen OSt, Süd, WEst die forecast geladen, und dann aufgeteilt in Fronius und victron daten dazu wird gerechnet Victron = 1*West+0.4*Süd+0.6*Ost Fronius ? 0.6*Süd+0.4*Ost) und das muss dann für jedes Reading gemacht werden
Zitat von: sn0000py am 23 Dezember 2022, 14:04:53
dazu wird gerechnet Victron = 1*West+0.4*Süd+0.6*Ost Fronius ? 0.6*Süd+0.4*Ost) und das muss dann für jedes Reading gemacht werden
Danke für die Erläuterung. Wie gesagt, es ist - ausgeführt "alle halbe Stunde" - sicher nicht so, dass das das System ausbremst (auch nicht beim Starten), aber beim Lesen irritiert mich trotzdem das "muss" für "jedes" Reading. Es ist sicher nicht falsch, sich (häufig benötigte) Berechnungsgrößen irgendwo zwischenzuspeichern und ggf. auch anzeigen lassen zu können, aber ob es wirklich ein "muss" ist, musst du selbst wissen.
Manchmal ist es erfahrungsgemäß halt sinnvoll, mal die ganze Kette zu betrachten und sich die Frage zu stellen, ob "althergebrachte" Glaubenssätze ("muss") denn wirklich einer Überprüfung standhalten, denn nicht eben solten "tickt" FHEM eben konkret doch anders, als man das so in Erinnerung hatte (qed).
So noch mal die Fragen wegen dem langen starten von FHEM?
Kann ich da noch was machen (das attr initialUsbCheck disable 1 hat leider nichts gebracht)
bzw wie lange dauert das bei euch?
Bei mir bleibt das Teil relativ lange so stehen. (also so ca 2-3 minuten)
Musst Du zufällig auch custom packages vorinstallieren lassen wie hier beschrieben https://github.com/fhem/fhem-docker#add-custom-packages (https://github.com/fhem/fhem-docker#add-custom-packages)?
Für meinen Roomba (99_RoombaUtils.pm) muss ich das machen
-e CPAN_PKGS="Device::Firmata Math::Polygon::Calc Math::ConvexHull"
Installieren per cpan braucht halt seine Zeit. Der Start vom FHEM-Docker dauert bei mir dadurch bis zu 7 Min. insgesamt.
nein ich habe keine custom packages zu installieren.
Im Moment läuft noch alexa direkt auf der docker Installation (sprich das braucht nach dem update immer ein sudo npm install -g alexa-fhem) aber das habe ich bei dem log noch nicht gehabt und wurde erst nach dem starten dann ausgeführt
und kommt nun in ne eigene docker-image
7 minuten oho - das ich ja mal echt lange, vielleicht sind dann die 3 minuten bei mir normal?
Zitat von: sn0000py am 30 Dezember 2022, 11:18:40
...vielleicht sind dann die 3 minuten bei mir normal?
Würde ich Dir nicht so pauschal ins Ohr flüstern wollen. Wenn ich ein Testsystem starte (quasi frische Installation von FHEM) geht es ratzfatz.
Hängt imho also von der individuellen Situation ab. Ich denke, weitere Rückmeldungen könnten Dir mehr Aufschluss geben :)
Wenn es speziell um den Start geht, und du ggf. MQTT2_SERVER im Einsatz hast, könnte das Löschen der retain-Einträge und das nicht-Speichern beim Beenden des betreffenden Readings helfen (siehe die entsprechenden Setter und Attribute bei M2S).
nein habe keinen MQTT2-SERVER im einsatz (nur einen externen der in einem eigenen docker-Image läuft)
gibt es noch eine möglichkeit das logging beim starten zu verfeinern?
Bei mir bleibt er die meiste Zeit hier stehen
6. Enforcing file and directory permissions for /opt/fhem ...
Wenn er wirklich an dem Punkt hängt, der dort steht - ist denn Dein Volume für /opt/fhem sehr umfangreich?
Entere ich meinen Container und lasse dort ein
du -hc --max-depth=1 /opt/fhem/los, erhalte ich als Total 2,5GB, wobei 2,3GB allein auf /opt/fhem/log entfallen.
Und wenn ich
find /opt/fhem/ | wc -l ausführe, bekomme ich 8281.
Ist das bei Dir ggf. deutlich mehr und deshalb ein möglicher Verzögerer beim Ändern der File-Attribute?
Ok danke das wars, hatte ein zusatzliches volume ins /opt/fhem/cache eingebunden, wo dann unterverzeichnisse mit 60000 Files waren (in diversen dirs)
ohne dem startet er jetzt wieder so wie es sein sollte
Danke