PRESENCE/lepresenced nach Neustart FHEM

[KernSani]

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

[pula]

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

[PatrickR]

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.

[Markus Bloch]

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

[pula]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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):

Code Auswählen Erweitern

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

[PatrickR]

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.

[pula]

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

[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