SmartVISU + fronthem - Plotübergabe (gelöst)

[alkazaa]

Ich habe meine Routinen zur Mittelwertbildung nochmal überarbeitet, damit Werte an Grenzen eines Mittelungsintervalls korrekt verarbeit (und nicht weggeworfen) werden.
Siehe dazu den Nachtrag und den Anhang in diesem Topic.

Falls Wolfram hier noch mitliest:
Ich denke, man könnte das ganze jetzt in den master branch einfügen. Da ich nicht mehr sicher bin, von welcher Version ich ausgegangen bin, müsste ich eine Version mit den aktuellen UZSU Routinen haben, um meine Änderungen dazu zu mergen. Welche wäre das?

Beste Grüße
und einen guten Rutsch

Franz

[wvhn]

Moin Franz,

Klar lese ich noch mit und habe das Thema auch noch auf meiner to-do List. Ich schau mir das in den nächsten Tagen mal an, welche Erweiterung ich guten Gewissens in welchem branch zur Verfügung stellen kann.

Unentschlossen bin ich noch mit den Erweiterungen der Zeiteinheiten ('q', 'v'), weil das von smartVISU nicht unterstützt wird und dort an mehreren Stellen abgefangen werden müsste. Vielleicht fällt uns da noch eine andere Lösung ein.

Gruß
Wolfram

[wvhn]

Hallo zusammen,

wie schon vor einiger Zeit versprochen habe ich die Versionen in den beiden branches überarbeitet.

• der master branch enthält jetzt die bisherige Version, erweitert um die an den smartVISU-Standard angepassten Zeitangaben: durations mit mehreren Termen, Unix-Zeitstempel und "now". Wie oben beschrieben wird die Berechnungsmethode (hourstats, daystats, weekstats, monthstats) für die Auswertungsmodi aus dem ersten Term der duration entnommen.
• der develop branch enthält die letzte von Franz bereitgestellte Version mit neuen Auswertungsmöglichkeiten für die Plots (https://forum.fhem.de/index.php/topic,118668.msg1252219.html#msg1252219), sowie die neuen UZSU-Routinen von raman.

Aus meiner Sicht ist dies die beste Lösung, um sowohl eine breit getestete und bewährte Version, als auch eine noch experimentelle Version mit neuen Features zur Verfügung zu stellen.

Gruß
Wolfram

[alkazaa]

Moin Wolfram,

im KNX-smartvisu Forum hatte ich die "sub fronthem_Time($$)" für negative duration-format Angaben wie z.B. '-2h' so erweitert:

Code Auswählen Erweitern

sub
fronthem_Time($$)
{
my ($time, $period) = @_;
my $temp;

if ($period =~ /^(.*?)\s*(\d{13})/) { # alkazaa
return int($2/1000 + 0.5);
}
if ($period eq "now") {
return $time;
}

# alkazaa
# the next 'if' is meant to parse a tmin or tmax parameter of the form "0w 2022-12-01 12:34:56"
# It converts correctly for further processing, however, it is not working with SmartVISU, since
# within the SV plot.period widget such a tmin statement does not produce the correct x-axis
if ($period =~ /^(.*?)\s*(\d{4})-(\d{2})-(\d{2})\s(\d{2}):(\d{2}):(\d{2})/) {
return timelocal($7,$6,$5,$4,$3-1,$2);
}

my @periods = split(' ', $period);  # alkazaa: split composed time specifications like "1y 3m 5d 10h"
foreach my $period (@periods)     # into an array like ("1y","3m","5d","10h") and loop over array elements
{
if ($period =~ /^([-+]?\d{1,4})(s|i|h|d|w|m|y)/)
{
my $newTime = 0;
if ($3 eq "s")
{
$newTime = $2;
}
elsif ($3 eq "i")
{
$newTime = $2 * 60;
}
elsif ($3 eq "h")
{
$newTime = $2 * 3600;
}
elsif ($3 eq "d")
{
$newTime = $2 * 3600 * 24;
}
elsif ($3 eq "w")
{
$newTime = $2 * 3600 * 24 * 7;
}
elsif ($3 eq "m")
{
$newTime = $2 * 3600 * 24 * 30;
}
elsif ($3 eq "y")
{
$newTime = $2 * 3600 * 24 * 365;
}
$time -= $newTime;
}

}
return $time;
}
Ich schlage vor, das in den develop branch zu übernehmen. Die Einführung der $sign Variablen scheint mir hinreichend betriebssicher implementiert, sie auch gleich in den master branch zu bringen.

Beste Grüße
Franz

[wvhn]

Moin Franz,

vielen Dank. Ich übernehme das bei nächster Gelegenheit.

Gruß
Wolfram

[alkazaa]

Ich übernehme das bei nächster Gelegenheit.

Danke, Wolfram! (aber aufpassen: Ich habe das Vorzeichenhandling im code snippet von Beitrag #63 nochmal editiert, ist jetzt kompakter geschrieben)

-Franz

[wvhn]

Hallo Franz,

kannst Du mir mal helfen, das Regex

Code Auswählen Erweitern

if ($period =~ /^([-+]?\d{1,4})(s|i|h|d|w|m|y)/) zu verstehen?
Mit den beiden Klammern gibt es zwei Auswertegruppen, deren Ergebnisse nach $1 und $2 geschrieben werden müssten. Du verwendest aber im Folgenden $2 und $3.

Da ich den Code nicht selbst testen kann, möchte ich ihn zumindest verstehen, bevor ich ihn im Repository veröffentliche.

Denke und Gruß
Wolfram

[alkazaa]

Wolfram,
danke fürs Aufpassen. Du hast natürlich recht, es muss $1 und $2 heißen.

Die Änderung gegenüber der 1. Version im Beitrag #63 lag darin, das Vorzeichen der Zahl gleich in der 1. capture group mitzunehmen.

Das kommt davon wenn man zu schnell etwas 'kompakter' schreiben will...

Sorry, Franz

[wvhn]

Die Änderung ist jetzt im master branch und im develop branch. Negative durations ermöglichen es, ein Diagramm auch in die Zukunft hinein zu skalieren - z.B. zur Darstellung von Prognosedaten.

Gruß
Wolfram