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

Medel · 12 Mai 2019, 10:34:41

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

eppi · 12 Mai 2019, 10:39:31

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

Gigafix · 12 Mai 2019, 10:55:32

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

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 · 12 Mai 2019, 14:51:14

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.

zentis666 · 12 Mai 2019, 15:02:07

Hallo,

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

Code Auswählen

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 · 12 Mai 2019, 15:08:59

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
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 · 12 Mai 2019, 18:03:34

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


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 · 12 Mai 2019, 19:41:39

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 · 12 Mai 2019, 19:43:12

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 · 12 Mai 2019, 20:17:07

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 · 12 Mai 2019, 20:24:32

Hallo,

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

Gruß Mario

CoolTux · 12 Mai 2019, 21:03:14

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

Medel · 12 Mai 2019, 21:17:25

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

CoolTux · 12 Mai 2019, 21:24:25

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

Medel · 12 Mai 2019, 21:39:26

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

Code Auswählen


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

-   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.