TS: php 7 auf RasPi, file_put_contents mit FILE_APPEND, [edit]

Hello,

ich bin gerade sehr irritiert. Das kleine Skript schreibt Temperaturdaten in eine Datei.

<?php
    $text = file_get_contents('/sys/bus/w1/devices/28-011432fac57a/w1_slave');
    $_data = explode(' ', $text);
    $temp = substr(array_pop($_data), 2, 5);  ### alternativ "..., 2)"
    $out = date('Ymd h:i:s ') . $temp . PHP_EOL;
    echo $out;
    file_put_contents('/home/pi/Messungen/s1-temp.txt', $out, FILE_APPEND);

?>

Ich hatte zuerst vermutet, dass in der w1_slave bereits ein EOL stehen würde...

Leider wird in der Datei ein doppeltes 0x0A am Zeilenende eingefügt. Das lässt mich vermuten, dass file_put_contents() mit Flag FILE_APPEND bereits selbst ei 0x0A schreibt, also wieder den guten alten Textmodus benutzt. Das war mMn in PHP 6 nicht so.

Da aber auch LOCK_EX erwähnt wird in den Beispielen, wäre das unlogisch. Der gute alte Textmodus benötigte kein LOCK_EX, da das OS das bereits selbständig geregelt hat.

Ich habe leider im Moment nur das Tablet und den RasPi zum Testen.

##[edit]: ok, das EOL hing, wie vermutet, noch am $temp dran. Irgendwie hat der Raspi aber wohl das geänderte Skript (substr mit Längenangabe) nicht benutzt, sondern noch ein paarmal das alte (ohne Längenangabe beim substr).

Muss mal genauer untersuchen, wenn ich wiedef am PC sitze

Glück Auf
Tom vom Berg

--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.

