[GELÖST] Überwachung / Zugriff auf zweiten Raspi

Markus. · 12 Dezember 2019, 10:49:59

Hallo Zusammen,

ist es eigentlich möglich ein Logfile auf einem andern Raspberry zu überwachen und eine Art Status device aus den Ergebnisen des Logfiles zu erstellen.
Also FHEM läuft auf Raspi1 und auf Raspi2 wird ein Logfile kontinuierlich alle 5 Sekunden mit einer neuen Zeile gefüllt.
Der Logeintrag sieht folgendermaßen aus:

Code Auswählen


2019.11.27 11:09:02 [./threads.cpp: 704] T:193102 thread_IOWorker L Alarm: 0 | Baby: 0 | Feuer: 0 | P-Ruf: 0 | Tel: 0 | T▒r 1: 0 | T▒r 2: 0 | Wasser: 0
2019.11.27 11:09:07 [./threads.cpp: 704] T:193102 thread_IOWorker L Alarm: 0 | Baby: 0 | Feuer: 0 | P-Ruf: 0 | Tel: 0 | T▒r 1: 0 | T▒r 2: 0 | Wasser: 0
2019.11.27 11:09:12 [./threads.cpp: 704] T:193102 thread_IOWorker L Alarm: 0 | Baby: 0 | Feuer: 0 | P-Ruf: 0 | Tel: 0 | T▒r 1: 0 | T▒r 2: 0 | Wasser: 0
2019.11.27 11:09:17 [./threads.cpp: 704] T:193102 thread_IOWorker L Alarm: 0 | Baby: 0 | Feuer: 0 | P-Ruf: 0 | Tel: 0 | T▒r 1: 0 | T▒r 2: 0 | Wasser: 0
2019.11.27 11:09:22 [./threads.cpp: 704] T:193102 thread_IOWorker L Alarm: 0 | Baby: 0 | Feuer: 0 | P-Ruf: 0 | Tel: 0 | T▒r 1: 0 | T▒r 2: 0 | Wasser: 0
2019.11.27 11:09:27 [./threads.cpp: 704] T:193102 thread_IOWorker L Alarm: 0 | Baby: 0 | Feuer: 0 | P-Ruf: 0 | Tel: 0 | T▒r 1: 0 | T▒r 2: 0 | Wasser: 0
2019.11.27 11:09:32 [./threads.cpp: 704] T:193102 thread_IOWorker L Alarm: 0 | Baby: 0 | Feuer: 0 | P-Ruf: 0 | Tel: 0 | T▒r 1: 0 | T▒r 2: 0 | Wasser: 0
2019.11.27 11:09:37 [./threads.cpp: 704] T:193102 thread_IOWorker L Alarm: 0 | Baby: 0 | Feuer: 0 | P-Ruf: 0 | Tel: 0 | T▒r 1: 0 | T▒r 2: 0 | Wasser: 0

Es müsste also immer die neuste Zeile zur Auswertung genommen werden. Diese Zeile würde ich dann gerne als device mit den unterschiedlichen Statis anzeigen lassen.
Hab aber im Moment noch keine Idee wie ich das hinbekommen kann. Da fängt es schon mit dem Zugriff von FHEm auf Raspi 1 auf das Logfile in Raspi2 an.

Zum andren würde ich auch gerne den GPIO Status des zweiten Raspis auswerten können.

Für Tipps wäre ich euch sehr dankbar..

Viele Grüße

Markus

MadMax-FHEM · 12 Dezember 2019, 10:57:21

Ich hab ja nicht so 100%ig verstanden was das mit dem Logfile und der Zeile etc. usw.

Wie wird das Logfile, das du hier zeigst erzeugt?

Wenn es aus Events kommt, also ein FileLog ist, dann passen die folgenden Möglichkeiten (direkt):

Fhem2Fhem
MQTT (vermutlich auch)

Ansonsten musst du halt die Logeinträge in ein Device (Dummy?) kriegen: daher die Frage wo/wie kommt das Logfile zustande
Und dann per Fhem2Fhem/MQTT "übertragen"...

