As a related but side project from my work with OpenEVSE EV charging station (see thread).
I have put together a little script to poll the Nissan Leaf EV connect API to obtain battery charge level and charging status of a Nissan LEAF EV and publish the data to MQTT. Climate control can also be controlled via and MQTT topic.
Once data is in MQTT it can easily be used to inform home automation and smart charging applications. e.g OpenHAB, Home Assistant, OpenEVSE.
Here is an example of displaying the MQTT data via openHAB Android app:
In this example the the ‘Home Charger’ power (openEVSE) is monitored by emonPi, however data could also come from openEVSE with wifi connectivity to post to Emoncms. 14W is the power going to the charging station in standby plus emonPi (Raspberry Pi 3)
Code and install instructions are on my GitHub:
I experiment running the script via a systemd unit script, this is the fist time I have used systemd for my own script. I was impressed with how easy it was to use and how powerful systemd is e.g with an extra couple of lines in the
leaf-python-mqtt.service unit file it’s possible to instruct systemd to reload the script after X number of seconds if the script exists due to an error
Suggestions for improvements welcome.
This is a personal hacked together side-project and not an officially supported OpenEnergyMonitor development.
Hey @glyn.hudson, this is really great. Thanks for posting. Once this is linked with the OpenEVSE solar charging project we’ll have a complete solution.
I was reading your readme on the github about the options for polling either the Nissan API or the car itself. Does the state of charge get updated to the API automatically? Otherwise I assume it will be necessary to poll the car only, at least during charging.
Thanks, I’m reluctant to schedule periodic updates from the car due to the possibility of draining the battery if polled too frequently.
However, I do use the excellent leaf manger Android app which triggers a car update when the car is parked, then every hour if the car is charging (the app detects when the cars Bluetooth disconnects then triggers an update from the car). Without leaf manager triggering an update, I’m not sure how frequently the car will update on it’s own accord, if at all.
Hi, that’s great! I gave a shot and i received wrong info:
leaf/status Connecting to MQTT host —.—.—.----
leaf/status MQTT connected
leaf/status/last_updated 2017/01/03 16:42
My car is parked outside with ~80% and not charging
Is it performing the “Request Last Status” ?
Also how do you get the Battery %?
[quote=“glyn.hudson, post:3, topic:2672, full:true”]
Thanks, I’m reluctant to schedule periodic updates from the car due to the possibility of draining the battery if polled too frequently.[/quote]
Yes, this is the problem with the Leaf (and probably other makes too) that it will not charge the aux battery while the main charger is connected.
I am considering getting a float charger and rigging up a convenient way to connect both that and the main charger at the same time. Then I can leave both connected all the time the car is not in use without worrying about draining the aux battery.
You haven’t received the wrong info, you’ve just received out of date info.
If you publish a ‘1’ to leaf/control/update mqtt topic this will trigger an update from the car I.e car will report to Nissan severs via gsm, you will then see updated data via the api. Opening the Nissan Connect ev app or leaf manager app would also trigger a car update.
I have left if up to you the user to decide how and when you want to trigger a car update. I have head if people polling the car frequently for updates e.g every 15 but I’m not that brave! I don’t want to risk draining my 12v aux battery if the gsm modem in the car is continously being woken up.
Hi, i see now, your implementation is great. Just one note, the % of battery has to be found statically, dividing the number of bars by 12.
Is someone know if there are generic APIs to check the battery status (maybe a common standard)? or each car uses its own APis?
It’s a generic API that you authenticate using your Nissan Connect EV username and password. It uses the new secure API (not unauthenticated old version that was hacked all over the news!).
The API was updated by Nissan at the end last month (Feb 17). Be sure to use the latest version of the python library:
Every API is different, and even within the Leaf, the API reports back different parameters. On 24kWh Nissan Leaf the APP reports no more than the number of bars of charge, so you end up with a very rough estimate of the SOC with huge 1/12 steps.
On the 30kWh Leaf the Carwings API delivers more information, including the correct SOC as shown on the dashboard.
But that’s not all, the SOC that the manufacturers present in the car is different from the real SOC of the battery, so today a implementation of a way to charge a car up to a determined % is highly specific and not very precise. I have made one with my EVSE and last time i checked had a accuracy of about 5% with is better than nothing.
Just passing by and now installing this.
For people doing this on a vanilla RPi you will need to also
sudo apt install python-pip python-dev libyaml-dev git
Still installing, there may be more generic dependencies - I will edit
OK, which “username” and “password” is it please?
I am getting a Car Wings error and not being a python person not sure how to enable the debug logs.
I note that there are multiple accounts involved during my original setup: You+Nissan, NissanConnect.eu and then the User ID that generates in the app. I know the passwords, so am going through random tests…
UPDATE: Found how to enable logging DEBUG and I now get an odd error about file not found:
The requested URL /gworchest_160803A/gdc/InitialApp.php was not found on this server.
Going to go read code.
Hi. This looks like a really useful project. Thanks for sharing your code.
I am very keen to try this for myself, but from my research online I think there have been some big changes with Nissan systems. Do you know if this project still works with the current systems that Nissan Leaf uses?
I’ve abandoned using the Nissan API in favour of OVMS:
I had too many issues with the Nissan API, is has never worked reliably. OVMS is a totally open-source 3rd party solution and has a really nice MQTT (server V3) API to work with. The data is totally real time and much more data is available.
I have recently been using the new Nissan NC App to find state of charge. It is absolutely useless, but does occasionally give the SoC. (The car is really nice though - the App is the biggest reason not to buy it).
I messaged Nissan technical support, and asked where the App gets the data from and could they provide details of the API. The reply was “the App is the only way to get the information”. If I want to do some technical development, then I could write a letter (like we did last Century) to Nissan Head Office in Rickmansworth.
Like with smart meters, I think data access is down to an unwillingness to open up the information, rather than just simple incompetence.
The OVMS seems like a rather expensive way to get around an artificial barrier. I assume this puts the vehicle data into a cloud based MQTT server?
Anyone know how this issue is with other EVs?
I doubt you will get any help from Nissan, the telematics hardware in the car is poor. It’s woken up via SMS and only reports 1/12 battery SOC bars which the app then converts into an approximate SOC. I’s very reliable, far from real time and does not provide data such as charging current, battery temperature, ODO reading, real-time GPS location and speed etc. OVMS is fully open-source and its a very functional alternative to Nissan’s system.
Most EV’s apart from Tesla (and maybe BMW) either don’t have any connectivity or it’s poor.
I run the OVMS module too for our 2014 Leaf Tekna.
After getting a local simcard, very happy with the result.
Did you find a way to stop charging based on the SOC reported through Dexter’s Web?
If so - would you share it?
Great to hear that OVMS is working well. It should have been possible to use the included Hologam SIM card, this SIM will work globally. However, it’s not a problem to use a local SIM if you prefer.
I’m afraid it’s not currently possible to stop the change using OVMS. However, work is underway to support this:
I’ll follow Dala’s thread.
Met vriendelijke groet,
Verzonden vanaf mijn mobiele telefoon.
Misschien bondiger dan u gewend bent.
Op 13 jan. 2021, om 01:03, Glyn Hudson via OpenEnergyMonitor Community <[email protected]> schreef: