tesla-local-control / tesla_ble_mqtt_docker

Apache License 2.0
29 stars 8 forks source link

Control 2 (or more) cars #1

Closed andreaconfa closed 4 months ago

andreaconfa commented 5 months ago

Hi, This is awesome. Unfortunately I already see an issue for my use-case.

I have two car (and this mean two different vins). Maybe you can make the VIN number as a setting in home assistant instead of passing it directly to the docker container….

I don’t need to send commands to the car simultaneously, but I need to switch between them depending of which one is charging (I will manage this via home assistant)

Do you think is possible ?

andreaconfa commented 5 months ago

I can try to contribute to this but I’m not sure what is the best way to do it.

Using the vin as parameter in home assistant (sent via Mqtt) means that people with only one car need to also use it when not needed.

Maybe a combination of fixed vin in docker (as a default one) and mqtt paremeter to override the default vin can be the way to do it.

iainbullock commented 5 months ago

I did start off with this in mind, but because I wanted to release it today (I'm going on holiday) I went for the simpler 1 car option. This is what I suggest.

In discovery.sh change the topics to include the VIN, so for example:

mosquitto_pub -h $MQTT_IP -p $MQTT_PORT -u $MQTT_USER -P $MQTT_PWD -t homeassistant/button/tesla_ble/trunk-open/config -m \
 '{
  "command_topic": "tesla_ble/command",
  "device": {
   "identifiers": [
   "tesla_ble_mqtt"
   ],
   "manufacturer": "iainbullock",
   "model": "tesla_ble_mqtt",
   "name": "Tesla_BLE_MQTT"
  },
  "name": "Open Trunk",
  "payload_press": "trunk-open",
  "unique_id": "tesla_ble_trunk-open"
 }' 

Would become:

mosquitto_pub -h $MQTT_IP -p $MQTT_PORT -u $MQTT_USER -P $MQTT_PWD -t homeassistant/button/tesla_ble/${VIN}/trunk-open/config -m \
 '{
  "command_topic": "tesla_ble/${VIN}/command",
  "device": {
   "identifiers": [
   "tesla_ble_mqtt"
   ],
   "manufacturer": "iainbullock",
   "model": "tesla_ble_mqtt",
   "name": "Tesla_BLE_MQTT"
  },
  "name": "Open Trunk",
  "payload_press": "trunk-open",
  "unique_id": "tesla_ble_${VIN}_trunk-open"
 }' 

You could have a list of VINs in the environment from docker-compose.yml and iterate through the above with them (use something different than $TESLA_VIN as this is used by the Tesla Go library). This would create separate topics and entities in HA for each VIN

In run.sh, there is a loop which listens for changes to the topics. You could extract the VIN from the topic and set $TESLA_VIN before calling send_command()

You would also need to do something in run.sh to iterate the generation and deployment of the keys for each VIN

A simpler but less scaleable method would be as above but just make it work say for 2 cars.

If you want to have a go please submit any PR against the dev branch, as I'm unable to test whilst I'm away and would merge into main when its tested on my return

MrBLJ commented 5 months ago

I did start off with this in mind, but because I wanted to release it today (I'm going on holiday) I went for the simpler 1 car option. This is what I suggest.

In discovery.sh change the topics to include the VIN, so for example:

mosquitto_pub -h $MQTT_IP -p $MQTT_PORT -u $MQTT_USER -P $MQTT_PWD -t homeassistant/button/tesla_ble/trunk-open/config -m \
 '{
  "command_topic": "tesla_ble/command",
  "device": {
   "identifiers": [
   "tesla_ble_mqtt"
   ],
   "manufacturer": "iainbullock",
   "model": "tesla_ble_mqtt",
   "name": "Tesla_BLE_MQTT"
  },
  "name": "Open Trunk",
  "payload_press": "trunk-open",
  "unique_id": "tesla_ble_trunk-open"
 }' 

Would become:

mosquitto_pub -h $MQTT_IP -p $MQTT_PORT -u $MQTT_USER -P $MQTT_PWD -t homeassistant/button/tesla_ble/${VIN}/trunk-open/config -m \
 '{
  "command_topic": "tesla_ble/${VIN}/command",
  "device": {
   "identifiers": [
   "tesla_ble_mqtt"
   ],
   "manufacturer": "iainbullock",
   "model": "tesla_ble_mqtt",
   "name": "Tesla_BLE_MQTT"
  },
  "name": "Open Trunk",
  "payload_press": "trunk-open",
  "unique_id": "tesla_ble_${VIN}_trunk-open"
 }' 

You could have a list of VINs in the environment from docker-compose.yml and iterate through the above with them (use something different than $TESLA_VIN as this is used by the Tesla Go library). This would create separate topics and entities in HA for each VIN