Oder eben mit "Linux-Mitteln" einfach direkt auf das Logfile per ssh etc. zugreifen...

Gruß, Joachim

Markus. · 12 Dezember 2019, 11:20:09

das Logfile auf dem zweiten RPI wird durch einen Service erstellt der eben auf dem zweiten RPI läuft. Auf diesem läuft kein FHEM.
RPI1 mit FHEM soll die Auswertung und Visualisierung machen.
Die neuen Einträge in diesem Logfile kommen zyklisch. Also alle 5 Sekunden.

Glaube der Zugriff per SSH auf den zweiten Raspi hört sich gut an. Hast Du da ein Beispiel wie ich das aufbauen könnte im ersten Schritt?

Gruß

Markus

Otto123 · 12 Dezember 2019, 11:40:07

Hallo Markus,

hast Du Einfluss auf den Service?
Ich würde sagen, ohne weitere Umwege wäre ein (Prinzip) mosquitto_pub -h Pi1 -i Log -t t1/t2/t3/ -m {logzeile}
Die einfachste und direkteste Variante.

Notfalls mit System Mitteln die letzte Zeile aus dem Log in den pub Befehl schieben. Stichwort inotify, tail

Ich habe keine konkrete Lösung, aber den prinzipiellen Ansatz mit mqtt habe ich schon mal getestet und beschrieben.

Gruß Otto

Markus. · 12 Dezember 2019, 11:44:43

Ich glaube ich hol mal zur Erklärung ein wenig weiter aus

Also meine Frau ist Schwerhörig und wir haben Rauchmelder und Klingelsensoren von Humantechnik. Das Funksystem basiert auf 868 MHZ. Bekomme da aber die Codes nicht vernünftig über einen Cul ausgelesen. Das heisst wenn einer der Senoren auslöst, wird das durch eine Blitzeinheit neben dem akustischen Signal dargestellt.
Zu den ganzen Sensoren und Blitzeinheiten, haben wir noch so eine Art Gateway. Das Gateway kommuniziert mit einem WebService der das ganze dann auf eine Handyapp bringt. Nunja die App ist echt übel. Ich will das ganze per Telgram haben. das Gateway ist nichts anderes wie ein Raspi mit 868 MHZ funkmodul das eben lauscht von welchem sensor was kommt. Dann sendet das Ding per rest die Info and den Server im Web. Gleichzeigitg werden über die GPIOs des raspis entsrechende Stus LEDs angesteuert und eben die Info ins Log file geschrieben. Ich möchte ungern auf diesem Gateway raspi zusätzlcih FHEM installieren um dann FHEM2FHEM zu machen. Ein Status des Servives sieht wie folgt aus:

Code Auswählen


● htgw.service - LSB: Humantechnik Gateway Daemon
   Loaded: loaded (/etc/init.d/htgw; generated; vendor preset: enabled)
   Active: active (running) since Wed 2019-11-27 10:30:49 UTC; 1h 0min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 535 ExecStart=/etc/init.d/htgw start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/htgw.service
           └─918 /usr/bin/SCREEN -h 9999 -dmS htgw su root -c ./htgw  --daemon-foreground

Nov 27 10:33:59 rpi-ht htgw[535]: | 1 | Input          |   6  |  31  -  32  |  12  | Input          | 0 |
Nov 27 10:33:59 rpi-ht htgw[535]: | 0 | Input          |  13  |  33  -  34  | GND  |                |   |
Nov 27 10:33:59 rpi-ht htgw[535]: | 0 | Input          |  19  |  35  -  36  |  16  | Input          | 0 |
Nov 27 10:33:59 rpi-ht htgw[535]: | 0 | Input          |  26  |  37  -  38  |  20  | Input          | 0 |
Nov 27 10:33:59 rpi-ht htgw[535]: |   |                | GND  |  39  -  40  |  21  | Input          | 0 |
Nov 27 10:33:59 rpi-ht htgw[535]: |---|----------------|------|-------------|------|----------------|---|
Nov 27 10:35:03 rpi-ht htgw[535]: Offline 3

