0.22 vs 0.4x vs Tesla Fleet vs HA 2025.x

[dettofatto]

Hello, thank you for your magnificent work, as you might have noticed, I’m a fan of yours! I’ve attached a screenshot to show you how I’m using your Docker, which I’m currently running on version 0.22. I wanted to ask if these observations can also be applied to the newer versions.
I’m using Tesla Fleet at the same time as your tool, where Tesla Fleet is used for querying data, and your tool is used for sending commands. The Docker runs on a Raspberry Pi 4 located near the cars, and the execution time for a command is about 7 seconds. I have solar panels, and my goal is to regulate the charging process based on the sunlight.

As you can see, I’m charging two Tesla cars. The first one is on a three-phase connection (max 11kW), and the other on a single-phase connection (max 3.5kW). I’ve added numbers (in yellow) on the screenshot for reference:

Line 1 corresponds to the kW reserved for my house (I can choose manually), which is calculated as a ratio of solar production and the value read by an automation that adjusts the amperage for the two cars. In this case, I’m reserving 0.5kW for the house, the solar production is 4.63kW, and the Tesla value (number 7 in yellow) tells the automation to use 7A for (number 2 in yellow: “Tesla Mia Amperage”), which is triggered by the automation at point 8.
The other Tesla (number 4) is not using automation, and I’ve manually set it to 3A.
If the Tesla value (number 7) increases or decreases, depending on numbers 9 and 1, the amperage (number 2) also increases or decreases.
Furthermore, if I disable 8 and 5, I can manually adjust the amperage on line 2.

After this long introduction, I’ve noticed that with the newer versions, there seems to be command congestion. Often, when both Teslas are no longer at home, I need to restart the Docker, which doesn’t happen with version 0.22.

Additionally, I’ve noticed that with version 0.22, the value at point 6 in yellow on the screenshot isn’t static but instead updates dynamically. Let me explain better:
When I send the command through your Docker (e.g., 7A), the amperage slider in version 0.22 adjusts to 7. However, in version 0.4x, it needs to be updated manually.

On cloudy days, in addition to creating a constant back-and-forth of commands from the automation (which always needs to know the current charging amperage), this results in the "not-at-home" issue. With Tesla Fleet, I don’t experience this problem, and I could continue using TF along with version 0.22, but I’ve noticed that when upgrading to the new version of HA (2025.x), Tesla Fleet becomes almost unusable.

And so, here’s my final question:
Is it possible to somehow integrate or limit Tesla Fleet (which will likely be discontinued soon) and modify your project to follow a similar approach? I’m also attaching my automation.

Thank you for your support and continuous work.

Automation (3), I've another automation for 4

alias: Ricarica Tesla Mia
description: Aumenta gli ampere di ricarica di Tesla Mia in base alla produzione di energia
triggers:
  - trigger: time_pattern
    seconds: /15
    enabled: true
  - entity_id: sensor.tesla_kw_sottratti_da_casa
    trigger: state
    enabled: true
conditions:
  - condition: device
    device_id: 930976fa5e779b9b4646ef6e4c82da50
    domain: lock
    entity_id: 01e8c773262645fc62a3a483651c08d6
    type: is_locked
  - condition: state
    entity_id: sensor.tesla_mia_charging
    state: charging
