No, it doesn’t use this; it uses simple authentication through the component.
The original author of the Automatic component hasn’t been around for a while so if this component requires an update to handle the Pro, someone else may need to take over.
Other than your indentation your device_tracker section looks like mine.
So if HA uses “simple authentication through the component”, then can I assume that leaving the “OAuth Redirect URL” field set to “http://localhost/redirect” at the Automatic developer site is okay? If not, what should it be?
I’ve been playing with this on/off for weeks, so maybe the issue is as you said Pro vs non-pro, but its hard to believe the API would be different. If that is the case, do you know the process for making the developers aware of the problem?
Thanks again for your patience and help.
No idea; let me go take a look.
That’s what I have set. Also:
Client Type: Confidential/Web Event Delivery: No Events
Authorized Scopes looks like this:
Available Scopes
scope:public Access to public information about user.
scope:user:profile Access to user's profile.
scope:location Access to historical location.
scope:current_location Access heartbeat location updates in realtime during a drive.
scope:vehicle:profile Access to vehicle information.
scope:vehicle:events Access to vehicle events details.
scope:trip Access to trips that are visible to a user.
scope:behavior Access to user's driving behavior summary stats.
Unavailable Scopes
scope:vehicle:vin Access to VIN.
scope:adapter:basic Direct bluetooth access to all adapters on the user's account.Event Delivery Preference: WEBSOCKET, otherwise it’s the same as mine. The Automatic guys told me that WEBSOCKET event delivery is a requirement for heartbeat updates … but I’ll try switching it to NO EVENTS to see if matters.
Available Scopes
scope:public Access to public information about user.
scope:user:profile Access to user’s profile.
scope:location Access to historical location.
scope:current_location Access heartbeat location updates in realtime during a drive.
scope:vehicle:profile Access to vehicle information.
scope:vehicle:events Access to vehicle events details.
scope:trip Access to trips that are visible to a user.
scope:behavior Access to user’s driving behavior summary stats.
Unavailable Scopes
scope:vehicle:vin Access to VIN.
scope:adapter:basic Direct bluetooth access to all adapters on the user’s account.
Man you’ve been great. Thanks again.
@Teagan42 was the dev on this but as I said, I haven’t really heard from her in quite some time; even her last tweet was in in December so she may be busily involved in some project.
Hopefully tagging her here will get her to check in.
May have something …
When I changed to NO events, Authorized Users went from 1/25 to 0/25 then back to 1/25 when I started HA.So its looks like it’s authenticating?.
TWO devices showed up - and in fact I’ve seen those two devices in the past but they disappeared. Guess I need do go for a drive to be sure. I have TWO vehicles connected to that same Adapter so that may be the reason why I see two. Does your Automatic device have a MAC address that starts with C_ (C underscore)? That’s not a normal MAC …
Yes, the 1/25 is correct because no matter how many cars you have on the account, HA will be the one consumer of data.
And your two devices with the C_ are definitely your vehicles. I seem to remember mine already being named to match the vehicle name in my account though it was a while back so I can’t be sure.
Great news. As I said, I’ve seen these two devices before, but they never did anything so I removed them from my known_devices with the hope that they would one day reappear. Lets see if they move now that I’ve changed to NO EVENTS. Going for a quick drive and I’ll update the post when I get back…
Good News!
It’s working - although it only updates at the end of a trip - after I turn the ignition off. So apparently what Automatic Labs calls their “heartbeat update” feature is not functional in HA.
Now here’s the strange thing. Both the WEBHOOK and WEBSOCKET settings work for the “Event Delivery Preference” (EDP). So I’m actually right back to where I started from a settings standpoint.
To recap, the only changes I made today was to cycle through each EDP. And each time I changed the EDP I saw the “Authorized Users” go from 1, to 0, back to 1 on HA restart. So clearly it was registering. Is it possible that just making the change away/back to WEBSOCKET fixed the problem? Whichever the case, I hope it’s fixed for good and doesn’t disappear like it did before.
Hey thanks again @rpitera. You’ve been a GREAT help.
PS
If @Teagan42 is listening and is still working on this component, it would be great if the Automatic’s heartbeat update" feature was functional in HA.
That’s how it is supposed to work, so you’re ok there. My Automatic STD does the same.[quote=“tggman, post:30, topic:3813”]
To recap, the only changes I made today was to cycle through each EDP. And each time I changed the EDP I saw the “Authorized Users” go from 1, to 0, back to 1 on HA restart. So clearly it was registering. Is it possible that just making the change away/back to WEBSOCKET fixed the problem? Whichever the case, I hope it’s fixed for good and doesn’t disappear like it did before.
[/quote]
Could it be that doing so reinitialized the connection with HA? Possible but I can’t say for sure. I can say that unless you have a 1 in the count, then it isn’t connected.
I’m glad I could be of help though!
Hi
No upate on the heartbeat location realtime update for HASS ?
Thanks for writing in to Automatic Developer.
Your app now has the additional scope(s) enabled. Note you’ll need to reissue tokens with this additional scope in your oAuth URL for any users you want to receive expanded data from. You can find a preformatted oAuth URL for your convenience in your app settings at developer.automatic.com/my-apps/
Additionally, because you are using current location, you will need to consume all events through websocket instead of webhook. If your app was set to webhook event delivery, it has now been converted to websocket delivery. Please see the documentation for more info on using websockets.
Cheers,
Adam
I don’t think the 1/25 that’s displayed on the developer site means that HASS is connected.
The site displays 1/25 even though the tracker isn’t added to HASS.
device_ tracker
I’m using a PRO with the following settings, and nothing shows up anywhere in HASS.
No ERROR log, been testing for over a week now, followed every recommendation in this discussion.
Looks like someone is going to have to take over development of this component to update it for the Pro.
Just an update; in speaking with @armills on an unrelated update to the Automatic lib for another issue, he stated that he is using the Pro without an issue. (Note that this lib update is merged into dev, so you’ll have to wait for the next update to test and see if it helps with your Pro issue.)
I’m using it with an Automatic Pro, and haven’t had any issues. I assume you’re talking about this thread? Automatic ODB II Issue
We’re accessing the cloud API, so in theory it shouldn’t make a difference, and possibly the extra input sanitizing will help iron out some issues, (even though it creates some extra headaches like this issue). If you can trace a problem back to the library, feel free to open an issue at GitHub - emlove/aioautomatic: Asyncio library for the Automatic API. Archived due to Automatic shutting down - https://automatic.com/customerfaq
The biggest benefit of the new library will be the upcoming websocket support for live updates. Stay tuned!
Thanks to whoever updated the Automatic component in v0.44 to take advantage of the Heartbeat Location feature. I just updated to v0.44 and so far it’s been working great with my Automatic Pro. Thanks again!
That would be @armills, as mentioned above. Give him a shout! He also added webhook support for events which I haven’t set up yet but looks amazing!
Glad to hear it’s working well!
I’ve been using this component for a few days now and I just have to say … this is one of the most reliable device_trackers I have used to date. It’s as good or better then Tasker (which I use to forge OwnTracks MQTT payloads when connected to my car’s BT) and way more reliable than OwnTracks itself.
I compensate for this component’s time delay (~5 minutes), by using the google_travel_time platform, and for the more time sensitive actions, I use a connection to my Google Wi-Fi as an event trigger. So far, this combination of triggers has given me a reliability of 100%.
Thanks again @armills
Wrong place to ask … but I will anyhow. Am I missing something or is there no native support for Google Wi-Fi? I’m currently use IFTTT and Maker webhook to tell HA that a device has connected to my Google Wi-Fi.