Das müsste doch irgendwie "remote" von meinem FHEM Server auszulesen sein neben der Auswertung des Logfiles.

Viele Grüße

Markus

Otto123 · 12 Dezember 2019, 12:17:15

Zitat von: Markus. am 12 Dezember 2019, 11:44:43
Ich möchte ungern auf diesem Gateway raspi zusätzlcih FHEM installieren um dann FHEM2FHEM zu machen.

Deswegen ja die Idee mqtt.
Du kannst auch über FHEMWEB zugreifen mqtt find ich aber mittlerweile eleganter.

Willst Du jetzt primär das Log oder GPIO Status? Oder muss es beides?
Wie zeitnah reagiert dieser Service und Webservice? Sprich wie zeitnah muss es auf Telegram sein? Mir scheint die Anwendung ziemlich zeitkritisch.

Der Zustand der GPIO lässt sich doch auf Systemebene einfach auslesen und über mqtt (oder was auch immer) abschicken?

Gruß Otto

Markus. · 12 Dezember 2019, 12:39:07

Zeitkritisch ist das nicht wirklich, läuft alles in einem 5 Sekunden Fenster.
Will beides mal testen, soll heißen GPIO Status und Logfile. Aber ich werde erstmal Mosquito Client installieren auf dem Teil
Gibt es igrnedwo eine Info/doku wie ich z.B. den GPIO stauts auf MQTT gepublished bekomme?
In deiner Doku machst du das ja mit der CPU Temp. Aber mir ist nicht ganz klar wie die Systax ist oder vielmehr wie ich da Werte auf Systemebene abfragen und Publishen kann.

Gruß

Markus

Otto123 · 12 Dezember 2019, 13:57:20

Hallo Markus,

so spontan fällt mir ein mit wiringpi oder irgendwie geht das sogar mit cat siehe z.B. hier
cat hat den Nachteil man muss wohl erhöhte Rechte haben. Ich bin da auch nicht so fit, aber helfe Dir gern.

Probier mal so ein Beispiel mit dem mosquitto Client aus, das ist ziemlich simpel und schnell gemacht. Und ist eine gute Vorarbeit.

Gruß Otto

Markus. · 15 Dezember 2019, 09:36:03

Hallo Otto,
Also hab dein Beispiel mal umgesetzt, bis auf den Unterschied, das ich auch mosquitto als Broker auf dem Ghem Server definiert habe und somit kein Device automatisch angelegt wird. Subscriben geht aber erstmal auf der Konsole. Wiringpi ist auf dem zweiten auch jetzt installiert und bekomme den GPIO Status angezeigt. Aber wie packe ich denn eine wiringpi Abfrage auf dem zweiten Taspi in ein MQTT- publish?

Viele Grüße

Markus

Otto123 · 15 Dezember 2019, 16:00:17

Hallo Markus,

erster Schritt: Ich mache mal meinen Einzeiler als Script:

Code Auswählen

#Variable setzen
host=raspib2
CID=COMPUTER
topic=CPU/$(hostname)/temperature
pause=30

# Endlosschleife
while [ true ] ; do
    message=$(($(</sys/class/thermal/thermal_zone0/temp)/1000))
    mosquitto_pub -h $host -i $CID -t $topic -m "$message" 
    sleep $pause
done

Zweiter Schritt, ich baue die Message anders:

Code Auswählen

    wert=$(cat /sys/class/leds/led0/brightness)
    message=$wert

Mit der Abfrage über wiringpi muss das doch so ähnlich gehen?

Jetzt kann man alles noch auf json Format umstellen und mehere GPIO Ports in einen String packen und gleich getrennte Readings machen. So in etwa:

