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.
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.
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.
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.
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.
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.
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.
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:
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.
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…
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.
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.
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.
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.
Same case here the min/max Superchart option is not working here. I do not understand how it works perfectly in Blynk legacy and is not working in Blynk 2.0. There are many problems with changing in y-axis scaling here in the new platform… suggestion for the development team use Blynk legacy code instead… it works perfectly!!!
I had the problem with min/max being ignored but took the advice of [K_Zhou] by restarting the app and hey-presto, the chart rescales to the min/max settings I had selected. I am running on iOS 16.2.
I had the problem with min/max being ignored but took the advice of [K_Zhou] by restarting the app and hey-presto, the chart rescales to the min/max settings I had selected. I am running on iOS 16.2.
