Hallo zusammen,
ich habe ein paar Verständnisfragen zur Archivkontrolle:
Wenn ich eine Variable im Objektbaum lösche, weist das Archiv trotzdem noch einen Eintrag „12345 Objekt #12345 existiert nicht“ auf. Ich hätte eigentlich erwartet, dass der Eintrag dann auch im Archiv verschwindet. Oder ist dies Absicht, damit geloggte Daten dieser ehemaligen Variablen weiterhin verfügbar sind?
Da im Archiv scheinbar für alle Variablen Einträge erzeugt werden (auch wenn diese nicht geloggt werden sollen), kann das ganze m.M. ziemlich unübersichtlich werden. Außerdem kann man Einträge wohl nur einzeln löschen (?)
Als Limitierung für die Beta ist ja angegeben: „Archiv loggt nur Rohdaten (Keine Aggregation, entsprechend auch nur Stundengraphen/Tagesgraphen in HD verfügbar)“
Ich logge momentan die Daten meines Stromzähöers im Abstand von 2 Sekunden. Im Webfront werden die Stundengraphen auch richtig dargestellt, bei den Tagesgraphen sind nur die ersten 5 bis 6 Stunden des Tages dargestellt (entsprechend ca. 10000 Messwerte). Gibt es hier ein Limit ‚10000‘ oder hängt das mit der fehlenden Aggregation zusammen?
>> Niemals! Nein! Nene! Es werden nur die Variablen dort aufgelistet, welche entweder den Haken beim Logging drinne haben, oder den Haken mal drinne hatten! Ansonsten hätte ich ernsthafte Probleme g
>>>> Zumindest ist das unter Windows so, damit vmtl/hoffentlich auch bei Linux
>> Löscht man eine Variable, bleibt diese im Archiv erhalten und muss dort extra gelöscht werden. Der eine findet es gut, weil er seine geloggten Daten nachträglich noch in eine andere Variable überführen kann, der andere schlecht, weil er es nicht braucht und es ihm alles vermüllt…
Ich logge momentan die Daten meines Stromzähöers im Abstand von 2 Sekunden. Im Webfront werden die Stundengraphen auch richtig dargestellt, bei den Tagesgraphen sind nur die ersten 5 bis 6 Stunden des Tages dargestellt (entsprechend ca. 10000 Messwerte). Gibt es hier ein Limit ‚10000‘ oder hängt das mit der fehlenden Aggregation zusammen?
Genau. Es gibt ein Limit von 10000 für die Berechnung der Stundenaggregation. Ich würde dir im Namen deiner SD-Kartenlebensdauer auch dringend empfehlen max. alle 30 Sekunden zu loggen.
Hmm, ist bei Linux scheinbar anders: Ich definiere eine Variable (ohne Logging) im Objektbaum und sehe diese dann sofort auch im Archiv.
Ich würde dir im Namen deiner SD-Kartenlebensdauer auch dringend empfehlen max. alle 30 Sekunden zu loggen.
Oh ja, das leuchtet ein. Ich nutze für /var/log auf dem BananaPI zwar bereits ramlog, aber die Datenbank würde ich dann eher auf meinen NAS-Server oder eine am BananaPI angeschlossenen Festplatte auslagern (SSD macht wohl keinen Sinn wegen der begrentzten Schreibzyklen?).
Um die Logintervalle zu reduzieren, würde ich die eintreffenden Messdaten dann per Ereignis z.B. alle 30 sec in eine Hilfsvariable kopieren, und diese dann loggen (und evt. im Kopierscript noch eine Mittelung versuchen) - ist das der richtige Weg?
Dazu gibt es Diskussionen hier im Forum, kannst du mal nachlesen.
> Da mach dir mal keine Gedanken, SSD halten deutlich länger und mehr aus, als der Laie vermutet
Im Archiv tauchen alle Var’s auf, auch die nicht geloggten.
Hier das Skript, welches bei mir einmal am Tag (00:00 Uhr ) aufgerufen wird (Raspberry)
Die Var’s „History“ und „History defekte ID“ vorm Start leeren!
„History defekte ID“ hatte ich mal eingebaut, weil ich Probleme mit einigen Dingen hatte, und das Orginal Skript auf die Nase fiel.
<?
/*****
*
* Automatische Reaggregation aller geloggten Variablen
*
* Dieses Skript reaggregiert automatisch alle geloggten Variablen nacheinander
* automatisiert bei Ausführung. Nach Abschluss des Vorgangs wird der Skript-Timer
* gestoppt. Zur erneuten kompletten Reaggregation ist der Inhalt der automatisch
* unterhalb des Skripts angelegten Variable 'History' zu löschen.
*
*****/
$archiveHandlerID = IPS_GetInstanceIDByName("Archive", 0);
$historyID = CreateVariableByName($_IPS['SELF'], "History", 3, "");
// Neu rein, TS
$historyIDdef = CreateVariableByName($_IPS['SELF'], "History defekte ID", 3, "");
// Neu rein ENDE, TS
$finished = true;
$history = explode(',', GetValue($historyID));
// Neu rein, TS
$historydef = explode(',', GetValue($historyIDdef));
// Neu rein ENDE, TS
$variableIDs = IPS_GetVariableList();
foreach ($variableIDs as $variableID)
{
// if(IPS_GetVariable($variableID)["VariableValue"]["ValueType"] != 3)
if(IPS_GetVariable($variableID)["VariableType"] != 3)
{
if (AC_GetLoggingStatus($archiveHandlerID, $variableID) && !in_array($variableID,$history))
{
$finished = false;
// Neu rein, TS
$history[] = $variableID;
SetValue($historyID, implode(',', $history));
// Neu rein Ende, TS
if (@AC_ReAggregateVariable($archiveHandlerID, $variableID))
{
// Neu raus, TS
// $history[] = $variableID;
// SetValue($historyID, implode(',', $history));
// print_r ($variableID);
// Neu raus ENDE, TS
}
// Neu rein, TS
else
{
$historydef[] = $variableID;
SetValue($historyIDdef, implode(',', $historydef));
}
// Neu rein Ende, TS
break;
}
}
}
if ($finished)
{
IPS_LogMessage('Reaggregation', 'Reaggregation completed!');
}
IPS_SetScriptTimer($_IPS['SELF'], $finished ? 0 : 6); //zum testen, da schneller auf Odroid....
// IPS_SetScriptTimer($_IPS['SELF'], $finished ? 0 : 60); // Orginal
function CreateVariableByName($id, $name, $type, $profile = "")
{
global $_IPS;
$vid = @IPS_GetVariableIDByName($name, $id);
if($vid === false)
{
$vid = IPS_CreateVariable($type);
IPS_SetParent($vid, $id);
IPS_SetName($vid, $name);
IPS_SetInfo($vid, "this variable was created by script #".$_IPS['SELF']);
if($profile !== "")
{
IPS_SetVariableCustomProfile($vid, $profile);
}
}
return $vid;
}
?>
Wie siehts den da so zeitlich aus das fest einzubauen? Das ist für mich das letzte was fehlt. Ich fahre ja nun schon seit 61 Tagen produktiv mit dem rasppery
Die Funktion zum Reaggregieren ist zur Zeit eher schlecht als recht Ich würde auf die Werte die dort raus kommen nicht so sehr vertrauen
paresy
Kann es sein, das ich den Ergebnissen immer noch nicht trauen sollte ?
Ich habe da komische, aber gleichmäßige Abweichungen einer Variable zwischen Tag und Woche/Monat (Faktor +2)
Das mit den Timestamp hatte ich auch mal, da war wohl was im argen bei mir, und das Skript fiel auf die Nase.
Daher hatte ich mir"History defekte ID" eingebaut, und konnte so die ID’s gezielt suchen und anschauen (verändern).
Seit dem läuft das schon seit einigen Wochen klaglos.
Im Moment habe ich keine Probleme mit der Anzeige und den Werten feststellen können,
Die Menge ist egal. Was er dir sagt, ist, dass du irgendwo mindestens einen Wert mit einem Zeitstempel hast, welcher nicht fortlaufend ist. D.h. irgendein Zeitstempel ist kleiner als der vorherige. Was praktisch nicht möglich ist… theoretisch aber schon. z.B. wenn ntp deine Zeit synchronisiert und deine Uhr vorgelaufen ist.
Ab dem nächsten Update werfe ich diese Meldung nur ins Log und ignoriere den falschen Datensatz.
Es werden nur die Variablen dort aufgelistet, welche entweder den Haken beim Logging drinne haben, oder den Haken mal drinne hatten! Ansonsten hätte ich ernsthafte Probleme g
