Hallo Zusammen,
ich komm einfach nicht weiter.
Habe mir ein Anwesenheitstool für Fritz-Box mit 2 Repeatern mit DOIF gebaut.
Im Prinzip funktioniert es auch, manchmal fehlt jedoch die Befehlwiederholung und deshalb kommt es dann zu einem Plotabriß.
Ich hab schon eine Variante mit komplexer Struktur und derzeit eine Variante mit jedem Fall einzel als DOELSEIF aber wie gesagt es funktioniert nicht zuverlässig.
Ich vermute immer wenn das Handy über Roaming den Accespoint wechselt, dann geht der wait_timer verloren.
([Fritz_Box:mac_xx] eq "inactive") (
set FB_Handy absent,
set HomeStatus absent)
DOELSEIF ([Fritz_Box:mac_xx] =~ "WLAN, 0 / 0 Mbit/s, 0" and [Fritz_Repeater_WZ:mac_xx] =~ "WLAN, 0 / 0 Mbit/s, 0") (
set FB_Handy absent,
set HomeStatus absent)
DOELSEIF ([Fritz_Box:mac_xx] =~ "WLAN, 0 / 0 Mbit/s, 0" and [Fritz_Repeater_OG2:mac_xx] =~ "WLAN, 0 / 0 Mbit/s, 0") (
set FB_Handy absent,
set HomeStatus absent)
DOELSEIF ([Fritz_Box:mac_xx] =~ "WLAN, 0 / 0 Mbit/s, 0"
and [Fritz_Repeater_WZ:mac_xx] eq "inactive"
and [Fritz_Repeater_OG2:mac_xx] eq "inactive") (
set FB_Handy absent,
set HomeStatus absent)
DOELSEIF ([Fritz_Box:mac_xx] eq "inactive" and
[Fritz_Repeater_WZ:mac_xx] eq "inactive" and
[Fritz_Repeater_OG2:mac_xx] eq "inactive") (
set FB_Handy absent,
set HomeStatus absent)
DOELSE (
set FB_Handy present,
set HomeStatus present)
Korrektes Reading:
Device Fritz_Box12.11.2016 18:28
cmd 6 12.11.2016 18:14
cmd_event Fritz_Box 12.11.2016 18:14
cmd_nr 6 12.11.2016 18:14
e_Fritz_Box_mac_xx Handy (WLAN, 71 / 25 Mbit/s, 53) 12.11.2016 18:28
e_Fritz_Repeater_OG2_mac_xx inactive 12.11.2016 18:22
state cmd_6 12.11.2016 18:14
wait_timer 12.11.2016 19:14:58 cmd_6 Fritz_Box 12.11.2016 18:14
ZitatIch vermute immer wenn das Handy über Roaming den Accespoint wechselt, dann geht der wait_timer verloren.
Das könntest Du prüfen, wenn Du wie beschrieben vorgehst: http://www.fhemwiki.de/wiki/DOIF/Tools_und_Fehlersuche#Verhaltensanalyse_des_DOIF
Ja das hab ich auch so eingerichtet und darum komme ich zu der Annahme,
dass wenn der Zweig 6 durch verschiedene Bedingungen wahr wird (Roaming, anderer Access Point)
dann verliert es den Timer.
Kann das sein?
Dann musst Du prüfen, ob die Attributkonstellation, das zulässt.
Ich dachte, dass mir da jemand den entscheidenden Tipp geben könnte.
"repeatcmd" und "wait" reichen nicht aus.
"do always" hab ich probiert, hat glaube ich funktioniert,
aber dadurch wurden dann die Zweige permanent und nicht nur bei Änderung durchlaufen.
In der Zwischenzeit hat sich meine Vermutung bestätigt.
Nachdem ich den Zweig in seine Varianten zerlegt habe,
ist das Problem nicht mehr aufgetreten.
Grüße
Du könntest auch statt
([A]) (set x y)
DOELSEIF ([B]) (set x y)
DOELSEIF ([C]) (set x y)
DOELSEIF ([D]) (set x y)
DOELSEIF ([E]) (set x y)
DOELSE (set x z))auch
([A] or [B] or [C] or [D] or [E] ) (set x y)
DOELSE (set x z))
schreiben, da setzt ein Wechsel zwischen den Zweigen 1-5 wait nicht zurück.
ZitatIch vermute immer wenn das Handy über Roaming den Accespoint wechselt, dann geht der wait_timer verloren.
Ich habe es so verstanden, dass Du Deine Vermutung verifizieren woltest.
ZitatKann das sein?
Ohne ausreichende Information, kann ich nur raten, Du hättest ja do resetwait verwenden können.
ZitatIch dachte, dass mir da jemand den entscheidenden Tipp geben könnte.
Kennst Du jemanden, der Gedanken lesen kann? ;)
Verifiziert, ja.
Immer wenn durch Roaming ein Statuswechsel stattfinden der nicht in einem separaten Zweig definiert ist,
geht der 1h-Timer verloren.
([A] or [B] or [C] or [D] or [E] ) (set x y)
DOELSE (set x z))
Hab ich probiert, hat wohl aus ähnlichen Gründen den 1h-Timer verloren.
Da es mir bis dato nicht gelungen ist bei einem Dummy per event-on-change-reading und event-min-interval 1x/h einen Logeintrag bei Inaktivität zu erreichen, wollte ich dies mit dem 1h-Timer umgehen. Ich könnte das natürlich auch mittels einem zusätzlichen at umgehen.
do resetwait, setzt doch wait xx:xx:xx zurück, oder?
Das ist nicht mein Problem, das funktioniert genau so wie gewollt.
Ich vermute mein Problem mit repeatcmd xx:xx:xx,
da ich wie oben erwähnt verifizieren konnte, dass wenn der Zweig durch mehrere Events durchlaufen werden kann,
dann das repeatcmd plötzich auf "no timer" umschwenkt.
Momentan muss ich aber feststellen, dass es wohl noch andere Gründe geben kann,
da ich trotz eindeutiger (relativ, da die WLAN Performance ja variieren kann) eben wieder den "no timer" vorgefunden habe.
Kann es sein, dass repeatcmd nur eine max Anzahl von Schleifen erzeugt?
Danke und Grüße
Zitatdo resetwait, setzt doch wait xx:xx:xx zurück, oder?
Diese Frage beantwortet die Befehlsreferenz.
ZitatKann es sein, dass repeatcmd nur eine max Anzahl von Schleifen erzeugt?
Ja, wenn Du es mit repeatsame begrenzt.
Falls DOELSE unerwartet zuschlägt, werden die laufenden Timer zurückgesetzt, dann müsstest Du DOELSEIF verwenden, und nur die gewünschten Fälle zulassen.
Also ich hab es nun mehrere Tage beobachtet.
Mein Problem war, dass ich mehrere Betriebszustände nicht erfasst hatte.
Durch Erweitern der DOELSEIF konnte ich es dann letztendlich Lösen.
Grüße