Open firefixmaarten opened 1 month ago
My initial reaction was to say that the add-on doesn't know the status of any of the entities because the Tesla library that is used by this project doesn't provde a means of reading status. Therefore the command entities use 'Optimistic Mode' which assume the initial state, and just toggle whenever there is user input. (see https://www.home-assistant.io/integrations/cover.mqtt/ for more details regarding the MQTT Cover entity which is used for the charge port door command).
You can get status using the https://github.com/alandtse/tesla custom integration.
However you have got me thinking. Maybe we could parse the error codes like the one you refer to, which would actually infer the status.
I have to think if such functionality would be useful or not. Possible issues are: the status is only known after a command is sent; not all commands provide such error codes which can infer status; something else can change the status which the add-on would not be aware of
What do you think? Would you rather use https://github.com/alandtse/tesla to get the status, or have this add-on provide it in a limited way with the shortcomings I describe?
My current preference is to not implement, but await future updates by Tesla which might (or might not) add the ability to read state
@raphmur @baylanger do you have any comments?
@iainbullock , yes I thought about this as well.
What we are doing now is parsing the logs to :
Feel free
I actually have a working Tesla Fleet API integration that provides me with updates every 11 minutes. More would hit thé rate limit.
So I currently use that for reading data. But it would be Nice to not depend on a cloud or internet solution.
I do understand that you Will need to send a command first to interfere thé status.
I would suggest not to focus on reading the status regulary and hope it Will get added in thé ble stack by Tesla.
I do would like a check before changing thé switch (or revert it):
This to avoid putting the switch to charge, thinking it charges while it did nothing due to some error. I could wait 11 minutes to verify it did not start, but these kind of checks we could do I think.
I might look into a PR if I find the time, currently busy with other work 😕.
It is something we could look at I agree, but I've also not got much time at the moment!
To get round the 11 min delay in my integrations, I call the button.press service for the button.xxxx_force_data_update entity in Tesla Custom Component.
Hello @firefixmaarten , I use Tesla Custom Integration to read the state. But as for you it updates every 10 mins. With the BLE protocol, we can only receive information if we send a command.
So sending a start-charge command will fail if the cable is not plugged in (and the log will tell you this) --> This will work We could also use the close-charge-port command maybe, which could fail and tell you the output "already closed" or "cable plugged in" --> @iainbullock I will try just to know, but it is still a hack
@firefixmaarten what is the issue with trial and error on the start-charge command? We we can work on for sure is:
Hello, I have been testing several different scenarios and I see that as soon as the car is awake to receive a command it is updating values on teslamate... would it be possible to use mqtt discovery to define state topics based on teslamate mqtt messages? The main limitaiton is that it is going to work only for people having teslamate installed (maybe we need to provide a mapping tesla_ble VIN <-> teslamate car_id, for those having several cars) As far as I understand, this approach will reflect the real status no matter how it got changed
I'm not particularly knowledgable about Teslamate. If the various car sensor status is in MQTT, then it should be possible to read and use state values as you suggest.
I'm not sure it's something we are likely to be working on, but if you or others manage to make it work please let us know and share what you do.
Thanks
Hello, Well I have just created a file tesla_proxy.yaml that creates a device with a few entities where I use teslamate to get states and tesla_ble to send commands, it works well on my side (I deal only with a few entities: Charger, plugged, location, battery level). Please find my yaml in this gist To try it you need to:
I would be nice if we can include this "hybrid" definition on tesla_ble MQTT discovery Best Regards
Excellent work and thanks for posting your yaml. I'm sure we could make this work in the Add-on and Docker versions of our project as you suggest. I will look into Teslamate so I understand it better.
It might take us a while though as we are all busy on other things. @raphmur @baylanger what do you think?
Thanks!
@gonzalodrobles looks nice! You've reached what I wanted, but without the time for it! --> A handy "device" that you can create which seamlessly integrates the best of all modules...
Do you want to integrate this in the overall project? Have you had a look also at the Tesla Custom Integration to integrate similarly? I don't know how device .yaml work... Can you also implement some logic?
I would like to figure out if there is a charge cable connected so that I don't try to start charging when not connected.
If I try to close the lid it says impossible to close in the logs but then just put the charge flap state into closed, some error checking might be good here ;)