As can be seen here: TimeOfDayTrigger.json the definition of the TimeOfDayTrigger contains a property called "context":"time". This has the effect, that in Paper UI, the Input value is rendered in the format of hh:mm instead of an empty text field.
Note: If you use it, this is at your own risk. Especially, you should not expect any documentation besides what is available on the Eclipse SmartHome website
There are no docs yet. It’s experimental, not done, and not yet ready for general use.
For answers to questions like these you might have some luck asking on the Eclipse SmartHome forum but most likely you will have to look at the code and figure it out yourself. There is no thorough documentation for all of this stuff yet.
About all I can say at this point is when creating a Rule with a Time of Day trigger like that, you need to use HH:MM MM where MM is “AM” or “PM”.
I know that this is experimental, but in order to improve it, I need to figure out how this works. I just like to try if someone can help me understand things before I look at the code and find out myself, since this would save me a lot of work.
Ok I will ask that question over there.
I don’t know if the version you use is different than mine, but in mine hh is for hours (0-24), mm is for minutes and you can not enter anything but numbers.
Some important things that are lacking with the PaperUi created rules that I’ve found so far that IMHO makes it not yet ready for general use include:
Cron time based triggers, in particular triggers that occur more than once a day
-Member of triggers. There is a works around for Member of changed and Member of updated (though this is currently broken) but no way to do Member of received command.
global variables or any way to create a variable that can be used across multiple rules or multiple runs of the same rule. The renders the bulk of the use case for Timers impossible. Expire binding could be a work around but it’s only a 1.x version binding and one cannot set custom amounts of time for the timer.
there are a ton of improvements that need to be made to the UI including: add all enum type commands to the drop down lists, make it more clear that any arbitrary value can be entered for state fields, sizing problem on the script entry dialog when first creating a new script action or but only if script, and syntax highlighting and checking in the script entry (off the top of my head).
None of these are problems with the rule engine itself since JSR223 rules can do all of these. But the PaperUi doesn’t let me do any of these. And all of theses are things those transitioning from Rules DSL will expect.
I’ve not yet created issues for these pending my completion of that initial set of users guides. The JSR223 file are providing a lot of help too, helping me figure out some things and steering me right when I go wrong.
But having spent the last few weeks experimenting with paper UI created rules I can say it can be a pretty painful process. I can see the potential and even if the engine itself is stable, usability is not.
Now that I thought about it more intensively.
The new rule engine wants to force you to put state into items, I guess. You can set item values, get item values and be triggered on item value changes. That way you can even “debug” easier, because you can just look up an item state in the GUI.
There are many time related triggers and conditions missing that is correct. But they are work in progress.
The JSR223 editor in PaperUI is a pain. It should at least provide syntax highlighting and a “validate” button. I agree.
Which I understand and mostly support. But you can’t put a Timer into an Item. And setting and checking Timers across multiple rules and multiple runs of the same Rule is a major use case for Timers. Set and forget Timers is in the minority of Timer use cases based on my experience on the forum.
Most everything else can be handled with Items and/or Item metadata but that one is a sticking point.
If someone can figure out a good way to create a 2.x version of the Expire binding that lets us set an arbitrary timeout from a Rule instead of the hard coded timeout supported in the Expire 1.x version binding, then I think we would be OK actually. Or if there were a Timer type Item that let us sendCommand the time and function to run at that Time that would work too.