Charts buggy after "now", "0", "0h" fix

[psilo909]

my charts are buggy after merging the 0h fix.

the last values overlap and e.g. form a "z" style line.

[thernst-de]

I will fetch the current version and test

[thernst-de]

Just fetched SNHG (release 1.2) and Smartvisu (latest master branch). Plot,period working as expected

[psilo909]

interesting ;)

[psilo909]

how is your plot.period set up?

[psilo909]

same behavior for 0, now and 0h:

{{ plot.period('corridor_gf_humdity_plot', 'corridor_gf.temperature.humidity', 'avg', '12h', 'now', '', '', '', 'Luftfeuchte', '#00a', 'line', 'Luftfeuchte in %') }}

i can try to reset the database..

[thernst-de]

{{ plot.period(
        'waermepumpe-popup-warmwasser-plot-1', 
        ['zentral.heizung.warmwasser','zentral.heizung.zirkulationrl'],
        'avg',  
        '24h', 0, '','',144,
        ['Austritt', 'RL Zirkulation'], 
        ['#aa0', '#a00'], 
        ['spline', 'spline'],
        ['24 Stunden', '°C']) }}

[psilo909]

just deleted my database and will retry

[thernst-de]

"0" and "now" will be translated into "0h". Could you try "1s" as tmax if it's still not working?

[psilo909]

still:

[psilo909]

trying 1s

[psilo909]

{{ plot.period('outside_temperature_plot_24h', ['knx_global.weather.temperature','eta_unit.temperature_outside.value','dwd_weather.temperatur'], 'avg', '24h', '1s', '', '', '', ['Wetterstation','Garage','DWD'], ['#aa0', '#a00', '#00a'], 'line', 'Temperatur in °C') }} Chart not working anymore..

[thernst-de]

OK. Just checked. The sqlite_visu2_8 plugin from SHNG does not know about "s" (seconds). Please try "1i" (one minute) instead.

O.T._ As "1s" is a valid value accoding to http://docu.smartvisu.de/2.7/index.php?page=misc/fundamentals I will probably create a PR for SHNG

[psilo909]

just did a rollback from the PR. Charts working fine now.

Will try 1i now.

[psilo909]

1i not changing anything:

[psilo909]

but i have to admit i am testing vs shng DEV. but there shouldnt be any changes which affect the behavior

[thernst-de]

I'll try SHNG Dev too ...

[psilo909]

sample answer: 1471766421734,50.66,1471768115850,50.66,1471767068594,50,1471768115850,50

[psilo909]

The returned order of Timestamps seems to be crappy? why is 2nd and last timestamp duplicated?

1471766421734 ,50.66 1471768115850 ,50.66 1471767068594 ,50 1471768115850 ,50

[psilo909]

ich habe das jetzt eindeutig bis zum sqlite_visu28 plugin weiterverfolgt:

[psilo909]

Query dazu: SELECT MIN(_start), ROUND(SUM(_avg * _dur) / SUM(_dur), 2) from num WHERE _item='corridor_gf.temperature.humidity' AND _start + _dur >= 1471735208318 AND _start <= 1471778348318 GROUP by CAST((_start / 431400) AS INTEGER) ORDER BY _start ASC

[psilo909]

auf den letzten Werten kriege ich 100% einen Dreher. Da die DB sauber initialisiert war, wird das schon bei allen so sein m.E. Ich denke SHNG hat mit den 0h Probleme.

[psilo909]

wobei, ich sehe, die timestamps passen hier..

[psilo909]

Kommt im plot.period an:

1471766421702,24.12 1471767668561,24 1471768268494,23.9 1471768868427,23.8 1471770068312,23.5 1471770668251,23.3 1471771268175,23.1 1471774267826,22.9 1471774867759,22.8 1471776067624,23 1471776667575,23.2 1471779059699,23.2 1471778467358,23.3 1471779059699,23.3

SQL Ausgabe:

"1471766421702" "24.12" "1471767668561" "24.0" "1471768268494" "23.9" "1471768868427" "23.8" "1471770068312" "23.5" "1471770668251" "23.3" "1471771268175" "23.1" "1471774267826" "22.9" "1471774867759" "22.8" "1471776067624" "23.0" "1471776667575" "23.2"

SELECT MIN(_start), ROUND(SUM(_avg * _dur) / SUM(_dur), 2) from num WHERE _item='corridor_gf.temperature.state' AND _start + _dur >= 1471735859699 AND _start <= 1471779059699 GROUP by CAST((_start / 432000) AS INTEGER) ORDER BY _start ASC

Frage: wo kommen die zusätzlichen Werte her?!

[psilo909]

ich befürchte fast, dass wir die Verarbeitung von NOW in SHNG nicht unterschätzen dürfen

Ich vermute in dem Block, wird was überflüssiges appended:

    if item_change < iend:
        value = float(_item())
        if item_change < istart:
            tuples.append((istart, value))
        elif init:
            tuples.append((item_change, value))

[thernst-de]

