When state expires allow to set a default value instead of "NULL" the state object

[DutchmanNL]

Current behavior : using the setstate expire will result in a NULL value at the state after time has reached.

Wanted behavior : more flexibility for assigning an "expire" value to developers

Suggestion : implement SetState {expireDef : >time<) which will use the def value of an state object to set after timeout has reached.

I see several situation were I would. like to use the default value at state expire instead of NULL. example online status : will. be set at polling time and set to false at time reached Have the default false value here is more efficient and understandable than NULL.

relation to https://github.com/ioBroker/ioBroker.js-controller/issues/665

[Apollon77]

The realization will be tricky ... expires are currently handled "redis style" which means that really the complete state value gets deleted. Independetly if controller is running or not ...

So to realize this we need to completely rebuild expiry handling :-(

[foxriver76]

So I guess currently it’s just a SETEX redis command. Redis does not provide a logic to expire and set a new value on expire. Expiration always means deletion.

So maybe it’s better to keep the mechanics of the current function and describe the mechanics in the docs. We could create a separate method setStateTimeout or something like this for this use case, using timeout and clearing the timeout if state gets changed before timeout executes.

[Apollon77]

So I guess currently it’s just a SETEX redis command. Redis does not provide a logic to expire and set a new value on expire. Expiration always means deletion.

Exactly. this is the only "easy" way to handle this with a real redis as data store. There could be ways like additional "SETs" or such that can be used, but also means more effort and complexity.

[DutchmanNL]

We could create a separate method setStateTimeout or something like this for this use case, using timeout and clearing the timeout if state gets changed before timeout executes.

sounds like a plan, currently this is my workaround to implement the kind of. functionality. into adapters. But would be more nice to have it handled by the backend.

[Apollon77]

But the problem is then that this gets lost when the adapter (if adapter is doing it) or controller (if controller is doing it) gets restarted or such. So it is no 100% solution

[foxriver76]

It depends. Is the goal really to build a 1:1 behavior of redis expire or is it enough on controller level. To rebuild redis behavior it is probably lots of overhead (would decline it).

We would need to store the timeouts in a separate State and delete them in the state on execution and on controller startage check if there are expired timeouts, if so, set state now (which would also not be exactly like redis), else start a timeout with the remaining time...

[Apollon77]

Yes we need to solve it with "redis mechanisms only" because we need to support having Redis as DB too ... I think there could be ways (like special keys that store these expiry infos and after that checks/reacts on key changes ... but this is not "simple" ;-)

I would not plan it into any version as of now and we see how often we stumble over it in the future

[foxriver76]

Guess, this one is a duplicate: https://github.com/ioBroker/ioBroker.js-controller/issues/650 - I would keep the current issue open due to our discussion, even though the other one was there before.

[DutchmanNL]

Guess, this one is a duplicate: #650 -

Yes, stupid me ...