@community: My opinion, what are you thinking about?
there should be at least an option to keep the core running even if the cloud connection fails.
And it should be possible to start or reset firmware w/o having web access!
There are many reasons why this could happen:
-What's the use of running on battery power (or having a backup battery) if i can't move away from router ?
-What's the use of having a backup battery for data logs in RAM if everything is lost because the core reboots w/o Cloud Connection ?
-EMI problems for some seconds in rough environment
-temporary problems with the DSL/cable provider, but router is still running (especially when provider works on backbone issues or upgrades in the night f.e.)
-router down for a firmware update
-you want to move the core to another place outside your wireless LAN for logging purposes or in a vehicle but read the datalog later w/o USB cable.
Example: One scenario for me is having the core to control my heating 24/7, but it has more priority to keep the heating running w/o cloud access than to have remote control. Or even more important: It should automatically wake the heating from standby after there's no cloud access for whatever reason for some hours. Think of the fatal damage to your home and your waterlines in case there's no heating while you are out for skiing for a week because the power supply of the router failed....
I think there are a lot of scenarios that need the core keep running even the cloud connection fails. What does the community think about it ?
EDIT: Also RTC should keep running, as requested here:
Related to this… What happens when the core starts up with an initial connection to the cloud, but then leaves the wifi range? Does the program thats currently running continue to operate, or does it hang at some point when it tries to communicate with the cloud and there’s no response?
I was thinking about doing a run/bike logging application with more stats than you could get with a smartphone ap, but that might not work if the core cant leave the wifi range…
Definitely this. I’m getting lots of problems with connections to the cloud. Given my situation (home automation) It’s easier for me to just talk locally via tcp/udp and not use the cloud. Its a bit annoying that the feature that’s causing the core to constantly fail and require a reset is a feature I don’t actually need or use. So +1 from me
Thank you for this discussion, we totally agree. This is a high priority issue for us right now. The problem stems from the blocking nature of the calls to the CC3000. Our planned fix requires the firmware to do some context switching which is taking some time to implement. Zach posted about this a bit in this thread:
It will do exactly what you guess: It behaves like E.T.: it wants to phone home
That's the reason why I started this thread, this behaviour is not acceptable.
I just want to chime in with an explanation of why this happens.
We would absolutely prefer to have your application run regardless of the connection state; we have no intention of handicapping your code to require an internet connection. However, the code for interfacing with the CC3000 blocks, which means that when it’s attempting to re-establish a connection, nothing else can happen.
The solution is to decouple the Spark code (which handles connectivity) from the user code. This is something we’re actively working on, but it’s relatively complex, so it’ll probably be a couple of weeks before this is implemented. However it is currently one of our top priorities.
@satishgn - great news. Is it possible this will eventually grow out to general multi-threading in client code, or are there technical limitations that would make this unworkable?
It sounds like doing this in firmware means having multiple execution stacks going in memory, so without knowing more about the fine-grained implications, I think a big limiting factor is available ram.
I realize the spark team have put in a huge amount of effort into the cloud services and cloud connectivity, but for people that just want wifi without the cloud, do we still need multithreading? Without knowing the details, my gut says that multithreading wouldn’t be needed.
We’ve started talking about the trade offs between multi-threading on the core in general vs. just multi-threading the networking code on the CC3000. I think that was the big reason we went down that path, since the stock library for the CC3000 was blocking. If we could simply have a non-blocking version of that driver, then we wouldn’t need it for the stm32.
For my part I would be happy if one of my spark cores simply could act like an arduino with wifi-shield. Should have the tcp/udp funktions and run stable.
For the other core i’d like to have local cloud functions.
You can definitely do that too! Just #undef SPARK_WLAN_ENABLE, and you can write as much of the networking stack as you’d like, or you can use the Spark.connect() / disconnect() mentioned earlier. You can also change as much of the firmware as you’d like it’s here: https://github.com/spark/core-firmware .
Ive setup the local toolchain and find it much faster to use. Plus I can use the new Spark.disconnect() to disconnect from the cloud straight after setup finishes, essentially leaving you with Arduino + WiFi.
I’ve run it for a few days on a core that was getting CFOD every few hours whilst connected to the cloud and it seems to solve my issue. I was away for a few days so had it disconnected from power, just back home now and will set a test going again for a few more days and report back. So far so good though!
This is a high priority issue for us right now. The problem stems from the blocking nature of the calls to the CC3000. Our planned fix requires the firmware to do some context switching which is taking some time to implement. Zach posted about this a bit in this thread:
