Updating of subscribed mqtt topics does not work reliably

[psteinrueck]

Problem description:
Issuing commands to the vehicle e.g. climatization start / stop or wake - sleep works fine

• car responds almost in real time
• car reaction checked via Volkswagen app)

Updating of the related topics either works delayed or not at all,

• issuing an update command does not help either

Observations
carconnectivity-plugins\mqtt\mqtt-client
def method: _oncarconnectivity_event

elif ((flags & Observable.ObserverEvent.VALUE_CHANGED)
or (self.republish_on_update and (flags & Observable.ObserverEvent.UPDATED)))
and isinstance(element, attributes.GenericAttribute) and element.enabled:
self._publish_element(element)

        ######################## added debug code ############################
        if "climatization/state" in topic:
            vin = topic.split("/")[3]
            print (f"mqtt_client got new value --- climatization state ={vin} {element}")
        #######################added debug code #############################

tyical behaviour

• car reacts
• flags & Observable.ObserverEvent.VALUE_CHANGED turns True after delay of about 60 sec:

debug log:

mqtt_client got new value --- climatization state =WVWZZZED1SE504916 heating

carconnectivity_connectors\volkswagen\connector.py
def fetch data...

###########################added debug code ####################################
time.sleep(1)

    keys = [
        ("climatisation", "climatisationStatus", "value", "carCapturedTimestamp"),
        ("climatisation", "climatisationStatus", "value", "climatisationState"),
        ("charging", "chargingStatus", "value", "carCapturedTimestamp"),
        ("charging", "plugStatus", "value", "plugConnectionState"),
        ("charging", "chargingStatus", "value", "chargingState"),
        ("charging", "chargingStatus", "value", "chargePower_kW")
    ]

    def get_nested(data, path):
        """Liest einen verschachtelten Key-Pfad aus und gibt None zurück, falls er fehlt."""
        d = data
        for key in path:
            if isinstance(d, dict) and key in d:
                d = d[key]
            else:
                return None
        return d

    timestamp1 = get_nested(data, keys[0])
    cli_state = get_nested(data, keys[1])
    timestamp2 = get_nested(data, keys[2])
    plu_state = get_nested(data, keys[3])
    cha_state = get_nested(data, keys[4])
    cha_power = get_nested(data, keys[5])
    
    if all(var is not None for var in (timestamp1,cli_state)):
        print(f"   Klimatisierungs-Zeitstempel : {timestamp1}\t{cli_state}")
    if all(var is not None for var in (timestamp2,plu_state,cha_state,cha_power)):
        print(f"   Charging-Zeitstempel        : {timestamp2}\t{plu_state}\t{cha_state}\t{cha_power}")
    time.sleep(1)
    #############################added debug code #############################
    return data

debug log; e.g. on connecting the car to a wallbox at 21.53:15 GMT+1

WVWZZZED1SEXXXXXX
Klimatisierungs-Zeitstempel : 2025-12-10T19:55:04Z off
Charging-Zeitstempel : 2025-12-10T19:55:04Z disconnected notReadyForCharging 0
WVWZZZED1SEXXXXXX
Klimatisierungs-Zeitstempel : 2025-12-10T20:54:09Z off
Charging-Zeitstempel : 2025-12-10T20:55:30Z connected notReadyForCharging 0

remark: carconnectiviyt has been started appr. at 21:45, but not reaction in mqtt client / explorer

Used hardware and software
VW ID.7 SW 5.2 online
Windows 11 25H2
Python 3.13 IDLE environment
carconnectivity-mqtt package 0.9.2.
carconnectivity-connector-volkswagen 0.9.2.
mqtt explorer on local host Port 1884
config File: intervall 300, broker: local host port 1884

[psteinrueck]

When the climatisation state changes from "heating" to "off":
in

...\volkswagen\connectors.py

line 1005:

vehicle.climatization.state._set_value(value=climatization_state, measured=captured_at)# pylint: disable=protected-access

does not cause the observer to start the method: _carconnectivity_event in in.

..\mqtt_client.py

Most probably the UPDATE or VALUE_CHANGED flag ist not set. Thus the mqtt broker never will be notified about the changed status. Interstingly Changing form "off" to "heating" works fine.

[psteinrueck]

Issue: Climatization state changes sometimes not propagated (MQTT / observers)

Problem
In the Volkswagen connector, changes of climatisationState (e.g. heating → off) may not trigger observer notifications or MQTT updates, although _set_value() is called.

Cause
GenericAttribute._set_value() ignores updates whose measured timestamp is older than the last update:

if self.last_updated > measured:
    return

The VW API often returns the same or an older carCapturedTimestamp for state changes, so valid transitions are discarded.

