Just an FYI this code is great but XIVELY wont report data accurately unless you alter it slightly.
if (millis()-LastUpTime>1000)
That is to fast for Xively to properly GRAPH the data. So your method will report the data to Xively but it is to fast to graph it. For those who want to use Xively’s graphing tools change 1000 to 5000. Perhaps I am the only one who uses graphing in Xively but wanted to share in case it might help another.
You guys should check out www.Ubidots.com its way better than Xivley . I’ve tried both.
Check out this thread where I used it recently http://community.spark.io/t/melexis-contact-less-infrared-sensor-code-port/7091/6
Thanks @rwb for sharing I am definitely going to check it out. Looks like they have a far superior data layout.
@Herner here is the setup guide for the Spark Core + Ubidots. Its what I used to get started.
Hi @Herner
You might find this example useful as well: Logging temperature and humidity using the Spark Core + Ubidots.
Feel free to ping us if you have any questions, or create a topic in our community portal.
This is an old discussion, but may still be a good resource for people, so I am commenting. The part of the code where it checks current millis() vs the LastUpTime should fail when millis() exceeds the max value that can be stored as an unsigned long This is a big number but is really 4294967295 milliseconds, which equals less than 50 days. On the Arduino you can use a casting like this to avoid the rollover problem:
if ((unsigned long)(currentMillis - previousMillis) >= interval
But I am not sure if this syntax also works with Spark.IO…!
On the Spar Core millis() does return unsigned long and you should use the same type for any variable that should receive its value anyhow, so casting should not be required ([ulong] - [ulong] = [ulong]).
I am not sure it is necessary, but this was to account for rollover.
For example, if you were storing millis() and previousMillis() as 8-bit numbers, when you got past 255, the values would wrap around. So 258-254 would not be 4, but rather -252, and thus not greater than the threshold.
Exactly!
And to tak up your example you can either have an 8bit unsigned number which ranges from 0 to 255 an will wrap over to 0 again with no negative value possible or you hav an signed 8bit which ranges 0…+127…-128…-1…0.
This now taken for a unsigned 32bit number - as millis() and related variables - you get 0…(2^32-1) with no possibility for negative results.
In other words [unsigned] - [unsigned] can never result in a negative number (unless you overrule the automatic type resolution of the compiler).
Addition: In your example above, you would never have 258 - 254, since 8 bit only goes to 255. So you’d rather have 2 - 254 which would not result in -252 but 4
Hi, do you know if your code still works with xively ?
I am not able to record any datastream as I did years ago.
What’s changed ?
Thank You