Forum

...und noch:
vielleicht sollten die print Statements in meinem GIST auf englisch sein und die ganze Absicherung etc. gilt
natürlich auch für das aus- und wieder einschalten der Überwachungsanlage.
luemar.

Ja, vielleicht.

» Ja, vielleicht.
Ist die (versehentlich angefangene) Fortsetzung von https://www.elektronik-kompendium.de/forum/forum_entry.php?id=249133

Weiterführung von: https://www.elektronik-kompendium.de/forum/forum_entry.php?id=249914
Korrigierter GIST-Link: https://gist.github.com/luemar/de19d38429fd68f3f391a2102dd00f31

» vielleicht sollten die print Statements in meinem GIST auf englisch sein
» und die ganze Absicherung etc. gilt
» natürlich auch für das aus- und wieder einschalten der Überwachungsanlage.
» luemar.

Also ich finde nicht, dass die ganzen Texte bei GIST auf englisch sein müssen, die Kommentare hättest drin lassen können und ggf. sogar um deine eigenen Ergänzen. Dann findet sich ein deutschsprachiger Leser schneller im Code zurecht. Denk mal auf englisch gibts eh schon genügen Einsteiger-Literatur im Netz

Mir ist noch etwas bei der PIR_DELAY/MAX_COUNT-Logik aufgefallen :

if current_count > last_count and last_count < MAX_COUNT and time.time() > (last_time + PIR_DELAY):
last_count = current_count

Und zwar wenn der PIR alle zehn sekunden ein Signal sendet, PIR_DELAY ein vielfaches von zehn ist (sagen wir mal 30 Sekunden) dann ist das verhalten so:
1. Bewegung erkannt -> Versende Mail current_count = last_count = 1
2. Bewegung erkannt -> Igonriere da noch nicht lange genug gewartet current_count = 2, last_count = 1
3. Bewegung erkannt -> Igonriere da noch nicht lange genug gewartet current_count = 3, last_count = 1
4. Bewegung erkannt -> Igonriere da noch nicht lange genug gewartet current_count = 4, last_count = 1
5. Bewegung erkannt -> Versende E-Mail, setzte current_count = 5, last_count = 5 !

Sprich wenn PIR_DELAY zu lange ist, werden weniger Mails versendet bevor die Sleep-Phase erreicht wird. Das fällt natürlich nicht ins Gewicht, wenn der PIR von sich aus schon ein Delay verwendet das ähnlich groß dem PIR_DELAY ist. Ist mir nicht aufgefallen, weil mein PIR von sich aus 10 Sekunden delay hat und ich aus Ungeduld mit PIR_DELAY = 10 geteste habe

» Weiterführung von:
» https://www.elektronik-kompendium.de/forum/forum_entry.php?id=249914
» Korrigierter GIST-Link:
» https://gist.github.com/luemar/de19d38429fd68f3f391a2102dd00f31
»
» » vielleicht sollten die print Statements in meinem GIST auf englisch sein
» » und die ganze Absicherung etc. gilt
» » natürlich auch für das aus- und wieder einschalten der
» Überwachungsanlage.
» » luemar.
»
» Also ich finde nicht, dass die ganzen Texte bei GIST auf englisch sein
» müssen, die Kommentare hättest drin lassen können und ggf. sogar um deine
» eigenen Ergänzen. Dann findet sich ein deutschsprachiger Leser schneller im
» Code zurecht. Denk mal auf englisch gibts eh schon genügen
» Einsteiger-Literatur im Netz
»
» Mir ist noch etwas bei der PIR_DELAY/MAX_COUNT-Logik aufgefallen :
»
» if current_count > last_count and last_count < MAX_COUNT and time.time() >
» (last_time + PIR_DELAY):
» last_count = current_count
»
» Und zwar wenn der PIR alle zehn sekunden ein Signal sendet, PIR_DELAY ein
» vielfaches von zehn ist (sagen wir mal 30 Sekunden) dann ist das verhalten
» so:
» 1. Bewegung erkannt -> Versende Mail current_count = last_count = 1
» 2. Bewegung erkannt -> Igonriere da noch nicht lange genug gewartet
» current_count = 2, last_count = 1
» 3. Bewegung erkannt -> Igonriere da noch nicht lange genug gewartet
» current_count = 3, last_count = 1
» 4. Bewegung erkannt -> Igonriere da noch nicht lange genug gewartet
» current_count = 4, last_count = 1
» 5. Bewegung erkannt -> Versende E-Mail, setzte current_count = 5,
» last_count = 5 !
»
» Sprich wenn PIR_DELAY zu lange ist, werden weniger Mails versendet bevor
» die Sleep-Phase erreicht wird. Das fällt natürlich nicht ins Gewicht, wenn
» der PIR von sich aus schon ein Delay verwendet das ähnlich groß dem
» PIR_DELAY ist. Ist mir nicht aufgefallen, weil mein PIR von sich aus 10
» Sekunden delay hat und ich aus Ungeduld mit PIR_DELAY = 10 geteste habe

hallo bastelix
hatte meinen PIR mit einem Voltmeter getestet und fand keine Übereinstimmung
mit den Angaben des PIR Herstellers Adafruit auf der entsprechenden Website

https://learn.adafruit.com/pir-passive-infrared-proximity-motion-sensor/testing-a-pir:

