MQTT values for active_route_* are not clearing

[vincep5]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

The active route MQTT values are not resetting after arriving to destination. I navigated to the store - it showed the values correctly. But then when I drove home without navigation - the values remained from the store.

Expected Behavior

It should clear out your values once you're parked.

Steps To Reproduce

No response

Relevant log output

None

Screenshots

No response

Additional data

No response

Type of installation

Docker

Version

1.28.4

[brianmay]

This no doubt is because we don't publish nil values:

https://github.com/teslamate-org/teslamate/blob/master/lib/teslamate/mqtt/pubsub/vehicle_subscriber.ex#L56-L57

This easy solution would be to add this values to the @always_published.

But am uneasy doing this, because publishing a nil values tells mqtt to drop the value from the retain database. Which is probably undesirable for this data. i.e. when you subscribe you would get an instant message if there is an active route, but if there is no route you would not receive a message to say so until the value changes.

[JakobLichterfeld]

But then when I drove home without navigation

This is expected behavior as no new values got propagated if no new navigation starts.

[vincep5]

@JakobLichterfeld While looking at this from a Home Assistant perspective, I was hoping to use that field active_route_destination to help set off some things at home.. But if that field doesnt get reset to blank or null and the car is not actively navigating anywhere, then the data for it is not useful. The "active" prefix is not accurate then

[JakobLichterfeld]

Active navigation is directly propagated from the Tesla API. changing the original behavior within Teslamate would be bad practice as it would change the meaning and would break interoperability and interchangeably.

[brianmay]

I think there might be a misunderstanding here. The Tesla API (most likely) does the right thing.

The problem is we are getting nil values from Tesla, which we then interpret as "unknown". We then refuse to publish these to mqtt because - why would we want to publish unknown data? But here nil doesn't mean unknown, it means there is no active route.

At least that is my general feeling. Would be good to have some evidence to back this up. If I am right, the quick fix solution is to add all of those attributes to @always_published as I mentioned above.

If I remember, will try to get the dump of the data from Tesla with and without navigation active. (something I have been wanting to do for a while actually).

[brianmay]

The values when the car is not driving and with no route set:

        "drive_state": Object {
            "active_route_latitude": Number(lat2),
            "active_route_longitude": Number(lon2),
            "active_route_traffic_minutes_delay": Number(0.0),
            "gps_as_of": Number(1711399845),
            "heading": Number(200),
            "latitude": Number(lat),
            "longitude": Number(lon),
            "native_latitude": Number(lat),
            "native_location_supported": Number(1),
            "native_longitude": Number(lon),
            "native_type": String("wgs"),
            "power": Number(0),
            "shift_state": Null,
            "speed": Null,
            "timestamp": Number(1711399846493),
        },

I replaced the lat/long values as I don't want to publish the location of my house. But I note that the active route lat/lon is different to the other two values, my guess is that might be the last place we navigated to. Will continue.

[brianmay]

My testing seems to show that the car always provides these attributes, even when not navigating:

• active_route_latitude
• active_route_longitude
• active_route_traffic_minutes_delay

When not navigating, these have values from the last navigation. Wonder if this is a Tesla bug. Doesn't matter though, we have to deal with it. And we have no ability to report this to Tesla either.

This is 2016 Model S upgraded to MCU2.

My suspicion is if I reboot the MCU these values might disappear (not tested).

When navigating, we get additional values. These values only appear when the car is navigating, they don't appear (not even as nil values) when car is not navigating.

• active_route_destination
• active_route_energy_at_arrival
• active_route_miles_to_arrival
• active_route_minutes_to_arrival

While not strictly related to this issue, the question occurred previously concerning vehicle_state.media_info.a2dp_source_name. It looks like that value is currently set to a Mobile phone even though the car is not connected via bluetooth. So No, you can't use this field to detect if the driver is nearby.

Getting back to this issue, we can't clear the top 3 values, because these values are showing up in the API. But maybe something can be done about the other values.

[JakobLichterfeld]

Getting back to this issue, we can't clear the top 3 values, because these values are showing up in the API.

Even if I wish it was not, my assumption about how the Tesla API handles this was correct.

Active navigation is directly propagated from the Tesla API. changing the original behavior within Teslamate would be bad practice as it would change the meaning and would break interoperability and interchangeably.

[vincep5]

Would it make sense to also publish out the values for the other active_route_*** to MQTT so that I can at least use values? Or would those be something that will not be reported cleanly ?

…

On Wed, Mar 27, 2024 at 1:51 AM JakobLichterfeld ***@***.***> wrote: Getting back to this issue, we can't clear the top 3 values, because these values are showing up in the API. Even if I wish it was not, my assumption about how the Tesla API handles this was correct. — Reply to this email directly, view it on GitHub <#3748 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGNXO5CREAIBBCGLAZJSXZLY2JM4VAVCNFSM6AAAAABE6IDCNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRSGA3TKMJYGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[brianmay]

See my PR, #3789.

[vincep5]

Great - thanks for looking into it.