Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Renault] Cockpit/odometer information no longer retrieved #16669

Closed
maxonthegit opened this issue Apr 20, 2024 · 2 comments · Fixed by #16675
Closed

[Renault] Cockpit/odometer information no longer retrieved #16669

maxonthegit opened this issue Apr 20, 2024 · 2 comments · Fixed by #16675
Labels
bug An unexpected problem or unintended behavior of an add-on

Comments

@maxonthegit
Copy link

maxonthegit commented Apr 20, 2024

Expected Behavior

One of the channels exposed by things created with the Renault binding is odometer, which is supposed to indicate the total distance traveled so far. Linking a Number type item to this channel is expected to provide a reading of the car odometer.

Current Behavior

Up to a few days ago, the odometer reading was regularly available. Then, suddenly, the linked item just ceased to be updated: the car odometer in the My Renault mobile app continued to increase, confirming that such information is available in the My Renault cloud, but the item was just frozen at the last available reading.

None of the following attempts restored the expected odometer reading:

  • pausing and resuming the thing created with the Renault binding
  • creating a new Renault car thing from scratch and linking the existing item to its odometer channel
  • forcedly setting the existing item to a different value from the Karaf console and waiting for it to be updated
  • creating a new item and linking it to the odometer channel

No relevant errors appear in the Karaf console using log:tail when either of the aforementioned actions is undertaken (just some warnings about known unsupported features of this car model, like lock status update, HVAC and battery status; these have always been there anyway).

Possible Solution

Developers of the renault-api project, the openHAB Renault binding is based upon, have already spotted a change in the Renault API that causes cockpit reading to fail being retrieved: this is documented in their issue #1135.

As a fallback, the API call for the cockpit data should be reverted to using version 1 of the API. As of version 4.1.2 of openHAB and of the org.openhab.binding.renault binding, this corresponds to updating line 238 of file /bundles/org.openhab.binding.renault/src/main/java/org/openhab/binding/renault/internal/api//MyRenaultHttpSession.java from:

                + "/kamereon/kca/car-adapter/v2/cars/" + config.vin + "/cockpit?country=" + getCountry(config));

to:

                + "/kamereon/kca/car-adapter/v1/cars/" + config.vin + "/cockpit?country=" + getCountry(config));

To verify this suggestion, I have attempted to rebuild the addon using Maven after applying this change, and the odometer reading became available again in the usual expected way.

Steps to Reproduce (for Bugs)

  1. Install the Renault binding in an openHAB 4.1.2 instance.
  2. Create a thing using the Renault binding.
  3. Create a Number:Length item pointing to the odometer channel of the freshly created thing.
  4. Check that the item is never updated.

Context

N/A

Your Environment

I am using the latest stable (4.1.2, release build) version of openHAB, packaged in a Docker container created from its stock openhab/openhab image.
Although this is of limited relevance, Docker is executed on a Raspberry Pi OS/Raspbian installation which is at release 11 (bullseye).

@maxonthegit maxonthegit added the bug An unexpected problem or unintended behavior of an add-on label Apr 20, 2024
@openhab-bot
Copy link
Collaborator

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/betatest-renault-ze-services-binding/72226/254

dougculnane added a commit to dougculnane/openhab-addons that referenced this issue Apr 22, 2024


Signed-off-by: dougculnane <doug@culnane.net>
@dougculnane
Copy link
Contributor

#16675 applies suggested fix.

Thanks for the excellent work @maxonthegit

@jlaur jlaur linked a pull request Apr 22, 2024 that will close this issue
jlaur pushed a commit that referenced this issue Apr 22, 2024
lo92fr pushed a commit to lo92fr/openhab-addons that referenced this issue Apr 30, 2024
psmedley pushed a commit to psmedley/openhab-addons that referenced this issue Jun 15, 2024
 (openhab#16675)

Signed-off-by: dougculnane <doug@culnane.net>
Signed-off-by: Paul Smedley <paul@smedley.id.au>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An unexpected problem or unintended behavior of an add-on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants