Core: Automatic OBDII Tracker – "err_invalid_client" – Change of authorisation method?

Created on 3 Aug 2017  Â·  29Comments  Â·  Source: home-assistant/core

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version):
0.50.2

Python release (python3 --version):
3.5.2

Component/platform:
device_tracker/automatic

Description of problem:
When Home Assistant is loading components, it is no longer able to configure a web socket with Automatic's servers. Enabling "DEBUG" logging for all components doesn't give much information, other than an error in the form of "err_invalid_client".

Expected:
Successful connection with Automatic's servers and establishment of Websocket.

Traceback (if applicable):

2017-08-03 08:16:01 ERROR (MainThread) [homeassistant.components.device_tracker.automatic] err_invalid_client
2017-08-03 08:16:01 ERROR (MainThread) [homeassistant.components.device_tracker] Error setting up platform automatic

Additional info:
During the setup of the platform, I can see that a CURL request is made to Automatic servers using the client secret, client ID, username and password as follows:

2017-08-03 08:23:33 DEBUG (MainThread) [aioautomatic.base] Sending POST, to https://accounts.automatic.com/oauth/access_token: {'client_secret': '[REDACTED]', 'password': '[REDACTED]', 'username': '[REDACTED], 'scope': 'scope:location scope:vehicle:profile scope:trip scope:current_location', 'grant_type': 'password', 'client_id': '[REDACTED]'}

Digging through the API documentation for authorisation, I cannot find any method that uses "password" as a grant type. They clearly state that 'value should be "authorization_code"'.

I'm wondering if there has been a change in Automatic's accepted authorisation methods (perhaps since August 1st? The last location that HA has was received from Automatic on 01/08/17 at 07:57am GMT. This is near enough to midnight in California where Automatic's head offices are located, if they did swap at 00:00.

Most helpful comment

Switching to OAuth2 will be a better model in any case.

We should be able to redirect the user with the configurator.

All 29 comments

This is not limited to the Pro units either - I am on a first generation unit and am experiencing the same symptoms and same error message. (HA 0.50.2 - Python 3.4.2 - Deb Jessie)

Other users reporting the same in the forums; I have directed them to this issue.

I am using a 2nd generation Automatic adapter, the one released before the Pro and Lite models were announced.

I have reached out to Automatic's devs via email to see if it is as simple as the API has changed to support 'authorization_code' only — it seems the most likely case.
An update to armills/aioautomatic will be required if so.

I have a single Automatic PRO adapter which was WORKING fine as one of my device_trackers at v0.49. First NOTICED it was broke after upgrading to 0.50.2

HASS Config:

device_tracker:

  • platform: owntracks
  • platform: automatic
    client_id: !secret automatic_client_id
    secret: !secret automatic_secret
    username: !secret automatic_username
    password: !secret automatic_password
    HASS Log:
    ERROR (MainThread) [homeassistant.components.device_tracker.automatic] err_invalid_client
    ERROR (MainThread) [homeassistant.components.device_tracker] Error setting up platform automatic

The Automatic Developer site shows Maximum Connections 25 just like @Coolie1101 and @rpitera. Last time I checked on March 4, 2017 it showed 1/25

Confirm that this is due to a change in authentication; OAuth2 is now required. Just looked at this page:
https://developer.automatic.com/api-reference/#support

I guess we are using OAuth...

Something's up with Automatic, I can't even reset client secret, it just sits there and does nothing.

Switching to OAuth2 will be a better model in any case.

We should be able to redirect the user with the configurator.

Let me know if you need someone to test and thanks for looking into this @armills .

Yes thanks @armills . And I too would be glad to help test should it be required.

Update:

It seems like there's some strange things going on with Automatic's authentication servers. I opened a PR that adds OAuth2 support, but when I'm testing I can never re-authenticate with the refresh token they provide. I'm leaving password support in there for now, in case this is just a temporary problem.

I'd appreciate some volunteers to test out the changes in #8962, to see if you're seeing the same behavior. In order to test out the OAuth2 authentication, you need to comment you the username/password in your configuration.yaml. You'll also need to update the OAuth Redirect URL in your Automatic Apps Manager. It should be set to https://<hass-domain>/api/automatic/callback.

You'll also need to update the OAuth Redirect URL in your Automatic Apps Manager. It should be set to https://<hass-domain>/api/automatic/callback.

My "OAuth Redirect URL" is currently set to "https://localhost/api/automatic/callback"

Do I need to change it to something else?

@Coolie1101 You'll probably need to use http instead of https unless you have a cert for localhost, otherwise that should be fine, assuming you're doing the authentication on the same machine running hass. You might need to specify the port though. I've opened the docs PR which provides a little more clarification: https://github.com/home-assistant/home-assistant.github.io/pull/3174/files

I think there developer site is still broken, I'm unable to make any changes to the "OAuth Redirect URL".

I re-enabled the Automatic Device Tracker, and HA is throwing the same error.

Yeah, there's definitely some strange things happening there. You should open a ticket with them if you haven't yet to get more eyes on it. Being unable to reset the client secret is a pretty big problem.

I tested with a second app I created a while back, and still get the same error.

Configuration,yaml

device_tracker:
  - platform: automatic
    client_id: 1234567
    secret: 0987654321
    username: [email protected]
    password: your_password

image

Event Delivery Preference = WEBSOCKET

"You should open a ticket "
I opened a ticket and sent a couple emails since August 2nd, yet to receive a response.

You need to remove username/password from your config to use OAuth2.

2017-08-13 15:31:12 ERROR (MainThread) [homeassistant.config] Invalid config for [device_tracker.automatic]: required key not provided @ data['password']. Got None
required key not provided @ data['username']. Got None. (See ?, line ?). Please check the docs at https://home-assistant.io/components/device_tracker.automatic/

You can't test this without applying the changes from PR #8962.

Above my skill level, as I was never able to locate "requirements_all.txt" while experiencing issues with another component.

@armills I am getting this error
ERROR (MainThread) [homeassistant.components.device_tracker.automatic] Stored refresh token was invalid.
after I restart my HA

my config

  • platform: automatic
    client_id: !secret automatic_client_id
    secret: !secret automatic_key
    current_location: true

and my oath url is http://:8123/api/automatic/callback (Ha is on http)

@imaredia Thanks for testing! Is this after successfully performing the first authentication?

I've also been getting that error myself. I can't say for certain, but I think this is just part of the problem that Automatic is currently having with their authentication servers. For now it seems that the only solution is reauthenticating each time hass is started.

yup I am able to successfully perform the first auth, but after waiting for couple of mins I didn't see any of my car tracker so decided to do reboot and after that I had to auth again.

INFO (MainThread) [aioautomatic.session] Fetching trips.
INFO (MainThread) [aioautomatic.session] Fetching trips.
INFO (MainThread) [aioautomatic.client] Opening websocket connection.
INFO (Thread-10) [homeassistant.core] Bus:Handling , new_state=None>
INFO (MainThread) [homeassistant.components.device_tracker.automatic] Websocket connected.

Let me restart my car and see if adapter sends some trips info, In automatic app it shows my trip today tho so I dont think that should be a problem.

Update: nope nothing yet

I see this was closed, but did it really get fixed? I still cannot get my (2) PROS working. I am unable to edit my OAuth URL in the automatic dev page.

Using https, HA is on an RPI3. Should I be able to access https:///api/automatic/callback? I get a 404 error when trying to go to that URL.

Thanks

Best I could tell they have a fix but decided to wait on the release. Wasn't clear to me why that decision was made.

Paulus was pretty clear about it. It is a breaking change and breaking changes aren't introduced in point releases (unless there is a major issue, like security).

Thanks. My bad I didn't read all through #8962

If you wanna try you can go ahead and install dev build if you comfortable with it. I installed it and does passes authentication in first step but after that it doesn’t update the status of my car and whenever i restart HA i have to redo authentication.

Yep. We've got a fix in for 0.52, but even with this change Automatic's servers are still acting strange, so there could be problems editing the OAuth2 URL. If you can't get it changed, you can always paste the query parameters ("?" and afterwards) onto the correct URL for your instance to get it running as a workaround. At this point though we've fixed everything we can on the Home Assistant side.

I understand this issue is closed – but since upgrading to 0.52.0, it seems the websocket connection is not functioning. Have created a new issue under #9137 for reference. Is anyone else experiencing this issue?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Gio76 picture Gio76  Â·  223Comments

ariel-madril picture ariel-madril  Â·  451Comments

Bergasha picture Bergasha  Â·  176Comments

McGiverGim picture McGiverGim  Â·  124Comments

Ciqsky picture Ciqsky  Â·  129Comments