Releases: willbeeching/ha-jlr-incontrol
Release list
JLR InControl v1.5.0-beta.6
Sign in again after updating if location has stopped for you — Settings › Devices & Services › Jaguar Land Rover InControl › ⋮ › Reconfigure. If location is currently working, just update and restart; your session is saved and resumed.
Back to a 4-minute keep-alive
beta.5 raised the keep-alive from 4 minutes to 8, to find out how infrequently we could get away with touching JLR's servers. That was a mistake and it is reverted.
What happened: a session held for 11 hours on the 4-minute touch. The same session, moved to 8 minutes, was lost 3 hours later — a successful location read, then dead twelve minutes after it. Meanwhile a second account left on 4 minutes passed 21 hours on a single sign-in and was still going.
Two runs is not proof, and I am not claiming to have measured the timeout. But the saving was seven requests an hour and the cost of being wrong is you going to find an emailed code. Four it is.
The rest is instrumentation
Both of this weekend's failures took a day each to understand, and neither needed to.
A portal session now records when it was created — saved alongside the session itself, so its age survives a restart — and every successful keep-alive and every successful location read logs it:
portal keep-alive ok, session 6h14m old
owner portal read ok, session 6h44m old
Age is what separates the two ways one of these sessions dies: idled out because we touched it too slowly, or expired because the far end was only ever going to keep it so long. At the moment of failure those look identical, and piecing the age together afterwards from scattered log timestamps is what cost the time.
A successful keep-alive also used to log nothing at all, which made it indistinguishable from a timer that never fired. That gap is precisely why "was 8 minutes too slow, or did the session die of old age?" could not be answered from a full day of logs.
If you hit a sign-in prompt on this version, the last few session … old lines before it are the whole diagnosis. They are debug-level — enable debug logging on the integration if you want them.
Live vehicle status over the telemetry websocket is unaffected by any of this.
What's Changed
- Measure the portal session's age, and go back to four minutes
- Keep the changelog right when a release is re-run
Installation
HACS (recommended)
Add https://github.com/willbeeching/ha-jlr-incontrol as a custom repository (category Integration), install, and restart Home Assistant.
Manual
Download jlr_incontrol.zip, extract into config/custom_components/, and restart Home Assistant.
JLR InControl v1.5.0-beta.5
No sign-in needed if location is working for you now — just update and restart. Your portal session is saved with the config entry and resumed after the restart, so the update costs you nothing.
If location has already stopped and you're being asked to sign in, then you do need to — but that is the session having lapsed before this release, not this release asking for one.
The keep-alive works
beta.4's 4-minute keep-alive held a portal session for 11 hours on a single sign-in, straight through the 2-hour cap that kills the identity session behind it. That settles the mechanism: once a portal session exists it is completely independent of the sign-in that created it, provided it is never allowed to lapse.
Four minutes was only the first interval tried, though — chosen for safety, not measured. Every touch that isn't needed is one JLR shouldn't have to serve, so this release walks it up to 8 minutes to find where the real boundary is. If it holds, it keeps climbing; if it doesn't, we've bracketed the timeout between four and eight and can stop guessing.
If you test this, the useful number is how long location keeps working. If eight minutes is too slow you'll know quickly — within roughly eight to sixteen minutes of the restart. Past a couple of hours means eight is fine.
Jaguar owners: the second half of the beta.3 fix
beta.3 checked which brand's portal actually has your cars on it, but only when signing in fresh — not when reusing a saved session. If you were carrying a live Land Rover session from an earlier version, it was resumed as-is and you landed back in the empty garage, skipping the check meant to catch exactly that. The saved session is now checked the same way, in the same request it was already making.
One consequence, so it isn't a surprise: if you are in that position, the saved session will now be correctly rejected, and replacing it needs a sign-in. That is the one case in this release where an emailed code is unavoidable.
Live vehicle status over the telemetry websocket is unaffected by any of this.
What's Changed
- Walk the keep-alive interval up to eight minutes
- Check the garage when resuming a remembered session too
Installation
HACS (recommended)
Add https://github.com/willbeeching/ha-jlr-incontrol as a custom repository (category Integration), install, and restart Home Assistant.
Manual
Download jlr_incontrol.zip, extract into config/custom_components/, and restart Home Assistant.
JLR InControl v1.5.0-beta.4
You will need to sign in again after updating — Settings › Devices & Services › Jaguar Land Rover InControl › ⋮ › Reconfigure. Not because of anything in this release; the session you have now has almost certainly already lapsed.
What changed
The owner-portal session that location depends on was being kept alive on the 15-minute housekeeping cycle. That is too slow. Measured on a live account: a portal session was already gone 15 minutes and 4 seconds after an interactive sign-in, and the identity session behind it refused to mint a replacement — both dead, from one emailed code, inside a quarter of an hour. The keep-alive was not preserving the session, it was discovering the loss.
It now runs on its own 4-minute clock, well inside the shortest session life observed. If the portal session has a short idle timeout, this should hold it open indefinitely and location will survive on a single sign-in.
A lost session is also reported the moment the keep-alive finds it, rather than up to half an hour later, and the touching then stops rather than retrying a sign-in that cannot succeed.
This is an experiment, and it may not work
If four minutes is still too slow, or the endpoint being touched does not count as activity on JLR's side, you will still be asked to sign in. Reports either way are genuinely useful — please say how long location kept working before it asked again.
Live vehicle status over the telemetry websocket is unaffected by any of this and keeps working regardless.
What's Changed
- Keep the portal session alive on a four-minute clock
Installation
HACS (recommended)
Add https://github.com/willbeeching/ha-jlr-incontrol as a custom repository (category Integration), install, and restart Home Assistant.
Manual
Download jlr_incontrol.zip, extract into config/custom_components/, and restart Home Assistant.
JLR InControl v1.5.0-beta.3
No sign-in needed — update and restart.
Jaguar owners: your location should start working
Jaguar and Land Rover share one sign-in, so signing in to the Land Rover portal succeeds even for an account with only a Jaguar on it — and then shows an empty garage. The Land Rover portal was always tried first and the first successful sign-in won, so Jaguar-only owners were signed in, had no vehicles found, got no location, and saw nothing in the logs explaining any of it.
A successful sign-in is no longer taken as proof of the right portal. The garage is checked, and a brand with none of your cars on it is passed over. The vehicle count is now logged either way, so "no cars on this portal" and "we read the response wrongly" can be told apart.
Still known, still being worked on
The owner-portal session that location depends on is lasting well under an hour before it asks you to sign in again. That is not fixed here and is the current focus — this release is the Jaguar fix only.
Live vehicle status over the telemetry websocket is unaffected either way.
What's Changed
- Pick the brand portal that has the cars on it
Installation
HACS (recommended)
Add https://github.com/willbeeching/ha-jlr-incontrol as a custom repository (category Integration), install, and restart Home Assistant.
Manual
Download jlr_incontrol.zip, extract into config/custom_components/, and restart Home Assistant.
JLR InControl v1.5.0-beta.2
Beta. Fixes vehicle location staying unknown on some cars even though the sign-in is working. No sign-in needed — update and restart.
What was wrong
To read a car's location the integration needs the owner portal's own internal id for that vehicle, and it took that from a single field which turns out to be missing on at least some fully registered cars. No id meant the location was never looked up — and nothing was logged, so it looked like "no location" rather than "couldn't find the car".
The dashboard's own links carry the same id, so those are now read as a fallback. Deliberately only where it is unambiguous: one car short of an id and one link spare is certain, anything else is a guess, and quietly showing one car's location for another would be worse than showing none. Where it stays ambiguous it now says so in the log instead of failing silently.
Also
When a vehicle record has no setup link, the integration now logs which fields that record does contain (field names only — the values hold your VIN and registration). If your location is still unknown after this, that line tells me exactly what to fix rather than leaving me to guess.
The portal-session persistence from beta.1 is unchanged and is still under test.
What's Changed
- Find the portal's vehicle id when the setup link is missing
Installation
HACS (recommended)
Add https://github.com/willbeeching/ha-jlr-incontrol as a custom repository (category Integration), install, and restart Home Assistant.
Manual
Download jlr_incontrol.zip, extract into config/custom_components/, and restart Home Assistant.
JLR InControl v1.5.0-beta.1
Beta. Reworks how the vehicle-location sign-in is kept, based on a measurement rather than a guess. Update, sign in once, then please leave it alone and report back — how long it lasts is the whole question.
What was measured
On a live account, Jaguar Land Rover's identity session lasts 60 minutes idle, 2 hours absolute. Nothing this integration does extends either, and a new one can only be created by signing in with an emailed code. The portal session that identity session creates is the durable half — one in active use has been observed working for over thirty hours.
What was wrong
This had it exactly backwards. It saved the short-lived identity session, threw the durable portal session away on every restart, and then tried to create a new portal session using an identity session that had already expired. That is the entire cause of the repeated "sign in again" prompts.
What changes
The portal session is now what gets saved. On start it is offered straight to the portal, and if it still works there is no sign-in chain at all. The identity route becomes a fallback, used only to create a new portal session while it is still possible — and whatever it creates is saved in turn.
Also stops saving one cookie that describes a single pending sign-in request rather than the session; handing a stale one back is a likely reason a second sign-in was refused while the session behind it was still alive.
The honest limit
When the portal session eventually dies there is no way back without you — Home Assistant will ask for one emailed code. This does not remove that. It aims to make it rare rather than half-hourly. If it still fails within the hour, the next step is removing vehicle location rather than asking anyone for more codes.
Live vehicle status is unaffected, as it has been throughout.
What's Changed
- Keep the portal session, not the identity session
Installation
HACS (recommended)
Add https://github.com/willbeeching/ha-jlr-incontrol as a custom repository (category Integration), install, and restart Home Assistant.
Manual
Download jlr_incontrol.zip, extract into config/custom_components/, and restart Home Assistant.
JLR InControl v1.4.8
Another attempt at vehicle location stopping about half an hour after you sign in. Update, then sign in once more.
What the evidence shows
Two sign-in attempts thirty minutes apart, on a build that does not modify the stored sign-in at all:
16:06 login SUCCEEDED
16:36 login FAILED
Same stored sign-in, byte for byte. Only time differs. So the earlier releases that blamed the way cookies were saved were wrong — that was coincidence, and I read it as cause. Apologies for the churn; several of those releases asked you to sign in again for nothing.
What actually happens is simpler: a sign-in works, the live connection keeps working for as long as nothing rebuilds it, and signing in a second time from saved credentials fails once the session has aged out. The portal's own session appears to time out after thirty minutes — which is exactly how often location was being read, so every read arrived just as the session lapsed and could not get back in.
The change
Stop needing the second sign-in. The integration now makes one small request to the portal every fifteen minutes, comfortably inside the timeout, so the session never lapses. Location itself is still read every thirty minutes — this adds around ninety small requests a day, not triple the page loads.
Being straight with you
This is an experiment. If location survives past an hour and overnight, the diagnosis was right. If it still stops after thirty minutes, the timeout is somewhere this change cannot reach, and the honest answer will be to remove location rather than keep asking people for emailed codes. Either way I will say which.
Live vehicle status is unaffected and has been throughout.
What's Changed
- Keep the portal session warm so it never has to sign in twice
Installation
HACS (recommended)
Add https://github.com/willbeeching/ha-jlr-incontrol as a custom repository (category Integration), install, and restart Home Assistant.
Manual
Download jlr_incontrol.zip, extract into config/custom_components/, and restart Home Assistant.
JLR InControl v1.4.7
Removes the change that has been causing the repeated "sign in again" prompts since v1.4.2.
Update, then sign in once. Sorry — this should be the last time. The evidence is now clear and it points at something I added rather than at Jaguar Land Rover.
What happened
v1.4.2 started refreshing the stored sign-in cookies after each connection to the owner portal, to try to keep the session alive. It had the opposite effect, and every version since has inherited it:
| version | behaviour | session lasted |
|---|---|---|
| v1.4.1 | no refresh | ~33 hours |
| v1.4.2 – v1.4.6 | with refresh | until the first re-login, ~30 minutes |
The reason: signing in to the portal can hand back routing cookies pointing at a different identity server from the one holding your session. Adopting those makes the stored set inconsistent, so every later sign-in is routed to a server that has never heard of the session — which looks exactly like an expired session and isn't one. Changing it to merge rather than replace (v1.4.4) only made it survive a bit longer before doing the same thing.
The set captured when you sign in is consistent by construction. It is now replayed unchanged, which is the only arrangement that has lasted more than an hour.
Live vehicle status has been unaffected throughout all of this.
What's Changed
- Remove the cookie refresh; it caused every failure it was meant to prevent
Installation
HACS (recommended)
Add https://github.com/willbeeching/ha-jlr-incontrol as a custom repository (category Integration), install, and restart Home Assistant.
Manual
Download jlr_incontrol.zip, extract into config/custom_components/, and restart Home Assistant.
JLR InControl v1.4.6
Fixes vehicle location repeatedly asking you to sign in again.
Update, then sign in once more — Settings → Devices & Services → Jaguar Land Rover InControl → ⋮ → Reconfigure. The improved sign-in capture only applies to a new sign-in. Apologies for asking again; this one is based on a captured exchange rather than a guess.
What was actually wrong
A bounce back to the login page means one of two things, and they look identical from the outside: the session expired, or the request reached an identity server that never held it. It was the second, every time.
Jaguar Land Rover's identity service sits behind a load balancer. The session cookie is necessary but not sufficient — a companion cookie routes the request to the server actually holding the session, and two more route inside their gateway. All of them arrive together when you sign in. Send the session without its siblings and you get the login page, looking for all the world like an expired session. That is what the previous few attempts were chasing.
Two fixes:
- The refresh only collected cookies applying to the site root, silently excluding two scoped to a subpath. It now takes the whole set.
- The session cookie's value is something the sign-in already returns separately, so it is now derived from that as well — the one cookie that cannot be missing no longer depends on it being noticed.
After this, a sign-in should last rather than needing repeating within the hour. If it still does not, that is worth reporting: it would mean the session really is short-lived, which is a different problem with a different answer.
Live vehicle status has been unaffected by all of this throughout.
What's Changed
- Carry the whole identity cookie set, not just the session
Installation
HACS (recommended)
Add https://github.com/willbeeching/ha-jlr-incontrol as a custom repository (category Integration), install, and restart Home Assistant.
Manual
Download jlr_incontrol.zip, extract into config/custom_components/, and restart Home Assistant.
JLR InControl v1.4.5
Stops the "sign in again" repair coming back every six hours after you dismiss it.
It is now raised once per Home Assistant restart rather than on every retry. Dismissing it means you have read it; re-raising it over a problem you cannot currently fix is nagging rather than informing.
Also adds a debug line naming which sign-in cookies are stored (names only, never values), to help diagnose portal sign-ins that land back on the login page.
No sign-in needed for this release. If your location is not updating, hold off on signing in again for now — it is under investigation and another sign-in is unlikely to help.
What's Changed
- Stop re-raising the sign-in repair, and log which cookies we hold
Installation
HACS (recommended)
Add https://github.com/willbeeching/ha-jlr-incontrol as a custom repository (category Integration), install, and restart Home Assistant.
Manual
Download jlr_incontrol.zip, extract into config/custom_components/, and restart Home Assistant.