During testing of my firmware yesterday, I encountered the following error:
Function myverylongfunction name not found
Of course, I studied my C code for a while looking for the problem to no avail. I could not find the problem.
I have three functions in my app, so I thought for some reason the Photon was limited in how many functions you could have (turns out the limit is 10). To test this theory, I reordered the functions to see if the one I was having trouble with would work if it was higher in the list.
Nope, that wasn’t it.I noticed that the function that wasn’t working had a name longer than the rest, so I shortened it and suddenly it started working. If you encounter this issue, know that the maximum function name length is 12 characters.
What I don’t understand is why this is even an error I had to figure out. The Particle Cloud is parsing the request and looking for a function that matches the name I’ve provided on the URL. If the function name is longer than 12 characters, then tell me that I’ve passed a function name that’s too long. Don’t tell me you can’t find the function. I knew I was providing the right function name, the one that matched my code, but the Particle Cloud couldn’t recognize it because it’s too long - that’s the perfect time for an error message back from the service that reads something like “The function name is too long.” That, for sure, would have shortened my troubleshooting time.
The short answer is that there is a table in your device that remembers all the function and variable names and that table takes precious RAM so that Particle engineers put a limit on name length.
The error occurs when you register the over-long name on the Photon–the cloud does not even know that such a name exists since the Photon never registers it with the cloud.
This is what happens today--I don't know why folks don't check the return value. Here is sample code from the doc for variables that mentions the limit and shows how to check it. It would be the same for functions.
// variable name max length is 12 characters long
Particle.variable("analogvalue", analogvalue);
Particle.variable("temp", tempC);
if (Particle.variable("mess", message)==false)
{
// variable not registered!
}
Lets improve the example to show the specific case of functions - that example is for variables, it would be easy to miss if you were just researching functions.
I know, I’ve seen the documentation and I understand the reason for the limit. You’re missing my point - The function not found error response is not indicative of the actual problem. In my case, my cloud URL exactly matched the function name in the code, so in my eyes it was correct. The cloud should deal better with this error, return a function name too long error so I know of the error and can quickly fix it.
I don’t want the cloud truncating it, because that could create a conflict with two 13 character (or longer) functions with the first 12 characters the same mystupidfunction1 and mystupidfunction2 for example would cause an inability to tell which function is being called.
I just tested this out in prep to update the docs, and I see that if you go over 12 chars for variables or functions it’s not truncated and registered… it’s just not registered at all.
electron7 [1234123412341234] (Electron) is online
Variables:
yourvariable (int32)
Functions:
int digitalread(String args)
Modified Tinker Code
int myvariable = 10;
void setup()
{
//Register all the Tinker functions
Particle.function("digitalread", tinkerDigitalRead);
Particle.function("digitalwrite12345", tinkerDigitalWrite);
Particle.function("analogread12345", tinkerAnalogRead);
Particle.function("analogwrite12345", tinkerAnalogWrite);
Particle.variable("myvariable12345", myvariable);
Particle.variable("yourvariable", myvariable);
}
From the CLI will show your devices and any registered functions they have. I understand your statement that the cloud should just tell you “that’s wrong” but it is well documented, easy to check from nearly every tool and expecting the Particle team to inspect the length of a portion of an API call on the “in-case” someone missed all the signs pointing to “don’t do that” is what I categorize as a VERY nice to have. Particle.function returns a user defined integer and I would argue that the error message received was exactly the correct message…the function you were calling wasn’t registered be it valid or invalid it didn’t exist to the Particle Cloud.
OK, so if I understand you correctly, what you’re proposing is that everything works - but ONLY if the developer reads every aspect of the docs and thoroughly works through every possible issue before submitting their code. Um, no, that makes no sense to me.
It’s input validation. If Particle knows there’s a limit, check it. then report if the code is not within compliance. It’s the minimum that’s expected of any developer who exposes an API or processes user input. No other vendor out there simply tosses out generic errors if input parameters are exceeded, it checks then warns.
Actually, the more I think about it - it’s actually the compiler (the code verification process) that should be catching this. The code is verified before published to the device, you’d think it would be MVP to check that there are not too many functions/variables and that the names are not too long.
What’s interesting is that ALL of us have done more work to say this isn’t necessary and me to defend that it’s MVP than it would have taken to implement this in the cloud. It’s three lines of code that I can think of and you’ve written paragraphs here against it.
If (length(functionName) > maxFunctionNameLength) {
Return “Function name exceeds maximum length limits”
}
That’s it, we’re done. Do we really need to argue this or can someone look at implementing it? It’s no big deal for me as I’ know now what the limit is. I apparently knew about the limit but forgot about it. I’m asking for this to help any beginning Particle developer in the future - it simply makes sense to help them solve problems more efficiently by simply providing a more accurate error message.
Just to be brief and not write paragraphs: Particle.function() returns an int not a String so if you checked for the returned int you'd have had the indication that something's wrong. Other standard C functions use return int codes a dev should check. Not all can be done at compile time (imagine a user-input string as function name). After the error has been made in firmware the cloud side has no way to give you any other info than "Not found" - since the function never was exposed.
Well, you don't have to read documentation, but then you might run into things that could've been prevented had you done so. I personally find it rather amusing to see that people are both complaining that the docs aren't good enough, but when things have been documented for ages, it's suddenly a strange thing to read them?
As far as implementing things goes, there's no way to do that on the Cloud side, because it never got that far in the first place. Then again, that's been explained often enough now
You are in luck! There is an Open Source version of the Particle cloud server. I can’t say for sure that the code in this version matches the hosted version most people use but since you feel so strongly about this and have a solution I would encourage you to submit a PR with your fix, maybe they will implement it in the hosted version as well. This is a community contributed platform, many people submit bug fixes or tweaks they feel are useful to others so if you aren’t willing to contribute to the fix please be willing to accept the API as it is with a respectful request for improvement in the future.
Let’s all remember the cloud service is free and I am willing to bet represents a significant monthly spend for Particle but that aside you are left with (3) options at this point:
Accept it
Fix It in OpenSource Spark-Server and submit a PR requesting review/implementation in the cloud version
Fix It and run it privately on your own Spark-Server instance
Not many vendors could offer so many wonderful options to a user!
I don’t agree that there’s no way to do it in the cloud. Simply check the length of the function name that comes through. If it’s more than 12 characters, return an error. I can’t believe so much argument is being made about something that’s so very, very simple. If the limit is ever increased, change the limit in the cloud check function and it’s suddenly compatible.
All I’m trying to do is suggest a way to make this more seamless for developers. I really don’t appreciate the “this is costing Particle money, so you’d better like it or accept it.” I’m trying to help, I’m trying to share my experiences in an effort to make it easier for others to come up to speed on this. Thanks for making me feel like my suggestion is stupid.
What do you expect your filesystem to tell you, when you ask it to
cd /thisDoesNotExistNoMatterHowLongThisIs
Do you expecti it to return, “This is no allowed directory” or “Not found”?
There might be multiple reasons for the function name not existing, but “Not found” is definetly true, no matter why.
If you want to find out why, go to the root!
If you refer to the URL path, this will be well-formed even with a long function name, but the “path” does just not exist.
