neue svg-Funktion: card

[jkriegl]

ok dann habe ich das ganze doch nicht verstanden.
Läuft etwas kürzer als eine slot-Dauer können Informationen verlohren gehen.
(bei card5 immerhin 5 Min) Für so einen Fall ist daher card leider nicht geeignet.

[Damian]

ok dann habe ich das ganze doch nicht verstanden.
Läuft etwas kürzer als eine slot-Dauer können Informationen verlohren gehen.
(bei card5 immerhin 5 Min) Für so einen Fall ist daher card leider nicht geeignet.

ja, so ist es.

Beispiel:

Max=100, Min=0

=>avg=50

1. Event im Slot 60 -> 60, wird übernommen, weil größer als avg und größter im Slot
2. Event im Slot 70 -> 70, wird übernommen, weil größer als avg und größter im Slot
3. Event im Slot 50 -> 70, wird nicht übernommen, weil größer als avg und nicht größter im  Slot
4. Event im Slot 30 -> 30, wird übernommen, weil kleiner als avg und kleinster im Slot
5. Event im Slot 20 -> 20, wird übernommen, weil kleiner als avg und kleinster im Slot
6. Event im Slot 30 -> 20, wird nicht übernommen, weil kleiner als avg und nicht kleiner im Slot
7. Event im Slot 40 -> 20, wird nicht übernommen, weil kleiner als avg und nicht kleiner im Slot

neuer Slot:
40 als letzter Wert wird in den nächsten Slot gerettet (da 20 gewonnen hat), wenn im nächsten Slot kein Event stattgefunden hat

Damit wird erreicht, dass Extrema gewinnen, aber der letzte Wert im Slot noch eine Chance bekommt, gerettet zu werden, wenn im nächsten Slot kein Event vorkommt.

Für ein Piktogramm mit 72-Plätzen muss es reichen, für genaue Analysen muss man jeden Wert loggen und über SVG-Plots plotten.

Im Anhang sieht man Cards mit 7 Tagen Laufzeit (Barometer war nicht immer aktiv).

Sowohl Sprit mit seinen Spitzen (nach oben und unten), alle kontinuierlich ansteigenden Verbräuche, die um Mitternacht auf Null gesetzt werden, als auch 24-Stundenmessungen für Temperatur oder Feuchtigkeit sind ebenso unkritisch.

Einen kurzen Aussetzer irgendwo wird man nicht erkennen, das ist aber auch nicht die Intention dieser Anzeige.

[jkriegl]

wie wird avg berechnet?
Vorgängerslot = 0, wird propagiert
1. event im slot = 1, avg = .5 wird übernommen
2. event im slot = 0, avg = .33, wird nicht übernommen, wird propagiert

[Damian]

avg ist immer der Mittelwert des aktuellen Maximums und Minimums über den definierten Zeitraum.

[jkriegl]

ok bin draussen
Zeitraum ? col?
Warum ist im Beispiel:
1. event = 1, 2. event =0, Ergebnis: mal Null mal EINS - rein zufällig
edit: die 1 gewinnt nur, falls sie alleine im slot ist.

[Damian]

ok bin draussen
Zeitraum ? col?
Warum ist im Beispiel:
1. event = 1, 2. event =0, Ergebnis: mal Null mal EINS - rein zufällig
edit: die 1 gewinnt nur, falls sie alleine im slot ist.

Zeitraum von col.

Es ist nichts zufällig, sondern nach dem programmierten Algorithmus, beides sind Extrema, das letzte Extremum des Slots gewinnt, das kann 0 oder 1 sein - wie schon beschrieben.

[jkriegl]

Zufall: Beispiel col1 hat weinger Treffer als col3
oder man müsste den Algorithmus anschauen.

[Damian]

Falls es jemandem zu bunt ist, ich habe bei $prop einen weiteren Parameter für graue Y-Achsenbeschriftung eingebaut:

[Damian]

Falls es jemandem zu bunt ist, ich habe bei $prop einen weiteren Parameter für graue Y-Achsenbeschriftung eingebaut:

neue Version eingecheckt, Doku zu $prop aktualisiert: https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Anzeige_eines_Werteverlaufs_und_des_aktuellen_Wertes_mit_Hilfe_der_SVG-Funktion_card

[mumpitzstuff]

ja, save (entspricht save config) speichert das save-File als auch die config-Datei, vermutlich damit sie nicht auseinander laufen, daher würde ich es nicht im Sekundentakt machen.

Ich hatte irgendwie angenommen, das Readings generell bei einen ,,shutdown restart" gesichert werden, egal ob sie z.B. durch einen . versteckt sind oder nicht. Weshalb ist es dann notwendig, vorher ein save config auszulösen?
Oder liegt es an der besonderen Art und Weise der Datenhaltung, weshalb das notwendig ist? Kann man diese Daten vielleicht auch in ,,normale" Readings stecken, deren Inhalt ein Shutdown restart überleben würde?

[Damian]

shutdown macht kein save, deswegen solltest du vor jedem shutdown save machen, sonst hast du nach dem Hochfahren einen alten Stand. Das hat nichts mit card zu tun.

[Damian]

ich sehe gerade, dass offenbar Readings gesichert werden, offenbar gibt es aber beim shutdown kein save-Event.

[mumpitzstuff]

Genau. Die config wird nicht gesichert, was auch gut ist, die readings aber schon (eben nochmal getestet). Wenn du deine Daten also irgendwo als verstecktes Reading sichern würdest und dieses Reading dann beim Init laden würdest, dann wären die Card collector Daten ganz ohne Zutun des Anwenders gesichert.

Man könnte dann übrigens die gesammelten Daten auch noch in Textform im RAW Output sehen...

[Damian]

Ich habe das Problem schon gelöst. Jetzt werden nicht nur beim SAVE-Event sondern auch beim Shutdown-Event,  die internen gesammelten Daten in Readings geschrieben, die dann ja gesichert werden - es funktioniert.

[Damian]

Neue Version eingecheckt.