Canadian EV - Get status return undefined when it is called after another action about node-red-contrib-bluelinky

[guyaumetremblay]

Never used the auto attach mode (I was not aware of the existence!) but yes, very useful!
I just added a launch.json file with this configuration :

      {
        "name": "Launch via NPM",
        "request": "launch",
        "runtimeArgs": [
          "run-script",
          "debug"
        ],
        "runtimeExecutable": "npm",
        "skipFiles": [
          "<node_internals>/**"
        ],
        "type": "node",
        "console": "integratedTerminal"
      }

For the "bug", on my side, I added a wait node for 90secs before my call to status and it seems to work. But if the lib could manage this, it would be better as I can tap 2 buttons in HomeAssistant back to back and the issue will happen..

[Hacksore]

I think we added guards in the main lib for this so I'm closing this.

[Hacksore]

@guyaumetremblay Are you able to reproduce this with bluelinky? I suspect that the Candian API doesn't like us calling services back to back, the US will throw an error which could be what's happening here.

Steps:

1. git clone https://github.com/Hacksore/bluelinky.git
2. cd bluelinky
3. npm install
4. create a config.json

{
  "username": "",
  "password": "",
  "pin": "",
   "vin": ""
}

5. node run debug
6. select CA
7. select lock
8. repeat steps 5-6 but select status

Once you run through that scrub the output of sensitive data and either add to the issue or send it to me [email protected]

[guyaumetremblay]

Hi @Hacksore , sorry for the delay! Here is the output:

> cross-env LOG_LEVEL=debug ts-node debug.ts

