16 bytes: anologRead() outputs unsigned integers between 0 and 1023
1023,1023\0\0 = 13 UTF-8 string bytes. Note, Sprintf() should add it's own null (\0) but for some unknown reason that can go missing, so imposing another is a belt-and-braces measure. We should test without the extra \0, see below.
sSensorVals: Should not need to be cleared, but there is no harm in doing so.
%u: is a place holder for an unsigned int. That should be bullet proof but it is possible for the sensor to glitch, depending on sensor quality and the environment.
\0: Yes, that seems to be working, Muhammad has a working graph. It is technically not a delimiter but an end-of-string flag. Each value pair is streamed to the App per 1 second (Arduino timing is more accurate than Android timing).
This error text does not appear in the app, so I am going to point the finger at the Kio graph block, because it does not match any AI2 list block complaint I have ever seen before.
I assume the Kio blocks maintain their own internal lists, because their graphs extend across the Canvas and that graph block accepts two points at a time.
Regarding ABG's comments about the Sketch:
Apart from the latest App Inventor Blocks fix, here is a modified Sketch that clears the sSensorVals string before the next value is applied. Also, '\0' is removed from sprinf(). Hopefully this will be even more robust.
The error message is triggered by the wonky value passed to the extension.
I think it would be good not to use an extension as there will be no point Juan maintaining it in future, now that App Inventor has it's own charts component.
Does the App Inventor chart allow run-time updates the way Juan's does? It will still require the code to omit wonky values.
Not sure if that's the Sketch or the App - I don't understand what you mean Can you describe the latest situation again (E.aia and E.ino) with the aid of an image?