Ich kann das die Zeit regelnde Potentiometer nur in einem kleinen Bereich,
vom Anschlag im gegenuhrzeigersinn (= ca. 2h) bis ca. 5h einstellen was mir
dann nach Bewegung eine Spannung von 3.3V für max. 8 bis min. 4 Sekunden gibt. Drehe ich
weiter im uhrzeigersinn gegen 6 h und mehr bekomme ich eine fast permanente Spannungsabgabe.
Diese Werte können mit der in obiger Website angegebenen Formel bzw. der RC Konstante nicht nachvollzogen werden.
Die gegenwärtige Stellung ergibt etwa 7 Sekunden Spannung, während dieser Zeit kann natürlich keine
neue Bewegung erkannt werden.

Ich muss allerdings einschränken, dass ich die PIR Messung mit einem PIR PI-ADA-189 gemacht habe während das
Script auf einem 2. Raspberry Pi B+ läuft, der in einem ModMyPi - Pi PIR Motion Sensor Camera Box Bundle eingebaut
ist, das einen etwas anders ausschauenden PIR enthält.

Ich habe auch das Script mit der Stoppuhr getestet und finde, dass nur die Zeit Einstellung am PIR
ausschlaggebend ist, währen ich durch PIR_DELAY_TIME von 3 bis 30 Sekunden keinen
Effekt fand, das Zeit Intervall zwischen einer Bewegung und dem print statement ('PIR2 wurde %s mal ausgeloest' % current_count)
bzw. dem Eintreffen des E-Mails mit Foto blieb immer bei 5 bis 6 Sekunden, wobei das E-Mail auf meinem
Mobile immer früher als in meinem PC eintraf.

Aber das Script erfüllt seinen Zweck.
luemar.

» bzw. dem Eintreffen des E-Mails mit Foto blieb immer bei 5 bis 6 Sekunden,
» wobei das E-Mail auf meinem
» Mobile immer früher als in meinem PC eintraf.
Vermutlich schaut dein Telefon öfter nach ob neue Mails da sind als der PC, die Mail kommt ja beim Mailserver an und wird von da durch die Mail-Clients abgeholt.

» Aber das Script erfüllt seinen Zweck.
Das ist die Hauptsache, dann passts

» » bzw. dem Eintreffen des E-Mails mit Foto blieb immer bei 5 bis 6
» Sekunden,
» » wobei das E-Mail auf meinem
» » Mobile immer früher als in meinem PC eintraf.
» Vermutlich schaut dein Telefon öfter nach ob neue Mails da sind als der PC,
» die Mail kommt ja beim Mailserver an und wird von da durch die Mail-Clients
» abgeholt.
»
» » Aber das Script erfüllt seinen Zweck.
» Das ist die Hauptsache, dann passts

Hallo bastelix, Experten,
habe meine Anlage nun im Langzeit Test bei mir zu Hause laufen gehabt und muss feststellen,
dass das Script zeitweise wie vorgegeben funktioniert und dann plötzlich gar nicht mehr reagiert.
Kann es sein, dass irgend ein Speicherabschnitt voll wird ?
Nach aus- und wieder einschalten geht's dann wieder.
Vielen Dank für Hilfe, luemar

» Hallo bastelix, Experten,
» habe meine Anlage nun im Langzeit Test bei mir zu Hause laufen gehabt und
» muss feststellen,
» dass das Script zeitweise wie vorgegeben funktioniert und dann plötzlich
» gar nicht mehr reagiert.
» Kann es sein, dass irgend ein Speicherabschnitt voll wird ?
» Nach aus- und wieder einschalten geht's dann wieder.
» Vielen Dank für Hilfe, luemar

Hi luemar,

ist das im gist: https://gist.github.com/luemar/de19d38429fd68f3f391a2102dd00f31 dein aktuelles Script? Mir ist da nämlich ein Syntaxfehler aufgefallen

Es kann sein dass im Script was überläuft, es kann aber auch irgendetwas anderes auf dem PI die Krätsche machen. Schreibst du die Script-Ausgaben in eine Log-Datei? Steht irgendetwas auffälliges in den Logs, auch syslog etc.?

Schau mal ob du da was findest, bzw. stell dein Script so um, dass die Debug-Ausgaben in eine Log-Datei geschrieben werden.

Ich kann grad nichts ausprobieren, da meine Bastel-Hardware schon verpackt in der neuen Wohnung steht. Nächste Woche steht dann endgültig der Umzug an - bis die ganzen Nachwehen vorbei sind wird es vermutlich noch bis Ende Juni dauern Falls du nicht weiter kommst kannst du mich gerne nochmal dran erinnern dass ich mir das genauer anschauen wollte - so ab Ende Juni hätte ich wieder mehr Luft.

Gruß
Bastelix

» » Hallo bastelix, Experten,
» » habe meine Anlage nun im Langzeit Test bei mir zu Hause laufen gehabt
» und
» » muss feststellen,
» » dass das Script zeitweise wie vorgegeben funktioniert und dann plötzlich
» » gar nicht mehr reagiert.
» » Kann es sein, dass irgend ein Speicherabschnitt voll wird ?
» » Nach aus- und wieder einschalten geht's dann wieder.
» » Vielen Dank für Hilfe, luemar
»
» Hi luemar,
»
» ist das im gist:
» https://gist.github.com/luemar/de19d38429fd68f3f391a2102dd00f31 dein
» aktuelles Script? Mir ist da nämlich ein Syntaxfehler aufgefallen
»
» Es kann sein dass im Script was überläuft, es kann aber auch irgendetwas
» anderes auf dem PI die Krätsche machen. Schreibst du die Script-Ausgaben in
» eine Log-Datei? Steht irgendetwas auffälliges in den Logs, auch syslog
» etc.?
»
» Schau mal ob du da was findest, bzw. stell dein Script so um, dass die
» Debug-Ausgaben in eine Log-Datei geschrieben werden.
»
» Ich kann grad nichts ausprobieren, da meine Bastel-Hardware schon verpackt
» in der neuen Wohnung steht. Nächste Woche steht dann endgültig der Umzug an
» - bis die ganzen Nachwehen vorbei sind wird es vermutlich noch bis Ende
» Juni dauern Falls du nicht weiter kommst kannst du mich gerne nochmal
» dran erinnern dass ich mir das genauer anschauen wollte - so ab Ende Juni
» hätte ich wieder mehr Luft.
»
» Gruß
» Bastelix

Hallo Bastelix,
auf Dich ist immer Verlass !!!

Gegenüber meinem Script auf https://gist.github.com/luemar/de19d38429fd68f3f391a2102dd00f31
hat das Script auf dem Raspberry Pi 2 folgende Abweichungen:
Zeile 16: PIR_IGNORE_TIME = 2700
Zeile 17: Hier steht DEBUG = True (ist das vielleicht der angesprochene Script Fehler ?)
Zeile 71: time.sleep (2)

Mit der Umleitung der Debug-Ausgaben in eine Log-Datei muss ich mich zuerst noch beschäftigen

Gruss und Dank, luemar.

Hi Luemar,

» auf Dich ist immer Verlass !!!
Sofern es meine Zeit zulässt tue ich mein Möglichstes.

» Gegenüber meinem Script auf
» https://gist.github.com/luemar/de19d38429fd68f3f391a2102dd00f31
» hat das Script auf dem Raspberry Pi 2 folgende Abweichungen:
» Zeile 16: PIR_IGNORE_TIME = 2700
» Zeile 17: Hier steht DEBUG = True (ist das vielleicht der angesprochene
» Script Fehler ?)
» Zeile 71: time.sleep (2)
Zeile 63: if last count >= MAX_COUNT:
Müsste meiner Meinung nach if last_count >= MAX_COUNT: (also last_count, mit unterstrich) heißen.

» Mit der Umleitung der Debug-Ausgaben in eine Log-Datei muss ich mich zuerst
» noch beschäftigen
Vermutlich startest du dein Programm über einen Eintrag in /etc/rc.local der in etwa so aussieht
python /pfad/zum/script.py &
oder einfach
/pfad/zum/script &

Wenn du das änderst in
python /pfad/zum/script.py > /var/log/pir.log 2>&1 &
müsste die Ausgabe vom Script in /var/log/pir.log landen (wichtig, Schreibrechte prüfen! Dein User für das PIR-Script muss in die Datei schreiben können, sonst funktioniert das nicht.)

Gruß
Bastelix

» Hi Luemar,
»
» » auf Dich ist immer Verlass !!!
» Sofern es meine Zeit zulässt tue ich mein Möglichstes.
»
» » Gegenüber meinem Script auf
» » https://gist.github.com/luemar/de19d38429fd68f3f391a2102dd00f31
» » hat das Script auf dem Raspberry Pi 2 folgende Abweichungen:
» » Zeile 16: PIR_IGNORE_TIME = 2700
» » Zeile 17: Hier steht DEBUG = True (ist das vielleicht der angesprochene
» » Script Fehler ?)
» » Zeile 71: time.sleep (2)
» Zeile 63: if last count >= MAX_COUNT:
» Müsste meiner Meinung nach if last_count >= MAX_COUNT: (also last_count,
» mit unterstrich) heißen.
»
» » Mit der Umleitung der Debug-Ausgaben in eine Log-Datei muss ich mich
» zuerst
» » noch beschäftigen
» Vermutlich startest du dein Programm über einen Eintrag in /etc/rc.local
» der in etwa so aussieht
» python /pfad/zum/script.py &
» oder einfach
» /pfad/zum/script &
»
» Wenn du das änderst in
» python /pfad/zum/script.py > /var/log/pir.log 2>&1 &
» müsste die Ausgabe vom Script in /var/log/pir.log landen (wichtig,
» Schreibrechte prüfen! Dein User für das PIR-Script muss in die Datei
» schreiben können, sonst funktioniert das nicht.)
»
» Gruß
» Bastelix

...vielen Dank.
Ja, der fehlende Unterstrich war nur ein Tipp Fehler oben.
Wenn ich das Script mit ./ ausführe funktioniert es wie gedacht.
Werde Deine Anweisung nun umsetzten.
Gruss, luemar..

