Feature Request: Allow app/driver HTTP calls to negotiate TLS 1.3 and HTTP/2

Developers
1

Feature Request: Allow app/driver HTTP calls to negotiate TLS 1.3 and HTTP/2

Summary

External services are beginning to require HTTP/2 and a minimum of TLS 1.3 on their endpoints and are rejecting HTTP/1.1 / TLS ≤ 1.2 connections outright. Hubitat's built-in HTTP methods (httpGet, httpPost, httpPostJson, and the asynchttp*family) currently provide no way for a developer to request HTTP/2 or to set a minimum TLS version, so apps/drivers calling these services fail at the transport layer. Please either upgrade the underlying HTTP client to negotiate HTTP/2 + TLS 1.3, or expose options on the existing methods so developers can opt in.

Concrete, current real-world trigger

Tesla has tightened the transport requirements on their authentication and API hosts (auth.tesla.com, owner-api.teslamotors.com). Clients connecting with HTTP/1.1 or TLS below 1.3 are now rejected with 403/connection-handshake failures before the request is evaluated (so it presents as a "token invalid / null response" even with a perfectly valid token).

This was diagnosed and fixed in the TeslaMate project, which has full control over its HTTP client. Their fix was simply to enable HTTP/2 and force TLS 1.3 minimum for the Tesla auth host:

The same fix is not reachable from a Hubitat app/driver today, because the platform HTTP methods don't expose protocol/TLS-version control. This breaks the widely-used DarwinsDen Tesla Powerwall Manager (and any other integration that talks to Tesla's cloud) for all Hubitat users, with no developer-side workaround short of standing up an external reverse proxy.

Current Hubitat limitation (as observed by developers)

  • The synchronous (httpGet/httpPost/httpPostJson) and asynchronous (asynchttpGet/asynchttpPost/etc.) methods appear to use an HTTP/1.1-only client.

  • The only TLS-related option exposed to developers is ignoreSSLIssues (certificate validation), introduced in 2.1.8. There is no option to set the protocol version (HTTP/1.1 vs HTTP/2) or a minimum TLS version.

  • TLS version is therefore whatever the platform JVM negotiates by default, which a developer cannot raise to "require 1.3," and HTTP/2 is unavailable entirely.

