Simple question on particle.variable & particle.function

Firmware
1

I hate to ask what appears to be a simple question, but since I can’t answer it for myself I figured I might as well ask the experts. Given this particle.variable example:

Particle.variable("temp", tempC);

What does the “temp” parameter represent? I know that tempC is the variable name used in code when you assign a value to the variable, and that the two parameters do not have to be identical. So, why two parameters and what does the first one represent?

Same question for particle.function:

bool success = Particle.function("funcKey", funcName);

I know funcName is the name of the function that you create, but what does “funcKey” represent?

2

That’s the name of the function/variable on the “cloud side”, so you know what you’re talking to.
In the console for example:

image

That’s also the name you need to use to call those specific functions/variables from the cloud, should you wish to reach them.

3

Thanks @Moors7, so basically it’:

(cloud name, local name)

Any best practices on naming them the same, or different? Or is it just personal preference?

4

Whatever you want to call them :slight_smile:
I personally like to make them at least somewhat descriptive so I know what I’m looking at when I see them in an overview. And I try to make them match with each other a bit. Wouldn’t make a whole lot of sense to go with Particle.variable("temp", humidity); for example.

5

Hi,
there are limitations on the length of the name of the cloud variable:

From:
https://docs.particle.io/reference/firmware/photon/#particle-variable-

Up to 20 cloud variables may be registered and each variable name is limited to a maximum of 12 characters.

So sometimes I have this internal variable called myInternalCuteVariable that I cannot map in the cloud. So the mapping allows me to have my cute internal var with that long(er than 12 chars name) but I can expose it nonetheless as cuteVar, for instance.
Cheers,
Gustavo.

2 Likes
6

Good point @gusgonnet.

7

One other thing I’d consider good practice rather than a rule: Don’t use blanks

Even when blanks are allowed (just like in path names in Windows or Linux systems) I’d avoid them wherever possible and stick to the same rules of naming them as I would name any valid C variable (although leading digits can be acceptable for filenames and directories - as exception to the “rule” :wink: )
Rather use CamelCase to stress word boundaries than split them up with blanks (or maybe even underscores).

2 Likes