build: require Elixir 1.19.5 or newer

[magrathean-uk]

Summary

• Require Elixir 1.19.5 or newer in mix.exs, matching the current official image and CI runtime.
• List Elixir and Erlang/OTP separately and remove the untested Elixir 1.18.4 support claim.
• Update the unsupported Debian and FreeBSD guides so manual installations can still use versions that meet the current runtime requirements.
• Keep both manual guides consistent with the PostgreSQL 18 baseline.

Package check

Checked on 2026-07-15:

• Debian Trixie ships Elixir 1.18.3 on Erlang/OTP 27, so its stock packages already do not meet TeslaMate's OTP 28 requirement.
• FreeBSD's latest ports provide Elixir 1.19.5 and Erlang/OTP 28. The quarterly Elixir port is still 1.17.3, so the guide now points to FreeBSD's latest package repository and requires a version check.
• Debian users are directed to the official Elixir installation methods when distribution packages are too old.

The previous Inspect compatibility workaround has been removed completely. This does not add a version matrix.

Validation

• mix ci on Elixir 1.19.5 / Erlang/OTP 28 with PostgreSQL 18.4: 361 tests, 0 failures
• npm run build in website
• Prettier and typos checks
• Requirement accepts 1.19.5 and 1.20.x, and rejects 1.19.4 and 2.0.0

Closes #5505

[netlify]

✅ Deploy Preview for teslamate ready!

Name	Link
🔨 Latest commit	1567e28
🔍 Latest deploy log	https://app.netlify.com/projects/teslamate/deploys/6a57c78ce41e350008f3569c
😎 Deploy Preview	https://deploy-preview-5507--teslamate.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[JakobLichterfeld]

Newer supported Elixir releases warn when TeslaMate calls the private Inspect function.

Thanks, not sure if this is the right direction. Older Elixir versions complain, newer versions are fine.

[magrathean-uk]

Yep, you’re right ; my wording there was backwards. The warning happens on Elixir 1.18.4; 1.19.5 is fine.

This came from the Inspect implementation I added in #5475. Inspect.Map.inspect_as_struct/4 is not available in 1.18.4, while TeslaMate’s support text still includes 1.18.4+ on OTP 28 and mix.exs allows ~> 1.17.

Inspect.Algebra.container_doc/6 is public and available in 1.17, 1.18 and 1.19. I checked the exact formatter on 1.18.4, including the same struct output and token redaction, and current CI is green.

So this PR is restoring the currently stated compatibility rather than fixing newer Elixir. I’ve corrected the PR description as well. If the intended direction is to require 1.19.5 everywhere instead, then I agree the cleaner option is to close this and tighten mix.exs and the support wording.

[Copilot]

Pull request overview

This PR updates how TeslaApi.Error values are rendered via the Inspect protocol to avoid calling the private Inspect.Map.inspect_as_struct/4, which causes warnings-as-errors failures on Elixir 1.18.4+ / OTP 28. It switches to the public Inspect.Algebra.container_doc/6 API while keeping struct-shaped output and preserving credential redaction behavior.

Changes:

• Replaced Inspect.Map.inspect_as_struct/4 usage with Inspect.Algebra.container_doc/6 in TeslaApi.Error’s Inspect implementation.
• Kept output limited to reason, message, and env fields while ensuring redaction is applied before formatting.
• Strengthened the redaction test to assert the inspected output remains struct-shaped (%TeslaApi.Error{...}).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
lib/tesla_api/error.ex	Switches error inspection to Inspect.Algebra.container_doc/6 to eliminate private API usage while preserving redaction and struct-like formatting.
test/tesla_api/error_test.exs	Adds an assertion ensuring the inspected error remains %TeslaApi.Error{...} while still verifying secrets are redacted.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JakobLichterfeld]

If the intended direction is to require 1.19.5 everywhere instead, then I agree the cleaner option is to close this and tighten mix.exs and the support wording.

That's my thinking, but we need to check if Debian and FreeBSD from the manual installation support it. Yes they are marked as unsupported but hard to drop atm.
I do not like to try to avoid something which is not an issue in CI infrastructure. So yes we can introduce Matrix testing different Elixir versions, the foundation is already laid out, but atm this shouldn't be our priority.

[magrathean-uk]

Yep, checked both and changed the PR to that direction.

Debian Trixie's stock package is Elixir 1.18.3 on OTP 27, so it already does not meet the current OTP 28 requirement. FreeBSD 14 with the latest package repository provides Elixir 1.19.5 and OTP 28, while older and quarterly repositories can lag.

I removed the Inspect workaround completely. The PR now tightens mix.exs to Elixir 1.19.5+, lists OTP 28 separately, and fixes both unsupported guides so manual installs remain possible. No Elixir version matrix added.

Full mix ci is green with 361 tests, and the website production build is green too.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[swiffer]

Looks good for the Elixir-related changes.
One minor note: Postgres support has been limited to 18.0+, but the code isn’t enforcing that yet and still allows 16.7 / 17.3 / 18.0. We’re happy with that, so please keep it as is.

teslamate/lib/teslamate/database_check.ex

Lines 11 to 17 in 4e11474

	# When changing these requirements, also update the eval-time assertion in
	# nix/module.nix (services.teslamate.postgres.package), which mirrors them.
	@version_requirements %{
	1600 => %{min_version: "16.7", min_version_num: 160_007},
	1700 => %{min_version: "17.3", min_version_num: 170_003},
	1800 => %{min_version: "18.0", min_version_num: 180_000}
	}