(heating.gas.consumption.total) large difference between timestamp and dayValueReadAt

[berroniko]

I noticed that sometimes there is a significant difference between the "timestamp" (which I understand as the moment the response was sent) and the dayValueReadAt (which I understand as the time the measurement was taken). In the following example the difference is a full month. There are other examples with less than a month, too.
Do you have any idea what the reason could be?

        "dayValueReadAt": {
            "type": "string",
            "value": "2023-05-24T03:54:25.876Z"
        },
        "weekValueReadAt": {
            "type": "string",
            "value": "2023-06-18T21:59:51.460Z"
        },
        "monthValueReadAt": {
            "type": "string",
            "value": "2023-05-31T23:56:13.834Z"
        },
        "yearValueReadAt": {
            "type": "string",
            "value": "2023-05-24T03:54:27.007Z"
        }
    },
    "commands": {},
    "apiVersion": 1,
    "uri": "https://api.viessmann.com/iot/v1/equipment/installations/18594/gateways/7571381629375109/devices/0/features/heating.gas.consumption.total",
    "gatewayId": "-",
    "feature": "heating.gas.consumption.total",
    "timestamp": "2023-06-24T20:01:19.054Z",
    "isEnabled": true,
    "isReady": true,
    "deviceId": "0"
},

[MichaelHanna]

Hi @berroniko , Thank you for sharing here in the community!

Our IT colleagues will need to have a look to clarify this point. I will let you know as soon as I get a response.

Regards,

Michael 

[berroniko]

Hi Michael, did you get any feedback from your IT colleagues?

[MichaelHanna · Accepted solution]

Hi @berroniko, I now got an information from the IT. They state that sometimes 'ValueReadAt' was not updated as the value did not change or the update wasn't sent yet. This kind of large gap is probably due to some temporary error.

Unfortunately we cannot track this issue so far in the past –  are you still experiencing large time differences now?

Regards,

Michael

[berroniko]

Thanks Michael!
I checked my data and found the discrepancies only in the period between mid May and early October 23. Afterwards it's mostly the same day, sometimes one day difference. So it was a temporary error.

To get my numbers right, I will then ignore "ValueReadAt" for this period and use "timestamp" instead.

Best regards

Niko