» » Hi Luemar,
» »
» » » auf Dich ist immer Verlass !!!
» » Sofern es meine Zeit zulässt tue ich mein Möglichstes.
» »
» » » Gegenüber meinem Script auf
» » » https://gist.github.com/luemar/de19d38429fd68f3f391a2102dd00f31
» » » hat das Script auf dem Raspberry Pi 2 folgende Abweichungen:
» » » Zeile 16: PIR_IGNORE_TIME = 2700
» » » Zeile 17: Hier steht DEBUG = True (ist das vielleicht der
» angesprochene
» » » Script Fehler ?)
» » » Zeile 71: time.sleep (2)
» » Zeile 63: if last count >= MAX_COUNT:
» » Müsste meiner Meinung nach if last_count >= MAX_COUNT: (also
» last_count,
» » mit unterstrich) heißen.
» »
» » » Mit der Umleitung der Debug-Ausgaben in eine Log-Datei muss ich mich
» » zuerst
» » » noch beschäftigen
» » Vermutlich startest du dein Programm über einen Eintrag in /etc/rc.local
» » der in etwa so aussieht
» » python /pfad/zum/script.py &
» » oder einfach
» » /pfad/zum/script &
» »
» » Wenn du das änderst in
» » python /pfad/zum/script.py > /var/log/pir.log 2>&1 &
» » müsste die Ausgabe vom Script in /var/log/pir.log landen (wichtig,
» » Schreibrechte prüfen! Dein User für das PIR-Script muss in die Datei
» » schreiben können, sonst funktioniert das nicht.)
» »
» » Gruß
» » Bastelix
»
» ...vielen Dank.
» Ja, der fehlende Unterstrich war nur ein Tipp Fehler oben.
» Wenn ich das Script mit ./ ausführe funktioniert es wie gedacht.
» Werde Deine Anweisung nun umsetzten.
» Gruss, luemar..

Hallo Bastelix
habe das Script bzw. meine "Konstruktion" nun wieder über Tage getestet, und immer funktioniert es nach einr
gewissen Zeit (oder einer bestimmten Anzahl von PIR Aktivierungen ?) nicht mehr:

Trotz Abbrüche des Scripts finde ich keinen Eintrag in /var/log/log.pir. Die Schreib- bzw. Zugriffsrechte habe ich
mit chmod a+w meine ich richtig eingestellt.

Habe dann das Script zum Testen direkt mit ./PIR_V1.py gestartet, aber auch so nach einiger Zeit Funktionsabbrüche
registriert und jetzt startet das Script beim Einschalten des Raspberry - eingetragen wie oben in /etc/rc.local - gar nicht mehr,
während der Eintrag eine Zeile vorher, der mir ein Mail beim Einschalten zur Kontrolle schickt, funktioniert.
So kann natürlich auch nichts mehr in /var/log/pir.py eingetragen werden.

Bis vor kurzem habe ich den Raspberry über PuTTY bedient dann aber festgestellt, dass ich so die print Meldungen des Scripts
nicht über längere Zeit verfolgen kann, da ich die timeout Funktion von PuTTY nicht deaktivieren kann.