What we're asking for (in priority order)

  1. Preferred: Upgrade the platform HTTP client so it can negotiate HTTP/2 with ALPN and TLS 1.3 automatically when the remote server requires it (transparent to existing drivers, since HTTP/2 falls back to HTTP/1.1 for servers that don't support it).

  2. Or, expose opt-in parameters on the existing sync + async HTTP methods, e.g.:

    httpPostJson([    uri: "https://auth.tesla.com",    path: "/oauth2/v3/token",    httpVersion: "HTTP_2",     // or "2.0"; default "1.1"    minTlsVersion: "TLSv1.3",  // default current behavior    body: payload]) { resp -> ... }

    The same httpVersion / minTlsVersion keys should be honored by asynchttpGet/asynchttpPost/asynchttpPut/asynchttpPatch/asynchttpDelete/asynchttpHead.

Either option resolves it; option 1 fixes affected integrations without any driver changes.

Suggested implementation notes (for whoever picks this up)

  • If the platform is on a JDK 11+ runtime, java.net.http.HttpClient supports HTTP/2 and TLS 1.3 natively (.version(HttpClient.Version.HTTP_2), and SSLParameters / jdk.tls.client.protocols), and could back these methods.

  • If staying on Apache HttpComponents, HttpClient 5.x supports HTTP/2; 4.x does not. TLS minimum can be set via SSLConnectionSocketFactory with supportedProtocols = ["TLSv1.3"].

  • HTTP/2 with ALPN requires the negotiation to happen over TLS; servers that don't support h2 will ALPN-fall-back to HTTP/1.1, so enabling h2 by default is low-risk for existing integrations.

Impact / who is affected

  • Any Hubitat integration that calls a service enforcing HTTP/2 or TLS 1.3 — currently and most visibly all Tesla cloud integrations (Powerwall mode control, backup reserve, storm watch, vehicle integrations). This list will grow as more providers tighten transport security.

  • Today the only workaround is a user-run external reverse proxy (nginx/Caddy/Tesla-HTTP-Proxy) that speaks HTTP/2+TLS1.3 upstream and HTTP/1.1 to Hubitat — impractical for most users and outside the platform.

References

PS, Claude wrote this as I’m not a dev.
@bobbyD @mike.maxwell

2

FWIW, I was speaking to some of the Infra and networking engineers at work today, and they advised many big players and even Aus Government agencies will be enforcing TLS v1.3 by years end.

3

This will be a 2.5.1 update. But it will definitely be in 2.5.1, not maybe.

4

Thank you for the great support Hubitat team! :folded_hands:

5

UPDATE: The Tesla app is working again on Beta Release 2.5.1.118! :tada: :smiling_face_with_sunglasses:

image
image2026×1108 413 KB

6

from v2.5.1.120 the entire Tesla Powerwall manager app is working 100% (local gateway comms was broken in .118) - Lovely work Hubitat team! :tada::ok_hand:

SCR-20260704-htph
SCR-20260704-htph2782×832 223 KB

7

How can I get Powerwall Version 3.9.x as I’m now on Hubitat Version 2.5.1.128

Hubitat Package Manager is reporting Powerwall Verison v0.3.84.20240405 is the most current. I’m guessing I need 3.9.x in order to solve the token validation issue.

Tesla Powerwall Manager

**app:68**2026-07-15 2:07:26.308 pm

info

HTTP exception getting status from /api/1/products : com.hubitat.hub.executor.helpers.ExecutorHttpResponseException: status code: 403, reason phrase: Forbidden

Thanks

8

Here’s my modified app - you do need to be on HE 2.5.1.x (currently in Beta) for it to work tho.

https://raw.githubusercontent.com/dJOS1475/hubitat/refs/heads/master/tesla-powerwall-manager.groovy

9

Thanks for the updated app. Unfortunately I still can’t get full validation:

image
image1929×589 39.2 KB

image
image1522×206 7.05 KB

image
image1908×469 36.5 KB

Should I try generating a brand new refresh token?

10

That is worth trying.

image
image2764×838 218 KB

11

Thanks for the quick reply. I’ll give that a try tomorrow

12

are you running the latest Hubitat Beta release FW? Without it, Tesla servers won’t respond.

13

Yes, I’m running Hubitat Platform Version2.5.1.128

I just generated a new Tesla Token and pasted into your app and it is still failing which appears to be related to the refresh token is getting copied into the access token field or am I doing something wrong trying to set this up?

image
image1834×1204 257 KB

14

You shouldn’t need to enter an access token, once you enter in the main token, it should be able to generate the access token by itself.

15

I just upgraded to the latest beta, and so far it’s still working normally.

IMG_4836
IMG_48361179×1852 282 KB

16

Ok thanks for the confirmation. What appears to be happening is I make sure both teh Refresh Token and Access token are blank. I then paste in my refresh token. It validates and then when I open the “OPTIONAL” section, the access token field appears to be automatically loaded with the refresh token and shows “not validated”

I’m using the Windows version of Tesla Auth to generate my refresh token

As FYI, I have a 2025 Tesla PowerWall 3

17

The PW3 uses a different API to the PW2, known as the Fleet API, that’s why it isn’t working for you.

18

Thanks, I thought I read somewhere that Tesla very recently removed Owner API access to the PW3 and now only supports Fleet API and was wondering if that was why PowerWall Manager is not working for me. Do you have any plans to update your App to use the Fleet API?

19

It’s not my app and I don’t have a PW3 to test with. Here is the authors Githb repo - you could always raise an issue requesting he support it.

20

Good news: the App started working the other day using my Owner-API refresh token. I also pulled the code off GitHub and, with the help of Claude AI the original code has been updated to use the Tessie Fleet API for authentication. I need to do some more testing, but if all goes well, I’ll send the updated code to DarwinsDen so they can decide if they want to make it available to everyone or not.