actions:
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: -10000
            below: 0.6
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: sensor.tesla_mia_charger_current
                below: 2.1
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 0
          - delay:
              hours: 0
              minutes: 0
              seconds: 10
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 0.6
            below: 1.32
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 2.1
                above: 1.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 2
          - delay:
              hours: 0
              minutes: 0
              seconds: 10
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 1.32
            below: 1.99
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: sensor.tesla_mia_charger_current
                below: 3.1
                above: 2.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 3
          - delay:
              hours: 0
              minutes: 0
              seconds: 10
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 1.99
            below: 2.64
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 4.1
                above: 3.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 4
          - delay:
              hours: 0
              minutes: 0
              seconds: 10
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 2.64
            below: 3.3
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 5.1
                above: 4.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 5
          - delay:
              hours: 0
              minutes: 0
              seconds: 10
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 3.3
            below: 3.96
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 6.1
                above: 5.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 6
          - delay:
              hours: 0
              minutes: 0
              seconds: 10
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 3.96
            below: 4.6
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 7.1
                above: 6.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 7
          - delay:
              hours: 0
              minutes: 0
              seconds: 8
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 4.5
            below: 5.28
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 8.1
                above: 7.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 8
          - delay:
              hours: 0
              minutes: 0
              seconds: 8
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 5.28
            below: 5.94
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 9.1
                above: 8.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 9
          - delay:
              hours: 0
              minutes: 0
              seconds: 8
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 5.94
            below: 6.6
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 10.1
                above: 9.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 10
          - delay:
              hours: 0
              minutes: 0
              seconds: 8
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 6.6
            below: 7
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 13.1
                above: 12.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 13
          - delay:
              hours: 0
              minutes: 0
              seconds: 8
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 7
            below: 7.2
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 15.1
                above: 14.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 15
          - delay:
              hours: 0
              minutes: 0
              seconds: 8
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
      - conditions:
          - condition: numeric_state
            entity_id: sensor.tesla_kw_sottratti_da_casa
            above: 7.2
            below: 12
          - condition: not
            conditions:
              - condition: numeric_state
                entity_id: number.tesla_mia_charge_current
                below: 16.1
                above: 15.9
        sequence:
          - device_id: fd6deb800e11e84cd1f19c4ad77860ba
            domain: number
            entity_id: 59cc05d8fa2aedf960c9c67fb0f2c041
            type: set_value
            value: 16
          - delay:
              hours: 0
              minutes: 0
              seconds: 8
              milliseconds: 0
          - data:
              entity_id:
                - number.tesla_mia_charge_current
            action: homeassistant.update_entity
  - delay:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
mode: single

[iainbullock]

It is a very interesting setup you have. I think many people are using this for controlling their solar / car charging. In my setup I also have a home battery, which is useful as it means I don't have to keep changing the car's charging current very often. I attempt to keep the home battery at approx 80%. Once the home battery is close to 80% it sets the car charging current to be the same as the solar production less whatever the house is using. It doesn't have to be very accurate nor update very often as the home battery will either charge a little more, or discharge a little. I don't mind as long as everything I generate ends up in the home battery or the car.

I haven't been through all your automation code, but I can comment on some of your questions / comments as follows:

• I too have found that V0.4.x will stop working if the car is away. See this Issue where I have described how I investigated and hopefully fixed this body-controller-state: Error: failed to find a BLE device: .... tesla_ble_mqtt_core#142. In your case with 2 cars you might need to set PS_LOOP_DELAY to be even more than 60 as you have twice as much scanning to do
• The sliders 'dynamically updating' in v0.2.x is an 'illusion'. This is because in v0.2x we couldn't read state, so it used MQTT optimistic mode (see https://www.home-assistant.io/integrations/number.mqtt ). This means whenyou make a change to an entity in HA, there is no feedback as to whether the change actually occurred, HA simply assumes it has and changes the control immediately. In 0.4.x we can read state, and HA gets feedback from the state topic. It can be very slow however, as it has to wait for the next poll to take place, or a manual forced update. You can still read the value from Tesla Fleet (or the HA built in Tesla Integration) if you wish, it will probably give better performance
• If you send many (or maybe even just a few) commands whilst the car (or cars not sure) is away, you will cause the bluetooth device to lock up which I believe is the cause of the 'not-at-home' issue you (and others) report. Your automations should not send commands to a car which is not present. I am currently experimenting with a better way of detecting presence using the 'body-controller-state'. When I'm happy with it, I will also use it to prevent command being sent when the car is not present, which I hope will improve robustness

I'm not sure I've answered everthing but hopefully it helps in some way

[dettofatto]

Thank you for your suggestions!
Only for updating you, in my case I've seen that my status is reported as away, but my cars are in my home. This issue doesn't happen with 0.22.
And for the The sliders illusion, yes I know! But I must improve my observation, because I can't explain very well the situation. When I revert to 0.4x I'll improve my observation.
Thank you!

[iainbullock]

I have implemented various changes in v0.4.3b-dev which is on DockerHub. Main changes are robustness improvements, see the CHANGELOG. I hope this will fix the bluetooth lock up issues see tesla-local-control/tesla_ble_mqtt_core#142

[dettofatto]

