Productie Zonnepanelen Bijhouden & Voorspellen - Nieuwe Tool

[Edek]

Bij ons worden volgende week een PV systeem van Enphase geplaatst. Ik heb gezocht naar een applicatie waar ik in één oogopslag de gemeten historische en voorspelde toekomstige productie op basis in kan zien om het stroomverbruik in te plannen. Ik zou het liefst een tool hebben dat een overzicht zoals dat op energieopwek.nl kan bieden, maar dan voor ons huis .

Uit voorlopig onderzoek en rondvragen op dit forum heb ik geen gratis applicatie kunnen vinden die hier aan voldoet. Daarom ben ik van plan om zelf hier een tool voor te schrijven. Die kan ik dan hosten op een privé gedeelte van mijn persoonlijke website zodat ik er altijd bij kan. Ik denk aan de volgende MVP:

Minimumeisen

• Historische productie van een Enphase systeem kan hiermee worden ingezien per kwartier.
• Historische en voorspelde weerdata, specifiek de insolatie kan worden ingezien.
• Een zonnemodel dat calibreert op historische productie en insolatie en op basis van de weersvoorspelling de toekomstige productie kan voorspellen.
• Een interface dat qua functionaliteit lijkt op energieopwek.nl, dat wil zeggen een productie grafiek per dag met kalender om vorige en volgende dagen te bekijken.
• Open-source (GNU GPLv3)

Technische Eisen:

• Werkt op een webserver met PHP 8 en MariaDB.
• PHP backend en frontend met wat HTML/CSS en JS.
• Gebruikt Enphase Developer API voor productie data.
• Gebruikt OpenMeteo API voor historische en voorspelde weersdata.

Nice to have, maar geen MVP:

• Historische stroomverbruik kan worden ingezien
• Dynamische stroomprijzen kunnen worden ingezien
• Packagen in lighttpd+PHP+SQLite zodat dit ook kan worden gebruikt als locale applicatie op een Windows/Unix computer.
• Als dit allemaal goed werkt, wellicht op een dag naar een Android app porten.

Ik zou de applicatie graag zo schrijven dat hij goed voor ons werkt, maar ook door anderen gebruikt gerund kan worden voor eigen gebruik. Is hier vraag naar? Hebben jullie wellicht zelf suggesties of ideeën?

Het is eeuwig zonde dat Tweakblogs weg is , anders had ik graag een Tweakblog over deze ontwikkeling geschreven. Als de mods het goed vinden dan gebruik ik deze topic om mijn vooruitgang te delen en feedback te vergaren.

[FredvZ]

Misschien denk ik te simpel, maar klinkt als een hele ingewikkelde manier om tot de conclusie te komen dat je je apparaten aan moet zetten als de zon schijnt.

[de Peer]

FredvZ schreef op zaterdag 1 februari 2025 @ 12:01:
Misschien denk ik te simpel, maar klinkt als een hele ingewikkelde manier om tot de conclusie te komen dat je je apparaten aan moet zetten als de zon schijnt.

dat is hier niet het doel. Hij wil gewoon een mooi overzicht hebben. Dus monitoring als doel op zich.

[fenrir]

Home assistant met de Enphase integration? Was je dit al tegengekomen?
Eventueel in combinatie met grafana zodat je alle grafieken kunt maken die je wil?

Iets zelf ontwikkelen is natuurlijk leuk, maar waarom zelf het wiel uit willen vinden?

[Kalentum]

de Peer schreef op zaterdag 1 februari 2025 @ 12:39:
[...]

dat is hier niet het doel. Hij wil gewoon een mooi overzicht hebben. Dus monitoring als doel op zich.

En een voorspelling van wat de panelen gaan doen. Op basis van weersgegevens en dan automatisch gecorrigeerd naar je eigen systeem.

Ik heb zelf wel eens gespeeld met https://forecast.solar maar die data zit er continue naast omdat er factoren zijn waar je geen rekening mee kan houden in zo'n algemeen model. Schaduw in de winter bv is bij mij in mijn mooie groene woonwijk best wel erg.

En op zich is het wel handig als je om 7:30 's morgens weet of je je wasmachine 1, 2 of 3 uur moet uitstellen.

Persoonlijk weet ik nog niet of ik zoiets nodig heb. Een blik op de weersverwachting in combinatie met een blik naar buiten geeft ook al een aardig beeld. En vaak willen we dat de was toch klaar is om 14 uur ofzo dus uiteindelijk zet je het maar gewoon aan ondanks dat het qua verbruik niet optimaal i.

@Edek Zorg in elk geval dat je systeem omvormer-onafhankelijk is. Het moet mogelijk zijn om ondersteuning voor andere omvormers toe te voegen. En ook zo database-onafhankelijk mogelijk. Om maar wat te noemen, ik gebruik geen MariaDB en ik ga ook mijn eigen monitoring niet vervangen.

[Edek]

fenrir schreef op zaterdag 1 februari 2025 @ 12:45:
Home assistant met de Enphase integration? Was je dit al tegengekomen?
Eventueel in combinatie met grafana zodat je alle grafieken kunt maken die je wil?