Bediene den Raspberry jetzt direkt mit Tastatur und separatem Monitor. Nach Start mit ./ ,nach rund 18h und 30m und dann
nach 2 PIR Aktivierungen folgende Fehlermeldung, wobei das Script die beiden male nicht mehr ausgeführt wurde bzw. keine Fotos mehr eintrafen:
Traceback (most recent calllast):
>File "./PIR_V1.py", line 59, in <module>
>>smtp = smtplib.SMTP(smtpHOST, smtpPort)
>File "/usr/lib/python3.4/smtplib.py", line 242, in __init__
>>(code, msg) = self.connect(host, port)
>File "/usr/lib/python3.4/smtplib.py", line 321 in connect
>>self.sock = self._get__socket(host, port, self.timeout)
>File "/usr/lib/python3.4/smtplib.py", line 292 in _get_socket
>>self.source_address)
>File "/usr/lib/python3.4/socket.py", line 491 in create_connection
>>for res in getaddrinfo(host, port, 0, SOCK_STREAM):
>File "/usr/lib/python3.4/socket.py", line 530 in getaddrinfo
>>for res in -socket.getaddrinfo(host, port, Family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known

Offenbar liegt das Problem bei der IN Verbindung, falls auch die früheren "Ausfälle"
darauf zurück zuführen waren, worüber z.Z: aber keine Angaben vorhanden sind.
In obiger Traceback Meldung finde ich die einzelne Klammer am Ende der 8. Zeile auffällig.

Zweifle an der Zuverlässigkeit von Raspberry Pi.

Gruss, luemar.

» » » Hi Luemar,
» » »
» » » » auf Dich ist immer Verlass !!!
» » » Sofern es meine Zeit zulässt tue ich mein Möglichstes.
» » »
» » » » Gegenüber meinem Script auf
» » » » https://gist.github.com/luemar/de19d38429fd68f3f391a2102dd00f31
» » » » hat das Script auf dem Raspberry Pi 2 folgende Abweichungen:
» » » » Zeile 16: PIR_IGNORE_TIME = 2700
» » » » Zeile 17: Hier steht DEBUG = True (ist das vielleicht der
» » angesprochene
» » » » Script Fehler ?)
» » » » Zeile 71: time.sleep (2)
» » » Zeile 63: if last count >= MAX_COUNT:
» » » Müsste meiner Meinung nach if last_count >= MAX_COUNT: (also
» » last_count,
» » » mit unterstrich) heißen.
» » »
» » » » Mit der Umleitung der Debug-Ausgaben in eine Log-Datei muss ich mich
» » » zuerst
» » » » noch beschäftigen
» » » Vermutlich startest du dein Programm über einen Eintrag in
» /etc/rc.local
» » » der in etwa so aussieht
» » » python /pfad/zum/script.py &
» » » oder einfach
» » » /pfad/zum/script &
» » »
» » » Wenn du das änderst in
» » » python /pfad/zum/script.py > /var/log/pir.log 2>&1 &
» » » müsste die Ausgabe vom Script in /var/log/pir.log landen (wichtig,
» » » Schreibrechte prüfen! Dein User für das PIR-Script muss in die Datei
» » » schreiben können, sonst funktioniert das nicht.)
» » »
» » » Gruß
» » » Bastelix
» »
» » ...vielen Dank.
» » Ja, der fehlende Unterstrich war nur ein Tipp Fehler oben.
» » Wenn ich das Script mit ./ ausführe funktioniert es wie gedacht.
» » Werde Deine Anweisung nun umsetzten.
» » Gruss, luemar..
»
» Hallo Bastelix
» habe das Script bzw. meine "Konstruktion" nun wieder über Tage getestet,
» und immer funktioniert es nach einr
» gewissen Zeit (oder einer bestimmten Anzahl von PIR Aktivierungen ?) nicht
» mehr:
»
» Trotz Abbrüche des Scripts finde ich keinen Eintrag in /var/log/log.pir.
» Die Schreib- bzw. Zugriffsrechte habe ich
» mit chmod a+w meine ich richtig eingestellt.
»
» Habe dann das Script zum Testen direkt mit ./PIR_V1.py gestartet, aber auch
» so nach einiger Zeit Funktionsabbrüche
» registriert und jetzt startet das Script beim Einschalten des Raspberry -
» eingetragen wie oben in /etc/rc.local - gar nicht mehr,
» während der Eintrag eine Zeile vorher, der mir ein Mail beim Einschalten
» zur Kontrolle schickt, funktioniert.
» So kann natürlich auch nichts mehr in /var/log/pir.py eingetragen werden.
»
» Bis vor kurzem habe ich den Raspberry über PuTTY bedient dann aber
» festgestellt, dass ich so die print Meldungen des Scripts
» nicht über längere Zeit verfolgen kann, da ich die timeout Funktion von
» PuTTY nicht deaktivieren kann.
»
» Bediene den Raspberry jetzt direkt mit Tastatur und separatem Monitor. Nach
» Start mit ./ ,nach rund 18h und 30m und dann
» nach 2 PIR Aktivierungen folgende Fehlermeldung, wobei das Script die
» beiden male nicht mehr ausgeführt wurde bzw. keine Fotos mehr eintrafen:
» Traceback (most recent calllast):
» >File "./PIR_V1.py", line 59, in <module>
» >>smtp = smtplib.SMTP(smtpHOST, smtpPort)
» >File "/usr/lib/python3.4/smtplib.py", line 242, in __init__
» >>(code, msg) = self.connect(host, port)
» >File "/usr/lib/python3.4/smtplib.py", line 321 in connect
» >>self.sock = self._get__socket(host, port, self.timeout)
» >File "/usr/lib/python3.4/smtplib.py", line 292 in _get_socket
» >>self.source_address)
» >File "/usr/lib/python3.4/socket.py", line 491 in create_connection
» >>for res in getaddrinfo(host, port, 0, SOCK_STREAM):
» >File "/usr/lib/python3.4/socket.py", line 530 in getaddrinfo
» >>for res in -socket.getaddrinfo(host, port, Family, type, proto, flags):
» socket.gaierror: [Errno -2] Name or service not known
»
» Offenbar liegt das Problem bei der IN Verbindung, falls auch die früheren
» "Ausfälle"
» darauf zurück zuführen waren, worüber z.Z: aber keine Angaben vorhanden
» sind.
» In obiger Traceback Meldung finde ich die einzelne Klammer am Ende der 8.
» Zeile auffällig.
»
» Zweifle an der Zuverlässigkeit von Raspberry Pi.
»
» Gruss, luemar.

..noch etwas, evtl. interessant für andere mit ähnlichen Projekten:
Es dauert eine gewisse Zeit vom Aktivieren der PIR bis dann im Script
ein Foto aufgenommen wird. In dieser Zeit kann sich das auslösende "Objekt"
aus dem Gesichtsfeld der PiCamera entfernen, so dass es nicht mehr sichtbar ist.
Dieses Problem kann mittels einer Weitwinkel Linse etwas eingegrenzt werden.

Hi Luemar,

der Stacktrace ist was womit man arbeiten kann Um das Thema loggen/Ausgabeumleitung können wir uns später kümmern (vermutlich nur ne Kleinigkeit, aber bis wir die Finden...).

