-2010 (INVALID PARAMS)

[Todd1561]

I just started using this a couple days ago and it was working fine for me in the US but using the "NE" region code. Now starting yesterday I'm getting this error when trying to perform an update.

ERROR: received status code -2010 (INVALID PARAMS)

However, if I place the program in debug mode it seems to be getting the proper JSON data back but keeps looping the same request over and over again. Maybe the response from the API has slightly changed and you need to update your program accordingly?

I have tried the default US region code and that has always given me a "timed out" error.

Here's an example of the debug response I'm seeing:

+POST https://gdcportalgw.its-mo.com/api_v190426_NE/gdc/BatteryStatusRecordsRequest.php map[RegionCode:[NE] VIN:[REMOVED] custom_sessionid:[REMOVED] tz:[America/New_York]]
HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Date: Mon, 30 Sep 2019 12:25:32 GMT
Server: Apache
Strict-Transport-Security: max-age=15768000

2fe
{"status":200,"VoltLabel":{"HighVolt":"240","LowVolt":"120"},"BatteryStatusRecords":{"OperationResult":"START","OperationDateAndTime":"2019\/09\/30 08:23","BatteryStatus":{"BatteryChargingStatus":"NOT_CHARGING","BatteryCapacity":"240","BatteryRemainingAmount":"216","BatteryRemainingAmountWH":"34960","BatteryRemainingAmountkWH":"","SOC":{"Value":"90"}},"PluginState":"NOT_CONNECTED","CruisingRangeAcOn":"222000","CruisingRangeAcOff":"242000","TimeRequiredToFull":{"HourRequiredToFull":"5","MinutesRequiredToFull":"30"},"TimeRequiredToFull200":{"HourRequiredToFull":"2","MinutesRequiredToFull":"30"},"TimeRequiredToFull200_6kW":{"HourRequiredToFull":"1","MinutesRequiredToFull":"30"},"NotificationDateAndTime":"2019\/09\/30 12:23","TargetDate":"2019\/09\/30 12:23"}}
0

[joeshaw]

Could you try setting the environment variable BROKEN_BATTERY_CHECK=1 and run the carwings update command again?

Back in December 2018 Nissan broke the API used to check for battery status, and I had to add a hacky workaround that checks the NotificationDateAndTime timestamp in the JSON response. If it hasn't updated for a minute the command times out. Maybe that timeout needs to be longer, or maybe the API has changed again in a way such that this check no longer works either.

[joeshaw]

Another thing to check: Is the NotificationDateAndTime in the right timezone for you? In your pasted JSON it is 2019/09/30 12:23 -- that should be in local time. Switching the region might affect your time zone, as would your system's local timezone.

[joeshaw]

I can reproduce the -2010 status code when I try to use the NE region for my US car. There's probably not anything I can fix there.

[Todd1561]

OK, does that mean there's effectively no way to use this program in the US? My understanding was our only option was to use the Euro region code because of changes they made to the US API that haven't been implemented here.

[joeshaw]

US should work fine, that's what I've been using. They have instituted a new API that the US Nissan app uses, and which I haven't implemented, but the old API has continued to work.

The API in general is pretty flaky -- while trying to investigate your issue I saw an update timeout as well, but I just re-ran it now and it worked. I wish I had a better explanation, but the Nissan service for this just isn't very good.

[joeshaw]

I just ran some more tests and it looks like they fixed the key-based battery status checks, which should improve reliability. I will add a commit to remove the workaround and hopefully that'll improve reliability for you.

[Todd1561]

Awesome, thanks for looking into this so quickly! I'll try it out and let you know.

[joeshaw]

Oop, merging the pull request auto-closed this. @Todd1561 can you try this out and let me know if it behaves better for you?

[Todd1561]

I'm still getting the timeout with either the NE or NNA region. So the -2010 error seems to be gone, so that's different. Just to clarify, should I be specifying the NE region or just using the default NNA US region? Thanks!

[joeshaw]

Since you're in the US, try the NNA region. You could also try setting the -timeout flag to something longer than 60s. carwings -timeout 5m update perhaps.

[Todd1561]

OK thanks. Are we sure this an API issue? When I run in debug mode I see your program initiating the same call over and over again. Each time there seems to be valid JSON data coming back (e.g. I can see my valid current SOC in the response). So presumably the API is sending information but I'm wondering if it's not what your program is expecting and therefore you re-run the request. But I'm probably misunderstanding what is going on here.

[joeshaw]

The way the API is designed is that the program makes an initial API request to update the car, and it gets back a "key". The program then has to make another API call to ask about the status of the key, so this is what you're seeing repeated in the debug output. Once the update has finished, the API says, "ok, I finished updating." So the flow looks like this:

Client: I'd like to update battery status! Server: OK! I am going to contact the car, check back with key "abc123" (wait 5 seconds) Client: What's up with key "abc123"? Server: No news yet (wait 5 seconds) Client: What's up with key "abc123"? Server: No news yet ... after 60 seconds ... Client: What's up with key "abc123"? Server: No news yet. Client: I give up 😭

OR

Client: What's up with key "abc123"? Server: I successfully updated!

And then you would run carwings battery to see the results.

So the timeout could just be that (a) Nissan really isn't able to contact your vehicle and get the status, (b) doing so is taking longer than the 60 second default timeout, (c) that there is an issue with the API.

Although Nissan's API is pretty unreliable, given that I'm currently able to update my vehicle battery status it's probably not (c) right now. Unfortunately the API doesn't give any useful feedback why the update is taking so long, and there's no real failure other than just giving up after trying for a while. So I don't really have any insight into why the update might be failing for you right now. If you're parked in a garage, maybe the 3G cell signal isn't strong enough. Maybe the 30 days since the car last asked you for permission to send your data to Nissan has passed and you haven't hit "OK" on the touchscreen at power-on. Maybe there's another issue. I know it's frustrating and I'm sorry about that, but at this point I don't think it's an issue in the code here.

One last thing to note: all the carwings update command does is instruct Nissan to ask the car for its latest battery data. carwings battery asks the API for the most recently available information. It's possible that Nissan gets the updated info even though the carwings update command timed out. There is a timestamp in the carwings battery output -- check that to see if it's recent and that'll give you a sense of whether up-to-date info came in after carwings update gave up.

[Todd1561]

Oh OK, thanks for the thorough explanation, that makes sense. I do have the car in a garage at the moment, but the Nissan Mobile app has never had an issue pulling data. I tried extending the timeout to 5 minutes but still no go. You can keep the issue closed, seems like it's some oddity on my end.

Thanks again for looking into it

[joeshaw]

@Todd1561 What model and year do you have? I wonder if it's something to do with 2nd generation cars (2018 or newer)

[Todd1561]

It's a 2019 SV, 40 kW battery

[Todd1561]

It's looking to me like the newer cars need to use the new API that has a base URL of https://icm.infinitiusa.com/NissanLeafProd/rest/. After reviewing some of the other API projects I started using this one (handily linked on your project page): https://github.com/Tobiaswk/dartnissanconnectna and it's been working great for me. This appears to be the only one that implements the new USA API. Sniffing my network while running the commercial iOS app on my phone confirms a lot of traffic to that infinitiusa.com URL.