Event-Logs auf meiner Webseite

Mir ist es wichtig, bestimmte Events langfristig über viele Tage und Wochen als separate Event-Logs auf meiner Webseite zu protokollieren. Diese Event-Logs entstehen beim Ablauf von Scenes auf VERA. Ein Event-Log auf meiner Webseite zeigt beispielsweise die stündliche Entwicklung von Temperatur und Feuchte eines bestimmten Raumes. Ein anderes Log listet z.B. für einen bestimmten Gebäudebereich die Events DoorOpen, DoorClose oder Motion.
Ich möchte eine Vielzahl solcher spezieller Event-Logs auf meiner Webseite. Sie sollen übersichtlich und sehr lange verfügbar sind. Auf meiner Webseite sollen sie deshalb liegen, damit sie einfach und von überall abfragbar sind.
In solche Logs sammle ich auch Zustandswerte zum Austesten von Devices, von scenes oder von scene Prozesseketten. Das hat sich im Tagesbetrieb, bei Fehlersuche und zur Optimierung vielfach bewährt.

Ein Lösungsweg wäre, die Nachrichten in die VERA Logdatei zu schreiben. Die Logdatei muss dann natürlich auf einem entsprechend großen USB-Speichermedium liegen und darf bei VERA Restarts nicht überschrieben werden. Sodann muss man die relevanten Nachrichten aus dem umfangreichen Log-Pool selektieren und geeignet darstellen. Das alles ist möglich, aber nicht so einfach bzw. komfortabel. Und es gibt Nachteile bezüglich der Performance und des automatischen Backups.

Die hier dargestellte Alternative: Man schreibt für jeden Log-Typ eine separate Event-Logs auf meiner Webseite fort (auf meinem Webserver). Diese vielseitigen Logs lassen sich per Browser von überall komfortabel aufrufen. (Bei Bedarf kann man den Zugriff per Passwort schützen.)
Dazu benötigt man lediglich eine LUA Funktion aLog und ein PHP-Skript auf dem Webserver. Diese Funktion wird bei mir von allen möglichen Scenes aufgerufen und schreibt einige 100 Zeilen täglich. Ich habe bisher keine Performance Probleme festgestellt.

Funktion aLog mit Hilfsfunktion mySplit 


function mySplit(inStr,sep)
 local t={}; i=1
 for str in string.gmatch(inStr,"([^"..sep.."]+)") do
  t[i] = str
  i = i + 1
 end
 return t
end

function aLog(arg)
 local sArg=mySplit(arg,"!")
 local logFile=sArg[1]
 local scnNr=sArg[2]
 local aStr=sArg[3]
 local aaStr=string.gsub(aStr, " ", "+")
 luup.inet.wget ("DomainnamePath/vera.php?tgt=" .. logFile .. "&scn=" .. scnNr .. "&aStr=" .. aaStr,3)
end

aLog und mySplit müssen als globale Funktionen definiert werden. Also am einfachsten in die StartupLua eintragen. Die Funktion aLog benötigt 3 Argumente: logFile, scnNr und aStr. Diese Felder werden mit dem Trennzeichen “!” in einem gemeinsamen String übergeben.
Die Hilfsfunktion myStr wandelt den übergebene Argumente-String in ein Array um. Die Funktion aLog bildet daraus die 3 lokalen Variablen und ersetzt Leerzeichen durch +. Dann wird der CGI-String gebildet, mit dem dann vera.php auf der Webseite aufgerufen wird.
Einschränkungen aufgrund dieser CGI-Datenübergabe: Im Text funktionieren die Zeichen !+#*” nicht. Umlaute und andere Sonderzeichen können vielleicht (abhängig vom Webserver) korrekt übertragen werden. Deshalb muss man auf diese Zeichen verzichten bzw. zunächst deren Verträglichkeit austesten.

PHP-Skript

Auf dem gewünschten Pfad des Webservers wird die Skriptdatei vera.php angelegt und zwar mit nachfolgendem Inhalt. Das Skript benötigt Schreibberechtigung für den Benutzer (CHMOD 700).


