tesla-local-control / tesla_ble_mqtt_docker

Apache License 2.0
15 stars 5 forks source link

Control 2 (or more) cars #1

Open andreaconfa opened 3 weeks ago

andreaconfa commented 3 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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 1 week ago

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

iainbullock commented 1 week 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 6 days 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 6 days 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 6 days 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 6 days 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 6 days 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 6 days 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 5 days 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 5 days 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 5 days ago

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

Enjoy!

MrBLJ commented 4 days 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 days 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 days 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 days 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 2 days ago

Thanks both for your feedback

MrBLJ commented 11 hours 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 10 hours 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 10 hours ago

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