Hallo,
ich habe heute ein FHEM-UPDATE gemacht, danach startete mein FHEM nicht mehr. Folgendes sagt das Logfile beim Start.
2020.05.07 19:35:31 0: Server shutdown
2020.05.07 19:35:32 2: eventTypes: loaded 9127 events from ./log/eventTypes.txt
2020.05.07 19:35:33 1: KU.TEMP: no I/O device
2020.05.07 19:35:35 1: PERL WARNING: main::SIRD_Power() called too early to check prototype at ./FHEM/17_SIRD.pm line 74.
2020.05.07 19:35:35 1: PERL WARNING: main::SIRD_Volume() called too early to check prototype at ./FHEM/17_SIRD.pm line 151.
2020.05.07 19:35:35 1: PERL WARNING: main::SIRD_Mute() called too early to check prototype at ./FHEM/17_SIRD.pm line 247.
2020.05.07 19:35:35 1: PERL WARNING: main::SIRD_Shuffle() called too early to check prototype at ./FHEM/17_SIRD.pm line 307.
2020.05.07 19:35:35 1: PERL WARNING: main::SIRD_Repeat() called too early to check prototype at ./FHEM/17_SIRD.pm line 367.
2020.05.07 19:35:35 1: PERL WARNING: main::SIRD_RemoteState() called too early to check prototype at ./FHEM/17_SIRD.pm line 1038.
2020.05.07 19:35:35 1: PERL WARNING: main::SIRD_Input() called too early to check prototype at ./FHEM/17_SIRD.pm line 1120.
2020.05.07 19:35:35 1: PERL WARNING: main::SIRD_SearchTerm() called too early to check prototype at ./FHEM/17_SIRD.pm line 1716.
2020.05.07 19:35:35 1: PERL WARNING: main::SIRD_DABScan() called too early to check prototype at ./FHEM/17_SIRD.pm line 1766.
2020.05.07 19:35:36 1: WZ.TEMP: no I/O device
2020.05.07 19:35:36 1: EC3000_BCF0: no I/O device
2020.05.07 19:35:36 2: EnOcean Cryptographic functions are not available.
2020.05.07 19:35:36 2: EnOcean XML functions available.
2020.05.07 19:35:36 1: EC3000_C1A8: no I/O device
2020.05.07 19:35:36 0: [echodevice] load ECHO Device ECHO_G090L90964011JQ3
2020.05.07 19:35:36 0: [echodevice] load ECHO Device ECHO_G090L909648611RW
2020.05.07 19:35:36 0: [echodevice] load ECHO Device ECHO_G090QU0674710HHC
2020.05.07 19:35:37 1: PERL WARNING: Use of uninitialized value $model in string eq at ./FHEM/32_YeeLight.pm line 172.
2020.05.07 19:35:37 1: AUSSEN.TEMP: no I/O device
2020.05.07 19:35:37 2: Switched cul_cube rfmode to MAX
2020.05.07 19:35:37 2: Registering GEOFANCY geofancy for URL /geo...
2020.05.07 19:35:37 1: AZ.TEMP: no I/O device
2020.05.07 19:35:37 1: PERL WARNING: given is experimental at ./FHEM/98_PID20.pm line 305.
2020.05.07 19:35:37 1: PERL WARNING: when is experimental at ./FHEM/98_PID20.pm line 307.
2020.05.07 19:35:37 1: PERL WARNING: given is experimental at ./FHEM/98_PID20.pm line 339.
2020.05.07 19:35:37 1: PERL WARNING: when is experimental at ./FHEM/98_PID20.pm line 341.
2020.05.07 19:35:37 1: PERL WARNING: when is experimental at ./FHEM/98_PID20.pm line 345.
2020.05.07 19:35:37 1: PERL WARNING: when is experimental at ./FHEM/98_PID20.pm line 356.
2020.05.07 19:35:37 1: PERL WARNING: when is experimental at ./FHEM/98_PID20.pm line 363.
2020.05.07 19:35:37 1: PERL WARNING: when is experimental at ./FHEM/98_PID20.pm line 370.
2020.05.07 19:35:37 1: PERL WARNING: when is experimental at ./FHEM/98_PID20.pm line 385.
2020.05.07 19:35:38 2: FRITZBOX FritzBox: Define.255 Modul functionality limited because of missing perl modules: Net::Telnet
2020.05.07 19:35:40 1: EC3000_8351: no I/O device
2020.05.07 19:35:40 1: EC3000_F8DC: no I/O device
2020.05.07 19:35:40 1: KeyValueProtocol_LGW_5677390: no I/O device
2020.05.07 19:35:40 1: Messages collected while initializing FHEM:SecurityCheck:
WEB is not password protected
MQTT2_FHEM_Server is not password protected
WEBhook is not password protected
WEBphone is not password protected
Protect this FHEM installation by configuring the allowed device allowedWEBhook
You can disable this message with attr global motd none
2020.05.07 19:35:40 2: TCM TCM_ESP3_0 RESPONSE: OK
2020.05.07 19:35:41 2: TCM TCM_ESP3_0 RESPONSE: BaseID: FF9D7D80 RemainingWriteCycles: 0A
2020.05.07 19:35:41 2: TCM TCM_ESP3_0 RESPONSE: APIVersion: 02050000 APPVersion: 020A0000 ChipID: 018E3AFB ChipVersion: 454F0103 Desc: GATEWAYCTRL
2020.05.07 19:35:41 2: TCM TCM_ESP3_0 RESPONSE: OK
2020.05.07 19:35:41 2: TCM TCM_ESP3_0 repeater 0000 restored
2020.05.07 19:35:41 2: TCM TCM_ESP3_0 RESPONSE: OK
2020.05.07 19:35:41 2: TCM TCM_ESP3_0 maturity 01 restored
2020.05.07 19:35:41 2: TCM TCM_ESP3_0 RESPONSE: OK
2020.05.07 19:35:41 2: TCM TCM_ESP3_0 smartAckMailboxMax 0 restored
2020.05.07 19:35:41 2: TCM TCM_ESP3_0 RESPONSE: NOT_SUPPORTED
2020.05.07 19:35:41 2: TCM TCM_ESP3_0 initialized
2020.05.07 19:35:41 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/37_harmony.pm line 1765.
2020.05.07 19:35:41 2: alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg
2020.05.07 19:35:41 0: Featurelevel: 6
2020.05.07 19:35:41 0: Server started with 312 defined entities (fhem.pl:21762/2020-04-23 perl:5.026001 os:linux user:fhem pid:19804)
Can't use an undefined value as a subroutine reference at ./FHEM/10_MAX.pm line 850.
Signal 15 (TERM) caught by ps (3.3.12).
ps:ps/display.c:66: please report this bug
2020.05.07 19:35:42 1: UWZ uwz: UWZ.900 Error: Can't get http://feed.alertspro.meteogroup.com/AlertsPro/AlertsProPollService.php?method=getWarning&language=de&areaID=UWZde01159 -- http://feed.alertspro.meteogroup.com/AlertsPro/AlertsProPollService.php?method=getWarning&language=de&areaID=UWZde01159: Select timeout/error: Interrupted system call
Auffällig ist folgendes:
Signal 15 (TERM) caught by ps (3.3.12).
ps:ps/display.c:66: please report this bug
Es wurden folgende Module geupdated:
andreas@fhem:/opt/fhem/restoreDir/update/2020-05-07/FHEM$ ls
00_THZ.pm 70_BOTVAC.pm 98_configdb.pm
00_ZWDongle.pm 70_HYDRAWISE.pm 98_DOIF.pm
10_MAX.pm 72_XiaomiDevice.pm 98_RandomTimer.pm
10_SOMFY.pm 73_DoorBird.pm 98_readingsWatcher.pm
14_CUL_MAX.pm 73_GardenaSmartBridge.pm 98_todoist.pm
31_HUEDevice.pm 74_GardenaSmartDevice.pm 98_WeekdayTimer.pm
37_echodevice.pm 77_UWZ.pm controls_fhem.txt
42_SMARTMON.pm 93_DbLog.pm lib
57_Calendar.pm 95_holiday.pm
Der Fehler lässt sich beheben wenn ich die 14_CUL_MAX.pm aus dem restoreDir zurückspiele.
Braucht ihr weitere Infos um das Problem einzugrenzen?
Grüße
Andreas
ich verwende einen umgeflashten CUBE angebunden per IP-Adresse
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXOefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.2.7:2323 1234
DeviceName 192.168.2.7:2323
FD 17
FHTID 1234
FUUID 5c49963d-f33f-1dd6-b4e6-57c84697173976f8
NAME cul_cube
NR 178
NR_CMD_LAST_H 11
PARTIAL
RAWMSG Z0F0004600703780000000039003D00B91C
RSSI -60
STATE Status:Initialized || Credits: 1301
TYPE CUL
VERSION V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) CUBe (F-Band: 868MHz)
cul_cube_MSGCNT 7
cul_cube_TIME 2020-05-07 19:54:01
initString X21
Zr
Helper:
DBLOG:
credit10ms:
logdb:
TIME 1588874737.21233
VALUE 1301
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-05-07 19:50:38 cmds B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
2020-05-07 20:05:37 credit low
2020-05-07 20:05:37 credit10ms 1301
2020-05-07 19:54:01 state Initialized
XMIT_TIME:
1588873842.32433
1588873848.73208
1588873850.23583
1588873851.75325
1588873853.53463
1588873860.24118
1588873868.43235
1588873874.45355
1588873880.96256
1588873887.46516
1588874028.77176
Attributes:
DbLogExclude 1
event-min-interval .*:1800
event-on-change-reading .*
rfmode MAX
room ZZZ_RXD_TXD
stateFormat Status:state || Credits: credit10ms
userReadings credit {cul_credits(ReadingsVal("cul_cube","credit10ms",0));}
hier noch das "cm"-Device
Internals:
DEF 123456
FUUID 5c49963d-f33f-1dd6-c63f-896522ac331b9c14
IODev cul_cube
LASTInputDev cul_cube
MSGCNT 7
NAME cm
NR 166
STATE Defined
TYPE CUL_MAX
addr 123456
cnt 0
cul_cube_MSGCNT 7
cul_cube_RAWMSG Z0F0004600703780000000039003D00B9
cul_cube_RSSI -60
cul_cube_TIME 2020-05-07 19:54:01
pairmode 0
retryCount 0
READINGS:
2020-05-07 19:51:30 packetsLost 4
sendQueue:
Attributes:
DbLogExclude .*
IODev cul_cube
room ZZZ_RXD_TXD
Sonst wüsste ich nicht was ich noch liefern könnte.
BTW. ich musste auch die 10_MAX.pm zurücksichern, sonst läuft MAX natürlich nicht.
Grüße
Andreas
und auch die ganzen anderen Fehlermeldungen beim Start verschwinden wenn du die alten Dateien wieder benutzt ?
So einen Absturz wie bei dir habe ich noch nie gesehen und kann daher nur raten. Von der 14_CUL_MAX sehe ich nichts in deinem Log Auszug wohl aber halt von 10_MAX
Ich würde daher darauf tippen das etwas mit deiner 10_MAX.pm nicht stimmt. Mach doch bitte nach 8:00 Uhr nochmal ein Update.
Wichtig : wenn du die Dateien tauschst, zur Vorsicht immer beide.
Alt CUL_MAX und neu MAX sollte gehen, aber die neue CUL_MAX brauch immer die neue MAX.
mir ist noch eingegfallen, dass ich meine Thermostate per "PID20" regele. Auf initialized gibt es ein notfiy, dass direkt das maxValveSetting setzt. Scheinbar crashed fhem dabei.
Wenn ich heute update kommt die 14_CUL_MAX.pm gar nicht mit? :/
Mit der neuen 10_MAX.pm stehen meine Thermostate nach dem initialized auf "waiting for Data".
Ich bin etwas ratlos.
Grüße
sorry, aber jetzt blicke ich nicht durch. Läuft die neue 10_MAX nun doch ? Waiting for Data ist normal bis ein Telegramm von diesem Device empfangen wurde.
Die neue 14_CUL_MAX.pm läuft leider nach wie vor nicht. Ich werde am WE das Problem mal mit verbose 5 nachstellen und die neuen Logs hier einstellen, vllt. sieht man dann mehr.
Grüße
Andreas
ich habe jetzt erfolglos versucht das Problem nachzustellen, FHEM crasht weiterhin mit der neuen 14_CUL_MAX.pm. Mit verbose 5 kommen derartige viele Meldungen, dass eine Fehlersuche erfolglos erscheint.
Ich bin erstmal nicht gewillt hier weiter zu forschen und habe die Dateien als "exclude from update" gesetzt. Ich bin scheinbar auch der einzige den das betrifft, daher bitte ich um Entschuldigung, dass ich nicht weiter nachforschen will.
Grüße
Andreas
Zitat von: bartman121 am 09 Mai 2020, 10:41:49
Ich bin erstmal nicht gewillt hier weiter zu forschen
das ist schade, denn nur so lernt man dazu und ich bin natürlich auch neugierig.
Zitat von: Wzut am 09 Mai 2020, 13:48:17
das ist schade, denn nur so lernt man dazu und ich bin natürlich auch neugierig.
Angespornt durch deinen Beitrag habe ich mir jetzt ein Testsystem (minimal) aufgebaut. Das Problem tritt auf, sobald der PID20-Regler mit ins Spiel kommt, danach stürzt fhem unvermittelt ab und das System startet fhem neu.
Ich denke das kannst du mit deinem Testsystem auch mal nachstellen nur zur Sicherheit, damit wir vom gleichen Problem reden.
Es reicht den PID20-Regler zu definieren und auch zu parametrieren und fhem neuzustarten. Danach tritt der Fehler auf.
Anbei ein List meines PID20-Reglers:
Internals:
DEF WZ.TEMP:temperature WZ.HT1:maxValveSetting
FUUID 5c499640-f33f-1dd6-5a0a-d84196bf9a374cc7
NAME PID.WZ.HT1
NR 209
NTFY_ORDER 50-PID.WZ.HT1
STATE processing
TYPE PID20
VERSION 1.0.0.9
Helper:
DBLOG:
actuation:
logdb:
TIME 1589039896.07535
VALUE 0
actuationCalc:
logdb:
TIME 1589039776.0636
VALUE -22.228
delta:
logdb:
TIME 1589039776.0636
VALUE -3.7
desired:
logdb:
TIME 1589039896.07535
VALUE 17
measured:
logdb:
TIME 1589039776.0636
VALUE 20.7
p_d:
logdb:
TIME 1589039896.07535
VALUE 0
p_i:
logdb:
TIME 1589039896.07535
VALUE -0.028
p_p:
logdb:
TIME 1589039776.0636
VALUE -22.2
state:
logdb:
TIME 1589041332.47263
VALUE processing
READINGS:
2020-05-09 18:22:12 actuation 0
2020-05-09 18:22:12 actuationCalc -22.228
2020-05-09 18:22:12 delta -3.7
2020-05-09 18:22:12 desired 17
2020-05-09 18:22:12 measured 20.7
2020-05-09 18:22:12 p_d 0
2020-05-09 18:22:12 p_i -0.028
2020-05-09 18:22:12 p_p -22.2
2020-05-09 18:22:12 state processing
helper:
actor WZ.HT1
actorCommand maxValveSetting
actorErrorAction freeze
actorErrorPos 0
actorInterval 120
actorKeepAlive 72000
actorLimitLower 0
actorLimitUpper 100
actorThreshold 1
actorTimestamp 2020-05-09 10:52:09
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient 0
deltaOld -3.7
deltaOldTS 2020-05-09 18:07:58
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.01
factor_P 6
isWindUP 1
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor WZ.TEMP
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
disable 0
event-min-interval .*:1800
event-on-change-reading .*
pidActorInterval 120
pidActorKeepAlive 72000
pidActorValueDecPlaces 0
pidFactor_I 0.01
pidFactor_P 6
room ZZZ_System->PID
Grüße
hat etwas gedauert bis ich den PID20 dazu gebracht habe , aber irgendwann :
2020.05.09 19:50:32 5: PID20 PID20: Calc.697 actor:Thermo1 actorCommand:maxValveSetting actuation:30
Can't use an undefined value as a subroutine reference at ./FHEM/10_MAX.pm line 850.
Na das ist doch schon mal etwas, beim Versuch das maxValveSetting zu verdrehen kracht es.
Ich denke mal das Problem werd ich finden, nur heute nicht mehr :)
das war ne harte Nuß und hat mich einige Stunden gekostet ....
Ursachen bzw Lösungem gibt es zwei :
1. Ich wollte 10_MAX und 14_CUL_MAX robuster machen gegen das Reihenfolge Problem in der fhem.cfg.
D.h. idealerweise ist zurerst die Hardware definiert -> 00_CUL.pm
dann das CULMAX Device -> 14_CUL_MAX.pm
und dann alle MAX Geräte -> 10_MAX.pm
Wie gesagt der Idealfall, durch diverse Hardware Tauschaktionen und Tests kann diese Reihenfolge später aber abweichen, CUL steht hinter CULMAX oder CULMAX nach einem MAX Device. Um das für den User stressfrei zu bekommen habe ich beim FHEM Neustart das eine oder andere etwas verzögert. Und genau diese Verzögerung sorgt nun dafür das beim Einsatz von 98_PID20 FHEM eine Bruchlandung hinlegt sobald PID20 das erste Mal das Ventil verstellen will.
@bartman121, kannst du bitte mal deine fhem.cfg checken wie dort die Reihenfolge der Devices ist ?
2. eine andere Ursache ist wie 98_PID20.pm die Ventilverstellung aufruft :
my $cmd = sprintf( "set %s %s %g", $hash->{helper}{actor}, $hash->{helper}{actorCommand}, $actuation );
$ret = fhem $cmd;
Hier werde ich versuchen Kontakt mit John aufzunehmen und ihn bitten die beiden Zeilen leicht zu ändern :
my $cmd = sprintf( "%s %s %g", $hash->{helper}{actor}, $hash->{helper}{actorCommand}, $actuation );
$ret = CommandSet(undef, $cmd);
@bartman121, auch das kannst du mal machen wenn du es dir zutraust.
du bist Klasse :)
auf meinem Testsystem stimmt die Reihenfolge und ich konnte das System mit der geänderten 98_PID20.pm erfolgreich wieder in Betrieb nehmen.
Auf meinem Hauptsystem kann ich die Reihenfolge nicht wirklich prüfen, da ich dort configDB nutze, aber das schaue ich mir noch an. Dort war die Änderung der 98_PID20.pm leider nicht erfolgreich. Ich denke hier stimmt die Reihenfolge nicht.
Ich muss das noch genauer untersuchen.
Grüße
Andreas
komisch, ich habe jetzt mal die Dateien direkt von hier (https://svn.fhem.de/fhem/trunk/fhem/FHEM/) geholt und die 98_PID20.pm geändert und jetzt funktioniert meine Hauptinstanz auch mit den neuen Dateien.
Allerding erhalte ich bei "version" diese Hinweise:
No Id found for 14_CUL_MAX.pm
das gleiche auch für 10_MAX.pm
Habe ich etwas falsch gemacht?
Grüße
Andreas
So wie ich das sehe fehlt dort allen Dateien die $Id $ im Kopf. Hat für dich aber keine negativen Auswirkungen.
Wenn du die mit update 10_MAX bzw. update 14_CUL_MAX holst sollte aber eine aktuelle Id drin stehen.
Ich habe ein ähnliches Problem (verwende auch PID20, habe die Datei auch schon angepasst, der Fehler besteht aber weiterhin):
Can't use an undefined value as a subroutine reference at ./FHEM/10_MAX.pm line 772.
In der Zeile 772 wird aber nicht versucht das Ventil zu begrenzen sondern hier geht ein set desiredTemperature raus.
Daher denke ich das PID20 an der Stelle unschuldig ist. Welche Module oder eigenen Code benutzt du noch um die Soll Temperatur zu verstellen ?
Und wie schaut bei dir die Reihenfolge in der fhem.cfg aus ?
Hallo
Nach heutigem update crasht auch mein fhem mit
Undefined subroutine &main::MAX_ParseTemperature called at ./FHEM/10_MAX.pm line 378.
@hietzi , da passt aber etwas nicht , in 10_MAX gibt es um die Zeile 378 kein MAX_ParseTemperature .....
Ich habe aber einen Fehler in der 14_CUL_MAX gefunden wo MAX_ParseTemperature verlangt wird.
Update ab morgen 8:00 Uhr verfügbar.
Nochmal zum eigentlichen Thema
Can't use an undefined value as a subroutine reference at ./FHEM/10_MAX.pm line xxx
Ich schaffe es ums Verrecken nicht mehr den Fehler vom Sonntag nachzustellen ! D.h. auch ohne Änderung von 98_PID20 oder die Reihenfolge in der fhem.cfg verwürfelt, er kommt nicht mehr.
nach heutigem update ist der Fehler weg und Fhem starte wie gewohnt.
Besten Dank für den Fix
lg
Chris
Zitat von: Wzut am 12 Mai 2020, 07:16:46
In der Zeile 772 wird aber nicht versucht das Ventil zu begrenzen sondern hier geht ein set desiredTemperature raus.
Daher denke ich das PID20 an der Stelle unschuldig ist. Welche Module oder eigenen Code benutzt du noch um die Soll Temperatur zu verstellen ?
Und wie schaut bei dir die Reihenfolge in der fhem.cfg aus ?
Ich verwende ein MAX Wandthermostat in Verbindung mit PID20 und einem FS20 Stellantrieb.
Desired Temperature setze ich teilweise aus dem Code heraus (bei Anwesenheit/Abwesenheit).
in der fhem.cfg sieht die Reihenfolge so aus:
define CUL_868_MAX CUL
define cm CUL_MAX 123456
define Heizung_xy MAX HeatingThermostat
@kingmathers, bitte nach 8:00 Uhr ein Update von 10_MAX und 14_CUL_MAX machen und bei weiteren Problemen in die Log Datei schauen.
Habe heute auch geupdatet. (bin auf den Standard weg, also keine Beta oder sonstiges)
Leider startet nun mein FHEM auch nicht mehr. Und ich weiß auch nicht wie ich es zum laufen bekomme. Mir ist davor aufgefallen dass es immer beim deassosiate Befehl abgestürtzt ist.
Ich habe auch keine Ahnung wie ich nun an logs komme
Zitat von: smoki3 am 14 Mai 2020, 10:59:11
Habe heute auch geupdatet. (bin auf den Standard weg, also keine Beta oder sonstiges)
Leider startet nun mein FHEM auch nicht mehr. Und ich weiß auch nicht wie ich es zum laufen bekomme. Mir ist davor aufgefallen dass es immer beim deassosiate Befehl abgestürtzt ist.
Ich habe auch keine Ahnung wie ich nun an logs komme
Das klingt nicht sehr gut, ohne Grundkenntnisse wirst du immer wieder in solche Probleme laufen. Bitte eigne Dir das an um in Zukunft gewappnet zu sein.
Mit diesen drei Befehlen kannst du das update rückgängig machen:
sudo cp -r /opt/fhem/restoreDir/update/2020-05-14/* /opt/fhem/
sudo service fhem stop
sudo service fhem start
Damit sollte dein FHEM erstmal wieder starten.
Grüße
Andreas
hab fhem schon wieder zum laufen gebracht durch löschen der Module. Hab nun auch rausgefunden was das Problem ist.
Und zwar stürzt fhem ab wenn ich die fakeWT Geschichte benutzen will. Leider steht dazu in den Logs nichts. Sobald die Temperatur vom Thermometer ankommt stürzt fhem komplett ab und lässt sich dann auch nicht mehr starten, bis ich das attribut wieder aus der config nehme.
Zitat von: smoki3 am 14 Mai 2020, 15:20:33
Leider steht dazu in den Logs nichts.
Das kann ich nicht glauben, ich hatte bei den ganzen Aktionen keinen einigen Fall wo nicht im Logfile stand warum ich FHEM zum Absturz gebracht habe.
Und glaube mir das waren seit November ein paar hundert ..... Kleiner Tipp : wie steht denn global verbose und ist stacktrace auf 1 ?
Verbose war auf 3 und stacktrace gar nicht definiert.
Ich kann es nochmals versuchen.
aber bitte erst morgen früh nach 8:00 Uhr und einem update 14_CUL_MAX :)
Hallo Wzut,
auch bei mir stürzt FHEM inzwischen immer mal ab. Ich bin aktuell auf verbose 2 und habe Stacktrace aktiviert.
Nach dem Neustart fand ich Hinweise darauf im Protokoll, dass mein Cube noch nicht gefunden werden kann und daraufhin ein DOIF nicht arbeiten kann.
Ich denke da braucht einfach der Raspi ein wenig bis er die Netzwerkverbindungen wieder hergestellt hat, aber sicher ist sicher.
2020.05.25 13:04:14 1: 192.168.1.49:2323 disconnected, waiting to reappear (MAX_CUL_0)
2020.05.25 13:04:14 1: PERL WARNING: Argument "No answer" isn't numeric in numeric lt (<) at (eval 339) line 1.
2020.05.25 13:04:14 1: eval: MAX_CUL_Doif.Credits.low_Telegram: warning in condition c01
2020.05.25 13:04:14 1: stacktrace:
2020.05.25 13:04:14 1: main::__ANON__ called by (eval 339) (1)
2020.05.25 13:04:14 1: (eval) called by ./FHEM/98_DOIF.pm (2060)
2020.05.25 13:04:14 1: main::DOIF_CheckCond called by ./FHEM/98_DOIF.pm (2403)
2020.05.25 13:04:14 1: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (2629)
2020.05.25 13:04:14 1: main::DOIF_Notify called by fhem.pl (3784)
2020.05.25 13:04:14 1: main::CallFn called by fhem.pl (3704)
2020.05.25 13:04:14 1: main::DoTrigger called by fhem.pl (4769)
2020.05.25 13:04:14 1: main::readingsEndUpdate called by fhem.pl (4951)
2020.05.25 13:04:14 1: main::readingsSingleUpdate called by ./FHEM/00_CUL.pm (448)
2020.05.25 13:04:14 1: main::CUL_Get called by fhem.pl (3784)
2020.05.25 13:04:14 1: main::CallFn called by fhem.pl (1972)
2020.05.25 13:04:14 1: main::CommandGet called by ./FHEM/14_CUL_MAX.pm (1220)
2020.05.25 13:04:14 1: main::CUL_MAX_SQH called by ./FHEM/14_CUL_MAX.pm (995)
2020.05.25 13:04:14 1: main::CUL_MAX_Send called by ./FHEM/10_MAX.pm (1120)
2020.05.25 13:04:14 1: main::MAX_Set called by fhem.pl (3779)
2020.05.25 13:04:14 1: main::CallFn called by fhem.pl (1907)
2020.05.25 13:04:14 1: main::DoSet called by fhem.pl (1939)
2020.05.25 13:04:14 1: main::CommandSet called by ./FHEM/10_MAX.pm (2152)
2020.05.25 13:04:14 1: main::MAX_Notify called by fhem.pl (3784)
2020.05.25 13:04:14 1: main::CallFn called by fhem.pl (3704)
2020.05.25 13:04:14 1: main::DoTrigger called by fhem.pl (4071)
2020.05.25 13:04:14 1: main::Dispatch called by ./FHEM/00_ZWDongle.pm (980)
2020.05.25 13:04:14 1: main::ZWDongle_Parse called by ./FHEM/00_ZWDongle.pm (875)
2020.05.25 13:04:14 1: main::ZWDongle_Read called by fhem.pl (3784)
2020.05.25 13:04:14 1: main::CallFn called by fhem.pl (760)
2020.05.25 13:04:15 1: cm, Send Queue error CUL MAX_CUL_0 did not answer request for current credits. Waiting 5 seconds
2020.05.25 13:04:20 1: PERL WARNING: Argument "No answer" isn't numeric in numeric lt (<) at (eval 419) line 1.
2020.05.25 13:04:20 1: eval: MAX_CUL_Doif.Credits.low_Telegram: warning in condition c01
....
2020.05.25 13:05:20 1: 192.168.1.49:2323 reappeared (MAX_CUL_0)
Ab hier wirds wieder ruhiger..
Sorry, aber das Problem hast du dir selbst gebaut : Dein DOIF scheint nur brauchbar für numerische Werte zu sein, 00_CUL liefert aber halt auch mal Strings wie "No Answer" 14_CUL_MAX z.B kommt damit wunderbar zurecht.
Ich würde ja mal anfangen nach der Ursache suchen (CUL Disconnect) statt Symptome mit unzureichenden Mitteln mehr schlecht als recht versuchen zu behandeln.
Auf jeden Fall ist 14_CUL_MAX unschuldig wenn irgendwann dein CUL nicht mehr mag.
Moin zusammen,
Erstmal ein großes Dankeschön an den Entwickler, das man sich die Mühe macht, dieses Modul wieder zu supporten.
Ich habe nach dem Update folgendes Verhalten.
Mein Cul_Max device pusht seit dem Update ca. alle 3 seinen state. Früher hat es das lediglich beim Start gemacht, jetzt immer wiederkehrend, also wenn der MapleCun initialisiert, wird auch Cul_Max getriggert.
Ist das so gewollt?
Du meinst du siehst im Eventmonitor ständig den aktuellen state vom CUL_MAX Device ?
Wenn ja : das Readings state wird aktualisiert wenn das Device entweder selbst etwas tun muss oder vom CUL angesprochen wird.
Ist dir das zu häufig ? dann hilftt wie immer in solchen Fällen das Attribut event-on-change-reading auf .* zu setzen.
Genau das,
Aufgefallen war's mir im Log, dem CUL ,,verbiete" ich die Events, aber da das CUL_Max Modul bis dato nur einmal beim Start ein Event erzeugt hatte, habe ich da keine entsprechenden Einstellungen vorgenommen.
Werde also das CUL_Max Modul mit entsprechenden attr versehen.
Danke für die Info!