This object is in archive! 

Creating a rule using Sunset/Sunrise for outdoor lights

Arild D. Andersen shared this question 7 years ago
Need Answer

Hi all


Im trying to create a rule based on sunrise and sunset for my outdoor lights. I´ve been using Tellstick for this mission, but i want to get this function over to my Zipato controller. In the Tellstick UI, this is a simple task to get up and running.


c86ebee6d675ac1755faa073fcc5b836


This function will adjust the clock according to the sunrise and sunset times all year automatically. I don´t need to adjust anything.


I want the same function on my rule in zipato. The sunrise and sunset times should update it self and trigger the lights. Im a total newbie to this rule creation at zipato, but I'm trying to understand it. In the picture, you can see what i have tried to do. Can anyone give me some pointers if I'm totally off or am i going in the right direction?


Im happy to answer any question or give more details about the rule. It would be great to have this figured out once and for all :-)


40c632021b870a11be5acdef74249bbc

Replies (14)

photo
1

I´ve been told they still work on sunset and sunrise as metering functions (and adviced me not to use it as a metering function)


So its easier to just use a planer to start something on sunset or sunrise (upper examples) or just use a variable, based on sunset or sunrise. With the pure weather function you also have no astro-offset. I use a variable (example below) which becomes 1 between 30 min past sunrise and 30 min before sunset (much better inside a home because at sunrise / sunset it is still dark in the house. That variable can be used in all of the other rules.

photo
1

Thanks for you answer.


I thought they fixed the sunrise/sunset problems in the latest firmware?

4c441631ba29037832c0849a89aa2a06

photo
photo
1

Even if it has been fixed I would recommend a variable (because of the astro-offset) and its just a guess but I would rather use sunset and sunrise as shown in the attached picture because I wouldn´t expect your rule to work. I think sunset and sunrise can´t set themselves. But thats just my understanding of those metering functions. Perhaps someone here has a clue?

photo
2

Ups I think I´ve forgotten the "time of" tile. Can´t try it out right now, but I think thats the problem.

photo
1

Hey,

I am using a virtual switch "Tageslicht" (daylight) which is set to on in the morning by a scheduler with astro option and and in the evening to off with an other rule (also scheduler with astro). It works fine since a long time. I use this switch in a lot of rules to test for daylight. You can use it in your rule


when motion on

join

if daylight off

.....

else

....


is much easyer.....and easy to read

photo
1

is that virtual switch still working?

Or is there an easier method available already for sunrise/set actions?

photo
photo
1

I´m using the astro offset in scheduler config to create a virtual switch with sunrise in a rule, and one rule to create sunset.


This virtual switch is used in other rules.

photo
1

hey guys, the best solution is as helle, andreas and klaus suggest, is to create a rule that makes a variable or virtual switch or virtual sensor that is based on a scheduler rule for sunset and sunrise. Then this variable/switch/sensor can be used in multiple rules without having to add in scheduler puzzles all the time. Also I do not think you can get a time between sunset and sunrise with Zipato rules. I think the sunrise and sunset just act as a point of time, not a type of meter.

If you need help configuring the astro and scheduler for a virtual sensor let us know.

photo
1

Have a look at my comments on this topic for a possible way to make sunrise and sunset times into more usable variables.

https://community.zipato.com/topic/need-a-way-to-store-and-compare-datestimes#comment-26273

photo
1

I don't know what everyone else has found, but the "sunrise" and "sunset" values in the Zipato weather station seem, in fact, to be strings. If I copy those values to a virtual meter and try to compare them to other date values, they always behave as 0. If I send them to an email, the reason becomes clear. This is what I see (the description in brackets were added by me).


19:36 (Sunset)

08:25 (Sunrise)

They're not numerical time values at all.

photo
1

Dave, what does it mean? In common language not programming...

photo
1

It means that the raw "sunset" and "sunrise" values can't be used in any kind of comparison with times.


However, it turns out that "hour of (sunset)" converts it into a valid time value, and now (as of firmware 1.0.17) the comparison does work properly.

photo
1

Actually I've just discovered a way to exploit this. You can make comparisons with fixed times using the "time" piece, but it only allows 15-minute intervals. What if you wanted to ask something more precise like


time > 19:01


?


Well you can exploit the fact that time of () casts a string into a time value, and just write the time in yourself. I didn't know that. (Perhaps you did!)

photo
1

I guess Arild should have solved his problem by now by using the scheduler or weather "device".

I had a problem with a rule to check if sunset is over by "NOW". After many trials I found out that the TIME() function creates the number which counts the seconds from midnight times 1000 (or 36000000 per hour). However your time is converted into UTC. Example for times(15:00) - CET:

15h CET is 14h UTC . 14 * 36 000 000 = 50 400 000

That is for (CET): times(14:00)=50400000

Now I can use comparison in rules and I can use also weather input to use in calculations.

photo
1

Could you give us an example of a rule where you do this? I understand that you're not storing time values in variables (the last time I checked, that didn't work).

photo
1

This examples compares the a. m. time values of variables.

photo
1

Are you able to store those values in variables? I tried to do it in all kinds of different ways, but found that the variables couldn't handle those values. In practice they behaved as if they contained 0. Unless Zipato have changed something...

photo
1

Yes, time value can be stored in variables. See attachments. Rule was triggered at 18:00 (6 pm). The attachments are in German, sorry.

photo
1

Hi Michael

No problem, I know German.

Unfortunately I fear your rules may not be working the way you think they are. What I concluded after a lot of testing is that, although you can indeed store dates and times in variables and send them to yourself in an email, and see the values, they behave in rules as if they had the value zero. I reported this to Zipato a long time ago. In fact, if you try to compare a variable with a stored date or time to a time or date value (e,g. if variable1 > time of (now)), you get an error (see screenshots).


I made another test rule to see if things had changed since I last looked at this, and unfortunately they haven't. When I run the test rule (see screenshot), the only switches that toggle are 4 and 10, indicating that the test value is considered to be zero.


Do you have a Zipabox or a Zipatile? I suppose it's possible that there might be a difference there.

photo
1

You are right. My tests show:

All calculations with variables end up with ZERO (0.0)

However, comparison works (see attachment)!

photo
1

I modified my test to do more or less the same thing yours does, and to do some more checks, and I definitely can't make a successful comparison. The only test switches that flip are 2, 4 and 10, indicating that both values are 0, and equal. :-(


So your test enters into the "if" and triggers the dimmer?


Do you have a Zipabox? What year did you get it (I don't suppose it's the new one)?

photo
1

You are right. I did some more tests: Comparison with variables do not work either, although the variables show values which could be compared.

Result: Comparison and calculations with variables do not work!!

photo
2

Sadly not! :-(


I hope this will get fixed at some point.


Anyway that's why I created a date-time meter which uses smaller values which the Zipabox variables can handle. The date-time values use fractions of hours, and the time values use seconds.


https://community.zipato.com/topic/a-method-for-creating-manipulable-time-and-date-values

photo
photo
2

Arild,

Take a look at this file, you can create a daylight sensor and use it across many rules.

photo
1

Just to share my setup for our garden lights based on the build-in weather station sunrise/sunset capabilities. Based on the scheduler I set a variable and a virtual switch. I have also included a manual override switch for the occasional glitch in case the Zipabox was unable to determine the sunset/sunrise times.


I created the rule around the following requirement: 'turn on garden lights when it gets dark in the evening and turn them off when it is 00:30. In the morning, turn on garden lights when still dark at 07:00 (first one leaves the house around 07:15) and turn them off at sunrise.'

To clarify some of the Dutch words used in my rules:


  • Zonsondergang = sun set
  • Zonsopgang = sun rise
  • Zon onder = no sun (no daylight)
  • Tuinlampen = garden lights

PS I use a 'proxy' switch for the garden lights because I experienced some connectivity issue with my z-wave wall plug and by using a proxy I did not have to fix all my rules that include the garden lights when I had to remove and pair the wall plug.


Leave a Comment
 
Attach a file