I think the Table Widget needs a second value added as an option.
icon | name | value0
or maybe
name | value0 | value1
Even if you dont show value1, its still logged but will be hidden for reference later on.
BLYNK_WRITE(V1) {
String cmd = param[0].asStr();
if (cmd == "select") {
//row in table was selected.
int rowId = param[1].asInt();
//value0 in table was recalled.
int value0 = param[2].asInt();
//value1 in table was recalled.
int value1 = param[3].asInt();
}
}
Just my two cents on an older topic. I have found the table widget to be very useful for easily logging sparse and intermittent data sets. As @tjohansen mentioned, it has some advantages over the history graph in certain applications. In my use case, it has been handy for logging and subsequent troubleshooting of relatively infrequent events. I worked up a cryptic set of compact status codes and concatenated them together with the uptime. This helped me isolate an intermittent problem with a connected sensor that turned out to just need a periodic reset.
I just tried out the table for logging results of a day.
Its ok for that, but comes with some sacrifices:
It can only hold 100 posts
it resets when power off
there are not much control of formats like the labeled value field
I wanted to log two/three results in one post/line
In a perfect scenario, I could log date, and value1 and value2, because I want to log the date, the min/max temp of the day and the khw use of my heatpump.
At the moment I can only log min/max as on post and a second post with my kwh.
In my graphs I reset a variable every night for the temps.
My screens, sorry they are in danish.
And the graphs going crazy is power offs and testing.
Two posts per day, one with the kwh use and one withthe min/max temp, and the funny thing is that no matter how wide I make the table it cuts off the values to the right.
the Yellow numbers in the buttom is just testing a bmp180.
Thanks for the update. Beautiful work, thanks for sharing it.
My use case was much simpler, but I ran into the same limitations. In my case, I have a capacitative moisture sensor that delivers an analog value to a pin on my arduino yun. I am trying to save power, so do not want the sensor powered except when reading it. However, since the sensor is capacitative, not resistive, it needs time for the charge to build. I needed to empirically determine the minimum amount of time needed to turn on the digital pin that provides the power before taking a reading under a variety of soil moisture conditions.
Because of this, I only needed the table to work during my calibration tests, not log for long sessions. I agree that this widget has huge potential and needs just a few limitations removed to achieve it. I have also found the terminal widget useful for querying variable states but the table widget requires much less coding that distracts from the main task.