Hallo,
nach dem Update das ich heute morgen gemacht habe startet Fhem nicht mehr.
Hier der Start Log:
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
Bei mir auch selbes Verhalten und Logeintrag. Ebenfalls Rollback auf die vorgehende fhem.pl (Version 6.5.2019) gemacht.
LG Eppi
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:
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.
Zitat von: Gigafix am 12 Mai 2019, 10:55:32
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.
Hallo,
bei mir kommt fhem nach Update auch nicht mehr hoch, ich habe am Ende des logfiles
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
Zitat von: zentis666 am 12 Mai 2019, 15:02:07
Hallo,
bei mir kommt fhem nach Update auch nicht mehr hoch, ich habe am Ende des logfiles
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
Hi,
ich hab noch ein bischen in den logs rumgewühlt, hatte ja mehrmals neu gestartet.
Es kommt immer das gleiche Muster:
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
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 (https://forum.fhem.de/index.php?topic=97340.new;topicseen#new)
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
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 :-(
Hallo,
alte fhem.pl aus dem restoreDir wieder einspielen sollte bis zum beseitigen des Fehlers helfen.
Gruß Mario
Es gab seit der Version vom 04.05 nur Änderungen im Bereich sleep Befehl.
Das Modul 34_ESPEasy.pm welches offensichtlich die Probleme mit der geänderten fhem.pl verursacht benutzt wahrscheinlich diese funktion.
Eigentlich nicht. Die angemeckerte Stelle 951 ist die ruft eine Funktion sysread() auf. Ich gehe davon aus das $hash->{CL} Probleme hat.
Die angemeckerte Stelle 951 kann aber auch eine Meldung der fehlenden Verbindung sein. Davor kommt:
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
- 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.
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.
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.
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
Zitatbei mir kommt fhem nach Update auch nicht mehr hoch
Kannst du bitte ein "attr global verbose 5" Log hier anhaengen?
ZitatCommandDelete($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.
ZitatHy 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.
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
Hallo zusammen.
habe mal bei mir nachgeschaut. Soweit läuft das ganze System, auch ESPEasy.
Hier mal meine Versionsübersicht.
Hoffe es hilft weiter.
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
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
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.
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
ZitatIn 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".
Hallo,
nach einem Update läuft mein System in einer Schleife...
Anbei mein Log.
MFG Rico
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 ;D
Und ich denke mal ich werde dev0 bescheid geben, ist sein Modul.
Zitat von: rico5588 am 13 Mai 2019, 10:15:17
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.
UPS,
da ist wohl was schief gegangen.
@Medel
Kannst Du bitte den Threadtitel besser wählen. Einfach den ersten Post editieren. Baue bitte ESPEASY Modul mit ein
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
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):
Zitat
.....
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 .....
@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?
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.
Rudi war schneller
Zitat von: rudolfkoenig am 13 Mai 2019, 11:00:55
@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
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 ..
Zitat von: Wernieman am 13 Mai 2019, 11:11:53
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ß.
ZitatEin 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?
Zitat
https://forum.fhem.de/index.php/topic,72717.0.html (https://forum.fhem.de/index.php/topic,72717.0.html)
Wohl deswegen laug Modulcode
Das haette man auch mit einem eigenen AuthenticateFn loesen koennen.
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:
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)
Zitat von: rudolfkoenig am 13 Mai 2019, 11:19:51
Wenn systemd es neu startet: weiss jemand, wann systemd auf diese Idee kommt?
Zitat
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.
ZitatRestart=: 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.
#Restart=always
RestartSec=5
Steht bei mir aktuell so ....
Zitat von: Wernieman am 13 Mai 2019, 11:26:45
#Restart=always
RestartSec=5
Steht bei mir aktuell so ....
Und dennoch kommen die Reboots?
Type=forkingkannst Du das mal auf simple stellen bitte.
<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 ....
Zitat von: Wernieman am 13 Mai 2019, 11:35:52
<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 ;D
Deshalb das "<scherz>" ...
Hatte hier nur reingeschrieben, um Probleme zu kanalisieren ... und um Konstruktive Fehlermeldungen zu bringen ...
ZitatESPEASY 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.
Danke Dir Rudi.
Zitat von: rudolfkoenig am 13 Mai 2019, 11:55:04
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!
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?)
Zitat von: Wernieman am 13 Mai 2019, 12:50:10
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 :)
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 ...
ich habe gerade einen Update gemacht. Geht wieder !
Danke für das Schnelle Fixing sowie das debugging!
Also sind die Updates morgen früh verfügbar?
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 13 Mai 2019, 14:26:35
Also sind die Updates morgen früh verfügbar?
Nein, jetzt schon.
Danke an alle!
Gesendet von meinem E6653 mit Tapatalk
Danke ebenso läuft wieder!
Zitat von: sash.sc am 13 Mai 2019, 14:26:35
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.
Zitat von: rudolfkoenig am 13 Mai 2019, 11:55:04
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...
Zitat
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.
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.