Iets zelf ontwikkelen is natuurlijk leuk, maar waarom zelf het wiel uit willen vinden?

We hebben geen zin om hier een home assistant server op te zetten, ik wil iets simpels en lichtgewichts. Daarnaast speelt ook een rol dat ik zelf in Finland woon. De zonnepanelen staan op het ouderlijk huis. Ik wil er dus bij kunnen van een afstand.

Grafana is een goeie aanbeveling, ik zal ernaar kijken.

Kalentum schreef op zaterdag 1 februari 2025 @ 17:20:
[...]


En een voorspelling van wat de panelen gaan doen. Op basis van weersgegevens en dan automatisch gecorrigeerd naar je eigen systeem.

[...]

@Edek Zorg in elk geval dat je systeem omvormer-onafhankelijk is. Het moet mogelijk zijn om ondersteuning voor andere omvormers toe te voegen. En ook zo database-onafhankelijk mogelijk. Om maar wat te noemen, ik gebruik geen MariaDB en ik ga ook mijn eigen monitoring niet vervangen.

Ja inderdaad, ik wil de cross-section tijdsafhankelijk maken, zodat het enigzins het effect van schaduw mee kan nemen. Zal natuurlijk nooit perfect zijn.

Ja, ik probeer het systeem omvormer-onafhankelijk te maken alleen voor nu pleur ik dus alleen Enphase erin. Werkt jouw systeem ook met gemeten productie intervallen van 15 minuten, net als bij Enphase? Wat voor een inverter heb jij? Database-onafhankelijk zou in grote lijnen moeten lukken, alleen kan het altijd dat er kleine SQL verschillen achteraf gecorrigeerd moeten worden.

[Kalentum]

Edek schreef op zaterdag 1 februari 2025 @ 18:46:
[...]


We hebben geen zin om hier een home assistant server op te zetten, ik wil iets simpels en lichtgewichts. Daarnaast speelt ook een rol dat ik zelf in Finland woon. De zonnepanelen staan op het ouderlijk huis. Ik wil er dus bij kunnen van een afstand.

Grafana is een goeie aanbeveling, ik zal ernaar kijken.


[...]


Ja inderdaad, ik wil de cross-section tijdsafhankelijk maken, zodat het enigzins het effect van schaduw mee kan nemen. Zal natuurlijk nooit perfect zijn.

Ja, ik probeer het systeem omvormer-onafhankelijk te maken alleen voor nu pleur ik dus alleen Enphase erin. Werkt jouw systeem ook met gemeten productie intervallen van 15 minuten, net als bij Enphase? Wat voor een inverter heb jij? Database-onafhankelijk zou in grote lijnen moeten lukken, alleen kan het altijd dat er kleine SQL verschillen achteraf gecorrigeerd moeten worden.

Ik heb een SMA omvormer en lees ik elke seconde uit. Dat gaat naar een Influxdatabase voor Grafana en naar PostgreSQL. De secondenwaarden in Influxdb worden automatisch gewist na 4 weken, ik archiveer wel de secondenwaarden. Mijn PostgreSQL database heeft inderdaad waarden per kwartier. En per dag. Ik gebruik Redash voor het opslaan van de queries en voor visualisaties. De rest van mijn energieverbruik (p1 meter, een paar kWh meters, gas) zit er ook in dus alles op 1 plek.

De data van solar forecast is per uur dus ik kan vrij eenvoudig de verwachtte productie koppelen aan de gerealiseerde productie.

[maarten_NL]

FredvZ schreef op zaterdag 1 februari 2025 @ 12:01:
Misschien denk ik te simpel, maar klinkt als een hele ingewikkelde manier om tot de conclusie te komen dat je je apparaten aan moet zetten als de zon schijnt.

Met de ingewikkelde data en parameters een accuratere voorspelling geven, waarmee je verbruikers kan automatiseren. Ik zie het nu wel

Solar forecast vind ik maar maar matig en zit maar zelden goed.

Als je test data nodig hebt? Ik heb een influxDb vol met data (elke 10s, recht uit de omvormer)

[Edek]

Kalentum schreef op zaterdag 1 februari 2025 @ 19:01:
[...]
Ik heb een SMA omvormer en lees ik elke seconde uit. Dat gaat naar een Influxdatabase voor Grafana en naar PostgreSQL. De secondenwaarden in Influxdb worden automatisch gewist na 4 weken, ik archiveer wel de secondenwaarden. Mijn PostgreSQL database heeft inderdaad waarden per kwartier. En per dag. Ik gebruik Redash voor het opslaan van de queries en voor visualisaties. De rest van mijn energieverbruik (p1 meter, een paar kWh meters, gas) zit er ook in dus alles op 1 plek.

Ik denk dat dat moet lukken! Dat systeem lijkt redelijk compatibel met wat ik in gedachten had. Je gebruikt dus niet de SMA online API. Is daar een reden voor, heb je daarover nagedacht?

maarten_NL schreef op zaterdag 1 februari 2025 @ 21:36:
[...]


Met de ingewikkelde data en parameters een accuratere voorspelling geven, waarmee je verbruikers kan automatiseren. Ik zie het nu wel

[...]

