.htaccess file to not force https

If you don't force it, don't put that line in your .htaccess files. It will by default NOT act on http or https header/protocol
You may upload your currect .htaccess file so we can judge which lines to remove for it to work.
You _could_ delete a few lines yourself, but without the whole picture, you may also totally break the site.

I need the site to force to https i DONT want the subdomain to have https

It's for development until I get an SSL

You DO know you used two definitions now, so I don't know which one you want?
A subdomain is NOT the same as subfolders.

Also, why wait for SSL, when you can get one for free within 5 minutes?

the .htaccess forces https.  I do not want to force http on subdomains.  I want the subdomains to be able to be http so I don't get the warnings

BEFORE your RewriteRule

RewriteCond %{HTTP_HOST} !=/(.*?)/.yourdomain.com

Select allOpen in new window

The LetsEncrypt cert that I have forces HTTPS on everything from my web root on down including folders and sub-domains that are not otherwise related to the main domain.

Can you do this? Maybe. Depends on if HSTS is running on domain, if it is, then no.

Better question is why are you trying to do this, as there's likely a far better approach.

Many Browsers block HTTP as suspicious sites now (because they are) + shortly all Browsers will do this...

This means you'll only run HTTP on sites with no visitors... so it's unclear what benefit this might provide...

So describe clearly what exact problem you're trying to solve.

Also, provide the host/domain of your site to determine if this is possible, based on your TLS config.

I suspect the reason is that the sub-domains have hard coded 'http://' links that are causing an error message to show and he either needs time or can't clean them up.

I'm not following the problem, I guess.  If we have the domain

mydomain.whatever

with subdomains of

www.mydomain.whatever (alias of mydomain.whatever)
otherserver.mydomain.whatever
yetanother.mydomain.whatever

each subdomain should have its own server instance so that what fails on one won't corrupt the others.  This I/M/O is just good practice.  Further, insecure and secure servers can also be started as separate instances.  In fact browsers should be encouraged to use HTTPS by including the proper headers such as

Content-Security-Policy: upgrade-insecure-requests

There are also unexpected and sometimes obscure issues, e.g., losing cookies, when browsers downgrade a session from secure HTTP to insecure HTTP on the same site, especially so under HTTP 2.0 where enormous amounts of data can go in one request.

If the issue is the lack of an SSL certificate, go to Let's Encrypt, download the free package to do SSL maintenance on whatever system is in use and go SSL.  This is the proper solution and if it hasn't been done it should be done now because (as per supra) browsers are becoming less and less tolerant of non-secure sites.

HSTS Aside: Remember if HSTS is set, then no subdirectory can every serve as HTTP... as all Browsers in existence will reject the HTTP connection type as a potential hack attempt.

Also Dr. Klahn brings up a consideration I hadn't thought about either.

Best if you provide your actual Website URL for testing to determine if what you're asking is even possible.

On all of my shared hosting accounts, secondary domains are just a folder under my primary domain.  Let'sEncrypt will provide HTTPS for the entire folder structure including the secondary domains.  I think this may be what the asker is seeing.

For example, on my primary domain / website, I have 8 other domains/websites in folders under my primary domain's 'public_html'.  Let'sEncrypt covers them all with HTTPS connections.

The current issue is, I just don't want to see the errors.  The SSL the client purchased from Network Solutions does not cover sub-domains and the ones that do are expensive, so the client does not want to incur that cost right now.  I just want to work on the new site without the error.  SOOOO, I am trying to implement a temporary work around

Start by providing a URL for testing.

Better to test + know, than guess.