I have a bunch of cores with variables that all work–I think your problem must be something silly we have overlooked. I asked for you remove the TCP Client code since I thought it would be good to isolate things. I don’t think you have a faulty core–that has been both rare and obvious when it happens. I wasn’t sure what you were trying to do with your GET request since after the blank line you continue to send temperature data. Your own server might know what to do with that but a regular web server would not.
The doc is here and has improved greatly in recent weeks, but the examples are simple, toy examples that don’t check return values for errors etc. so they are not production ready examples. The examples meant to be easy to understand, not show you every single detail you need.
So what does the USB serial port print for TempC? Is it longer than 10 chars? That could still be the problem if sprintf is clobbering memory.
Any red flashing on the main LED? That indicates a problem–the doc has the codes.
Maybe @Dave can check the build log for your core device id and see if anything funny is going on.
Thanks. Serial port gets perfect temp. I commented the TCP Client (is it different than removing?) so those lines aren’t even part of the compiled code.
28.652012
28.652012
28.652012
28.732598
28.652012
28.732598
28.652012
28.652012
28.732598
28.732598
28.652012
28.652012
28.571427
Ah okay, I’m seeing the problem now, you have a 10 second delay before you declare your Spark.variables, so if you make any request before that, they won’t be seen as ‘registered’ yet. We also added a workaround recently for deep_update that asks the core if it has any variables / functions to declare shortly after starting up, so if you block for that long in your setup before declaring them, then they won’t be seen. If you move your Spark.variable lines before your delay(10000), then it’ll work.
Sorry about any confusion that caused! People weren’t aware of that temporary change because it was added recently to help perform deep updates on cores with much older firmware. That would still happen if you were polling for your variable before your delay had finished, since your variables wouldn’t have been registered in your firmware yet.