Als je test data nodig hebt? Ik heb een influxDb vol met data (elke 10s, recht uit de omvormer)

Mooi . Ik laat je weten indien het nodig is. Welke omvormer en API gebruik jij?

[Edek]

@Kalentum Ik heb overigens een database schema geschreven. Je kunt vast kijken of het compatibel is met je Postgres setup, ik ben benieuwd wat je vindt.

Database schema broncode:

code:

-- SQL code implemented on MariaDB 10.6

START TRANSACTION; -- Creates all tables in one go, or not

-- First, we create the index tables

/* A note on time. I considered making a
 * table containing all quarters of an
 * hour from 2000-2100. I opted not to.
 * Instead, we simply use integer Unix
 * timestamps for everything.
 * This is time-zone independent.
 * We also consider leapseconds to
 * have never happened so that
 * all quarters of an hour in our
 * calendar are given conform to:
 * unixtimestamp % (60*15) == 0.
 * Generally speaking most databases also
 * disregard leapseconds. Furthermore, all
 * data should be stored exactly on
 *  5/15/60/etc. minute intervals 
 * depending on the datasource.
 * We thus do not accept unixtimestamps
 * reflecting times such as
 * 2025-02-03T10:15:00.1,
 * because it is off by .1 seconds and
 * thus cannot be connected to a
 * specific time interval
 *
 * We try to use iana defined timezones:
 * https://stackoverflow.com/questions/33465054/storing-timezone-in-a-database
 * Note that for an Enphase system
 * timezone is fixed by the API. We always
 * use that when outputting to user.
 *
 * A Note on INTEGER PRIMARY KEY compatibility:
 * In SQLite AUTO_INCREMENT is not defined.
 * However, INTEGER PRIMARY KEY is functionally equivalent.
 * This is called a ROWID. To get this. must write
 * INTEGER PRIMARY KEY, not INT PRIMARY KEY.
 */

/* This is a handy hack which allows us to add integrations in the future
 * and still be able to cascade down to system the effect of deleting such
 * an integration. The only requirement here is that exactly one
 * integration is pointed to at a time, and no more. */
