Trouble with Particle.variable() and Particle.publish

yes the serial values are correct

I know a publish must be a char but Particle.variable can be a int right? I just commented out the Particle.publish so I can concentrate on the Particle.variable dsTmp when it shows gives correct values however it doesn’t show on the console as of now

What does this function do?

sprintf(szInfo, “%2.2f”, fahrenheit);

it is from the DS18b20 library I looked at the library and can’t figure out what it does?


That converts the double value to a char*, which is what you need to do to publish. You should Google it, there are plenty of good C and C++ references on the web.


I noticed this line inside setup(). That’s wrong. STARTUP() macros need to be outside of any function - preferable as far up the top of you code as possible (e.g. 1st line).

Just to make sure your code will also run when you’re not connecting a serial monitor add a timout to your Serial.available() loop

// change
// while(!Serial.available()) SPARK_WLAN_Loop();
// to
  // wait for serial input but max 10 seconds
  while (!Serial.available() && millis() < 10000) Particle.process();
1 Like


I put the startup command inside setup because the reference told me to

WiFi.selectAntenna() selects one of three antenna modes on your Photon or P1. It takes one argument: ANT_AUTO, ANT_INTERNAL or ANT_EXTERNAL. WiFi.selectAntenna() must be used inside another function like STARTUP(), setup(), or loop() to compile.

I am going to start over with a working example and add stuff til it breaks.

the sprintf will come in handy!

thanks steve

the more I look at it I suspect the WiFi.selectAntenna() is already inside Startup. ahh

Yup, the docs say WiFi.selectAntenna() should be inside a function but I was refering to STARTUP() which should not :wink:

ok I figured it out there was a line waiting for a serial signal to start

while(!Serial.available()) SPARK_WLAN_Loop();

no signal …no start

That’s what I meant with

But since you earlier said your serial output came through, and that only can happen when the “wait for serial input” had been passed, there “must” have been other things at play too.

Scruffr, thanks in case you hadnt noticed sometimes it taked a bit for things to sink in. Your comment was what prompted me to look back in that direction. thanks to all