(gelöst) Nach update läuft Fhem nicht mehr mit 34_ESPEasy.pm

[Medel]

Hallo,

nach dem Update das ich heute morgen gemacht habe startet Fhem nicht mehr.
Hier der Start Log:

Code Auswählen Erweitern

2019.05.12 10:23:05 1: Including fhem.cfg
2019.05.12 10:23:46 1: HMCCU: [myccu] Initialized version 4.3.015
2019.05.12 10:23:46 1: HMCCU: [myccu] HMCCU: Initializing device
2019.05.12 10:23:47 1: HMCCU: [myccu] HMCCU: Read 16 devices with 217 channels from CCU 192.168.1.33
2019.05.12 10:23:47 1: HMCCU: [myccu] HMCCU: Read 3 interfaces from CCU 192.168.1.33
2019.05.12 10:23:47 1: HMCCU: [myccu] HMCCU: Read 4 programs from CCU 192.168.1.33
2019.05.12 10:23:47 1: HMCCU: [myccu] HMCCU: Read 0 virtual groups from CCU 192.168.1.33
2019.05.12 10:23:48 1: mysduino/define: /dev/ttyCUL2
2019.05.12 10:23:48 1: mysduino/init: /dev/ttyCUL2
2019.05.12 10:23:49 1: HMCCURPCPROC: [d_rpc001033BidCos_RF] Initialized version 1.7.001 for interface BidCos-RF with I/O device myccu
2019.05.12 10:23:49 1: HMCCURPCPROC: [d_rpc001033HmIP_RF] Initialized version 1.7.001 for interface HmIP-RF with I/O device myccu
2019.05.12 10:23:50 1: Including ./log/fhem.save
2019.05.12 10:23:51 1: ESPEasy myEspEasy: Error: Can't open server port [TCP:IPV4:8383]
2019.05.12 10:23:51 1: ESPEasy myEspEasy: Address already in use
2019.05.12 10:23:51 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2019.05.12 10:23:51 1: myfrm: Can't open /dev/ttyFRM: No such file or directory
2019.05.12 10:23:51 3: myowserver: Opening connection to OWServer 127.0.0.1:4304...
2019.05.12 10:23:51 3: myowserver: Successfully connected to 127.0.0.1:4304.
2019.05.12 10:23:51 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 496.
2019.05.12 10:23:51 0: Featurelevel: 5.9
2019.05.12 10:23:51 0: Server started with 344 defined entities (fhem.pl:19376/2019-05-11 perl:5.024001 os:linux user:fhem pid:2928)
2019.05.12 10:23:51 1: hm485: HM485d already running with PID  1551. We are using this process.
Can't use an undefined value as a symbol reference at ./FHEM/34_ESPEasy.pm line 951.
2019.05.12 10:31:22 1: SIP_Tel[2969], can´t find my parent 2928 in process list !
Died at ./FHEM/96_SIP.pm line 386.

wenn ich die alte fhem.pl vom 06.05.2019 einspiele geht es.

Gruß

Mario

[eppi]

Bei mir auch selbes Verhalten und Logeintrag. Ebenfalls Rollback auf die vorgehende fhem.pl (Version 6.5.2019) gemacht.
LG Eppi

[Gigafix]

Auch bei mir gleiches Problem - ich habe erst einmal die Datensicherung von gestern wieder eingespielt. Gibt es schon Erkenntnisse welches Update das Problem erzeugt?

Hier die Liste für die Module die ich heute upgedatet habe:

Code Auswählen Erweitern

fhem
List of new / modified files since last update:
UPD ./CHANGED
UPD ./fhem.pl
UPD FHEM/10_MYSENSORS_DEVICE.pm
UPD FHEM/70_Pushover.pm
UPD FHEM/73_AutoShuttersControl.pm
UPD FHEM/88_HMCCU.pm
UPD FHEM/88_HMCCURPCPROC.pm
UPD FHEM/91_notify.pm
UPD FHEM/98_Heating_Control.pm
UPD FHEM/98_WeekdayTimer.pm
UPD FHEM/98_autocreate.pm
UPD FHEM/DevIo.pm
UPD FHEM/UConv.pm
UPD docs/commandref_frame.html
UPD docs/commandref_frame_DE.html

