[patch] presenced, lepresenced, collectord

[Martin Fischer]

Hallo Zusammen,

die Anwesendheit überprüfe ich, wie vermutlich viele von Euch, mittels presenced, lepresenced und collectord (für beide Varianten). Ich betreibe verschiedene Netzwerkzonen, so dass sich die presenced bzw. lepresenced "Satelliten" nicht immer im selben Netz befinden, wie der collectord. Zum Teil ist hier auch NAT im Spiel.

Nun möchte ich die Erreichbarkeit sowie Funktionalität des gesamten "Orchesters" (collectord, collecterd für lepresenced, presenced und lepresenced) ausserhalb von FHEM z.B. mittels monit überwachen.

Dazu habe ich sowohl collectord, presenced und lepresenced um ein "ping" erweitert. "ping" ist jedoch nur weiterer command, der dann mit "pong" antwortet und die Verbindung trennt.

Hier ein Auszug für monit:

Code Auswählen Erweitern

if failed host localhost port 5222 with send "ping\n" expect "pong" timeout 30 seconds then alert

Bei mir funktionieren die hier anhängenden Anpassungen, so dass ich mich freue, wenn diese nach einer Prüfung der Maintainer so oder angepasst, übernommen werden.

Viele Grüße
Martin

[Markus Bloch]

Hallo Martin,

ich hab kein Problem damit das einzubauen. Würde das nicht auch mit "command rejected" funktionieren?

Code Auswählen Erweitern

if failed host localhost port 5222 with send "ping\n" expect "command rejected" timeout 30 seconds then alert

Bei presenced und lepresenced (sofern ich mich nicht irre) schließt Du aktiv die Verbindung nach dem "pong". Beim collectord nicht. Hat das einen Grund?

Viele Grüße

Markus

[Martin Fischer]

Hallo Markus,

ich hab kein Problem damit das einzubauen. Würde das nicht auch mit "command rejected" funktionieren?

In der Theorie (und natürlich auch in der Praxis  ) funktioniert das mit "command rejected".

Aber:
Mein Argument für ein "ping / pong" (oder etwas ähnliches, z.B. "knock / knock") ist, das ich ja gezielt eine Funktion testen will. Da ist es meiner Menung nach einfach schöner, wenn bei einer entsprechenden Abfrage auch die erwartet Antwort kommt.

Wenn man "command rejected" mißbraucht, weiss man ja eigentlich nicht ob der Befehl "ping" abgelehnt wird ("rejected") und ein Fehler vorliegt oder weil der Befehl unbekannt ist.

Wenn man "command unknown" mißbraucht, weiss man das der Befehl als falsch erkannt wurde. Das würde aber auch kommen, wenn man ein Typo hat. Ich fand es einfach nur "sauberer". 

Bei presenced und lepresenced (sofern ich mich nicht irre) schließt Du aktiv die Verbindung nach dem "pong". Beim collectord nicht. Hat das einen Grund?

Bei (le)presenced kann ich mich entsinnen, dass das Verhalten von unterschiedlich war: einer hat die Verbindung (laut log) von sich aus geschlossen, der andere nicht. Ist aber nur as der Erinnerung, hab die Änderung schon vor längerem angewandt und erst jetzt veröffentlicht.

Bei collectord wird die Verbindung laut log geschlossen. Daher habe ich das nicht nochmal eingebaut. Da bist Du tiefer im Bild 

Viele Grüße
Martin

[Markus Bloch]

Hallo Martin,

ich habe den Ping-Befehl für collectord und presenced übernommen und neue Pakete bereitgestellt.

Viele Grüße

Markus

[Martin Fischer]

Hallo Markus,

ich habe den Ping-Befehl für collectord und presenced übernommen und neue Pakete bereitgestellt.

vielen Dank dafür! Das freut mich 

Wäre toll, wenn lepresenced noch nachzieht...

Viele Grüße
Martin

[PatrickR]

Mahlzeit!

Wäre toll, wenn lepresenced noch nachzieht...

Na gut

Version 0.9 ist im SVN. Habe den Patch etwas modifiziert, neben "redaktionellen" Änderungen habe ich die Antwort noch etwas erweitert:

Code Auswählen Erweitern


pr@epsilon:~% echo ping | nc rpi-flur 5333
pong [clients=3;devices=13;min_age=0;max_age=1133;beacons_hcitool=15870;beacons_hcidump=15870;beacons_diff=0]


Ggf. müsstest Du Dein Matching minimal anpassen, vermutlich expect "^pong". Dafür gibt es aber Potenzial für einen Ausbau des Checks.

Patrick

[Martin Fischer]

Mahlzeit!
Na gut

Danke Dir...

Version 0.9 ist im SVN. Habe den Patch etwas modifiziert, neben "redaktionellen" Änderungen habe ich die Antwort noch etwas erweitert:
[...]
Ggf. müsstest Du Dein Matching minimal anpassen, vermutlich expect "^pong". Dafür gibt es aber Potenzial für einen Ausbau des Checks.

Danke auch dafür... allerdings würde ich es eher begrüßen, wenn collectord, presenced UND lepresenced das gleiche Verhalten, sprich die gleiche Antwort liefern würden. Mir würde ein "pong" ausreichen.

Vielleicht als Kompromiss:
Pack doch die erweiterte Antwort zusätzlich in ein "status" cmd.

Viele Grüße
Martin

[PatrickR]

^pong sollte auf alle Varianten matchen.


Von unterwegs gesendet.

[Martin Fischer]

Nun, ich bin durchaus in der Lage "regular expressions" anzuwenden..    Darum ging es jedoch nicht. Es ging ja um "gleiches Verhalten".

Du hast es jetzt anders implementiert. Dafür bedanke ich mich und finde mich dann damit so ab. 

So wie ich es sehe, gabe es im Vorfeld jedoch keine Anfrage / Anforderung zu den zusätzlichen Infos; ein einfaches "pong" hätte also meiner Meinung nach gereicht.

Aber lassen wir das..

Danke für die Anpassung...

[PatrickR]

Hallo Martin!

Um ehrlich zu sein bin ich etwas irritiert.

Nun, ich bin durchaus in der Lage "regular expressions" anzuwenden..    Darum ging es jedoch nicht. Es ging ja um "gleiches Verhalten".

Es ging mir nicht darum, Dich in der hohen Kunst der Programmierung zu belehren sondern lediglich darum, wie Du aus "Usersicht" das gleiche Ergebnis wie "gleiches Verhalten" bekommst, nämlich "gleiche Konfiguration". Das war mir auch deshalb besonders wichtig, weil ich Markus nicht mit meiner Implementierung quasi in Geiselhaft nehmen möchte.

So wie ich es sehe, gabe es im Vorfeld jedoch keine Anfrage / Anforderung zu den zusätzlichen Infos; ein einfaches "pong" hätte also meiner Meinung nach gereicht.

Wenn wir ehrlich sind, dann gab es für lepresenced selbst auch keine Anforderung, nicht einmal für blescan.pl (wenn Du Dich noch erinnerst). Und ich muss Dir widersprechen. Die Anforderung gab es, nämlich bei mir selbst und inspiriert durch Deine Idee. Der Ansatz, neben einem Check, ob der Prozess läuft, auch "in den Prozess reinzuschauen" ist ja äußerst sinnvoll, gerade weil sich durch die wundervolle Bluetooth-Implementierung und Linux gerne mal was verhakt. Ich habe das allerdings weitergedacht, so dass man optional(!) echte Lebenszeichen von lepresenced und den gespawnten Prozessen bekommen kann und damit gleich - zumindest mit starker Unschärfe - Fehler wie das Ausbleiben jeglicher Beacons (vgl. Schwesterthread) detektieren kann.

Gerne können wir das - vielleicht bist Du mal in Berlin - bei einem Bier vertiefen

Patrick

[Martin Fischer]

Hallo Patrick,

ich widerspreche Dir doch gar nicht.. meine Argumentation bezieht sich auf die Sicht des Users. _Ich_ halte es für sinnvoll, wenn sich die Drei gleich verhalten.. und man muss es nur einmal erklären und insbesondere für Anfänger nicht auf regexp verweisen.

Daher der Vorschlag, die zusätzlichen Informationen in einen extra command zu packen.

"ping": liefert "pong"
"status" liefert: clients=3;devices=13;min_age=0;max_age=1133;beacons_hcitool=15870;beacons_hcidump=15870;beacons_diff=0

Wem ein "pong" ausreicht, der senden einen "ping".. wer mehr wissen will, sendet ein "status" und benötigt den "pong" dann nicht...

Innerhalb FHEM gibt es schon genug unterschiedliche "Rückmeldungen" auf vermeintlich gleiche Aktionen. Aber diese Diskussion führe ich immer wieder mal schon seit gefühlt > 8 Jahren... irgendwo bei den ehemaligen FHEM Google Group nachlesbar 

ABER: das ist meine Meinung.. und die muss sich nicht mit Deiner decken, also.... alles gut... 

Viele Grüße

[Markus Bloch]

Daher der Vorschlag, die zusätzlichen Informationen in einen extra command zu packen.

"ping": liefert "pong"
"status" liefert: clients=3;devices=13;min_age=0;max_age=1133;beacons_hcitool=15870;beacons_hcidump=15870;beacons_diff=0

Würde ich begrüßen.

Gruß
Markus

[stromer-12]

Hallo Markus,

ich habe den Ping-Befehl für collectord und presenced übernommen und neue Pakete bereitgestellt.

ist dieses presenced-1.5 auch für rpi ?
Ich habe die presenced-rpi-1.4 bei mir drauf.

Gruß
Stromer

[Markus Bloch]

Hallo Stomer,

ja, die Version ist auch für den Rpi gedacht. Mit der Einführung von systemd ist die Unterscheidung hinfällig geworden.

Viele Grüße

Markus

[stromer-12]

Achso, ok.
Danke

Gruß
Stromer