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

[jeremypoulter]

@pb66

The emonTx sketch could very easily during setup, pass a string of names to the emonESP that can be used to split the stream of data that follows off into pairs in the way you are currently focused on. That “name string” would also be very useful during serial debugging too, much like the existing sketch version etc that we currently see from an emonTX etc.

The problem with that is if the EmonESP (or what ever the other end is) starts up after the EmonTX it will miss the name string

@pb66

This would allow those of us that want (or sometimes have no choice but) to post to emonhub locally via socket to get on board too

I am not sure there is any reason why you could not use the same setup just would mean that the emonhub service would need to be updated to read the JSON like output of the EmonTX.

@pb66

There is also the issue that keeps cropping up (not related directly to emonESP) about the processing of data at emoncms and the fact that when individual data’s are sent eg MQTT or when JSON pairs are sent to emoncms you have little or no control over the order that they are processed in and that causes irregularities, in contrast sending a single CSV string ensures the processing is done in the expected order and the results are reliable.

The EmonESP posts all the values (to EmonCMS) in one request so I would assume this is no different than passing as CSV if not I would think it should not be to hard to ‘fix’ to ensure processing in the order passed. That being said I have not looked at the EmoCMS code

MQTT is a different case, I am not sure there is a way to post multiple values at the same time, EmonESP certainly posts one value at a time, but the order is very consistent and in the order they are in the string sent from the EmonTX.

You have however highlighted a potential issue in the processing of my inputs that I will need to look at

@pb66

My suggestion isn’t asking those of you that embrace posting via named value pairs or individual topics to change your habits, or convince you that any particular way is the better way, just asking you to not exclude those of us that have a different opinion and include some scope for exploring other avenues.

While I do agree with you that there does need to be some consistency I personally would like to see the move to something like (proper) JSON rather than the OEM specific strings that all the current transports use. This would make it extremely easy to say directly read the EmonTX output directly in to Node-RED for example.