Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request] Machine friendly live status API #1135

Open
jenskueper opened this issue Jul 9, 2023 · 2 comments
Open

[Request] Machine friendly live status API #1135

jenskueper opened this issue Jul 9, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@jenskueper
Copy link

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

@jenskueper jenskueper added the enhancement New feature or request label Jul 9, 2023
@ccoenen
Copy link

ccoenen commented Sep 18, 2023

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
Copy link
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants