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] Initial Contribution #11467

Merged
merged 16 commits into from
Dec 5, 2021
Merged

[renault] Initial Contribution #11467

merged 16 commits into from
Dec 5, 2021

Conversation

dougculnane
Copy link
Contributor

Initial renualt-api binding Issue: #11465

Electric car charging rules can be improved if the battery state of the car is known. There was a Renault ZE service API but this is no longer available and a new renault-api has a complex authentication flow. There is python implemented code that mimics the mobile app and allows a command line interface to pull data from the Renault API. (https://github.com/hacf-fr/renault-api)

It would be nice to have this available as an easy to use binding so that openHAB users can get car battery (and other) status information in openHAB.

This is a long discussion documenting the issue:
https://community.openhab.org/t/betatest-renault-ze-services-binding/72226

I have implemented a basic binding that translates the python code to a Java. It works on at least 3 cars according the the forum. https://community.openhab.org/t/betatest-renault-ze-services-binding/72226/79?u=doug_culnane

@dougculnane dougculnane requested a review from a team as a code owner October 28, 2021 14:47
… <doug@culnane.com>

Signed-off-by: Doug Culnane <doug@culnane.net>
@kaikreuzer kaikreuzer added rebuild Triggers Jenkins PR build and removed rebuild Triggers Jenkins PR build labels Oct 28, 2021
@wborn wborn added the new binding If someone has started to work on a binding. For a new binding PR. label Oct 29, 2021
@wborn wborn linked an issue Oct 29, 2021 that may be closed by this pull request
@wborn wborn changed the title #11465 Initial renualt-api binding Initial renualt-api binding Oct 29, 2021
@fwolter fwolter changed the title Initial renualt-api binding [renault] Initial Contribution Oct 29, 2021
@Flole998 Flole998 added rebuild Triggers Jenkins PR build and removed rebuild Triggers Jenkins PR build labels Nov 2, 2021
@lolodomo
Copy link
Contributor

lolodomo commented Nov 19, 2021

I am going to review your binding.
As a first request, please add the missing entries in the openhab-addons BOM and CODEOWNERS files.

Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review part 1 of 2

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

Thanks @lolodomo for some great feedback. I think I have got all your points and I will build and test the changes locally this weekend. I hope to push a tested version ASAP.

Thanks again.

@lolodomo
Copy link
Contributor

I will review the last part (comm part) probably tomorrow.

Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review part 2 of 2

@dougculnane
Copy link
Contributor Author

Review part 2 of 2

Thanks @lolodomo I have a couple of questions in the comments and some work to do. I will do and test these changes and get back with an updated version.

Thanks again.

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

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New comments after your last set of changes.

@lolodomo
Copy link
Contributor

@dougculnane : thank you for all your changes. I marked as "resolved" most of my old comments. Please take a look to the ones which are not yet marked as resolved and please consider the new ones.
We are not too far from something clean.

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

@lolodomo Thanks for some good tips and feedback. I have got all currently open issues resolved or attempted to resolve them now.

Thanks again.

Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here are my very final comments leading a clean compilation of the binding.

Signed-off-by: Culnane Douglas <douglas.culnane@extern.a1.at>
@dougculnane
Copy link
Contributor Author

dougculnane commented Dec 3, 2021

I have refactored this to make errors more transparent. I am not sure if this is openHAB friendly? I want the thing to stay online but say there is a com error with the location (which happens in some cars). Or if you car gets un-paired I want this to be more transparent. I hope this is OK?

Screenshot_20211203_193820

@dougculnane
Copy link
Contributor Author

@lolodomo I hope this is OK now? Thanks again for your time.

@lolodomo
Copy link
Contributor

lolodomo commented Dec 4, 2021

I have refactored this to make errors more transparent. I am not sure if this is openHAB friendly? I want the thing to stay online but say there is a com error with the location (which happens in some cars). Or if you car gets un-paired I want this to be more transparent. I hope this is OK?

Honestly, this looks a little weird to me. Displaying a communication error but keeping the thing ONLINE.
If I correctly understand, you just want to ignore these communication errors because you already know that some of the cars will trigger these errors. Why not just keeping the thing status unchanged and add a DEBUG log that a user can display if he would like to investigate why a particular channel is not set ?
Additionally, your solution could even lead to several status changes (several communication errors) and the user will see in UI only one communication error.

@lolodomo lolodomo removed the work in progress A PR that is not yet ready to be merged label Dec 4, 2021
@dougculnane
Copy link
Contributor Author

@lolodomo I know it is not great.

The problem I am trying to solve is that if the car gets up-paired or some channels have errors there is no way of telling unless you look in the log files. The the binding need to ignore errors and keep polling so it should stay ONLINE (as far as I understand or it will stop polling). Is there a better way of reporting errors or should I create a new channel for a status message or something? Thanks again.

@dougculnane
Copy link
Contributor Author

@lolodomo
There is a good suggestion at the bottom of this tread that I can do. Ignore not implemented channels:
https://community.openhab.org/t/betatest-renault-ze-services-binding/72226/115?u=doug_culnane

Is the status message a good idea or is there some other error viability idea? Or are you getting board of this?

Thanks again again.

@lolodomo
Copy link
Contributor

lolodomo commented Dec 4, 2021

For requests that are failing systematically (comm error) because not supported by a car, my opinion is that you should just log something and do nothing regarding the thing status. Avoiding next similar requests is of course a good idea. You could have "disableXXX" booleans in your car structure that you will set to true in case a first request is failing.

For requests that are failing only in not normal situations but you know that the request is applicable for the car, your current solution could be acceptable. Keep status ONLINE if you are really sure that there is not general comm problem, else set it to OFFLINE.
Note that your scheduled task will continue to be called even if your thing status is OFFLINE.

We have to conclude quickly now, even if not perfect, to have your binding part of the final 3.2 distribution.

Let me know if you want to add a new final optimization (avoid recalling for ever requests that you know they will fail).

@dougculnane
Copy link
Contributor Author

@lolodomo Thanks for the advice. I will try to push an update this evening.

Signed-off-by: Culnane Douglas <douglas.culnane@extern.a1.at>
@dougculnane
Copy link
Contributor Author

@lolodomo I added a not not Implemented error and disableXXX flags for the services. I keep the errors to the log files. I recreate the car Object on init so that you can reset it... Thanks again.

Signed-off-by: Culnane Douglas <douglas.culnane@extern.a1.at>
Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very final comment

Signed-off-by: Culnane Douglas <douglas.culnane@extern.a1.at>
Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dougculnane
Copy link
Contributor Author

@lolodomo Getters and setter are done. I have tested the binding on my openHAB installation. Thanks again.

@lolodomo lolodomo merged commit 3d2663c into openhab:main Dec 5, 2021
@dougculnane dougculnane deleted the renault-pr branch December 5, 2021 08:34
@lolodomo
Copy link
Contributor

lolodomo commented Dec 5, 2021

@dougculnane : thank you for your new binding contribution.

@lolodomo lolodomo added this to the 3.2 milestone Dec 5, 2021
@dougculnane
Copy link
Contributor Author

@lolodomo Merci beaucoup for your help and time getting this ready for release.

NickWaterton pushed a commit to NickWaterton/openhab-addons that referenced this pull request Dec 30, 2021
* openhab#11465 Initial renault-api binding
Signed-off-by: Doug Culnane <doug@culnane.com>
Signed-off-by: Nick Waterton <n.waterton@outlook.com>
@lolodomo
Copy link
Contributor

lolodomo commented Jan 9, 2022

@dougculnane : if not yet done, you could add your binding's logo to the openHAB website. See https://www.openhab.org/docs/developer/bindings/#add-your-binding-s-logo-to-the-openhab-website

mischmidt83 pushed a commit to mischmidt83/openhab-addons that referenced this pull request Jan 9, 2022
* openhab#11465 Initial renault-api binding
Signed-off-by: Doug Culnane <doug@culnane.com>
Signed-off-by: Michael Schmidt <mi.schmidt.83@gmail.com>
@dougculnane
Copy link
Contributor Author

@lolodomo I have created a PR for the logo here: openhab/openhab-docs#1730

All the best, Doug

nemerdaud pushed a commit to nemerdaud/openhab-addons that referenced this pull request Jan 28, 2022
* openhab#11465 Initial renault-api binding
Signed-off-by: Doug Culnane <doug@culnane.com>
volkmarnissen pushed a commit to volkmarnissen/openhab-addons that referenced this pull request Mar 3, 2022
* openhab#11465 Initial renault-api binding
Signed-off-by: Doug Culnane <doug@culnane.com>
marcfischerboschio pushed a commit to bosch-io/openhab-addons that referenced this pull request May 5, 2022
* openhab#11465 Initial renault-api binding
Signed-off-by: Doug Culnane <doug@culnane.com>
andan67 pushed a commit to andan67/openhab-addons that referenced this pull request Nov 6, 2022
* openhab#11465 Initial renault-api binding
Signed-off-by: Doug Culnane <doug@culnane.com>
andrasU pushed a commit to andrasU/openhab-addons that referenced this pull request Nov 12, 2022
* openhab#11465 Initial renault-api binding
Signed-off-by: Doug Culnane <doug@culnane.com>
Signed-off-by: Andras Uhrin <andras.uhrin@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new binding If someone has started to work on a binding. For a new binding PR.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Renault-api binding.
5 participants