I’m fine with the current behavior if the “unknown” period is properly recorded into the history database, and the state change timestamp is consistent with and can be read from the state tracking database
Edit:
Let it be an option on the integration component to decide. It doesn’t make sense to update the changed timestamp and not store a state change in the entity history. The entity state doesn’t have a memory of the system restart.
From the entity perspective, the timestamp is behavior so unpredictable that it appears random, which is the physics def for choas as opposed to the emotional definition. Yes, I can write a script to lookup the system uptime and see if it is within 20 seconds of the last state change timestamp, but is a poor basis for deciding if the timestamp is updated due to system restart
This feature request is actually a duplicate of the top 6th (out of hundreds) most outstanding feature request on the platform with 341 votes