Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Nissan Leaf Integration (Carwings / NissanConnect EV) #19786
Adds support for monitoring and controlling the Nissan Leaf remote control platform.
Currently introduces two switches (climate control and charging, charging can only be turned on as per the API limitation), 3 sensors (battery charge and range with and without AC on), a binary sensor for if the car is currently plugged in, device tracker for the car location (if the car is capable).
I'm based in the UK with a 2016 30kWh leaf so assistance from others is very useful.
Example entry for configuration.yaml:
nissan_leaf: username: "username" password: "password" region: 'NE' # Indicates Europe, must be changed for other regions nissan_connect: true # Set to false for early Leafs 24kWh that don't report location update_interval: hours: 1 update_interval_charging: minutes: 15 update_interval_climate: minutes: 5 force_miles: true
If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
If the code does not interact with devices:
Feb 15, 2019
MartinHjelmare left a comment
Please open a new PR where we can address the comments.
Generally I think there is too much logging and the update logic seems complicated.
Consider use of async vs sync api. Don't do I/O in event loop.
I'm looking forward to the next PR.
@MartinHjelmare Thank you for the review, and also to @fabaff and @dgomes. I will submit another pull request when I've tried to address the issues raised. I hope you don't mind if I comment against the conversation points raised as I'm attempting to resolve them.
When you say too much logging, do you mean logging using info or in general?
Part of the reason for so much logging is that Nissan break their API on a semi-regular basis, and sometimes only for certain people (like how they only broke battery charge for older cars that report in bars). They have basically no sense of DevOps for API versioning/maintenance so the logging is needed at least on trace to debug issues that only occur for certain people.
Both. Generally we don't want to log on info level in components. If it's not a warning or error, we should use debug.
There are some more places where the debug logs only seem to be used to verify our own logic. That's not how we should use logging. If we need to verify our own logic, we should use tests.
It's ok to log the result of an api but we should probably not log that we called the api, and definitely not log internal component variable changes. Sounds good?