New Daylight features in v2.05.69

[ebaauw]

I like the new state.sunrise and state.sunset attributes for the built-in Daylight sensor.
However, I do think they should report UTC time instead of local time, for consistency with the rest of the API (particularly with state.lastupdated of the very same resource).

I'm not sure how a CLIPDaylightOffset sensor would work. I would expect a state.flag-like attribute that would be true from midnight to sunrise + offset (or from sunset + offset to midnight), cf. state.daylight and state.dark.

I'm not sure how to use a CLIPDaylightOffset sensor in a rule condition. The in operator expects a time range (e.g. T07:00:00/T23:00:00). Currently there's no way to use a variable value in a condition. How would I enter a CLIPDaylightOffset sensor?
Wouldn't it make more sense to extend the ISO8601 syntax with special time values for sunrise +/- offset and sunset +/- offset, e.g. T00:00:00/TSR-00:30? for midnight to half an hour before sunrise, or TSR-00:30/TSS+00:30 for daylight.

[salopette]

where is there such an attitude?

[manup]

I like the new state.sunrise and state.sunset attributes for the built-in Daylight sensor.
However, I do think they should report UTC time instead of local time, for consistency with the rest of the API (particularly with state.lastupdated of the very same resource).

Ah good point haven't thought about that, I'll change it to UTC.

I'm not sure how a CLIPDaylightOffset sensor would work. I would expect a state.flag-like attribute that would be true from midnight to sunrise + offset (or from sunset + offset to midnight), cf. state.daylight and state.dark.

Currently it doesn't work ;) it's still work in progress and only contains the CLIP resource without the rules conditions and functionality behind it implemented. The main idea is it to define intervals consisting of two CLIPDaylightOffset sensors, with the interval defined via resourcelink(s) containing the sensor uniqueids.

We are working on a UI in the Phoscon App where the user can define individual daylight related intervals like "morning" and then say, this automation (like motion sensor control or switch configuration) should be active in this interval.

One side effect of the interval points being CLIPDaylightOffset sensors rather then condition values in rules is that they can be reused for multiple automations. So the user can just modify just a handful of intervals and all the related automations will automatically follow without rewriting the rules.

I'm not sure how to use a CLIPDaylightOffset sensor in a rule condition. The in operator expects a time range (e.g. T07:00:00/T23:00:00). Currently there's no way to use a variable value in a condition. How would I enter a CLIPDaylightOffset sensor?
Wouldn't it make more sense to extend the ISO8601 syntax with special time values for sunrise +/- offset and sunset +/- offset, e.g. T00:00:00/TSR-00:30? for midnight to half an hour before sunrise, or TSR-00:30/TSS+00:30 for daylight.

The rule condition operators need to be extended to support the CLIPDaylightOffset sensor as reference point, for example CLIPDaylightOffset sensors a and b as part of the in operator like CDO-<uniqueid>/CDO-<uniqueid> very much like your TSR/TSS idea just with an indirection to a sensor resource.

However the TSR/TSS additions are a great idea, these can be very useful and are simpler to implement for many applications which don't require the overhead of a CLIPDaylightOffset sensor.

I would suggest going for both :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.