I’m getting a wrong data in the charts. The wrong values were not sent by my device. I have a log in Arduino and see all data sent to Cayenne. These wrong values always appear at a round hours like 10:00 AM or 03:00 PM, etc. Look at the screenshots:
This is a very bad thing, because I may have triggers to do something on such changes, but it is wrong change!
2, What type of smoothing do you use for data? Is it possible to download original data sent to Cayenne? Not the smoothed data you show in the chart.
Do you plan to add settings for chart? Smoothing type, chart type, etc.?
I’ve wrote data sent to Cayenne to Arduino log and then use Excel to draw chart.
This is the same time range. As usual there is a unexpected spike in the Cayenne and there is no such data in actual chart.
The worst thing is that Cayenne developers does not answer to this bug report and does nothing to fix it. I wrote about this bug a couple of months ago, but noting has changed.
@bestes@rsiegel - Something about that? I also have similar bug with DHT11. I was thinking that is from the sensor, but I purchase original one month ago. Still has some peask
Sorry for late response here…I’ve had my head down working on a few things hmmm. Yes if multiple people are reporting this then likely is something that is happening on our end.
@rsiegel do you have some time to look into this so we can get into backlog? It seems was brought up before here too by @svoskar
Sure, apologies that this did not get a quicker response guys.
If you have a moment, could each of you grab the .csv file from the ‘Download Chart Data’ button on a chart where you see these spikes, and attach it to an an email to support@mydevices.com or Private Message to me along with a screenshot of the Cayenne line chart that doesn’t match the data? This will help a ton towards getting our developers some data to investigate the issue.
Tagging @svoskar to see if they can provide this as well?
April 27
Sure, apologies that this did not get a quicker response guys.
If you have a moment, could each of you grab the .csv file from the ‘Download Chart Data’ button on a chart where you see these spikes, and attach it to an an email to support@mydevices.commailto:support@mydevices.com or Private Message to me along with a screenshot of the Cayenne line chart that doesn’t match the data? This will help a ton towards getting our developers some data to investigate the issue.
Thanks, I see the matching chart and CSV data now, and I do see the drops at 2:00 each day.
Would it be possible for you to capture the Arduino IDE serial monitor output while one of these spikes are occurring? With #define CAYENNE_DEBUG uncommented, so we can see the full log? This way we can see if the low values are coming from the Sensor/Arduino to Cayenne (and we are just logging what we get), or if we’re getting different values and then corrupting them on our end somehow.
Hi, here is just example - serial monitor capture using CoolTerm (I do not know how to capture Arduino IDE serial monitor into text file). If this is sufficient, I will try to run it over night, to see critical time around 2 a.m. One thing I had to do was adding code to Serial.print value of photoresistor, as it was not in the original code, because I added photoresistor directly at widget dashboard by specifying analogpin. (so reading nor serial.print was not in original code)
here is serial monitor file: CoolTerm.txt (94.0 KB)
FYI I’m seeing the same issue. Right at the top of the hour I sometimes get erroneous data. This problem was happening a couple weeks ago and I thought it was just my sensor, then it was good for like 2 weeks. Now in the last couple days it started back up again. I’ll get my print logs for ya.
Question: “finest” time period of downloaded data is one hour. How Cayenne agregates data into reported hour? Is for example value 968 for reported 3 am average from 2:00:00 up to 2:59:59? What is the formula for time data agregation?
Thanx for your help
hmmm. Yes if multiple people are reporting this then likely is something that is happening on our end.