Solution (connector-side) \carconnectivity_connectors\volkswagen\connector.py line 1001
Ensure a monotonic timestamp before calling _set_value():

captured_at = robust_time_parse(climatisation_status['carCapturedTimestamp'])
now = datetime.now(tz=timezone.utc)
if captured_at is None or captured_at <= now:
    captured_at = now

Result
All climatization state changes reliably trigger observer flags and MQTT publications, without modifying the core framework.

---

[Schnulli87]

Does this only affect the climatisationState or also e.g. the target-temperature?
I noticed a long delay, when I change the target temperature in the VW app and try to get this change into carconnectivity.

[psteinrueck]

To Schnulli87: I have not tried to change climate settings via carconnectivity yet. Thus I can't comment.

However, as you report that carconenctivity reports the new settings at all, Thus I assume the "no reaction" issue of "stop climatisiation" does not apply. Be aware carconnectivity only reports changes to any parameters only at occasion of the next update cycle. If the update interval has been set to 300 (default) this might take some time. If you need to have an ultimate response you may add:

self.update_vehicles()

at the end of:

  def __on_wake_sleep(self, wake_sleep_command: WakeSleepCommand, command_arguments: Union[str, Dict[str, Any]])  -> Union[str, Dict[str, Any]]:

around lines 1800 in connector and publish a wake command via mqtt.
please find the patched version of connector. py attached. Changes to the original file have been marked by '#####'. There are some addintional debugging prints included which I found to be very helpful.
Replace .../site-packages/carconnectivity_connectors/volkswagen/connector.py by the attached file

connector.py

[tillsteinbach]

The long response time after a command or set is possible to fix. I have done that in WeConnect-python before. After a command you get an ID for a running request back and can poll until the request is finished. When it is finished the values can be refetched and will contain the new values.
But implementing this is not very high on my todo list.

[tillsteinbach]

The long response time after a command or set is possible to fix. I have done that in WeConnect-python before. After a command you get an ID for a running request back and can poll until the request is finished. When it is finished the values can be refetched and will contain the new values. But implementing this is not very high on my todo list.

https://github.com/tillsteinbach/WeConnect-python/blob/main/weconnect/elements/helpers/request_tracker.py for reference

[psteinrueck]

Thanks a lot: meanwhile I have found a work around working nicely. I have added an update command at the end of

def __on_wake_sleep_command

in connector.py. Publishing a wake command via mqtt triggers a data update. So I can live with prettypolling long intervalls (720s) for our e_Golf (180 s exceeds the request quota already in the morning, for our ID.7 this not an issue)

[psteinrueck]

BTW: the above suggested patch to connector.py seems to essential to get any response on the "stop heating" issue. Without the patch, heating is reported by carconnectivity to be on forever (although stopped on the car and reported by the VW app)

[tillsteinbach]

@psteinrueck you are running carconnectivity in a thread expecting it to update in the background, right? do you have a car_connectivity.startup() call in your code? This would start the necessary background threads that would do the updating.

[psteinrueck]

@tillsteinbach I am running a python script

Car_Connectivity.py

see attachment) which starts the wrapper: carconnectivity-mqtt config-file and hence does all communication via the paho mqtt client. Except the "climatisation stop" command everythings works fine. As pointed out I have analysed the problem's root cause:

On stopp heating the time stamp is not updated by the API. Therefore the car_connectivity hook mechanism checking first for updated timestamp and second for changed values does does not recognize the signal to be updated.

Car_Connectivity.py

[tillsteinbach]

On stopp heating the time stamp is not updated by the API. Therefore the car_connectivity hook mechanism checking first for updated timestamp and second for changed values does does not recognize the signal to be updated.

You mean the timestamp for the heating status? This should not really matter as long as it does not become older than the previous timestamp. You mean this part?

CarConnectivity/src/carconnectivity/attributes.py

Line 353 in 30705ea

if self.last_updated is not None and measured is not None and self.last_updated > measured:

do you see the Value from the past message when in debug log?

[psteinrueck]

I refer to:
https://github.com/tillsteinbach/CarConnectivity-connector-volkswagen/blob/main/src/carconnectivity_connectors/volkswagen/connector.py
1008: captured_at: datetime = robust_time_parse(climatisation_status['carCapturedTimestamp'])
As soon as I replaced captured.at with

############################################################################################
# --- PATCH: ensure monotonic timestamp for observable attributes ---
now = datetime.now(tz=timezone.utc)
# Make sure captured_at is never in the past relative to local processing time
if captured_at is None or captured_at <= now:
captured_at = now
############################################################################################

carconnectivity did what it was expected to. (reacted to heating-> off)

[tillsteinbach]

This is still confusing me, all the values will have captured_at in the past relative to the local time. The values cannot have been measured in the future.