-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use FHEM::Core::Timer::Helper #1075
Conversation
Name der Lib angepasst
- make SIGNALduino_IdList more robust
- updated tests
- Added plan - Removed duplicarte subtest from 02_SIGNALduino_IdList.t
- Updated test
- verifys the undef function and if timers are removed
Codecov Report
@@ Coverage Diff @@
## master #1075 +/- ##
==========================================
+ Coverage 63.42% 63.64% +0.21%
==========================================
Files 128 132 +4
Lines 9479 9525 +46
Branches 1504 1508 +4
==========================================
+ Hits 6012 6062 +50
+ Misses 2308 2298 -10
- Partials 1159 1165 +6
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
changed timer creation and deletion
timer syntax failures corrected
Test auf Timerlib adaptiert
more syntax fixes
- adaptes test to timerlib
Ich habe auf die Timer Bibliothek umgestellt, damit keine Timer im Falle eines undef zurück bleiben. Der Branch wäre aber mal intensiv zu testen, bevor wir der Anpassung trauen können. |
Weit gekommen bin ich mit dem ersten Test nicht :-) Ich habe drchgeführt:
und
FHEM hat sich verabschiedet mit folgendem im Log:
Das dürfte aber nicht an den Timern liegen, sondern an Zeile 3347:
Nachdem ich diese auskommentiert habe, läuft FHEM erstmal. Ich habe jetzt aber keinen Plan, wie ich die Timer testen könnte. |
Die Aussage, das FHEM nach der Auskommentierung, läuft, ziehe ich zurück - ich hatte aus Versehen, die vorhergehende 00_SIGNALduino.pm verwendet. |
Wenige Minuten später der Test auf dem zweiten System:
FHEM schmiert wahrscheinlich immer ab, wenn eine der IdList leer ist. |
Das ist aber so gewollt dass es bei einem leer ist oder? |
Ja, klar, ich aktiviere eigentlich immer nur die Protokolle, die benötigt werden. Ich habe jetzt noch etwas weiter probiert. Wenn ich hier, den alten Timeraufruf wieder verwende, kommt FHEM etwas weiter:
... scheitert dann aber wieder:
|
Ich denke, der Timer versucht eine Funktion aufzurufen die es nicht gibt:
Das FHEM da hängen bleibt, ist aber eher darauf zurückzuführen, dass es hier nicht robust ist. |
- Provide timer func as coderef
force return of gettimeofday() to scalar context
Vermutung war korrekt.
Timer wurde gefunden. gettimeofday() liefert einen array zurück, wenn es nicht auf scalar context angewiesen ist. |
Ist das jetzt schon soweit, das ein neuer Test auf einem Live-System sinnvoll ist, oder arbeitest du noch daran? |
Aktuell arbeite ich nicht daran. Es scheint alles zu funktionieren. |
Tja, hier schmiert FHEM weiterhin an der gleichen Stelle ab:
Ich habe diesmal extra noch bei dem sduinoEasyPico868 jeweils noch ein Protokoll eingetragen. Daran liegt es aber auch nicht. |
Sehr seltsam. Meine Anpassung ist nicht eingecheckt, das wundert mich doch sehr. |
Was meinst du mit "ist nicht eingecheckt"? |
Ich dachte ich hätte den commit nicht gepusht, aber es ist doch enthalten. Die Sache ist seltsam.
Tatsächlich hatte ich aber das Problem, das FHEM nach einem neustart einmal abgestürzt ist. Jetzt läuft es aber wieder. |
remove less timer if device is connected
Fehler in Zeile 1388 gefunden, hier wurden zu viele Timer gelöscht:
Fraglich ist, welche solle hier wirklich gelöscht werden.
|
Ich habe die aktuelle 00_SIGNALduino.pm aus diesem Branch jetzt auf 3 Systemen laufen. Bis jetzt habe ich noch keine Auffälligkeiten bemerkt. |
Das sind doch gute Nachrichten. |
wollen wir hier mergen oder ist euch noch was aufgefallen? |
Ich denke mal, ich kann grünes Licht geben :-) |
(You can also link to an open issue here, if this describes the current behavior)
#855 #856
Timers are deleted correcty
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Other information: