Hallo zusammen,
mir ist heute ein seltsames Verhalten aufgefallen...
* Ich überwache Anwesenheit per GTags. Lepresenced läuft auf einem RasPI (<> dem FHEM RasPi), das funktioniert prinzipiell auch bestens
* Wenn ich FHEM neustarte, gehen die GTags alle auf unreachable/absent
* Ein sudo hctitool lescan auf dem entfernten Raspi findet die GTags und kurze Zeit später sind auch die GTags in FHEM wieder present...
Für mich gibt das alles keinen Sinn... Hat jemand schonmal ein ähnliches Verhalten beobachtet?
Danke,
Grüße,
Oli
Hallo,
ist mir auch aufgefallen nach einem restart mit presence per ping. (ich überwache einen China-Access-point per ping, der dann ggf durch die Steckdose neu gestartet wird).
Hab auch noch keine Lösung - wäre aber interessiert an einer :-)
Cheers,
Pula
Hmm. Also lepresenced läuft durch und nur FHEM wird neu gestartet?
Da das Problem scheinbar auch bei Ping auftritt riecht das erstmal nicht nach lepresenced als Ursache. Wenn Du es genau wissen willst stelle doch mal den Loglevel von lepresenced temporär auf LOG_DEBUG und rekonstruiere das Problem.
Erholt sich der Status von selbst oder musst Du per Hand aktiv werden?
Von unterwegs gesendet.
Hallo Oli,
kannst Du hier ein Logauszug mit verbose 5 in deiner PRESENCE-Definition anhängen? Ein list-Output von der Definition wäre ebenfalls hilfreich.
Vielen Dank
Gruß
Markus
Hi,
ich hab mal das verbose von dem betreffenden device auf 5 gestellt und ein shutdown restart gemacht.
Folgendes hab ich dabei im Logfile gefunden:
2018.03.13 00:32:54 5: PRESENCE (pWLANKeller) - stopping timer
2018.03.13 00:32:54 5: PRESENCE (pWLANKeller) - starting blocking call for mode lan-ping
und hier greift dann leider das entsprechende notify:
2018.03.13 00:32:54 3: nanoCUL IT_set: server_wlan off
(Sinn des Ganzen: Hin und wieder hängt sich der Accesspoint auf. Und durch presence lässt sich das per ping feststellen und dann per nanoCUL die Steckdose aus und wieder einschalten.)
Im Unterschied zu Oli habe ich den ping allerdings lokal auf dem fhem-rechner (potenter Server unter debian) laufen. Ein List des devices:
Internals:
ADDRESS 192.168.1.235
DEF lan-ping 192.168.1.235 300
INTERVAL_NORMAL 300
INTERVAL_PRESENT 300
MODE lan-ping
NAME pWLANKeller
NOTIFYDEV global
NR 640
NTFY_ORDER 50-pWLANKeller
STATE present
TYPE PRESENCE
READINGS:
2018-03-13 00:32:49 model lan-ping
2018-03-13 00:37:26 presence present
2018-03-13 00:37:26 state present
helper:
CURRENT_STATE present
Attributes:
devStateIcon present:FS20.on .*:FS20.off
room Keller,Praesenz
verbose 5
Das zugehörige notify sieht so aus (leider hat mich die Abfrage auf $fhem_started hier auch nicht weitergebracht):
pWLANKeller:presence:.* {
if (ReadingsVal("pWLANKeller", "state", "absent") eq "absent" and defined($fhem_started)) {
fhem "set server_wlan off";
fhem "sleep 3";
fhem "set server_wlan on";
fhem "set telegram message \@Otto WLAN Keller restartet!";;
}
}
Ein manuelles Eingreifen ist nicht nötig, das notify greift und schaltet den AP wieder ein.
Das Ganze ist zwar nicht lebensbedrohlich, aber manchmal ein wenig lästig ;-) (es hängen hier auch ein paar ESPs per wifi dran).
Cheers,
Pula
Logge doch mal testweise ReadingsVal("pWLANKeller", "state", "unbekannt") im Notify. Möglicherweise ist die ungünstige Wahl des ReadingsVal-Defaults der Übeltäter.
Von unterwegs gesendet.
Hi,
danke für Deine Antwort und sorry für meine späte Antwort!
Nach einigen Shutdown restarts habe ich nun festgestellt, dass das presence-modul scheinbar gar nicht der Übeltäter ist, sondern das CUL-Modul, an dem der Access-Point hängt.
Scheinbar setzt das die Dose auf off beim restart. Werde dort mal weiterforschen...
Cheers,
Pula
Danke nochmal!
Habe weitergeforscht und es war ein ziemlich ungeschicktes notify, das das ausgelöst hat.
Danke für Deine Hilfe, wäre wahrscheinlich sonst noch ewig weitergestolpert :-)
Cheers,
Pula