Reactor goes crazy as dusk is at 7am?

I have a strange problem where sometimes my automation gets messed up. Today, for example the “civil dusk” happened at 07:07:43 and triggered the stuff which should happen later in the day.

As per Reactor plugin, sundata says dawn should be at 1652211462 (10 May 2022 19:37:42).
If I convert the time it actually triggered, it says 1652166463 (10 May 2022 07:07:43)

The difference is 44999 seconds… Is that off any meaning? Basically 45000 seconds…?

The plugin has not restarted since a few days and is “stable”. I had to set up some special rules and automation which is switching off devices if they come on when they are not supposed to. I thought it is related to one single outdoor device (I thought a buggy zwave module) but now I have seen that dusk appeared to be in the morning. So I am not so sure anymore about the device and suspect Reactor is buggy?
Location is remote and I can´t check daily what is happening. I will have to add a more “self-checks”?

In the logic summary you sent me via email for Reactor Sensor 1, although the group name/comment is “30 minutes before civil Sunrise”, your actual condition says “AFTER sunrise - 30” – that’s conflicting/seems incorrect, seems like you mean BEFORE in the condition there, and that would definitely make the logic unpredictable. You have the same lower down under “30m vor Sonnenuntergang”… an AFTER in the condition that seems like you meant to use BEFORE.

I recommend you audit all of your logic carefully and make sure your conditions have the correct operators for the intent.

All the sunrise and sunset times are correct in the logic summary for the time it was taken, and the inidividual logic states shown are also correct given the conditions.

Hi there, thanks for the reply.
I had now time to sit down with a beer and have a look at it. I can´t agree with you though.
I have not changed the logic conditions, just renamed them to English with a better word choice.

The first condition is supposed to go TRUE after/“at” (as we don´t have an “at”) the point in time, when we are 30 minutes away to civil dawn. This means if civil dawn is at 07:00:00AM, I am expecting this to be 06:30:00AM.
The second condition is supposed to go TRUE after/“at” (as we don´t have an “at”) the point in time, 30 minutes have passed since sunrise. This means, if sunrise is at 07:45:00AM, I am expecting this to be 08:15:00AM.
As civil dawn is always before sunrise, both time conditions can´t overlap (before civil dawn, after sunrise) .

Or am I using the + and - wrong in the offsets?

I have to admit that the 45´000 seconds was longshot and probably by coincident, not relevant. I probably also made a mistake there with the UTC offsets, disregard it.

If there was a bug in sunrise/sunset in this version of Reactor, I suspect more people than just you would have raised the issue, in the more than 15 months since this version’s release. It’s always possible, but the complexity of this Reactor Sensor (18 conditions not shown in your post, and a large number of inter-connected activities) as shown by the Logic Summary makes me suspicious that you have a logic error. The contents of the Logic Summary posted, as I said, are pointing to Reactor having correct astro times and responding correctly for the time and conditions given.

As for the time stamps in your original post, the 19:05:58 is the time of day at the moment the condition was last evaluated. That can be any time, and with an RS as complex as what you have, any related/watched device changing state or any of the other 18 conditions triggering a re-evaluation will cause all of the conditions in the Reactor Sensor to be re-evaluated/examined, and all the present-time values on date/time conditions will move to reflect that moment. The “as of 07:07:43” is the moment the condition last changed state, and that could simply be caused by you editing the Reactor Sensor (which shows nearly 100 edits as of the Logic Summary sent), or resetting it or enabling/disabling it, any of which would cause the state to be erased and recomputed, so that time would merely be the time you last hit “save” or “reset” or “enable”. In order to get real time “as of” stamps, you would need to stop editing this Reactor Sensor and just let it run for full day, uninterrupted and without edits, resets, or enable/disable of the RS.

If you are convinced that civil dawn/dusk is not operating correctly, you’ll need to make a smaller test case to show the problem. Make a Reactor Sensor like this (and nothing else), and do not edit it for at least 24 hours. If something goes wrong, do not make any changes, just go to the Tools tab for the test RS and grab the Logic Summary and post it here.

Make sure it’s enabled. The initial state will be based on your current time (again as of when you hit the save button), so you will have to roll over midnight to really begin the real test. At midnight your local time, all conditions will go false. Based on current conditions for your location, the first condition should go true at about 4:47am your local time, the second one hour later, and both remain true all day. The third will go true at about 9:10pm your local time, and the fourth one hour later, and also remain true until midnight. All times are estimates for your location, but should be within a few minutes. At midnight, all conditions will again reset to false. This RS should be left undisturbed (no edits, resets, etc.) for at least a full cycle (midnight to midnight).

I have completely re-done this sensor from the ground up and changed some triggers. Seems okay now, most probably it was a logic mistake.

1 Like

Best Home Automation shopping experience. Shop at getvera!

© 2021 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules