Below are some examples of interface logic that is recommended when integrating with Event2HVAC. These show different strategies and ideas that you can employ. Obviously, this isn't the only way to do things, but you should consider the best solution for your end-user for overall reliability and ease of use.
Master Building Schedule Logic
Assuming you have master schedules for zones already in place, create logic to switch the master building schedule or "null" based on whether the E2H-S point is active or not. The "E2H_Active" point can be overridden by the user to use default building schedules or Events2HVAC schedules. Note: If you don't want to monitor E2H-S directly, you can use the E2H_Active point as your manual user switchover control and eliminate all the logic upstream of that point.
The output of the boolean switch "Use Backup Schedules" will be connected to the "IN" for each of the zone schedules. Null values on the IN will use the E2H zone schedule. Non-null values on IN will override the E2H zone schedule and pass the result of the master building schedule.
This logic can reside on one Supervisor or shared with multiple stations. You can decide if you want each building controller to be able to switchover independently or if it is done globally from one spot.
Important: There is a 10 min on delay and 15 min off delay when E2H-S changes status or point goes in fault or down. This is to prevent short-cycling equipment occupancy when the Events2HVAC server is restarted or there are intermittent network communication issues. An Events2HVAC restart can take a few seconds, but if it is the first time sending data over to the HVAC side, the event query can take up to 5 minutes (more or less depending on the size of implementation). A typical upgrade of Events2HVAC usually takes less that 15 minutes. Worst case would be going from E2H control (less equipment on) to default building occupancy (all equipment on), so you want to put more of a delay on the "Off Delay".
Using Zone Schedule Objects
Using the Master schedule logic above, each zone would be configured as below:
Zone2 Schedule would contain the exception schedules sent by Events2HVAC and
Zone2 Out would connect to the end device for the zone (e.g. the VAV occupancy CMD).
The building schedule link for the end device occupancy point would need to be removed or the Zone2 Out would need to write to a higher priority than the existing schedule.
Above zone would be schedule in Events2HVAC using a "SendExceptionSchedule" action:
Alternative: Using a Switch to change schedules at each zone
If you aren't using a Master Schedule logic like above, you can insert a boolean switch at each zone like below. However, this requires more control objects per zone.
Using Binary Zone Occupancy Only
If you only want to receive occupancy state commands from Events2HVAC, you can switch your default building schedules by utilizing a boolean switch and the monitored E2H-S point for switchover.
The output of the boolean switch would be connected to your end device occupancy command point. (e.g. VAV occupancy command)
Writing Events2HVAC Occupancy Direct to End Device Points
In this example, you already have default building schedules writing to the end device at priority 14. Export this point to BACnet and in Events2HVAC, write to this point at priority 13 to override the default schedules.
In the event of Events2HVAC disruption, either detect the E2H-S change or on a manual point change, issue a one-shot "null" command to slot 13 to release the E2H command and allow default schedules to be active again. When E2H send the next command after coming back online, priority 13 will take over again.
Note: this won't inhibit Events2HVAC from commanding again so if you want that you'll need to add more logic here.
Events2HVAC BACnet Start/Stop Action definition for above device point.
Related Topics:
0 Comments