# Functionality with no internet connection present

**URL:** <https://community.particle.io/t/functionality-with-no-internet-connection-present/2209>\
**Category:** Cloud\
**Created:** [January 19, 2014, 9:05pm UTC](https://community.particle.io/t/functionality-with-no-internet-connection-present/2209 "2014-01-19T21:05:25Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![goseese](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/goseese/32/20812_2.png) [@goseese](https://community.particle.io/u/goseese)\
**Post date:** [January 19, 2014, 9:05pm UTC](https://community.particle.io/t/functionality-with-no-internet-connection-present/2209/1 "2014-01-19T21:05:26Z")

</div>

So, what happens with the sparks when internet connectivity is gone.

Lets say I have activated and claimed my core and it’s monitoring a simple Temp sensor and controlling a DO.

I understand with normal internet connectivity I would be able to see the core AI reading of the temp sensor and control the DO.

What happens if the internet connection to my WiFi router goes down for some reason? The core will still have a WiFi connection to the router, but no path to the cloud. If my smart phone is on the same LAN WiFi SSID as the core will I still be able to see/control the core directly?

If this is covered in docs someplace that I missed just point me to them.

---

<div class="post-metadata">

**Author:** ![goseese](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/goseese/32/20812_2.png) [@goseese](https://community.particle.io/u/goseese)\
**Post date:** [January 19, 2014, 9:44pm UTC](https://community.particle.io/t/functionality-with-no-internet-connection-present/2209/2 "2014-01-19T21:44:09Z")

</div>

Looks like I found the answer to my question. I needed to be searching for "cloud" not WiFi

> **[Core should keep running or be able to start even w/o Cloud access](https://community.particle.io/t/core-should-keep-running-or-be-able-to-start-even-w-o-cloud-access/1167/6)**
>
> Hi All! 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...