New Topic

Zipato support center Topic Question Rule creator

This object is in archive!

Problem with sunset and sunrise

Klaus G shared this question ago

Need Answer

I´m not absolutly sure but I think the lower part of this rule (old rule) used to work until the last update. Its purpose is to make sure the day/night sensor is set propperly.

It was part of a routine that ran after a reboot but now it doesn´t work anymore ;-( Can anyone confirm, that those constructions used to work or should work (perhaps a fault in the new firmware)? Or do you have a better idea to set a virtual sensor according to sunrise and sunset? (it has to work whenever the box restarts so using a scheduler (which I have for normal operation, see regular setting of sensor) won´t help)

Files:

The same question

Replies (4)

Klaus G ●

Sorry, I have forgotten this picture and can´t edit the old topic

Files:

Reply URL

Attila Hajdu ●

Your rule 11 does not make sense from Zipato programming point of view. You cannot ever use anything else than one scheduler in the when block as trigger. You cannot even combine it with other states. So if you need a scheduler to start, only use one and make 2 rules if you need 2 schedulers. In your rule 17 what happens if the variable reboot is not 0. You need to remember that after restart the varialbe will have no value and not be "0"...

See my printscreen. The rules are named accordingly:

1. One is a simple restart tester - you cans et it to run every 5 minutes, no need to have it more frequent

2. 2 rules sets the sunrise (one virtual weather station based and another based on simple scheduler with latest possible time

3. 2 rules sets the sunset (one virtual weather station based and another based on simple scheduler with latest possible time

Files:

Reply URL

Carlo ●

Hi Attila, I'm using up to four scheduler in the same rule and it works (see screenshot).

Files:

URL

Attila Hajdu ●

Hmmm, interesting. It was a while ago when I was told by various Power users and also by Zipato to not combine schedulers together. perhaps this was fixed or addressed with later releases.

I will give it a try as it would also help me making less rules with same effect.

URL

David Pritchard ●

Wow. I'd never even thought of doing that. Interesting.

URL

Klaus G ●

Attila,

believe me, the rule with two schedulers runs for quite some time and I think of it as the most reliable rule I have. I just want someting to make sure the switch is in the right state after a reboot.

And the second rule to detect a reboot is also reliable. After each reboot the variable is zero and I get an email. The only problem was, that there seems to be an issue with "Time of now is between sunrise und sunset" Als David suggested, I tried out some this part alone but to no avail. I think thats the reason, I always got the same state after a reboot, regardless of the time of day.

I then tried some old ways I experimented with in the past and this rule (of which I´m sure it didn´t work in the past) now seems to do the trick....

Files:

URL

David Pritchard ●

It's very strange that one works and the other doesn't (although if you go back before 1.0.17 the time of(sunrise/sunset) thing didn't work, you can see it mentioned in the firmware notes). However, I've tried it here and it's apparently still OK, and I'm now on 1.2.20.

URL

Alberto Macias ●

It used to be a problem to use anything else than a scheduler, I had that problem. My way around was to create virtual sensors that turn ON/OFF based on schedulers, and use those instead in the rules.

URL

David Pritchard ●

Klaus, I think it should work. How often does the rule run? Every minute?

Try inserting a delay before calculating the night/day setting. Perhaps immediately after reboot it's still resetting some important parameters.

Also try running the sunset/sunrise check in another rule, outside the context of the reboot, to make sure it's working.

Reply URL

David Pritchard ●

I have a 30-second delay in my reboot detector before I start setting up values. I don't know whether it's strictly necessary - I'd have to do more tests.

Reply URL

Klaus G ●

Hi David,

thank you very much, that was my first approach, too. But I think the problem lies in the "Time of now is between sunrise und sunset" part and I think I will give it a try with my new/old approach as shown in my answer to Attilla. If that works, I´m happy again. There remains only one question: The original rule sets the virtual sensor via those two schedulers to "Daylight" between 30min after sunrise and 30min before sunset.

Could you think of a way to implement that behaviour after a reboot (where one can´t use a scheduler) I think it wouldn´t be a good idea to use a 30min wait after sunrise and I can´t think of a way to do the trick before sunset.)

URL

David Pritchard ●

I'll have to check the sunrise/sunset thing. Time of (now) between time of (sunrise) etc. should work!

URL

Klaus G ●

Thanks a lot. Then I´m going to leave the rule untouched in case it was just a problem after the update. And I forgot to say that I also had a 30 sec. delay inside my original rule. I deleted it, because I saw no effect, even though I feared that the virtual weather station meight take even longer to update the values after a reboot. And my rule to check for a reboot runs every seven minutes because I wanted to separate it from another rule which runs every five minutes ;-)

URL

David Pritchard ●

It seems to be working OK here.

Files:

URL

David Pritchard ●

Klaus, try comparing timeof(sunrise) and timeof(sunset) to 0. They're just numbers really. If they're not working, the obvious conclusion would be that the values are 0!

Alternatively, you can copy those values into variables and send them to yourself in an email. If you use the variable in a rule, it will always appear to be zero, but in the email you can see the real value - weird. As a control, include another variable containing timeof(now).

URL

Alberto Macias ●

You have to use TIME OF NOW BETWEEN TIME OF as you already mentioned. I noticed sometimes this didn't update after a reboot, this sould be related to the update of the service for weather forecast that zipato uses. I went around that with two rules, one that runs immediately after a reboot and the second one runs 5 times after the first one, every minute, this way my virtual sensors are always correct.

Files:

URL

Klaus G ●

@David

Thanks a lot, I will give it a try on the weekend (quite busy right now with my job) Sending variables via email is a quite a lot of work as I do not have a pro licence and I always build very long rules (if var=0 send mail "0", if var=1 send mail "1".... if var=100 send mail "100" and after the last problem has been solved I was so stupid to delete that rule... So I have to build that again and keep it forever or until zipato let us at least see the value of variables....

@Alberto

I think I will rewrite those rules from scratch to make sure they work as expected. And I´m going to add the function which repeats the procedure of setting all virtual switches and sensors after five minutes, too.

I thank you both very much for your help and I hope that one day we are able to see the value of variables in the web UI and perhaps one other day we will have backup as well and for all users.

Klaus

URL

Adrian Van Der Heijden ●

Im with Alberto and Attila, didn't know that multiple Schedulers worked now. I also just use virtual sensors for sunrise/sunset, and variables. Also wasn't aware the between sunrise sunset meters was working. Thanks guys.

To get a variable value, have you tried putting the value into a Virtual meter. These can be viewed in the app easily enough. Haven't tried this,but thought it may work, create a run that runs on any change in the variable and then set the virtual meter to the value of the variable.

URL

David Pritchard ●

Adrian, the problem with viewing time values is that the variables can't hold them properly. So if you put the value in a virtual meter, you get something weird, and in rules the variables behave as if they had the value 0. But if you send the variable to an email, weirdly, you can see the value! Bizarre but apparently true.

URL