Add missing Home Assistant discovery entities for published MQTT topics

[vincep5]

Is there an existing issue for this?

• I have checked the existing issues and discussions, and I can confirm that there are no duplicates.

What happened?

In Home Assistant while using the auto discovery (MQTT Discovery (automatic configuration)) via the docs, I notice several sensors are not created. MQTT has the entries, but the sensors are not in the config

teslamate/cars/1/tpms_soft_warning_fl
teslamate/cars/1/tpms_soft_warning_fr
teslamate/cars/1/tpms_soft_warning_rl
teslamate/cars/1/tpms_soft_warning_rr

teslamate/cars/1/charge_current_request
teslamate/cars/1/charge_current_request_max

These were the ones I had noticed as missing

Also to note, the TPMS look to have some duplicated sensors
I see
homeassistant/sensor/teslamate_1/tpms_pressure_fl
and
homeassistant/sensor/teslamate_1/tpms_pressure_fl_psi

In Home Assistant, you are able to set the Unit of Measurement in the Entity settings. So those that want to see it as bar or psi can make it whichever way they prefer.

Expected Behavior

HA MQTT auto discovery, should create the entities per the expected topics and values from MQTT

Can the issue reliably be reproduced?

Yes

Steps To Reproduce the issue

1. Setup the Teslamate env with notes from https://docs.teslamate.org/docs/integrations/home_assistant/#mqtt-discovery-automatic-configuration
   MQTT_HOME_ASSISTANT_DISCOVERY=true
2. In Home Assistant add the MQTT as an integration or reload the integration from the page
3. View the entities created for the vehicle

Relevant log output

none

Screenshots

Additional data

No response

Type of installation

Docker (https://docs.teslamate.org/docs/installation/docker/)

Version

v4.1.1

PostgreSQL version

No response

Are you running latest major supported PostgreSQL version?

• I run the latest major supported PostgreSQL version

Are you using a reverse Proxy for TeslaMate?

No

Details about your reverse Proxy if applicable

No response

[vincep5]

The soft warning ones should be a binary sensor since they report true/false

[JakobLichterfeld]

Thanks for reporting. We will double check. We ensured all from here is covered https://docs.teslamate.org/docs/integrations/mqtt So need to look into this, but first guess is, that the duplicates are caused by your manual sensor config.

[JakobLichterfeld]

Thanks again for the detailed report — confirmed, and good catch!

I cross-checked all topics we publish against the discovery entity list in lib/teslamate/mqtt/pubsub/home_assistant.ex. The ones you noticed are real gaps, and there are a few more. Missing discovery entities:

• tpms_soft_warning_fl / _fr / _rl / _rr
• charge_current_request, charge_current_request_max
• climate_keeper_mode
• center_display_state
• service_mode
• sun_roof_state, sun_roof_installed, sun_roof_percent_open
• download_perc, install_perc

Two things that look missing but are intentional:

• latitude/longitude are covered by the device_tracker (location) entity rather than individual sensors.
• The individual door/window topics (driver_front_door_open, …) are covered by the aggregate doors_open/windows_open binary sensors. Adding the individual ones as well would be a reasonable enhancement, though.

Regarding the duplicated TPMS sensors: the tpms_pressure_*_psi entities are deliberate duplicates derived from the bar topic via a value_template. You're right that Home Assistant can convert the display unit per entity for device_class: pressure, so they are technically redundant — but removing them now would break existing automations and dashboards that reference them, so they'll stay for the time being.

We'll treat this issue as: add discovery configs for the missing sensors listed above.

---

🤖 Reply drafted with Claude Code (Fable 5 high) — sponsored by Claude for Open Source

[nebhale]

I'm on it.

[nebhale]

@vincep5 just to set expectations, there are a handful of MQTT topics that I plan to outright ignore (@JakobLichterfeld described the reasoning accurately). Additionally, there are a few topics that overlap with one another (e.g. lat and long) and a few topics that are now used to populate the Device metadata. For all of those, I'll be putting in the sensors for them, but they'll be disabled by default. Users and easily enable them if they need the raw data for a specific purpose.

[vincep5]

Sounds great. Thanks for looking into it.