Latest Dev version (display ?) bug with calculated kwh (bar) graphs

Guys,

i’m having a weird issue that i just noticed today… My calculated kwh feeds displayed in a bar graph with delta = on all display a huge negative value for today…

when i set delta = off it seems to be correct but that’s not the display i want …

when looking at the feed graph of it looks ok to me so it might be the values are correctly saved (not sure how i can check that as i don’t know if it’s a display bug or data bug)

I’m not sure if this is normal but when looking using the “graph” menu and selecting all kwh calculated feeds and moving to the right (into the future timewise) they all drop off also… But i as i said i’m not certain if this is a problem it could be it’s always displayed like this when looking into the future. The drop off also always is on the exact time (now) each time i reload the page.

I’ve been looking through the code changes and i noticed @nchaveiro did a PR for changing a few things related to using boolean values but i’m not certain the issue started there. I’ll look some more to see if i can find the culprit though… but it could be there’s a bug in latest dev. Also i’m not certain but since when does a bargraph with delta on display data for the current day ? it used to always display up until today -1. I’m all for displaying the current day values though but it could be there’s a bug. I’m also thinking it’s not really a data bug but actually a display / calculation bug as My electric isn’t showing the huge negative values for the current day …

cheers

I just updated and checked. I’m seeing this too. I’ll have a hunt as well.

glad i’m not the only one, what version where you before updating ? Might make it easier to narrow it down

Looks like it’s this commit: 69ce584. And I think I can see why. There’s a couple of zeros at the end of the returned data array after this commit, because it’s casting some nulls that were there before to a float, which end up being 0. The null was being interpretted by the graph as a missing value before, but now it’s being interpretted as, well, 0.

The right fix is to stop it from requesting too much data.

OK I think it’s worth asking @chaveiro about this. I’ll post a GitHub issue and he can chime in as he’s been doing all the casting types everywhere.

FWIW I think the casting types is great, as not being proper types everywhere just masks this sort of issue.

1 Like

nice & quick find, i wouldn’t have noticed that. I removed the float typecasts and it indeed fixes the errors and it’s displaying data up until day-1 again.

edit: it also the cause of the drop off in the line graph when looking into to the future (last screenshot in 1st post), so before it just stopped but did not go to zero.

Reading this you may have uncovered the reason I’ve seen ta deterioration in the web apps data. for example this page shows a lot of “dropping out”.

When I looked into it I found all my graphs based on phpfina feeds seem to be reporting “null” values as zero.

This next graph shows the phpfina feed “solar” which is a total of the 3 individual phase feeds, since the feeds are never at zero it should not ever be a zero value, but being a fixed interval it can easily record “nulls” if the timing is out.

This is the same data but called “solar power” and it is a phptimeseries feed based on the same value derived from the 3 +feeds, just persisted to a different feed type.

For now I have simply altered the apps to allow me to use the phptimeseries feeds in place of the phpfina as a temp fix, but it could well be related to this issue you see too, I do not recall seeing this prior to a few days ago.

Ouch. Yes, I see the same on my apps too. OK, more of a serious issue then.

it probably is, i think it only affects phpfina & phpfiwa (and templateengine ? not sure what that is exactly) as far as i could see

At least it’s on the “display” side of things rather than the “record” side of things, the nulls are still nulls, they are just being displayed as zero’s as far as I can tell so once a fix is in place the historic data should be fine.

you could easily check if that’s the case by removing the float typecasts that were added in that commit. But i think it probably is the case, as i temporary did this and everything reverted to normal, although i do only use my electric and could not see if something was wrong there (like your screenshots).

I will take a look tomorow… Just have to figure where the nulls are coming and where are they being cast to int.

Last update to 9.7.5 should fix this…

@nchaveiro thanks … just pulled it and as far as i can see it indeed fixes it on all the places where i had troubles with it