<?php
$logLine=array();
if (!empty($_GET['tgt'])) {$ZielLog=$_GET['tgt'];} else {$ZielLog="no_ZielLog";}
$ZielLog="./log/" . $ZielLog . ".log";
if (!empty($_GET['scn'])) {$scn=$_GET['scn'];} else {$scn="no_scn";};
if (!empty($_GET['aStr'])) {$aStr=$_GET['aStr'];} else {$aStr="no_aStr";};

$logLine[]=date("Y-m-d H:i:s") . " " . $scn . " " . $aStr;

// #  #  #  #  ausgabe ZielLog File  #  #  #  #
$logLine=implode("\n",$logLine) . "\n";
$tL = fopen ($ZielLog, "a+t");  
fwrite($tL, $logLine); 
fclose($tL); 
/*

Das Skript liest die übergebenen CGI-Daten (Zieldatei, Scene-Nr, Text) und schreibt eine Logzeile in die Zieldatei. Die Zieldatei liegt im Unterverzeichnis /log.

Beispiel:
Vom Aufruf von aLog bis zur Anzeige des Logfiles

Die Funktion aLog ruft man in VERA beispielsweise wie folgt auf:
luup.call_delay(‘aLog’,0,”beispielFile!123!Irgendetwas”)
Die Funktion startet auf dem Webserver das Skript vera.php auf. Diesem Skript werden per CGI-String die relevanten Werte übergeben. Mit diesem Aufruf schreibt vera.php eine Logzeile in beispielFile.log.  Neben den Daten wird auch ein Timestamp protokolliert. Nachfolgend der Ablauf im Detail:

Bei Bedarf können Variablenwerte in die Nachricht integriert werden, z.B.:
local v1="4711a"
local aStr="Irgendetwas plus v1: " .. v1

Aufruf von aLog() in VERA:
luup.call_delay('aLog',0,"beispielFile!123!" .. aStr)

Die Funktion aLog() startet nach 0 sek und ruft auf dem Webserver das Skript vera.php auf. Diesem Skript werden per CGI-String folgende Werte übergeben:
 Die Zieldatei (beispielFile), 
 Die Scene-Nr (123),
 Text (Irgendetwas plus v1: 4711a)
Die URL sieht wie folgt aus:
http://DomainnamePath/vera.php?tgt=beispielFile&123&Irgendetwas+plus+v1:+4711a

vera.php schreibt im Unterverzeichnis /log eine Logzeile mit folgendem Inhalt in beispielFile.log:
2019-01-14 16:15:59 123 Irgendetwas plus Wert von v1: 4711a

Die Logdatei kann vom Webserver aufgerufen werden mit der URL:
http://DomainnamePath/log/beispielFile.log

Dieser Beitrag gehört zur Themengruppe
Smarthouse Programmierung

VERA erlaubt individuelle SMART HOUSE Programmierung mit LUA und LUUP. Dabei ist LUUP die Kommandosprache von VERA. LUUP Kommandos können nicht nur aus LUA heraus ausgeführt werden. Der Aufruf von LUUP ist auch von außen über CGI (http-GET) möglich. Dieser Weg ermöglicht vielfältige Zugriffe auf VERA aus Drittsystemen. Bei der LUA Programmierung für SMART HOUSE sind einige Apps und Werkzeuge hilfreich. Zusätzlich ist Entwicklungsdisziplin gefordert. Ein SMART HOUSE Controller wie VERA ist nämlich ein limitiertes Kleinsystem. Deshalb ist eine performante Strukturierung des LUA Programm Codes besonders wichtig. Dabei sollten die Schreib-Aktionen minimiert werden. Es empfiehlt sich, Datenfehler sorgfältig abzufangen. Denn ein nachträgliches Debugging ist bei VERA nicht einfach. Versteckte Programmfehler können viel Ärger machen. Also am besten jede einzelne Programmentwicklung oder -änderung gut austesten, bevor man weitergeht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert