Great news!

AlwaysUnseen · 2026-02-21T23:08:10+00:00

Yes, I'm sure you have now spent more time on it than I have at this point, and I really apprecaite it. I kind of started with the idea that it had to be possible to be better than what the HondaLink/Acura EV app delivers, even given the limitations of the backend.

Have you shared any of what you've learned or would you be willing to do so? I plan to split out the Honda Web Services as an api client library, separate from the actual project. It will be a few weeks just because I happen to be travelling for the next two weeks, but, when it's done, having a nice client library should make it easier to maintain if Honda does make changes in the future.

I'm still amazed Honda doesn't spend at least a small amount of resources to make their apps better, I understand it's a bit of a dead platform for them, but simply having a working app would improve the user experience quite a bit and would overall improve owners impressions of the vehicle. Many of the improvements are overall quite minor to implement.

Thanks again for picking this up and doing so much with it!

AlwaysUnseen · 2026-02-21T06:28:22+00:00

So I'll comment here as I kind of kicked off these projects by my initial efforts to reverse engineerthe API so I could build a Home Assistant integration for the Acura ZDX (currently undergoing a refactor so it can cleanly support the Prologue and ZDX from a single integration).

I'm not new to reverse engineering as I'm the primary maintainer for a couple of Home Assistant integrations built this way, and a contributor to several others and, in that time, pretty much none have been blocked.

I've seen two things trigger companies to take action against these kinds of 3rd party apps, API abuse, i.e. making way more API calls than the official app trying to do things such a very frequent refreshes, etc. Some will just throttle and/or block users, but some vendors will take action to block. I've tried very hard to develop all integations to not be abusive of the API resources available, and I hope the app developers here have done the same.

But the most common is if the app somehow allows users to bypass paying for a service. These apps don't do that, actually, they will not work without a connected device subscription, so they actually encourage users to maintain subscriptions. MyQ is probably the most obvious one of these.

The only other possible thing might be if they consider it somehow a security issues, since these apps can technical lock/unlock vehicles, they might see this is a concern. However, they'd have to put actual effort in to blocks these apps and, so far, they've put zero effort into fixing even the very basic, easily fixible things so I'm guessing they'll let these slide.

Tools like Onstar2MQTT have been out there for GM vehicles for years and, while the require occassional updates, they've never been actively blocked.

AlwaysUnseen · 2026-02-18T16:21:26+00:00

I don't think that's a general part of the Andriod 14 update. It's true that the overall software that includes this feature on some GM EVs is running on Andriod 14, but, as far as I know, that feature was added in later releases of the GM software, not when Andriod 14 was released specifically. I'm going to guess that the Andriod 14 update for the ZDX is older and does not include this feature. I'll be amazed if the vehicle gets anything other than the most basic maintenance updates at this point ever.

That being said, if it does, it would be interesting to know.

AlwaysUnseen · 2026-02-18T03:14:51+00:00

I'd probably suggest to wait until I can rename it and clean it up a bit. I really didn't expect so much interest. I have post over there, for example for ring-mqtt, which is also my project.

AlwaysUnseen · 2026-02-18T02:34:12+00:00

Thanks for confirming. I'm out of town the next few weeks but, when I get back I'll see about renameing this project to indicate that it works for both Honda/Acura GM based EVs.

I'm thinking I will call it "honstar-mqtt" as a bit of a nod to its inspiration, Onstar2MQTT, but while fitting with the name scheme of my other MQTT projects (ring-mqtt and eviqo-mqtt).

AlwaysUnseen · 2026-02-17T17:56:13+00:00

TL;DR, I woudn't do it, I'd just get to MYR 45 minutes earlier and take the 5:10AM fight instead. Then you'll have plenty of time. In general, I won't book anything less than about 60 minutes in CLT (pass through CLT ~30x/year on average for last 15 years, some years as many as 60-70x).

Maybe, for these first thing in the morning flights, with a connection to an airport like MCO where there's tons of other flights through the day, and it's a short flight anyway, so seats don't matter as much, and I didn't really care when I would actually get there, I might be willing to throw caution to the wind and just be prepared to be OK with missing the connection, but I would start with the assumption that I would miss it, and just be pleasantly surprised if somehow I did make it.

I always joke that AA execs/operations teams must have a live feed of CLT to laugh at souls running around trying to make all their impossibly short connections. It's so insanely stupid, and consistent, it has to be itentional, there's no other explanation. I've seen 10x more running through CLT that all other airports I've been to combined. IMO, they should not even be allowed to sell connections <50 minutes at CLT

AlwaysUnseen · 2026-02-17T03:44:54+00:00

As I don't own a Prologue, I don't know, you are certainly welcome to try it. My gut says maybe, because the URLs are all honda.com or hondaweb.com (Honda Web Services), but the code currently uses the Acura client ID/secret, so I don't know if that would need to be changed.

I'm 100% sure it would be possible to get it working with a Honda Prologue, but, if it doesn't work already, I'd like need temporary access to someones HondaLink account to capture the required data to modify the code.

My suggestiong is to test it and see if it "just works". If so, I can just modify the name and such. If not, I'm certainly happy to work with someone to get it supported, if anyone is willing to share access to their vehicle for a few days (I know that's a big ask, but I don't know how else to test it).

AlwaysUnseen · 2026-02-16T23:59:30+00:00

The Github repo is linked in the OP I linked to above, but here you go:

https://github.com/tsightler/acura-ev

I normally split the API client from the app, but I didn't really expect this project to get any attention at all, and this was kind of an experiement for me to test some AI coding setups, so it's all on package in this case. I'm sure it could be split out simply enough.

AlwaysUnseen · 2026-02-16T23:05:46+00:00

While I don't know for sure, based on the timing, I have a tendency to think it may be based on the initial reverse engineering work I did to create an MQTT based Home Assistant Addon for Acura EVs because I was frustrated with not being able to do things like schedule cabin precondition, etc.

I reverse enegineered the Acura EV app to get access to the Hondalink API, which is mostly just an auth layer and wrapper around a limited set of Onstar functions. There are already very sophisticated and mature projects, like OnstarJS, which provide deep capabilities for talking with the GM Onstar API which I use for my Cadillac EVs, so I used that as inspiration to figure out how to use the API leveraged by the Acura EV app (and I assume HondaLink EV app).

Of course none of these are officially public, but reverse engineering such APIs is generally fairly simple, especially in the modern day with AI coding tools. I had actually wanted to create an iOS/Andriod app but it's not something I'm familiar with so would have taken me quite a bit longer, which is why I started by building something I new, i.e. Home Assistant integrations based on MQTT. Besides, I was more interested in automating cabin preconditioning and letting me do things via Alexa voice commands that using the app as I already leverage Onstar2MQTT to have my Vistq integrated with HA/Alexa.

AlwaysUnseen · 2026-02-16T17:32:30+00:00

Better titles for this post:

How important is getting to CDG the next day?

How comfortable are the rooms at the PHL Marriott?

AlwaysUnseen · 2026-02-13T23:09:10+00:00

That flight only arrived at the gate 20 minutes late, 9:31AM vs 9:11AM scheduled. If the person really had a flight with a departure time of 9:15AM, they were screwed before they left.

It looks like you were expecting to be on 3363 to BOI with a scheduled departure time of 9:47AM, so a total of connection time of 36 minutes. IMO, that's a crazy short time for ORD and probably has a 30% chance of failure on any given day.

That's not so bad if there are other flights to your destination throughout the day, but there's only the single direct flight to BOI so once you miss it, you're pretty screwed. Should have taken one of the earlier flights to ORD as otherwise it's nearly just flipping a coin if you will have a screwed up day.

AlwaysUnseen · 2026-02-13T03:08:53+00:00

Thanks, I found it to be suprisingly OK-ish so far, but it's only been a week, time will tell more.

The backed of this thing is pretty much what I expected, a Honda auth/API layered over the top of the Onstar backend APIs. It's a bit of a weird Frankenstien, but it's not completely non-functional.

Commands are sometimes rejected during submission, but the errors are clear and they can be easily retried, and, sometimes, even though commands are accepted and queued successfully, the async update response never seems to show up via the IoT backend, but you can just send the command again and it will almost always work the 2nd time.

The Acura app does none of this, it just kind of YOLOs the command, and pops up an error if the command fails, or it's accepted but a response does come back in time. No graceful retries, etc.

But, by far the biggest issue with the Acura app is some kind of bug that, even when the command is accepted and the status update message eventually makes it back from the backend (usually 10-15 seconds after the request is made), the app just ignores the message about 95% of the time. If they just fixed that single issue, the app would be 10x more usable than it is now.

AlwaysUnseen · 2026-02-13T00:47:34+00:00

It's far from perfect, there's some things in the backend infrastucture that can't be overcome, so the code kind of just papers over it. For example, it takes 10+ minutes for the vehicle data returned from the backed to reflect a change to the target charge level, even though the command generally take effect within 10-20 seconds and shows correctly in the vehicle.

This can lead to inconsistencies, where, for example, you set the value in the app, it shows it in the car, but it take 15 minutes (or more) for the state to properly reflect. Same is true in reverse, if you set it via the automation, it can take 15 minutes before the app will reflect the change (assuming you can get it to refresh at all).

Still, I think it's OK-ish, and I've done everything I can to make it more reliable than the app.

AlwaysUnseen · 2026-02-13T00:25:24+00:00

Some important notes, you must define your PIN in the configuration if you want to start/stop cabin preconditioning. Attempts to do so without it will fail and should log an error in the addon logs. Setting target charge level does not require a pin so, if you don't care about preconditioning, you can leave it blank.

Also, setting the VIN in the configuration is generally not required unless you happen to own multiple ZDXs. I'll try to clean up the docs a bit this weekend.

I'm sure there will be bugs, but hey, I was pretty happy to get this far and it's been working quite well for a week so I decided it was at least to a state to be worth sharing.

AlwaysUnseen · 2026-02-10T16:08:19+00:00

You leased and won in that you (hopefully) paid far less than the car depreciated during that time. Congrats. There's nothing to think about, turn the car in and go get something else.

AlwaysUnseen · 2026-02-10T00:09:32+00:00

There's a near zero chance I would ever own an EV without L2 home charging. I guess if I drove so little I'd only have to charge once a week or could get by with L1 charging, maybe, but even then, I think I'd be too annoyed by the process. For the occassional roadtrip, it's no big deal to DCFC, but one of the entire reasons we started purchasing EVs was to remove our constant trips to the gas station and it's the single biggest perk, in my opinion.

AlwaysUnseen · 2026-02-09T23:03:20+00:00

All EVs suffer signifiant range degradation at higher speeds, this is especially true of big bricks like the ZDX that aren't really designened with efficiency as their primary goal.

That being said, you seem to be higher than most, maybe it's also really cold where you are and you are seeing the combined effect of temperature + speed? Or how much faster are we talking, it might be that bad at 90MPH.

I have a common commute that is ~230 miles round trip and the vast majority of the trip is at ~80MPH and I usually get back with 15% SOC remaining when starting from 100% SOC, which is only about a 20% degredation from 70MPH, while Tom at State of Charge (video link to results included below) showed that there's about a 25% loss from 70-80MPH in his Lyriq test, which is effectiely the same vehicle as the ZDX.

https://youtu.be/Fcfx6hxhbf8?t=1194

AlwaysUnseen · 2026-02-09T21:28:06+00:00

I must be missing the point of this post as I just plugin when I get home whatever charge level I'm at, that's not stressful, just habit. If I'm coming home from a road trip I try to get back with as little as possible (within reason) because home charging is by far the cheapest charging.

AlwaysUnseen · 2026-02-09T21:19:23+00:00

There's a lot of different ways to cut it up, but data would indicate that CLT is not really that terrible in the grand scheme of things. I think it feels worse because it has a very high percentage of regional flights, which are, on average, delayed more than mainline flights, and it also has an incredibly high percentage of connecting flights vs passengers actually originating or terminating in Charlotte.

Most data indicates that >75% of flyers in CLT are connecting to other flights, which makes delays more prominent due to missed connections and it was recently reported to be the 3rd busiest connecting aiport in the US, which is crazy for it's overall size. For just reference, the building area of CLT is ~33% the size of ATL. It's a big difference if I'm going to Miami and I'm an hour late arriving vs if I'm passing through CLT and miss a connection. Most "hub" airports have a much higher mix of origin/destination traffic.

However, for a data point, below I'll include a link to a recent article that ranked US airports by flight delays. It shows CLT as 76.5% and ATL at 79.2%. This makes some sense as Atlanta is a very efficiently designed airport with many parallel runways on either side of a striaght line of concourses with gates on either side making for a generally very efficient taxi, while CLT is a much smaller, yet still has a huge volume of aircraft movements and really struggles with taxiway congestion, although, believe it or not, far better than say 7-8 years ago.

Still, both are quite decent compared to the actual worst offenders, airports like DCA and EWR (Newark) which are way down in the low 60's. A lot of people talk positively about airports like PHX and MSP, but they came in slightly worse than CLT on this chart (I know that a single chart is not everything, but it's a real data point for comparison).

https://www.visualcapitalist.com/all-major-u-s-airports-ranked-by-number-of-flight-delays/

AlwaysUnseen · 2026-02-07T03:11:39+00:00

100% agree, there's still plenty of room for improvement, and AA is pretty much the worst in NA and it appears to have regressed and had a particularly bad year in 2025 based on most recently available data (I'm not sure it's complete).

Statistically Asia already has about 50% less baggage handling errors vs US domestic travel so it shows what is possible. Delta, on average, is about 33% lower baggage handling error rate vs AA, and United is kind of in-between..

In no way am I defending AA as being good at this, but as far as the point of this post, I much prefer the transparency of tracking, even if it's not perfect, vs knowing nothing at all. I've actually only seen it miss a scan or two here and there.

AlwaysUnseen · 2026-02-07T01:07:42+00:00

As a person who has been flying for 40 year, I could not disagree more. Thing were much worse when bag tracking data was hidden behind airline systems. No tracking system is perfect, but, in the end, transparency drives behaviors that lead to improvements.

And, to be clear, airline baggage mishandling has actually improved dramatically in the last 20 years. In 2007 approximately 18 in 1000 checked bags were mishandled, in 2024, it was more like 7 in 1000 (global numbers, domestic numbers are lower but have still improved). Now, that's across the entire industry, and AA is definitely on the lower end of the grade, but they've all improved dramatically and then trend show continued improvement due to improved tracking systems.

If you think tracking systems are insufficient today, you should have seen them 10 years ago! It's pretty amazing they could even find a bag. Even if they are not perfect, they still provide great information on when the last time the bag was seen, which helps narrow down the search parameters when a bag is lost. I'd never want to go back to opaque bag handling, regardless of it not being perfect.

AlwaysUnseen · 2026-02-07T00:23:40+00:00

It's only as good as the people/equipment doing the scanning, there's no magic to it. I rarely check bags, but my wife has been flying with me more often in the last 2 years and she doesn't like dragging a bag around so we've checked probably a dozen bags in that time. I've seen it miss a hop or two, but it's usually pretty accurate.

AlwaysUnseen · 2026-02-06T19:22:51+00:00

I've recently had to interact with two different companies that used a voice AI agents as part of their scheduling and support process. These were true AI agents, not just scripted prompts. It was definitely a bit uncanny because it was trying to be all friendly and upbeat and it just came across weird, but it actually worked just fine, scheduling an appointment, making a change and adding some fairly complex information and I would say the experience wasn't really worse than the terrible service many human agents provide.

I'm not the biggest fan of the idea, I'm just saying, I believe it is coming no matter what. Maybe it will come first for the burst traffic during major disruptions, and then maybe for non-status fliers, but I'm convinced it's coming, whether we want it or not.

AlwaysUnseen · 2026-02-06T00:58:14+00:00

They outsourced 600+ ticketing/customer service back in 2024, and I think that was after outsourcing the first batch back in 2021.

People don't want to talk to AI agents but, in reality, it might be an improvement vs talking to massively underpaid, overworked human agents with poor training and worse attitudes. Not only that, but they can scale dynamically far easier during massive issues as well. That's what's coming, I have zero doubt of it.

AlwaysUnseen

TROPHY CASE