I have came across this and it took me a while to understand what's going on so sharing it here in a hope that it will be useful and may get fixed in the next firmware.
If my application tries to register 2 cloud functions where one has a key that is part of the other such as this for example:
Particle.function("measure", measure);
Particle.function("measureBlack", measureBlack);
This then completely messes up the registered cloud functions and variables so when my Photon is queried is shows zero variables and functions registered. A workaround is to always use keys that are not part of one another (below for example) but that is not ideal:
Particle.function("measure", measure);
Particle.function("measBlack", measureBlack);
@AlexeyDanilchenko That’s interesting. I have “led led2 led3 led5 led6” registered on the same device, and everything works like it should. Maybe it’s because of the way you query functions.
You can try to use the new Functions UI available in Console, just click on a device and it should expand. Does it still happen in there?
2 Likes
you may have some other problem…
void setup()
{
Particle.function("measure", measure);
Particle.function("measureBlack", measureBlack);
}
void loop() {
}
int measure(String command)
{
return 0;
}
int measureBlack(String command)
{
return 1;
}
As I said - when I register functions as in my example - I cannot see neither functions nor variables. It has nothing to do with querying them - querying the device itself returns 0 functions registered.
In my example one of them goes to max length of 12 characters - not sure if that is something to do with it.
I’d be curious to know what that is - I am on 0.6.1 and spend the whole evening yesterday. I was not using the console but getting the device info back via say curl and the functions were not there…
maybe your cURL command was wrong? or maybe post your code so we can see.
Usually if you go over the 12 character name limit, you would get a (albeit obscure) compilation error.
EDIT: I'm wrong... it has been magically de-obfuscated recently!
In file included from ../wiring/inc/spark_wiring.h:47:0,
from ./inc/application.h:36,
from new.cpp:1:
../wiring/inc/spark_wiring_cloud.h: In instantiation of 'static bool CloudClass::function(const T&, Types ...) [with T = char [16]; Types = {int (*)(String)}]':
new.cpp:4:54: required from here
../wiring/inc/spark_wiring_cloud.h:190:9: error: static assertion failed:
In Particle.function, name must be 12 characters or less
static_assert(!IsStringLiteral(name) || sizeof(name) <= USER_FUNC_KEY_LENGTH + 1,
^
make[1]: *** [../build/target/user/platform-6new.o] Error 1
make: *** [user] Error 2
I guess it has been quite a while since I made that mistake! 
2 Likes
Hmm, tried to recompile and upload just now changing function key back how it was yesterday and it is working. Edited the file some more (comments and upped internal buffer size that has no relation to variables/functions), recompiled and it stopped working again. Looking at the console or my app - same.
That is quite peculiar - I do however run Photon in manual mode using this
> if (!Particle.connected())
> Particle.connect();
> Particle.process();
both at the end of the setup() and in loop(). Could this be a problem?
Particle.process() needs to be called regularly with SYSTEM_MODE(MANUAL), but Particle.connect() should only be called sparingly to prevent one connection attempt to interfere with a previous one.
Posting your full code may also reveal other places for improvement.
I call Particle.connect() only if its not connected - isn’t itr a blocking call that returns only after it has been connected?
I cannot post the sources publically just yet - sorry.
I will however experiment further and see if I can find out some regularities in all this. For now it seems to be working.
Nope, it’s not a blocking call.
If you want to block indefinetly till you are connected again, you should use waitUntil(Particle.connected)