Code Auswählen

    wert=$(cat /sys/class/leds/led0/brightness)
    message={\"LED0\":\"$wert\"}

Gruß Otto

Otto123 · 16 Dezember 2019, 10:09:15

Hallo Markus,

ich habe mal noch etwas gespielt. Ich habe auf der Seite des Entwicklers von wiringpi gelesen: er wird es nicht weiter entwickeln.
Ich arbeite gern mit Shell Scripten, aber ich glaube für diese Aufgabe ist python besser.
So habe ich mal ganz auf die Schnelle ein Script zusammen kopiert (ich habe kaum Ahnung von python - sorry) - quasi als Fallstudie

http://www.steves-internet-guide.com/into-mqtt-python-client/
https://makezine.com/projects/tutorial-raspberry-pi-gpio-pins-and-python/
https://keyboardinterrupt.org/catching-a-keyboardinterrupt-signal/

Ich habe ein device in FHEM raspib2

Code Auswählen

defmod fuehler1 MQTT2_DEVICE mqtt2c
attr fuehler1 IODev mqtt2s
attr fuehler1 readingList home/states/.* { if ($TOPIC=~m/$NAME/) { json2nameValue($EVENT) } }

das folgende Script braucht vorher pip install paho-mqtt und setzt bei Pin7 eine LED an und fragt Pin5 auf Tastendruck ab.

Hinweis:
Das ist zwar eine Endlosschleife, aber kein Polling! Der Befehl GPIO.wait_for_edge wartet auf den Tastendruck!
Quasi ohne Verzögerung wird über MQTT gesendet! das Programm erzeugt keine nennenswerte Systemlast!

Code Auswählen

#braucht paho-mqtt, vorher installieren!
#pip install paho-mqtt

# mqtt initialisieren und eine Startnachricht senden
import paho.mqtt.client as mqtt
client =mqtt.Client("COMPUTER")
broker="192.168.56.82"
client.connect(broker, keepalive=86400)  # per default ist keepalive=60, damit steht die Verbindung nur 1 min :
client.publish("home/states/fuehler1","{\"GPIO\":\"start\"}")

#gpio initialisieren. Achtung Pin Modus BOARD! Pin 7 LED, Pin 5 Taster
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(7, GPIO.OUT)
GPIO.output(7, True)
GPIO.setup(5, GPIO.IN)

print("Starte Schleife ... Can be canceled with CTRL+C")
try:
    while True:
        GPIO.wait_for_edge(5, GPIO.FALLING)
        client.publish("home/states/fuehler1","{\"GPIO\":\"Pressed\"}")
        print("Button 1 Pressed")
        GPIO.wait_for_edge(5, GPIO.RISING)
        client.publish("home/states/fuehler1","{\"GPIO\":\"Released\"}")
        print("Button 1 Released")
except KeyboardInterrupt:
    print("KeyboardInterrupt has been caught.")

print("Beende Programm")
GPIO.output(7, False)
GPIO.cleanup()

Edit:
Das Programm wird jetzt mit ctrl+c beim nächsten Tastendruck (PIN 5) ordentlich beendet.

Man könnte das Script einfach über crontab beim systemstart starten und laufen lassen.

Gruß Otto

Wernieman · 16 Dezember 2019, 11:25:14

Nachfrage:
Wird jetzt Logfileanalyse benötigt oder geht es per GPIO?
Habe beim Durchlesen den Faden verloren ...

Grundsätzlich.
Würde bei solche einer Anwendung immer die Daten Pushen (per MQTT, FHEM-Web, Telnet o.Ä.) als zu pollen (d.h. FHEM fragt ab).

Wenn ich es richtig verstanden habe, hast Du vollen Zugriff auf den Pi?

Markus. · 16 Dezember 2019, 12:11:05

Hallo Zusammen,

Danke Dir Otto.. Hoffe ich komme da heute mal weiter..
Mit Wiringpi habe ich auch gelesen, das es nicht weiter entwickelt wird. Dann bin ich über folgendes gestolpert

http://www.jamesrobertson.eu/pysnippets/2013/mar/08/listening-for-a-gpio-pin-state-ch.html

Das Problem an der Sache ist, das das ganze auf Mosquitto-Pythton aufbaut was ja durch PAHO abgelöst wurde.
Wie auch immer..
Die RPI.GPIO ist schon in Stretch drin? Wo finde ich denn da eine Doku darüber um mal ganz banale Sachen auf der Konsole zu machen wie GPIO Status und so ?

@Wernieman.. nein mit dem Logfile ist noch nicht ganz abgehakt, aber finde die Abfrage und publishen des GPIO Status im Moment Spannender..

Gruß

Markus

Otto123 · 16 Dezember 2019, 16:02:40

Hallo Markus,

mein Beispiel kannst Du nehmen wie es ist und probieren. In deinem mosquitto solltest Du sehen was published wird.
PIN5 und 6 kannst Du anstatt des Tasters auch mit einem Jumper brücken.

Meine beiden Links sollten zum Einstieg für banale Sachen gut sein, die haben mir auch geholfen. Bei steve kannst Du umher schauen, der hat einige, gut bebilderte Artikel genau zu dem Thema.
Ansonsten gibt es für python noch sowas https://www.python-kurs.eu/

Ja RPi.GPIO kannst Du einfach importieren, das ist bei python offenbar dabei.

Ich finde ja, mit dem separat installierten mosquitto broker machst Du Dir die Sache schwerer als mit MQTT2

Gruß Otto

Markus. · 16 Dezember 2019, 17:58:44

Hallo Otto,

viel brücken kann ich an dem Teil keine Pins. Da ist ein 868 MHZ Funkmodul verbaut und LEDs als Ausgänhe zum signalisieren der Alarmzustände.
Hier mal eine Übersicht:

Code Auswählen


 +-----+-----+---------+------+---+---Pi 3B--+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 |  OUT | 0 |  3 || 4  |   |      | 5v      |     |     |
 |   3 |   9 |   SCL.1 |  OUT | 0 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |  OUT | 0 |  7 || 8  | 0 | IN   | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 0 | IN   | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |  OUT | 0 | 11 || 12 | 1 | OUT  | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |  OUT | 0 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |  OUT | 0 | 15 || 16 | 0 | IN   | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 0 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI |  OUT | 0 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO |  OUT | 0 | 21 || 22 | 0 | IN   | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK |   IN | 0 | 23 || 24 | 0 | IN   | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 0 | IN   | CE1     | 11  | 7   |
 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |
 |   5 |  21 | GPIO.21 |   IN | 0 | 29 || 30 |   |      | 0v      |     |     |
 |   6 |  22 | GPIO.22 |   IN | 0 | 31 || 32 | 0 | IN   | GPIO.26 | 26  | 12  |
 |  13 |  23 | GPIO.23 |   IN | 0 | 33 || 34 |   |      | 0v      |     |     |
 |  19 |  24 | GPIO.24 |   IN | 1 | 35 || 36 | 0 | IN   | GPIO.27 | 27  | 16  |
 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | IN   | GPIO.28 | 28  | 20  |
 |     |     |      0v |      |   | 39 || 40 | 0 | IN   | GPIO.29 | 29  | 21  |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+---Pi 3B--+---+------+---------+-----+-----+

Das Problem ist, ich kann im Moment nicht sehen welche der GPIOs auf High geschaltet werden bei einem bestimmten Alarmzustand. Das bin ich im Moment am checken. Die Meldung die über die LEDs ausgeben wird, wollte ich dann weiter verwenden.

Bezüglich Mosquitto statt MQTT2 als Broker hast Du recht. Da ich MQTT auf dem FHEM serve im Moment nicht produktiv verwende, wollte ich den Sevrive einfach disablen und MQTT2_Server auf dem FHEM verwenden. (Falls meine "Denke" hier richtig ist).

Aber was ich jetzt erstmal amche ist mir so ein Skript zusammen bauen, das mir die GPIOs auf rising abfragt und pubished.

Viele Grüße und viiiiiiielen Dank für deine Hilfe!!

Markus