Schedules don't trigger handlers after power loss
A schedule that should become active during a power outage doesn't trigger event handlers after the mango is turned on again during the active time, even the schedule turns active on the events list immediately after the startup.
And vice versa, when an active schedule is should become inactive during a power outage, event handlers are not triggered after the mango turn on again during the inactive time, although the schedule becomes inactive, as seen on the events page.
What version of Mango are you using? What event handler type do you have configured? Email?
The event handler type is set point, BACnet in this case, but this behavior is same with virtual data set point event handler.
@nachum37 thanks for making us aware of this, I will take the information you provided here and have our team replicate what is happening so we can fix any problems we find.
This is not on the plans to change this functionality for Mango 4.
A pity, it makes using the mango less reliable for essential applications. Do you have an idea for a workaround?
I second your view. As it is now, Mango can not be used for any building opration
requiring scheduling due to this issue. The whole building will not be restarted after
power has come back.
Are you able to utilize a small UPS backup power supply to ride through outages?
This is what I thought I would do. But then the controllers with the handled setpoints also need to be connected to the UPS, as well as the network switches between them if they are connected over the network. And in a typical installation, with controllers installed on each floor, It can be complicated and expensive to wire all the controllers through UPS, and even a large expensive UPS lasts a limited time.
I was thinking of partly workaround this by placing a single controller next to the mango and connecting both to the UPS, setting all controllers to constantly read the values from that controller. Needless to say, this is not possible in every controller, especially a not programmable one. Still in case of a longer power outage, when the UPS goes out of battery, and meantime the schedule needs to be inactive, for example, and then the power comes back the setpoint will be in the status it was in when the schedule was active because the mango does not trigger the handler when it is turned on.
Another option is to check out what I saw in the forum regards syncing a schedule with a BACnet schedule, although I'm not entirely sure I understood what needed to be done, and whether exceptions also sync, which is essential.
And overall, what if the handler is not a setpoint handler at all? Such as email, etc? UPS will not help in those cases.
Basically, the thing here is an activated schedule triggers the handler only once, at the start time, and not again. For example, someone can accidentally turn off the lights using a wall switch while the schedule is active. To prevent that handler types should be can be configured, only once or repeated, meaning "repeat all the time when the trigger is active", So the lights soon turn on after accidentally manual override (except higher BACnet priority, safety, etc.) or power outage.
This is my first experience with Mango and I hope this issue is resolved so I can use it.
I think the problem is that neither the re-activate nor the active-only-at-the-right-time behaviors are correct for all users in all cases. I guess they could consider providing the event raise / return behavior as an option on the schedule.
You can imagine there are other sorts of toggles that make no sense to happen outside of the exact time. For instance, if the scheduler was making a bell chime for the time of day, surely power loss leading to erroneous chiming is not desirable. Or, if it takes a snapshot of data, it may be more desirable to have a hole to manually fill than to have malformed data appearing to look good.
It's a tough problem to solve for all cases. You can always use a scripting data source to achieve arbitrary scheduling controls and handling of a power loss situation, but it'd take some programming and noodling.
You describe a behavior that is more appropriate for a timer (an event that needs to happen at a specific time).
Schedule means a desirable situation from the activation of the schedule to the end.
Since there are events where a schedule behavior is not appropriate, as you say, i think the better solution is to add a checkbox to the schedule settings to indicate that is a "constant" schedule so even when the schedule is activated after the original start time the event handlers should be triggered.