Make sure you update and regenerate the OpenAPI spec (and any MCP artifacts) before merging so the docs match the new JSON responses.

Schlaubi ;)

@naltatis integration hab ich wohl verdaddelt- dass das dann 17 Minuten läuft ist aber auch nicht schön?

dass das dann 17 Minuten läuft ist aber auch nicht schön?

ich schau mir die Timeouts mal an.

@TheNinth7 Ich denke dieser PR wird für deine Garmin App Breaking.

No hurry, lets see if we can get this working first and then prepare transition.

@TheNinth7 Ich denke dieser PR wird für deine Garmin App Breaking.

Ja, Danke für den Hinweis, werde die App entsprechend vorbereiten!

... currently the existence of a result object (in json response) is a true indication (in the ha-evcc), that there had been no other issues/errors with the request/response...

So when this result container object will be removed, at least the possible error evaluation & handling will become more complex...

currently the existence of a result object (in json response) is a true indication (in the ha-evcc), that there had been no other issues/errors with the request/response

How about checking whether the status code is 200?

Exactly that 👍🏻

How about checking whether the status code is 200?

of course the ha-integration is checking for http status 200, before reading any json data... I personally prefer, when http status codes are not used to indicate application layer information - so http 200 must not mean, that the response itself have valid/consistent data... But since this is just my opinion, and since it's your project, I will adopt to this change.

I'm not saying that it necessarily does but at the same time I'm not aware of any best practice requiring wrapping json payloads in top level elements which is what we're changing here.

and since it's your project,

I disagree (and I personally don't like the wording). It is a community project and we're open to feedback! Adhering to best practices certainly is of high value to us.

I disagree (and I personally don't like the wording). It is a community project and we're open to feedback! Adhering to best practices certainly is of high value to us.

I must assume, before starting with this breaking 'everything' change, you had internally (e.g. in slack) discussed the pro's & con's already. I highly appreciate the overall structure of this project and the clean code principles. So there is great experience & expertise in the core development group. Getting rid of an obsolete container object seams to be reasonable.

The only thing I wanted to remark was triggert by "why not (simply) check for http 200?" - From my point of view, http 200 should not be the indicator, that the response object is in the expected format or structure. So processing any API response with http status 200 must be done with care and without any additional assumptions.

In the HA integration, I have (mis)used the presence of the result container in any of the API responses, as validation: that the request was processed by an evcc-endpoint and "seams to be valid in it's internal structure" - at least it has not been generated by any infrastructure in between. For sure this approach was also far from being perfect, but IMHO it is quite a cheap' approach (CPU & data wise) and nobody really want to return to SOAP.

So when the result will not be present any longer, I have to rethink the current data-validation-procedure - which probably take less time, then writing this reply :-)

• ha-evcc @marq24 - handling implemented with release https://github.com/marq24/ha-evcc/releases/tag/2025.7.0

An update for the Garmin app will be released in the next few days, adding support for both JSON formats - with and without the "result" wrapper. The app uses a jq filter to reduce memory usage, and the filter has been updated to handle both cases.

The code was tested with the old format, but I can only fully verify support for the new one once the update is live. Mock servers can't replicate how the jq filter is applied by the actual server.

Side note: AI isn’t much help with Garmin’s Monkey C or SDK, but it is well-versed in jq and was also helpful in this case. 😉

@andig I also noticed the openHAB evcc binding isn’t showing up in the list. Maybe it needs an update too to handle the new JSON format?

Whom do we need to cc?

Whom do we need to cc?

@florian-h05, would you be the right person to look into how this change affects the openHAB evcc binding? Or do you happen to know who maintains it currently?

Announcement is done via release notes and discussions: #22416.

I'd tentatively like to schedule this for 0.206.0.

I'd tentatively like to schedule this for 0.206.0.

my experience with HA Integration users is, that they update Integrations not frequently - but the obvious question is, "how long you are willing to wait" with the rollout of this PR... In my opinion this change does not add any (awaited) functionality - therefor the release-pressure is not high (IMHO)

The pressure comes from the other release contents. But we'll need to merge this into the nightly before.

that they update Integrations not frequently

This will be an issue for any release, be it sooner or later?

Maybe make it a "dedicated" release, where people can roll-back to the previous version if they cannot immediately update their integrations? I guess, a lot of people are on the "latest" tag when using Docker and will otherwise be quite surprised by the update and it would be beneficial, if they could rollback one version in order to update their home automation integrations.

Wir haben gethomepage/homepage#5630 vergessen :/

Unfortunately, the integration with openHAB is currently broken — the evcc binding no longer works with the latest evcc version.

I haven’t opened a PR yet, as I need another user to help test and finalize it.

Perhaps I can help. However, I’m running openHAB in Docker, so I can only use what’s available as a Docker image or what can be installed into an existing installation via Karaf.