Search Results

Versuch's doch mal so Source Code (13 lines)

Das könntest du leicht rausbekommen, in dem du das script zu Testzwecken leicht veränderst und es dann laufen läßt. Source Code (13 lines)Jetzt ruft dein Script nur noch ls auf. Wenn jetzt der Sheduler stabil läuft, lag's wohl daran.

ich wüsste jetzt erst mal nicht, welchen Einfluss das script auf den Sheduler haben sollte. Ich wird mal versuchen, das auf meinem Raspi nachzustellen, ob bei mir dann der Sheduler auch aussteigt.

So, ich musste mir erst mal Pilight installieren. Das läuft bei mir nur auf den Slaves, dort läuft aber logischerweise kein Sheduler. Wie lange dauert es denn, bis bei dir der Sheduler in die Wiese geht? Und vor allem, wann tut er das? (evtl. mal mit htop beobachten) Also bei mir läuft das Script ohne Beeinflussung vom Sheduler. Allerdings habe ich a) keinen 433MHz-Empfänger angeschlossen, empfange somit nicht per pilight-receive und zum anderen kann ich das script ja einfach nur laufen lassen, …

Hm...wie erkennst du ob der Sheduler aussteigt? Ist der Prozess nicht mehr vorhanden bzw. beendet? Wenn er beendet ist, würde er ja nicht von selbst wieder starten. Mit sheduler-einstellungen meine ich folgendes: Brainfuck Source Code (10 lines)das Performance-Profile

Starte doch mal den pilight-receive in einer Konsole so, lass ihn mal laufen und schau mal, ob im SHC-Webinterface der Sheduler auch wieder als "läuft nicht" angezeigt wird.

Wie startest du denn die tuer.sh aus dem SHC? Vielleicht habe ich deinen Ablauf auch noch nicht ganz verinnerlicht. Ich bin davon ausgegangen, dass die tuer.sh eigentlich immer im Hintergrund laufen soll, um eben die Ereignisse deine 433 MHz-Türkontakts zu empfangen, und du löst dann die pushbullet. sh mit dem Parameter "Tuer offen" aus. Was steht denn in der pushbullet? Mir fehlt hier der Zusammenhang mit dem SHC. In welchen Zeitabständen erhältst du denn von dem Türkontakt über pilight-receive…

Mir fehlt da immer noch der Zusammenhang mit dem Sheduler. Wenn du die alarmon.txt per Hand erstellst und das script tuer.sh auch per Hand startest, was passiert dann im SHC? Der gleiche Fehler?

Nein, ich meinte jetzt nicht, dass du pilight-receive in der Konsole staten sollst, sondern einfach mal alles, was das SHC dan automatisch machen soll per Hand nachstellen. Also alarmon.txt per Hand erstellen und dann tuer.sh von Hand starten. Von pilight hatte ich grad nichts geschrieben. ich würde sagen der Sheduler macht alles, was in irgendeiner Form zeitgesteuert abläuft. Also auslesen der Eingänge, der DS18x20, usw. Wenn du aber deine Alarmanlage scharf schaltet, stösst du ja die Vorgänge …

Quote from galaxia99: “die tuer.sh wird als Ereignis gestartet, wenn alarmon.txt vorhanden ist. Also überwacht ein Ereignis "Datei vorhanden". Und alarmon.txt erstelle ich über eine Schaltfunktion. ” Weil das steht "Und alarmon.txt erstelle ich über eine Schaltfunktion." war ich davon ausgegangen. Also ich würde das ja so machen, dass ich beim Scharfschalten über SHC nur das Script tuer.sh starten würde. In dem Script würd ich ganz zu Anfang die alarmon.txt erstellen lassen (warum das vom SHC ma…

oder einfach: Source Code (15 lines)und dann einfach nur das script tuer.sh starten

Quote from rmjspa: “Wie ist dieses Intervall und wie oft kommt der Code? ” Die Frage hatte ich auch schon gestellt. Deswegen wollte ich ja, dass er mal das ganze von Hand auslöst.

Warum erzeugst du die alarmon.txt nicht in der tuer.sh? Ohne die vorab zu erzeugen macht es doch eh keinen Sinn. Warum so umständlich?

Quote from DieterWo: “oder einfach: Source Code (15 lines)und dann einfach nur das script tuer.sh starten ”

Wieso sollte das Script nicht mehr beendet werden? die alarmon.txt wird doch außerhalb der while-schleife erzeugt, und die While-Schleife wird verlassen, wenn die alarmon.txt nicht mehr existiert. ich hab das grad mal ausprobiert. statt "timeout 60s sudo ..." müsstest du mal "sudo timeout 60s ..." schreiben. mach dem erstellen der alarmon.txt habe ich noch eine pause von 2 sek eingebaut, damit die Datei auch sicher existiert. Hier mal die Datei: Shell-Script (16 lines)Also bei mir funktioniert d…

Das werde ich mal ausprobieren.

Okay, das liegt daran, dass dein Script und auch die verwendeten Pfade auf /home/pi zugreifen wollen. Ein Verzeichnis, worauf der user www-data keinen Zugriff hat. SHC startet die script unter dem Benutzer www-data. Wenn du z.B. das script nach /var/www/shc kopierst, und deine Pfade innerhalb des scripts entsprechen anpasst, läuft das auch und kann auch über das SHC gestartet werden.

Wird denn die Datei pilight_00.txt erzeugt? Vielleicht findet er ja pilight-receive nicht. Ich würde die Datei vor jedem Aufruf von pilight-receive löschen, und vor dem egrep-if noch ein if exist der Datei einfügen und das ggf. noch in einem Logfile loggen, um das während der Ausführung zu überwachen und dem Fehler auf die Spur zu kommen.

das logging kannst du erreichen, in dem du dir innerhalb den Ablaufs Daten per Echo in eine Datei schreibst. So kannst du z.b. Variablenwerte mitschreiben. Aber auch per if exists ob eine Datei existiert, oder ein Echo, ob das Script überhaupt einen Block durchläuft. So kannst du danach in der Datei den Ablauf nachvollziehen. So kannst du den Fehler mit Sicherheit eingrenzen und ermitteln.