Speak EV - Electric Car Forums banner

Recurring (unplugged) pre-heat

3K views 31 replies 9 participants last post by  DBMandrake 
#1 · (Edited)
I’ve had a search and couldn’t see this exact question, so…. Is there a way to preheat the car whilst unplugged on a recurring schedule? I appreciate that if plugged in this is easy, but we’re not currently doing the miles to necessitate a charge every night.

The Nissan or (excellent) My LEAF app can set a 1 off timer, but I can’t find a way to make it repeat.

The reason for asking is that the BCM was entirely too wet and I’m trying to minimise condensation.

Edit - I'll be easily persuaded that the correct word to use reoccurring rather than recurring...
 
#3 ·
There's nothing built in to do what you want - the built in charge timers only work when plugged in, and the app's as you've noticed only let you schedule on turn on time.

A couple of ideas though:

1) The timer in the app is server side on the Nissan servers, however if you can find some other app or service that will connect to your You+Nissan account that service might be able to periodically send a remote climate control request. I think there is an Android app that can actually do this although I don't recall its name.

Keep in mind that each 15 minute heating session uses a few percent of the battery, so you'd still want to keep an eye on the battery level as it will gradually go down with each warm up session.

2) If the issue is that you just don't want the battery being fully charged while plugged in, use the charge timer to prevent charging. If the charge timer is enabled overall but not set for a given day, the car will not automatically charge at all that day. I have my charge timer set to Monday-Friday, if I leave the car plugged in on Friday night it won't charge until Monday morning unless I press the override button or use the app.

I haven't tried enabling the timer but not setting a time range on any day - if that doesn't work set it to maybe charge for 10 minutes on one day of the week to fool it, and when you do actually want to charge the car just press the override button or use the app to start a charge.

With this approach the climate control will run for 30 minutes each time then go off, however keep in mind that the battery charge level will actually creep up about 2-3% on every plugged in pre-heat session, so after enough sessions you would end up with a high charge level.
 
#5 ·
Not sure if it’s been fixed but preheat seemed to not run the A/C in the past so the car would be hot but humid. Personally I’d just leave the car running for a few hours with the heater set on the 30 and the window cracked slightly. Take the keys inside with you, and do it during the day so your neighbours don’t keep coming round to tell you you’ve left your lights on (ask me how I know!!)
 
#6 ·
Nice idea, except for the fact that you can't lock the car from the outside while it's turned on ?! (Mine just beeps in complaint if I try)

If the car is on and unlocked anyone can drive it away even if the keys aren't still in the car.

Pre-heat only runs the A/C if the car needs to be cooled, not if it needs to be heated. It works similarly to Auto mode although it does cycle through multiple vent settings during the 30 minute pre condition period.
 
#8 ·
Yes they could, but wouldn't get far! Once the car needs recharging you're stuck. And I believe you can lock the door with the physical key from outside.
 
#12 ·
Really?? It might just need re programming (think it's roll all the way down and hold the switch in position for ten seconds, then roll all the way up and hold in position for ten seconds). Mines a 2011 so could well be different but seems an odd feature to drop!
 
#17 ·
I'd forgotten that the pre-heat doesn't use the AC, that's a bit of an issue.

My drivers windows now has auto close working again - ta!(y)

I think my preferred way for leaving it running is to use LEAF spy to set it such that just the driver's door unlocks and then use the key to manually lock it, although I confess I've not tried yet.

Looking here (click) it seems possible to code my initial want, but it's beyond my IT skills.
 
#19 ·
Any pointers on where to look for those of us who do program in Python? :)

The only problem with this approach may be that the Nissan connected services really don't like more than one device logging into the account at once. For example logging in via My Leaf or the You+Nissan portal actually logs out the Nissan Connect EV app on my phone... :rolleyes: (Why Nissan, why.... more than one person might want to drive and remote control a car without having to manually reauthenticate all the time...)
 
#20 ·
I've been playing a little today.

got pycarwings2 (pycarwings2) to poll the car and get latest SoC and Time_to_charge

Then got the OctopusAgile library (markgdev/OctopusAgile) querying the Agile API for the cheapest continuous "time_to_charge" block between 11pm and 8am.

Then sending a web request to my Sonoff/Tasmota device to switch the charger on at the optimal time.

I've not had any nissan authentication issues, although i dont normally use the nissan app, i use MyLeaf instead.
 
#21 · (Edited)
I've been playing a little today.

got pycarwings2 (pycarwings2) to poll the car and get latest SoC and Time_to_charge
Ah, nice, I'll have a look at that. :)

Be careful with automated polling though - every time you poll the car it wakes up some of the ECU's - you can actually hear relays clicking under the bonnet to power up the (presumably) BMS and/or climate control ECU's.

If you polled excessively while the car is unplugged you could potentially run the 12v battery down after a few days. (I've seen some chat on the US Leaf forum suggesting that in years gone by bugs with the Nissan Connect servers and/or app that were causing excessive polling was actually causing 12v batteries to run down on cars - the same might be true of 3rd party apps abusing the ability to poll frequently)

You could mitigate that by only polling infrequently while the car is unplugged, increasing polling rate when you detect the car is actively charging, and backing off the polling rate again as soon as you detect the car has ended charging.
I've not had any nissan authentication issues, although i dont normally use the nissan app, i use MyLeaf instead.
I have both the Nissan app and MyLeaf and to be honest I bought My Leaf because everyone told me the Nissan app never works - but for me it works 99% of the time and I find it more usefriendly than MyLeaf.

But if I try to use both apps as soon as I use one it logs the other one out, which is another reason I stopped using My Leaf.

I don't suppose you've seen anything in the API that allows you to stop a charge session? That's a feature which is sorely lacking in the official apps and it's not clear whether it's an API limitation or not since you can start a charge remotely.

You can both start and stop climate control remotely but only start charging remotely - I don't get the logic behind that....
 
#22 ·
I'm truly impressed. :) One minor issue, the time to charge includes the battery balancing time of around 1.5 hours.
Where are you running the code?
Also, anyone know a similar way to find the best series of discrete 30 minute periods to achieve the same?
 
#25 · (Edited)
Thanks for confirming there is no stop charge API call. :(

I have a dumb charger (2017 Rolec) so was holding out hope that there might be a stop API call the apps don't expose so I could write my own "charge to 80% on the weekends" routine but nope!

I still haven't got past the authentication hurdle though - I can't get pycarwings2 to authenticate to my you+nissan account. I see an open git issue for the same problem posted 28 days ago so I'm not alone and yet @Aragorn seems to have it working, so I think I will try changing my password to one without certain punctuation in it. It wouldn't be the first Web API python binding I've used that can't handle good random character/punctuation passwords properly due to quoting/escaping issues. :rolleyes: The author of pycarwings2 doesn't seem to respond to git issues recently from what I can see so I don't think it's being actively maintained and perhaps not many people are using it.
 
#26 ·
I was in the same situation as you and just ended up spending (more!) money on the Ohme Type 2 > Type 1 cable, it does everything I wanted to do and wish I just got their home charging cable in the first place to be honest.

It has been very reliable, although is at the mercy of the Nissan API to report battery SoC so it does quite frequently guess and assume it's at 80% but it has actually finished it's charge at 76% or 83%, not going to complain about t hat though.
 
#27 ·
Sorry on been on in a few weeks and missed this. In a moment of real stupidity i lost the work i'd done and havent revisited yet.

I had been using a Debian install as a sandbox, except what i thought was a persistent install on a USB stick was actually a "live" install and i rebooted it and lost everything i'd done.

I use a Sonoff device to control the EPC in my Rolec, so if i wanted to stop a charge, i could simply send a web command to the Sonoff to shut it off.

However the cars range is so awful currently, that an 80% charge wouldnt be much use to me.

I actually bought a CAN bridge from Dala last year to run his LeafEnhancer package, and planned to fit that and set it to stop charging at 90%, however I've decided against it given the range issues mentioned. So if anyone wants to buy a CAN bridge, give me a shout :)
 
#28 · (Edited)
I now have a Shelly WiFi switch installed in my Rolec wallpod as per this thread, and the switch has a very simple API that I can use to poll the current state to see if the car has activated the EVSE or not, (thus only poll the Nissan API when I know the car is plugged in charging to avoid waking sleeping ECU's...) and also for me to disable the EVSE to end the charge, which the Nissan API itself can't do.

However on revisiting pycarwings2 many months later I still can't get it to work and there is deafening silence in the git ticket I posted in and no real other way to get in touch with anyone who might be using it:


I'm at a bit of a loss here. Is pycarwings2 working for anyone ? I'm no python expert but I'm not a newb either, I've written a reasonable amount of Python but I am unfamiliar with the pycarwings2 module and not having seen it working before I don't know if I'm missing just one thing or whether there are multiple issues at play here. :unsure:

I'm using the filcole fork of pycarings2 with python 3.5.3 as that seems to be the most up to date maintained fork. This version requires Python 3.

Leaf's like mine before mid 2018 use a different app to those after 2018 (6 months into the Leaf 2 run) due to different Telematics systems, but it's unclear to me whether this requires a different backend API - NE (Europe) seems to be the only valid option for me to choose for pycarwings2 but doesn't give me a way to specify whether my car uses the earlier or later app. In any case I tried all the region options and none worked. Just "INVALID PARAMS" coming back from Nissan as in the git issue.
 
#30 · (Edited)
Finally got it to work! :)

Turns out it was the user agent issue after all, which is fixed in the following not yet merged pull request:


I didn't think this was the issue because I thought I had already installed this modified version of pycarwings2 from source, but I must have accidentally installed the pip version of the package which is not yet fixed instead of the modified version. Doh.

Looks like Nissan is playing a game of cat and mouse blocking User-Agents so lets hope they get tired of doing that...

I can now query battery status via the API, and monitor EVSE status and switch the EVSE on/off via the Shelly local API so time to get coding...
 
#31 ·
Hmm, i thought i'd edited that user agent... perhaps the pip version is located somewhere else?

edit:
Yep, same thing, i'd edited the local version, not the pip version, and i guess the library takes priority.

I set user agent to "Mozilla/5.0" and now its working:

DEBUG:pycarwings2.pycarwings2:Response HTTP Status Code: 200
DEBUG:pycarwings2.pycarwings2:Response HTTP Response Body: b'{"status":200,"BatteryStatusRecords":{"OperationResult":"START","OperationDateAndTime":"08-Jun-2021 17:32","BatteryStatus":{"BatteryChargingStatus":"NOT_CHARGING","BatteryCapacity":"240","BatteryRemainingAmount":"120","BatteryRemainingAmountWH":"12240","BatteryRemainingAmountkWH":"","SOC":{"Value":"46"}},"PluginState":"NOT_CONNECTED","CruisingRangeAcOn":"73000","CruisingRangeAcOff":"74000","NotificationDateAndTime":"2021\\/06\\/08 16:32","TargetDate":"2021\\/06\\/08 16:32"}}'
start_date= 08-Jun-2021 17:32
date 08-Jun-2021 17:32
date 2021/06/08 16:32
battery_capacity2 240
battery_capacity 240
charging_status NOT_CHARGING
battery_capacity 240
battery_remaining_amount 120
charging_status NOT_CHARGING
is_charging False
is_quick_charging False
plugin_state NOT_CONNECTED
is_connected False
is_connected_to_quick_charger False
time_to_full_trickle None
time_to_full_l2 None
time_to_full_l2_6kw None
battery_percent 46.0
state_of_charge 46
 
#32 · (Edited)
Feeling my way around the pycarwings2 interface with a test script and having good success with it now and have learnt a few things.

For use in a persistent script you only need to call the initial login methods once:

Code:
s = pycarwings2.Session(username, password, region)
leaf = s.get_leaf()
Assuming that initial login succeeds (wait and try again later if not) from then on you can call the other functions over a long period of time without worrying about the login timing out as pycarwings2 automatically handles logging back in for you if the session has timed out. (Which seems to take around 10-15 minutes, not sure exactly how long) I've tried leaving my script paused for a couple of hours before telling it to poll again without explicitly logging in and I can see pycarwings2 automatically logging me back in.

Although the initial login does ping the car for an update automatically, (which you will get after a minimum of about 30 seconds) to affirmatively get the latest data every time you are best to use resultkey = leaf.request_update() which triggers a poll of the car, then wait a minimum of 30 seconds before checking the result with response = leaf.get_status_from_update(resultkey) this function will just return None if there is no response from the car yet, in which case wait a while longer in a while loop (I wait another 20 seconds) then call the function again and see if you have a response - I will probably retry every 20 seconds for a maximum of 4 retries after which point I'll assume polling the car has failed and wait until my next scheduled polling period. (Which is going to be dynamic based on current state of charge, but probably in the order of 10 minutes)

Using leaf_request_update() and get_status_from_update() together is very reliably getting me up to date data in a timely fashion when I am periodically polling - from what I've seen it takes a minimum of about 25 seconds for the Nissan servers to ping the car, wake the ECU's in the car and retrieve the the data from the car for it to be available, hence always waiting at least 30 seconds to avoid unnecessary repeat polls to the API as it usually succeeds the first time if you wait 30 seconds. Sometimes it's taking as long as about 40-50 seconds and no doubt if the car was in an area with a poor mobile data connection it could take quite a bit longer so up to a total of about 2 minutes seems reasonable to wait before giving up, especially if the cars are using 2G as I've heard is the case.

The data and time that the data was received from the car (which seems to be accurate) is also available in the response, so you could do a sanity check to make sure that data was no more than 2-3 minutes old - in my testing it has never been more than one minute old when using leaf_request_update() together with leaf_get_status_from_update().

Once you have positive confirmation that the car has been polled and up to date data is available you can get battery SoC and charging status with leaf_info = leaf.get_latest_battery_status()

The is_charging state is useful as well because this is True when the car is actually charging, but false if the car is plugged in doing timed climate control but not simultaneously charging.

So for example if you detect the car is plugged in and activates the EVSE, and current SoC was already above your target, you could terminate the charging session immediately by switching off the EVSE, but only if is_charging is True, because if it is false, it is just going to be timed/remote climate control, not actually charging, in this case you don't want to switch off the EVSE or you will stop the climate control from working.

Anyway slowly working on this script and testing it out - I think this is going to work very well, and I will of course code in failsafe where if I can't poll the API at all I just revert to switching off at a preset time as the Shelly does now with its 3:13 am switch off schedule.

And even if that failed for some reason the result of the compete failure of the script to work would simply be that the car charged to 100%! The timers built into the car and the Shelly enable/start charging, the script I'm writing will only stop the charging at the right time... if the script is not running or working properly the car will just continue charging to 100%.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top