Should the Spark be able to communicate directly to a local server on the same LAN? e.g., setup A directs traffic on the Spark to a public url server on port 80, which works fine. Setup B has my local server IP, which will not work. I’ve moved the Spark to a WAN connection, and setup my local server with a public url, and it works fine. Trying to determine if all traffic from the Spark goes back to the public Spark Cloud (thus server directed traffic can only reach public facing IP’s / url’s). Should it be able to reach a LAN server with a private IP on the same network? Not sure if my router is blocking traffic?? Thanks for any input. -Cheers.
Are you trying to use a Local 
?
If that’s what you want to do, the core will talk to you server directly without going through the Spark
Thanks! No local in place at this time.
I’m fine implementing a local spark – just trying to determine if I need to?
It sounds like all communication routes back to the Spark before going to a server?
So, if a Spark core is configured to talk with a local server (192.168.x.x) address, then it can’t access it if it’s setup to work only with the Spark , correct?
@h2ogood, some clarification is needed here. If you are doing direct TCP/UDP communications with a local server, it will NOT go through the cloud. If you are using cloud functionality like Spark.publish, Spark.subscribe, etc. then the Core MUST connect to either a local cloud server or to the Spark Cloud servers.
So when you say “communicate directly”, this assumes TCP or UDP type communications. If both the Core and your server are on the same subnet, then they should be able to “see” each other. Perhaps a better description of your LAN/WAN configuration is in order so we can better understand your routing. 
3 Likes
Thanks @peekay123 !
Ha! I once described troubleshooting as customers providing as little information as possible while expecting a complete solution (which turns into detective work more than anything else). Sorry about that - I’ll try to elaborate (although I think you’ve answered my question).
So, I simply programmed the Spark with Lumiere Code while replacing lines 30-33 from:
// Host of server
#define API_HOST "lumiere.lighting"
// Port of server
#define API_PORT 80
to:
// Host of server
#define API_HOST "192.168.x.x"
// Port of server
#define API_PORT 3030
where “.x.x” is my local meteor server running Lumiere.
I can access the local server fine from other computers on my LAN.
However, the Spark does not seem to be communicating with my server.
So, I tried moving the Spark to a WAN environment (outside of my LAN), opened up my server with a public URL on port 80 (so that anything could connect from the WAN environment), and all works fine. I’m still scratching my head trying to figure out why the Spark can’t reach my server when on the LAN.
Works when I have:
// Host of server
#define API_HOST "dnsname.com"
// Port of server
#define API_PORT 80
Something isn’t right - not sure what though? 
@h2ogood, I’ll have to verify this but I suspect the problem lies with API_HOST being defined as a DNS name versus an IP. The HTTPClient library may be expecting a DNS name instead of an IP. Can you ping your local server by name or just by IP?
Hi @peekay123
You are correct that an IP address in a char array like “192.168.0.1” does not get handled properly by the DNS client on the TI part.
You can convert to IPAddress(192,168,0,1) or “www.somehost.com”.
2 Likes
Ah, that must be it @bko / @peekay123 … stinking variables (sorry - I keep resisting the programming part, but am slowly giving in and learning). I will work on converting the API_HOST variable to accept an IP, or fiddling with it to change things out. Makes sense now - thanks again for your patience and help! My end goal is to have a local server to control my LED lights in the 3 season porch - so I’ll be pre-wired for holiday light colors via just a change of color. One step at a time. -Cheers.
3 Likes
AFAIK there is a dedicated IP field in the HTTPClient.h types for this.
1 Like
Sorry to resurrect some old posts, but I really like closure.
Thanks (yet again) @ScruffR - overcame the IP issue quite easily with your recommendation.
For future reference / documentation purposes:
// Host of server
// I will change API_HOST to ip since ip is defined in HttpClient library and my host/server is on the local LAN and no dns name is being used locally - actually my stinking router won't do a NAT hairpin, but that's another story
//#define API_HOST "www.dnsnamehere.com"
// Be sure to change any reference of API_HOST to ip - only found one where it defines the variable
#define ip "192.168.##.##"
Working great!