akzeptierte Antworten

  1. Hello,

    mit welcher Granularität sollte man die Messungen für eine brauchbare Außentemperaturkurve durchführen?

    Ich habe jetzt "aller fünf Minuten" in die Crontab eingetragen. Aber das erscheint mir doch etwas zu oft, oder?

    Glück Auf
    Tom vom Berg

    --
    Es gibt nichts Gutes, außer man tut es!
    Das Leben selbst ist der Sinn.
    1. Hi,

      mit welcher Granularität sollte man die Messungen für eine brauchbare Außentemperaturkurve durchführen?

      Ich habe jetzt "aller fünf Minuten" in die Crontab eingetragen. Aber das erscheint mir doch etwas zu oft, oder?

      Kommt doch auf den Verwendungszweck der erfaßten Daten an.

      Bei z.B. Gewitter mit Hagel kann es in wenigen Minuten zu deutlichen Abkühlungen von mehreren Grad kommen.

      Wie schnell soll auf sowas reagiert werden können? Davon hängt es doch ab, wie oft die Meßwerte erfaßt werden müssen.

      cu,
      Andreas a/k/a MudGuard

      1. Hello,

        stimmt einerseits, andererseits sollte die Datenbasis universell nutzbar bleiben.
        Aber Jörg hat mich da schon auf den Weg gebracht.

        Glück Auf
        Tom vom Berg

        --
        Es gibt nichts Gutes, außer man tut es!
        Das Leben selbst ist der Sinn.
    2. mit welcher Granularität sollte man die Messungen für eine brauchbare Außentemperaturkurve durchführen?

      Kommt drauf an.

      Geheimtipp: Die Messungen müssen nicht mit der dauerhaften Speicherung übereinstimmen. So kann man sich z.B. eine wunderbar "feingranulierte" Kurve für die letzten 24 Stunden anzeigen lassen und irgend ein Cron-Dingens killt alles, was a) älter als 24 Stunden ist und b) keine Messung zu einer vollen Stunde.

      $out = date('Ymd h:i:s ') . $temp . PHP_EOL;
      

      Das gewählte Textformat ist hierfür freilich suboptimal. Nimm die Unix-Zeit in Sekunden und speichere das Zeug vielleicht auch besser mit sqlite3.

      1. Hello,

        mit welcher Granularität sollte man die Messungen für eine brauchbare Außentemperaturkurve durchführen?

        Kommt drauf an.

        Geheimtipp: Die Messungen müssen nicht mit der dauerhaften Speicherung übereinstimmen. So kann man sich z.B. eine wunderbar "feingranulierte" Kurve für die letzten 24 Stunden anzeigen lassen und irgend ein Cron-Dingens killt alles, was a) älter als 24 Stunden ist und b) keine Messung zu einer vollen Stunde.

        Das gewählte Textformat ist hierfür freilich suboptimal. Nimm die Unix-Zeit in Sekunden und speichere das Zeug vielleicht auch besser mit sqlite3.

        Stimmt beides. Gute Anregung.
        Ist bisher auch nur ein Schnellschuss mit dem Tablet. Da kann ich nur umständlich mit JuiceSSH arbeiten.

        Ich sollte also z. B. 24 Stunden mit einer hohen Granularität erfassen und dann die Steigung der Kurve als Grundlage dafür nehmen, ob der Einzelwert persistent bleibt, oder für die Langzeitspeicherung gelöscht werden kann. Also die zweite Ableitung als Maß für die Intervalllänge benutzen: je größer die Änderungsabweichung, desto kürzer das Intervall. Da gab's mal was von Fourier ☆tztz☆.

        Wenn da zwanzig mal hintereinander "190632" als Temperaturwert steht (1000stel K), ist das ja nicht spannend.

        Glück Auf
        Tom vom Berg

        --
        Es gibt nichts Gutes, außer man tut es!
        Das Leben selbst ist der Sinn.
    3. Tach!

      Zum Einen, das Zeilenendenproblem konnte ich nicht in meinem Test nachvollziehen. Ich würde aber erst ganz zuletzt davon ausgehen, dass das ein PHP-Fehler sein könnte.

      mit welcher Granularität sollte man die Messungen für eine brauchbare Außentemperaturkurve durchführen?

      Kommt auf den Anwendungsfall an. Wenn du das aktuelle Geschehen genauer sehen möchtest, muss es schon etwas häufiger sein. Vielleicht möchtest du aber Grafiken haben wie Munin sie erzeugt. Hier ein Beispiel für eine Apache-Zugriffsstatistik:

      Munin-Statistik von einem Apachen

      Dann könntest du gleich zu Munin greifen und dir ein Plugin für dein Thermometer schreiben. Munin sammelt alle 5 Minuten, fasst aber historische Daten so zusammen, dass das Datenvolumen stets gleich groß ist.

      dedlfix.

      1. Hello,

        danke für die Unterstützung.
        Dar EOL−Fehler kam durch die Eingangsdaten. Da hing noch ein EOL am Temperaturwert dran. Und die Änderung des Skriptes uaf substr($temp,2,5), also mit Länge für den Messwert, wurde ulkigerweise nicht gleich aktiv. Ich vermute, dass PHP7 hier einen cache hat?

        Glück Auf
        Tom vom Berg

        --
        Es gibt nichts Gutes, außer man tut es!
        Das Leben selbst ist der Sinn.
        1. Tach!

          Dar EOL−Fehler kam durch die Eingangsdaten. Da hing noch ein EOL am Temperaturwert dran. Und die Änderung des Skriptes uaf substr($temp,2,5),

          Ich würde ja trim() nehmen.

          dedlfix.

          1. Hello,

            Dar EOL−Fehler kam durch die Eingangsdaten. Da hing noch ein EOL am Temperaturwert dran. Und die Änderung des Skriptes uaf substr($temp,2,5),

            Ich würde ja trim() nehmen.

            Kam mir auch noch in den Sinn. Aber vorne muss ja sowieso das "t=" weggeschnitten werden.

            Ist, wie geschrieben, erstmal ein Schnellschuss. Ich werde das Datenformat gemäß Jörgs Hinweisen noch ändern. Das werde ich ggf. auch schon im Treiber tun können. Dann werden nur noch zwei Werte für Datumzeit und Temperatur geliefert, ohne chichi.

            Glück Auf
            Tom vom Berg

            --
            Es gibt nichts Gutes, außer man tut es!
            Das Leben selbst ist der Sinn.