Particle.variable not printing

Hi Folks

Just wanting to share an odd thing that my E-Series device was doing when I was trying to use Particle.variable.

I have had several variables exposed and working fine for some time, I also have the same variables being spat out the serial port when I’m datalogging, all good, all the time.

Added another last night and it would not work with particle.variable but it was being sent out the serial port just fine. When I tried to retrieve the variable thru the console all I got back was the “STX” ASCII code (essentially just 3) in the console display, I could not display the string value (an integer) that was perfectly happy coming out of the serial port. Finally fixed it this morning by changing the variable name by removing a space in the string name.

I went from this…
Particle.variable(“RADAR (mm)”, Str_Raw_RADAR);

Particle.variable(“RADAR(mm)”, Str_Raw_RADAR);

and the problem went away.

there is nothing in the documentation about this and a space is a perfectly valid thing to have in a string anyway “Hello World” anyone…?

I like the particle products but Jeez I wish they had better documentation…though this I more of a bug to be honest

cheers :slight_smile:

Are you sure it’s not documented?

Hi ScruffR

I have 7 variables in total, no name is more than 9 characters now, the previous longest was 10 when it included the ASCII 32 space character.

I stand corrected it is in the documentation… I was standing on top of a milk vat on a rural farm as I was trying to solve my installation problem, covered in dust and spiderwebs, clearly wasn’t taking enough time to read the help page at the time…

Why do they say
Note: Only use letters, numbers, underscores and dashes in variable names. Spaces and special characters may be escaped by different tools and libraries causing unexpected results.

Clearly this means their own tools as well.


1 Like

The simplest way to illustrate the problem is that you could request a variable from your browser by typing in<yourDeviceID>/varName?access_token=<yourAccessToken>

Imagine varName was var Name?
Sure, you could write the URL as var%20Name, but then some other protocol might use different kind of escaping?
Hence the restriction was born and documented and any “what-ifs” are of little value after that.

1 Like