Hallo
zum Glück lief mein FHEM während dem urlaub durch. Nun daheim angekommen spinnt es seit 1 Woche.
Entweder habe ich 100pc Perl oder 1Wire geht auf 100pc. (mit Top ausgelesen)
Ich habe auch schon mit perl fhem.pl -d fhem.cfg nachgesehen - finde auch nix besonderes.
Im Forum habe ich auch schongelesen es könnte der OW Server sein. nonblocking steht auf 1!
Im Moment muss ich wieder in der Garage einen Neustart des Systems machen, denn ich komme auch nicht mehr mit ssh drauf.
Initializing USB Stick ist auch disabled.
Hat bitte jemand für mich noch einen Tipp was ich vielleicht noch schauen kann?
Sonst muss ich wohl am We schnell ein neues System auf einer neuen Karte aufsetzen, mit einem BU ziehe ich einen vorhandenen Fehler ja wieder auf die Karte.
Die Poolpumpe kann ich ja zur Not auch über den HM manuell schalten.
Gruß
Helmut
als Du nicht mit ssh raufkamst, war der PI anpingbar?
Update gemacht?
Was hast Du auf dem System?
Servus
Ping habe ich nicht versucht. Gut werde ich das nächste mal drauf achten.
Ja gestern ein Update gemacht.
Es ist ein Demkovi 1 wire Adapter, ein HM USB Stick mit VCCu drauf
Steuere über die HM Und die 1wire meinen Pool und die Gartenbeleuchtung und 3 TürFenstersensoren
Nix besonderes im Prinzip. Im Vergleich zu manch anderen ,,Rechenzentren"
Gruß Helmut
ist der speicher vom pi voll?
was sagt free?
Hallo frank
Free liefert das - sehe eigentlich nix böses. und die SD Karte ist auch ok oder
Ja sonst läuft noch AMAD 2.6.10. und RFHEM.
OWServer ist Version 3.1p5
Soeben wieder nicht erreichbar
Das ist das Ergebnis vom ping. DAs PowerLan funktioniert aber?
Ist das der ping zum pi oder vom pi?
Vom Terminal auf die IP vom Pi
So wieder daheim. Ich tippe auf Netzwerkkarte am Pi da ich ihn nicht singen kann, nur wie hängt das mit der perl Auslastung zu 100pc zusammen?
Oder habe ich mir da 2 Fehler gleichzeitig eingetreten?
Fragt der PI diverse Sachen im Netz ab?
DAS würde zusammenpasen .. Du hast ein Netzwerkproblem
Hallo,
hast Du mal den Denkovi abgezogen ?
Würde ich mal machen und dann versuchen per ssh draufzukommen.
Wahrscheinlich blockiert der Denkovi mit Owserver alles....
Servus B. 8)
werde ich das nächste mal machen - Danke
Und was wenn es der ist? OWServer kübeln?
LG
Helmut
Starte bitte auch mal "apptime" auf dem Pi (Fhem-Kommandozeile).
Nach ein paar Stunden rufst Du das mit "apptime max " nochmal auf, dann siehst
Du, welche Prozesse die meisten Kapazitäten gefressen haben.
Mit OW-Server habe ich keinerlei Erfahrung, bei mir läuft OWX-Async seit Jahren stabil.
Aber mach erstmal die Erreichbarkeit im Netzwerk "heile"
Zitat von: Wernieman am 04 August 2018, 22:14:26
Aber mach erstmal die Erreichbarkeit im Netzwerk "heile"
Bei allem Respekt, daran glaube ich nicht.
Wenn mein System bei 100% Systemauslastung ist, geht da auch nix mehr.....
Zitat von: Bartimaus am 04 August 2018, 22:17:06
Bei allem Respekt, daran glaube ich nicht.
Wenn mein System bei 100% Systemauslastung ist, geht da auch nix mehr.....
Das geht schon, Fhem läuft nur auf einem Core und der RPi2/3 hat 4 Cores.
Das selbe Problem hatte ich auch vor ein paar Tagen. Der Fhem Prozess lief auf einem Core auf 100% CPU Last und hat sich nach ca. 15 Sekunden 2 von 4 GB Ram Speicher gegönnt.
https://forum.fhem.de/index.php/topic,84372.msg823794.html#msg823794
Am Fhem oder an der Perl Version lag es nicht. Ich habe eine andere Perl Version, die oben im Thread empfohlen wurde, installiert. Aber das Problem ging nicht weg.
Ich habe das System schlussendlich neu aufgesetzt und das selbe Fhem Backup eingespielt und der Fehler war verschwunden.
Keine Ahnung war das war.
Hallo
habe jetzt auch noch ein SystemUpdate durchgeführt (habe nun eine neuere Version von perl drauf - 5.24.1)
und im Logfile kann ICH keine Fehler feststellen
2018.08.05 14:12:18 0: Server shutdown
2018.08.05 14:12:21 1: Including fhem.cfg
2018.08.05 14:12:21 3: OWServer: OWNet version 3.1p5 loaded.
2018.08.05 14:12:21 3: OWServer: Opening connection to OWServer localhost:4304...
2018.08.05 14:12:21 3: OWServer: Successfully connected to localhost:4304.
2018.08.05 14:12:21 3: OWServer: owserver version 3.1p5 found.
2018.08.05 14:12:21 3: OWServer: Matching OWNet version already loaded.
2018.08.05 14:12:21 3: Opening CUL_0 device /dev/ttyACM0
2018.08.05 14:12:21 3: Setting CUL_0 serial parameters to 9600,8,N,1
2018.08.05 14:12:21 3: CUL_0: Possible commands: BbCFiAZNkGMKUYRTVWXefmLltux
2018.08.05 14:12:21 3: CUL_0 device opened
2018.08.05 14:12:21 3: telnetPort: port 7072 opened
2018.08.05 14:12:22 3: WEB: port 8083 opened
2018.08.05 14:12:22 3: WEBphone: port 8084 opened
2018.08.05 14:12:22 3: WEBtablet: port 8085 opened
2018.08.05 14:12:22 2: eventTypes: loaded 1039 events from ./log/eventTypes.txt
2018.08.05 14:12:22 3: AMAD (TabletGarage) - defined with host 10.0.0.2 on port 8090 and NONE AccessPoint-SSID
2018.08.05 14:12:22 3: AMAD (AMADCommBridge) - defined Bridge with Socketport 8090
2018.08.05 14:12:22 3: AMAD (AMADCommBridge) - Attention!!! By the first run, dont forget to "set AMADCommBridge fhemServerIP <IP-FHEM>"
2018.08.05 14:12:22 3: AMADCommBridge: port 8090 opened
2018.08.05 14:12:23 1: HMLAN_Parse: HMUSB new condition disconnected
2018.08.05 14:12:23 3: Opening HMUSB device 127.0.0.1:1234
2018.08.05 14:12:23 1: HMLAN_Parse: HMUSB new condition init
2018.08.05 14:12:23 3: HMUSB device opened
2018.08.05 14:12:26 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet/:
2018.08.05 14:12:26 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2018.08.05 14:12:26 1: Including ./log/fhem.save
2018.08.05 14:12:26 3: Device AbstellraumFeuchte added to ActionDetector with 000:10 time
2018.08.05 14:12:26 3: Device AbstellraumTuer added to ActionDetector with 002:50 time
2018.08.05 14:12:26 3: Device Brunnen added to ActionDetector with 000:10 time
2018.08.05 14:12:26 3: Device Einfahrt added to ActionDetector with 028:00 time
2018.08.05 14:12:27 3: Device GaragenTor added to ActionDetector with 028:00 time
2018.08.05 14:12:27 3: Device Gartenhuette added to ActionDetector with 028:00 time
2018.08.05 14:12:27 3: Device HM_5455FD added to ActionDetector with 000:10 time
2018.08.05 14:12:27 3: OWServer: Opening connection to OWServer localhost:4304...
2018.08.05 14:12:27 3: OWServer: Successfully connected to localhost:4304.
2018.08.05 14:12:31 0: Featurelevel: 5.8
2018.08.05 14:12:31 0: Server started with 157 defined entities (fhem.pl:17089/2018-08-04 perl:5.024001 os:linux user:fhem pid:948)
2018.08.05 14:12:31 3: CUL_HM set GaragenLicht statusRequest
2018.08.05 14:12:31 1: HMLAN_Parse: HMUSB new condition ok
2018.08.05 14:12:32 3: CUL_HM set GartenLicht statusRequest
2018.08.05 14:12:34 3: CUL_HM set PoolPumpe statusRequest
2018.08.05 14:12:37 3: CUL_HM set SolarPumpe statusRequest
2018.08.05 14:12:38 3: CUL_HM set AbstellraumHZ statusRequest
2018.08.05 14:12:39 3: CUL_HM set Roboter statusRequest
2018.08.05 14:12:40 3: CUL_HM set Heizung_Brunnen statusRequest
2018.08.05 14:12:41 3: CUL_HM set MV_Brunnen statusRequest
2018.08.05 14:12:42 3: CUL_HM set pHSteuerung statusRequest
2018.08.05 14:12:43 3: CUL_HM set PoolRollladen statusRequest
2018.08.05 14:12:45 3: CUL_HM set PoolGrasBewaesserung statusRequest
2018.08.05 14:12:46 3: CUL_HM set Poolbeleuchtung statusRequest
Mit TOP sehe ich nur das der w1_bus_master zwischen 15 und 45% CPU verbraucht - ist das ein normaler Wert???
Werde beobachten
Gruß
Helmut
@Bartimaus
das ist das Ergebnis von Apptime max
active-timers: 56; max-active timers: 57; max-timer-load: 2 min-tmrHandlingTm: 0.3ms; max-tmrHandlingTm: 2016.5ms; totAvgDly: 34.0ms
name function max count total average maxDly avgDly TS Max call param Max call
tmr-OWDevice_UpdateValues HASH(0x3f8ffe0) 1074 10 9500.83 950.08 164.32 20.01 05.08. 14:22:38 HASH(SolarSensor)
tmr-OWDevice_UpdateValues HASH(0x3f36bb0) 1066 10 9307.43 930.74 958.31 97.29 05.08. 14:18:48 HASH(Abstellraum)
tmr-OWDevice_UpdateValues HASH(0x3f91a40) 1066 10 9415.66 941.57 9.38 5.64 05.08. 14:22:47 HASH(PoolSensor)
tmr-OWDevice_UpdateValues HASH(0x3f90cb8) 1065 10 9239.44 923.94 97.52 11.15 05.08. 14:22:37 HASH(LuftTemp_Telefonmast)
tmr-OWDevice_UpdateValues HASH(0x3f36c70) 1046 10 9223.00 922.30 10.62 6.70 05.08. 14:22:35 HASH(Garage)
tmr-OWDevice_UpdateValues HASH(0x3f937f8) 1039 10 9163.01 916.30 56.27 7.00 05.08. 14:22:36 HASH(Technik_Pool)
WEB_10.0.0.18_61163 FW_Read 236 37 1587.11 42.89 0.00 0.00 05.08. 14:20:07 HASH(WEB_10.0.0.18_61163)
WEB_10.0.0.18_61165 FW_Read 158 29 1523.23 52.53 0.00 0.00 05.08. 14:20:07 HASH(WEB_10.0.0.18_61165)
WEB_10.0.0.18_61131 FW_Read 108 36 757.13 21.03 0.00 0.00 05.08. 14:20:06 HASH(WEB_10.0.0.18_61131)
HMUSB HMLAN_Read 93 40 814.75 20.37 0.00 0.00 05.08. 14:27:28 HASH(HMUSB)
FileLog_PoolSensor FileLog_Get 77 23 894.27 38.88 0.00 0.00 05.08. 14:20:08 HASH(FileLog_PoolSensor); FileLog_PoolSensor; -; -; 2018-08-05_00:00:00; 2018-08-06_00:00:00; 4:temperature
FileLog_SolarSensor FileLog_Get 75 23 1104.34 48.01 0.00 0.00 05.08. 14:20:08 HASH(FileLog_SolarSensor); FileLog_SolarSensor; -; -; 2018-08-05_00:00:00; 2018-08-06_00:00:00; 4:temperature
tmr-RFHEM_GetUpdate HASH(0x4012898) 70 1 70.88 70.88 3.34 3.34 05.08. 14:27:31 HASH(FHEMHaus)
tmr-Weather_GetUpdate HASH(0x3e62800) 65 2 98.66 49.33 303.54 190.53 05.08. 14:27:39 HASH(Wetter)
FileLog_LuftTemp_Telefonmast FileLog_Get 54 23 287.35 12.49 0.00 0.00 05.08. 14:20:08 HASH(FileLog_LuftTemp_Telefonmast); FileLog_LuftTemp_Telefonmast; -; -; 2018-08-05_00:00:00; 2018-08-06_00:00:00; 4:temperature
tmr-SYSMON_Update HASH(0x3b7bdf8) 45 10 427.99 42.80 5.12 3.61 05.08. 14:19:24 HASH(sysmon)
SolarDiff DOIF_Notify 34 141 531.80 3.77 0.00 0.00 05.08. 14:27:39 HASH(SolarDiff); HASH(SolarSensor)
di_BrunnenTemp DOIF_Notify 24 141 106.80 0.76 0.00 0.00 05.08. 14:27:28 HASH(di_BrunnenTemp); HASH(Brunnen)
battStatus readingsGroup_Notify 23 141 181.96 1.29 0.00 0.00 05.08. 14:18:29 HASH(battStatus); HASH(AbstellraumFeuchte)
tmr-Twilight_sunpos HASH(0x433ed30) 23 1 23.22 23.22 1.31 1.31 05.08. 14:22:25 HASH(Daemmerung_sunpos)
tmr-Twilight_sunpos HASH(0x4420c70) 22 1 22.48 22.48 1.48 1.48 05.08. 14:27:25 HASH(Daemmerung_sunpos)
tmr-AMAD_checkDeviceState HASH(0x2ea22d8) 22 7 49.60 7.09 6.01 3.95 05.08. 14:20:22 HASH(TabletGarage)
WEB_10.0.0.18_61830 FW_Read 8 3 8.88 2.96 0.00 0.00 05.08. 14:27:29 HASH(WEB_10.0.0.18_61830)
FileLog_SolarSensor FileLog_Log 8 10 20.83 2.08 0.00 0.00 05.08. 14:19:37 HASH(FileLog_SolarSensor); HASH(SolarSensor)
FileLog_AbstellraumFeuchte FileLog_Log 7 4 11.40 2.85 0.00 0.00 05.08. 14:21:02 HASH(FileLog_AbstellraumFeuchte); HASH(AbstellraumFeuchte)
tmr-CUL_HM_ActCheck ActionDetector 7 1 7.44 7.44 3.11 3.11 05.08. 14:22:27 ActionDetector
FileLog_sysmon FileLog_Log 7 20 26.22 1.31 0.00 0.00 05.08. 14:18:25 HASH(FileLog_sysmon); HASH(sysmon)
di_Solar1 DOIF_Notify 6 141 112.72 0.80 0.00 0.00 05.08. 14:21:37 HASH(di_Solar1); HASH(SolarDiff)
FileLog_Abstellraum FileLog_Log 6 10 19.21 1.92 0.00 0.00 05.08. 14:25:49 HASH(FileLog_Abstellraum); HASH(Abstellraum)
WEB_10.0.0.18_61820 FW_Read 6 2 9.12 4.56 0.00 0.00 05.08. 14:27:26 HASH(WEB_10.0.0.18_61820)
FileLog_Brunnen FileLog_Log 6 4 10.65 2.66 0.00 0.00 05.08. 14:25:13 HASH(FileLog_Brunnen); HASH(Brunnen)
WEB_10.0.0.18_61821 FW_Read 5 2 8.62 4.31 0.00 0.00 05.08. 14:27:26 HASH(WEB_10.0.0.18_61821)
di_GartenLichtEinfahrt DOIF_Notify 4 141 56.77 0.40 0.00 0.00 05.08. 14:27:25 HASH(di_GartenLichtEinfahrt); HASH(Daemmerung)
di_AbstellraumTemp DOIF_Notify 4 141 64.99 0.46 0.00 0.00 05.08. 14:25:49 HASH(di_AbstellraumTemp); HASH(Abstellraum)
di_Solar2 DOIF_Notify 4 141 92.08 0.65 0.00 0.00 05.08. 14:18:46 HASH(di_Solar2); HASH(SolarDiff)
telnetPort telnet_Read 4 10 42.50 4.25 0.00 0.00 05.08. 14:25:25 HASH(telnetPort)
di_Brunnen DOIF_Notify 4 141 43.81 0.31 0.00 0.00 05.08. 14:25:13 HASH(di_Brunnen); HASH(Brunnen)
GaragenLicht CUL_HM_Set 4 1 4.20 4.20 0.00 0.00 05.08. 14:27:25 HASH(GaragenLicht); GaragenLicht; ?
di_AbstellraumTempAutomatik DOIF_Notify 3 141 59.07 0.42 0.00 0.00 05.08. 14:20:48 HASH(di_AbstellraumTempAutomatik); HASH(Abstellraum)
Wasserstand CUL_HM_Set 3 1 3.67 3.67 0.00 0.00 05.08. 14:27:25 HASH(Wasserstand); Wasserstand; ?
GartenLicht CUL_HM_Set 3 1 3.65 3.65 0.00 0.00 05.08. 14:27:25 HASH(GartenLicht); GartenLicht; ?
Dein Fhem scheint auf eine Antwort vom OWServer zu warten...
Schon mal da geguckt? https://wiki.fhem.de/wiki/OWServer_%26_OWDevice#FHEM_h.C3.A4ngt.2C_wenn_OWServer_nicht_erreichbar_ist
Also mal ernsthaft, wenn ping nicht geht (und das ist KERNEL Arbeit), dann geht der rest auch nicht.
Kurzgefasst: Ein Rechner der nicht anpingbar ist, hat ein Kernelproblem. FHEM läuft aber nicht im Kernelbereich (oder Du machst einen Fehler),
Daher: Repariere Dein Netzwerk
DANN kannst Du Dir "den Rest" angucken ....
Zitat von: amenomade am 05 August 2018, 18:18:54
Dein Fhem scheint auf eine Antwort vom OWServer zu warten...
Schon mal da geguckt? https://wiki.fhem.de/wiki/OWServer_%26_OWDevice#FHEM_h.C3.A4ngt.2C_wenn_OWServer_nicht_erreichbar_ist
Nonblocking steht auf 1
Zitat von: Wernieman am 05 August 2018, 19:11:26
Also mal ernsthaft, wenn ping nicht geht (und das ist KERNEL Arbeit), dann geht der rest auch nicht.
Kurzgefasst: Ein Rechner der nicht anpingbar ist, hat ein Kernelproblem. FHEM läuft aber nicht im Kernelbereich (oder Du machst einen Fehler),
Daher: Repariere Dein Netzwerk
DANN kannst Du Dir "den Rest" angucken ....
Das Netz funktioniert. Ich nehme an der Pi ist defekt? Bin dabei einen anderen zu verwenden und das System neu aufzusetzen
und dann werde ich vielleicht statt ow Server owx async verwenden ??
Ich kennen Dein Netz nicht, deshalb kann ich es dir nicht sagen ....
Es könnte auch die Netzwerkkomponente davor sein oder das Netwerkkabel oder .... oder ...
Sorry aber für nähere Tipps braucht man nähere/tiefere Informationen.
Siehe Signatur:
Für Mehr Output bitte mehr Input
servus na klar Fernwartung durch die Glaskugel ist besonders bei Netzwerken schwierig.
Ich verwende um in die Garage zur Steuerung zu kommen ein Devolo PowerLan1200
in der Garage hängt ein 5 fach Switch. An dem hängt der Pi (Netzwerkkabel habe ich bereits getauscht) und dann hängt ein alter Netgear als accessPoint.
Der breitet das WLAN in der Garage für das Tablet aus. Tablet dient mit AMAD zur Anzeige und Steuerung.
Als der pi ausfiel, hatte ich aber über das Tablet Zugriff aufs iNet. Also sollte das Netz funktionieren.
DAs einzige was mir aufgefallen ist, ist folgendes: mein iMac hing damals auch per lanKabel im Haus/AZ im PowerLan.
iNet vorhanden aber der Zugriff auf die Weboberfläche war nicht möglich - ABER vom iPhone aus konnte ich die Steuerung erreichen.
So, nun habe ich den iMac vom Lan genommen und per WLAN verbunden - dann konnte ich den Pi wieder erreichen.
WLAN im Haus und PowerLan sind im selben IP Bereich im selben SubNet. Das ist schon strange oder?
Im Moment läuft alles zur vollsten Zufriedenheit, aber ich traue dem Frieden nicht.....
Gruß
Helmut
Zitat von: Helmi55 am 06 August 2018, 18:48:22
So, nun habe ich den iMac vom Lan genommen und per WLAN verbunden - dann konnte ich den Pi wieder erreichen.
Konflikt bei der Vergabe von IP-Adressen? Benutzt du zufällig eine Fritzbox die kürzlich aktualisiert wurde?
Nein keine Fritzbox. Habe hier in Ö von A1 eine Hybridbox.
schon mal die ports vom switsch getauscht?
Switchhersteller?
Eventuell den Switch/WLAN-Acesspoint mal probiert zu rebooten?
Könnte auch eine übergelaufende MAC-Tabelle in einem Netzwerkgerät sein ....
TP-Link (https://www.amazon.de/gp/product/B00A128S24/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1)
Ja, Switch und AccessPoint habe ich für 1 Minute vom Netz genommen,auch den PowerLan Adapter in der Garage
Kann jetzt noch testen, den Pi direkt an die PowerLan Dose zu hängen. Muss ich halt auf das Tablett verzichten. Für einen Versuch?
TP-Link habe ich privat auch ... leider auch beruflich. Deren MAC-Tabelle ist seeeeehr klein.
Fürs debugging kannst Du gerne probieren. Ob es die Ursache/Lösung ist ....
D.h. Ich müsste den Switch wöchentlich rebooten.? Ließe sich mit einem alten IT Schalter dazwischen lösen
Nicht sauber, könnte aber helfen?
Zitat von: Helmi55 am 07 August 2018, 09:10:02
D.h. Ich müsste den Switch wöchentlich rebooten.? Ließe sich mit einem alten IT Schalter dazwischen lösen
Nicht sauber, könnte aber helfen?
Meinst nicht es wäre besser die Ursache komplett zu eliminieren? Ich würde einfach einen neuen kaufen für 20 Euro
Wenn es die Ursache ist ... wir haben noch keinen Beweis dafür. Netzwerfehler zu finden kann viel Zeit kosten ....
Hallo zusammmen,
versuche gerade seit Tagen einen Raspberry Pi (2 Mod B) mit Raspbian Stretch Lite (2018-11-13, 4.14) und fhem (5.9) nach Anleitung (https://wiki.fhem.de/wiki/Raspberry_Pi) aufzusetzen.
An meinem Pi hängt nichts außer die Stromversorgung, HDMI und das Netzwerkkabel.
Installation von Raspbian Stretch Lite ging reibungslos, anschließendes Update wurde auch durchgeführt.
Somit auch keine Netzwerkprobleme
Nach der Installation von fhem lag die CPU-Last auch bei 100% :o :(
Danach gegoogelt und vieles probiert .... (Empfohlenen Patch laut wiki ausgeführt / sleep in perl fhem.pl fhem.cfg eingefügt / usw.)
Was geholfen hat, war über den "harten" Weg ..
sudo nano /opt/fhem/fhem.cfg
in der "fhem.cfg" die Zeile :
# define initialUsbCheck notify global:INITIALIZED usb create
etweder komplett auszukommentieren oder über
define initialUsbCheck notify global:INITIALIZED usb create
attr initialUsbCheck disable 1
zu deaktivieren.
Danach getestet und mehrfach neu gebootet, fhem sowie RasPi, und ohne das ein einziges mal die CPU Last wieder bei 100% hängen blieb.
Nun werd ich das System mal weiter aufbauen und hoffen das nichts mehr hängen bleibt ...
Vielleicht bringt die Hilfe ja dem Einen oder Anderen etwas.
Viel Erfolg weiterhin :-)
Danke! Dies hat bei mir auch geholfen!
Nun startet FHEM direkt nach einem Raspi-Neustart. Zuvor muste ich FHEM mit:
sudo systemctl stop fhem.service stoppen (dauert ~1min) und anschließen mit
sudo systemctl start fhem.service wieder starten.
Hatt gleiches Phänomen.. auch bei mir die USB check Zeile auskommentiert und läuft