SuperChart Y range multiple bugs

Issues and Errors
1

I am using a single data stream SuperChart.
When using “Auto” for Y-axis scaling, the min/max scale is calculated “correctly” only initially after switching between the different time bases. And when I say “correctly” I mean still extremely badly (20-25 range when the data currently being shown is in the 23.2-23.6 range and so the resulting plot is a straight line with no way to see the small changes).
It gets even worse on the next data update (so a few seconds after the time base switch) or even initially when the app (Android) is first opened, the min/max range is auto selected in such a way not to cover ANY of the actual data points (20-21.2 range auto selected when the actual data is in the 22-24 range)!

When I use a fixed min/max Y scale in the settings, this does not happen but neither does is exactly work, experiencing a completely different set of bugs. If I select 21-24 for the min-max values, what the chart actually shows is the 20-23 range (that understandably cuts off some of the data). Also, as soon as I switch to another time base the Chart selects another (this time, auto) range, ignoring my request to use the fixed min-max values.

As a hobbyist programmer, I am frankly puzzled how can one manage to write a code that fails to correctly find the minimal and maximal value from a set of numbers.

2

You’re far more likely to get this issue resolved if you tone-down the rhetoric and righteous indignation and provide actual data that is of help to the Blynk staff and enables them to understand the issue in detail.

I’d start with details of the mobile OS type and Blynk app version, and then include plenty of screen shots and narrative to explain the issue.
This will need to include screenshots of the SuperChart setup and options, along with information about how the datastream is defined in the web console, including what’s in the Advanced settings.

I’d probably also include information about how frequently you are sending data to the datastream, and give an example of the values that were sent during the period shown in the screenshots you provide - maybe by using a sketch which sends an artificial series of data points to ensure repeatability.

Finally, details of which subscription plan you are using may also be useful.

Pete.

3

This is not normally how I write bug reports but after being forced to re-do a lot of my projects based on the old Blynk (for which I have bought quite a few ‘energy packs’) because it was decided that the new Blynk is worth a lot more money, and still the same bugs remain and some new are added… I can’t help but to add a bit of ‘sass’.
It would de different it it were an open source project maintained by volunteers.

I’ve already tried to provide all the details I deemed relevant. I’m using Android and the latest available Blynk IoT. My sketch sends a new temperature value every 5s and as it’s previously calculated with a lot of averaging, it’s extremely smooth and well behaved (no sudden spikes or out of bounds values). Value is currently in the 23.2±0.5 range . When I do get to see the actual data on the graph (between all the bugs mentioned) it’s indeed smooth with no missing values (connect missing data points turned off) or sudden spikes. For me that means that the Blynk server has the correct data and so the actual sketch that sends it should be irrelevant.

OK, after further experimentation I’ve identified a switch that triggers the manifestation of most of the mentioned bugs: “Override auto scaling for all datastreams”. As I am using a single datastream on a chart (Free version, so can’t use multiple) I left it at the default (off) thinking it does not apply to my use case (a single stream).

With it set to ON and “Y-axis scaling” set to “Auto” these bugs remain:
Non critical:

  1. Non optimal and not consistent range selection:
    On App open or initially after switching between the time bases, a needlessly large range gets selected making small changes impossible to spot. Needless to say, my expected behavior here would be to select the range in such a way to best use the available Y space to show the data.
    Screenshot_2022-11-08-09-27-53-685_cloud.blynk-01
    Screenshot_2022-11-08-09-27-53-685_cloud.blynk-011080×654 62.5 KB

    On the next chart update, the upper bound gets a better value, but the lower bound does not:
    Screenshot_2022-11-08-09-29-40-279_cloud.blynk-01
    Screenshot_2022-11-08-09-29-40-279_cloud.blynk-011080×651 69.6 KB

    Critical:
  2. Both X and Y tick (labeled values) are chosen in such a way that they require rounding beyond what is shown on the labels and thus the labels no longer represent the actual values at that chart position (what I would consider a shocking “offence” for any even remotely respectable data plotting widget). Expected behavior: literally look how it’s done on any X/Y data plot ever.

With it set to ON and “Y-axis scaling” set to “MIN/MAX: 21-24” these bugs remain:
3. I can detect no change from the “Auto” position. This could be the expected behavior as I am not 100% sure what the “Override auto scaling for all datastreams” is supposed to do in such a situation.

With it set to OFF and “Y-axis scaling” set to “Auto” this is the additional bug on top of the ones mentioned before:
4. only after switching between the time bases is a sane(ish) auto range initially selected:

Screenshot_2022-11-08-09-05-06-354_cloud.blynk-01 (1)
Screenshot_2022-11-08-09-05-06-354_cloud.blynk-01 (1)1080×647 66.9 KB

Then on the next chart update (so after a couple of seconds, depending on the time base selected), without fail, a completely wrong range gets selected usually containing no actual data points:
Screenshot_2022-11-08-09-06-06-309_cloud.blynk-01
Screenshot_2022-11-08-09-06-06-309_cloud.blynk-011080×638 61.1 KB

The same happens when the chart is shown the first time the App is opened and the only way to (temporarily) fix it is to change to another time base and back. After a few seconds the range again gets selected incorrectly.

With it set to OFF and “Y-axis scaling” set to “MIN/MAX 21-24”:
5. The range no longer seems to be Auto-ranging but neither is it what I have requested. Initially it’s 21-23 (cutting off a lot of the values) and only after base change it changes to 20-25 (still not what I requested but at list all the data is shown).

I am willing to provide more data but only what the actual code maintainer deems necessary. As I am using the latest Blynk App and libraries, only a single SuperChart widget with only a single datastream on that widget, with a VirtualPin update rate of once every 5 seconds and a very well behaved value, I would be very surprised it this is some obscure, never seen before and impossible to replicate behavior.

EDIT: Ok, I think I (partly) understand the rational behind the issue 2. Rather than selecting the optimal range for the data that is currently shown, the range is selected based on all of the data saved on the server as it was the easiest way to implement the data scrolling but at the significant Y resolution loss at shorter time scales. I would gladly turn off the ability to scroll it that meant a better range selection for the actual data currently shown. It still does not explain most of the other issues.

4

I’m glad to hear it, but it’s a pity you’ve made an exception in this case.
Try putting yourself in the shoes of the Blynk developer who looks at this post. Attempting to extract the relevant information from your posts is incredibly difficult as you don’t seem able to be factual and objective and provide the relevant data.

With Blynk IoT the way the data is stored in the database varies depending on whether raw data is selected in the template datastream setup. So this, along with information about the frequency of the data and the actual data values sent to the database will give them a reference point for the values being plotted. I asked you about this, but I can’t find your answers to those questions.

The way that the raw or averaged values are plotted in SuperChart depends on the time range selected, and on whether standard of high resolution is chosen for that particular SuperChart widget. Once again, you’ve not shared info about this part of the setup as far as I can see.

It seems that you’ve accumulated 5 years worth of anger towards the SuperChart widget since it was introduced in August 2017, and rather than provide ongoing feedback during that time you’ve decided to have a mass outpouring over the past few days.
That’s fine, but it’s far from the most effective way of flagging-up the problems that you’ve identified and providing sufficient data to allow the developers to exactly replicate your issues and work towards resolving them.

Once again, my advice is to dial-back the rhetoric and provide structured data regarding the issues you’ve identified.

Pete.

5

I am not using RAW datastreams. From what the info hint says, that would mean that only one data point per minute is saved, averaging any multiple points that get sent inside that minute. I am fine with that resolution. I am not sure why would that have any bearing on the chart range calculation routines, but here it is - non RAW datastreams used.
As for the resolution selected, I am using:
standard - Live, 15min
high - 6h, 1d, 1w
Issues mentioned apply to both high and low resolution timebases (the same behavior on both 15m and 6h time base).

Though I am extremely far from being a professional programmer, I do enough coding to understand how easy and understandable it is to make a mistake / introduce a bug. At the same time I can recognize conscious algorithmic decisions that are simply inexcusable. To decide that the way you will plot tick labels is to somewhat randomly decide on the highest and lowest bound, divide that with the fixed number of labels (get something like 1.23426564 tick distance) and then round that number when displaying it… and get stuff like 12 13 15 16 18 hour sequence, equally spaced… I’m sorry but that’s not a honest mistake. Any programmer that does that should be ridiculed, especially if he is trying to sell you his software - to other programmers.

6

It makes a difference because when Raw isn’t selected the Live view plots the values as they appear. Ranges up to and including 1 Day use data that is accumulated and averaged at one minute intervals. Anything greater than 1 Day is plotted using the one minute data that has been further accumulated and averaged into one hour values.

Yes, we hear you!
All you’re doing is increasing the signal to noise ratio here, making it much more difficult to “see the wood for the trees”. As I said before…

but you don’t seem to be able to help yourself in this regard.

Pete.

7

No, it does seem that in this particular instance I am not able to. Some of the bugs described are simply too obvious (should be to anyone who has made or even used any plotting program, ever). But, OK, I believe I’ve made that point. Don’t get me wrong, Blynk is a cool library and service. Well thought out and for most part very well executed. But from where I am sitting charting widget seems pure crap.

Now I am curious, considering how much extra data I was asked (possibly, quite rightfully), how obscure is this issue? If I am the only one who has seen such behavior then I am obviously prepared to give as much assistance as I can to track down the obscure set of conditions and settings that allowed these bugs to manifest in an otherwise perfectly working widget. On the other hand, if it’s extremely easy to reproduce then asking a user for further and further info just seems lazy and rude.

So Peter, I would appreciate (and probably so would Blynk programmers) to learn if you have indeed not come across any of the issues I have mentioned, even with a similar use case to mine (single stream SuperChart). Maybe it’s Android specific (if you are using iOS)?

As for the significance of the RAW/ not RAW streams, though I’ve tried to think of a reason the mentioned difference could explain the sudden jumps in Y ranges, I couldn’t think of anything and I am afraid that only someone with access to the actual widget code will be able to figure out what is happening and why.

