REGEX is indeed hard. It’s its own programming language (it was proven to be Turing Complete some years ago). I’d recommend maybe a link to one of the many tutorials out there and perhaps a tester. Though one problem a lot of users run into is that the way the REGEX transformation works is not standard. The transform needs to match the whole text and we need to use parens to define what part we want to return. Standard REGEX would just need to define the part of the text you want to return. And that is how the online REGEX testers work. That’s why we see so many postings along the lines of “It works in regex101.com, why not in OH?”
Given that this is an integration with an external service, it seems to me that it belongs in a binding. Obviously the CalDav binding will need to be replaced for OH 3.
In my opinion, I wouldn’t go out of your way to make this happen. If it’s easy to provide an API endpoint to allow bindings to post things to the schedule that seems reasonable, but like you say, if someone is using the CalDav binding then using a native calendar service makes sense to me.
Indeed. A lot of the “never cloud” users will want to be able to use OwnCloud or NextCloud calendars for something like this.
I like the scheduler a lot.
Now to bring up a bunch of tricky use case questions:
-
What about order? If two timers on an Item expire at the same time, is the order defined or undefined?
-
Timer loops? With two timers I could easily set up (deliberately or accidentally) a loop
-
That way you can influence (read: stop/restart) expire timers with a given ID or given tags.
This one is actually quite different from the way Expire Timers work and it makes me wonder whether it makes sense to do it. The Expire works like “when Item changes to a state that is not state x, set it to state x after the configured amount of time”. To cancel the timer one simply sets the Item back to the configured Expire state. Is there actually a use case where we would want to cancel the Timer without the Item going back to the Expired state? Maybe cancelling the Timers like this is overkill. Or maybe we we need only to support start/stop and not the Expire state behavior?
Obviously it would be a smoother transition for those of us who rely upon the current Expire binding. But part of me is wondering if we need to implement both use cases. Probably the answer is yes. Just throwing out the question a something to consider.
This raises a question. One important use case that is missing right now is personal alarm clocks. Here is a case where the biggest lack is the sitemap, and I’m not really intending to address that part of the problem here. But is there some way, assuming that a user interface is created to allow users to set the time, that they could set an alarm through this mechanism? I think the answer must be yes, but I can’t fit my mind around how. Is it as simple as just updating the DateTime Item tagged with “alarm”?