[Request] Machine friendly live status API

[jenskueper]

Is your feature request related to a problem? Please describe.

I am running OpenDTU for a month now and the hardware and overall features are great. I started integrating it into my MQTT -> Telegraf -> Influx 2 -> Grafana stack and I am now in the process of switch to Node Red instead grafana to be more flexible. While doing so, I tried out the rest endpoint /api/livedata/status and its not really well designed for machine processing. From my experience with other APIs, consistency is a key feature.

Naming is mixed between camelCase and snake_case e.g. YieldTotal/limit_absolute. Next thing is casing. Some words start uppercase, some lowercase and some are capital letters only (INV).

Suggestion: Stick to lowercase and snake_case

Second thing is units. Units should be defined in the schema and not change dynamically since it take more effort to parse it to standard units afterwards.

Suggestion: Use the https://en.wikipedia.org/wiki/International_System_of_Units without any multiplier. The unit should also not be part of the API response but of the API definition to keep it slim and lightweight.

I can offer to open a PR for a /api/v2/livedata/status or /api/livedata/status?v=2

Keep up the good work

Describe the solution you'd like

Second version of the API with consistency and easy to process programmatically

Describe alternatives you've considered

No response

Additional context

No response

[ccoenen]

It would be very cool if it could just directly push new values to influx (without telegraf). If it could be configured to speak the influx 2 line protocol, all you would need would be an influx-server and credentials.

Here is the full API specification and here is an article from the makers of influxdb themselves: Writing Data from Arduino to InfluxDB v2 - while this is obviously not arduino, it does explain how to use the InfluxDB-Client library.

[stefan123t]

@jenskueper we are in the process of aligning both the API endpoints, the MQTT topic tree structure and content as well as for both projects OpenDTU & Ahoy. This would allow us to leverage the same data structures with both projects and their forks as well as consume them e.g. via a remote Display or a Proxy / Gateway DTU. Please take a look at #378 were we started to document the current / future API using Swagger.

@jenskueper & @ccoenen you two both have the idea to push the same / similar data structures in the form of rows with values to a remote logger / database like Telegraf / Influx2.

What would be a suitable format in which you would like to send the data to Influx2 ?

Note that Hoymiles does break down the Inverters by inputs / channels and calls each channel a port, hence a 4-in-1 or 2-in-1 inverter would report 4 or 2 ports respectively. Maybe this in mind can help to simplify the log format.

row	inv-serial	port / input channel	value_w	value_v	...
1	114175212345	0	100W	50V	....
2	114175212345	1	49W	50V	....
3	114175212345	2	51W	50V	....
4	114175298765	0	200W	60V	....

@ccoenen Can you specify a complete example of such a row / set of rows sent to Influx based on the Influx API you suggested ?

I myself would already be happy with a simple serial output line-by-line format which can be printed in the Arduino Graph/Monitor Window or saved and stored / imported as a CSV file to be analysed in LibreOffice Calc or similar Spreadsheet applications.

Note that #1123 does something along your lines, though we were considering to post it using the PATCH method to a WebDAV / Google Spreadsheet for starters, but the logformat with a single row having the data for either one inverter or multiple inverters would probably be similar and a basic requirement / thought.