Thank you again! Your work is truly awesome.
I've read all your posts for the new dev and noticed that you've resolved all the issues I previously encountered (e.g., Bluetooth hardware hc switch, presence detection, and too many commands sent to two cars).
I'm excited to test the new dev version in the coming days! I'm also thrilled by your observations in other posts-they've made me realize I'm not so crazy after all.. :-)
May be I'll try your dev with the internal bt of my nuc, then I'll test all my other bt, only for knowing (I'm too honest, and I've all my BT adapter that I've buy on Amazon).
Thank you again.
In my case I would use two different hw and Bluetooth for each car. I'll try it.

[iainbullock]

It's still dev release so it might still need more work, but I think it's getting there.

I haven't tested the feature to set the hci number - if you are able to test this would be great. Set $BLE_HCI_NUM to whatever your setup needs. e.g for most people on hci0 they would set this to 0, etc

'In my case I would use two different hw and Bluetooth for each car. I'll try it.' You should get better performance I think

[dettofatto]

It's still dev release so it might still need more work, but I think it's getting there.

I haven't tested the feature to set the hci number - if you are able to test this would be great. Set $BLE_HCI_NUM to whatever your setup needs. e.g for most people on hci0 they would set this to 0, etc

'In my case I would use two different hw and Bluetooth for each car. I'll try it.' You should get better performance I think

No... With integrated bt of my NUC is the same. Presence is ok.

Listening to MQTT
vin:5xxxble_ln:Sd7c0bC match:(4a6bbC|:1:8C:0B) presence detected
vin:5YJ presence has expired, set presence ON
Received MQTT message; topic:tesla_ble/5YJ3/config msg:read-state-charge vin:5YJ7cmd:config
read-state; calling readState()
sendBLECommand: Attempt 1/5 sending Send state command with category=charge to vin:5YJcommand:state charge
Car is not responding to bluetooth, it's probably away VIN:5Y
sendBLECommand; Retrying....
sendBLECommand: Attempt 2/5 sending Send state command with category=charge to vin:5YJcommand:state charge
Car is not responding to bluetooth, it's probably away VIN:5YJ3E
sendBLECommand; Retrying....
sendBLECommand: Attempt 3/5 sending Send state command with category=charge to vin:5YJ3Ecommand:state charge
Car is not responding to bluetooth, it's probably away VIN:5Y
sendBLECommand; Retrying....
sendBLECommand: Attempt 4/5 sending Send state command with category=charge to vin:5YJcommand:state charge
Car is not responding to bluetooth, it's probably away VIN:5YJ3
sendBLECommand; Retrying....
sendBLECommand: Attempt 5/5 sending Send state command with category=charge to vin:5YJ command:state charge
Car is not responding to bluetooth, it's probably away VIN:5YJ
sendBLECommand; Retrying....
sendBLECommand; max retries unsuccessfully trying to send command state charge to 5YJ
Received MQTT message; topic:tesla_ble/5Y/command msg:wake vin:5YJcmd:command

MQTT_PASSWORD=xxxx
# Default 5 (seconds)
#
BLE_CMD_RETRY_DELAY=3
# Default 120 (seconds)
#
PRESENCE_DETECTION_LOOP_DELAY=120
# Default 240 (seconds)
#
PRESENCE_DETECTION_TTL=240
# Your timezone
# Ref: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
#
TZ='Europe/Rome'
### Default false
#
TEMPERATURE_UNIT_FAHRENHEIT=false
### Default 48
#
MAX_CURRENT=16
### Default false
#
DEBUG=false
#
# WARNING; If you run Home Assistant, keep this true unless you know what you're doing
#
ENABLE_HA_FEATURES=true
NO_POLL_SECTIONS='climate tire-pressure closures drive'
BLE_HCI_NUM=0

[iainbullock]

Is this your stack.env I assume so?

In which case the last line BLE_HCI_NUM=0 set to whatever your hci number is

Or you can put it in docker-compose.yml wherever you prefer to set your Docker environment variables

[dettofatto]

I've put it in docker-compose.yml
I've edited mine previous comment.
Also I've seen that the command from NUC with HA and your docker (0.43 for tesla 5y), have some issues, because also send command to other your (0.22 for tesla LR) docker on PI4

[iainbullock]

I'm travelling today so can't really look at it. For the NUC what did you set BLE_HCI_NUM to? Not sure how you tell what the hci number is but it might be worth looking at this in case it's something other than 0

[dettofatto]

Yes. In my case was 0 and I've set 0. Il try with another adapter.
About my slider illusion in this post, you can understand better, my opinion

#82 (comment)

[iainbullock]

I'll comment on #82 on that thread. Let me know how you get on with the hci number here! Thanks

[dettofatto]

About using 2 different docker with 2 different hardware for send/recive commands for each tesla (pi4 to tesla_mia and nuc with its bt for tesla_c), I've seen that there is some issues with mqtt (mqtt server can't understand the right origin, so send command to all), I've added this line MQTT_TOPIC_PREFIX=tesla_c in stack.env

So, I have:

MQTT_USERNAME=xxx
MQTT_OUT=mqtt://192.168.1.x:1883
MQTT_TOPIC_PREFIX=tesla_c

But It is the same.
Any suggestion?
Then I can try the right HCI :-)

[iainbullock]

It probably won't work if you have both hardware connected to both cars. Is that what you intended?

It should work without any issues if you have the pi4 just set up for car 1 and the nuc just setup for car 2. Can you get this to work?

If you must have both devices connected to both cars I will have to give it some thought if possible and if so how to do it.

[dettofatto]

One hw, for each tesla!
Yes I'm not so brilliant, but not so bad!
So pi 4 is for the black Tesla and the nuc is only for the red Tesla.
In my env I've put only the right vin (pi4, black Tesla 's vin and on the nuc the other).
On the nuc there is also home assistant.
But command ed info are shared!

[iainbullock]

OK that should be possible. I will take a look at it and get back to you. Note I have limited time this week so it might be next weekend when I respond

[iainbullock]

Haha you are correct, I have setup a second device and can replicate the problem. I will work on a fix

[iainbullock]

Please can you send me your version of these logs for each device:

2025-02-02T09:21:28.481039033Z Core version is 0.4.3e-dev
2025-02-02T09:21:28.481157040Z Configuration Options are:
2025-02-02T09:21:28.481163753Z   TC_CMD_TIMEOUT=5
2025-02-02T09:21:28.481165994Z   TC_CON_TIMEOUT=5
2025-02-02T09:21:28.481167937Z   TC_KILL_TIMEOUT=25
2025-02-02T09:21:28.481170302Z   PS_LOOP_DELAY=30
2025-02-02T09:21:28.481172186Z   DEBUG=false
2025-02-02T09:21:28.481174132Z   MQTT_SERVER=192.168.x.y
2025-02-02T09:21:28.481176054Z   MQTT_PORT=1883
2025-02-02T09:21:28.481177886Z   MQTT_PASSWORD=Not Shown
2025-02-02T09:21:28.481179740Z   MQTT_USERNAME=xxxxxxx
2025-02-02T09:21:28.481181611Z   PRESENCE_DETECTION_LOOP_DELAY=120
2025-02-02T09:21:28.481183534Z   PRESENCE_DETECTION_TTL=240
2025-02-02T09:21:28.481185423Z   VIN_LIST=LRW3XXXXXxxxxxx
2025-02-02T09:21:28.481187286Z   MAX_CURRENT=32
2025-02-02T09:21:28.481189129Z   NO_POLL_SECTIONS=
2025-02-02T09:21:28.481190975Z   BLE_HCI_NUM=0
2025-02-02T09:21:28.481192838Z   IMMEDIATE_UPDATE=true
2025-02-02T09:21:28.481194820Z   ENABLE_HA_FEATURES=true

[dettofatto]

I'm trying to add to app/mqtt.sh this line:
eval $MOSQUITTO_PUB_BASE -t "${MQTT_TOPIC_PREFIX}${args}" -m "$topic_json"
And also i've put inthe stac.env MQTT_TOPIC_Prefix

NUC:

Core version is 0.4.3e-dev
Configuration Options are:
  TC_CMD_TIMEOUT=5
  TC_CON_TIMEOUT=10
  TC_KILL_TIMEOUT=25
  PS_LOOP_DELAY=30
  DEBUG=false
  MQTT_SERVER=192.168.
  MQTT_PORT=1883
  MQTT_PASSWORD=Not Shown
  MQTT_USERNAME=gl
  PRESENCE_DETECTION_LOOP_DELAY=100
  PRESENCE_DETECTION_TTL=200
  VIN_LIST=5Y
  MAX_CURRENT=16
  NO_POLL_SECTIONS=climate tire-pressure closures drive
  BLE_HCI_NUM=0
  IMMEDIATE_UPDATE=true
  ENABLE_HA_FEATURES=true

pi4

 Setting up MQTT clients with authentication
