gelöst: Probleme mit repeatcmd und wait_timer

Begonnen von KNUT345, 12 November 2016, 18:35:52

Vorheriges Thema - Nächstes Thema

KNUT345

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

Ellert

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

KNUT345

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?

Ellert

Dann musst Du prüfen, ob die Attributkonstellation, das zulässt.

KNUT345

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

Ellert

#5
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?  ;)

KNUT345

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

Ellert

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.

KNUT345

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