Group Decay script

[CrazyIvan359]

Provides automated Group decay timer Item and Rules. When all other Items in the Group have changed to the same state as the decay Item is configured to decay to, a timer will be started and the decay Item will be set at the end of the timer period. Example usage is for presence sensor Groups where you want the Group to stay ON for a period after all other Items in the Group have changed to OFF. Decay will only look at the immediate members of the Group that has the metadata, it will not recurse into Groups. The Decay Item will be created if it is not found in the Group.

I realise that the functionality of this is almost identical to #234 but it didn't fit into my existing presence setup the way I wanted. This is my take on the same idea, figured I'd submit it as an alternate option for those interested.

[CrazyIvan359]

Force push is because I forgot to include a configuration.py.example file.

[rkoshak]

In what ways did it not fit if the functionality is almost identical? My concern is that if we have two or more libraries that all do the same thing but slightly differently it's going to be very challenging for users to figure out what to use. Seems like it would be better to update the one library so it fits your required functionality.

But it's not my repo so my opinion doesn't count for much.

Would it be possible to use #283 to simplify this some? It's a class that let's you sendCommand but schedule it to run X minutes (or seconds or hours or ...) from now, with the ability to cancel of course. I'm still waiting for a reading on the policy for community libraries that depend on other community libraries so it's mainly just curiosity.

[CrazyIvan359]

I agree that multiple solutions could be confusing. Decay differs a bit from yours as it is not specific to presence. I also didn't want to step on your toes, as code wise this is quite dissimilar.

Your script requires creating a proxy item to use as the presence switch, I already had everything setup with my groups of sensors and didn't want to rearrange things. I already had decay items but they were outside the group and used expire, this only worked for decaying general presence and not a specific person. So I wrote Decay to improve on what I had without requiring me to change anything I had. I also wanted it to be wide open, not just specific to presence, and configured in metadata.

Yes, 283 would be a good fit for this and expire. Though it would make decay and expire mutually exclusive for an item as one would cancel the other's timer.

[rkoshak]

It's called persistence but it was never my intention that it would only be suitable for that. I can change the name and nothing else and it won't be presence specific anymore (OK, yes the logs are presence specific but that's easy to change too). I had to name it something and I chose to name it presence mainly so there would be tracability from the tutorial on the forum and the library. But it was never intended to be used just for presence.

The proxy Item, as far as I can tell is the same thing as the decay Item. Except for the fact that my implementation doesn't use Expire (any more, the Rules DSL version that I started from did use Expire but I didn't want to submit a library that depends on a 1.x version binding) and the timeout is defined in configuration.py instead of Item metadata the two serve the exact same function. The only real difference is terminology.

So as far as I can tell the only technical difference (in terms of what the code does, not in terms of how the code is implemented) is the use of metadata instead of configuration.py. The rest is just differences in nomenclature.

[CrazyIvan359]

Decay doesn't use expire, it's just using the same format for the metadata and by consequence the same time string parser.

Your script uses a proxy item them that is used as the actual presence switch where Decay uses the group and just adds an item to it. That plus the metadata vs configuration.py are the only differences.