Open Eseraz opened 5 years ago
@adimova WDYT?
So the feature seems to work already, but when thinking a bit more about it, maybe it would be better if you could just set two time values without any comparator. So if the first time value is before the second value, it checks if the time is between those two values and if the first time is set after the second value it will check if the time is between 00:00 and the first time value, or the second value and 00:00.
I think i will try that and then I'll figure out how to put this in a pull request, if you think that would be a nice feature :)
If you want to have a look, the feature is implemented on this branch. I will most likely add some tests tomorrow and then make a pull request.
I have a few thoughts...
1) The end time should be excluded from the interval, to avoid overlaps. One condition ending at 5AM and another starting at 5AM, should not both be true at 5AM.
2) ZonedDateTime should be used instead of LocalTime, in order to handle Daylight Saving Time transitions. For example, a LocalTime interval from 1:15AM-1:45AM would occur twice on a transition day.
3) There are several other temporal conditions that could be combined, including what you've done with TimeOfDay. Each condition has a start and end date, but the user input fields could be a free-form manual time, or a DateTime Item with an optional duration offset. I think this would cover most use cases for a Date/Time condition. This might be better as a future feature request, but since the TimeOfDay functionality would be included, implementing it now would save some rework. However, I do not know if any of this is something that would be approved, but it seems like a good addition to me!
Start | End |
---|---|
Item1 | Item2 |
Item1 | Item1 plus duration |
Item1 minus duration | Item1 |
05:00:00 PM (before Item1) | Item1 |
Item1 | 05:00:00 PM (after Item1) |
05:00:00 PM | 09:00:00 PM |
Good point, I will change that!
True, that is a problem. But would that be solved if i changed that to ZonedDateTime? The form only takes hours and minutes as parameters, so if I want to transform start and end time to ZonedDateTime it would probably look like this:
LocalTime startTime = LocalTime.parse(startTimeConfig).truncatedTo(ChronoUnit.MINUTES);
LocalTime endTime = LocalTime.parse(endTimeConfig).truncatedTo(ChronoUnit.MINUTES);
ZonedDateTime currentZonedDateTime = ZonedDateTime.now();
ZonedDateTime zonedStartTime = ZonedDateTime.of(LocalDate.now(), startTime, ZoneId.systemDefault());
ZonedDateTime zonedEndTime = ZonedDateTime.of(LocalDate.now(), endTime, ZoneId.systemDefault());
Since I don't have any information about the time zone of start and end time, they always stay the same as the current times time zone. Therefore even with these changes (if I am correct), it would happen twice again, but once it would be 1:15AM-1:45AM in the BST Time Zone and once in the GMT Time Zone. Or am I missing something obvious?
An option might be to check the rules of the time transition using the ZoneRules and ZoneOffsetTransition classes to detect if the condition is affected by daylight savings. So if the check says the time exists twice on this day, the condition will return false the second time it occurs. Or if the check says the condition will not be true at all, since the hour between 1 and 2 AM is missing, the condition will return true from 2 AM to 3 AM instead. Although I'm afraid this option might be a little complicated...
I could easily create a separate condition, that compares a time item with another time item, or a time item to a time in hh:mm format. But I don't want to clutter the available options with too many time conditions.
When generating rules with Paper UI, I was unable to check if the time was later or earlier than a specific value through the UI. I want to add a module, which makes that possible.
I am guessing that this module would go in the org.eclipse.smarthome.automation.module.timer package?