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:
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
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
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
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 (https://heinz-otto.blogspot.com/2019/11/mqtt-ich-muss-das-testen.html).
Gruß Otto
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:
● 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
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 (https://heinz-otto.blogspot.com/2019/02/fhem-http-client.html) 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
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
Hallo Markus,
so spontan fällt mir ein mit wiringpi oder irgendwie geht das sogar mit cat siehe z.B. hier (http://nicht-traeumen-sondern-machen.de/RaspberryPi_Basteleien/Code_Abfrage_eines_GPIO_Ports.php?anker=a1)
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
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
Hallo Markus,
erster Schritt: Ich mache mal meinen Einzeiler als Script:
#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:
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:
wert=$(cat /sys/class/leds/led0/brightness)
message={\"LED0\":\"$wert\"}
Gruß Otto
Hallo Markus,
ich habe mal noch etwas gespielt. Ich habe auf der Seite des Entwicklers von wiringpi (http://wiringpi.com/)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
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!
#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
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?
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
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
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:
+-----+-----+---------+------+---+---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
Naja mein Test mit PIN5 war eine "ungefährliche" Versuchsvariante, da weiß ich das es geht und nichts passiert :)
An welchem PI Du dein Script testest ist ja egal ;) Da praktisch "nichts" installiert werden muss - ok eine python bibo :)
Ich würde
- ein Device in FHEM machen.
- Etwas per Hand (python Script) per mqtt publishen
- Die GPIO Abfrage mit Print testen (python script)
- Und dann beides "verknüppern" ;)
Oder andersrum :)
so in etwa hatte ich es vor... :-) Dauert nur etwas länger, da viel neuland auf mich wartet.. :-)
Da wären Abschaltung Mosquitto auf dem Fhem Server. Dann MQTT2_Server drauf neben Python Abfragen, und GPIOs ausklamüsren um raus zubekommen welche LED Warnmeldung an welchem GPIO hängt. Nunja letzteres habe ich jetzt..
Hoffe nur das geht mit dem MQTT2_Server smooth..
Gruß
Markus
Hallo Otto,
noch ne Frage ;-) Mal zum Verständnis..
Und zwar werden ja auf dem zweiten Raspi die Outputs über einen Service geschaltet. Wie sieht es dann da bei einem exklusiven Zugriff aus? Kann ich die Outputs eigentlich überhaupt "passiv" lesen?
Zum Beispiel Pin 15 ist ja laut WiringPI (getall) als Output definiert. Wenn ich jetzt "GPIO.setup (15,Output.Out)" mache im Skript wird dann nicht für den Skript-Prozess
der Output exklusiv behandelt und eben für den eigentlichen Service gesperrt?
Und noch was....
Wenn man innerhalb des Skriptes einen GPIO.Setup als OUT definiert, kann man dann GPIO.RISING und GPIO.Faling verwenden auf den als Output definierten Pin ?
So in etwa...
# mqtt initialisieren und eine Startnachricht senden
import paho.mqtt.client as mqtt
client =mqtt.Client("LISAGATEWAY")
broker="192.168.178.41"
client.connect(broker, keepalive=86400) # per default ist keepalive=60, damit steht die Verbindung nur 1 min :
client.publish("home/states/LED15","{\"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(15, GPIO.OUT)
GPIO.setwarnings(False)
print("Starte Schleife ... Can be canceled with CTRL+C")
try:
while True:
GPIO.wait_for_edge(15, GPIO.RISING)
client.publish("home/states/LED15","{\"GPIO\":\"AN\"}")
print("Alarm Pin 15 an")
GPIO.wait_for_edge(15, GPIO.FALLING)
client.publish("home/states/LED15","{\"GPIO\":\"AUS\"}")
print("Alarm Pin 15 aus")
except KeyboardInterrupt:
print("KeyboardInterrupt has been caught.")
print("Beende Programm")
#GPIO.output(15, False)
GPIO.cleanup()
Ich muss den PIN Status halt "passiv" lesen.
Gruß
markus
Hallo Markus,
das hat mich gestern Abend auch noch beschäftigt :)
Dabei hab ich auf die Schnelle noch das probiert:
Abfrage PIN7
#!/usr/bin/env python
#coding: utf8
import RPi.GPIO as GPIO
# Zählweise der Pins festlegen
GPIO.setmode(GPIO.BOARD)
# Pin 7 als Eingang festlegen
GPIO.setup(7, GPIO.IN, pull_up_down = GPIO.PUD_DOWN)
# Schleifenzähler
i = 0
# Endlosschleife
while 1:
# Eingang lesen
if GPIO.input(7) == GPIO.HIGH:
# Wenn Eingang HIGH ist, Ausgabe im Terminal erzeugen
print "Eingang HIGH " + str(i)
# Schleifenzähler erhöhen
i = i + 1
Und damit im zweiten Prozess das PIN7 gesetzt:
import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BOARD) # Broadcom pin-numbering scheme
GPIO.setup(7, GPIO.OUT) # output rf
# Initial state for LEDs:
print("Testing RF out, Press CTRL+C to exit")
try:
print("set GIOP high")
GPIO.output(7, GPIO.HIGH)
time.sleep(5)
except KeyboardInterrupt: # If CTRL+C is pressed, exit cleanly:
print("Keyboard interrupt")
except:
print("some error")
finally:
print("clean up")
GPIO.output(7, GPIO.LOW)
GPIO.cleanup() # cleanup all GPIO
Alles nur geraubt :) Aber prinzipiell funktioniert das. Ok die Flanke ermitteln ist damit nicht geklärt. ;)
Gruß Otto
Hallo Otto,
das ist ja genial.. :-) Hoffe ich komme heute mal zum testen. Aber wenn ich den cleanup richtig verstehe, sollte er doch im lesenden Prozess sein ? Oder?
Viele Grüße
Markus
ZitatCleanup
At the end any program, it is good practice to clean up any resources you might have used. This is no different with RPi.GPIO. By returning all channels you have used back to inputs with no pull up/down, you can avoid accidental damage to your RPi by shorting out the pins. Note that this will only clean up GPIO channels that your script has used. Note that GPIO.cleanup() also clears the pin numbering system in use.
Verstehe ich anders...
Im lesenden Prozess habe ich ja nichts verändert/will ich nichts verändern. Ja ok, ich schalte einen PullDown Widerstand. ??? Kann man vielleicht weglassen :)
Dein schreibender Prozess ist ja deine Anwendung.
Ich weiß es ehrlich nicht. Versuch ...
Es gibt noch andere GPIO Bibliotheken: GPIO Zero und pigpio ...
Habe gestern mal ein wenig mit dem Skript gespielt. Bin zwar noch einiges Entfernt von dem was ich haben will, aber zum verstehen des ganzen ist es verdammt hilfreich. Zwei fragen hätte ich dazu :-)
Und zwar, wenn ich client.connect(broker, keepalive=86400) verwende bekomme ich einen Syntax Fehler wie "Struct H blabla" (hab vergessen den zu kopieren).
Wenn ich dann baer das Keepalive raushole funktioniert es. Kann es sein das entweder nur der Host Oder alle 4 Parameter definiert werden müssen?
So wie "connect(host, port=1883, keepalive=60, bind_address="")"
Oder liegt es am Interpretereintrag den ich verwende #!/usr/bin/python
Und letzte Frage bevor ich heute Abend weiter bastel...
Ich habe das script jetzt im Verzeichnis /home/pi ablegt. Gibt es igrendwie eine Empfehlung wo solche eigenen Scripte liegen sollten?
Gruß
Markus
Hallo Markus,
So wie es dastand geht es bei mir, ich kann lediglich nicht keepalive=0 setzen.
Mit dem
broker="192.168.56.82"
client.connect(broker, port=1883, keepalive=86400)hatte ich folgende Probleme:
client.connect("raspib2") hat er gemacht, dann ging plötzlich meine Namensauflösung nicht mehr
client.connect("192.168.56.82") hat er nicht gemacht, da hat er die Punkte angemeckert.
dann habe ich das als extra Variable gemacht und es geht sowohl mit IP als auch mit Namen. Teste vielleicht einen kürzeren keepalive, ich bin da eh nicht sicher wie man richtig macht.
Der Interpreter Eintrag spielt ja nur ne Rolle wenn Du die Datei ausführbar machst, ich spare mir das immer mit python script.py
Wo Du die Scripts hinlegst? das entscheide ich immer aus dem Bauch und nach momentanen Ordnungssinn.
Wenn auf dem pi nicht viel passiert lass ich sie in /home/pi man muss sie ja nur lesen können, und beim bearbeiten ist es einfach.
Man kann auch /opt/scripts machen oder im Web hab ich das gefunden:
ZitatEs gibt auf Linux /usr/local/sbin für SystemScripts und /usr/local/bin für allgemeine Userscripts
Ich habe da irgendwie für mich noch keine Ordnung :)
Wollte eigentlich vermeiden, auf die "remote" Logfiles zuzugreifen. Aber die RPI.GPIO lib scheint ein wenig statisch zu sein, was den Zugriff auf "im Zugriffbefindliche GPIOs" betrifft (geiles Wort :-) )
pigpio ist die nächste Lib für Python die ich mir mal ansehen will. Da geht auch remote GPIO Monitoring. Aber die Basics mit Python muss ich mir nebenbei auch noch in den Kopf prügeln :-)
ja das war die erste Idee.. Aber trotzt allem bin ich offen für jede Möglichkeit... hast du irgendwo einen link oder mehr Infos wie ich das bewerkstelligen könnte. neben meiner GPIO Bastelei :-)
So habs mal mit pigpio gemacht. Also das Monitor.py geändert für MQTT ohne irgendwelche Überprüfung ob die Verbindung steht
import sys
import time
import pigpio
import paho.mqtt.client as mqtt
client =mqtt.Client("COMPUTER")
broker="192.168.178.41"
client.connect(broker, keepalive=6000)
last = [None]*32
cb = []
def cbf(GPIO, level, tick):
if last[GPIO] is not None:
diff = pigpio.tickDiff(last[GPIO], tick)
client.publish("G={} l={} d={}".format(GPIO, level, diff))
last[GPIO] = tick
pi = pigpio.pi()
if not pi.connected:
exit()
if len(sys.argv) == 1:
G = range(0, 32)
else:
G = []
for a in sys.argv[1:]:
G.append(int(a))
for g in G:
cb.append(pi.callback(g, pigpio.EITHER_EDGE, cbf))
try:
while True:
time.sleep(60)
except KeyboardInterrupt:
print("\nTidying up")
for c in cb:
c.cancel()
pi.stop()
Der Datensatz der gepublished wird, sieht wie folgt aus
G=22 l=0 d=5005442
Also BCM Pin, Zustand vorher / nachher, und Zeit seit letztem Zustand
Das kommt auch so in etwa auf dem FHEM Server an. Aber bekomme für das MQTT Device folgende Meldung im Log
2019.12.19 18:17:47 3: MQTT2_COMPUTER: bad reading name l=0 d=5004293:.* G_22_l_0_d_5004293 (contains not A-Za-z/\d_\.- or is too long)
So nun steh ich auf dem schlauch. Wie bekomm ich den nun ein vernünftiges Reading daraus ?
Gruß
Markus
so bin mal ein Stück weiter gekommen:
Publishen tue ich jetzt nur noch den level (0 oder1 ) und die GPIO Nummer
client.publish ("GPIO{}:STATUS{}".format(GPIO, level))
Aber als MQTT Device passt das noch nicht ganz und sieht wie folgt aus
GPIO22_STATUS0 2019-12-19 19:04:20
GPIO22_STATUS1 2019-12-19 19:04:15
Das Reading müsste aber z.b GPIO22 heissen und der Wert eben nur 0 oder 1
Wie kann ich das denn in dem Publish Befehl so einbauen?
Gruß
Markus
kann ich das nicht direkt am MQTT2_Device "auseinander pfriemeln"
Am Ende soll ja für jede GPIO ein extra reading automatisch angelegt werden. Es wird ja bei Statusänderung jeweils die PIN Nummer und der Level gepublished..
Da steh ich im Moment auf dem Schlauch mangels Programierkenntnissen in Python.
Ich denke mal am elegantesten wäre es, wenn man das direkt in der Client.publsih Zeile des Skriptes defineren könnte.
client.publish ("GPIO{}:STATUS{}".format(GPIO, level))
Gruß
Markus
Vermutlich tust du dir leichter, wenn du das besser zergliederst und Topictree und Payload trennst. Später auf der FHEM-Seite ist das vermutlich mehr Aufwand... Auf Verdacht:
client.publish ("remotePi/GPIO{}/STATUS{} ".format(GPIO, level))
Danke dir.. Werds nacher mal vesuchen. Was ich jetzt mal in einen "Trockentest" ohne Broker gemacht habe ist folgendes.
print ("home/states/GPIO{}".format(GPIO)),("{}".format(level))
Das gibt mir folgendes Ergenis auf der Konsole bei einem blinkenden Ausgang
home/states/GPIO18 0
home/states/GPIO18 1
home/states/GPIO18 0
home/states/GPIO18 1
home/states/GPIO18 0
home/states/GPIO18 1
home/states/GPIO18 0
Was ja eigentlich schon mal nicht so schlecht aussieht.. oder
Somit habe ich den Topic tree eben dynamisch und payload getrennt mit einem Leerzeichen. Bin nur mal gespannt wenn ich das nachher mal mit dem Broker testen kann und ob MQTT2_Server das device dann auch mit dem reading gpio18 anlegt ;-)
:)
Klar, warum sollte MQTT2_DEVICE das nicht machen...
Tendiere aber dazu, den STATUS und ggf. (empfangsseitig....) den COMMAND-Pfad hinten anzufügen, und das dann bei der Auswertung in MQTT2_DEVICE anders zu lösen (readingList-Eintrag, wieder "auf Verdacht"):
home/GPIO18/states {{"GPIO18"=>$EVENT?"on":"off"}}
oder gleich generalisiert:
home/([^/]+)/states {{"$1"=>$EVENT?"on":"off"}}
genial :-) Ja genau so teste ich das. Muss es generalisiert machen mit dem Reading sonst müsste ich für jeden möglichen Pin manuell eins anlegen oder?
Im Skript wird ja die Pin Nummer geändert, je nachdem wer seinen Level geändert hat. Und eben für jeden pin der seinen Level geändert hat ein reading angelegt werden soll.
Was mir ehrlich gesagt nur nicht ganz klar ist ... was meinst Du denn mit dem COPMMAND-Pfad? :-(
Na ja, vermutlich willst du den GPIO auch von FHEM aus steuern können ;) . Warum dann nicht über MQTT, dann ist alles beieinander...?
Dafür wäre es nur wichtig, dass ein "Kreis" entsteht, also die Anweisung auf einem anderen Topic-Pfad liegt wie die Rückmeldung (deine heutige/gerade zu entwickelnde Statusmeldung). Dafür würde ich dann
home/GPIO18/set mit Payload 0 bzw. 1 vorschlagen...
Hat den Vorteil, dass du ggf. dann auch nur einzelne Teile abbonieren kannst, wenn du den MQTT-Verkehr "von außen" mithören willst. Ist zwar für so ein "kleines" Device nicht soooo wichtig, aber es geht ja auch ein bischen darum, eine Referenz zu haben, falls mal was größeres ansteht oder jemand das beim Suchen findet...
Für den Fall, dass die komplizierte Variante nicht klappt, für den empfangsseitigen Testen auch noch eine einfachere Variante. Da schreibst du einfach den gewünschten Readingnamen dahinter, Zustand ist dann 0 bzw. 1:
home/GPIO18/states GPIO18
(Hoffe, das Prinzip wird jetzt etwas klarer, wie die Verarbeitung innerhalb des Moduls abläuft.)
mmh habs jetzt mal getestet. Er erzeugt zwar das Reading zb. GPIO22 aber den Wert 0 oder 1 zeugt er nicht an :-(
defmod MQTT2_LISAGW2 MQTT2_DEVICE LISAGW2
attr MQTT2_LISAGW2 DbLogExclude .*
attr MQTT2_LISAGW2 IODev MQTT2_Server
attr MQTT2_LISAGW2 readingList LISAGW2:home/([^/]+)/states {{"$1"=>$EVENT?"on":"off"}}\
LISAGW2:home/states/GPIO22:.* GPIO22
attr MQTT2_LISAGW2 room MQTT2_DEVICE
setstate MQTT2_LISAGW2 2019-12-20 17:01:21 GPIO22
Wenn ich das Reading wie vorgeschlagen ändere, wird bei der nächsten Änderung des Levels, das alte Reading hinzgefügt.
LISAGW2:home/states/GPIO22:.* GPIO22
Gesendet (publish) wird der String wie folgt
home/states/GPIO22 1
aber der String der gepublshed wird ist doch so korrekt oder ?
topictree leerzeichen wert
Im Eventmonitor sieht das so aus
2019.12.20 17:28:53 4 : MQTT2_DEVICE_Parse: MQTT2_LISAGW2 home/states/GPIO22 => GPIO22
2019-12-20 17:28:53 MQTT2_DEVICE MQTT2_LISAGW2 GPIO22:
Gruß
Markus
stop halt....
hab jetzt mal subscribed... da sieht das wie folgt aus
home/states/GPIO22 (null)
Also macht der beim Publish irgendwas anderes mit dem Wert als beim client.publish.
Nun dann wieder zurück zum Skript und dem Publish Befehl :-(
so es wird nun wie folgt gepublished.
home/states/GPIO22 0 (null)
home/states/GPIO22 1 (null)
home/states/GPIO22 0 (null)
home/states/GPIO22: 0 (null)
home/states/GPIO22: 1 (null)
home/states/GPIO22: 0 (null)
home/states/GPIO22: 1 (null)
home/states/GPIO22: 0 (null)
Das mit dem Doppelpunkt habe ich noch ausporbiert, aber geht immer noch nicht. Also Reading wird erzeugt aber wert 0 oder 1 wird nicht angezeigt.
im Log sieht es so aus:
2019.12.20 17:46:33 3: MQTT2_LISAGW2: bad reading name 0:.* GPIO22_0 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:46:41 3: MQTT2_LISAGW2: bad reading name 1:.* GPIO22_1 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:46:46 3: MQTT2_LISAGW2: bad reading name 0:.* GPIO22_0 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:48:11 3: MQTT2_LISAGW2: bad reading name 0:.* GPIO22__0 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:48:21 3: MQTT2_LISAGW2: bad reading name 1:.* GPIO22__1 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:48:26 3: MQTT2_LISAGW2: bad reading name 0:.* GPIO22__0 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:49:46 3: MQTT2_LISAGW2: bad reading name 1:.* GPIO22__1 (contains not A-Za-z/\d_\.- or is too long)
2019.12.20 17:49:51 3: MQTT2_LISAGW2: bad reading name 0:.* GPIO22__0 (contains not A-Za-z/\d_\.- or is too long)
so habe das Problem gefunden :-)
Es lag daran, wie das gepublished wird vom Skript.
home/states/GPIO22 0 (null)
home/states/GPIO22 0
home/states/GPIO22 1
Die Zeile mit dem (NULL) frisst der Broker irgendwie nicht.
Den Publish string im Skript habe ich dann anderes "zusammen gebaut" so das er auch nach der Syntax passt. die wie folgt aussehen muss:
client.publish("house/light","ON")
Das ganze sieht dann so aus:
client.publish (("home/states/GPIO{}".format(GPIO)),("{}".format(level)))
Damit sollte dann eigentlich für jeden GPIO der nun seinen Status mal ändert ein neues Reading anglegt werden.
Dann wäre ich jetzt beim nächsten Schritt und zwar das Skript auf dem remote Raspi als service zu defineiren damit es auch immer schön läuft.
Gruß
Markus
so läuft nun auch als Service.Nun bin ich gespannt wie stabil das ganze läuft.
Nochmals Danke an Otto und Beta-User :-)
Gruß
Markus
Hallo Markus,
das freut mich. Den letzen gemeinsamen Part von Dir und Beta-User hab ich nur mitgelesen und muss den für mich mal noch verständlich machen / nacharbeiten :)
Schöne Weihnachten
Otto
Zitat von: Markus. am 21 Dezember 2019, 18:10:26
so läuft nun auch als Service.Nun bin ich gespannt wie stabil das ganze läuft.
Nochmals Danke an Otto und Beta-User :-)
Gruß
Markus
Danke für die Rückmeldung!
Falls der Betrieb dann als "stabil" bezeichnet werden kann, wäre es nett, wenn du das ganze nochmal "nachbautauglich" zusammenfassen könntest; dann bau' ich's gerne in die "Praxisbeispiele" ein bzw. verlinke auf die Darstellung.
Gruß, Beta-User
Hallo Beta-User,
ich muss das Skript noch ändern, damit es auch permanent läuft. Im Moment wird die Verbindung zum Broker nach der Keep-alive Zeit beendet und das Skript muss neu gestartet werden. Ich wollte das diese Woche noch machen, dann kann ich die Infos liefern.
Viele Grüße
Markus
Hi Markus.,
kein Ding, eilt ja nicht, und wer schnell war braucht, kann ja hier auch nachfragen...
Danke jedenfalls schon mal vorab!