Ich habe mal die timestamp-generierung gedebugt. Die läuft für 0h so wie sie soll.

Bei denen Werten ist auffällig, dass der letzte Wert nochmal mehrfach hinzugefügt wird. Ich habe mir daraufhin nochmal das sqlite_visu2_8 plugin genauer anschaut und in der Tat gibt es bin "_series" einen else-Zweig "if end != 'now'" also eine Sonderroutine für das "now"

[psilo909]

das dachte ich auch erst, aber er kann aus den tuples nicht mehr holen als das sql hergibt

[psilo909]

drum muss es m.E. DANACH appended werden..

[psilo909]

und in meinem beispiel oben siehst du gut, dass im SQL nicht mehr drinsteckt als das was eigentlich soll

[psilo909]

ich kommentiere mal meinen verdaechtigen aus.

[psilo909]

das zickzack ist weg, aber offenbar geht anderes zeug jetzt nichtmehr

[psilo909]

    if item_change < iend:
        value = float(_item())
        if item_change < istart:
            pass #tuples.append((istart, value))
        elif init:
            pass #tuples.append((item_change, value))
        if init:
            tuples.append((iend, value))

[thernst-de]

Ich hätte vermutet dass die URsache ein paar Zeilen höher liegt:

        if end != 'now':
            tuples.append((iend, tuples[-1][1]))

[psilo909]

grundlegend sollten wir aber nicht an der stelle jetzt rumbauen. wir haben die 1.2 gerade erst released und wenn wir hier im core nen fix bauen, geht bei alten usern garnichts mehr mit der SV

[psilo909]

nein, weil in den tuples nur die DB Results sind. und da sind die Zeilen nicht drin; schau dir mein bild mit den werten an.. im SQL ergebnis ist alles super.

[psilo909]

wow.. habs auskommentiert.. jetzt gehen sie. du hast doch recht.. was macht -1 hier?

[psilo909]

    if tuples:
        if istart > tuples[0][0]:
            tuples[0] = (istart, tuples[0][1])
        if end != 'now':
            pass #tuples.append((iend, tuples[-1][1]))

[thernst-de]

-1 sollte das letzte Element in den tuples sein

[psilo909]

bei uns kommt jetzt leider besuch, aber an der stelle müssen wir wohl oder übel ansetzen, oder nen anderen fix in der sv bauen.. ohne es 100% zu verstehen sollten wir aber noch nichts beschliessen. warum kam das bei dir eigentlich nicht?

[thernst-de]

Ich denke es ist eine Schwachstelle des sqlite-Plugins, dass an mehreren Stellen explizit auf "now" geprüft wird. "0h" hat die gleiche Bedeutung, wird aber nicht korrekt verarbeitet. Warum es bei mir keine Probleme gab, kann ich dir leider noch nicht sagen. Werde ich aber mal untersuchen. Trotzdem hast du natürlich recht, eine Inkonsistenz zwischen SHNG und SV ist beiden Projekten nicht förderlich. Ich denke, dass ich diesen Fix so umbauen kann, dass statt "0h" doch "now" als Default-Wert verwendet wird und "0" bzw. "0h" zu "now" ersetzt werden. Dann sollte SHNG die korrekten Werte liefern. In einem zweiten Schritt wäre dann dafür zu sorgen, dass SHNG auch für "0h" die korrekten Werte liefert. Wenn das beides released ist kann man überlegen, ob man in SV wieder "0h" als Default-Wert verwendet.

[psilo909]

wenn das database plugin für die shng 1.3 mal was wird, könnte man auch da gleich alles anpassen und das alte sqlite verbannen

[psilo909]

bisher crasht - vermutlich wegen multithreading problemen - mein shng mit dem database plugin nur alle paar tage.

[thernst-de]

Ich konnte das Problem nun bei mir nachvollziehen. Ich habe dabei gelernt, dass

define('config_cache', 'off');

den SV-Cache nicht wirklich deaktiviert :angry: Gleichzeitig scheint das Problem nicht offensichtlich zu sein, wenn viele Datenpunkte im Plot sind.

Mit dem PR #18 wird die oben beschriebene Änderung hinsichtlich SV vorgenommen

[psilo909]

looks good at the moment -> close

[smaiLee]

Ist dieser Issue mit dem PR #18 endgültig gefixt oder ist noch was offen?

[psilo909]

@smaiLee erstmal ist er gefixt, wir sollten uns aber überlegen, ob wir synchron shng 1.3 und die sv so umbauen, dass wir anstatt now das 0h annehmen.

[thernst-de]

Ich glaube, ich habe eine Lösung das 0h-Problem im sqlite-Plugin von SHNG gefunden. Ich teste aber noch. Da eine Lösung aber erst in eine zukünftige Version von SNNG einfließen wird, sollte vorerst "now" der default-Wert bleiben.

[psilo909]

seit dem einspielen des PRs habe ich jetzt das problem, dass bei jedem seitenwechsel erst nach f5 die daten wieder da sind. kann das jemand reproduzieren?