Skip to content

Enable HA REST API proxy#142

Open
wlcrs wants to merge 1 commit into
evcc-io:mainfrom
wlcrs:enable-ha-api
Open

Enable HA REST API proxy#142
wlcrs wants to merge 1 commit into
evcc-io:mainfrom
wlcrs:enable-ha-api

Conversation

@wlcrs

@wlcrs wlcrs commented Mar 10, 2025

Copy link
Copy Markdown

By adding this line to the add-on configuration, we enable the internal proxy that exposes the HA REST API to the add-on.

In practice, this makes it possible to read the state of HA sensor via the http://supervisor/core/api/ endpoint, using the authentication token supplied in the SUPERVISOR_TOKEN environment variable (cfr. HA docs).

This effectively allows us to more easily integrate EVCC with HA, as you will no longer need to create long-lived tokens in HA to be able to read sensor data from it. For example: we could easily enable the use of HA entities in the Configuration UI.

Demo:

app # curl -X GET -H "Authorization: Bearer ${SUPERVISOR_TOKEN}" -H "Content-Type: application/json" http://supervisor/core/api/states/sensor.p1_meter_energy_import | jq
{
  "entity_id": "sensor.p1_meter_energy_import",
  "state": "6026.345",
  "attributes": {
    "state_class": "total_increasing",
    "unit_of_measurement": "kWh",
    "device_class": "energy",
    "friendly_name": "P1 Meter Energy import"
  },
  "last_changed": "2025-03-10T15:22:56.566781+00:00",
  "last_reported": "2025-03-10T15:42:11.567678+00:00",
  "last_updated": "2025-03-10T15:22:56.566781+00:00",
  "context": {
    "id": "01JP0ADSNPW2E01B35Y5XXGA2S",
    "parent_id": null,
    "user_id": null
  }
}

(jq and curl were installed into the add-on container for testing/demonstration purposes)

@dm82m

dm82m commented Mar 10, 2025

Copy link
Copy Markdown
Contributor

@thecem @goebelmeier i think this I a good improvement. I am using a bearer token currently and with this change I could just skip that and rely on the internal api proxy.

@thecem

thecem commented Mar 10, 2025

Copy link
Copy Markdown
Collaborator

@wlcrs pls test in nightly

@dm82m

dm82m commented Mar 10, 2025

Copy link
Copy Markdown
Contributor

already tested it @thecem

image

@dm82m

dm82m commented Mar 10, 2025

Copy link
Copy Markdown
Contributor

@wlcrs do you know how to access these env vars within the evcc config?

image

with that I do not get it work

@thecem

thecem commented Mar 10, 2025

Copy link
Copy Markdown
Collaborator

This is a main topic since the variable must be accessible within evcc. Don’t know if we have to add those var in evcc.

@dm82m

dm82m commented Mar 10, 2025

Copy link
Copy Markdown
Contributor

currently its not working within the evcc.yaml that this variable gets resolved:

[lp-1 ] ERROR 2025/03/10 17:53:49 vehicle soc: unexpected status: 401 (Unauthorized)

@wlcrs

wlcrs commented Mar 10, 2025

Copy link
Copy Markdown
Author

Adding support to reading/using this environment variable in/by evcc is the next step. So for the moment we have nothing to test against.

@thecem this is a bit of a chicken-or-egg situation. I thought that first introducing this PR was the most straightforward, as it has no other impact whatsoever. Would you consider merging it if I only introduce the change to evcc-nightly for now?

@thecem

thecem commented Mar 10, 2025

Copy link
Copy Markdown
Collaborator

? It is implemented, but in the right place.
Next step should be to have a change on evcc side ( if needed).

@dm82m

dm82m commented Mar 10, 2025

Copy link
Copy Markdown
Contributor

@wlcrs we just need solutions on both sides. makes no sense to just integrate it here if there is no solution on evcc side itself. so we need to find a solution there, create a PR there and if this is done we can finally merge in the PR here.

I guess I found the solution, on evcc side in setup.go line 88 we need to call:
viper.AutomaticEnv()

I tested it, was not successful. as far as I understand, viper is not replacing the vars it finds in the config.yaml. it just reads in the config.yaml and provides all the data found there into the go application.
And with viper.AutomaticEnv() it just adds the env vars into the go app itself.

this article also describes that: https://stackoverflow.com/questions/52756532/go-viper-yaml-values-environment-variables-override

in evcc dev chat I raised the question aswell: https://evccgroup.slack.com/archives/C01321PUJAD/p1741625264523309

@wlcrs

wlcrs commented Mar 11, 2025

Copy link
Copy Markdown
Author

I've written up a proposal on how we can use the HA REST API proxy enabled by this PR here: evcc-io/evcc#19665

Any feedback would be appreciated, as I want to prevent to put work into coding features that the EVCC-team would not consider to merge.

@dm82m

dm82m commented Mar 11, 2025

Copy link
Copy Markdown
Contributor

draft PR: evcc-io/evcc#19687

andi declined this PR due to sundown of yaml config, so we need to find a solution in ui config to use env vars... -> evcc-io/evcc#19687 (comment)

@thecem

thecem commented May 7, 2026

Copy link
Copy Markdown
Collaborator

@wlcrs @dm82m
This strongly suggests that we should not try to “fix YAML environment variable replacement”, but instead implement a “Supervisor” option on the UI side ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants