evcc Integration for Elastic
Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability This functionality is in technical preview and is ready for evaluation. Use with caution in production; it is not recommended for mission-critical workloads. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. Specific Support terms apply. Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability This functionality is in technical preview and is ready for evaluation. Use with caution in production; it is not recommended for mission-critical workloads. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. Specific Support terms apply. The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability This functionality is in technical preview and is ready for evaluation. Use with caution in production; it is not recommended for mission-critical workloads. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. Specific Support terms apply. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
Serverless Observability
Preview
Preview
Serverless Security
Preview
Preview
Stack
Preview
9.1+
Preview since 9.1
| Version | 0.1.0 Availability Preview This functionality is in technical preview and is ready for evaluation. Use with caution in production; it is not recommended for mission-critical workloads. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. Specific Support terms apply. (View all) |
| Subscription level What's this? |
Basic |
| Developed by What's this? |
Community |
| Ingestion method(s) | API, journald |
| Minimum Kibana version(s) | 9.1.0 8.19.0 |
The evcc integration v0.1.0 is in technical preview
To use pre-release integrations, go to the Integrations page in Kibana, scroll down, and toggle on the Display beta integrations option.
The evcc integration collects site and per-loadpoint metrics, and application logs, from evcc, the open-source solar charging and energy management system. It enables monitoring of solar production, home battery state, grid power flow, EV charging activity, and operational issues (vehicle API errors, device read failures, charger warnings) in Elastic.
This integration collects data from the evcc REST API (/api/state) and, on Linux hosts where evcc runs as a systemd service, from its journald logs. It has been verified against evcc 0.312.x, but is expected to work with other recent evcc releases as well. Refer to the evcc REST API documentation for details. evcc's log line format is not formally documented upstream and may change between releases; unrecognized log lines are still shipped as plain message events rather than being dropped.
This integration uses two collection methods:
- The CEL input periodically polls the evcc REST API. Two metrics data streams each poll
/api/stateindependently: one extracts site-level metrics (solar, grid, battery, home power, cost statistics) and the other splits theloadpointsarray into one event per configured charge point (charging state, power, energy, connected vehicle). - The journald input reads evcc's application logs directly from the systemd journal and parses them into ECS fields.
The evcc integration collects metrics and logs of the following types:
- Site: home power, grid power, solar (PV) power and energy, home battery power/state of charge, and cost/CO2/solar-share statistics for several reporting periods.
- Loadpoint: per-charge-point position (
evcc.loadpoint.index), mode, charging/connected/enabled state, charge power, charged energy, session duration, effective current/SoC limits, and connected vehicle name/SoC/range. - Log: evcc's own application logs collected via journald. Charging session lifecycle events (car connected/disconnected, charging started/stopped), vehicle API errors (timeouts, HTTP error status codes), device read failures (battery/PV/grid meter connectivity), and charger logic warnings are parsed into dedicated ECS fields (
event.action,event.category,event.outcome,destination.ip/port,url.*,http.response.status_code, etc.). High-volume DEBUG-level telemetry lines are kept as plainmessagetext, since the same readings are already collected in structured form by the site and loadpoint data streams.
This integration enables visualizations and alerts for home energy management, such as tracking how much of your EV charging is solar-powered, monitoring home battery state of charge, being notified when a loadpoint stops charging unexpectedly, or alerting on repeated vehicle API or device read failures surfaced in the logs. The integration ships no Kibana assets of its own; build your own visualizations over the data streams listed below.
Logs and loadpoint metrics share a join key: evcc.loadpoint.index on the metrics side and evcc.log.loadpoint on the log side both hold the loadpoint's 1-based position in your evcc configuration, which is the number evcc uses in its lp-<N> log component prefix. Use it to correlate, for example, a charging session with the vehicle API errors logged for the same charge point. Note that the loadpoint data stream collects at most 32 loadpoints.
- A running evcc instance reachable over HTTP from the Elastic Agent, for the site and loadpoint metrics data streams. This integration does not currently support evcc instances that have password protection enabled.
- For the log data stream, evcc must run as a systemd service (the default on Linux installations) so its output is captured by journald, and Elastic Agent must run on that same Linux host with access to the system journal.
Elastic Agent must be installed. For more details, check the Elastic Agent installation instructions. You can install only one Elastic Agent per host.
For the metrics data streams, Elastic Agent polls the evcc REST API directly over HTTP(S). For the log data stream, Elastic Agent must run on the same Linux host as evcc and reads its logs from the local systemd journal. Events are then processed via the integration's ingest pipelines.
- In Kibana, go to Management > Integrations and add the evcc integration.
- Set the evcc URL to the base URL of your evcc instance, e.g.
http://evcc.local:7070. - Optionally adjust the polling Interval for the site and loadpoint data streams (default:
30s). - To collect logs, deploy the log data stream's input to an Elastic Agent running directly on the host where evcc's systemd service runs. Adjust Include Matches if evcc runs under a different systemd unit name than
evcc.service. Consider enabling Drop debug-level logs if you do not need evcc's high-volume DEBUG telemetry. By default the first collection starts at the end of the journal; set Seek toheadif you want evcc's existing journal history backfilled instead. - Assign the integration to an Elastic Agent policy and deploy it to an agent with the required network/host access.
After the integration is running, confirm data is arriving by checking the metrics-evcc.site-*, metrics-evcc.loadpoint-*, and logs-evcc.log-* data streams in Discover.
For help with Elastic ingest tools, check Common problems.
If no metrics appear, verify that the evcc URL is reachable from the host running Elastic Agent (e.g. curl <evcc URL>/api/state) and that no reverse proxy authentication is blocking the request.
If no logs appear, verify that evcc is running as a systemd service on the same host as the Elastic Agent collecting logs (systemctl status evcc), and that the Include Matches filter matches its actual unit name (check with systemctl list-units | grep evcc).
For more information on architectures that can be used for scaling this integration, check the Ingest Architectures documentation.
The site data stream provides site-level metrics from evcc of the following types: home power, grid power, solar power/energy, home battery power/SoC/capacity, and cost/CO2/solar-share statistics.
Exported fields
| Field | Description | Type | Unit | Metric Type |
|---|---|---|---|---|
| @timestamp | Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events. | date | ||
| data_stream.dataset | The field can contain anything that makes sense to signify the source of the data. Examples include nginx.access, prometheus, endpoint etc. For data streams that otherwise fit, but that do not have dataset set we use the value "generic" for the dataset value. event.dataset should have the same value as data_stream.dataset. Beyond the Elasticsearch data stream naming criteria noted above, the dataset value has additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword | ||
| data_stream.namespace | A user defined namespace. Namespaces are useful to allow grouping of data. Many users already organize their indices this way, and the data stream naming scheme now provides this best practice as a default. Many users will populate this field with default. If no value is used, it falls back to default. Beyond the Elasticsearch index naming criteria noted above, namespace value has the additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword | ||
| data_stream.type | An overarching type for the data stream. Currently allowed values are "logs" and "metrics". We expect to also add "traces" and "synthetics" in the near future. | constant_keyword | ||
| error.message | Error message. | match_only_text | ||
| evcc.site.battery.capacity | Home battery capacity, in kWh. | double | gauge | |
| evcc.site.battery.power | Current home battery power, in watts. Positive values indicate discharging, negative values indicate charging. | double | gauge | |
| evcc.site.battery.soc | Home battery state of charge, as a fraction where 1 means 100%. | double | percent | gauge |
| evcc.site.currency | Currency used for cost and tariff values. | keyword | ||
| evcc.site.grid.power | Current grid power, in watts. Positive values indicate import from the grid, negative values indicate export. | double | gauge | |
| evcc.site.home.power | Current home power consumption, in watts. | double | gauge | |
| evcc.site.pv.energy | Cumulative solar (PV) energy produced, in kWh. | double | gauge | |
| evcc.site.pv.power | Current combined solar (PV) power production, in watts. | double | gauge | |
| evcc.site.statistics.last_30d.avg_co2 | Average CO2 intensity of energy used over the last 30 days, in g/kWh. | double | gauge | |
| evcc.site.statistics.last_30d.avg_price | Average energy price per kWh over the last 30 days, in the configured currency. | double | gauge | |
| evcc.site.statistics.last_30d.charged_kwh | Total energy charged over the last 30 days, in kWh. | double | gauge | |
| evcc.site.statistics.last_30d.solar_percentage | Share of charged energy sourced from solar over the last 30 days, as a fraction where 1 means 100%. | double | percent | gauge |
| evcc.site.statistics.last_365d.avg_co2 | Average CO2 intensity of energy used over the last 365 days, in g/kWh. | double | gauge | |
| evcc.site.statistics.last_365d.avg_price | Average energy price per kWh over the last 365 days, in the configured currency. | double | gauge | |
| evcc.site.statistics.last_365d.charged_kwh | Total energy charged over the last 365 days, in kWh. | double | gauge | |
| evcc.site.statistics.last_365d.solar_percentage | Share of charged energy sourced from solar over the last 365 days, as a fraction where 1 means 100%. | double | percent | gauge |
| evcc.site.statistics.this_year.avg_co2 | Average CO2 intensity of energy used in the current year, in g/kWh. | double | gauge | |
| evcc.site.statistics.this_year.avg_price | Average energy price per kWh in the current year, in the configured currency. | double | gauge | |
| evcc.site.statistics.this_year.charged_kwh | Total energy charged in the current year, in kWh. | double | gauge | |
| evcc.site.statistics.this_year.solar_percentage | Share of charged energy sourced from solar in the current year, as a fraction where 1 means 100%. | double | percent | gauge |
| evcc.site.statistics.total.avg_co2 | Average CO2 intensity of energy used across all recorded history, in g/kWh. | double | gauge | |
| evcc.site.statistics.total.avg_price | Average energy price per kWh across all recorded history, in the configured currency. | double | gauge | |
| evcc.site.statistics.total.charged_kwh | Total energy charged across all recorded history, in kWh. | double | gauge | |
| evcc.site.statistics.total.solar_percentage | Share of charged energy sourced from solar across all recorded history, as a fraction where 1 means 100%. | double | percent | gauge |
| evcc.site.title | Configured title of the evcc site. | keyword | ||
| evcc.site.version | evcc software version. | keyword | ||
| event.dataset | Name of the dataset. If an event source publishes more than one type of log or events (e.g. access log, error log), the dataset is used to specify which one the event comes from. It's recommended but not required to start the dataset name with the module name, followed by a dot, then the dataset name. | constant_keyword | ||
| event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. |
keyword | ||
| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), event.module should contain the name of this module. |
constant_keyword | ||
| event.original | Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from _source. If users wish to override this and index this field, please see Field data types in the Elasticsearch Reference. |
keyword | ||
| input.type | Type of input that generated the event. | keyword | ||
| service.address | Address where data about this service was collected from. This should be a URI, network address (ipv4:port or [ipv6]:port) or a resource path (sockets). | keyword | ||
| tags | List of keywords used to tag each event. | keyword |
Example
{
"@timestamp": "2026-11-03T09:12:43.103Z",
"agent": {
"ephemeral_id": "9ec72002-833d-46bf-8e70-1a04c148b35e",
"id": "c49aac7d-5bc3-4267-bbc3-95f3d7db4579",
"name": "elastic-agent-39334",
"type": "filebeat",
"version": "8.19.0"
},
"data_stream": {
"dataset": "evcc.site",
"namespace": "59887",
"type": "metrics"
},
"ecs": {
"version": "9.3.0"
},
"elastic_agent": {
"id": "c49aac7d-5bc3-4267-bbc3-95f3d7db4579",
"snapshot": false,
"version": "8.19.0"
},
"evcc": {
"site": {
"battery": {
"capacity": 13.4,
"power": 0,
"soc": 0.76
},
"currency": "EUR",
"grid": {
"power": -407.8566601636994
},
"home": {
"power": 500
},
"pv": {
"energy": 24521.3,
"power": 8307.59154846352
},
"statistics": {
"last_30d": {
"avg_co2": 62.14859311838828,
"avg_price": 0.11162431782896463,
"charged_kwh": 221.77069867393018,
"solar_percentage": 0.8370583267207702
},
"last_365d": {
"avg_co2": 62.14859311838828,
"avg_price": 0.11162431782896463,
"charged_kwh": 221.77069867393018,
"solar_percentage": 0.8370583267207702
},
"this_year": {
"avg_co2": 62.14859311838828,
"avg_price": 0.11162431782896463,
"charged_kwh": 221.77069867393018,
"solar_percentage": 0.8370583267207702
},
"total": {
"avg_co2": 62.14859311838828,
"avg_price": 0.11162431782896463,
"charged_kwh": 221.77069867393018,
"solar_percentage": 0.8370583267207702
}
},
"title": "My Home",
"version": "0.312.1"
}
},
"event": {
"agent_id_status": "verified",
"dataset": "evcc.site",
"ingested": "2026-11-03T09:12:46Z",
"kind": "metric",
"original": "{\"battery\":{\"capacity\":13.4,\"devices\":[{\"capacity\":13.4,\"controllable\":true,\"name\":\"battery\",\"power\":0,\"soc\":76}],\"power\":0,\"soc\":76},\"currency\":\"EUR\",\"grid_power\":-407.8566601636994,\"home_power\":500,\"pv_energy\":24521.3,\"pv_power\":8307.59154846352,\"service_address\":\"http://svc-evcc:8080\",\"site_title\":\"My Home\",\"statistics\":{\"30d\":{\"avgCo2\":62.14859311838828,\"avgPrice\":0.11162431782896463,\"chargedKWh\":221.77069867393018,\"solarPercentage\":83.70583267207702},\"365d\":{\"avgCo2\":62.14859311838828,\"avgPrice\":0.11162431782896463,\"chargedKWh\":221.77069867393018,\"solarPercentage\":83.70583267207702},\"thisYear\":{\"avgCo2\":62.14859311838828,\"avgPrice\":0.11162431782896463,\"chargedKWh\":221.77069867393018,\"solarPercentage\":83.70583267207702},\"total\":{\"avgCo2\":62.14859311838828,\"avgPrice\":0.11162431782896463,\"chargedKWh\":221.77069867393018,\"solarPercentage\":83.70583267207702}},\"version\":\"0.312.1\"}"
},
"input": {
"type": "cel"
},
"service": {
"address": "http://svc-evcc:8080"
},
"tags": [
"preserve_original_event",
"forwarded",
"evcc-site"
]
}
The loadpoint data stream provides one event per evcc loadpoint (charge point) of the following types: mode, charging/connected/enabled state, charge power/energy/duration, effective current/SoC limits, and connected vehicle details.
Exported fields
| Field | Description | Type | Unit | Metric Type |
|---|---|---|---|---|
| @timestamp | Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events. | date | ||
| data_stream.dataset | The field can contain anything that makes sense to signify the source of the data. Examples include nginx.access, prometheus, endpoint etc. For data streams that otherwise fit, but that do not have dataset set we use the value "generic" for the dataset value. event.dataset should have the same value as data_stream.dataset. Beyond the Elasticsearch data stream naming criteria noted above, the dataset value has additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword | ||
| data_stream.namespace | A user defined namespace. Namespaces are useful to allow grouping of data. Many users already organize their indices this way, and the data stream naming scheme now provides this best practice as a default. Many users will populate this field with default. If no value is used, it falls back to default. Beyond the Elasticsearch index naming criteria noted above, namespace value has the additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword | ||
| data_stream.type | An overarching type for the data stream. Currently allowed values are "logs" and "metrics". We expect to also add "traces" and "synthetics" in the near future. | constant_keyword | ||
| error.message | Error message. | match_only_text | ||
| evcc.loadpoint.charge.duration.sec | Duration of the current charging session, in seconds. | double | gauge | |
| evcc.loadpoint.charge.energy | Energy charged during the current charging session, in Wh. | double | gauge | |
| evcc.loadpoint.charge.power | Current charging power at the loadpoint, in watts. | double | gauge | |
| evcc.loadpoint.charge.remaining_duration.sec | Estimated remaining duration until the charging target is reached, in seconds. | double | gauge | |
| evcc.loadpoint.charge.remaining_energy | Estimated remaining energy required to reach the charging target, in Wh. | double | gauge | |
| evcc.loadpoint.charger_status_reason | Reason reported by the charger for its current status. | keyword | ||
| evcc.loadpoint.charging | Whether the loadpoint is currently charging. | boolean | ||
| evcc.loadpoint.connected | Whether a vehicle is currently connected to the loadpoint. | boolean | ||
| evcc.loadpoint.connected_duration.sec | Duration a vehicle has been connected to the loadpoint, in seconds. | double | gauge | |
| evcc.loadpoint.effective.limit_soc | Effective vehicle state-of-charge charging limit for this loadpoint, as a fraction where 1 means 100%. | double | percent | gauge |
| evcc.loadpoint.effective.max_current | Effective maximum charging current for this loadpoint, in amperes. | double | gauge | |
| evcc.loadpoint.effective.min_current | Effective minimum charging current for this loadpoint, in amperes. | double | gauge | |
| evcc.loadpoint.enabled | Whether charging is enabled on the loadpoint. | boolean | ||
| evcc.loadpoint.index | 1-based position of the loadpoint in the evcc configuration. evcc uses the same number to identify loadpoints in its logs, where it appears as the lp-\<N\> component prefix and is mapped to evcc.log.loadpoint, so this field joins loadpoint metrics to loadpoint logs. |
long | ||
| evcc.loadpoint.last_24h_energy | Energy charged at this loadpoint over the last 24 hours, in Wh. | double | gauge | |
| evcc.loadpoint.last_7d_energy | Energy charged at this loadpoint over the last 7 days, in Wh. | double | gauge | |
| evcc.loadpoint.mode | Charging mode of the loadpoint, e.g. off, now, minpv, or pv. | keyword | ||
| evcc.loadpoint.title | Configured name of the loadpoint. | keyword | ||
| evcc.loadpoint.vehicle.id | Configuration name of the vehicle currently assigned to this loadpoint, as defined in the evcc configuration (evcc's vehicleName, for example my_car). |
keyword | ||
| evcc.loadpoint.vehicle.name | Display title of the vehicle currently assigned to this loadpoint (evcc's vehicleTitle). | keyword | ||
| evcc.loadpoint.vehicle.range | Estimated remaining range of the vehicle currently assigned to this loadpoint, in km. | double | gauge | |
| evcc.loadpoint.vehicle.soc | State of charge of the vehicle currently assigned to this loadpoint, as a fraction where 1 means 100%. | double | percent | gauge |
| evcc.site.title | Configured title of the evcc site this loadpoint belongs to. | keyword | ||
| event.dataset | Name of the dataset. If an event source publishes more than one type of log or events (e.g. access log, error log), the dataset is used to specify which one the event comes from. It's recommended but not required to start the dataset name with the module name, followed by a dot, then the dataset name. | constant_keyword | ||
| event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. |
keyword | ||
| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), event.module should contain the name of this module. |
constant_keyword | ||
| event.original | Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from _source. If users wish to override this and index this field, please see Field data types in the Elasticsearch Reference. |
keyword | ||
| input.type | Type of input that generated the event. | keyword | ||
| service.address | Address where data about this service was collected from. This should be a URI, network address (ipv4:port or [ipv6]:port) or a resource path (sockets). | keyword | ||
| tags | List of keywords used to tag each event. | keyword |
Example
{
"@timestamp": "2026-11-03T09:11:05.400Z",
"agent": {
"ephemeral_id": "25386234-4fc6-46bf-accc-15f99d301d39",
"id": "06811ca8-dae6-4276-9603-aa15328546be",
"name": "elastic-agent-10771",
"type": "filebeat",
"version": "8.19.0"
},
"data_stream": {
"dataset": "evcc.loadpoint",
"namespace": "51172",
"type": "metrics"
},
"ecs": {
"version": "9.3.0"
},
"elastic_agent": {
"id": "06811ca8-dae6-4276-9603-aa15328546be",
"snapshot": false,
"version": "8.19.0"
},
"evcc": {
"loadpoint": {
"charge": {
"duration": {
"sec": 91241
},
"energy": 103212.794,
"power": 6900,
"remaining_duration": {
"sec": 41739
},
"remaining_energy": 40000
},
"charger_status_reason": "unknown",
"charging": true,
"connected": true,
"connected_duration": {
"sec": 3600
},
"effective": {
"limit_soc": 0.95,
"max_current": 13,
"min_current": 3
},
"enabled": true,
"index": 1,
"last_24h_energy": 88014,
"last_7d_energy": 190432,
"mode": "pv",
"title": "Garage",
"vehicle": {
"id": "my_car",
"name": "blue e-Golf",
"range": 210,
"soc": 0.63
}
},
"site": {
"title": "My Home"
}
},
"event": {
"agent_id_status": "verified",
"dataset": "evcc.loadpoint",
"ingested": "2026-11-03T09:11:08Z",
"kind": "metric",
"original": "{\"charge_duration\":91241,\"charge_power\":6900,\"charge_remaining_duration\":41739,\"charge_remaining_energy\":40000,\"charged_energy\":103212.794,\"charger_status_reason\":\"unknown\",\"charging\":true,\"connected\":true,\"connected_duration\":3600,\"effective_limit_soc\":95,\"effective_max_current\":13,\"effective_min_current\":3,\"enabled\":true,\"index\":1,\"last_24h_energy\":88014,\"last_7d_energy\":190432,\"mode\":\"pv\",\"service_address\":\"http://svc-evcc:8080\",\"site_title\":\"My Home\",\"title\":\"Garage\",\"vehicle_id\":\"my_car\",\"vehicle_name\":\"blue e-Golf\",\"vehicle_range\":210,\"vehicle_soc\":63}"
},
"input": {
"type": "cel"
},
"service": {
"address": "http://svc-evcc:8080"
},
"tags": [
"preserve_original_event",
"forwarded",
"evcc-loadpoint"
]
}
The log data stream provides evcc's own application logs, collected via journald, of the following types: charging session lifecycle events, vehicle API errors, device read failures, charger logic warnings, and DEBUG-level telemetry (kept as plain text).
Exported fields
| Field | Description | Type |
|---|---|---|
| @timestamp | Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events. | date |
| data_stream.dataset | The field can contain anything that makes sense to signify the source of the data. Examples include nginx.access, prometheus, endpoint etc. For data streams that otherwise fit, but that do not have dataset set we use the value "generic" for the dataset value. event.dataset should have the same value as data_stream.dataset. Beyond the Elasticsearch data stream naming criteria noted above, the dataset value has additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword |
| data_stream.namespace | A user defined namespace. Namespaces are useful to allow grouping of data. Many users already organize their indices this way, and the data stream naming scheme now provides this best practice as a default. Many users will populate this field with default. If no value is used, it falls back to default. Beyond the Elasticsearch index naming criteria noted above, namespace value has the additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword |
| data_stream.type | An overarching type for the data stream. Currently allowed values are "logs" and "metrics". We expect to also add "traces" and "synthetics" in the near future. | constant_keyword |
| destination.ip | IP address of the destination (IPv4 or IPv6). | ip |
| destination.port | Port of the destination. | long |
| error.message | Error message. | match_only_text |
| evcc.log.available_version | evcc version reported as available in a "new version available" notice. | keyword |
| evcc.log.component | evcc log component/module that emitted the line, e.g. site, lp-1, main, sma. | keyword |
| evcc.log.current_actual | Actual charging current reported by the charger during a current mismatch warning, in amperes. | float |
| evcc.log.current_expected | Charging current evcc expected during a current mismatch warning, in amperes. | float |
| evcc.log.current_limit | Charge current limit evcc attempted to set when a set-current-limit call timed out, in amperes. | float |
| evcc.log.device_index | Configured index of the device within its subsystem (1-based), e.g. battery 1, pv 2. | long |
| evcc.log.device_sub_index | Index of the underlying meter/adder read that failed (0-based), from evcc's internal add[N] wrapper. | long |
| evcc.log.error_reason | Failure detail reported by evcc for a vehicle API call or device read (e.g. "connect: connection refused", "context deadline exceeded"). Kept as a dedicated field rather than ECS error.message, which is reserved for ingest pipeline processing errors. |
keyword |
| evcc.log.http_status_text | HTTP status text reported by a vehicle API call, e.g. Forbidden, Internal Server Error. | keyword |
| evcc.log.ignored_by_estimator | Whether evcc reported that a failed vehicle metric read was ignored by its SoC estimator. | boolean |
| evcc.log.loadpoint | Loadpoint index, parsed from a component value of the form lp-<N>. | long |
| evcc.log.min_interval_sec | Minimum polling interval evcc recommends to avoid charger logic current-mismatch warnings, in seconds. | long |
| evcc.log.phases_actual | Actual active phase count reported by the charger during a phases mismatch warning. | long |
| evcc.log.phases_expected | Phase count evcc expected during a phases mismatch warning. | long |
| evcc.log.reading | The reading that failed to be read, e.g. power, soc, energy. | keyword |
| evcc.log.subsystem | Site subsystem a device read failure relates to, e.g. battery, pv. | keyword |
| evcc.log.vehicle_metric | Vehicle metric a failed API call was attempting to refresh, e.g. soc, soc_limit, range, odometer. | keyword |
| event.action | The action captured by the event. This describes the information in the event. It is more specific than event.category. Examples are group-add, process-started, file-created. The value is normally defined by the implementer. |
keyword |
| event.category | This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. event.category represents the "big buckets" of ECS categories. For example, filtering on event.category:process yields all events relating to process activity. This field is closely related to event.type, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. |
keyword |
| event.dataset | Name of the dataset. If an event source publishes more than one type of log or events (e.g. access log, error log), the dataset is used to specify which one the event comes from. It's recommended but not required to start the dataset name with the module name, followed by a dot, then the dataset name. | constant_keyword |
| event.duration | Duration of the event in nanoseconds. If event.start and event.end are known this value should be the difference between the end and start time. |
long |
| event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. |
keyword |
| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), event.module should contain the name of this module. |
constant_keyword |
| event.original | Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from _source. If users wish to override this and index this field, please see Field data types in the Elasticsearch Reference. |
keyword |
| event.outcome | This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. event.outcome simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of event.outcome, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with event.type:info, or any events for which an outcome does not make logical sense. |
keyword |
| event.type | This is one of four ECS Categorization Fields, and indicates the third level in the ECS category hierarchy. event.type represents a categorization "sub-bucket" that, when used along with the event.category field values, enables filtering events down to a level appropriate for single visualization. This field is an array. This will allow proper categorization of some events that fall in multiple event types. |
keyword |
| host.hostname | Hostname of the host. It normally contains what the hostname command returns on the host machine. |
keyword |
| http.response.status_code | HTTP response status code. | long |
| input.type | Type of input that generated the event. | keyword |
| journald.custom.runtime_scope | The runtime scope in which the journal entry was captured, either initrd or system. |
keyword |
| journald.custom.seqnum | The sequence number of the journal entry in the journal it was read from. | keyword |
| journald.custom.seqnum_id | The identifier of the sequence number the journal entry belongs to, formatted as a 128-bit hexadecimal string. | keyword |
| journald.custom.stream_id | The identifier of the stream the journal entry was read from, formatted as a 128-bit hexadecimal string. | keyword |
| journald.gid | The group ID of the process the journal entry originates from. | long |
| journald.host.boot_id | The kernel boot ID for the boot the message was generated in, formatted as a 128-bit hexadecimal string. | keyword |
| journald.pid | The process ID of the process the journal entry originates from. | long |
| journald.process.capabilities | The effective capabilities of the process the journal entry originates from, formatted as a hexadecimal string. | keyword |
| journald.process.command_line | The command line of the process the journal entry originates from. | keyword |
| journald.process.executable | The path to the executable of the process the journal entry originates from. | keyword |
| journald.process.name | The name of the process the journal entry originates from. | keyword |
| journald.uid | The user ID of the process the journal entry originates from. | long |
| log.level | Original log level of the log event. If the source of the event provides a log level or textual severity, this is the one that goes in log.level. If your source doesn't specify one, you may put your event transport's severity here (e.g. Syslog severity). Some examples are warn, err, i, informational. |
keyword |
| log.origin.file.line | The line number of the file containing the source code which originated the log event. | long |
| log.origin.file.name | The name of the file containing the source code which originated the log event. Note that this field is not meant to capture the log file. The correct field to capture the log file is log.file.path. |
keyword |
| log.origin.function | The name of the function or method which originated the log event. | keyword |
| log.syslog.appname | The device or application that originated the Syslog message, if available. | keyword |
| log.syslog.facility.code | The Syslog numeric facility of the log event, if available. According to RFCs 5424 and 3164, this value should be an integer between 0 and 23. | long |
| log.syslog.priority | Syslog numeric priority of the event, if available. According to RFCs 5424 and 3164, the priority is 8 * facility + severity. This number is therefore expected to contain a value between 0 and 191. | long |
| log.syslog.procid | The process name or ID that originated the Syslog message, if available. | keyword |
| message | For log events the message field contains the log message, optimized for viewing in a log viewer. For structured logs without an original message field, other fields can be concatenated to form a human-readable summary of the event. If multiple messages exist, they can be combined into one message. | match_only_text |
| related.ip | All of the IPs seen on your event. | ip |
| systemd.cgroup | The control group path the journal entry originates from. | keyword |
| systemd.invocation_id | The invocation ID of the systemd unit the journal entry originates from. | keyword |
| systemd.slice | The systemd slice the journal entry originates from. | keyword |
| systemd.transport | How the entry was received by the journal service. | keyword |
| systemd.unit | The systemd unit the journal entry originates from. | keyword |
| tags | List of keywords used to tag each event. | keyword |
| url.domain | Domain of the url, such as "www.elastic.co". In some cases a URL may refer to an IP and/or port directly, without a domain name. In this case, the IP address would go to the domain field. If the URL contains a literal IPv6 address enclosed by [ and ] (IETF RFC 2732), the [ and ] characters should also be captured in the domain field. |
keyword |
| url.extension | The field contains the file extension from the original request url, excluding the leading dot. The file extension is only set if it exists, as not every url has a file extension. The leading period must not be included. For example, the value must be "png", not ".png". Note that when the file name has multiple extensions (example.tar.gz), only the last one should be captured ("gz", not "tar.gz"). | keyword |
| url.fragment | Portion of the url after the #, such as "top". The # is not part of the fragment. |
keyword |
| url.original | Unmodified original url as seen in the event source. Note that in network monitoring, the observed URL may be a full URL, whereas in access logs, the URL is often just represented as a path. This field is meant to represent the URL as it was observed, complete or not. | wildcard |
| url.original.text | Multi-field of url.original. |
match_only_text |
| url.password | Password of the request. | keyword |
| url.path | Path of the request, such as "/search". | wildcard |
| url.port | Port of the request, such as 443. | long |
| url.query | The field contains the entire query string, excluding the leading ? character, such as "q=elasticsearch". If a URL contains no ?, there is no query field. If there is a ? but no query, the query field exists with an empty string. The exists query can be used to differentiate between the two cases. |
keyword |
| url.registered_domain | The highest registered url domain, stripped of the subdomain. For example, the registered domain for "foo.example.com" is "example.com". This value can be determined precisely with a list like the public suffix list (https://publicsuffix.org). Trying to approximate this by simply taking the last two labels will not work well for TLDs such as "co.uk". | keyword |
| url.scheme | Scheme of the request, such as "https". Note: The : is not part of the scheme. |
keyword |
| url.subdomain | The subdomain portion of a fully qualified domain name includes all of the names except the host name under the registered_domain. In a partially qualified domain, or if the the qualification level of the full name cannot be determined, subdomain contains all of the names below the registered domain. For example the subdomain portion of "www.east.example.com" is "east". If the domain has multiple levels of subdomain, such as "sub2.sub1.example.com", the subdomain field should contain "sub2.sub1", with no trailing period. | keyword |
| url.top_level_domain | The effective top level domain (eTLD), also known as the domain suffix, is the last part of the domain name. For example, the top level domain for example.com is "com". This value can be determined precisely with a list like the public suffix list (https://publicsuffix.org). Trying to approximate this by simply taking the last label will not work well for effective TLDs such as "co.uk". | keyword |
| url.username | Username of the request. | keyword |
Example
{
"@timestamp": "2026-07-23T11:48:23.601Z",
"agent": {
"ephemeral_id": "9437d1ca-a9e7-4632-b5c4-30350e512c10",
"id": "0a170f41-5d11-4a32-ae09-f9a07badc69e",
"name": "elastic-agent-51182",
"type": "filebeat",
"version": "8.19.0"
},
"data_stream": {
"dataset": "evcc.log",
"namespace": "48110",
"type": "logs"
},
"ecs": {
"version": "9.3.0"
},
"elastic_agent": {
"id": "0a170f41-5d11-4a32-ae09-f9a07badc69e",
"snapshot": false,
"version": "8.19.0"
},
"evcc": {
"log": {
"component": "site"
}
},
"event": {
"agent_id_status": "verified",
"created": "2026-11-03T09:11:53.483Z",
"dataset": "evcc.log",
"ingested": "2026-11-03T09:11:56Z",
"kind": "event"
},
"host": {
"hostname": "test-host",
"id": "9a1b3c5d7e9f0a2b4c6d8e0f1a2b3c4d"
},
"input": {
"type": "journald"
},
"journald": {
"custom": {
"runtime_scope": "system",
"seqnum": "1",
"seqnum_id": "5f1cd4bc63dd4cd9bd55a0b4363414c0",
"stream_id": "aa1bb2cc3dd4ee5ff607a8b9c0d1e2f3"
},
"gid": 111,
"host": {
"boot_id": "6f2a1c9d7e4b4f1a9c3e8d2b5a7f0c31"
},
"pid": 274550,
"process": {
"capabilities": "400",
"command_line": "/usr/bin/evcc",
"executable": "/usr/bin/evcc",
"name": "evcc"
},
"uid": 106
},
"log": {
"level": "debug",
"syslog": {
"appname": "evcc",
"facility": {
"code": 3
},
"priority": 6
}
},
"message": "site power: -4745W",
"process": {
"args": [
"/usr/bin/evcc"
],
"args_count": 1,
"command_line": "/usr/bin/evcc",
"pid": 274550,
"thread": {
"capabilities": {
"effective": [
"CAP_NET_BIND_SERVICE"
]
}
}
},
"systemd": {
"cgroup": "/system.slice/evcc.service",
"invocation_id": "d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9",
"slice": "system.slice",
"transport": "stdout",
"unit": "evcc.service"
},
"tags": [
"forwarded"
],
"user": {
"group": {
"id": "111"
},
"id": "106"
}
}
These inputs can be used with this integration:
cel
For more details about the CEL input settings, check the Filebeat documentation.
Before configuring the CEL input, make sure you have:
- Network connectivity to the target API endpoint
- Valid authentication credentials (API keys, tokens, or certificates as required)
- Appropriate permissions to read from the target data source
To configure the CEL input, you must specify the request.url value pointing to the API endpoint. The interval parameter controls how frequently requests are made and is the primary way to balance data freshness with API rate limits and costs. Authentication is often configured through the request.headers section using the appropriate method for the service.
Note
To access the API service, make sure you have the necessary API credentials and that the Filebeat instance can reach the endpoint URL. Some services may require IP whitelisting or VPN access.
To collect logs via API endpoint, configure the following parameters:
- API Endpoint URL
- API credentials (tokens, keys, or username/password)
- Request interval (how often to fetch data)
journald
For more details about the Journald input settings, check the Filebeat documentation.
To collect logs via Journald, select Collect logs via journald and configure the following parameter:
- Condition: Condition to filter when to apply this input
These APIs are used with this integration:
GET /api/state— returns the complete state of the evcc instance, including site, loadpoint, and vehicle data.
Changelog
| Version | Details | Minimum Kibana version |
|---|---|---|
| 0.1.0 | Enhancement (View pull request) Initial release of the evcc integration. Collects site and loadpoint metrics from the evcc REST API, and evcc application logs via journald, parsed into ECS fields. |
9.1.0 8.19.0 |