? What Region are you in? CA
{ region: 'CA' }
Logging in...
[2021-02-01 11:33:17] debug: CA Controller created
[2021-02-01 11:33:17] debug: Bluelinky is logging in automatically, to disable use autoLogin: false
[2021-02-01 11:33:17] info: Begin login request
[2021-02-01 11:33:17] debug: [https://mybluelink.ca/tods/api/lgn] {} {"loginId":"REDACTED","password":"REDACTED"}
[2021-02-01 11:33:20] debug: {
  "accessToken": "REDACTED",
  "scope": [
    "profile"
  ],
  "tokenType": "bearer",
  "expireIn": 86400,
  "refreshToken": "REDACTED",
  "signature": ""
}
[2021-02-01 11:33:20] info: Begin getVehicleList request
[2021-02-01 11:33:20] debug: [https://mybluelink.ca/tods/api/vhcllst] {} {}
[2021-02-01 11:33:24] debug: CA Vehicle REDACTED created
[2021-02-01 11:33:24] debug: Found 1 on the account

? What you wanna do? lock
[2021-02-01 11:33:40] debug: Begin lock request
[2021-02-01 11:33:40] info: Begin pre-authentication
[2021-02-01 11:33:40] debug: [https://mybluelink.ca/tods/api/vrfypin] {} {}
[2021-02-01 11:33:40] debug: shouldRefreshToken: false
[2021-02-01 11:33:40] debug: Token not expired, no need to refresh
[2021-02-01 11:33:43] debug: [https://mybluelink.ca/tods/api/drlck] {"pAuth":"REDACTED"} {}
[2021-02-01 11:33:43] debug: shouldRefreshToken: false
[2021-02-01 11:33:43] debug: Token not expired, no need to refresh
lock : "Lock successful"

? What you wanna do? status refresh (fetch from vehicle)
[2021-02-01 11:34:01] debug: Begin status request, polling car: true
[2021-02-01 11:34:01] debug: [https://mybluelink.ca/tods/api/rltmvhclsts] {} {}
[2021-02-01 11:34:01] debug: shouldRefreshToken: false
[2021-02-01 11:34:01] debug: Token not expired, no need to refresh
[2021-02-01 11:34:03] debug: undefined
status remote : {
  "chassis": {
    "openDoors": {
      "frontRight": false,
      "frontLeft": false,
      "backLeft": false,
      "backRight": false
    },
    "tirePressureWarningLamp": {
      "rearLeft": false,
      "frontLeft": false,
      "frontRight": false,
      "rearRight": false,
      "all": false
    }
  },
  "climate": {
    "steeringwheelHeat": false,
    "sideMirrorHeat": false,
    "rearWindowHeat": false
  },
  "engine": {}
}

[Hacksore]

@guyaumetremblay does the same thing happen if you do status (on server cache) as the second command?

I suspect we'll need some better debug logging on the second command as undefined isn't really helping us move forward :)

[guyaumetremblay]

@Hacksore I just tried again the same but with the debugger (VS Code).
You were right, bluelink doesn't like 2 requests in 90seconds. The second request return this as the body:
(sorry, the error is in french but it means: "We already proceed a request for your car. Wait 90 seconds before asking another request")

{
    error: {
        errorCode:'6533'
        errorDesc:'Nous procedons en ce moment au traitement d'une demande precedente pour votre véhicule. Veuillez attendre 90 secondes avant de poursuivre vos prochaines demandes.'
    }, 
    responseHeader: {
        responseCode: 1, 
        responseDesc: 'Failure'
    }
}

The mobile app is probably slow because of this ... 🤦‍♂️

So the undefined come from canadian.vehicle.ts:46 :

const vehicleStatus = response.result;

As the method request return the value of response.body.responseHeader.responseDesc :

      if (response.body.responseHeader.responseCode != 0) {
        return response.body.responseHeader.responseDesc;
      }

[Hacksore]

Likely we can just guard with some optional chaining in that condition and handle the error better. It's worth mentioning I have a wiki to document rate limits for all the regions we could make a bit more robust.

https://github.com/Hacksore/bluelinky/wiki/API-Rate-Limits

For now, I'll open a new issue in the bluelinky repo to track this effort.

Also like the tip about the VSCode debugging, very helpful to capture the state when debug prints fail.
https://code.visualstudio.com/docs/nodejs/nodejs-debugging

[mr-thierry]

@guyaumetremblay I'm curious, why do you request the car status so quickly after sending the command? From my experience, the car takes a good 30 seconds to process the command (I'm in Canada).
In AndroBlue (the Android port of Bluelinky), I refresh the status 60 seconds and 120 seconds after the command is sent.

[guyaumetremblay]

@ThierryD
tldr; because it's bluelink...

You're right, I should not need to call a status after a request. But, by experience with the app, the command result is not 100% accurate. Two examples:

• Unlock door: the result is a success but in fact, it just never work! The app show a dialog saying a success and the car status show the door in red but if you call a status right after, everything appear locked again!
• Climate (EV): Very ofter, you need to call it twice! The first time, the car start the climate but turn it off right after! So the status of the command is a success but if you call a refresh status after, you see that it didn't work. It's a bug that a lot of people complain since some months.

So, I don't trust the result of the api... and I prefer to call a real refresh status myself.

[mr-thierry]

@guyaumetremblay it's my understanding that when you send the command to unlock and do a refresh status just after it, it's normal that the status still says "locked" because the car hasn't processed the command yet. :)

In my experience, the distinction is that when call the API to unlock the car, we are not unlocking the car. But instead we are sending an "unlock" command to the car. Depending of the quality of the network connection of the car, this can take some time. Only when the car acknowledge the command back to the server that the "unlock" status on the bluelink server is updated. And only then when we query the status that the status is "unlocked".

[guyaumetremblay]

@ThierryD Are you telling me that (still talking about the official mobile app), the request take approx. 1min just to be send to the server and, after that, the API respond "unlock successful" BUT the unlock didn't append yet? It take again time to execute it? I'm really not sure about that. The API should not respond a status like that if the car didn't receive the request yet.

And, for example, I requested a Unlock 30mins. ago. The bluelink app still show me that my doors are lock. Just did another test (still with the app): unlock return a success. I wait 2 mins before my call to a refresh status. Result: my doors are locked.

[mr-thierry]

@guyaumetremblay You understanding is almost correct correct! What is happening is that in the real app unlock is sent to the server. The server process the command and send the command over the cellular network to the car to unlock it. The server then returns a HTTP OK 200 to inform the app that the command has be sent to the car.

I know that the server is very slow to return the HTTP OK 200. This could be either because A) the server is in Korea, B) Hyundai doesn't want to pay to upgrade the server, C) to avoid abusing the server or D) another reason I don't know about

Now... Eventually the command reach the car. This could take some time depending on the condition of the cell network. When the car unlock the doors, it calls the server. The server then send a "Notification" with a payload to the user (Firebase Notification on Android). The app show the notification in the status bar, and update the status of the car in the app.

As for your example... I have no idea why you are seeing this behaviour. I would suggest to uninstall/reinstall the app. Personally, I can lock/unlock the car without any problem! :)