--- title: '003. AP Systems Solar Panel Metrics to Self-Hosted Influx' url: 'https://prozak.org/003-ap-systems-solar-panel-metrics-to-self-hosted-influx' markdown: 'https://prozak.org/003-ap-systems-solar-panel-metrics-to-self-hosted-influx.md' date: '2024-02-25' description: 'A walkthrough on how to extract solar energy data from AP Systems inverters and push it into a self-hosted InfluxDB instance for personal monitoring and analysis' taxonomy: category: - self-hosting tag: - self-hosting - influxdb archives_month: - feb_2024 archives_year: - '2024' --- # 003. AP Systems Solar Panel Metrics to Self-Hosted Influx [ Blog Posts ](https://prozak.org/) 003. AP Systems Solar Panel Metrics to Self-Hosted Influx 25 *Feb* #### [003. AP Systems Solar Panel Metrics to Self-Hosted Influx](https://prozak.org/003-ap-systems-solar-panel-metrics-to-self-hosted-influx) [self-hosting](https://prozak.org/tag:self-hosting) [influxdb](https://prozak.org/tag:influxdb) ![](https://prozak.org/images/b/a/8/6/6/ba86689273fa5b59585d21fd55e15e4d3faed16f-ema.jpeg) **Motivation.** Solar panels are a great solution to complement the self-hosting hobby. They augment the capacity of concurrent systems runningn without increasing your powerbill, plus, overall lower the cost of your month-by-month power bill. There are many solutions in the market, generally speaking, they follow the same model, a number of panels and inverters are installed in your home, it gets interconnected to the city's grid, your bill becomes net metered and it's all good. Most solutions provide means to monitor your power generation and overall system status. The problem with these solutions, lays down the fact that the reporting mechanisms are always a hosted solution, by a third party vendor, subject to the existance/payment on this vendor, which we know, at some point is going to fade away/disappear, If nothing is done preemtively to host these metrics ourselves, when time comes, we will be left without any observability of our own solar solutions. This post outlines an MVP solution to overcome this, ensuring that data is sent in parallel to the cloud solution whilst storing the metrics in our own hosted server. Minimizing the risk of these vendors to disappear, which has happened and will continue to happen. As example, the dissapearance of the Smart Things Cloud can be read HERE. **Core Objective.**Enable the capture of data generated by the AP Systems Solar solution that enables the vendor portal to run and provide owners information on operation, an example of this dashboard: ![EMA](https://prozak.org/images/b/0/8/d/4/b08d4f569dc9fa7f6d8b40249d264ae7617bbae9-ema.jpeg "EMA") To achieve this, we need to: 1. Call the AP Systems ECU device to ingest readings 2. Create payload to InfluxDB 3. Store information in InfluxDB **Required tools.** This MVP was initiated with existing tools at hand, to replicate, you can use: 1. Node-Red - Will function as Event Extractor, Transformation and Loading to InfluxDB. Link Here 2. Node-Red InfluxDB Nodes - Community created Nodes to enable InfluxDB operations. Link Here 3. Node-Red AP Systems ECU Nodes - Community created Nodes to directly talk to the AP ECU, in parallel of their overall cloud operation. Link Here 4. InfluxDB - Selfhosted Server, version 1.8 at the time of this writing. Here is an excellent article to install your Influx, Graphana solution. **Instructions.** Install the InfluxDB Nodes in Node Red 1. Hamburguer menu. 2. Manage Palette. 3. Search AP Systems ECU, InfluxDB nodes in the Search Tab, Install Design the workflow you want the data to flow, both node packages have excellent instructions. Here's my MVP workflow, for reference: ![MVP_Workflow](https://prozak.org/user/pages/04.blog/003-ap-systems-solar-panel-metrics-to-self-hosted-influx/MVP_Workflow.png "MVP_Workflow") What are we doing with this as of right now? - Triggering every 15 minutes the flow in the get action - Configuring the ECU nodes with the local information in the ecu-inverters-config node - Pulling the latest reading from the ECU with the ecu-inverters-query - Use the OOB node to flatten the payload to a simple 1 dimension JSON - Use the OOB Change activity to trim down all irrelevant fields to time series, such as ECU ID, etc. - Use the json converter to generate a properly outlined payload - Send to InfluxDB These steps are high level to encourage you to explore the payload and define what you are looking to get out of your solution, however they are explicit enough to give you the path to go forward. **Results.** After this 2-3 hour project, and fiddling with the Grafana connected to my instance, I am now able to play with Solar Panels information locally, and will not depend on the statistics/service of a third party solution. ![results](https://prozak.org/user/pages/04.blog/003-ap-systems-solar-panel-metrics-to-self-hosted-influx/results.png "results") [ Next Post](https://prozak.org/004-run-emby-server-as-a-different-user) [Previous Post ](https://prozak.org/002-content-wants-to-be-free-not-centralized) #### Related Posts - 50 [012. Dynamic DNS Python Script -> deSEC.io DNS Service](https://prozak.org/012-dynamic-dns-python-script-greater-than-desec-io-dns-service "012. Dynamic DNS Python Script -> deSEC.io DNS Service") - 50 [010. Centralized Wildcard Certificate on Debian with Let’s Encrypt + deSEC](https://prozak.org/010-centralized-wildcard-certificate-on-debian-with-lets-encrypt-desec "010. Centralized Wildcard Certificate on Debian with Let’s Encrypt + deSEC") - 50 [009. Caddy Server Auth Crunch Plugin](https://prozak.org/009-caddy-server-auth-crunch-plugin "009. Caddy Server Auth Crunch Plugin") - 50 [006. Why #SelfHosting should be preferred](https://prozak.org/006-why-selfhosting-should-be-preferred "006. Why #SelfHosting should be preferred") - 50 [005. Oracle Cloud Always Free Instance Ubuntu -> Debian Conversion](https://prozak.org/005-oracle-cloud-always-free-instance-ubuntu-greater-than-debian-conversion "005. Oracle Cloud Always Free Instance Ubuntu -> Debian Conversion") #### Links - [< ](https://webring.obeythesystem.com/page?=previous)[OBEY THE SYSTEM Webring](https://webring.obeythesystem.com/)[ >](https://webring.obeythesystem.com/page?=next) - [rc64k@Github](https://github.com/rc64k) - [Prozak's Mastodon](https://mastodon.social/@prozak) #### Popular Tags [self-hosting](https://prozak.org/tag:self-hosting) [linux](https://prozak.org/tag:linux) [python](https://prozak.org/tag:python) [caddy](https://prozak.org/tag:caddy) [cloud](https://prozak.org/tag:cloud) [privacy](https://prozak.org/tag:privacy) [Philosophy](https://prozak.org/tag:Philosophy) [Quote](https://prozak.org/tag:Quote) [emby](https://prozak.org/tag:emby) [tailscale](https://prozak.org/tag:tailscale) [influxdb](https://prozak.org/tag:influxdb) [network](https://prozak.org/tag:network) [unifi](https://prozak.org/tag:unifi) [artificial intelligence](https://prozak.org/tag:artificial%20intelligence) #### Archives - [ 1 October 2026 ](https://prozak.org/blog/archives_month:oct_2026) - [ 2 July 2026 ](https://prozak.org/blog/archives_month:jul_2026) - [ 3 March 2026 ](https://prozak.org/blog/archives_month:mar_2026) - [ 3 July 2025 ](https://prozak.org/blog/archives_month:jul_2025) - [ 1 May 2025 ](https://prozak.org/blog/archives_month:may_2025) - [ 1 March 2025 ](https://prozak.org/blog/archives_month:mar_2025) - [ 1 September 2024 ](https://prozak.org/blog/archives_month:sep_2024) - [ 1 February 2024 ](https://prozak.org/blog/archives_month:feb_2024) - [ 1 August 2023 ](https://prozak.org/blog/archives_month:aug_2023) - [ 1 March 2021 ](https://prozak.org/blog/archives_month:mar_2021) - [ 2 February 2021 ](https://prozak.org/blog/archives_month:feb_2021) #### RSS & Atom Feeds [ Atom 1.0](https://prozak.org/blog.atom) [ RSS](https://prozak.org/blog.rss) --- ## Navigation - Parent: [Blog Posts](https://prozak.org/index.md) - Previous: [004. Run Emby Server as a Different User](https://prozak.org/004-run-emby-server-as-a-different-user.md) - Next: [002. Content wants to be Free, Not Centralized](https://prozak.org/002-content-wants-to-be-free-not-centralized.md)