8

A quick search of the forum will show that there aren’t a large number of SuperChart issue that have been reported and not fixed, and I don’t recall seeing any that are remotely similar to the ones you’ve raised.
Superchart in IoT is implemented significantly differently compared to Legacy - as far as i can see, so historical report probably aren’t that relevant anyway.
So yes, you probably are the only person who has found this behaviour to be an issue.

I use iOS, and clearly don’t use the Supertchart widget in the same way as you. I tend to plot multiple datastreams on the same chart, and because they have significantly different scales I almost always use manual Y axis scaling.
I tend to use the web dashboard chart for my data analysis as I find that working on a wide screen monitor is more insightful.

Pete.

9

Thank you. As I have said, I have tried both a manual Y range and an auto range and both have issues. Are you also saying that when you select a 6h time base on your phone, you do not get an insane sequence of labels for the hours shown? Or simply the fact that X and Y axis labels that do not match their positions is not a big deal.
In the end, what I’ll probably end up doing is using a raspberry pi server to process all of my charts in a profesional level plotting software like gunplot and having the Blynk app link to that chart. I was doing it before I’ve started using Blynk and seems I’ll be better off using it again. I am used to a lot more advanced plotting programs but I did hope Blynk could handle a single stream with zero issues.

10

Insanity is often a case of perspective, but the time periods look fine to me…

image
image2160×1207 181 KB

My systems are based around a Pi running Node-Red and MQTT with the Node-Red plug-in for Blynk to allow me to use Blynk as my front-end.
Personally, I’d probably write the values into a Grafana database if I wanted to use a different graphing system.
But, if you’re using a a P for your database then you need to have a good SSD solution for it, as you’ll very quickly kill your SD card otherwise.

Pete.

11

I was just about to make a snarky remark that it does turn out that insanity is a case of perspective and that all that was required was to change the ‘perspective’ to landscape:

Screenshot_2022-11-09-05-56-11-314_cloud.blynk
Screenshot_2022-11-09-05-56-11-314_cloud.blynk2246×1080 124 KB

At the first glance, looked less insane but of course, on second glance the insanity came back in full force. 23, 01?! Current time (the latest value update) was 5:56, not nice round 05h that the label would like me to think (that 05 is actually 05:50, rounded down!). Also I have never in my life seen Y tick values selected in this fashion, have you? 0.385 per division?! Rounded on display only. In a non-alpha, production release. Passed by multiple Quality assurance personnel, “yeap, looks good enough to me!”.
When I say that this is completely mental, am I really speaking from some weird, difficult to understand perspective? iOS widget may be working correctly, but the same widget on Android is severely broken. Labels are up there the in the list of worst programming decisions (not honest bugs) in the history of chart making, auto-ranging tends to select a range that has no data points in it (but you do get a very clean chart), manual range gets partly ignored and even jumps around from one second to the next.
Or am I simply trying to use the Chart widget in a way it was not meant to be used? As an Android user maybe I am simply not as used to thinking, when I find a bug, “this must somehow be my fault”.

I do appreciate the useful suggestions concerning SD wear. What I was doing before was to keep the actual data on a third-party server database and use RPi to build a very complicated chart on demand. Problems could also be mitigated with less frequent disk writes.

12

In my experience, even using good quality SD cards and tuning the available settings to ensure that SD card access is minimised as much as possible, the SD card still takes quite a pounding and will fail eventually. And of course it’s always when you least expect it or want it.

I now run a number of RPI4s in various locations and all are fitted with the Geekworm x825 based kit and a good quality SSD…

Pete.

13

Hi, we have improved on the y-axis scaling in the Simple Chart widget (but it is limited to the pro plan only) and planed to update Super Chart as well, but we can not provide any estimates currently. I’ll try to improve the y-axis scaling for the one-datastream Super Chart in the nearest updates: probably in the 1.18.0/1 version, so I hope it will be in several weeks/month.

14

Hi, I also had some issues on my iPhone (you are not alone). I changed min and max but the chart did not update. Quite frustrating. What worked for me was restarting the App. Hope it works for you.

Kang

15

I have this exact same problem on Android that I reported but was told it couldn’t be duplicated.

16

Was that reported here on the forum, or via a GitHub Issue?

Pete.

17

Did it also happen with the 1-datastream graph?

18

This is where I described the problem. Lock sign on Superchart in Android - #8 by jstobaugh
It occurs if I leave the app running on my phone and minimized. When I go back the chart if looked at closely shows a time of when I last looked at it and not the current time. When I click on the hour, 6h or day it momentary goes to that but immediately goes blue back on whatever time it had been on.

19

that’s a different issue, we have some ideas on fixes (but we still have not reproduced it) - I’ll add a possible fix in next release

20

I too have noticed non-uniform divisions on the horizontal axis. I am on Android. Unfortunately I cannot provide better details because my project only runs in the summer and I do not have access to it right now.

1 Like