Add door open/close state

[tagcashdev]

add :
Driver Front state
Driver Rear state
Passenger Front state
Passenger Rear state

PS : I don't know if my modifications are sufficient to be able to retrieve the status via MQTT ex. "teslamate/cars/1/passenger_front_state but that's the goal

[brianmay]

I believe what you have here should be sufficient for MQTT. But not tested. :-)

Also see my #3087 where I added a field to MQTT, and tested it.

[brianmay]

If I am reading this correctly, this would publish the value as true or false.

But I think it might be better to publish it as "open" or "closed" instead.

[tagcashdev]

I must admit that I do not know the language at all. but currently on MQTT there is a doors_open state which sends true or false if at least one of the 4 doors is open which is cool ! But i am developing a lovelace custom card for HA and i would like to retrieve the state for each door individually.
in order to be able to visually display which door is open, PS this can also make it possible to create more precise notifications such as the left rear door is open instead of simply a door is left open.

I would be grateful to see these 4 states in teslamate natively I'm not sure I have the skills in this language to do it correctly

[brianmay]

Yes, it has been a annoyance for me too.

But maybe not so annoying that I have created a PR to fix it. :-)

On another note, I have a growing dislike the approach taken by teslamate of publishing each and every piece of data as a seperate mqtt topic. I guess it makes things simpler for systems like node-red, and maybe home assistant. But I tend to prefer if it json encoded data, and send it related data in groups. This means I don't have to listen to so many topics.

For a good example of what I mean here, have a look at the way latitude and longitude are sent as two different topics. It doesn't make a lot of sense, because anything that will want to consume one value will also want to consume the other value. It could get confusing if you accidentally use the old latitude with the new longitude or vice versa.

Another good example here would be to combine the door open/window/frunk/trunk open into one json encoded topic. Because typically it is unlikely you would only want one.

This is something else I haven't got around to creating a PR for :-( and could be a different solution to this PR and my PR.

But reluctant to much development with teslamate right now until I get some feedback on my PR.

[ramonsmits]

On another note, I have a growing dislike the approach taken by teslamate of publishing each and every piece of data as a seperate mqtt topic.

That is just the most used MQTT convention. Have topics with simple values.

I do agree having just a publish of the actual raw JSON response as-is can be very useful!

[tagcashdev]

I think my modification will not be integrated into the original branch ?
I would like to be able to test with my installation... but I don't know how to install my modifications on my docker... can someone help me ?

[brianmay]

That really depends on how you deploy. Personally what I do is:

docker build -t brianmay/teslamate:test.019 .
docker push brianmay/teslamate:test.019

And then I tell my deploy to use brianmay/teslamate:test.019 instead of the official docker image. Obviously you will have to change the docker account to your own.

[KrzysztofHajdamowicz]

May I have a suggestion?

Your PR publishes topics like {driver,passenger}_{front,rear)_door_state while HA Tesla custom integration pulls {d,p}{f,r) attributes.
Having them named the same makes it easier to use Teslamate MQTT streaming API between polling API by HA.
This relates to alandtse/tesla#707