The only reason I used the “time” card is that I want the flow to run only in the afternoon. The sun reaches the same altitude twice a day (except at noon). I’ll try the “between” option, since the issue is probably that the flow misses the exact “22” value, but I’ll still have to limit it to afternoon only. I originally avoided the “between” option because I didn’t want the flow repeatedly spamming the blind for all values within the given range. Thanks for the input.
I think the issue is probably that the flow misses the exact “22” value, so sometimes it works and sometimes it doesn’t. I would probably have to be checking every 1 second for that exact value, which feels a bit unnecessary so I’ll try the “between” option as suggested in the other reply. Thanks for you prompt answer.
Ah yes. My bad, I somehow got ‘azimuth’ in my head instead of ‘altitude’.
Hi @MarcelT, have you had a chance to review my query?
I’ve just confirmed that not only do the Times in the app setting span a two calendar day period, but they are updated before all events in that period have occurred.
For example, today the Times have been updated starting from Solar Noon on the 13/02 through to the Morning Golden Hour on the 14/02. However, the update to the Times occurred in the app before the events from at least Dawn through to the Morning Golden Hour ends had occurred on the 13/02.
I assume this isn’t an expected outcome and I’m guessing is the result of a scheduled update (possibly at midnight) to Times based on my timezone (I’m in AUS GMT +11) but the date/time calculated for the events in my location are calculated from GMT +0 and then adjusted to my time zone (i.e. in my location Solar Noon would be the first event to occur after midnight GMT +0).
Can you confirm the above or share what might be causing the issue? Also keen to understand if the bug can be fixed and when.
Thanks.
Hi,
Always difficult time zones. Please could you create a case here: GitHub · Where software is built
Describe the situation clearly and add some pictures that helps me a lot. Then I will work on it in the weekend and see if I can get it solved. I know we talked before but I can not recall it exactly.
I think a bug has crept in with the latest update. Circadian level is not updated. When restarting the app, I get the message that it is not installed.
You mean the 3.0.3 release? Could you create a bug on github and of possible logging / screenshot 's? Thanks
It is indeed 3.0.3. I just happened to restart the Homey. That seems to have helped. I’ll see that tomorrow.
This a known issue where i have created a case several years back at homey. Vars as parameter seems not to work (always). I am not sure if it is fixed and i need to change my code but i havent heard back from them. Even after several reminders.
Case at homey: Tag is value is not available as argument in trigger · Issue #204 · athombv/homey-apps-sdk-issues · GitHub
Hi is anybody facing the same issue?
After updating to version 3.1.1, my existing flows started being disabled with the following error message:
XY has been disabled, because the Flow executed too many times (homey:app:com.cyclone-software.sunevents:azimuth_change).
I created a bug ticket: Azimuth change executed too many times error · Issue #125 · magtimmermans/com.cyclone-software.sunevents · GitHub
Thank you
Heszi
Yeah i have the same problem.
Hi, I have the same problem as you
Could you please check the test version? Link on github.
Hello @MarcelT same issue still is happening since v3.1.1 and now in v3.1.2, my flows are getting disabled with the message: “flow x” has been disabled, because the Flow executed too many times (homey:app:com.cyclone-software.sunevents:azimuth_change).
Version 3.1.3 is underway (available in test) and should fix this issue. (At least at my place it is working)
Yes so far so good with the test version. Big thank you.
