Update device state in the past

Developer Programs Support
1

Hi, I’m using stateCallback api call to update my device state and try to update it for a timestamp that is in the past, here’s my call:

{
    "headers": {
        "schema": "st-schema",
        "version": "1.0",
        "interactionType": "stateCallback",
        "requestId": "abc-123-456"
    },
    "authentication": {
        "tokenType": "Bearer",
        "token": "<my token as received by grantCallbackAccess>"
    },
    "deviceState": [
        {
            "externalDeviceId": "my-smart-meter",
            "states": [
                {
                "component": "main",
                "capability": "st.energyMeter",
                "attribute": "energy",
                "value": 1.2,                
                "timestamp": "1706904634397"
                }
            ]
        }
    ]
}

but it only updates the current state instead of changing the state in the past.
is it supposed to work this way? if so - what is the purpose of the ‘timestamp’ field? it looks that it works the same with and without it.

thanks.

2

Hello!

I would imagine the point of the time stamp field is to provide the real state of a given device at a particular time. It never occurred to me that there would be a reason to change the recorded state of a device at a particular time in the past, or to change the recorded time at which a device was in a given state.

If I have a door that was Locked at 7:30am, why would I wish to change the time stamp of that status? If I change it to 7:32 when I unlocked the door, I would then have the device in two different states at the exact same time… if you are using ST for security and there’s a break-in, there’d be no value whatsoever in the recorded times if they were somehow edit-able.

2 Likes
3

Tagging @orangebucket

4

That’s exactly the point. I want to update the
data to be accurate to the time of the measurement, but the measurement is in the past.
The data is provided by a cloud service that provides data for the day before and for the current time.
Therefore I want to be able to update the value to a specific timestamp and not for now.

5

The schema stuff is outside of my experience so I can’t be much help. I am somewhat surprised that there is a timestamp property on the sending end at all as I associate timestamps with the time of events and to me that seems like something ST should be determining on receipt. I also can’t see any hints of timestamps in the sample code and libraries.

I don’t really see how the idea of state changes in the past fits in with the ST device model which is all about commands one way and events the other. However that’s probably a failure of my imagination. I would have thought that any such timestamp data should actually be an attribute of the device that is separate to the time the data is passed to SmartThings (which I assume timestamp to represent).

2 Likes
6

Thank you for your answer. I’ve just figured out that the timestamp is actually recorded as “raw time” in https://my.smarthings.com/advanced, but it is not presented anywhere in the app.
I’ll try to create a custom visual layout to display it as the graph instead of the default graph which displays the event time and not the raw time.

7

Hi, @Lior_Tamam
I asked the engineering team about this and they mentioned the field timestamp in the stateCallback Request is ignored due to concerns about some points like the data reliability and security.
So, the source of truth is the timestamp of when you send the request to update the status of the device.

8

Thank you for the follow-up.
I believe that should be exactly the opposite - the time when the event was submitted is never the source of truth, because the time that the event submitted is always after the measurement was collected from the sensor.
In my case this is much worse, since the power meter itself submits the data to the cloud few times a day, every few hours, and each time the data is provided in 15 minutes buckets.
The cloud service providing data only for the previous day, sometimes more than 24 hours in the past.
Using only the event submitation time, will make it impossible to create a reliable representation of the power consumed.
I understand that this is the given situation, so unfortunately I can not create a proper cloud to cloud integration as I intended.
Thank you.