dan-r
commented
1 month ago So the behaviour you're seeing is briefly explained in the README (not well!). Basically there's a polling interval (default 60 mins) when we wake the car up and ask for an update and there's also an update interval (default 10 minutes) where we just fetch the latest data from Nissan but don't wake the car. These intervals are both configurable under the 'Configure' menu.
The car very rarely sends updates without being asked BUT during driving, every so often it does. Sadly there's no easy way to tell if the car is being driven without doing some more analysis on the frequency of updates. You could kind of do it by putting the update interval to 1 minute and then seeing when the odometer stops going up, but not reliably.
The update logic is all designed around (for my use case at least) getting the most up to date info without killing the 12v battery. Polling the car too frequently can drain this, and as I found out from #14, being plugged in and not charging, the 12v battery can still drain!
Personally I have a hard wired Teltonika tracker and a Traccar instance which reports ignition state so it isn't a priority to add for me, but if you manage to come up with some conditions you can accurately correlate to driving, I'm happy to work with you on implementing it.
Sorry for the wall of text, let me know if you have any more questions!
Is it possibly to determine when the car (Nissan Leaf in my case) is being driven?
I've noticed that the update rate is quicker when I'm driving even when I haven't been charging prior to the drive, but I can't see anything in the code that would be causing that!
The use case would be an alert when you stopped driving 20 minutes ago and you haven't locked the doors and/or plugged in the car.