New entries in the CHANGED file:
- bugfix:  88_HMCCU: Flag for disabling initial device update
- bugfix:  10_MYSENSORS_DEVICE: prevent fhem crashing by ack timeout
             at higher verobse levels
- change:  98_Heating_Control.pm will be removed soon. Users will need to
             change their device definitions to 98_WeekdayTimer; supporting
             code is provided, but perl calls have to be changed manually.
- bugfix:  73_AutoShuttersControl: fix bug roommate and windwo comfort
- bugfix:  73_DoorBird: Error 404 handling for history images corrected
- bugfix:  73_AutoShuttersControl: fix sunset sunrise object values
- feature: 74_AMADtaskerset_4.4.0.prj: add nfc tag support in taskerset
               74_AMADautomagicflowset: fix bug then use VLC player
- feature: 73_DoorBird: Images can be stored as JPGs
- feature: 73_DoorBird: Secure communication with https ans SessionID
- bugfix:  73_AutoShuttersControl: fix brightness detection for IsDay,
               fix detection for manual driveing
- bugfix:  73_GardenaSmartBridge: fix the fix
- bugfix:  73_GardenaSmartBridge: check if defined $data
- bufix:   55_DWD_OpenData: SunUp calculation (forum #83097 msg #931972)
- feature: 10_RESIDENTS: add home alone mode
- new:     20_PET: new RESIDENTS module type for pets at home
- bugfix:  73_AutoShuttersControl: fix bugs and logic problems
- feature: 98_weekprofile: HMCCU support
- change:  10_MYSENSORS_DEVICE: enhance support for SetExtensions;
                      separate readings for heatrbeat, smartSleep & NACK
- bugfix:  73_GardenaSmartBridge: fix undefined_value Error
- feature: 98_Text2Speech: add Amazon Polly as new suggested TTS-Engine
... rest of lines skipped.

[roedert]

Gibt es schon Erkenntnisse welches Update das Problem erzeugt?

Es kann nur die fhem.pl selbst sein. Hatte heute morgen den gleichen Fehler und zuerst nur das Modulverzeichnis /opt/fhem/FHEM wiederhergestellt, aber immer noch den gleichen Fehler. Erst nach kompletten Restore von /opt/fhem lief es wieder.

[zentis666]

Hallo,

bei mir kommt fhem nach Update auch nicht mehr hoch, ich habe am Ende des logfiles

Code Auswählen Erweitern

Can't use an undefined value as a symbol reference at ./FHEM/34_ESPEasy.pm line 951.

Nachdem ich 34_ESPEasy.pm umbenannt und neu gestartet habe kommt fhem wieder hoch,
scheint als was mit der Datei zu tun zu haben.

Gruß
Sven

[no_Legend]

Hallo,

bei mir kommt fhem nach Update auch nicht mehr hoch, ich habe am Ende des logfiles

Code Auswählen Erweitern

Can't use an undefined value as a symbol reference at ./FHEM/34_ESPEasy.pm line 951.

Nachdem ich 34_ESPEasy.pm umbenannt und neu gestartet habe kommt fhem wieder hoch,
scheint als was mit der Datei zu tun zu haben.

Gruß
Sven

Hab das gleiche, gerade ein Update gemacht.

Die Datei hat sich aber Seit Februar nicht geändert.
Hab gerade im SVN nachgeschaut

[zentis666]

Hi,
ich hab noch ein bischen in den logs rumgewühlt, hatte ja mehrmals neu gestartet.
Es kommt immer das gleiche Muster:

Code Auswählen Erweitern


2019.05.12 14:42:32 3: ESPEasy ESPBridge: Bridge v2.18 port [TCP:IPV4:8383] opened.
<... Zeilen gelöscht ...>
2019.05.12 14:42:33 1: ESPEasy ESPBridge: Error: Can't open server port [TCP:IPV4:8383]
2019.05.12 14:42:33 1: ESPEasy ESPBridge: Address already in use
<... Zeilen gelöscht ...>
Can't use an undefined value as a symbol reference at ./FHEM/34_ESPEasy.pm line 951.


Vielleicht hilft das bei der Fehlersuche,
Gruß
Sven

[Maista]

Moin,

schön das ich nicht ein Einzelfall bin :

Die ESPBridge erkennt nach neu anlegen zwar die Devices und zeigt sie an.
Nach einem shutdown restart kommt erneut die Meldung mit dem Port 8383.

Mit der "fhem.pl  19328 2019-05-04 19:13:22Z" läufts wieder.

Gruss Gerd

Edit: Gleiche Thema https://forum.fhem.de/index.php?topic=97340.new;topicseen#new

[stefanru]

Bei mir auch das gleiche.
Das seltsame ist ja wirklich die Datei war gar nicht beim update dabei?

Ich schau mal in die line 951 rein.
my $ret = sysread($hash->{CD}, $buf, 9000); # accept jumbo frames
Da will er das erstmal lesen. Geht wahrscheinlich in die Hose weil er den Port nicht bekommen hat.
Bleibt die Frage warum der Port überhaupt offen geblieben ist?

Ok, selbst ein restart des Raspberry hilft nicht. Heißt der Port bleibt nicht offen. Sehr seltsam.

Kommentiert man die Zeile 951 aus kommt FHEM hoch, aber ohne ESP.

Messages collected while initializing FHEM:
configfile: Cannot load module ESPEasy

Ok bin jetzt auch erstmal wie von Maista geschrieben auf "fhem.pl  19328 2019-05-04 19:13:22ZW zurück.


Gruß,
Stefan

[bugster_de]

bei mir das Gleiche. Ich hatte seit Monaten kein Update mehr gemacht und wollte den verregneten Sonntag dazu nutzen. Habe ich jetzt auch genutzt, nur anders als gedacht ....

Nach etliche Reboots hatte ich auch die 34_ESPEasy.pm umbenannt. Jetzt kommt FHEM wieder hoch, aber die Hälfte aller Lampen im Haus kann man nicht mehr schalten, da sie auf ESP basieren

[Medel]

Hallo,

alte fhem.pl aus dem restoreDir wieder einspielen sollte bis zum beseitigen des Fehlers helfen.

Gruß Mario

[CoolTux]

Es gab seit der Version vom 04.05 nur Änderungen im Bereich sleep Befehl.

[Medel]

Das Modul 34_ESPEasy.pm welches offensichtlich die Probleme mit der geänderten fhem.pl verursacht benutzt wahrscheinlich diese funktion.

[CoolTux]

Eigentlich nicht. Die angemeckerte Stelle 951 ist die ruft eine Funktion sysread() auf. Ich gehe davon aus das $hash->{CL} Probleme hat.

[Medel]

Die angemeckerte Stelle 951 kann aber auch eine Meldung der fehlenden Verbindung sein. Davor kommt:

Code Auswählen Erweitern


ESPEasy myEspEasy: Error: Can't open server port [TCP:IPV4:8383]
ESPEasy myEspEasy: Address already in use


Ich vermute es hat mit der geänderten Funktion

Code Auswählen Erweitern

-   CommandDelete($cl, $name) if($defs{$name});
+   CommandDelete($cl, $sleepers{$id}{name}) if($sleepers{$id});
zu tun. Die wird ja zwei mal in 34_ESPEasy.pm verwendet.

[CoolTux]

Ja und Nein.

CommandDelete löscht ein Device in FHEM. Und ich denke das ist es.
Es wird wenn ein Geräte Daten an den TcpServerSocket senden will in FHEM eine temporäres Device angelegt über das dann quasi die Daten kommen. Eigentlich es es die Verbindung. Aus irgendeinem Grund ist aber die Verbindung nicht mehr da wenn er versucht zu lesen.

[CoolTux]

Ich habe mich gewundert wieso das nicht sauber funktionieren soll mit TcpServer_Open.
Die Antwort ist das nicht die original Funktion aus TcpServerUtils verwendet wird sondern eine abgewandelte Kopie.
Aber wo jetzt genau der Haken ist vermag ich nicht zu sagen.

[Gasmast3r]

Hy selbst wenn ich FHEM neu aufsetze macht es Probleme.

Neu definierte Sachen dauern gefühlt ewig bis ich die verwenden kann.

Da muss irgendwie mehr im argen sein.


Gesendet mit Tapatalk

[rudolfkoenig]

bei mir kommt fhem nach Update auch nicht mehr hoch

Kannst du bitte ein "attr global verbose 5" Log hier anhaengen?

CommandDelete($cl, $sleepers{$id}{name}) if($sleepers{$id});

Von welcher Version von 34_ESPEasy.pm ist hier die Rede? Ich finde kein sleepers in 34_ESPEasy.pm.
Auch CommandSleep (wo diese Zeile vorhanden ist) wird nicht aufgerufen.
Die letzte Aenderung in fhem.pl betraf sleep (und die Daten in sleepers), aber %sleepers ist fhem.pl lokal.

Hy selbst wenn ich FHEM neu aufsetze macht es Probleme.

Solche Aussagen helfen niemanden weiter (es sei denn man will nur Frust loswerden, aber dann lieber beim Pfarrer oder Psychiater).
Ich haette gerne auch in diesem Fall ein "attr global verbose 5" (oder perl fhem.pl -d fhem.cfg) Log.

[CoolTux]

Guten Morgen Rudi,

Mein Verdacht. Vielleicht hilft es etwas.
In der erwähnten Zeile wird sysread mit $hash->{CL} aufgerufen. Aber anscheinend gibt es $hash->{CL} da nicht mehr. Grund könnte der vorher ausgeführte CommandDelete für das temporäre Device alias TcpServer Client-Verbindung sein. Eine grobe Vermutung!!!


Grüße

[sash.sc]

Hallo zusammen.

habe mal bei mir nachgeschaut. Soweit läuft das ganze System, auch ESPEasy.

Hier mal meine Versionsübersicht.
Hoffe es hilft weiter.

Code Auswählen Erweitern


Latest Revision: 19330

File                       Rev   Last Change

fhem.pl                    19328 2019-05-04 19:13:22Z rudolfkoenig

34_ESPEasy.pm              18608 2019-02-16 09:03:52Z dev0


Habe es mal auf die hoffentlich interessanten Angaben zusammen geschrumpft.

Hier nochmal das List von der ESPBridge

Code Auswählen Erweitern


Internals:
   CONNECTS   26708
   DEF        bridge 8383
   FD         58
   FUUID      5c430274-f33f-852e-23e2-a5b424e6203f9c26
   FVERSION   34_ESPEasy.pm:0.186080/2019-02-16
   HOST       bridge
   IPV        4
   MAX_HTTP_SESSIONS 3
   MAX_QUEUE_SIZE 250
   NAME       espBridge
   NOTIFYDEV  global
   NR         287
   NTFY_ORDER 50-espBridge
   PORT       8383
   STATE      Initialized
   SUBTYPE    bridge
   TYPE       ESPEasy
   VERSION    2.18
   READINGS:
     2019-05-12 14:13:02   state           Initialized
   helper:
     maxCmdDuration:
       192.168.2.30 1
     pm:
       Encode     1
       JSON       1
     sessions:
       192.168.2.30 0
Attributes:
   authentication 0
   autocreate 1
   combineDevices 0
   devStateIcon I|initialized:WLAN_Status.1 disconnected:WLAN_Status.0
   group      ESPEasy
   icon       cul_wlan
   room       99_receiver,ESPEasy
   verbose    0


Gruß
Sascha

[CoolTux]

Ach Mist. Ich dachte Du hättest auch die letzten Tag ein Update gemacht.
Aber ist ok, mit der fhem.pl Version vom 04.05 geht es, erst mit einer nachfolgenden Version das ESPeasy Modul die Probleme.

Aber trotzdem vielen Dank für Deine Angaben.

[sash.sc]

Nee. Bin zwar ein Update Junkie, aber nur als 2 bis 3 Wochen... [emoji6]

Ich warte dann mal lieber....

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

[rudolfkoenig]

In der erwähnten Zeile wird sysread mit $hash->{CL} aufgerufen. Aber anscheinend gibt es $hash->{CL} da nicht mehr. Grund könnte der vorher ausgeführte CommandDelete für das temporäre Device alias TcpServer Client-Verbindung sein.

Mag alles sein, hilft mir aber nicht, da ich nicht weiss, wo ich suchen soll:
- ich habe nicht bewusst ein $hash->{CD} entfernt (CD: FD nach accept, und nicht CL: Benutzerverbindungs-Hash)
- ich habe die sleep-internas umgebaut, aber ESPEasy verwendet kein FHEM-Sleep
- an CommandDelete hat sich nichts geaendert. Wo kommt die Theorie her, dass CommandDelete die Ursache ist?
- ich habe auf die Schnelle (ohne ein mit ESPEasy geflashtes Geraet zu haben) kein ESPEasy-Testsetup hingekriegt, das waere aber sinnvoll.

Zum Fixen brauchen ich Hilfe ("attr global verbose 5" Output, Patch, Test-Config, Hinweis auf die Ursache, etc), aber nicht sowas wie "bei mir geht es auch nicht".

[rico5588]

Hallo,

nach einem Update läuft mein System in einer Schleife...
Anbei mein Log.

MFG Rico

[CoolTux]

CommandDelete hat ein User eingeworfen. Warum auch immer.

Es wird ja ein CommandDelete ausgelöst in der Read Funktion und damit wird das temporäre Device (die Clientvernindung) gelöscht. Somit ist dann auch $hash-{CL} weg.

Aber wie Du schon sagtest das alles ist nur spekulatius. Ich habe noch einige User in anderen Threads die den Fehler gemeldet haben, die nötige ich gerade zu einem Verbose 5 

Und ich denke mal ich werde dev0 bescheid geben, ist sein Modul.

[CoolTux]

Hallo,

nach einem Update läuft mein System in einer Schleife...
Anbei mein Log.

MFG Rico

Kannst Du das noch mal mit globalen verbose 5 bitte machen.

[rico5588]

UPS,

da ist wohl was schief gegangen.

[CoolTux]

@Medel
Kannst Du bitte den Threadtitel besser wählen. Einfach den ersten Post editieren. Baue bitte ESPEASY Modul mit ein

[rico5588]

Noch eine Anmerkung,

in meinem Testsystem habe  ich neben einer frischen Fhem Installation nur das Modul AptTodate, fhemInstaller,FluxLED,Wifilight und ESPEasy am laufen.
Fhem als solches macht was es soll. (auch nach Reboot und Update)
Nur ESPEasy geht in Error und legt keine devise an.
Anbei das LOG mit global verbose 5

[Wernieman]

Ich habe es jetzt bei mir getestet ...
1. FHEM kommt nach einem Update hoch ... aber das ESPEasy steht anschließend auf "error"
2. Nach dem rückspielen der (gesicherten) fhem.pl funktioniert es wieder
3. Verbose 5 Ausgabe des relevanten Teils (nicht mehr zu sehen):

.....
2019.05.13 10:40:06 1: HMCCU: [ccu2] HMCCU: Read 1 programs from CCU ccu2.maxel.home
2019.05.13 10:40:06 1: HMCCU: [ccu2] HMCCU: Read 4 virtual groups from CCU ccu2.maxel.home
2019.05.13 10:40:06 3: telnetSSL: port 7073 opened
2019.05.13 10:40:07 3: ESPEasy ESPEasy: Bridge v2.18 port [TCP:IPV4:8086] opened.
2019.05.13 10:40:08 1: Including ./log/fhem.save
2019.05.13 10:40:08 1: ESPEasy ESPEasy: Error: Can't open server port [TCP:IPV4:8086]
2019.05.13 10:40:08 1: ESPEasy ESPEasy: Address already in use
2019.05.13 10:40:08 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2019.05.13 10:40:08 0: Featurelevel: 5.9
2019.05.13 10:40:08 0: Server started with 222 defined entities (fhem.pl:19376/2019-05-11 perl:5.026001 os:linux user:fhem pid:15887)
2019.05.13 10:40:08 3: telnetForBlockingFn_1557736808: port 33737 opened
2019.05.13 10:40:08 1: ERROR: Select error -1 (9), error count= 0
2019.05.13 10:40:08 1: Found and deleted bad fileno for ESPEasy.8086
2019.05.13 10:40:08 3: FritzFone device opened
2019.05.13 10:40:20 1: HMCCU: [ccu2] Internal RPC server is depricated and will be removed soon. Set ccuflags to procrpc
2019.05.13 10:40:20 2: HMCCU: Create child process with timeouts 0.01 and 0.25
.....

Wenn wirklich benötigt kann ich mal versuchen, heute Abend ein nacktes FHEM nur mit einem espeasy Device aufzusetzen .....

[rudolfkoenig]

@rico5588:
- im angehaengten Log sehe ich keinen Absturz, geschweige denn die Ursache
- ein Copy&Paste vom Event-Monitor ist der falsche Weg, da FHEM vermutlich sich beendet, bovor FHEMWEB benachrichtigt werden kann. Besser: die Daten aus /opt/fhem/logs/fhem-2019-05.log zu nehmen. Am besten: FHEM in der Konsole mit "perl fhem.pl -d fhem.cfg" zu starten, und diese Ausgaben hier anhaengen.

Generell:
- die Meldung "ESPEasy espBridgeS0: Address already in use" ist "normal", da das Modul auf global:INITIALIZED reagiert, und versucht den Serverport nochmal zu oeffnen, ohne es vorher zu schliessen.
- Weiss jemand, warum ESPEay den Code aus TcpServerUtils dupliziert?

[CoolTux]

Es ist echt schwer zu sagen ob es wirklich am ESPEasy liegt. Direkt Abstürzen tut FHEM nicht aber meine Vermutung ist das systemd watchdog warum auch immer auf das error reagiert und FHEM neustartet.

Ich finde im Log jedenfalls nichts was direkt auf einen total Versagen von FHEM hinweist. Ausser das die "Bridge" (Device) in den Error geht.

[CoolTux]

Rudi war schneller

[CoolTux]

@rico5588:
- im angehaengten Log sehe ich keinen Absturz, geschweige denn die Ursache
- ein Copy&Paste vom Event-Monitor ist der falsche Weg, da FHEM vermutlich sich beendet, bovor FHEMWEB benachrichtigt werden kann. Besser: die Daten aus /opt/fhem/logs/fhem-2019-05.log zu nehmen. Am besten: FHEM in der Konsole mit "perl fhem.pl -d fhem.cfg" zu starten, und diese Ausgaben hier anhaengen.

Generell:
- die Meldung "ESPEasy espBridgeS0: Address already in use" ist "normal", da das Modul auf global:INITIALIZED reagiert, und versucht den Serverport nochmal zu oeffnen, ohne es vorher zu schliessen.
- Weiss jemand, warum ESPEay den Code aus TcpServerUtils dupliziert?

https://forum.fhem.de/index.php/topic,72717.0.html
Wohl deswegen laug Modulcode

[Wernieman]

Wie Rudi vorgeschlagen hat:
Ein Kurzer Test hat auf meinem FHEM-System schon 360k-Logzilen Produziert .... braucht Ihr die Ausgabe komplett, oder welche Teile?

Würde sie jetzt nur ungerne komplett veröffentlichen, da ich nicht nach secrets suchen möchte/kann ...

Und kann nur Hinweisen:
Mein FHEM stürzt nicht ab ... nur espeasy funktioniert nicht mehr ...

Edit:
Dateianhang gelöscht, da mittlerweile veraltet ..

[CoolTux]

Wie Rudi vorgeschlagen hat:
Ein Kurzer Test hat auf meinem FHEM-System schon 360k-Logzilen Produziert .... braucht Ihr die Ausgabe komplett, oder welche Teile?

Würde sie jetzt nur ungere komplett veröffentlichen, da ich nicht nach secrets suchen möchte ...

Besser alles. Ich wüsste nicht welcher Teil gerade relevant wäre. Wir konzentrieren uns zwar auf espeasy aber wer weiß.

[rudolfkoenig]

Ein Kurzer Test hat auf meinem FHEM-System schon 360k-Logzilen Produziert .... braucht Ihr die Ausgabe komplett, oder welche Teile?

_Wenn_ es zum FHEM Absturz fuehrt: die letzten 100 Zeilen sollten reichen. Kannst es auch per PM schicken.
Wenn systemd es neu startet: weiss jemand, wann systemd auf diese Idee kommt?

https://forum.fhem.de/index.php/topic,72717.0.html
Wohl deswegen laug Modulcode

Das haette man auch mit einem eigenen AuthenticateFn loesen koennen.

[Wernieman]

Habe es bei meinem Beitrag (2 davor) angehängt ....

Bitte Info, welche Information Ihr noch braucht ... ich jedenfalls sehe ich Logfile vieles ... aber nichts relevantes

Generiert mit:

Code Auswählen Erweitern

perl fhem.pl -d fhem.cfg >test.log

Edit:
@Rudi
siehe oben: Kein Absturz meinerseits. Da ich aber auch kein "standard"-Systemd config habe (gibt es eine für FHEM?), kann ich auch nicht in die Richtung gucken ....
Reines Ergebnis meinerseits: ESPEASY funktioniert nicht, ansonsten läuft fhem (aber nur oberflächlich getestet)

[CoolTux]

Wenn systemd es neu startet: weiss jemand, wann systemd auf diese Idee kommt?

Restart=always # alternativly uncomment this line for recover always
# RestartSec=5 # uncomment always if restart required!

Ich würde darauf tippen das es diese Zeilen sind. Zum testen kann man auch mal raus nehmen.

Restart=: This indicates the circumstances under which systemd will attempt to automatically restart the service. This can be set to values like "always", "on-success", "on-failure", "on-abnormal", "on-abort", or "on-watchdog". These will trigger a restart according to the way that the service was stopped.

[Wernieman]

Code Auswählen Erweitern

#Restart=always
RestartSec=5

Steht bei mir aktuell so ....

[CoolTux]

Code Auswählen Erweitern

#Restart=always
RestartSec=5

Steht bei mir aktuell so ....

Und dennoch kommen die Reboots?

Code Auswählen Erweitern

Type=forking
kannst Du das mal auf simple stellen bitte.

[Wernieman]

<scherz>
NEIN (*heul*) .. keiner hört mir zu ..
</scherz>

sorry aber habe es schon mehrfach geschrieben:
- Kein Absturz fhem
- Kein Reboot fhem
- Nur ESPEASY funktioniert nicht ....

[CoolTux]

<scherz>
NEIN (*heul*) .. keiner hört mir zu ..
</scherz>

sorry aber habe es schon mehrfach geschrieben:
- Kein Absturz fhem
- Kein Reboot fhem
- Nur ESPEASY funktioniert nicht ....

Ok das wissen wir nun warum kein Neustart. Du hast auskommentiert.
Danke Dir. Und sorry das ich das leicht überlesen habe 

[Wernieman]

Deshalb das "<scherz>" ...

Hatte hier nur reingeschrieben, um Probleme zu kanalisieren ... und um Konstruktive Fehlermeldungen zu bringen ...

[rudolfkoenig]

ESPEASY funktioniert nicht, ansonsten läuft fhem (aber nur oberflächlich getestet)

Danke. Nach mehr Analyse:
- ESPEasy oeffnet den ServerPort (etwas ungewoehnlich) in NotifyFn auf global:INITIALIZED _oder_ XXX:DEFINED
- wg. einem Programmierfehler vorgestern gibt es XXX:DEFINED Events (nur) _vor_ global:INITIALIZED
- ESPEasy versucht (vergeblich) den Port jetzt zweimal zu oeffnen, und zerstoert dabei seine eigenen internen Strukturen.

Da das Problem wg. dem fehlenden DEFINED auch andere trifft (insb. "das rote Fragezeichen " ist fuer define wirkungslos), habe ich meine Patches ab sofort fuer update zur Verfuegung gestellt.

[CoolTux]

Danke Dir Rudi.

[Frank_Huber]

Danke. Nach mehr Analyse:
- ESPEasy oeffnet den ServerPort (etwas ungewoehnlich) in NotifyFn auf global:INITIALIZED _oder_ XXX:DEFINED
- wg. einem Programmierfehler vorgestern gibt es XXX:DEFINED Events (nur) _vor_ global:INITIALIZED
- ESPEasy versucht (vergeblich) den Port jetzt zweimal zu oeffnen, und zerstoert dabei seine eigenen internen Strukturen.

Da das Problem wg. dem fehlenden DEFINED auch andere trifft (insb. "das rote Fragezeichen " ist fuer define wirkungslos), habe ich meine Patches ab sofort fuer update zur Verfuegung gestellt.

Auf meinem Testsystem verifiziert, mit aktuellem Update keine Fehler mit ESPEasy.

Danke Rudi!

[Wernieman]

Sieht bei mir jetzt auch gut aus
(Nur oberflächlich getestet)

Auch von mir:
Danke an alle Beteiligten

(War es jetzt wirklich mein Output, der es "gebracht" hatte?)

[CoolTux]

Sieht bei mir jetzt auch gut aus
(Nur oberflächlich getestet)

Auch von mir:
Danke an alle Beteiligten

(War es jetzt wirklich mein Output, der es "gebracht" hatte?)

Bezüglich systemd watchdog warst du der Gegenbeweis. Auch wichtig 

[Wernieman]

Auch wenn es jetzt in Diskussion ausufert ...

mache gerne Manöverkritik. Wollte sichergehen, das Rudi (oder wer auch immer) alle Informationen bekommen hat, welche er braucht. Auch um eventuell meine Fehlermeldungen zu verbessern.

Btw:
@Medel

Könntest Du bitte bei Dir auch testen und eventuell ein "Gelöst" vor dem Threadtitel eintragen?

Dazu einfach Deinen ersten Post bearbeiten ...

[bugster_de]

ich habe gerade einen Update gemacht. Geht wieder !
Danke für das Schnelle Fixing sowie das debugging!

[sash.sc]

Also sind die Updates morgen früh verfügbar?

Gesendet von meinem E6653 mit Tapatalk

[Frank_Huber]

Also sind die Updates morgen früh verfügbar?

Nein, jetzt schon.

[sash.sc]

Danke an alle!

Gesendet von meinem E6653 mit Tapatalk

[rico5588]

Danke ebenso läuft wieder!

[CoolTux]

Also sind die Updates morgen früh verfügbar?

Gesendet von meinem E6653 mit Tapatalk

Ausnahmsweise sind die Updates jetzt bereits Verfügbar. Ansonsten immer erst ab 8 Uhr Morgens rum.

[dev0]

Da das Problem wg. dem fehlenden DEFINED auch andere trifft (insb. "das rote Fragezeichen " ist fuer define wirkungslos), habe ich meine Patches ab sofort fuer update zur Verfuegung gestellt.

Vielen Dank für den schnellen Fix. Komme gerade erst aus dem Urlaub...

ESPEasy oeffnet den ServerPort (etwas ungewoehnlich) in NotifyFn auf global:INITIALIZED _oder_ XXX:DEFINED

Ist das Deiner Meinung nach zu ungewöhnlich, so dass ich es ändern sollte? Ich vermute das eher nicht, würde mich aber beugen und es ändern... Da der TCP Port an der einen und anderen Stelle geöffnet/geschossen wird, fande ich es übersichtlicher es zentral in der NotifyFn zu erledigen.

[rudolfkoenig]

Das Problem mit der Vorgehensweise ist, dass bestimmte Fehler beim define nicht zurueckgemeldet werden koenne. Hat dafuer Vorteile, insb. dass man auf alle Attribute zurueckgreifen kann. Will kein Urteil abgeben, ob das falsch ist oder nicht. Fuer mich war die Loesung ueberraschend, und hat deswegen 'ne Weile gedauert, bis ich die Ursache gefunden habe.