Loading ...
Sorry, an error occurred while loading the content.

RE: [BACnetLighting] BACnet lighting output: Long fades and ramps

Expand Messages
  • David Ritter
    Thanks for the response Steve, That likely is a reasonable response to the problem and takes the burden away from us to handle such a use case. We should put
    Message 1 of 3 , Feb 21 3:44 PM
    • 0 Attachment
      Thanks for the response Steve,

      That likely is a reasonable response to the problem and takes the burden away from us to handle such a use case. We should put it on the list to discuss on a telco or face to face meeting.

      Best Regards,

      David

      -----Original Message-----
      From: Steve Karg [mailto:steve@...]
      Sent: Monday, February 21, 2011 2:51 PM
      To: BACnetLighting@yahoogroups.com
      Cc: David Ritter
      Subject: Re: [BACnetLighting] BACnet lighting output: Long fades and ramps

      Hi Dave,

      I've thought about the long fade problem, and perhaps the solution is this:

      One reason the Lighting Output object is handling fades and ramps is
      that that type of control would consume large amount of network
      bandwidth, or may not be possible due to limited network bandwidth.
      For long fades or ramps, bandwidth is no longer the issue. Therefore,
      the light level can be controlled by an external algorithm directly
      writing to the Present_Value.

      Best Regards,

      Steve

      On Thu, Feb 17, 2011 at 2:06 PM, David Ritter <dritter@...> wrote:
      >
      >
      >
      > Hi BACneteers,
      >
      >
      >
      > One of the use cases that we've talked about in the lighting working group meetings is how certain applications use long fade or ramp times. These can be used to simulate sunrise or sunset for animal or other light sensitive habitats. In this case the fade or ramp occurs over many minutes or hours not seconds.
      >
      >
      >
      > Glen Nichols has also pointed out another use case for long fades whereby the lights are turned on to a bright level at the beginning of the day and then gradually dimmed to save energy. Apparently our eyes adjust and the gradual reduction in light output is imperceptible.
      >
      >
      >
      > However, long fades and ramps are not well suited to the current BACnet lighting output object as specified in addendum i:
      >
      >
      >
      > 1.       A lighting command that is written at a higher priority will cancel any current fade or ramp in progress. When the fade or ramp operation is cancelled at a specific priority and that priority slot becomes the highest again the result is the lighting output will be set to the target value of the fade. This works for short fade times but imagine a long fade scenario where the lights are overridden at a higher priority (either on or off) for a short period of time (e.g., maintenance is required in the animal habitat for 5 minutes). After the override has relinquished it may be reasonable to expect that the long fade would continue but that is not the case.
      >
      > 2.       Similar to the first issue is when a long fade is received by the lighting output object but it is not the highest priority. In this case the fade will never be started. When the slot where the fade was commanded becomes the highest priority the light level will go directly to the target level. Again this may be reasonable functionality for a short fade but may not be expected behavior for a long fade.
      >
      > 3.       When a fade or ramp operation is received at a specific priority the target value is written to the corresponding slot in the priority array and the fade or ramp happens behind the scenes. The priority array and the present value will only show the target value and not the current value. It may be confusing to see that the present value is set to a specific level (i.e., 100%) but the physical lighting output is nowhere near that level (i.e., 5%) and may not be for a long time. To see the current value of the fade you need to look at the tracking value. Again, this method works well for short fade times but not necessarily for long fades.
      >
      >
      >
      > So the question is whether or not we need to make changes to accommodate long fades and ramps or whether we can live with the limitations.
      >
      >
      >
      > Comments?
      >
      >
      >
      > David
      >
      >
      >
      >
      >
      >


      --
      http://steve.kargs.net/
    Your message has been successfully submitted and would be delivered to recipients shortly.