I took a completely different approach with a Expect scripts - it's an all-in-one app.

Here's a snippet of the available settings. I just added tons of more comments so you understand better. - The MQTT topics have pre/post options but those 2 aren't implemented. I wanted to have a discussion w/ you guys on what makes sense.

After the settings, an explanation of the current script's features.

Settings:

# Single VIN or regex "SabcdefghijklmnopC|SponmlkjihgfedcbaC"
export VIN_REGEX=

# Default first bluetooth controller
export BLE_CONTROLLER=

# After how long the vehicule is considered not present
export PRESENCE_TTL=180

export MQTT_SERVER=mqtt.foo.com

# Default 1883
export MQTT_PORT=
# Default mqttv31
export MQTT_PROTOCOL=

# Default anonymous
export MQTT_USERNAME=
export MQTT_PASSWORD=

# Example: tesla_ble/1/binary_sensor/presence
export MQTT_POST_TOPIC=binary_sensor/presence
export MQTT_PRE_TOPIC=tesla_ble/$CAR or $VIN ???
export MQTT_TOPIC=tesla_ble/binary_sensor/presence

# Obsolete
# CHG status messages tells us if the vehicule is present or not
# The cache might be wrong due to bugs but a CHG message tells us exactly
# what we need.
export REMOVE_CACHE=false

# Probably not needed anymore
export SCAN_TIMEOUT=60

Current features:

• Handles top-down presence detection
• Supports single or multiple VINs via a regex
• Runs non-stop in background
• Spawn bluetoothclt background process and listens to live messages
• Automatically find BLE MAC addr associated to a Local Name
• Spawns background mosquitto_pub process (if it dies, mqtt server restart? - it relaunchs)
• MAC addr array associated with a TTL
• Uses CHG and NEW status messages to refresh MAC addr's TTL
• Publish to MQTT (ON/OFF) only when needed by relying on the MAC addr array
• Able to publish ON or OFF to a MQTT topic

Todo:

• "auto-discovery / stalker" mode - anything that matches a Tesla BLE Local Name S.....C - Your friends&family coming to you place? HA can send you a notif when they arrive or leave.
• add option not to disable presence - I had done this in the bash script and forgot about it for Expect. With the Expect script if ble presence is disable, we just don't launch the script in background. That's all is needed.
• Perhaps allow end user to track anything Bluetooth... disable bluetooth_le_tracker? 🤔
• Possibly move away from env var and user command line args
• Move to command line arguments, instead of environment vars
• MQTT encryption / client certificate options...... proxy?!

Question:

Why is the presence value currently defined as ON & OFF instead of a bool True & False?

With the live listening implementation, I had 0 BLE dongle issues at all and it's something I've been doing very very often .. and even let it run overnight.

... Any suggestions / comments / questions?

I am available tomorrow for Discord or WhatsApp audo or video. Not sure if Discord does video or audio? I think it would be easier to discus over voice/video than chat.

In case someone read the above comment minutes ago, I just updated it.

Implement dedicated function to find MAC from VIN:

• Derive BLE LNAME from VIN using sha1sum. I cannot find origin post about this, though documented here in python
• Find MAC address using bluetoothctl scan. Credit to BogdanDIA

Add option to activate/deactivate proximity sensing.

Rule:

• if proximity sensing is activated and BLE_MAC is defined to a non empty string the listen_to_ble function will be called as in v0.0.8
• if proximity sensing is activated and BLE_MAC is not defined or is empty string the calc_ble_from_vin will be used to find the mac address to enable calls to listen_to_ble. It is tried at container startup and periodically if the MAC cannot be detected.
• if proximity sensing is deactivated, none of the above is done

Regarding the credit for using sha1sum, I also got the idea from https://teslabtapi.lexnastin.com/docs/start#vehicle-ble-name so that seems good unless @BogdanDIA or @baylanger have another reference

Keeping this one as draft until tesla-local-control/tesla_ble_mqtt_core#12 is merged