» Nach Start mit ./ ,nach rund 18h und 30m und dann
» nach 2 PIR Aktivierungen folgende Fehlermeldung, wobei das Script die
» beiden male nicht mehr ausgeführt wurde bzw. keine Fotos mehr eintrafen:
» Traceback (most recent calllast):
» >File "./PIR_V1.py", line 59, in <module>
» >>smtp = smtplib.SMTP(smtpHOST, smtpPort)
» >File "/usr/lib/python3.4/smtplib.py", line 242, in __init__
» >>(code, msg) = self.connect(host, port)
» >File "/usr/lib/python3.4/smtplib.py", line 321 in connect
» >>self.sock = self._get__socket(host, port, self.timeout)
» >File "/usr/lib/python3.4/smtplib.py", line 292 in _get_socket
» >>self.source_address)
» >File "/usr/lib/python3.4/socket.py", line 491 in create_connection
» >>for res in getaddrinfo(host, port, 0, SOCK_STREAM):
» >File "/usr/lib/python3.4/socket.py", line 530 in getaddrinfo
» >>for res in -socket.getaddrinfo(host, port, Family, type, proto, flags):
» socket.gaierror: [Errno -2] Name or service not known

Der interessante Teil sind die beiden letzten Zeilen, da steckt vermutlich der Grund für das Verhalten.

