Publish location updates in a single MQTT message

[Kevga]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Each time the car's location updates, longitude and latitude are published as individual messages, which means every consumer of this data needs to implement synchronization logic to not mix old longitudes with new latitudes and vice versa.

Expected Behavior

I would like to see the location published in a single message. Splitting lat/lon with a comma or a space would be easier to deal with.

Steps To Reproduce

No response

Relevant log output

No logs.

Screenshots

No response

Additional data

No response

Type of installation

Docker

Version

1.22.0

[ramonsmits]

It clearly is a feature request to have an additional topic that combines teslamate/cars/$car_id/latitude and teslamate/cars/$car_id/longitude in a single value.

Suggested topic teslamate/cars/$car_id/latlon

For example: teslamate/cars/$car_id/latlon which would contain the data 35.278131,29.744801 (based on MQTT topic docs.

Why a single topic is required

It really makes sense as these 2 values represent a single data element. You would not split date or time in to topics representing year, month, day, hour, minute, second.

I understand the history as the current topics map 1 to 1 to the json properties.

The current topics are fine for my action script that checks if the car is in a certain (dynamic) area (position of my phone).

However, its different for my secondary tracker. Due to the topics each time the car position is updated it results in 2 stored records. As there is no timestamp component these cannot really be deduplicated.

This results in 200% more data of which 50% of the data is actually incorrect. Not a big deal when the car is parked but when driving on the highway this results in really strange "stairs" in the data.

[brianmay]

I 100% agree. This has been bugging me for a while too.

Please create a pull request to do this :-)

IIRC this would need adding a new field to the summary struct: https://github.com/teslamate-org/teslamate/blob/master/lib/teslamate/vehicles/vehicle/summary.ex#L8

And then generate the field here:
https://github.com/teslamate-org/teslamate/blob/master/lib/teslamate/vehicles/vehicle/summary.ex#L72
(make sure you deal appropriately with nil values)

I believe all fields in the summary struct then automatically get sent using mqtt. Although take note we don't publish nil values unless they are in the @always_publish list (this is probably the correct behaviour here). https://github.com/teslamate-org/teslamate/blob/master/lib/teslamate/mqtt/pubsub/vehicle_subscriber.ex#L50

Also ideally need to update website/docs/integrations/home_assistant.md to use the new field (if this is possible),

[brianmay]

Note: making changes to the summary might effect tests. Although I think this change should be OK.

The tests are dodgy, see the kludge I made in #3471 to get this working.

[brianmay]

Question: What is the best output encoding? comma separated values? Or maybe json? Or something else?

Don't particularly care, whatever is easiest to parse I guess. Less likely to confuse latitude/longitude with json, but the size of the data increases also.

[ramonsmits]

I was already looking at the code base but I could not really see how those json values are published via mqtt. So good hints!

I think in this case just a comma separated value makes the most sense.

It's more like the serialization of a type than a structure or class. Would be different when it would contain more info like speed, elevator, bearing. Not even sure if alle those are exposed by the Tesla API but that would be a fully different topic like /position which could have a json value with all that data.