CREATE TABLE IntegrationKeys (
  integrationkeyid  INTEGER PRIMARY KEY AUTO_INCREMENT,
  ehaid         INTEGER
  -- We add the following foreign key dependency constraint
  -- later, once the EnphaseHomeownerAuthorisations is created:
  -- CONSTRAINT IntegrationKeyToEnphaseAuthorisation
  -- FOREIGN KEY (ehaid) REFERENCES EnphaseHomeownerAuthorisations(ehaid)
  -- ON UPDATE CASCADE ON DELETE CASCADE,
  
  -- NB: We would like to enforce that exactly one API key column
  -- is not null with:
  -- CONSTRAINT ExactlyOneAssociatedAPI
  -- CHECK ( (ehaid IS NOT NULL) + (secondapi IS NOT NULL) = 1)
  -- However, this is not permitted with ehaid in MariaDB,
  -- as AUTO_INCREMENT columns may sadly not be referenced
  -- in CHECK clauses. :-(. So we must enforce this ourselves.
);

CREATE TABLE Systems (
  -- ID used internally as index:
  systemid      INTEGER PRIMARY KEY AUTO_INCREMENT,
  -- Identifier used to identify system to API:
  external_identifier   VARCHAR(64) NOT NULL,
  -- Internal name as set by user:
  internal_name     VARCHAR(64) NOT NULL,
  -- Thus far only systemtype: "ENPHASEv4"
  systemtype        VARCHAR(32) NOT NULL,
  -- Identifies the relevant API:
  integrationkeyid  INTEGER,
  -- Set by user:
  latitude      FLOAT NOT NULL,
  -- Set by user:
  longitude     FLOAT NOT NULL,
  -- Supplied by Enphase or Set by User:
  timezone      VARCHAR(64) NOT NULL,
  -- This foreign key constraint allows deleting an
  -- authorisation without losing all system data.
  CONSTRAINT SystemToKey
  FOREIGN KEY (integrationkeyid) REFERENCES IntegrationKeys(integrationkeyid)
  ON UPDATE CASCADE
  ON DELETE SET NULL
) DEFAULT CHARSET=utf8mb4;

CREATE TABLE Meters (
  meterid       INTEGER PRIMARY KEY AUTO_INCREMENT,
  systemid      INTEGER NOT NULL,
  -- Identifier used to identify meter to API:
  external_identifier   VARCHAR(32) NOT NULL,
  -- Internal name as set by user:
  internal_identifier   VARCHAR(32) NOT NULL,
  -- The general class of this meter (e.g. total system production/consumption)
  meterclass        VARCHAR(32),
  -- The specific hardware and API dependent meter type:
  metertype     VARCHAR(32),
  -- Apply constraints & foreign key:
  CONSTRAINT MeterToSystem
  FOREIGN KEY (systemid) REFERENCES Systems(systemid)
  ON UPDATE CASCADE ON DELETE CASCADE
) DEFAULT CHARSET=utf8mb4;

-- Next, the data tables:

CREATE TABLE MeasuredPower (
  meterid       INTEGER NOT NULL,
  unixtimestamp     INTEGER UNSIGNED NOT NULL,
  interval_seconds  SMALLINT UNSIGNED NOT NULL,
  powerinwatt       FLOAT,
  -- Form primary key:
  CONSTRAINT MeasuredPowerPrimaryKey
  PRIMARY KEY (meterid, unixtimestamp),
  -- Apply foreign key dependency constraint:
  CONSTRAINT MeasuredPowerToMeter
  FOREIGN KEY (meterid) REFERENCES Meters(meterid)
  ON UPDATE CASCADE ON DELETE CASCADE
);

CREATE TABLE Weather (
  systemid          INTEGER NOT NULL,
  unixtimestamp         INTEGER UNSIGNED NOT NULL,
  interval_seconds      SMALLINT UNSIGNED NOT NULL,
  dni_wattperm2         FLOAT,
  dhi_wattperm2         FLOAT,
  ghi_wattperm2         FLOAT,
  airtemperature_celsius    FLOAT,
  windspeed_meterspersecond FLOAT,
  -- Form primary key:
  CONSTRAINT WeatherPrimaryKey
  PRIMARY KEY (systemid, unixtimestamp),
  -- Apply foreign key dependency constraint:
  CONSTRAINT WeatherToSystem
  FOREIGN KEY (systemid) REFERENCES Systems(systemid)
  ON UPDATE CASCADE ON DELETE CASCADE
);

-- Finally, the API tables:

/* Enphase docs:
 * https://developer-v4.enphase.com/docs/quickstart.html */
CREATE TABLE EnphaseDeveloperAccounts (
  edaid         INTEGER PRIMARY KEY AUTO_INCREMENT,
  clientid      VARCHAR(64) NOT NULL,
  clientsecret      VARCHAR(64) NOT NULL,
  apikey        VARCHAR(64) NOT NULL,
  -- Internal name as set by user:
  internal_name     VARCHAR(32) NOT NULL
) DEFAULT CHARSET=utf8mb4;

CREATE TABLE EnphaseHomeownerAuthorisations (
  ehaid         INTEGER PRIMARY KEY AUTO_INCREMENT,
  edaid         INTEGER NOT NULL,
  authorization_code    VARCHAR(32) NOT NULL,
  redirect_url      VARCHAR(256) NOT NULL,
  -- User defined, to help identify an authorisation:
  associated_username   VARCHAR(32) NOT NULL,
  -- Apply foreign key dependency constraint:
  CONSTRAINT EnphaseAuthorisationToDeveloperAccount
  FOREIGN KEY (edaid) REFERENCES EnphaseDeveloperAccounts(edaid)
  ON UPDATE CASCADE ON DELETE CASCADE
) DEFAULT CHARSET=utf8mb4;

-- Apply foreign key dependency constraint to IntegrationKeys table:
ALTER TABLE IntegrationKeys
ADD CONSTRAINT IntegrationKeyKeyToEnphaseAuthorisation
FOREIGN KEY (ehaid) REFERENCES EnphaseHomeownerAuthorisations(ehaid)
ON UPDATE CASCADE ON DELETE CASCADE;

/* This ensures that the IntegrationKeys table always contains a link to
 * an EnphaseHomeownerAuthorisation. */
CREATE TRIGGER CreateIntegrationKeyForEnphaseAuthorisation
AFTER INSERT ON EnphaseHomeownerAuthorisations 
FOR EACH ROW 
INSERT INTO IntegrationKeys (ehaid) VALUES (EnphaseHomeownerAuthorisations.ehaid);

CREATE TABLE EnphaseTokens (
  tokenid           INTEGER PRIMARY KEY AUTO_INCREMENT,
  ehaid             INTEGER NOT NULL,
  refresh_token         VARCHAR(128) NOT NULL,
  access_token          VARCHAR(128) NOT NULL,
  expires_at_unixtimestamp  INTEGER UNSIGNED NOT NULL,
  -- Apply foreign key dependency constraint:
  CONSTRAINT EnphaseTokenToAuthorisation
  FOREIGN KEY (ehaid) REFERENCES EnphaseHomeownerAuthorisations(ehaid)
  ON UPDATE CASCADE ON DELETE CASCADE   
) DEFAULT CHARSET=utf8mb4;

COMMIT; -- Completes transaction

[ Voor 17% gewijzigd door Edek op 02-02-2025 21:33 . Reden: bugfix schema ]

[maarten_NL]

@Edek

Ik lees de growatt omvormers via de RS485 poort uit, met een geforkte repo en ESP8266's

[Kalentum]

Edek schreef op zondag 2 februari 2025 @ 20:38:
[...]


Ik denk dat dat moet lukken! Dat systeem lijkt redelijk compatibel met wat ik in gedachten had. Je gebruikt dus niet de SMA online API. Is daar een reden voor, heb je daarover nagedacht?

Ik gebruik de omvormer lokaal uit (via modbus). De reden is dat ik dan onafhankelijk ben van storingen van mijn internetprovider of van SMA. Uitlezen en verwerken gebeurt dus lokaal.

Edek schreef op zondag 2 februari 2025 @ 20:42:
@Kalentum Ik heb overigens een database schema geschreven. Je kunt vast kijken of het compatibel is met je Postgres setup, ik ben benieuwd wat je vindt.

Nee het is heel anders. Ik heb maar 1 system dus geen systems tabel. Ik heb 1 tabel met kwartierwaarden (tijdstip (UTC) en 6 meetwaarden). De dagproductie staat in een parte tabel met 1 rij per dag.

Ik snap ook niet zo goed wat die 'interval_seconds' doet? Wat ik doe: metingen komen binnen op tijdstip 12:15:01, ik rond dat naar boven af (12:30:00). Bestaat er nog een rij voor dat kwartier, dan maak ik die rij aan, anders update ik de bestaande rij. Dan boeit het ook niet precies hoe laat een meting binnenkomt, als er maar wat binnenkomt in een kwartier.

De weersverwachtingen heb ik nog niet genormaliseerd: ik sla de JSON output van de API op in de database als JSON en gebruik de JSON functies van de database om die uit te lezen. Moet nog een beter maar voorlopig werkt dit prima.

[Edek]

Kalentum schreef op zondag 2 februari 2025 @ 21:22:
[...]
Nee het is heel anders. Ik heb maar 1 system dus geen systems tabel. Ik heb 1 tabel met kwartierwaarden (tijdstip (UTC) en 6 meetwaarden). De dagproductie staat in een parte tabel met 1 rij per dag.

Met vergelijkbaar doelde ik op het feit dat je een tabel met kwartierwaarden aanhoudt. In de power tabel ben ik ook in principe van plan kwartierwaarden op te slaan, alleen dan in de unixtimestamp format. Wat je in dit geval zou kunnen doen als ik een MVP prototype klaar heb, is de prototype gewoon over nemen in een subfolder van je website en de database tabellen kopiëren. Vervolgens stel je een SQL TRIGGER in zodat elke keer dat jij een waarde toevoegt aan jouw tabel met kwartierwaarden dan voeg je ook een nieuwe row toe aan de MeasuredPower tabel met eenzelfde informatie.

Ik snap ook niet zo goed wat die 'interval_seconds' doet? Wat ik doe: metingen komen binnen op tijdstip 12:15:01, ik rond dat naar boven af (12:30:00). Bestaat er nog een rij voor dat kwartier, dan maak ik die rij aan, anders update ik de bestaande rij. Dan boeit het ook niet precies hoe laat een meting binnenkomt, als er maar wat binnenkomt in een kwartier.
[...]

interval_seconds reflecteert de duur van het gemeten tijdsinterval in secondes. Dan loopt een unixtimestamp corresponderend aan 17:00 met interval_seconds=900 dus van 17:00 tot 17:15. Dat je je tijdstip afrondt op het kwartier is heel goed, dit voorkomt allerlei complexe dataverwerking stappen. Het is kritiek om exact gelijke tijdsintervallen in de DB te hebben staan.

[Edek]

Kalentum schreef op zondag 2 februari 2025 @ 21:22:
[...]
De weersverwachtingen heb ik nog niet genormaliseerd: ik sla de JSON output van de API op in de database als JSON en gebruik de JSON functies van de database om die uit te lezen.

Welke API?

[Kalentum]

Edek schreef op zondag 2 februari 2025 @ 21:43:
[...]


Welke API?

https://forecast.solar/

Waar ik dus mijn opbrengstverwachtingen vandaan haal

[PolarBear604]

Edek schreef op zaterdag 1 februari 2025 @ 11:46:
Een zonnemodel dat calibreert op historische productie en insolatie en op basis van de weersvoorspelling de toekomstige productie kan voorspellen.

Dat is wel een flinke eis, maar in theorie heb je wel wat nodig is om een degelijk model te maken. De nadruk op een degelijk model, want gewoon de historische productiedata koppelen aan verwachte instraling is dat niet. De voorspellingen van software zoals PVSol vallen en staan bij hoe accuraat de horizon is omschreven. Dat is best lastig, het is namelijk niet alleen directe schaduw maar ook indirecte schaduw die een rol speelt.

Het grote voordeel is dat je de correctiefactoren op basis van opwekdata gewoon weer kunt aanpassen, en je daarna een prima voorspellingsmodel hebt.

In de openmeteo datasets zit DHI (Diffuse), DNI (direct), temperatuur en optioneel windsnelheid.
Lokaal heb je locatiegegevens en tijd, welke je combineert met je systeemgegevens. Hierbij kun je zover gaan als je wilt, maar minimaal de orientatie, hellingshoek + installatiemethode, het vermogen en het type paneel. Je model schat in combinatie met de twee correctiefactoren voor directe en indirecte schaduw het opgewekte DC vermogen. Dit doe je per orientatie/MPPT en haal je door de vermogensefficientiecurve van je omvormer. Kabelverlies schat je op bv 3%.

Dat hele model hoef je niet zelf te maken, maar ik ken alleen een opensource versie die op python en matlab werkt (pvlib). De voorbeelden daar kunnen vrij intimiderend zijn aangezien het academisch wordt gebruikt. Ik verwacht dat je nadat je de correctiefactoren hebt aangepast de onzekerheid van je weersvoorspelling een grotere rol speelt dan de complexiteit van je model.
Afhankelijk van hoeveel directe schaduw je hebt moet je die correctiefactor misschien nog wel uitbreiden, daar heb ik geen gevoel bij.

Om even realistisch te zijn, denk ik dat het schrijven (en dus begrijpen) van een goed model theoretisch kan, maar het wel veel werk is voor niet heel veel toegevoegde waarde. Maar met wat extra bijdragers in theorie wel een prachtig tweakersproject, zeker aangezien de community data guidelines kunnen vormen voor de correctiefactoren. Dit zou dan een goed startpunt zijn, maar het lijkt me verstandig als iemand met ervaring in het ontwikkelen van PVsimulatiesoftware er eens een ongezouten plasje overheen doet. Zelf ga ik het voorlopig niet opzetten, eerst maar eens een huis bemachtigen.

Een alternatief is een AI model trainen op basis van historische data. Ik zou als features zeker kijken naar positie van de zon (eerst uit datum, tijd en locatie halen), Direct en Diffuse Irradiation, en dan temperatuur omdat dat veel invloed op de opwekking heeft. En uiteraard vermogen, waar dan ook de omvormersefficientie in zit verwerkt.

En alle omvormers hebben een Modbus RTU protocol over RS485, soms alleen niet online te vinden. Dat kun je sowieso uitlezen, maar zolang begrenzing niet in de scope van het project zit zou ik de informatie lekker via een portal uitlezen. Dat is gemakkelijker, en het is toch geen drama als je monitoring er een paar uur uitligt. Zeker niet als je eenmaal een goed model zou hebben.

[PolarBear604]

Kalentum schreef op zondag 2 februari 2025 @ 22:25:
[...]

https://forecast.solar/

Waar ik dus mijn opbrengstverwachtingen vandaan haal

Dat kende ik nog niet, maar het ziet er veelbelovend uit en lijkt me perfect voor OP. Ze hebben het direct indirect schaduw verhaal samengevoegd naar een clearsky factor, maar misschien is dat in de meeste gevallen wel prima. Ben wel benieuwd naar de verantwoording/overweging, aangezien ik wel wat gevallen heb gezien waarbij de opwekking op jaarbasis significant (10%) afwijkt van de voorspelling.

Heb je de opbrengst wel eens naast de voorspellingen bekeken? Hoeveel scheelt dat? En wat doet het verschil procentueel in de eerste en laatste opwekuren van de dag?

[Kalentum]

PolarBear604 schreef op maandag 3 februari 2025 @ 00:28:
[...]


Dat kende ik nog niet, maar het ziet er veelbelovend uit en lijkt me perfect voor OP. Ze hebben het direct indirect schaduw verhaal samengevoegd naar een clearsky factor, maar misschien is dat in de meeste gevallen wel prima. Ben wel benieuwd naar de verantwoording/overweging, aangezien ik wel wat gevallen heb gezien waarbij de opwekking op jaarbasis significant (10%) afwijkt van de voorspelling.

Heb je de opbrengst wel eens naast de voorspellingen bekeken? Hoeveel scheelt dat? En wat doet het verschil procentueel in de eerste en laatste opwekuren van de dag?

Ik heb nog nooit echt goed naar die data gekeken, want het vliegt alle kanten op. Maar ik kan vanavond wel eens even wat meer analyse doen. Ik heb nu data van 2023 en later (helaas niet compleet) dus dat is op zich wel aardig wat.

[Kalentum]

PolarBear604 schreef op maandag 3 februari 2025 @ 00:28:
[...]

Heb je de opbrengst wel eens naast de voorspellingen bekeken? Hoeveel scheelt dat? En wat doet het verschil procentueel in de eerste en laatste opwekuren van de dag?

Ik heb 8624 geldige uren (productie > 0 of voorspelling > 0)

Ik beschouw het als "goed voorspeld" als productie/voorspelling groter is dan 0,9 en kleiner dan 1,1
960 records zijn dat

Dus dat is niet zo veel. Grotere afwijkinen (factor < 0,5 of groter dan 1,5) zijn 4622 records.

Ik vind het ook wel logisch, want kleine verschillen in bewolkingsdichtheid kunnen al flinke verschillen (beide kanten op) in productie betekenen.

Zonder correctiefactoren (per week? per maand?) is het lastig dit goed krijgen. Maar je hebt al best wel wat data nodig om goede correctiefactoren toe te passen en die zijn voor iedereen anders. Ik woon in een mooie groene wijk en dat betekent bv in deze tijd van het jaar dat schaduw vanwege bomen en de laagstaande zon echt een verschil maakt. En orientatie ZO/NW helpt ook niet mee.

Mocht je nog wat willen spelen, de data kun je downloaden via Kaggle

[Edek]

PolarBear604 schreef op maandag 3 februari 2025 @ 00:05:
[...]
In de openmeteo datasets zit DHI (Diffuse), DNI (direct), temperatuur en optioneel windsnelheid.
Lokaal heb je locatiegegevens en tijd, welke je combineert met je systeemgegevens. Hierbij kun je zover gaan als je wilt, maar minimaal de orientatie, hellingshoek + installatiemethode, het vermogen en het type paneel. Je model schat in combinatie met de twee correctiefactoren voor directe en indirecte schaduw het opgewekte DC vermogen. Dit doe je per orientatie/MPPT en haal je door de vermogensefficientiecurve van je omvormer. Kabelverlies schat je op bv 3%.

Een alternatief is een AI model trainen op basis van historische data. Ik zou als features zeker kijken naar positie van de zon (eerst uit datum, tijd en locatie halen), Direct en Diffuse Irradiation, en dan temperatuur omdat dat veel invloed op de opwekking heeft. En uiteraard vermogen, waar dan ook de omvormersefficientie in zit verwerkt.

Dit zijn allemaal mooie punten. Inderdaad, om die reden zou ik het tweede kiezen, een model trainen. Ik heb dit eerder gedaan puur op DHI en DNI, en met wat inverter clipping. Ik overwoog toen ook wind en temperatuur mee te nemen, alleen bleek toen al dat de fout in de weersverwachting al véél groter was dan de model fout. Daarnaast was bleek dat zelfs historische insolatie data niet heel precies is. OpenMeteo heeft immers geen informatie over elke wolk die ooit voorbijgetrokken is.

En alle omvormers hebben een Modbus RTU protocol over RS485, soms alleen niet online te vinden. Dat kun je sowieso uitlezen, maar zolang begrenzing niet in de scope van het project zit zou ik de informatie lekker via een portal uitlezen. Dat is gemakkelijker, en het is toch geen drama als je monitoring er een paar uur uitligt. Zeker niet als je eenmaal een goed model zou hebben.

Waar doel je op met bregrenzing? Denk je trouwens ook dat inverter efficientië een serieus significante factor is?

[Edek]

@Kalentum Heel informerend die data! Heb je ook grafiekjes van voorspelde opbrengsten 1-dag van te voren vergeleken met daadwerkelijke opwek? Gebruik je een betaalde bundel?

Zou heel boeiend zijn om te zien of die uberhaubt lijken.

[Kalentum]

Edek schreef op maandag 3 februari 2025 @ 21:29:
@Kalentum Heel informerend die data! Heb je ook grafiekjes van voorspelde opbrengsten 1-dag van te voren vergeleken met daadwerkelijke opwek? Gebruik je een betaalde bundel?

Zou heel boeiend zijn om te zien of die uberhaubt lijken.

Dit is een gratis account en de voorstelling is in de morgen opgehaald

[PolarBear604]

Edek schreef op maandag 3 februari 2025 @ 21:27:
[...]

Daarnaast was bleek dat zelfs historische insolatie data niet heel precies is. OpenMeteo heeft immers geen informatie over elke wolk die ooit voorbijgetrokken is.


[...]


Waar doel je op met bregrenzing? Denk je trouwens ook dat inverter efficientië een serieus significante factor is?

Ik weet niet wat de algemene kwaliteit is van de meteodata, maar op basis van een kwartier zou die ene wolk zich wat uit moeten middelen. Het zal ook afhangen van hoever de meetpunten bij je vandaan liggen. Diffuse zou helemaal geen last moeten hebben van van die ene wolk, maar hoeveel deze % bijdraagt aan opwek verschilt nogal.

Begrenzing voor het beheersen van terugleveren, of voor bv het aansturen van laadvermogen laadpaal met een loadbalancer. Dan is snelheid van belang en heeft het continue uitlezen dus toegevoegde waarde.

Omvormerefficienctie zakt bij <30% Pmax en lagere Vmmpt in, maar dat zou max 5% verlies moeten zijn. Ik dacht dat dit vroeger best wat meer was voor consumentenomvormers. Het is wel een van de simpelere dingen om te modelleren aangezien er online parameters voor heel veel omvormermerken te vinden zijn.
De european efficiency is voor realistische voorspellingen op jaarbasis gemaakt, die is gebaseerd op de praktijkefficientie van een opstelling in noord-italie. Dat geeft een beeld van hoe de omvormer omgaat met niet optimale opwek omstandigheden.

En dank voor de evaluatie Kalentum, erg interessant.

[Hencksch]

Kalentum schreef op zaterdag 1 februari 2025 @ 17:20:
[...]


En op zich is het wel handig als je om 7:30 's morgens weet of je je wasmachine 1, 2 of 3 uur moet uitstellen.

heb je hier iets aan?
https://energie.theoxygent.nl/

De site geeft dagelijks het antwoord op een leuk optimalisatievraagstuk:
Wat is vandaag het beste moment op basis van weersverwachting en dynamische stroomtarieven als ik een (af-)wasprogramma wil draaien van x of y uren.

[Gizz]

Edek schreef op zaterdag 1 februari 2025 @ 18:46:
[...]


We hebben geen zin om hier een home assistant server op te zetten, ik wil iets simpels en lichtgewichts. Daarnaast speelt ook een rol dat ik zelf in Finland woon. De zonnepanelen staan op het ouderlijk huis. Ik wil er dus bij kunnen van een afstand.

Waarom zou je niet bij HA kunnen van een afstand?

Maar los daarvan, zelfs als je geen HA wil gebruiken zou ik je wel willen aanraden om je laten inspireren door wat anderen al hebben gebouwd Forecast.solar is al genoemd, als particulier kun je gratis gebruikmaken van hun API. Zelf een dergelijk systeem nabouwen lijkt me veel werk.

En voor HA zijn al veel mensen bezig om dat soort dingen verder te combineren met dynamische energieprijzen, suggesties voor de beste momenten om zware verbruikers aan te zetten etc.

Beter goed gejat/geïnspireerd dan vanaf 0 zelf beginnen. Al vraag ik me oprecht af waarom direct de forecast.solar API gebruiken niet voldoende is voor jouw gebruiksdoel.

[Kalentum]

Hencksch schreef op dinsdag 4 februari 2025 @ 10:26:
[...]

heb je hier iets aan?
https://energie.theoxygent.nl/

De site geeft dagelijks het antwoord op een leuk optimalisatievraagstuk:
Wat is vandaag het beste moment op basis van weersverwachting en dynamische stroomtarieven als ik een (af-)wasprogramma wil draaien van x of y uren.

Bedankt, ik kende deze niet.

Dit is natuurlijk heel handig als je geen zonnepanelen hebt en/of dynamische tarieven gebruikt.

Maar landelijk een laag dynamisch tarief tussen 12 en 14 wil nog niet zeggen dat mijn eigen systeem dan ook het beste presteert. Kan best zijn dat in mijn regio vanaf 8 uur de zon schijnt en tegen 11 uur de bewolking er is. Dan heb ik toch liever om 9 uur de wasmachine aan.

[Edek]

Gizz schreef op dinsdag 4 februari 2025 @ 10:34:
[...]
Maar los daarvan, zelfs als je geen HA wil gebruiken zou ik je wel willen aanraden om je laten inspireren door wat anderen al hebben gebouwd Forecast.solar is al genoemd, als particulier kun je gratis gebruikmaken van hun API. Zelf een dergelijk systeem nabouwen lijkt me veel werk.

En voor HA zijn al veel mensen bezig om dat soort dingen verder te combineren met dynamische energieprijzen, suggesties voor de beste momenten om zware verbruikers aan te zetten etc.

Om te bekennen vind ik het gewoon erg leuk om dingen zelf te doen, dan kan het precies naar wens. Bij ons zijn er trouwens 3 dakvlakken met wat boomschaduw daarbij. Forcast.solar kan volgens mij maar 1 vlak. Om die reden wil ik het toch wat anders aanpakken.

De installateur kwam vandaag kijken en trok meteen een paar dakpannen stuk en keerde onverrichter zake terug . Hopelijk lukt morgen de poging no. 2 met de daklegger erbij.

[Bravo]

Zelf werk ik (handmatig) al een tijd binnen HA met de verwachtingen van de zonneopwek om mijn 'domme' gebruikers (vaatwasser, wasmachine) te sturen. Helaas was gisteren weer zo'n dag dat de verwachting er hopeloos naast zat, de bewolking bleef aanwezig en loste niet op. Ik heb niet nagekeken hoe of de bewolking in heel Nederland is blijven hangen of dat iets lokaals was, maar het was een behoorlijke domper.
Hetzelfde geldt voor 31 januari, er was wat sluierbewolking, waar de modellen niet goed mee om kunnen gaan. En laten we nog maar even niet kijken naar de impact van mist...

Geel: verwachting voor de bewuste dag, gegeneerd op de dag zelf, wordt 5x bijgewerkt.
Groen: de daadwerkelijke opbrengst op de dag.
Wat ik wil aangeven: Het model voor de weersverwachting is leidend voor de foutmarge van de uitkomst. Het verlies wat ik heb door schaduwwerking valt helemaal weg in de ruis van de verwachting.

Mijn model
Solcast plugin met twee arrays. Hierdoor kan ik 5x per dag een forecast ophalen, geen 10x.
Groene lijn met opbrengst valt terug zodra de HM-omvormer uitschakelt en geen data meer levert.

[Edek]

@Bravo Boeiend om je analyste te lezen!

Weersvoorspelling is helaas een probabilistisch proces, en al helemaal als je kijkt naar insolatie met de wolken erbij. Ik denk dat de juiste aanpak hier fundamenteel een statistische moet zijn. Daarvoor zijn de ensembels van OpenMeteo bijvoorbeeld een uitkomst: die geven een range van uitkomsten. Typisch runnen ze dan 21 net verschillende modellen.

[ Voor 9% gewijzigd door Edek op 05-02-2025 16:31 ]

[Bravo]

Solcast werkt ook met een range. De hier weergegeven waarde zijn de mediaan waarden. Daarnaast zijn ook de 10e en de 90e percentiel waarden beschikbaar.
Voor vandaag:
10 3.66
50 7.67
90 9.9
werkelijke opbrengst: 4,7 kWh


De plot van de werkelijke opwek vs de 10 en 50 waarden uit Solcast van vandaag.
Je ziet ook goed dat bij de updates van rond 11:00 en 15:00 er een correctie van de verwachting heeft plaatsgevonden.