Hallo,
ich habe mich in diesem Forum angemeldet, weil mein Problem offenbar mit Linux zu tun hat und deshalb in dem Forum, in dem ich sonst zu Hause bin (https://www.symcon.de/forum/) nicht gelöst werden kann.
Ich habe auf Raspis eine Anwesenheitserkennung mit Bluetooth-Dongels (BLE = Bluetooth low energy) in Betrieb (erscheint z.B. das Signal des Dongels nach Abwesenheit wieder, werden bestimmte Aktionen ausgeführt, z.B.: Garagentor auf, Licht ein usw.).
Das Pgr, das die empfangenen Bluetooth-Signale auswertet, liefert ca. 0 bis 4 Datensätze pro Sekunde, Ausgabe an stdout; dieser Kanal wird auf eine Datei umgeleitet und das Pgr. nach ca. 3 bis 4 Sekunden abgebrochen:
Anschließend wird die Datei in PHP ausgelesen und dem Inhalt entsprechend die oben beschriebenen Aktionen ausgelöst. Das ganz funktioniert sehr gut und zuverlässig, hat aber den Nachtel, dass es bis zu 4 Sekunden dauern kann, bis ein Signal erkannt wird.
Es ist halt blöd, mit dem Auto vor der Garage zu stehen und den Verkehr zu blockieren, weil es da zu einer Erkennungsverzögerung kommt.
Deshalb kam der Gedanke auf, von diesem "Stottermodus" in einem "Parallelmodus" überzugehen:
Das Empfangs-Programm wird durch eine Instanz gestartet und parallel dazu wertet eine andere Instanz (benutzt wird PHP) schritthaltend die Signale aus.
Ich habe zuerst versucht, die Datei zu lesen (und bin gescheitert, der Inhalt steht erst irgendwann zur Vfg.)
Auch an die Bildschirmausgabe, die angeblich im proc filesystem (/proc/<pid>/fd/1) erreichbar sein soll, bin ich nicht rangekommen.
Dann die Überlegung, dass eine "Named Pipe (fifo)" eigentlich das richtige für diesen Zweck ist:
Ich habe auch zur Kenntnis genommen, dass es zu Blockaden kommen kann (Auszug aus Linux Programmer's Manual, pipe - overview of pipes and FIFOs :
Der BLE-Empfänger schreibt zwar offenbar kontinuierlich seine Daten in die Pipe
aber das Auswertprogramm kann sie nicht entnehmen.
Erst wenn der BLE-Empfänger beendet wird, kommen alle Daten in einem Zug beim Auswertprogramm an und das war ja nicht der Sinn der Übung, denn diese Methode dauert ja noch länger als der "Stottermodus".
Daher mein Betreff, dass die pipe zeitweise verstopft ist.
Kann mir jemand hier aus dem Forum mit einer fertigen Lösung helfen oder mal nachsehen, welchen Fehler ich mache?
Folgendes habe ich bereits realisiert:
Damit wird in der 1. Instanz die Pipe erstellt und der BLE-Empfänger gestartet.
Gestoppt wird der durch folgendes Skript:
Hier das Skelett meines PHP-Skriptes, das die Daten auswerten soll (System-spezifische Befehle habe ich meist weggelassen):
Das Stop-Skript starte ich bei dieser Test-Version separat vor Ablauf der Warte-Zeit von 50 sek.
Für Rückfragen und weiter Erläuterungen stehe ich gerne zur Verfügung.
Es wäre schön, wenn mir jemand helfen könnte.
Viele Grüsse
Harald
ich habe mich in diesem Forum angemeldet, weil mein Problem offenbar mit Linux zu tun hat und deshalb in dem Forum, in dem ich sonst zu Hause bin (https://www.symcon.de/forum/) nicht gelöst werden kann.
Ich habe auf Raspis eine Anwesenheitserkennung mit Bluetooth-Dongels (BLE = Bluetooth low energy) in Betrieb (erscheint z.B. das Signal des Dongels nach Abwesenheit wieder, werden bestimmte Aktionen ausgeführt, z.B.: Garagentor auf, Licht ein usw.).
Das Pgr, das die empfangenen Bluetooth-Signale auswertet, liefert ca. 0 bis 4 Datensätze pro Sekunde, Ausgabe an stdout; dieser Kanal wird auf eine Datei umgeleitet und das Pgr. nach ca. 3 bis 4 Sekunden abgebrochen:
Code:
#!/bin/bash
# BLEscan.sh
sudo hcitool lescan > /tmp/Lescan.txt & sleep 3;
pkill --signal SIGINT hcitool;
sleep 1;
Anschließend wird die Datei in PHP ausgelesen und dem Inhalt entsprechend die oben beschriebenen Aktionen ausgelöst. Das ganz funktioniert sehr gut und zuverlässig, hat aber den Nachtel, dass es bis zu 4 Sekunden dauern kann, bis ein Signal erkannt wird.
Es ist halt blöd, mit dem Auto vor der Garage zu stehen und den Verkehr zu blockieren, weil es da zu einer Erkennungsverzögerung kommt.
Deshalb kam der Gedanke auf, von diesem "Stottermodus" in einem "Parallelmodus" überzugehen:
Das Empfangs-Programm wird durch eine Instanz gestartet und parallel dazu wertet eine andere Instanz (benutzt wird PHP) schritthaltend die Signale aus.
Ich habe zuerst versucht, die Datei zu lesen (und bin gescheitert, der Inhalt steht erst irgendwann zur Vfg.)
Auch an die Bildschirmausgabe, die angeblich im proc filesystem (/proc/<pid>/fd/1) erreichbar sein soll, bin ich nicht rangekommen.
Dann die Überlegung, dass eine "Named Pipe (fifo)" eigentlich das richtige für diesen Zweck ist:
A very useful Linux feature is named pipes which enable different processes to communicate.
The output of the command run on the first console shows up on the second console. Note that the order in which you run the commands doesn't matter.
Ich habe auch zur Kenntnis genommen, dass es zu Blockaden kommen kann (Auszug aus Linux Programmer's Manual, pipe - overview of pipes and FIFOs :
Mein Problem ist jetzt folgendes:I/O on pipes and FIFOs
The only difference between pipes and FIFOs is the manner in which
they are created and opened. Once these tasks have been
accomplished, I/O on pipes and FIFOs has exactly the same semantics.
If a process attempts to read from an empty pipe, then read(2) will
block until data is available. If a process attempts to write to a
full pipe (see below), then write(2) blocks until sufficient data has
been read from the pipe to allow the write to complete. Nonblocking
I/O is possible by using the fcntl(2) F_SETFL operation to enable the
O_NONBLOCK open file status flag.
The communication channel provided by a pipe is a byte stream: there
is no concept of message boundaries.
If all file descriptors referring to the write end of a pipe have
been closed, then an attempt to read(2) from the pipe will see end-
of-file (read(2) will return 0). If all file descriptors referring
to the read end of a pipe have been closed, then a write(2) will
cause a SIGPIPE signal to be generated for the calling process. If
the calling process is ignoring this signal, then write(2) fails with
the error EPIPE. An application that uses pipe(2) and fork(2) should
use suitable close(2) calls to close unnecessary duplicate file
descriptors; this ensures that end-of-file and SIGPIPE/EPIPE are
delivered when appropriate.
Der BLE-Empfänger schreibt zwar offenbar kontinuierlich seine Daten in die Pipe
aber das Auswertprogramm kann sie nicht entnehmen.
Erst wenn der BLE-Empfänger beendet wird, kommen alle Daten in einem Zug beim Auswertprogramm an und das war ja nicht der Sinn der Übung, denn diese Methode dauert ja noch länger als der "Stottermodus".
Daher mein Betreff, dass die pipe zeitweise verstopft ist.
Kann mir jemand hier aus dem Forum mit einer fertigen Lösung helfen oder mal nachsehen, welchen Fehler ich mache?
Folgendes habe ich bereits realisiert:
Code:
#!/bin/bash
# BLEscan2.sh
cd /tmp;
sudo mkfifo /tmp/LePipe;
sudo hcitool lescan > /tmp/LePipe;
Damit wird in der 1. Instanz die Pipe erstellt und der BLE-Empfänger gestartet.
Gestoppt wird der durch folgendes Skript:
Code:
#!/bin/bash
# BLEstop.sh
sudo pkill --signal SIGINT hcitool;
sleep 1;
sudo rm /tmp/LePipe;
Hier das Skelett meines PHP-Skriptes, das die Daten auswerten soll (System-spezifische Befehle habe ich meist weggelassen):
Code:
$DatenDir = '/tmp/';
$LogFile = $DatenDir . 'Lescan.txt'; // wie in BLEscan2.sh
$StartTime = time ();
IPS_RunScript (GetObjectIDByIdentPath ('BLEscan/ACT2')); // Starte schon mal BLEscan2.sh
IPS_Sleep (1000); // Wartezeit in Millisekunden ohne Abfrage als Vorsprung
$handle = fopen ($DatenDir . 'LePipe', 'r'); // ensures at least one writer (us) so will be non-blocking
// stream_set_blocking($handle, false); // prevent fread / fwrite blocking (ist ohne Bedeutung)
do {
$line = trim (fgets ($handle, 64)); // Liest eine Zeile von der Position des Dateizeigers
// das folgende hab ich auch schon ausprobiert:
// $line = trim (fread ($handle,64)); // liest eine Zeile von $handle
// $line = trim (stream_get_line ($handle,64));
if ($line){
// var_dump( $line);
print( (time ()) . " '" . $line . "'\n");
}
} while ((time () - $StartTime ) < 50); // Wartezeit in Sekunden
Für Rückfragen und weiter Erläuterungen stehe ich gerne zur Verfügung.
Es wäre schön, wenn mir jemand helfen könnte.
Viele Grüsse
Harald