In run.sh, there is a loop which listens for changes to the topics. You could extract the VIN from the topic and set $TESLA_VIN before calling send_command()

You would also need to do something in run.sh to iterate the generation and deployment of the keys for each VIN

A simpler but less scaleable method would be as above but just make it work say for 2 cars.

If you want to have a go please submit any PR against the dev branch, as I'm unable to test whilst I'm away and would merge into main when its tested on my return

I'm in the same case as @andreaconfa. i'll follow your instructions and set this up, hopefully I can submit a PR afterwards.

raphmur commented 5 months ago

I thought about this and I looked through 1 idea: duplicate the docker image for each car (append identifiers where needed)... --> you would need to integrate the vin (or part of it) in the mqtt topic (as above)

iainbullock commented 5 months ago

I think that would work. The subscribe loop in run.sh would have to look at the VIN otherwise both containers would respond to both cars

andreaconfa commented 5 months ago

Any news on this? I'm not able to make it work...

iainbullock commented 4 months ago

It's on the to do list, but as I'm currently on holiday I've not made much progress. Watch this space it should be done during this week

iainbullock commented 4 months ago

Just to keep you posted, I am still working on this and will have a solution soon. I hope you can test it for me!

I am also working with 2 other devs to colloborate on the project, I will report on this soon. Our combined efforts will appear here:

https://github.com/tesla-local-control/tesla-local-control-addon

MrBLJ commented 4 months ago

Just to keep you posted, I am still working on this and will have a solution soon. I hope you can test it for me!

I am also working with 2 other devs to colloborate on the project, I will report on this soon. Our combined efforts will appear here:

https://github.com/tesla-local-control/tesla-local-control-addon

Thanks a lot for your work. I'm very interested in trying your addon, but I require to run bluetooth on my RPI since my HA server can't reach my cars via bluetooth in my garage.

The standalone option seems to be what I need, but I can't figure out how it should be set up. Are there any detailed instructions for it ? if you point me towards the right path, I can create some documentation related to this and the rest of the addon if needed.

raphmur commented 4 months ago

Hi there, we are 3 ppl collaborating and ultimately will push all devs from this repo to https://github.com/tesla-local-control/tesla-local-control-addon

The relevant documentation is in tesla_ble_mqtt/DOCS.md (so that it shows in HA). In the standalone folder you have a .sh script to execute. "Normally" that's all. Just download it, edit the config variables, and run it anywhere you want. You will see your car on HA through the MQTT entities declared.

So far the way we tried to make it work is: all the main code is similar to @iainbullock 's code but has been inclused and made compatible to run it as a standalone docker.

If you don't require the multi VIN feature I suggest you switch to the version in the addon repo.

MrBLJ commented 4 months ago

Hi there, we are 3 ppl collaborating and ultimately will push all devs from this repo to https://github.com/tesla-local-control/tesla-local-control-addon

The relevant documentation is in tesla_ble_mqtt/DOCS.md (so that it shows in HA). In the standalone folder you have a .sh script to execute. "Normally" that's all. Just download it, edit the config variables, and run it anywhere you want. You will see your car on HA through the MQTT entities declared.

So far the way we tried to make it work is: all the main code is similar to @iainbullock 's code but has been inclused and made compatible to run it as a standalone docker.

Thanks for you reply. I had a look at the script you mentioned. if I understand correctly, this is an automated setup of the docker standalone version, which do not require the addon to be installed in home assistant. So for now, it'd work exactly as my current setup (via docker on my RPI).

If you don't require the multi VIN feature I suggest you switch to the version in the addon repo.

I have two cars so I kind of do, but this isn't a major issue. Since you mentioned that all devs would be consolidated into the addon repo, i'll switch to using that one.

raphmur commented 4 months ago

Yes the script is a kind of installer that does all the stuff documented here. You need to have docker installed and an mqtt broker somewhere (it can also be a non home assistant). Please advise if there are bugs. It has been tested but you never know.

Most likely we will integrate the "more than one vin" this week or the next one...

epenet commented 4 months ago

Note 1: the script doesn't work for me. I'm tracking my issues in https://github.com/tesla-local-control/tesla-local-control-addon/issues/38 and will try to create PRs to fix but help would be welcome...

Note 2: I think that before multi-vin is implemented it would be better to work on "uniqueness" of the MQTT payloads. I've highlighted this before, and I think that https://github.com/tesla-local-control/tesla-local-control-addon/issues/19 should be treated with high priority - to avoid a breaking change further down the road.

iainbullock commented 4 months ago

@andreaconfa As you were the first to ask for this, I'd appreciate it if you could test it and provide some feedback here.

Note this project is moving, but we will respond to your feedback. See my closing notice being put on open Issues below. I will keep this Issue open in anticipation of your feedback. Thank you for your support.

The latest and probably final update has been released today in the main branch (v.1.1.2). It provides multi-car support (for commands, but not BLE presence), various bug fixes, and enhancements suggested by users.

The project is being migrated to a new one which has three developers (including me). With three of us working on it, we expect to improve functionality, quality, and responsiveness to issues. Check it out at https://github.com/tesla-local-control/tesla-local-control-addon

I will keep this project open until the first release at the new repository.

If your Issue remains unresolved by this release, please review existing Issues at the new repo, and open a new Issue there if required.

I will close the Issue here as the repo will soon be archived.

Thanks a lot for your input and support on this project.

andreaconfa commented 4 months ago

@andreaconfa As you were the first to ask for this, I'd appreciate it if you could test it and provide some feedback here.

Note this project is moving, but we will respond to your feedback. See my closing notice being put on open Issues below. I will keep this Issue open in anticipation of your feedback. Thank you for your support.

The latest and probably final update has been released today in the main branch (v.1.1.2). It provides multi-car support (for commands, but not BLE presence), various bug fixes, and enhancements suggested by users. The project is being migrated to a new one which has three developers (including me). With three of us working on it, we expect to improve functionality, quality, and responsiveness to issues. Check it out at https://github.com/tesla-local-control/tesla-local-control-addon I will keep this project open until the first release at the new repository. If your Issue remains unresolved by this release, please review existing Issues at the new repo, and open a new Issue there if required. I will close the Issue here as the repo will soon be archived. Thanks a lot for your input and support on this project.

hi. yes i can test it but for now i'm away for 2 weeks from home. I also have to understand why my tesla_http_proxy is not working anymore even for only reading data. I get error 429: TOO_MANY_REQUESTS even without sending commands

iainbullock commented 4 months ago

OK revisit us after your holidays at https://github.com/tesla-local-control/tesla-local-control-addon

Enjoy!

MrBLJ commented 4 months ago

OK revisit us after your holidays at https://github.com/tesla-local-control/tesla-local-control-addon

Enjoy!

I have two cars as well, I’ll set this up this evening.

epenet commented 4 months ago

One issue with the latest => if TESLA_VIN1 is set, but BLE_MAC is empty then it spams the logs. listen_to_ble should probably be deactivated if BLE_MAC is not set at all.

raphmur commented 4 months ago

Thanks for the feedback We are working on a more permissive version that will:

All this is at dev stage for now... We will keep you posted. Contrib is a bit difficult for the moment indeed. In the meantime yes, you need to supply MAC...

MrBLJ commented 4 months ago

Updated to the latest version. For some reason commands are difficult to send on my model Y, which is parked a bit further away. Otherwise it’s fine.

nothing to do with the Addon I think, so I’ll move the RPI closer and will try again during the weekend.

iainbullock commented 4 months ago

Thanks both for your feedback

MrBLJ commented 4 months ago

Updated to the latest version. For some reason commands are difficult to send on my model Y, which is parked a bit further away. Otherwise it’s fine.

nothing to do with the Addon I think, so I’ll move the RPI closer and will try again during the weekend.

I'm not sure what I did in the first place. Is the feature supposed to be functional ? I had a look at the logs since my model Y was behaving strangely, this is what I get :

Needs updating for multi-car, only supports TESLA_VIN1 at this time

This is super weird because both cars are present in HA MQTT, and I was pretty sure I had the whole thing working at some point.

edit: commands are working fine, I think it's the presence detector that's messed up.

iainbullock commented 4 months ago

You should be able to send commands to both cars. The message you are getting means presence detection isn't yet working for multiple cars (only VIN1).

Do commands work for both cars as I can't test?

We will support presence for multiple cars very soon

Thanks

iainbullock commented 4 months ago

Ah you said commands are working for both. Wait for the presence detection for both to be supported. It won't be long

MrBLJ commented 4 months ago

Ah you said commands are working for both. Wait for the presence detection for both to be supported. It won't be long

Thanks for your answer. I figured out what's wrong and this is on my end. I need mqtt commands to trigger charge using evcc, so I used mqtt explorer to sniff the commands sent via MQTT when I pushed the button provided by the service in HA. For example, when I press Start charging I see :

topic : tesla_ble_mqtt/myvin/command payload: charging-start

So I tried replicating that in MQTT :

service: mqtt.publish
data:
  payload: charging-start
  topic: tesla_ble_mqtt/myvin/command

Nothing is catched in the logs of the ble container. So I must have missed something. I'll keep digging.

iainbullock commented 4 months ago

You will need to set QOS=1 if this is to work!

MrBLJ commented 4 months ago

That's it !

iainbullock commented 4 months ago

New version released today. Note the config environment and HA entity names are different, which may cause breaking changes. Read CHANGELOG.md. Let me know how it goes. I will close this Issue, please reopen a new Issue if the original issue returns with the new release