14_CUL_MAX.pm - Crash nach update

Wzut · 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 ?

hietzi · 12 Mai 2020, 14:57:55

Hallo

Nach heutigem update crasht auch mein fhem mit
Undefined subroutine &main::MAX_ParseTemperature called at ./FHEM/10_MAX.pm line 378.

Wzut · 12 Mai 2020, 17:35:59

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

hietzi · 13 Mai 2020, 21:59:02

nach heutigem update ist der Fehler weg und Fhem starte wie gewohnt.
Besten Dank für den Fix

lg
Chris

kingmathers · 14 Mai 2020, 01:30:14

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:

Code Auswählen


define CUL_868_MAX CUL
define cm CUL_MAX 123456
define Heizung_xy MAX HeatingThermostat

Wzut · 14 Mai 2020, 06:14:21

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

smoki3 · 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

bartman121 · 14 Mai 2020, 11:52:45

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:

Code Auswählen


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

smoki3 · 14 Mai 2020, 15:20:33

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.

Wzut · 14 Mai 2020, 16:45:54

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 ?

smoki3 · 14 Mai 2020, 18:20:52

Verbose war auf 3 und stacktrace gar nicht definiert.

Ich kann es nochmals versuchen.

Wzut · 14 Mai 2020, 19:22:12

aber bitte erst morgen früh nach 8:00 Uhr und einem update 14_CUL_MAX

Parador · 25 Mai 2020, 14:05:24

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.

Code Auswählen

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

Wzut · 25 Mai 2020, 14:56:57

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.

Feinfinger · 26 Mai 2020, 07:50:09

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?