evcc Integration for Elastic
Version 0.1.0 (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/state independently: one extracts site-level metrics (solar, grid, battery, home power, cost statistics) and the other splits the loadpoints array 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 plain message text, 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.

  1. In Kibana, go to Management > Integrations and add the evcc integration.
  2. Set the evcc URL to the base URL of your evcc instance, e.g. http://evcc.local:7070.
  3. Optionally adjust the polling Interval for the site and loadpoint data streams (default: 30s).
  4. 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 to head if you want evcc's existing journal history backfilled instead.
  5. 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