What the Data Looks Like
Photovoltaic project yield data comes primarily from two sources: SCADA monitoring systems for photovoltaic power stations and grid connection dispatching platforms. This data supports daily yield reporting for financial institutions. Data is updated once per day, with full statistics for the previous day completed in the early morning. Each data entry uses structured JSON format. Core fields include: unique power station identifier, statistical date, total daily power generation, grid-connected power sold, self-generated and self-consumed power, and power generation per installed capacity. All fields have clear physical units. For example, power generation uses kilowatt-hours as the unit, and power generation per installed capacity uses kilowatt-hours per kilowatt. No extra formatted decorative fields are included.
Constraints for HTTP Interfaces and External Systems
This use case for daily photovoltaic yield reporting requires HTTP interfaces to support integration with at least two different external systems. Cross-origin request authentication parameters must be configured. The daily update rhythm means HTTP polling does not need high frequency. Scheduled task intervals must match the data update cycle to avoid invalid requests consuming resources from financial systems. Since all fields carry clear units, HTTP interface responses must retain unit information, or downstream systems must uniformly parse unit fields. This prevents unit confusion that could reduce report accuracy. Aggregation requirements by power station mean HTTP interfaces must support filtering using the power station ID as a parameter, to enable precise pulling of data for a single station.
Configuration Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
request_timeout | 300-600 seconds | Photovoltaic cross-source data pulling requires integration with inverter platforms and grid interfaces. Total processing time is long, so the timeout must cover full workflow duration |
retry_count | 2-3 times | Grid interfaces may experience temporary fluctuations. Retries reduce the failure rate of individual requests |
filter_param_key | station_id | Photovoltaic data is aggregated by power station. Filtering results by station ID ensures precise matching of data for a single station |
response_parse_mode | json_path | Photovoltaic data returns in structured JSON format. Specified fields must be extracted for daily report generation and downstream data transfer |
schedule_interval | 86400 seconds | Photovoltaic yield data is updated daily. High-frequency polling is unnecessary, so the interval must match the daily update cycle |
max_response_size | 100 MB | Maximum single response size for full historical data of one power station. This prevents memory overflow in workflow nodes |
The parameter values provided on this page are common recommended starting points for configuration. Actual values are affected by material form, data volume and business rules. Each scenario requires individual analysis. It is recommended to test with your own samples before finalizing values.
Three Common Configuration Mistakes
- Phenomenon: Downstream nodes cannot retrieve extracted variables after an HTTP request returns data. Cause:
response_parse_modeis not correctly configured asjson_path, or no properly formatted JSONPath expression is provided. - Phenomenon: A 400 status code is returned after a scheduled task triggers. Cause: The
station_idfield is not included in the request parameters, so the power station dimension filtering rules cannot be matched. - Phenomenon: HTTP requests time out or are rate-limited by the interface. Cause:
schedule_intervalis incorrectly set to a value smaller than 86400 seconds. High-frequency polling triggers access restrictions from external systems.
How to Verify Proper Configuration
- Manually trigger the HTTP request node, check if the returned results include the expected photovoltaic data fields, and verify that field units match the data source definitions.
- Check the scheduled task logs for the workflow, confirm that requests trigger daily in the early morning at the set interval, with no duplicate or missed execution records.
- Verify that extracted variables can be correctly passed to downstream daily report generation nodes, with no null values or format errors.
- Simulate an interface delay scenario, adjust
request_timeoutto a shorter value, confirm that the retry mechanism triggers normally and no data is lost.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.