Could emonESP also support CSV and post to a local emonHub?

I’m inclined to agree with you based on the fact the processing order has been more of an issue since MQTT was on the scene, previously there were not that many complaints despite the length of time that method has been in service and the number of users.

My comments regards JSON being unordered was not based on the inner workings of emoncms but the results I have had with “proper” JSON in other situations. hence my comment about emoncms working correctly due to it not being true JSON but more like CSV in JSON format (as per the bulk api).

It is good hear confirmation that the api processes current “JSON” in order and that if changes are made proper JSON can also be configured to force an order.

So both the CSV and JSON (maybe we should just stick to indexed and named as neither is fully JSON or CSV) methods are currently functioning correctly, great!

However they are still not interchangeable. and the reason behind that is the CSV “index” and JSON “name” being the same field, see my screenclip from the inputs page. you could not put the values of “CT1” “CT2” “T1” etc into the bulk (CSV) upload and post to the same inputs, it creates new inputs “1” “2” & “3” etc as you can see.

The only way for the 2 methods (named vs indexed) to be made interchangeable without breaking backwards compatibility for one or the other, is to add another field to the input schema and have both an index and a name, which in turn would give you an easier and configurable processing order, negating the need for any special ordered JSON.

I have been suggesting/asking for the adoption of an “index” field for a very long time! currently both the “name” and “description” fields are taken as different things in each case. When bulk uploading or using CSV ie un-named data then the “name field” is actually holding the “key” and the “description field” holds the “name”. but with named inputs the “name field” holds the “name” and a “description” goes in the “description field”.

In the inputs page though, what you see labelled as “Key” ids the “name field” and the “Name” is actually the “description field”.

The lack of a true index field means users must chose their method and stick to it, no interchanging.

(I think the JSON discussion needs splitting out to another thread, I will do it later this evening)

1 Like