fronius-json-tools: A Bare-Bones Python Toolkit for the Fronius Solar API

What This Project Actually Solves

The project does not claim to be a library with a clean API. It is a set of tools with a stated goal: fetch all available live data from the datalogger on a cron schedule, store it in SQLite, import archive data the same way, and generate graphs. The target user is someone who wants their own historical record of solar production, battery state, and grid interaction, independent of Fronius's own portal. The README lists an iOS app and today widget as goals, but those are not in the repository. What exists is the Python side: data collection, storage, and graphing. That distinction matters. You get the backend, not the frontend.

The Data Flow: From Datalogger to SQLite to Graphs

One notable detail in the README's notes on data is that PowerFlowRealtimeData is faster than the other endpoints because it uses fcgi, not cgi. It also summarises the most important data. That is a practical hint for anyone building a polling loop: prefer that endpoint for live updates, and use the others for deeper detail. The relationship between InverterRealtimeData and PowerFlowRealtimeData is also spelled out: PAC equals the absolute value of P_Load plus P_Grid. That kind of formula is exactly what you need when you are writing your own parsing code and the API docs are thin. The project is not just a scraper; it is an attempt to document the API's semantics through code and notes.

Getting It Running: What the README Does and Does Not Tell You

The lack of setup documentation is a genuine barrier. The scripts are described as incomplete, so you cannot assume they will run without modification. A practical first step is to run the API calls manually in a browser or with curl to see the JSON structure, then compare it with what the scripts expect. The README's changelog of API versions is your best guide for what fields to expect. Without that, you would be guessing. The project's value is not in the code you can run immediately; it is in the map of the API that the code and notes provide.

The API Changelog Is the Hidden Gem

This changelog is not a formal document; it is one user's observations. But it is concrete and specific, and it tells you what to check when your script starts returning nulls or missing keys. For example, the note that PowerFlowRealtimeData returns P_Akku and P_PV as 'null' when the inverter is in standby, but '0' when only the battery is in standby, is a subtle distinction that affects how you handle missing values in your database. If you write a script that treats null and 0 the same, you will misreport battery behaviour. This kind of detail is why the project exists. The author wrote these tools to understand the API, and the notes are the documentation that Fronius does not provide.

Limitations and Failure Modes

The wrong tool for this job would be a production monitoring system for a commercial solar installation. There is no error handling described, no retry logic, no logging strategy, and no alerting. If the datalogger is unreachable, the cron script will fail however it fails, and you will have to notice. For a hobbyist or a homeowner who wants to learn the API and build a personal dashboard, the limitations are acceptable. For a business that needs reliable uptime, this is a starting point, not a solution.

Alternatives and How They Differ

A more modern alternative would be to use a time-series database like InfluxDB instead of SQLite, and a graphing tool like Grafana instead of matplotlib. The README does not mention any of those, so the project is tied to SQLite and whatever graphing library the scripts use. If you want to scale to years of 5-minute data, SQLite can handle it, but it will not give you the built-in downsampling and retention policies that InfluxDB offers. That is a design choice, not a flaw, but it is a difference to consider before adopting the project. The author's goal was to fit his own needs, not to build a general-purpose platform.

Maintenance and Licence Implications

The licence also means you can take the API changelog notes and turn them into your own documentation, which is a practical way to benefit from this project without depending on its code. The MIT licence does not require you to contribute back, but if you do make improvements, the author would likely appreciate a pull request. That is the nature of a personal project on GitHub. The maintenance cost is not zero, but the licence gives you the freedom to make it whatever you need.

Editorial conclusion

Adopt this project if you own a Fronius datalogger, write Python, and need a head start on fetching live and archive data into SQLite without building everything from scratch. Do not adopt it if you expect a maintained, documented library with tests and packaging. Verify first that the API version on your datalogger matches the documented changes, and be prepared to fill in the missing setup instructions and incomplete scripts yourself. The project's real value is the changelog of API fields, which saves you from discovering breaking changes the hard way.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases