Hallo,
ich kann fhem nicht erreichen.
Mit putty/ssh kann ich mich mit dem Server verbinden und FTP geht auch.
An den logs kann ich sehen, dass fhem weiter werkelt und z.B. Daten loggt.
Wenn ich den fhem Status abfragen will,
kommt eine Fehlermeldung Failed to get D-Bus connection:
pi@raspberrypi ~ $ sudo systemctl status fhem
Failed to get D-Bus connection: No connection to service manager.
FHEM läuft :
pi@raspberrypi ~ $ service fhem status
fhem is running
pi@raspberrypi ~ $ sudo systemctl status fhem
Failed to get D-Bus connection: No connection to service manager.
pi@raspberrypi ~ $ sudo ps aux | grep [f]hem
fhem 1986 41.5 9.8 46088 43920 ? S 11:59 1:10 perl fhem.pl fhem.cfg
root 1987 0.0 0.2 1716 1228 ? Ss 11:59 0:00 startpar -f -- fhem
root 2125 0.0 0.2 1780 1152 ? Ss 11:59 0:00 /bin/sh -c /bin/sleep 300; /usr/bin/touch /opt/fhem/log/fhem.save; /etc/init.d/watchdog start
pi@raspberrypi ~ $
Der Befehl top zeigt an, dass FHEM das System nicht überlastet.
Keine Updates/Zusatzinstallationen/neue Devices in den letzten Wochen,
der Fehler kam sozusagen aus heiterem Himmel.
Kann hier jemand weiterhelfen ?
Viele Grüße
Ralf
Schau mal in /var/log/messages ob es da zum Thema systemd gibt.
Zitat von: Christoph Morrison am 12 Mai 2020, 12:34:46
Schau mal in /var/log/messages ob es da zum Thema systemd gibt.
Das Unterverzeichnis messages gibt es bei mir nicht:
pi@raspberrypi /var/log $ ls
alternatives.log debug.1 faillog regen_ssh_keys.log
alternatives.log.1 debug.2.gz fontconfig.log samba
alternatives.log.2.gz debug.3.gz fsck syslog
alternatives.log.3.gz debug.4.gz kern.log syslog.1
apache2 dmesg kern.log.1 syslog.2.gz
apt dmesg.0 kern.log.2.gz syslog.3.gz
auth.log dmesg.1.gz kern.log.3.gz syslog.4.gz
auth.log.1 dmesg.2.gz kern.log.4.gz syslog.5.gz
auth.log.2.gz dmesg.3.gz lastlog syslog.6.gz
auth.log.3.gz dmesg.4.gz lpr.log syslog.7.gz
auth.log.4.gz dpkg.log mail.err user.log
bootstrap.log dpkg.log.1 mail.info user.log.1
btmp dpkg.log.10.gz mail.log user.log.2.gz
btmp.1 dpkg.log.2.gz mail.warn user.log.3.gz
ConsoleKit dpkg.log.3.gz messages user.log.4.gz
daemon.log dpkg.log.4.gz messages.1 watchdog
daemon.log.1 dpkg.log.5.gz messages.2.gz wtmp
daemon.log.2.gz dpkg.log.6.gz messages.3.gz wtmp.1
daemon.log.3.gz dpkg.log.7.gz messages.4.gz
daemon.log.4.gz dpkg.log.8.gz news
debug dpkg.log.9.gz proftpdEine Datei mit diesem Namen auch nicht:
pi@raspberrypi /var $ ls
backups cache lib local lock log mail opt run spool swap tmp www
pWo kann/soll ich sonst noch suchen =?
Aber da ist doch die Datei messages?!?
Zitat
bootstrap.log dpkg.log.1 mail.info user.log.1
btmp dpkg.log.10.gz mail.log user.log.2.gz
btmp.1 dpkg.log.2.gz mail.warn user.log.3.gz
ConsoleKit dpkg.log.3.gz messages user.log.4.gz
daemon.log dpkg.log.4.gz messages.1 watchdog
Zitat von: HeikoBayer am 12 Mai 2020, 12:55:50
Aber da ist doch die Datei messages?!?
Oh Mann. Ja sorry ich war blind ....
In dieser Datei kommt das Wort
systemd nicht vor !
und d-bus auch nicht?
Also wenn der d-bus nicht mit dem service manager (systemd) reden kann, dann ist es meist so, dass der systemd irgendein Problem hat und nicht gestartet werden konnte.
Du bist dir ganz sicher, dass du die letzte Zeit nicht irgendwas umkonfiguriert / neu installiert hast? Grep auch mal im Verzeichnis /var/log nach d-bus und systemd.
Zitat von: frank am 12 Mai 2020, 13:27:30
und d-bus auch nicht?
auch nicht
Zitat von: Christoph Morrison am 12 Mai 2020, 13:27:59
Also wenn der d-bus nicht mit dem service manager (systemd) reden kann, dann ist es meist so, dass der systemd irgendein Problem hat und nicht gestartet werden konnte.
Du bist dir ganz sicher, dass du die letzte Zeit nicht irgendwas umkonfiguriert / neu installiert hast?
NACHDEM es heute nicht ging habe ich in fhem.cfg den NMAP Netzwerk-Scan rausgeworfen, da dieser mir öfter fhem für ein paar Sekunden blockiert hatte. Hat aber nix gebracht. Ansonsten habe ich in den letzten Tagen (wenn nicht Wochen) sicher nichts neues installiert und eigentlich auch nichts umkonfiguriert.
Zitat
Grep auch mal im Verzeichnis /var/log nach d-bus und systemd.
Bin absoluter Linuxlaie und musste
grep erstmal googeln.
Ich hab
sudo grep -irw d-bus /var/log und
sudo grep -irw systemd /var/logausgeführt. Ist das richtig so ? Das findet nichts. Nochmaliges Ausführen derselben Befehle
findet dann die grep-Aufrufe in der auth.log aber das ist ja klar....
Versuch mal sudo ll /var/log | grep d-bus
Zitat von: HeikoBayer am 12 Mai 2020, 14:40:42
Versuch mal sudo ll /var/log | grep d-bus
pi@raspberrypi ~ $ sudo 11 /var/log | grep d-bus
sudo: 11: command not found
pi@raspberrypi ~ $
:(
Oh, sorry nicht 11 sondern ll --> longlist
Oder aber wenn ll nicht geht, dann ls -l
Zitat von: HeikoBayer am 12 Mai 2020, 14:50:52
Oh, sorry nicht 11 sondern ll --> longlist
Oder aber wenn ll nicht geht, dann ls -l
ll ging auch nicht. Aber ls . Leider ohne Resultat
pi@raspberrypi ~ $ ls -l /var/log | grep d-bus
pi@raspberrypi ~ $ ls -l /var/log | grep systemd
pi@raspberrypi ~ $
Ich habe heute abend noch etwas Zeit mit meinem fhem Problem verbracht.
Anscheinend ist es nicht so, dass fhem gar nicht mehr erreichbar ist,
aber der Aufbau einer Seite kann schon mal mehrere Minuten dauern oder
das Laden der Seite (egal ob Tablet UI / Apache oder Standard-FHEM-Oberfläche)
bricht halt vorher ab.
Kann es sein, dass D-Bus / systemd gar nichts mit meinem Problem zu tun hat ?
Ich erhalte zwar :
pi@raspberrypi ~ $ sudo systemctl status fhem
Failed to get D-Bus connection: No connection to service manager.
aber auch
pi@raspberrypi ~ $ service fhem status
fhem is running
pi@raspberrypi ~ $ sudo /etc/init.d/fhem status
fhem is running
Ich habe was von einem Chrome64-Problem und longpoll/websocket gefunden und mal testweise von 1 auf websocket umgestellt, ich habe testweise meine 99utils.pm rausgenummen (obwohl schon 2 Jahre alt) aber es ändert sich rein nichts. Updates wurden seit Jahren nicht eingespielt und das letzte einzelne Modul vor 2 Monaten.
Ich habe top laufen lassen und mal einige Minuten zugeschaut. Meist ist die CPU-Auslastung (Raspi 1 ::)) bei 1-3% Auslastung, jenach dem welcher Prozess gerade oben läuft. Aber : alle paar Minuten belegt FHEM die CPU für 3-10 Sekunden mit Werten bis zu 98%, keine Ahnung ob das so normal ist.
FHEM läuft, Werte über 1-Wire, HMLAN, Tasmota/WLAN, httpmod etc erfasst und im log abgelegt. Die logs kann ich mir per FTP ansehen. Auch schaltet fhem zu den festgelegten Zeiten z-B die Lichter im Wohnzimmer and oder lässt die Jalousien runter. Nur selber schalten kann ich momentan nicht mehr, da ich nicht auf die Oberfläche komme.
Was ist da los ? Bin etwas hilflos....
Schöne Grüße
Ralf
Hallo Ralf,
ZitatWas ist da los ?
Auf jeden Fall läuft FHEM noch. 8)
ZitatAber : alle paar Minuten belegt FHEM die CPU für 3-10 Sekunden mit Werten bis zu 98%
Sieht nach freezes bzw. Blockierung aus. Verdacht: 1-Wire oder httpmod.
Schon mal den Rpi rebootet ? Am besten direkt noch schnell ein image der SD nach dem shutdown.
Grüße Markus
Zitat von: KölnSolar am 12 Mai 2020, 21:36:11
Hallo Ralf,Auf jeden Fall läuft FHEM noch. 8)Sieht nach freezes bzw. Blockierung aus. Verdacht: 1-Wire oder httpmod.
Schon mal den Rpi rebootet ? Am besten direkt noch schnell ein image der SD nach dem shutdown.
Grüße Markus
Hallo Markus,
ja rebootet habe ich mehrmals schon. Das ist ja momentan die einzige Möglichkeit irgendwas zu ändern.
Also fhem.cfg oder *.pm per FTP holen, ändern wieder auf den Raspi und dann per ssh ein sudo reboot ::)
Und ja ich hatte immer wieder freezes. Und habe noch. Hier die letzten log-Einträge :
2020.05.12 21:45:02.071 1: 192.168.178.6:1883 reappeared (Mosquitto)
2020.05.12 21:45:02.439 1: Perfmon: possible freeze starting at 21:45:00, delay is 2.438
2020.05.12 21:45:04.875 1: Perfmon: possible freeze starting at 21:45:03, delay is 1.875
2020.05.12 21:45:15.039 1: Perfmon: possible freeze starting at 21:45:05, delay is 10.039
2020.05.12 21:47:23.637 1: 192.168.178.6:1883 disconnected, waiting to reappear (Mosquitto)
2020.05.12 21:47:25.938 1: Perfmon: possible freeze starting at 21:45:16, delay is 129.937
2020.05.12 21:47:27.281 3: Nmap (Netzwerk) - starting network scan
2020.05.12 21:47:31.431 3: ONKYO_AVR device Amplifier is unavailable
2020.05.12 21:47:31.719 3: ONKYO_AVR device Amplifier is available
2020.05.12 21:47:32.167 1: 192.168.178.6:1883 reappeared (Mosquitto)
2020.05.12 21:47:32.746 1: Perfmon: possible freeze starting at 21:47:26, delay is 6.745
2020.05.12 21:47:34.926 1: Perfmon: possible freeze starting at 21:47:33, delay is 1.926
2020.05.12 21:47:43.969 1: Perfmon: possible freeze starting at 21:47:35, delay is 8.969
2020.05.12 21:48:28.262 3: Nmap (Netzwerk) - network scan done
2020.05.12 21:48:28.270 1: Perfmon: possible freeze starting at 21:47:45, delay is 43.27Ich dachte, die lägen an NMAP und habe die kleinen Verzögerungen (ab und zu dann mal 5-10s) dann so hingenommen.
Aber oben der letzte freeze im log mit 43s ist schon heftig und da ist nmap wohl nicht schuld dran.
Meinst du ich sollte mal vielleicht erstmal alle Devices mit httpmod und wenn das nicht hilft die Onewire-Devices aus der fhem cfg rausnehmen ? Andere Vorschläge ?
Viele Grüße
Ralf
Zitat von: rasti am 12 Mai 2020, 21:56:51
Meinst du ich sollte mal vielleicht erstmal alle Devices mit httpmod und wenn das nicht hilft die Onewire-Devices aus der fhem cfg rausnehmen ? Andere Vorschläge ?
Du könntest die HTTPMOD-Devices auch erstmal deaktivieren, die brauchst du nicht rausnehmen. Bei 1-Wire weiß ich nicht, ob man die deaktivieren kann.
CPU Usage ist bei einem System auch nicht die einzige Metrik die klemmen kann und es ist auch nicht so, dass die CPU-Usage automatisch mit hoch geht. Guck auch mal in Richtung I/O auf die Karte (SD-Karte ist meistens eine schlechte Idee). NMAP würde ich auch mal testweise deaktivieren, falls du das noch nicht gemacht hast.
Hi,
wenn es wirklich der "heitere Himmel" war - dann gibt es beim raspberry meist zwei Gründe:
- SD Card defekt
- Netzteil defekt / schlecht
Ich würde also erstmal ein offline Image der SD Card machen. (Und eventuell dieses Image auf einer neuen SD Card versuchen zu starten)
Lässt sich der fhem Service ordentlich beenden?
Läuft die demo.cfg?
Netzwerkkabel mal getauscht?
Gruß Otto
Hallo Otto,
Zitat von: Otto123 am 12 Mai 2020, 23:50:05
wenn es wirklich der "heitere Himmel" war - dann gibt es beim raspberry meist zwei Gründe:
- SD Card defekt
- Netzteil defekt / schlecht
Ich würde also erstmal ein offline Image der SD Card machen. (Und eventuell dieses Image auf einer neuen SD Card versuchen zu starten)
Ich hatte beides schonmal - aber da ging dann rein gar nix mehr. Dass sonst alles mit dem Raspi läuft (ssh, ftp, apacheserver) aber FHEM Ausfälle und Freezes zeigt ist schon merkwürdig. Naja, werde ich wahrscheinlich mal versuchen - ich weiss ja sonst nicht was ich noch machen könnte....
Zitat
Lässt sich der fhem Service ordentlich beenden?
Was heisst ordentlich? Ich kann fhem manuell anhalten, Status sagt dann not running - und manuell´starten, dann kommt Status running. Ist es das was du "ordentlich" nennst ?
Zitat
Läuft die demo.cfg?
Ja läuft eigentlich flüssig. Aber auch hier kommen perlmon freezes, siehe unten der ssh-Mitschnitt .
Zitat
Netzwerkkabel mal getauscht?
Vor dem Fehler - nein
nach dem Fehler : auch nicht aber ich hatte probeweise alle Kabel mal ab und wieder dran, auch LAN routerseitig.
VIele Grüße
Ralf
pi@raspberrypi ~ $ sudo /etc/init.d/fhem stop
Stopping fhem...
pi@raspberrypi ~ $ service fhem status
fhem is not running
pi@raspberrypi ~ $ cd /opt/fhem
pi@raspberrypi /opt/fhem $ perl fhem.pl fhem.cfg.demo
2020.05.13 01:54:21 2: Perfmon: ready to watch out for delays greater than one s econd
2020.05.13 01:54:21 1: Including fhem.cfg.demo
2020.05.13 01:54:22.001 3: telnetPort: port 7072 opened
2020.05.13 01:54:22.857 3: WEB: port 8083 opened
2020.05.13 01:54:22.875 3: WEBphone: port 8084 opened
2020.05.13 01:54:22.892 3: WEBtablet: port 8085 opened
2020.05.13 01:54:23.165 1: define Logfile FileLog ./log/fhem-%Y-%m.log fakelog: Can't open ./log/fhem-2020-05.log: Permission denied
2020.05.13 01:54:23.377 2: eventTypes: loaded 109 events from demolog/eventTypes .txt
2020.05.13 01:54:23.622 1: CUL_0 device is none, commands will be echoed only
2020.05.13 01:54:27.348 1: Including ./demolog/fhem.save
2020.05.13 01:54:27.758 1: configfile: Can't open ./log/fhem-2020-05.log: Permis sion denied
Cannot load module RSS
statefile: Please define Logfile first
2020.05.13 01:54:27.893 2: Messages collected while initializing FHEM: configfil e: Can't open ./log/fhem-2020-05.log: Permission denied Cannot load module RSS s tatefile: Please define Logfile first
2020.05.13 01:54:27.896 0: Featurelevel: 5.7
2020.05.13 01:54:27.899 0: Server started with 56 defined entities (fhem.pl:1133 8/2016-04-28 perl:5.014002 os:linux user:pi pid:2445)
2020.05.13 01:54:27.902 1: Perfmon: possible freeze starting at 01:54:22, delay is 5.902
2020.05.13 01:54:52.671 1: Perfmon: possible freeze starting at 01:54:47, delay is 5.67
2020.05.13 01:55:04.931 1: Perfmon: possible freeze starting at 01:54:59, delay is 5.931
2020.05.13 01:55:13.689 3: FS20 set Alarm off
2020.05.13 01:55:26.942 1: Perfmon: possible freeze starting at 01:55:21, delay is 5.942
Zitat von: Christoph Morrison am 12 Mai 2020, 22:15:55
Du könntest die HTTPMOD-Devices auch erstmal deaktivieren, die brauchst du nicht rausnehmen. Bei 1-Wire weiß ich nicht, ob man die deaktivieren kann.
CPU Usage ist bei einem System auch nicht die einzige Metrik die klemmen kann und es ist auch nicht so, dass die CPU-Usage automatisch mit hoch geht. Guck auch mal in Richtung I/O auf die Karte (SD-Karte ist meistens eine schlechte Idee). NMAP würde ich auch mal testweise deaktivieren, falls du das noch nicht gemacht hast.
Ich habe nun nacheinander
* httpmod-Devices und Prolanta
* 1Wire-Devices
* Homematic-Devices
* MQTT-Devices (mosquitto läuft auf selben Raspi)
aus der fhem-cfg rausgenommen und jedesmal danach rebootet.
Leider keine Änderungen - alles immer seehr langsam, eigentlich kein Zugriff möglich
und immer laaange Freezes (60-100s) in fhem.log zu finden.
Bin auch die alten logs durchgegangen -
bevor der Fehler auftrat, hatte ich nur vereinzelte kurze
Freezes (1-10s) und bei einem nmap jeweils ein langes (ca. 40s). Jetzt
seit der Fehler auftritt, stehen auch
besagte lange Freezes im log. Und in diesen letzten 1-2 Tagen habe ich auch rein gar nichts geändert sprich
keine Änderung an der fhem.cfg oder irgendwelchen Modulem vorgenommen.
Das würde für die SD-Kartentheorie sprechen....
ZitatDas würde für die SD-Kartentheorie sprechen....
Immer denkbar bei Problemen, die plötzlich und ohne jegliche vorherige Änderung des Systems auftreten. Allerdings kann ich mich nicht an Problemfälle erinnern, wo die defekte SD "nur" zu freezes führte. :-\
Sicherlich ist es aber bei massiven Problemen immer der beste Weg, ein funktionsfähiges image auf neuer SD laufen zu lassen, um die SmartHome-Funktionalität wieder zu haben und daher ungestresst dem Fehler auf die Spur zu kommen.
Bei den 5s-freezes kommt mir global dnsServer in den Sinn. Hast Du den gesetzt ? Vielleicht ist ja im Netzwerk was allgemeines im argen(Otto spekulierte ja auch schon in die Richtung).
Für die freeze-Prävention und -monitoring nutze ich freezemon anstatt perfmon. Das liefert "Verdächtige" und es wird ein zusätzliches freeze-Log erstellt, wo die Aktionen vor u. nach dem freeze mit global verbose=5 gelogged werden.
Grüße Markus
Zitat von: rasti am 13 Mai 2020, 02:09:08
Ist es das was du "ordentlich" nennst ?
Ja das meinte ich.
2020.05.13 01:54:27.758 1: configfile: Can't open ./log/fhem-2020-05.log: Permis
ich denke, das soll "permission denied" sein.
wie sind die berechtigungen?
gibt es eventuell ein grosses "durcheinander" im fhem bereich?
zeig mal den inhalt vom log ordner mit "ls -al".
@Frank Das ist das log aus dem Start der demo.cfg . Wenn man diesen Start als User pi macht, schaltet fhem.pl nicht um auf User fhem und hat damit keinen Zugriff auf das schon existierende Log von dem Standarddienst.
ok, macht sinn.
berechtigungen würde ich trotzdem checken.
diese freezes, sowohl in demo.cfg, als auch fhem.cfg, sind schon extrem.
ZitatCannot load module RSS
statefile: Please define Logfile first
Ich bin mir gerade nicht sicher (und ich hab nix gefunden, als ich in der SVN-Version der fhem.cfg-demo nachgeschaut habe), aber RSS wird dort nicht geladen. Weshalb wird dann versucht RSS zu laden und warum hast du RSS nicht? Die ist ja etwas älter.
$ svn info 02_RSS.pm
Path: 02_RSS.pm
Name: 02_RSS.pm
Working Copy Root Path: /Volumes/Development/hab/core/subversion
URL: svn+ssh://svn.fhem.de/trunk/fhem/FHEM/02_RSS.pm
Relative URL: ^/trunk/fhem/FHEM/02_RSS.pm
Repository Root: svn+ssh://svn.fhem.de
Repository UUID: 2b470e98-0d58-463d-a4d8-8e2adae1ed80
Revision: 21919
Node Kind: file
Schedule: normal
Last Changed Author: neubert
Last Changed Rev: 16812
Last Changed Date: 2018-06-03 21:52:27 +0200 (Sun, 03 Jun 2018)
Text Last Updated: 2020-04-15 08:45:34 +0200 (Wed, 15 Apr 2020)
Checksum: 8c0935c9b8eaa41621c4aad2c38904605c83e8a9
Hallo zusammen,
kurzes Update nach einem laaangen Vormittag mit FHEM.
- aktuelles Image auf neuer SD-Karte => ging nicht
- aktuelles Image auf neuer/alter SD-Karte in anderem Raspi1 => ging nicht
- altes Image aus 2018 auf alter SD-Karte im Original.´-Raspi1 => ging nicht
- hatte nebenbei bemerkt, dass der Raspi zeitweise keinen Netzzugang hatte,
d.h. aus irgendeinem Grund schlug z.B. wget fehl
- daraufhin Fritzbox angeschaut und das gefunden :
12.05.20 16:58:11 Anmeldung des Benutzers nas an der FRITZ!Box Benutzeroberfläche von IP-Adresse 195.154.63.224 gescheitert (falsches Kennwort).
12.05.20 16:35:20 Anmeldung des Benutzers nil an der FRITZ!Box Benutzeroberfläche von IP-Adresse 77.247.108.15 gescheitert (falsches Kennwort).
=> https://www.abuseipdb.com/check/77.247.108.15
=> https://www.abuseipdb.com/check/195.154.63.224
- Fritzbox rebootet
- LAN-Stecker in anderen Bridgeeingang => ging nicht
- Wieder Image aus 2020 auf alter SD-Karte im Original.´-Raspi1 => ging nicht
Ich hab mich dann seelisch und moralisch schon drauf eingestellt, alles neu aufzusetzen,
das schieb ich sowieso schon laange vor mir her und
einen Raspi3 hätte ich gerade übrig .... habe dann alles wieder WIE ES WAR ins Original-Gehäuse
gepackt, nochmal eingeschaltet und die Kiste => geht !!!
Ich habe keine Ahnung woran es gelegen hat aber es läuft wieder.
Richtig flott, man könnte (wenn man nicht gerade viele Plots auf einer Seite hat)
denken ich hätte schon auf Raspi 3 oder upgegradet :=)
Die logs haben noch manchmal kurze Freezes aber meistens nur 2-3 Sekunden.
Selbst nmap (30-40 hostsUp hat vorher 40sek gebraucht ) ist in 6 Sekunden fertig und blockiert nicht mehr wirklich
2020.05.13 14:05:24.509 3: Nmap (Netzwerk) - starting network scan
2020.05.13 14:05:30.373 3: Nmap (Netzwerk) - network scan done
Ich finde momentan noch im log :
2020.05.13 13:54:46.181 1: PERL WARNING: Scalar value @fld[5] better written as $fld[5] at (eval 627) line 1, <GEN281> line 136.
2020.05.13 13:54:46.182 3: eval: @fld[5]/1000 (mit verschiedenen Werten zu Lines und eval
2020.05.13 13:54:22.942 1: PERL WARNING: Argument "0%" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 1256.
2020.05.13 13:54:22.944 1: PERL WARNING: Argument "100%" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 1256.
2020.05.13 13:51:33.533 3: IOTA: Read callback: request type was update retry 0, no headers, body empty,
Error: read from to http://www.coinkurs.com:80 timed out
2020.05.13 13:50:28.963 1: statefile: Usage: setstate <name> <state>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.
Usage: setstate <name> <state>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.
Also es läuft wieder aber ich habe keinen Plan woran das nun gelegen hat.
Bin erstmal wieder froh ;D
Zitatnach einem laaangen Vormittag mit FHEM
Und die vorangegangene Nacht war ja schon kurz. ;D
Aber prima, dass es wieder geht. Jetzt aber schnell noch ein image erstellen....
Klingt dann ja irgendwie nach Netzwerkproblem(Ursache "verwirrte" FritzBox :-\). Deshalb solltest Du meinen Hinweis zu global dnsServer umsetzen, denn dadurch verhinderst Du blockierendes Verhalten bei Netzwerkzugriffen.
Und freezemon anstatt perfmon einzusetzen wäre auch nicht verkehrt, denn dann sollte der Verursacher von freezes angezeigt werden, wodurch sich auf Netzwerkprobleme schließen ließe.
Naja wenn es nicht die SD Card war und auch nicht das Netzteil (Stecker/Kabel?) - äußert sich beides eigentlich massiver :-\
Dann tippe ich ich auch nach wie vor auf "Netzwerkkabel" - symbolisch gemeint ;) und unterschreibe alle Ideen von Markus :)
Zitat von: KölnSolar am 13 Mai 2020, 14:58:56
Und die vorangegangene Nacht war ja schon kurz. ;D
Oh ja ::)
Zitat
Aber prima, dass es wieder geht. Jetzt aber schnell noch ein image erstellen....
Ist gemacht !
Zitat
Klingt dann ja irgendwie nach Netzwerkproblem(Ursache "verwirrte" FritzBox :-\).
Tja. Nix genaues weiss man nicht. Leider.
Die Ursache wird wohl keiner mehr feststellen können (zumindest ich nicht).
Zitat
Deshalb solltest Du meinen Hinweis zu global dnsServer umsetzen, denn dadurch verhinderst Du blockierendes Verhalten bei Netzwerkzugriffen.
Auf was und wie sollte ich den denn setzen ? Einfach "attr global dnsServer" ? Müsste mich da erst noch einlesen, verstehe das Attribut noch nicht wirklich. Bedeutet das, dass fhem einen eigenen Nameserver betreibt ? Woher dann die Domainname-IP-Zuordnung ? Werden da einfach die IPs bisheriger DNS-Anfragen gespeichert ?
Zitat
Und freezemon anstatt perfmon einzusetzen wäre auch nicht verkehrt, denn dann sollte der Verursacher von freezes angezeigt werden, wodurch sich auf Netzwerkprobleme schließen ließe.
Tja. Geht nicht. Mein FHEM ist zu alt (fhem.pl aus 2016), da kann man nicht einfach irgendwelche neuen Modul einbinden. :(
Und einfach updaten geht nicht, Tablet UI wird über Apache bedient, die Dateien stehen in keinem Standardverzeichnis mehr, Mosquitto ist eine alte Version weil nur die es für meinem alten Rasbian gab, ich hab die Standard .css für Tablet UI editiert anstatt die userdatei und und und. Viel gestrickt, da blickt keiner mehr durch.
Aufgeräumt wird das ganze mit einem großem Update und das gibt es erst zusammen mit einem Hardware-Upgrade.
Wahrscheinlich der nächsthöhere Raspi mit viel GB RAM bei dem SSD-Booten standardmäßig (wieder) geht.
Oder wenn mein FHEM den Dienst verweigert so wie gestern - ich stand kurz vor dem Abgrund (bzw. einem Upgrade auf Raspi3 )
;D ;D ;D
Zitat von: Otto123 am 13 Mai 2020, 15:35:42
Naja wenn es nicht die SD Card war und auch nicht das Netzteil (Stecker/Kabel?) - äußert sich beides eigentlich massiver :-\
Dann tippe ich ich auch nach wie vor auf "Netzwerkkabel" - symbolisch gemeint ;) und unterschreibe alle Ideen von Markus :)
Habe eben festgestellt, dass mein Onkyo und mein Volumio-Raspi auch nicht mehr taten was sie sollten. Habe die vom Strom genommen und neu booten lassen. Dass die nicht gelaufen sind war mir gar nicht aufgefallen, da ich die mit den Fingern gar nicht mehr angreife sondern grundsätzlich über Tablet UI steuere. Spricht auch für Netzwerkprobleme, die mein FHEM zum Absturz gebracht haben....
ZitatAuf was und wie sollte ich den denn setzen ? Einfach "attr global dnsServer" ? Müsste mich da erst noch einlesen, verstehe das Attribut noch nicht wirklich. Bedeutet das, dass fhem einen eigenen Nameserver betreibt ? Woher dann die Domainname-IP-Zuordnung ? Werden da einfach die IPs bisheriger DNS-Anfragen gespeichert ?
neenee, schon eine IP eines DNS-Servers. Ich habe pi-hole als DNS-Server, Du kannst es aber auch auf die FritzBox setzen(glaub ich)
attr global dnsServer meineDNS_IPEs ist weder ein DNS-Server in FHEM, noch werden DNS-Anfragen in FHEM gecached.
Zitat von: KölnSolar am 13 Mai 2020, 16:12:27
neenee, schon eine IP eines DNS-Servers. Ich habe pi-hole als DNS-Server, Du kannst es aber auch auf die FritzBox setzen(glaub ich)
attr global dnsServer meineDNS_IPEs ist weder ein DNS-Server in FHEM, noch werden DNS-Anfragen in FHEM gecached.
OK und was ist dabei nun anders als wenn ich den DNS-Server in der Konfiguration von Linux/Rasbian ändere ?
Meine /etc/resolv.conf sieht so aus :
domain fritz.box
search fritz.box
nameserver 192.168.178.1
Was soll da nun mit
attr global dnsServer 192.168.178.1besser werden ?
steht in der Doku:
ZitatdnsServer
Enthält die IP Adresse des DNS Servers. Die von bestimmten Modulen (oder eigenen Code) aufgerufene HttpUtils_NonblockingGet wird auch bei der DNS Auflösung nicht mehr blockieren, falls dieses Attribut gesetzt ist, da es in diesem Fall FHEM eigene Routinen aufgerufen werden. Sonst werden die OS-eigenen, blockierenden Routinen inet_aton bzw gethostbyname aufgerufen.
Zitat
steht in der Doku:
dnsServer
Enthält die IP Adresse des DNS Servers. Die von bestimmten Modulen (oder eigenen Code) aufgerufene HttpUtils_NonblockingGet wird auch bei der DNS Auflösung nicht mehr blockieren, falls dieses Attribut gesetzt ist, da es in diesem Fall FHEM eigene Routinen aufgerufen werden. Sonst werden die OS-eigenen, blockierenden Routinen inet_aton bzw gethostbyname aufgerufen.
Ah ok. Verstanden. Ich habe eben aber (wie schon so oft) festgestellt, dass mein fhem dafür zu alt ist :
global: unknown attribute dnsServer. Type 'attr global ?' for a detailed list.Ich hab fhem.pl vom 30.4.16 und das
attribute dnsServer kam anscheinend im August 2016.
Ich kann inzwischen die meisten Kurz-Freezes entsprechenden http-Abfragen zuordnen und habe diese
weitgehend minimiert. Für den Nachrichten-Ticker brauche ich z.B. nicht alle 10 Minuten neue Texte,
da reichen mir auch 2 Stunden. Die paar verbleibenden max. 3s-Freezes sind höchstwahrscheinlich OWtherm zuzuordnen.
(kann ohne Fhem-update aber nicht auf asynch owx wechseln - also wird das auch noch aufgehoben bis zum
großen Soft- und Hardwareupdate)
Das einzige was gerade noch wirklich lästig ist, ist dass NMAP wieder eine Totzeit von 40 Sekunden hat.
Das habe ich dann gerade alle 15 Minuten 1x:
2020.05.13 19:20:41.484 3: Nmap (Netzwerk) - starting network scan
2020.05.13 19:21:28.757 3: Nmap (Netzwerk) - network scan done
2020.05.13 19:21:28.766 1: Perfmon: possible freeze starting at 19:20:47, delay is 41.766Bei
http://192.168.178.6:8083/fhem?detail=Netzwerk steht aber
scanDuration = 3Naja, man kann nicht alles haben ....
ZitatIch hab fhem.pl vom 30.4.16 und das attribute dnsServer kam anscheinend im August 2016
Das ist ja Ewigkeiten her. ;D
Mal rein der Neugierde halber: Warum lässt Du zyklisch nmap rennen ?
Zitat von: KölnSolar am 13 Mai 2020, 21:29:36
Das ist ja Ewigkeiten her. ;D
Never change/touch a running system...
Aber es ist jetzt wirklich mal wieder Zeit aufzuräumen.
Zitat
Mal rein der Neugierde halber: Warum lässt Du zyklisch nmap rennen ?
Für Presence-Abfragen (Kinderkontrolle ...) und einfach um zu sehen, ob irgendwelche Clients Probleme haben.
Ich habe viele Tasmota-Devices (Schaltsteckdosen, Energiemess-Steckdosen und Shellies für Beleuchtung).
gibt es in deiner zeitzone (-4 jahre) kein presence modul?
Zitat von: frank am 14 Mai 2020, 08:19:26
gibt es in deiner zeitzone (-4 jahre) kein presence modul?
Gab es : Per LAN-Ping.
Hatte ich vor NMAP auch am Laufen. nmap scheint aber wesentlich zuverlässiger zu sein,
und da nmap eh bei mir läuft nehme ich es halt auch dafür
ZitatHatte ich vor NMAP auch am Laufen. nmap scheint aber wesentlich zuverlässiger zu sein,
zumindestens blockiert es zuverlässig für 40s und fhem steht im dunkeln. ;)
bei uns in der gegenwart kann das presence modul auch eine (eigene) funktion aufrufen. ich denke, das wäre dann auch nicht blockierend.
oder nmap in 2. fhem instanz auslagern und mit fhem2fhem koppeln.
abgefahren wäre, wenn die 2. fhem instanz auf aktuellem stand ist. dann würde fhem2fhem quasi ein wurmloch etablieren. 8)
Zitat von: frank am 14 Mai 2020, 09:50:47
zumindestens blockiert es zuverlässig für 40s und fhem steht im dunkeln. ;)
nur 4 x pro Stunde 8)
Zitat
bei uns in der gegenwart kann das presence modul auch eine (eigene) funktion aufrufen. ich denke, das wäre dann auch nicht blockierend oder nmap in 2. fhem instanz auslagern und mit fhem2fhem koppeln. abgefahren wäre, wenn die 2. fhem instanz auf aktuellem stand ist. dann würde fhem2fhem quasi ein wurmloch etablieren. 8)
In der Tat eine coole Idee. Sozusagen das Beatmungsgerät für mein altes FHEM ;D ;D ;D