Can I make a suggestion about the interaction between the emonTx sketches and the emonESP ?
Rather than a different payload as you are trialing now, could we look to standardize the way the data leaves the AVR to a string of values that is suitable to RFM, serial-direct and emonESP alike, so that we do not have to revise every sketch and narrow the use of this great development to those that want to post direct to emoncms via single api calls or those using MQTT.
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.
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.
With the current arrangement each device will have to have it’s own reliable network connection, what happens to data produced during a network/server outage? Is it just lost? I would expect so. If a small buffer was to be introduced the “string of numbers” is easier and more compact to buffer.
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 “power1pluspower2” in the emonpi payload is an example of the only way of getting around it, Are we going to start putting all our processing in the sketches just so we can have the fixed variable names repeated in every (unseen by humans) payload?
Once the emonESP has a string of names, plus a stream of “stringed values” (maybe CSV rather than space separated is the way to go?) the handling could be really flexible. Everything you have now would still be possible PLUS users like me can post locally to emonHub via a socket (by adding a emonhub.ino?), and move towards using MQTT in the near future BUT by passing a single payload of values to emonhub and emonhub then doing it’s intended job to pass that intact string to emoncms(s) for accurate and predictable processing AND also (if desired which there is strong evidence to suggest there is) break out the values to individual MQTT topics on the LAN for other purposes eg openHAB. Merging these 2 tasks into one is the bottleneck of the current OEM ecosystem.
Also what if a user wants to send to other locations? not just emoncms(s)? yes you could put “local” and “remote” emoncms settings but even that is very restrictive.
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.