emoncms.org input names can now be alpha-numeric bringing this part of the API in-line with emoncms on the emonpi/emonbase. E.g:
Node names need to be 16 characters or less long and can contain a space, - (dash) and . (full stop). Examples of valid nodenames are: 10, emontx, emontx10, emonth-19, mynode.1, “mynode 2”
There is a limit of 32 nodes per user on emoncms.org, this was previously restricted by only allowing node id’s between 0 and 31, it is now based on the number of nodes regardless of their names. so a node with nodeid 100 is possible or emontx123.
This removes the need to set the node name to 0 on emonesp nodes, documentation has been updated accordingly: GitHub - openenergymonitor/EmonESP: ESP8266 WIFI serial to emoncms link and Using the emonTx v3 with the ESP8266 Huzzah WIFI module - Guide | OpenEnergyMonitor
Emoncms.org API Error messages
Input post errors:
- Error: invalid node name - returned if node name given contains any characters that are not a-z, A-Z, 0-9, dash, full stop or space.
- Error: node name must be 16 characters or less
- Error: Request contains no data via csv, json or data tag
- Error: Format error, json key missing or invalid character - eg if json=power1:100,:200 - the second input has an empty key.
- Error: input name must be 64 characters or less
Input bulk errors:
- Error: Format error, json string supplied is not valid - failure to decode json string with php json_decode.
- Error: Format error, last item in bulk data does not contain any data - bulk data upload requires at least one entry e.g: input/bulk.json?data=[[0,16,1137]]
The above error messages do not yet cover all possible errors in input, certain input errors cannot be caught at the stage where the inputs are received as the inputs are placed in a processing queue with minimal checking in order to free up the apache2 instance as fast as possible.
Node name errors are yet flagged by the input/bulk api in the event that most of the nodes in the bulk upload are valid. The above is a starting point to be improved further, while attempting to be as carefull as possible not to break existing posting of data to emoncms.org.
When emoncms was first developed I added the requirement to add .json to the end of API requests to signal the requirement for a result in json format with the idea that the API might return results in a variety of formats: e.g: json, csv, xml. This was never really developed and instead we have examples of API calls with .json returning json, text and csv data and so its not technically correct to require the .json extension.
Rather than have the user define the response format where alternative response formats are not implemented the input API now returns a result in the format that makes sense for each API call. Which means:
now works, usually returning ok, in plain/text mime type.
still works for backwards compatibility. This change will be made available on the main branch of emoncms soon as well.