SuperChart 1M, 3M range clipping, 6M range draw bug (Android 2.26.4)

Version information
Android: 6.0.1
Blynk app: 2.26.4
Local server: 0.38.6 (java8)

SuperChart clips historical values on 1M and 3M ranges:

The history goes further back which can be seen on the 6M graph. The 6M graph has some drawing issue also which you can see from the CO2 graph.

If I try to scroll the 6M graph the graph scrolls a bit and it then looks correct after which the scrolling gets locked. Note also that the first X axis date changes from Jan 13 to Jan 14.

I cannot scroll any of the above ranges either. I don’t know if this is due to a recent update or a bug though. Scrolling on a high resolution 1W range goes back one week.

Please show your graph settings. Was it ok before the update or you don’t remember? (by the way - the latest one is 2.26.5)

Ah yep sorry I forgot I’ve disabled automatic updates to better be able to keep the local server in sync. Update didn’t help though.

Unfortunately I don’t remember at what point the problem started appearing but it’s been there for some time, I’ve been hoping for it to get fixed as it seemed so obvious. The same occurs with my tablet which has Android 5.0.2 running.

I’ve in general noticed issues with the SuperCharts when there are more than one on a single tab. The ones I remember:

  • I created a SuperChart with tow line graphs (height limited to show them distinct from each other) which both had a green/red grandient color. Then created a copy of that and configured different vpins on the second one. The gradient color did not work on any of the line graphs on the second one but were orange color

  • I created a copy of the small particles chart shown on the previous screenshots to the same tab to display different data. For the copy I could not get the title visible (tried toggling it on/off and changing the title text. When I created a new one and manually recreated the same height limits it worked fine.

Anyway back to the topic - I didn’t know which settings in particular you wanted to see so here’s an example of all the settings for the temp/humi graph.

Thanks for details, we will investigate.

I’ve prepared a build with a possible fix: - could you try to install it and check?

This build was definately an improvement but does not completely fix the issue. The 1M and 3M ranges initially drawn clipped from the same timepoint as on the previous screenshots when opened. However, with this build I can now scroll the graphs.

For some reason I had to first uninstall the official version to be able to try this out but eventually got it installed and running. Is this typical?


Yep, that is typical for some devices.

On your issue - does the issue reproduces with the same periods but from high resolution part of periods picker - could you check?

@ristomatti please send me your login email.

The problem seems to only affect the regular time ranges. The high resolution charts for 1M or 3M display without clipping.

I’m using a local server but I can do a CSV export of the data for the charts if that would help?

We need mostly “.bin” files from “data” folder

I PM’d you for details to identify the correct ones. I’ll send a share link through a PM when I know which ones you need.

@Dmitriy / @BlynkAndroidDev sorry I haven’t had time to dig into sending the .bin files. The issue is so minor now after the last update that fixed the scrolling I don’t see it worthwhile the effort. It seems to only occur on certain SuperChart widgets and maybe just might go away by recreating them.

In case you want to dig deeper into the issue I can still send the files but since it’s a minor glitch this probably isn’t a very high priority anyway? What I can tell about the graphs though is that both have these in common:

  • 3 graphs running on top of each other from virtual pins
  • there’s data of about 1 year, updated every 15-60 seconds depending on the data source

@ristomatti issue seems to be an app bug, so it may appear in other places/users, we would like to dig into it. Would be very helpful if you can provide us with those data (bin files for pins were you see the problem).

Ok I’ll do that now and PM a link in a moment.

@ristomatti thanks! That was very helpful. Few questions: what OS do you have? What exactly java version? Server version? Did you update it recently? Have you done something special with server between 30 June and 1 of July?

@ristomatti One more thing - are you able to grep all your “*.log” files for the “Error” message?

odroid@odr01 ~ $ uname -a
Linux odr01 3.14.79-113 #1 SMP PREEMPT Wed May 10 00:43:15 BRT 2017 aarch64 aarch64 aarch64 GNU/Linux
odroid@odr01 ~ $ java -version
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)

Oracle Java, Debian is running on an Odroid C2 (ARMv8 SOC I think). Server version is the one mentioned on the top of the thread. I run it through PM2 (should make a systemd script but couldn’t have been bothered yet).

I don’t remember doing anything else with the server than updating it every once in a while. I don’t have any files modified in the server folder near those dates at least. But I might have done an update from 0.38.1 to .2 as it’s the closest jar file to the date. I only update a symlink to the latest jar before restart so can’t know for sure.

@ristomatti ok, waiting for “grep”, also please check your system for daily_temp.bin files.