DateTime or Time only triggers - the 'eternal 'alarm clock question

Setup, Configuration and Use Beginners
1

I have read the very many posts on ‘how to allow a user-defined trigger’ time- or ephemeris based trigger for something, among others: this one:

(https://community.openhab.org/t/timers-and-datetime/141590)

I have - for example a swimming pool pump, which needs to run - say 3 times for 2 hours - per day in summer, and only 2 times 1 hour in winter.

Among the various possibilities, I settled for DateTime rule triggers, which I can (crudly) edit within a list item using a

listWidget="oh-input-item" [outline="true", clearButton="false", showTime="false",type="datetime-local", sendButton="true",validate="false"]

It’s not beautiful, but it works.

I then use the defined timer items as triggers for switching the pump on …

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: poolPump_On_1
      timeOnly: true
    type: timer.DateTimeTrigger
  - id: "2"
    configuration:
      itemName: poolPump_On_2
      timeOnly: true
    type: timer.DateTimeTrigger
  - id: "3"
    configuration:
      itemName: poolPump_On_3
      timeOnly: true
    type: timer.DateTimeTrigger
conditions: []
actions:
  - inputs: {}
    id: "4"
    configuration:
      command: ON
      itemName: poolPump
    type: core.ItemCommandAction

It’s not exactly elegant, but it works.

What really bothers me is, that the DateTime trigger items, don’t survive a reboot, i.e. the DateTime Items aren’t persisted and not even restored to the last value. I’m using rrdj4 and I really would hate to create a separate persistence strategy just for that.

Any thoughts on a better solution?

2

Nope. Persistence is the best solution, especially since you’ve done all the other work already. MapDB is a one-click install and you can define the strategy to only persist this one item if that’s all you care about. The overhead is neglible.

If you’re dead set against that, you could use a rule to copy the datetime value into a number item that gets persisted, with a second rule that replaces it on system startup. But I wouldn’t consider this to be a better solution since there are more moving parts and more things that could go wrong. MapDB just works, and you’ll never have to think about it.

Personally, I couldn’t get by without MapDB since I have a lot of string and datetime items in my system.

Alternatively, you could switch to using InfluxDB. It’ll be more work, but it’ll handle all of your items and enable you to use Graphana and other tools for data visualization.

1 Like
3

Well, you have to. rrd4j is only for number values.
Use mapdb for values to restore on startup.

4

What version of OH?

I have a memory of seeing a PR come across that added support to rrd4j to store DateTimes as well as Switches and Contacts. All three can be represented as a number so rrd4j can handle them (Date Times can be saves as epoch).

Though as I’m looking at my rrdj4 files I’m not seeing any of my DateTime Items represented.

I use rrd4j for charting and mapdb for restoreOnStartup. Both are optimal for each different task. I have custom .persist files for both.

rrd4j.persist

Strategies {
        everyMinute  : "0 */1 * * * ?"
        default = everyChange
}
Items {
        * : strategy = everyMinute, everyChange
}

mapdb.persist

Strategies {
  default = everyChange
}
Items {
        * : strategy = everyChange, restoreOnStartup
}

time instead of datetime-local generates a nice time picker widget.

image
image1256×632 71 KB

5

Thanks @rlkoshak, I have adapted it to the same set of strategies. let’s how that goes.
I have tried this:

value: oh-input-item
config:
  outline: "true"
  type: time
  sendButton: "true"
  validate: "false"

For some reason, it doesn’t send the command, though. When clicking the tick mark button, the input is reset… :grimacing:

image
image1920×1080 169 KB

image
image1920×1080 154 KB

6

In general, and relating back to this discussion, it would really be great, if I could, within the rule using that Timer Item as a trigger then reference to the name of the (Timer) Item … (or at least the trigger id)… This would allow to use one rule for all timers, and store the specifics of the timer (which Item to control? which command? and a ton of other things …) in metadata or appropriately named helper items … instead of creating one rule per timer.

7

Hmm, it should but I admit I didn’t try it. That might be a bug worth filing (How to file an Issue).

There is the start of a PR to add this sort of information to event but work on it has stalled. Add event information in rules for time, manual and RunRuleAction trigger by J-N-K · Pull Request #2965 · openhab/openhab-core · GitHub

In the mea time you can use the current time compared to the times in the Items you know can trigger the rule and see which is closest to now. In JS Scripting you could do something like the following (if all the triggering Items are in a Group).

var now = time.toZDT();
var howClose = time.Duration.ofSeconds(1);
var triggeringItems = TimeTriggerItems.members.filter(i => time.toZDT(i).isClose(now, howClose));

if(triggeringItems.length != 1) {
  // if null or zero, not triggered by the Time Items, manual?
  // if > 1 your DateTime Items are too close together in time
}
else {
  var trigger = triggeringItems[0];
}

If you don’t care about error checking it could be a one liner.

Note isClose tests both sides of the date time. So in this case if the time is between one second before to one second after the Item it will return true. But in practice, a rule triggered by a Time trigger won’t run before that time.

8

I think the PR just requires review and merge, or is there still something missing from my side?

9

I don’t think there’s anything missing from my side. I’ve been eagerly awaiting this feature for awhile. If it’s ready to merge would it be inappropriate to ping maintainers to give it a look? I’m sure it’s been forgotten. It’d be a great new feature to brag about for OH 4.

1 Like
10

Even when used as the default widget for an item, the sendButton feature requires that an item config be specified.

2 Likes
11

@JustinG,
This is really beyond me, now.

With the above configuration, the Item is actually updated through the widget. and adding a hard coded item: "itemname" config line doesn’t actually change anything to that…

However, if type: time then the widget doesn’t populate the field with the current value and it will clear the field, when the send button is pressed. (That behavior is independent of whether or not item: "itemname" is hard configured.

When using type: datetime-local, well the field is prepopulated with the value and the value modified through the widget isn’t cleared frm the input field, once the send Button is pressed.

Is that the expected behavior?

12

Well, this is beyond my paygrade. But if I can send a message to somebody to trigger (no pun intended) the review and merge… :wink:

13

Sorry, I thought from your previous post that the command was not even being sent from the widget.

The behavior you’re seeing, I think, is the same as was discussed in this thread. I guess that the bug wasn’t reported at that time, so Rich is right, you should probably file an issue about it.