>>for res in -socket.getaddrinfo(host, port, Family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known

Ohne jetzt irgendetwas über python Netzwerkprogrammierung zu kennen, sehe ich das so: Es wird versucht der Hostname vom SMTP-Server aufzulösen und das schlägt fehl was über eine Exception signalisiert wird. Ich glaub auf die fehlende Fehlerbehandlung hab ich schon mal hingewiesen, aber das ist normal für ne Alpha-Version

Es kann also der Hostname des SMPT-Servers nicht aufgelöst werden, folgende Gründe kann ich mir vorstellen

* Netzwerkverbindung getrennt
* Internetverbindung getrennt (Zwangstrennung vom Provider, Router abgestürzt/beim rebooten, ...)
* DNS-Server nicht erreichbar
* DNS-Server kennt den Hostname aufgrund einer Störung nicht

Ich halte die ersten beiden Punkte für die wahrscheinlichsten, mit DNS-Servern passiert auch gelegentlich was und im DNS geht auch mal was schief, aber das ist nicht reproduzierbar und passiert i.d.R. nicht alle 24 Stunden (oder so).

Wie gehst du jetzt damit am besten um?
Naja, Fehlerbehandlung einbauen!

Das einfachste wäre ein try-except-Block um deine Mail-Versand-Funktion (ab Zeile 59), dann wird einfach keine Mail verschickt wenn der Hostname des Mailservers nicht aufgelöst werden kann (oder sonstwas mit dem Netzwerk beim Mail-Versand schief geht) . Der Nachteil ist halt, dass die Mails dann verloren sind. Etwas aufwändiger wäre das mit einer lokalen Mail-Queue zu lösen - also entweder selber programmieren, oder einen lokalen SMTP-Server als Smart-Proxy aufzusetzen - ist aber etwas anspruchsvoller.

Du kannst mal den Artikel hier lesen https://www.networkcomputing.com/applications/python-network-programming-handling-socket-errors/1384050408 da geht es um die Fehlerbehandlung von Netzwerkverbindungen in Python, vielleicht hilft dir das um das ganze besser zu verstehen.

» Zweifle an der Zuverlässigkeit von Raspberry Pi.
Es liegt nur am PI, wenn das Netzwerk-Interface wegbricht - und selbst dann ist das noch kein Stabilitätsproblem solange das nur einmal alle paar Stunden passiert und das Netzwerkinterface von alleine wieder online kommt.

(IP)-Netzwerke sind einfach unzuverlässig, da hängen so viele Komponenten (Router, DNS-Server, andere Server, verschiedene Provider und Carrier, ....) drin, dass da immer irgendetwas grad nicht geht. Um so flexibler und komplexer das Gesamtsystem ist um so mehr Fehlerbehandlung bei Netzwerkfehlern braucht man. Netflix hat einiges zu dem Thema veröffentlicht: https://github.com/Netflix/Hystrix/wiki/How-it-Works Kannst mal überfliegen, wenn du das nicht verstehst ist das auch nicht schlimm, deren Infrastruktur ist ein bisschen mehr als ein PIR, ein PI und ein Mail-Server - aber das Grundproblem ist das gleiche: Irgendwas ist immer grad nicht erreichbar Damit haben wir auf Arbeit auch immer mal wieder zu tun - und seitdem immer mehr Dienste in die Cloud abwandern wird das noch schlimmer, das bekommt der normale User aber im Idealfall nicht mit weil die Fehlerbehandlung so gut ist, dass immer ein Fallback greift

Gruß
Bastelix

» Hi Luemar,
»
» der Stacktrace ist was womit man arbeiten kann Um das Thema
» loggen/Ausgabeumleitung können wir uns später kümmern (vermutlich nur ne
» Kleinigkeit, aber bis wir die Finden...).
»
» » Nach Start mit ./ ,nach rund 18h und 30m und dann
» » nach 2 PIR Aktivierungen folgende Fehlermeldung, wobei das Script die
» » beiden male nicht mehr ausgeführt wurde bzw. keine Fotos mehr eintrafen:
» » Traceback (most recent calllast):
» » >File "./PIR_V1.py", line 59, in <module>
» » >>smtp = smtplib.SMTP(smtpHOST, smtpPort)
» » >File "/usr/lib/python3.4/smtplib.py", line 242, in __init__
» » >>(code, msg) = self.connect(host, port)
» » >File "/usr/lib/python3.4/smtplib.py", line 321 in connect
» » >>self.sock = self._get__socket(host, port, self.timeout)
» » >File "/usr/lib/python3.4/smtplib.py", line 292 in _get_socket
» » >>self.source_address)
» » >File "/usr/lib/python3.4/socket.py", line 491 in create_connection
» » >>for res in getaddrinfo(host, port, 0, SOCK_STREAM):
» » >File "/usr/lib/python3.4/socket.py", line 530 in getaddrinfo
» » >>for res in -socket.getaddrinfo(host, port, Family, type, proto,
» flags):
» » socket.gaierror: [Errno -2] Name or service not known
»
» Der interessante Teil sind die beiden letzten Zeilen, da steckt vermutlich
» der Grund für das Verhalten.
»
» >>for res in -socket.getaddrinfo(host, port, Family, type, proto, flags):
» socket.gaierror: [Errno -2] Name or service not known
»
» Ohne jetzt irgendetwas über python Netzwerkprogrammierung zu kennen, sehe
» ich das so: Es wird versucht der Hostname vom SMTP-Server aufzulösen und
» das schlägt fehl was über eine Exception signalisiert wird. Ich glaub auf
» die fehlende Fehlerbehandlung hab ich schon mal hingewiesen, aber das ist
» normal für ne Alpha-Version
»
» Es kann also der Hostname des SMPT-Servers nicht aufgelöst werden, folgende
» Gründe kann ich mir vorstellen
»
» * Netzwerkverbindung getrennt
» * Internetverbindung getrennt (Zwangstrennung vom Provider, Router
» abgestürzt/beim rebooten, ...)
» * DNS-Server nicht erreichbar
» * DNS-Server kennt den Hostname aufgrund einer Störung nicht
»
» Ich halte die ersten beiden Punkte für die wahrscheinlichsten, mit
» DNS-Servern passiert auch gelegentlich was und im DNS geht auch mal was
» schief, aber das ist nicht reproduzierbar und passiert i.d.R. nicht alle 24
» Stunden (oder so).
»
» Wie gehst du jetzt damit am besten um?
» Naja, Fehlerbehandlung einbauen!
»
» Das einfachste wäre ein try-except-Block um deine Mail-Versand-Funktion (ab
» Zeile 59), dann wird einfach keine Mail verschickt wenn der Hostname des
» Mailservers nicht aufgelöst werden kann (oder sonstwas mit dem Netzwerk
» beim Mail-Versand schief geht) . Der Nachteil ist halt, dass die Mails dann
» verloren sind. Etwas aufwändiger wäre das mit einer lokalen Mail-Queue zu
» lösen - also entweder selber programmieren, oder einen lokalen SMTP-Server
» als Smart-Proxy aufzusetzen - ist aber etwas anspruchsvoller.
»
» Du kannst mal den Artikel hier lesen
» https://www.networkcomputing.com/applications/python-network-programming-handling-socket-errors/1384050408
» da geht es um die Fehlerbehandlung von Netzwerkverbindungen in Python,
» vielleicht hilft dir das um das ganze besser zu verstehen.
»
» » Zweifle an der Zuverlässigkeit von Raspberry Pi.
» Es liegt nur am PI, wenn das Netzwerk-Interface wegbricht - und selbst dann
» ist das noch kein Stabilitätsproblem solange das nur einmal alle paar
» Stunden passiert und das Netzwerkinterface von alleine wieder online kommt.
»
»
» (IP)-Netzwerke sind einfach unzuverlässig, da hängen so viele Komponenten
» (Router, DNS-Server, andere Server, verschiedene Provider und Carrier,
» ....) drin, dass da immer irgendetwas grad nicht geht. Um so flexibler und
» komplexer das Gesamtsystem ist um so mehr Fehlerbehandlung bei
» Netzwerkfehlern braucht man. Netflix hat einiges zu dem Thema
» veröffentlicht: https://github.com/Netflix/Hystrix/wiki/How-it-Works Kannst
» mal überfliegen, wenn du das nicht verstehst ist das auch nicht schlimm,
» deren Infrastruktur ist ein bisschen mehr als ein PIR, ein PI und ein
» Mail-Server - aber das Grundproblem ist das gleiche: Irgendwas ist immer
» grad nicht erreichbar Damit haben wir auf Arbeit auch immer mal wieder
» zu tun - und seitdem immer mehr Dienste in die Cloud abwandern wird das
» noch schlimmer, das bekommt der normale User aber im Idealfall nicht mit
» weil die Fehlerbehandlung so gut ist, dass immer ein Fallback greift
»
» Gruß
» Bastelix

Hallo Bastelix,
vielen Dank für die Infos, habe schon begonnen, mich damit auseinandersetzen.
Wenn ich das richtig mitbekommen habe, kann der Fehler jeweils mit try und except lokalisiert aber nicht behoben werden.

Habe die Weiterleitung des PIR_V1.py Scripts in /var/log/pir.log eliminiert und jetzt wird das Script beim Einschalten/rebooten wieder ausgeführt.

Bekomme obigen Traceback nun nach unterschiedlichen Zeiten in jeder neuen Script - Periode. Dabe fällt mir auf, dass vorher der Zaähler der IRQs plötzlich wieder bei 1 anfängt.

Nach dem letzten Traceback wurde ein reboot Prozess eingeleitet, allerdings mit folgender Fehlermeldung:
[FAILED] Failed to start /etc/rc.local Compatiblity
See 'systemct1 status rc-local.service' for Details.

Du hast whs. recht mit dem Rat, eine professionelle Überwachungsanlage zu kaufen. Ich fürchte, es wird mit PI nicht gehen.
Natürlich würde der PIR im vorgesehen Ort niemals so häufig ausgelöst wie bei meinem Test,
eigentlich hoffentlich gar nie.


Grüsse, luemar.

Hallo Luemar,

» Wenn ich das richtig mitbekommen habe, kann der Fehler jeweils mit try und
» except lokalisiert aber nicht behoben werden.
Genau, du kannst verhindern, dass dein Programm aufgrund des nicht behandelten Fehlers beendet wird aber den Grund für die Störung kannst du damit nicht beheben (das liegt ja Außerhalb deiner Kontrolle).

In diesem konkreten Fall muss man sich für die Fehlerbehandlung überlegen:
* darf die Mail verloren gehen -> try/expect und weiter als wäre nichts passiert (ggf. noch loggen)
* darf die Mail verzögert zugestellt werden -> Queue entweder selber implementieren oder einen lokalen Mail-Server als Smart-Proxy aufsetzen
* muss die Mail sicher zugestellt werden -> nicht grad auf Internet und E-Mail setzten, da sind Verzögerungen von bis zu 72 Stunden schon im Standard erlaubt und Manipulationen relativ einfach möglich

» Habe die Weiterleitung des PIR_V1.py Scripts in /var/log/pir.log eliminiert
» und jetzt wird das Script beim Einschalten/rebooten wieder ausgeführt.
Gut, dann hat da etwas mit der Umleitung der Ausgabe nicht gestimmt. Statt dem rc-local Eintrag könnte da eine eigene systemd-Konfiguration zum starten des Daemons helfen, falls du da noch Interesse dran hast.

» Bekomme obigen Traceback nun nach unterschiedlichen Zeiten in jeder neuen
» Script - Periode. Dabe fällt mir auf, dass vorher der Zaähler der IRQs
» plötzlich wieder bei 1 anfängt.
Ohne jetzt nachzuschauen, es könnte sein, dass der Mailversand in einem eigenen Thread abläuft (also asynchron) und es eher Zufall ist, dass der Counter grad wieder bei eins anfängt. Genaueres könnte man wohl nur mit Logging oder aktivem Debuggen herausfinden.

» Nach dem letzten Traceback wurde ein reboot Prozess eingeleitet, allerdings
» mit folgender Fehlermeldung:
» [FAILED] Failed to start /etc/rc.local Compatiblity
» See 'systemct1 status rc-local.service' for Details.
Sagt mir jetzt leider nichts. Kling danach als hätte systemd versucht rc-local auszuführen und dabei ist etwas schief gegangen. Wenn du systemctl status rc-loca.service auf der Konsole eingibst könnte da etwas aus dem Log von systemd kommen was weiterhilft. Allerdings musst du das zeitnah machen, sonst sind die Logs zu alt und du musst dich durch das Syslog wühlen bis du die Einträge findest.

» Du hast whs. recht mit dem Rat, eine professionelle Überwachungsanlage zu
» kaufen. Ich fürchte, es wird mit PI nicht gehen.
Naja ich hab ja gesagt, wenn die eine Anlage bauen willst weil du eine Bauen möchtest helfe ich dir gerne. Wenn du eine Anlage bauen willst weil du eine brauchst solltest du eine professionelle Lösung kaufen. Aber wir haben beide einiges gelernt. Ich z.B. Python, zwar nicht so gut wie andere Programmiersprachen die ich kann aber viel mehr als ich je geplant hatte und auch ein bisschen was über PIRs - damit werde ich im Herbst eine Steuerung für die Beleuchtung unseres neuen Kleiderschranks bauen (der Hersteller der die besseren Schränke baut, hatte leider nur Fußschalter mit viel zu kurzen Kabeln - hat der Händler aber nicht gesagt... *grml*). Du hast auch einiges über Python und Linux gelernt und hoffentlich hat dir das Basteln auch Spaß gemacht .

» Natürlich würde der PIR im vorgesehen Ort niemals so häufig ausgelöst wie
» bei meinem Test, eigentlich hoffentlich gar nie.
Naja, das Problem ist halt nicht wie oft der PIR auslöst, sondern dass ab und zu das Netzwerk nicht verfügbar ist und dann das Programm stirbt (zumindest im Moment noch). Falls du doch mal nach ner professionellen Lösung schauen möchtest, ein Freund von mir arbeitet bei einer Firma die Alarmanlagen einbaut (mit dem hab ich neulich sogar über das Projekt gesprochen ) wenn du willst kann ich den mal Fragen ob ich dir die Kontaktdaten zukommen lassen darf (ich weiß aber nicht ob seine Firma auch in der Schweiz aktiv ist, aber vielleicht kennt er da jemanden) - dann schreib mir aber bitte über die PN-Funktion vom Forum, Kontaktdaten stelle ich nicht frei zugänglich ins Internet.

So, ich klettere jetzt über ein paar unausgepackte Umzugskartons ins Bett

Gruß
Bastelix