The fact that the JSON works in emoncms because it isn’t really JSON is not the strongest argument for using JSON and you are not the first to discuss changing the way emoncms works so the fact it works by accident is not something we can rely on remaining “faulty”.
No there isn’t! But it is not currently an option, And size would perhaps, still provide valid reason to prefer CSV as this is the same 3 packets using the current CSV bulk upload,
[[1473023340,node,10,20,30],[1473023350,node,10,20,30],[1473023340,node,10,20,30]]
it also includes the node id which would need something like "nodename":"node", added to each of the 3 entries in your example. Size might be important if using GSM which is another area of interest for the OEM project or if buffering “en-route” as in the solution offered on the thread “Data not sending after network loss” thread.
@ 82 chars verses >400, that is a fifth of the size in terms of data allowance or disc space (or RAM?) used.
By the way a remote “GSM only” location would also be better off posting via wifi AP locally and use one GSM connection to forward data rather than multiple GSM devices. (This too is an area I intend to explore rather than tackling the proxies and firewalls at my install sites).
My intention was not (as I pointed out up front) to try and convert you to my way of thinking, nor was it to promote the use of CSV, not even to highlight or discuss the potential pitfalls of any method. I only wanted to ask that users of CSV and/or local emonhub as a local “hub” not be excluded by developing only for JSON or MQTT in such a way that it cannot be used for a wider purpose.
I have learn’t from the dozens and dozens of lengthy discussions on this that there is no winning solution and that is why I avoid trying to force anyone to change against their will, I simply ask that I/we be given the same consideration. I cannot use the methods currently being implemented, for the reasons given and ask that be considered so we can develop a flexible solution rather than force users to make changes that might not work for them.
So far it has been suggested all the sketches need changing to suit emonESP and now we are discussing changing emonhub to accept JSON and emoncms to parse JSON in a known order which looks like it will have to include a complete revamp of the emoncms api’s and in turn the way emonESP formats it’s JSON. Maybe over time all these things can happen but for now since the CSV appears to be handled by the emonESP quite well unintentionally already, couldn’t we build on that to give a full compliment of choice rather than abandoning methods that work well in favor of those that are not yet perfect?
The predominant feature of ISP over Wifi is to be able to develop, improve and deploy firmware to the devices, the main area of improvement in measuring energy use is accuracy, either through better code or by better calibration, there is little point in fine tuning a continuous sampling sketch if there is no guarantee all data will always arrive (no buffering), or that the data isn’t timestamped at source, but if/when it hits the server, or if that data is then randomly mixed with old and new data during processing.