Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Daylight features in v2.05.69 #1828

Open
ebaauw opened this issue Sep 7, 2019 · 2 comments

Comments

@ebaauw
Copy link
Contributor

@ebaauw ebaauw commented Sep 7, 2019

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

This comment has been minimized.

Copy link

@salopette salopette commented Sep 8, 2019

where is there such an attitude?

sshot-2019-09-08- 1

@manup

This comment has been minimized.

Copy link
Member

@manup manup commented Sep 9, 2019

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.