Core version is 0.4.3e-dev
Configuration Options are:
  TC_CMD_TIMEOUT=5
  TC_CON_TIMEOUT=10
  TC_KILL_TIMEOUT=25
  PS_LOOP_DELAY=30
  DEBUG=false
  MQTT_SERVER=192.168.
  MQTT_PORT=1883
  MQTT_PASSWORD=Not Shown
  MQTT_USERNAME=gl
  PRESENCE_DETECTION_LOOP_DELAY=100
  PRESENCE_DETECTION_TTL=200
  VIN_LIST=LRW
  MAX_CURRENT=16
  NO_POLL_SECTIONS=climate tire-pressure closures drive
  BLE_HCI_NUM=0
  IMMEDIATE_UPDATE=true
  ENABLE_HA_FEATURES=true

[iainbullock]

The topic prefix already contains the car VIN. The bug is that the code doesn't check received MQTT messages that the VIN is in VIN_LIST. I can probably do a quick fix.

Can you send the same logs for your other car?

[dettofatto]

Yes...! I've done... I'me waisting my time for this stupid ``` , because in Italy we don't have it!!
And may be also in the near future Tesla... :-)

[iainbullock]

Ah sorry my fault it came through later whilst I was typing. No idea how you do a on an Italian keyboard! I used to have this in one of my passwords and when using the browser in the Tesla I couldn't find it so I know some keyboards don't have it.

I will test a fix soon and send it to you to try

[iainbullock]

OK I have a patch for mqtt-listen.sh. The following lines should be inserted into the listen_to_mqtt function:

      # Ignore messages for cars not in the vin list
      inVINList=0
      for v in $VIN_LIST; do
        if [ $v == $vin ]; then
          inVINList=1
          break
        fi
      done
      if [ $inVINList -eq 0 ]; then
        log_warning "Received MQTT message for vin: $vin which is not in VIN_LIST"
        continue
      fi

They go here:

      # Don't spam the logs for these topics/ commands
      if [ $cmd == "poll_state" ]; then
        log_debug "Received MQTT message; topic:$topic msg:$msg vin:$vin cmd:$cmd"
      else
        log_info "Received MQTT message; topic:$topic msg:$msg vin:$vin cmd:$cmd"
      fi

      # Ignore messages for cars not in the vin list
      inVINList=0
      for v in $VIN_LIST; do
        if [ $v == $vin ]; then
          inVINList=1
          break
        fi
      done
      if [ $inVINList -eq 0 ]; then
        log_warning "Received MQTT message for vin: $vin which is not in VIN_LIST"
        continue
      fi

      case $cmd in
      config)

Do you know how to modify the code inside a running container? If so please could you make the mod on both machines, restart the contianers, and test?

If not I will make a temporary build when I get chance

[iainbullock]

I'm confident it will work so I'll do a new build in Dockerhub

[dettofatto]

let me try....
Yesss.... Now I can see:
"Received MQTT message for vin: 5YJ3E7which is not in VIN_LIST
vin:LRW3E75 ble_ln:Sa9 match:(Sa92566a44cfa116dC|F4:60:77:97:EB:4B) presence detected
Received MQTT message for vin: 5YJ33 which is not in VIN_LIST
Received MQTT message for vin: 5YJ33 which is not in VIN_LIST"

And The other side:
"vin:5YJ3 presence has expired, set presence ON
Received MQTT message for vin: LRW35 which is not in VIN_LIST"
But I'm testing....

[iainbullock]

OK thanks. I will wait for your testing, and if it works I will do a Dockerhub build

[dettofatto]

Now i have both Tesla outside, and my dockers restart... And I've added one Bluetooth... So I can test only tomorrow..
But for now it's almost good!

[iainbullock]

OK no rush. My daughter has arrived and is staying with me for a few days so I won't have time for much until later in the week. I can do a Dockerhub build if your tests go well

[dettofatto]

My two cents...
IN any case home assistant send the same input to each docker, than the docker choose if the input is appropriate for that vin.
It would better have a specific input for specific docker/vin/hw?
About bt, I've seen that my nuc, with hci set to 1 in .env, has switched to hci 2. So it's possible to link to specific HW (uid)?

[iainbullock]

The dockers 'listen' to MQTT rather than have messages sent to them. In most use cases there is a single device (maybe supporting multiple cars) so the code is written to listen to messages relating to all cars in the VIN list. Had I envisaged your case of multiple devices I could have subscribed to multiple topics (one topic per VIN) in the mosquitto_sub call. I might rewrite this at some point to do this. As I'm short of time at the moment, the easiest fix was to ignore messages for cars not in the vin list. It won't change the performance just be a more logical.

Regarding the BT on your NUC. If the hci is still jumping, I don't think it's going to work. The kernel driver doesn't like whatever tesla-command is doing and is trying to reset the bluetooth device. We can't link to specific UID because this all happens inside Tesla's code (well maybe someone could rewrite it). However I still don't think it will work in your case as the kernel will still object to whatever the code is doing regardless of how we specify the device.

I think your options are:

• Try a different USB BT device plugged into the NUC (preferable BT version >=5.0). You would need to figure out what the hci number is
• Use another RPi
• Have a single RPi for both cars

[dettofatto]

I'll try all the suggestions.
I've used internal BT and external BT (5.3), but the presence go away so often.
So now il try wit rpi2.
And also I would try with esp, it's more simple than raspberry, but I must understand something more about esp32 but proxy.

[iainbullock]

You might find the presence going away on the external BT is fixed after the robustness improvements made in v0.4.3. I can't be sure as it wasn't a problem for me

[dettofatto]

You might find the presence going away on the external BT is fixed after the robustness improvements made in v0.4.3. I can't be sure as it wasn't a problem for me

In my case I think that the nuc hates my Teslas...

[dettofatto]

The bt seems more stronger than previous updates on raspberry Pi2 with bt 5.3, that not hates my Teslas.

But with 2 HW, I have this situation:
Input (in this case read-state charge) is send from 2 (with HA), but it is pushed only to 1 and not to 2 (and we can se that the VIN is not in list). I must push again the input and sometimes is ok.
You can see it on the screenshot in the same time.

[iainbullock]

Looks like I will have to implement vin specific topics on mosquito_sub. I will do it Weds / thurs when my daughter has gone home

[dettofatto]

I'm trying to add some helps, so I've done something like this:
eval $MOSQUITTO_SUB_BASE --nodelay --disable-clean-session --qos 1 --topic tesla_ble/right vin/+ -F \"%t %p\" --id tesla_ble_mqtt |
Maybe it helps.
Thank you again!

[iainbullock]

Yes that's it thanks (at least for a single car per device). Does it fix the problem?

[dettofatto]

Yes that's it thanks (at least for a single car per device). Does it fix the problem?

mmmmhhh not so much... I've "trapped" my mqtt server...

[iainbullock]

Ok I'll have to have a closer look when I have time. Won't be until Thursday at the earliest

[iainbullock]

Ok I think we have a solution.

Because the mosquitto_sub call specifies the client ID, which is the same in both cases, whichever MQTT client reads it first, the MQTT server cleans the message so the other never sees it. That's why it seems to be random which one responds.

The fix for this is to remove --disable-clean-session and --id tesla_ble_mqtt from the _sub call

I think both clients should read all messages in order to clean up properly. Therefore --topic tesla_ble/right vin/+ should be changed back to --topic tesla_ble/+/+

The line with the call should therefore be changed to this:

eval $MOSQUITTO_SUB_BASE --nodelay --qos 1 --topic tesla_ble/+/+ -F \"%t %p\" |

The code to ignore messages for cars not in the vin list is still required

I've tested it locally with two clients (though I only have one car) and it seems to work. Please could you test it? If it works for you I will add it to #iain-dev and build it for Dockerhub

Thanks

[dettofatto]

So the new 0.43g has this feature? Or, in any case I must apply this?
I'll try soon as possible!

[iainbullock]

Yes I just built it for DockerHub. It also has vehicle-command v0.3.3 which claims to improve the bluetooth. Might help your NUC?

From the CHANGELOG for v0.4.3-g-dev:

• Use the latest version of vehicle-command (v0.3.3 at the time of writing), which amongst other things adds 'Refactor BLE connecting to allow scanning for vehicle presence' Refactor BLE connecting to allow scanning for vehicle presence teslamotors/vehicle-command#353, though I'm not sure how this gets used in practice. More importantly it claims to fix 'ble.NewConnection sometimes never returns' ble.NewConnection sometimes never returns teslamotors/vehicle-command#272, which if it works will improve robustness for some users

[dettofatto]

Perfect! I can use 1 pi4 for first Tesla and 1 pi2 with dongle bt for second Tesla!