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

Re: [ukusa_gateway] Actions based on level change of group

Expand Messages
  • Kevin Hawkins
    ... A scene on C-Bus is a collection of several groups that each independently have a level and ramp rate associated with them. As such the concept of dimming
    Message 1 of 7 , Jan 3, 2009
    View Source
    • 0 Attachment
      Paul Gale wrote:
      >
      > Does what I want to achieve make sense?
      >
      A scene on C-Bus is a collection of several groups that each
      independently have a level and ramp rate associated with them. As such
      the concept of dimming a scene doesn't sit naturally as members of the
      scene may be at different levels (even off).. Indeed on the trigger
      group a scene is triggered by that group being set to a specific
      level. That's not to say you can't use level changes on a group and
      apply them to a scene but it requires some interpretation. The
      normal/obvious one is that a scene at 50% level would set each member of
      the scene to 50% of the normal level that it would be on at normally.
      The ramp rates are normally maintained at the standard scene settings.
      Only some C-Bus devices can dim scenes.

      There's a problem though in that you said "HV do some clever stuff based
      on time of day, alarm state (eg night mode) etc etc." - which I take to
      mean that when you set specific levels eg level 128 that the scene
      behaves differently ie its not just a half brightness scene. ie really
      you're trying to use one button to be able to do upto 256 different
      things..... If so you couldn't use the C-Bus inbuilt dimmable scenes.

      One reason is that the results seen on C-Bus would not be inline with
      what C-Bus might be expecting - eg if it tried to set a scene at 50%
      brightness but you suceeded in modifying this then there are fairly
      sophisticated self reconciling aspects of C-Bus that might kick in and
      try and resolve/correct this. Actually I don't think they would but
      it's a possibility. Another possible problem is that as you started to
      traverse the dim level range - assuming you had a C-Bus implemented
      dimmable scene then it might provide realtime reaction yet you would
      only be using this to get to a specific level that actioned some other ,
      possibly totally unrelated change.
      > I really don't want to do it in a xAP app if possible - like you, I'd rather do anything concerned with lighting etc in hardware.
      >
      There's a point at which certain levels of sophistication are really
      only achievable in software as the complexity in configuring the
      permutations mean it can't be accomodated nicely in the limited hardware
      environment. In a software app you effectively have infinite storage
      resource and a great UI for configuration plus a near unlimited
      scripting environment.

      One thing you could perhaps do is have a member of the scene that was
      virtual and set to the scene level - and then maybe a later member that
      toggled or pulsed (somehow) then when the later member toggled the
      earlier member would already be set to the new level. From HV the
      actions would be triggered and you could do whatever you wanted based on
      testing the virtuals level.

      Also C-Bus relays can have threshold on/off levels set so you could have
      a number of these configured that actually did turn on/off as the level
      moved between different values in the range 0-255.
      > Re the slower level changes etc - I don't (think!) I'm at all interested in changing a scene from a CB group level change that hasn't originated from a DLT or other switch input. At least, I've not thought of a situation yet where that would be useful. In my example, I'd just want to very occasionally set the CB group level on the DLT and have HV set all the actual light levels and do some other stuff.
      >
      In a way you would be able to do this currently via xAP but not sure
      about HV though. The reason is that xAP interprets level and state
      (on/off) independently and so a device could be OFF at level 123 or
      indeed ON at level 0. So if the DLT toggled on/off a group the current
      level would be retained and the on/off macro would fire and the level ,
      as set on DLT, could be used in the macro for testing (maybe). However
      IIRC HV custom lighting always treats OFF as level 0 ...

      I'll investigate a bit... Itmay be possible to somehow inform you of a
      level change in a group in a way that triggered a macro. Maybe I could
      have a specifically named macro 'xLevelChange' that ran whenever a level
      changed and I could prefill a named HV variable 'xGroupNumber'with the
      number of the group that had changed. Coincident level changes would
      cause issues though, and would certainly delay HV reactions. Is this an
      acceptable compromise (HV reacting slower ?)
      > Now, thinking about it, obviously HV won't give me real-time feedback, so maybe this wouldn't be as useable as a CB dimmable scene? I guess most users would expect instant feedback on a dimmer?
      >
      Absolutely - and it creates other issues - in that when things don't
      respond instantly users tend to press again, and again and you get a
      very frustrating result of things continually changing or looping in
      unexpected ways. Both the HV serial interface , and the C-Bus PCI are
      bottlenecks in both directions so I would try and stick with C-Bus
      dimmable scenes for any realtime feedback.

      > I guess another way to achieve a more basic version of this is to have a bell push key setup on the DLT and have HV cycle through several different combinations of levels in the scene.
      >

      Possible... and you might be able to have some preloaded labels for
      each of those states to cycle through - if you were prepared to update
      them via xAP. Preloaded lables don't cause wear on the DLT's memory.

      K
      > Thanks,
      >
      > Paul.
      >
      >
      >> -----Original Message-----
      >> From: ukusa_gateway@yahoogroups.com
      >> [mailto:ukusa_gateway@yahoogroups.com] On Behalf Of Kevin Hawkins
      >> Sent: 30 December 2008 14:30
      >> To: ukusa_gateway@yahoogroups.com
      >> Subject: Re: [ukusa_gateway] Actions based on level change of group
      >>
      >> No you can't currently do this as HomeVision only triggers actions
      >> based
      >> on on/off changes. Although a lamp can be off at a level eg off at 50%.
      >> There is a way if you use a xAP capable HA application (see end))
      >>
      >> I'm not sure what the advantage is over just setting a group on or off
      >> ?
      >> I realise you need more groups this way but there are plenty, also the
      >> LED indicators work correctly. Convince me it's a desireable feature ;-
      >> )
      >> BTW do you mean groups in the lighting application or the trigger
      >> application ?
      >>
      >> There are several issues..
      >>
      >> The main one is that sending/checking all the group levels can be very
      >> bandwidth heavy on the realtively slow HomeVision serial interface
      >> leading to delays in things happening.
      >>
      >> The action screens in HV or HVXL do not have a place to enter levels
      >> and
      >> there is only one action per group address. This makes the setup of
      >> such
      >> things complex and confusing.
      >>
      >> Triggering the action on every level change means every action macro
      >> has
      >> to check and decide whether it should run based on previous and current
      >> level. To do this you need to have previous level stored somewhere and
      >> it makes macros very long. A way to enable level triggers on a per
      >> group
      >> basis is also needed so that people wanting the normal on/off behaviour
      >> don't get triggers on level changes.
      >>
      >> Also consider a trigger based on say level 200. Should a lamp dimming
      >> from 210 to 190 over say 30 seconds trigger such an action ? In
      >> actuality the HV custom lighting level is set to 190 instantly at the
      >> start so it wouldn't. Supplying intermediate levels to HV would be very
      >> intensive - on a dim from 255 to 0 over a few secs then 256 different
      >> levels would have to be transferred realtime which is not possible.
      >>
      >> It may be that there is some sort of workaround for this in a future
      >> version but the way I tried it before (trigger on every change and
      >> supply old/new dim levels to teh macro) was complicated and wasn't
      >> going
      >> to be very useful. It may need some front end support within HVXL which
      >> Schelte might consider but the standard HV app wouldn't
      >> offer.
      >>
      >> You can already accomplish this using any xAP capable scripting
      >> application. You would trigger a script based on the level change and
      >> then send a xAP command to force run a suitable macro on HV.
      >>
      >> K
      >>
      >>
      >>
      >>
      >> Paul Gale wrote:
      >>
      >>> Kevin,
      >>> I think this isn’t possible but wanted to check…
      >>> I’d like to setup an intelligent scene using a single CB group and
      >>> dimmer button on a DLT. The idea is that I can set a level on the
      >>> button and HV would interpret that level and set a number of lights,
      >>> LEDs and other devices to a certain level. This level may also be
      >>> based on time of day, alarm state etc etc.
      >>> My understanding is that HV won’t currently trigger an action based
      >>>
      >> on
      >>
      >>> a level change, only an on/off. Is this correct?
      >>> Is there a way to make this work? I’d love to be able to set a number
      >>> of these intelligent scenes around the house.
      >>> Thanks,
      >>> Paul.
      >>> __________ Information from ESET NOD32 Antivirus, version of virus
      >>> signature database 3723 (20081230) __________
      >>> The message was checked by ESET NOD32 Antivirus.
      >>> http://www.eset.com
      >>>
      >>>
      >> ------------------------------------
      >>
      >> Yahoo! Groups Links
      >>
      >>
      >>
      >>
      >>
      >> __________ Information from ESET NOD32 Antivirus, version of virus
      >> signature database 3723 (20081230) __________
      >>
      >> The message was checked by ESET NOD32 Antivirus.
      >>
      >> http://www.eset.com
      >>
      >>
      >
      >
      > __________ Information from ESET NOD32 Antivirus, version of virus signature database 3723 (20081230) __________
      >
      > The message was checked by ESET NOD32 Antivirus.
      >
      > http://www.eset.com
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
    • Paul Gale
      Thanks for the reply Kevin, I m going to have to sit down and consider it carefully over the next few days. One question for now though - you mentioned HV
      Message 2 of 7 , Jan 3, 2009
      View Source
      • 0 Attachment
        Thanks for the reply Kevin,

        I'm going to have to sit down and consider it carefully over the next few days.

        One question for now though - you mentioned HV possibly reacting slower with the possible CB group level reporting and macro triggering - any ideas what the worst case could be or is this dependent on how many groups change in a small period of time? I don't currently have much going on in HV each loop but not sure how much processor capacity is left?

        Paul.

        > -----Original Message-----
        > From: ukusa_gateway@yahoogroups.com
        > [mailto:ukusa_gateway@yahoogroups.com] On Behalf Of Kevin Hawkins
        > Sent: 03 January 2009 12:34
        > To: ukusa_gateway@yahoogroups.com
        > Subject: Re: [ukusa_gateway] Actions based on level change of group
        >
        > Paul Gale wrote:
        > >
        > > Does what I want to achieve make sense?
        > >
        > A scene on C-Bus is a collection of several groups that each
        > independently have a level and ramp rate associated with them. As such
        > the concept of dimming a scene doesn't sit naturally as members of the
        > scene may be at different levels (even off).. Indeed on the trigger
        > group a scene is triggered by that group being set to a specific
        > level. That's not to say you can't use level changes on a group and
        > apply them to a scene but it requires some interpretation. The
        > normal/obvious one is that a scene at 50% level would set each member
        > of
        > the scene to 50% of the normal level that it would be on at normally.
        > The ramp rates are normally maintained at the standard scene settings.
        > Only some C-Bus devices can dim scenes.
        >
        > There's a problem though in that you said "HV do some clever stuff
        > based
        > on time of day, alarm state (eg night mode) etc etc." - which I take to
        > mean that when you set specific levels eg level 128 that the scene
        > behaves differently ie its not just a half brightness scene. ie
        > really
        > you're trying to use one button to be able to do upto 256 different
        > things..... If so you couldn't use the C-Bus inbuilt dimmable scenes.
        >
        > One reason is that the results seen on C-Bus would not be inline with
        > what C-Bus might be expecting - eg if it tried to set a scene at 50%
        > brightness but you suceeded in modifying this then there are fairly
        > sophisticated self reconciling aspects of C-Bus that might kick in and
        > try and resolve/correct this. Actually I don't think they would but
        > it's a possibility. Another possible problem is that as you started to
        > traverse the dim level range - assuming you had a C-Bus implemented
        > dimmable scene then it might provide realtime reaction yet you would
        > only be using this to get to a specific level that actioned some other
        > ,
        > possibly totally unrelated change.
        > > I really don't want to do it in a xAP app if possible - like you, I'd
        > rather do anything concerned with lighting etc in hardware.
        > >
        > There's a point at which certain levels of sophistication are really
        > only achievable in software as the complexity in configuring the
        > permutations mean it can't be accomodated nicely in the limited
        > hardware
        > environment. In a software app you effectively have infinite storage
        > resource and a great UI for configuration plus a near unlimited
        > scripting environment.
        >
        > One thing you could perhaps do is have a member of the scene that was
        > virtual and set to the scene level - and then maybe a later member that
        > toggled or pulsed (somehow) then when the later member toggled the
        > earlier member would already be set to the new level. From HV the
        > actions would be triggered and you could do whatever you wanted based
        > on
        > testing the virtuals level.
        >
        > Also C-Bus relays can have threshold on/off levels set so you could
        > have
        > a number of these configured that actually did turn on/off as the level
        > moved between different values in the range 0-255.
        > > Re the slower level changes etc - I don't (think!) I'm at all
        > interested in changing a scene from a CB group level change that hasn't
        > originated from a DLT or other switch input. At least, I've not thought
        > of a situation yet where that would be useful. In my example, I'd just
        > want to very occasionally set the CB group level on the DLT and have HV
        > set all the actual light levels and do some other stuff.
        > >
        > In a way you would be able to do this currently via xAP but not sure
        > about HV though. The reason is that xAP interprets level and state
        > (on/off) independently and so a device could be OFF at level 123 or
        > indeed ON at level 0. So if the DLT toggled on/off a group the
        > current
        > level would be retained and the on/off macro would fire and the level ,
        > as set on DLT, could be used in the macro for testing (maybe).
        > However
        > IIRC HV custom lighting always treats OFF as level 0 ...
        >
        > I'll investigate a bit... Itmay be possible to somehow inform you of a
        > level change in a group in a way that triggered a macro. Maybe I could
        > have a specifically named macro 'xLevelChange' that ran whenever a
        > level
        > changed and I could prefill a named HV variable 'xGroupNumber'with the
        > number of the group that had changed. Coincident level changes would
        > cause issues though, and would certainly delay HV reactions. Is this an
        > acceptable compromise (HV reacting slower ?)
        > > Now, thinking about it, obviously HV won't give me real-time
        > feedback, so maybe this wouldn't be as useable as a CB dimmable scene?
        > I guess most users would expect instant feedback on a dimmer?
        > >
        > Absolutely - and it creates other issues - in that when things don't
        > respond instantly users tend to press again, and again and you get a
        > very frustrating result of things continually changing or looping in
        > unexpected ways. Both the HV serial interface , and the C-Bus PCI are
        > bottlenecks in both directions so I would try and stick with C-Bus
        > dimmable scenes for any realtime feedback.
        >
        > > I guess another way to achieve a more basic version of this is to
        > have a bell push key setup on the DLT and have HV cycle through several
        > different combinations of levels in the scene.
        > >
        >
        > Possible... and you might be able to have some preloaded labels for
        > each of those states to cycle through - if you were prepared to update
        > them via xAP. Preloaded lables don't cause wear on the DLT's memory.
        >
        > K
        > > Thanks,
        > >
        > > Paul.
        > >
        > >
        > >> -----Original Message-----
        > >> From: ukusa_gateway@yahoogroups.com
        > >> [mailto:ukusa_gateway@yahoogroups.com] On Behalf Of Kevin Hawkins
        > >> Sent: 30 December 2008 14:30
        > >> To: ukusa_gateway@yahoogroups.com
        > >> Subject: Re: [ukusa_gateway] Actions based on level change of group
        > >>
        > >> No you can't currently do this as HomeVision only triggers actions
        > >> based
        > >> on on/off changes. Although a lamp can be off at a level eg off at
        > 50%.
        > >> There is a way if you use a xAP capable HA application (see end))
        > >>
        > >> I'm not sure what the advantage is over just setting a group on or
        > off
        > >> ?
        > >> I realise you need more groups this way but there are plenty, also
        > the
        > >> LED indicators work correctly. Convince me it's a desireable feature
        > ;-
        > >> )
        > >> BTW do you mean groups in the lighting application or the trigger
        > >> application ?
        > >>
        > >> There are several issues..
        > >>
        > >> The main one is that sending/checking all the group levels can be
        > very
        > >> bandwidth heavy on the realtively slow HomeVision serial interface
        > >> leading to delays in things happening.
        > >>
        > >> The action screens in HV or HVXL do not have a place to enter levels
        > >> and
        > >> there is only one action per group address. This makes the setup of
        > >> such
        > >> things complex and confusing.
        > >>
        > >> Triggering the action on every level change means every action macro
        > >> has
        > >> to check and decide whether it should run based on previous and
        > current
        > >> level. To do this you need to have previous level stored somewhere
        > and
        > >> it makes macros very long. A way to enable level triggers on a per
        > >> group
        > >> basis is also needed so that people wanting the normal on/off
        > behaviour
        > >> don't get triggers on level changes.
        > >>
        > >> Also consider a trigger based on say level 200. Should a lamp
        > dimming
        > >> from 210 to 190 over say 30 seconds trigger such an action ? In
        > >> actuality the HV custom lighting level is set to 190 instantly at
        > the
        > >> start so it wouldn't. Supplying intermediate levels to HV would be
        > very
        > >> intensive - on a dim from 255 to 0 over a few secs then 256
        > different
        > >> levels would have to be transferred realtime which is not possible.
        > >>
        > >> It may be that there is some sort of workaround for this in a future
        > >> version but the way I tried it before (trigger on every change and
        > >> supply old/new dim levels to teh macro) was complicated and wasn't
        > >> going
        > >> to be very useful. It may need some front end support within HVXL
        > which
        > >> Schelte might consider but the standard HV app wouldn't
        > >> offer.
        > >>
        > >> You can already accomplish this using any xAP capable scripting
        > >> application. You would trigger a script based on the level change
        > and
        > >> then send a xAP command to force run a suitable macro on HV.
        > >>
        > >> K
        > >>
        > >>
        > >>
        > >>
        > >> Paul Gale wrote:
        > >>
        > >>> Kevin,
        > >>> I think this isn’t possible but wanted to check…
        > >>> I’d like to setup an intelligent scene using a single CB group and
        > >>> dimmer button on a DLT. The idea is that I can set a level on the
        > >>> button and HV would interpret that level and set a number of
        > lights,
        > >>> LEDs and other devices to a certain level. This level may also be
        > >>> based on time of day, alarm state etc etc.
        > >>> My understanding is that HV won’t currently trigger an action based
        > >>>
        > >> on
        > >>
        > >>> a level change, only an on/off. Is this correct?
        > >>> Is there a way to make this work? I’d love to be able to set a
        > number
        > >>> of these intelligent scenes around the house.
        > >>> Thanks,
        > >>> Paul.
        > >>> __________ Information from ESET NOD32 Antivirus, version of virus
        > >>> signature database 3723 (20081230) __________
        > >>> The message was checked by ESET NOD32 Antivirus.
        > >>> http://www.eset.com
        > >>>
        > >>>
        > >> ------------------------------------
        > >>
        > >> Yahoo! Groups Links
        > >>
        > >>
        > >>
        > >>
        > >>
        > >> __________ Information from ESET NOD32 Antivirus, version of virus
        > >> signature database 3723 (20081230) __________
        > >>
        > >> The message was checked by ESET NOD32 Antivirus.
        > >>
        > >> http://www.eset.com
        > >>
        > >>
        > >
        > >
        > > __________ Information from ESET NOD32 Antivirus, version of virus
        > signature database 3723 (20081230) __________
        > >
        > > The message was checked by ESET NOD32 Antivirus.
        > >
        > > http://www.eset.com
        > >
        > >
        > > ------------------------------------
        > >
        > > Yahoo! Groups Links
        > >
        > >
        > >
        > >
        > >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        > __________ Information from ESET NOD32 Antivirus, version of virus
        > signature database 3733 (20090102) __________
        >
        > The message was checked by ESET NOD32 Antivirus.
        >
        > http://www.eset.com
        >


        __________ Information from ESET NOD32 Antivirus, version of virus signature database 3733 (20090102) __________

        The message was checked by ESET NOD32 Antivirus.

        http://www.eset.com
      • Kevin Hawkins
        Yes The response time decrease will be directly proportional to the the number of levels that change..and is likely to be three to fourfold (see below) but
        Message 3 of 7 , Jan 3, 2009
        View Source
        • 0 Attachment
          Yes The response time decrease will be directly proportional to the the
          number of levels that change..and is likely to be three to fourfold (see
          below) but would only be apparent if there was a trigger/response
          situation. Also bear in mind that a threefold increase on something
          very small is still small so it may be acceptable. Later changes would
          be delayed more than earlier ones ie if 5 levels (group1-5) changed then
          group 1 would trigger its responses much faster than level 3 which in
          turn would be faster then group 5.

          Re processing - then normally HV will be very lightly loaded so you
          won't be taxing it in that respect. However if you run anything 'every
          loop' then it can dramatically effect the performance. Inparticular if
          you change anything - eg a variable or flag and you have serial
          reporting enabled for this object type then you have dire results that
          get worse with the more of these types of objects you have in your
          schedules. Avoid this !

          This is because HV does not just report the one value that changed but
          all of the object values for this type - and has to do this over the
          slow serial interface(s) - every loop ! With a gateway and HVXL atatched
          it has to do this on two serial interfaces... If you had 100 variables
          and change one then 100 variables are reported twice - worse still which
          one(s) have changed are't identified so the gateway has to check each
          value independently against the last known value. Very laborious. If
          you do turn off reporting of a specific object type then this is avoided
          but the gateway can no longer track these and so that object type is not
          maintained on xAP. This may not be a worry to most users however. In
          general turn off the object reporting if you don't need it.

          ....
          Here's the nitty gritty, based on my experience in trying to add such a
          feature last time...... if anyones interested... ;-)


          At the moment I update each custom light in HV every time it changes on
          C-Bus. This takes one command, or two if an on/off action macro is
          required to be run. If I trigger a level chnage macro it will
          triple/double this as I have to populate the group number to a variable
          and then always run the 'level changed' macro. Of course if you didn't
          create such a macro then the gateway would know this and so this
          wouldn't impact existing users. HV will also report a macro running as
          an event out its serial interface. So at best it would halve the speed
          of respone and more likley reduce it by two thirds. What this actually
          means in practice is less defineable as doubling something that is near
          instant doesn't impact too much.

          . A lot is also to do with what happens in your macros as obviously
          these take time to run. Currently the response time assuming no macro
          runs is pretty fast - let's guess it as 1/10th second roundtrip which is
          not too far out , this covers forming the message within the gateway,
          sending it on the serial interface (the slow bit), actioning it in HV,
          sending the acknowledge back to the gateway (slowish) ..so it would drop
          to 300ms.

          Now (worst case ish) let's assume a macro takes 100ms to run and 5
          groups change level. There isn't an on/off action for any group
          involved but there is the level change and variable update for every
          group of course. So the time for all groups to be actioned would be
          500ms normally and 2000ms (two seconds) ie a x 4 increase. Note this
          time only impacts the later groups really as each group is being updated
          along the timeline. Also unless your updating something , as a result
          of this then actually this time is of no concern as there isn't a
          trigger/reponse apparent.

          If in any of your macros you change a C-Bus group (which I'm guessing is
          the purpose) that will mean the serial commands to accomplish that have
          to be sent from HV to the gateway - and translated to the CB protocol
          and then moved on to the PCI and then from the PCI to C-Bus . There is
          the added complication that should these result in a group level change,
          as they likley will, should this then be reported back to the
          'LevelChange' macro and it be retriggered ? (HV doesn't do this on
          state changes for actions so I think the answer is no, which is also the
          easiest and safest in avoiding loops).

          Another nasty - Macros are not re-entrant - meaning that if one is
          running then the macro can't run again until the first one finishes .
          When I say can't I mean mustn't so the gateway will have to protect
          against that within the LevelChange macro by waiting for the macro to
          finish before the next level is transferred to to HV. I am not sure HV
          can even inform me when it finishes running a macro (cf starting) so you
          may have to send a serial command at the end of the LevelChange macro to
          let the gateway know..... - so you get the below sequence which is lots
          of steps with delays compared to the just send 5 custom light updates
          with acks to HV.

          [5 levels change]

          >> group 1 state and level transferred to HV
          << wait ack
          update level variable
          <<wait ack
          >> run LevelChange Macro
          << wait ack
          ..wait/check for macro complete
          <completed

          Then back to top for next group etc (loops 5 times)

          Once again something that seems easy has some ramifications that only
          become apparent when you try and implement it.

          I too will give this some more thought though...

          K



          Paul Gale wrote:
          > Thanks for the reply Kevin,
          >
          > I'm going to have to sit down and consider it carefully over the next few days.
          >
          > One question for now though - you mentioned HV possibly reacting slower with the possible CB group level reporting and macro triggering - any ideas what the worst case could be or is this dependent on how many groups change in a small period of time? I don't currently have much going on in HV each loop but not sure how much processor capacity is left?
          >
          > Paul.
          >
          >
          >> -----Original Message-----
          >> From: ukusa_gateway@yahoogroups.com
          >> [mailto:ukusa_gateway@yahoogroups.com] On Behalf Of Kevin Hawkins
          >> Sent: 03 January 2009 12:34
          >> To: ukusa_gateway@yahoogroups.com
          >> Subject: Re: [ukusa_gateway] Actions based on level change of group
          >>
          >> Paul Gale wrote:
          >>
          >>> Does what I want to achieve make sense?
          >>>
          >>>
          >> A scene on C-Bus is a collection of several groups that each
          >> independently have a level and ramp rate associated with them. As such
          >> the concept of dimming a scene doesn't sit naturally as members of the
          >> scene may be at different levels (even off).. Indeed on the trigger
          >> group a scene is triggered by that group being set to a specific
          >> level. That's not to say you can't use level changes on a group and
          >> apply them to a scene but it requires some interpretation. The
          >> normal/obvious one is that a scene at 50% level would set each member
          >> of
          >> the scene to 50% of the normal level that it would be on at normally.
          >> The ramp rates are normally maintained at the standard scene settings.
          >> Only some C-Bus devices can dim scenes.
          >>
          >> There's a problem though in that you said "HV do some clever stuff
          >> based
          >> on time of day, alarm state (eg night mode) etc etc." - which I take to
          >> mean that when you set specific levels eg level 128 that the scene
          >> behaves differently ie its not just a half brightness scene. ie
          >> really
          >> you're trying to use one button to be able to do upto 256 different
          >> things..... If so you couldn't use the C-Bus inbuilt dimmable scenes.
          >>
          >> One reason is that the results seen on C-Bus would not be inline with
          >> what C-Bus might be expecting - eg if it tried to set a scene at 50%
          >> brightness but you suceeded in modifying this then there are fairly
          >> sophisticated self reconciling aspects of C-Bus that might kick in and
          >> try and resolve/correct this. Actually I don't think they would but
          >> it's a possibility. Another possible problem is that as you started to
          >> traverse the dim level range - assuming you had a C-Bus implemented
          >> dimmable scene then it might provide realtime reaction yet you would
          >> only be using this to get to a specific level that actioned some other
          >> ,
          >> possibly totally unrelated change.
          >>
          >>> I really don't want to do it in a xAP app if possible - like you, I'd
          >>>
          >> rather do anything concerned with lighting etc in hardware.
          >>
          >> There's a point at which certain levels of sophistication are really
          >> only achievable in software as the complexity in configuring the
          >> permutations mean it can't be accomodated nicely in the limited
          >> hardware
          >> environment. In a software app you effectively have infinite storage
          >> resource and a great UI for configuration plus a near unlimited
          >> scripting environment.
          >>
          >> One thing you could perhaps do is have a member of the scene that was
          >> virtual and set to the scene level - and then maybe a later member that
          >> toggled or pulsed (somehow) then when the later member toggled the
          >> earlier member would already be set to the new level. From HV the
          >> actions would be triggered and you could do whatever you wanted based
          >> on
          >> testing the virtuals level.
          >>
          >> Also C-Bus relays can have threshold on/off levels set so you could
          >> have
          >> a number of these configured that actually did turn on/off as the level
          >> moved between different values in the range 0-255.
          >>
          >>> Re the slower level changes etc - I don't (think!) I'm at all
          >>>
          >> interested in changing a scene from a CB group level change that hasn't
          >> originated from a DLT or other switch input. At least, I've not thought
          >> of a situation yet where that would be useful. In my example, I'd just
          >> want to very occasionally set the CB group level on the DLT and have HV
          >> set all the actual light levels and do some other stuff.
          >>
          >> In a way you would be able to do this currently via xAP but not sure
          >> about HV though. The reason is that xAP interprets level and state
          >> (on/off) independently and so a device could be OFF at level 123 or
          >> indeed ON at level 0. So if the DLT toggled on/off a group the
          >> current
          >> level would be retained and the on/off macro would fire and the level ,
          >> as set on DLT, could be used in the macro for testing (maybe).
          >> However
          >> IIRC HV custom lighting always treats OFF as level 0 ...
          >>
          >> I'll investigate a bit... Itmay be possible to somehow inform you of a
          >> level change in a group in a way that triggered a macro. Maybe I could
          >> have a specifically named macro 'xLevelChange' that ran whenever a
          >> level
          >> changed and I could prefill a named HV variable 'xGroupNumber'with the
          >> number of the group that had changed. Coincident level changes would
          >> cause issues though, and would certainly delay HV reactions. Is this an
          >> acceptable compromise (HV reacting slower ?)
          >>
          >>> Now, thinking about it, obviously HV won't give me real-time
          >>>
          >> feedback, so maybe this wouldn't be as useable as a CB dimmable scene?
          >> I guess most users would expect instant feedback on a dimmer?
          >>
          >> Absolutely - and it creates other issues - in that when things don't
          >> respond instantly users tend to press again, and again and you get a
          >> very frustrating result of things continually changing or looping in
          >> unexpected ways. Both the HV serial interface , and the C-Bus PCI are
          >> bottlenecks in both directions so I would try and stick with C-Bus
          >> dimmable scenes for any realtime feedback.
          >>
          >>
          >>> I guess another way to achieve a more basic version of this is to
          >>>
          >> have a bell push key setup on the DLT and have HV cycle through several
          >> different combinations of levels in the scene.
          >>
          >> Possible... and you might be able to have some preloaded labels for
          >> each of those states to cycle through - if you were prepared to update
          >> them via xAP. Preloaded lables don't cause wear on the DLT's memory.
          >>
          >> K
          >>
          >>> Thanks,
          >>>
          >>> Paul.
          >>>
          >>>
          >>>
          >>>> -----Original Message-----
          >>>> From: ukusa_gateway@yahoogroups.com
          >>>> [mailto:ukusa_gateway@yahoogroups.com] On Behalf Of Kevin Hawkins
          >>>> Sent: 30 December 2008 14:30
          >>>> To: ukusa_gateway@yahoogroups.com
          >>>> Subject: Re: [ukusa_gateway] Actions based on level change of group
          >>>>
          >>>> No you can't currently do this as HomeVision only triggers actions
          >>>> based
          >>>> on on/off changes. Although a lamp can be off at a level eg off at
          >>>>
          >> 50%.
          >>
          >>>> There is a way if you use a xAP capable HA application (see end))
          >>>>
          >>>> I'm not sure what the advantage is over just setting a group on or
          >>>>
          >> off
          >>
          >>>> ?
          >>>> I realise you need more groups this way but there are plenty, also
          >>>>
          >> the
          >>
          >>>> LED indicators work correctly. Convince me it's a desireable feature
          >>>>
          >> ;-
          >>
          >>>> )
          >>>> BTW do you mean groups in the lighting application or the trigger
          >>>> application ?
          >>>>
          >>>> There are several issues..
          >>>>
          >>>> The main one is that sending/checking all the group levels can be
          >>>>
          >> very
          >>
          >>>> bandwidth heavy on the realtively slow HomeVision serial interface
          >>>> leading to delays in things happening.
          >>>>
          >>>> The action screens in HV or HVXL do not have a place to enter levels
          >>>> and
          >>>> there is only one action per group address. This makes the setup of
          >>>> such
          >>>> things complex and confusing.
          >>>>
          >>>> Triggering the action on every level change means every action macro
          >>>> has
          >>>> to check and decide whether it should run based on previous and
          >>>>
          >> current
          >>
          >>>> level. To do this you need to have previous level stored somewhere
          >>>>
          >> and
          >>
          >>>> it makes macros very long. A way to enable level triggers on a per
          >>>> group
          >>>> basis is also needed so that people wanting the normal on/off
          >>>>
          >> behaviour
          >>
          >>>> don't get triggers on level changes.
          >>>>
          >>>> Also consider a trigger based on say level 200. Should a lamp
          >>>>
          >> dimming
          >>
          >>>> from 210 to 190 over say 30 seconds trigger such an action ? In
          >>>> actuality the HV custom lighting level is set to 190 instantly at
          >>>>
          >> the
          >>
          >>>> start so it wouldn't. Supplying intermediate levels to HV would be
          >>>>
          >> very
          >>
          >>>> intensive - on a dim from 255 to 0 over a few secs then 256
          >>>>
          >> different
          >>
          >>>> levels would have to be transferred realtime which is not possible.
          >>>>
          >>>> It may be that there is some sort of workaround for this in a future
          >>>> version but the way I tried it before (trigger on every change and
          >>>> supply old/new dim levels to teh macro) was complicated and wasn't
          >>>> going
          >>>> to be very useful. It may need some front end support within HVXL
          >>>>
          >> which
          >>
          >>>> Schelte might consider but the standard HV app wouldn't
          >>>> offer.
          >>>>
          >>>> You can already accomplish this using any xAP capable scripting
          >>>> application. You would trigger a script based on the level change
          >>>>
          >> and
          >>
          >>>> then send a xAP command to force run a suitable macro on HV.
          >>>>
          >>>> K
          >>>>
          >>>>
          >>>>
          >>>>
          >>>> Paul Gale wrote:
          >>>>
          >>>>
          >>>>> Kevin,
          >>>>> I think this isn’t possible but wanted to check…
          >>>>> I’d like to setup an intelligent scene using a single CB group and
          >>>>> dimmer button on a DLT. The idea is that I can set a level on the
          >>>>> button and HV would interpret that level and set a number of
          >>>>>
          >> lights,
          >>
          >>>>> LEDs and other devices to a certain level. This level may also be
          >>>>> based on time of day, alarm state etc etc.
          >>>>> My understanding is that HV won’t currently trigger an action based
          >>>>>
          >>>>>
          >>>> on
          >>>>
          >>>>
          >>>>> a level change, only an on/off. Is this correct?
          >>>>> Is there a way to make this work? I’d love to be able to set a
          >>>>>
          >> number
          >>
          >>>>> of these intelligent scenes around the house.
          >>>>> Thanks,
          >>>>> Paul.
          >>>>> __________ Information from ESET NOD32 Antivirus, version of virus
          >>>>> signature database 3723 (20081230) __________
          >>>>> The message was checked by ESET NOD32 Antivirus.
          >>>>> http://www.eset.com
          >>>>>
          >>>>>
          >>>>>
          >>>> ------------------------------------
          >>>>
          >>>> Yahoo! Groups Links
          >>>>
          >>>>
          >>>>
          >>>>
          >>>>
          >>>> __________ Information from ESET NOD32 Antivirus, version of virus
          >>>> signature database 3723 (20081230) __________
          >>>>
          >>>> The message was checked by ESET NOD32 Antivirus.
          >>>>
          >>>> http://www.eset.com
          >>>>
          >>>>
          >>>>
          >>> __________ Information from ESET NOD32 Antivirus, version of virus
          >>>
          >> signature database 3723 (20081230) __________
          >>
          >>> The message was checked by ESET NOD32 Antivirus.
          >>>
          >>> http://www.eset.com
          >>>
          >>>
          >>> ------------------------------------
          >>>
          >>> Yahoo! Groups Links
          >>>
          >>>
          >>>
          >>>
          >>>
          >>>
          >> ------------------------------------
          >>
          >> Yahoo! Groups Links
          >>
          >>
          >>
          >>
          >>
          >> __________ Information from ESET NOD32 Antivirus, version of virus
          >> signature database 3733 (20090102) __________
          >>
          >> The message was checked by ESET NOD32 Antivirus.
          >>
          >> http://www.eset.com
          >>
          >>
          >
          >
          > __________ Information from ESET NOD32 Antivirus, version of virus signature database 3733 (20090102) __________
          >
          > The message was checked by ESET NOD32 Antivirus.
          >
          > http://www.eset.com
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
        • Paul Gale
          Kevin, Thinking about the pre-loaded labels (or label variants as I think CB Toolkit calls them?) - does xAP and your gateway currently support real time
          Message 4 of 7 , Jan 10, 2009
          View Source
          • 0 Attachment
            Kevin,

            Thinking about the pre-loaded labels (or label variants as I think CB Toolkit calls them?) - does xAP and your gateway currently support real time switching between them? Toolkit only appears to give 4 variants per DLT button though - but maybe enough for some tasks. - and you were saying that variants are actually stored in the unit, hence not wearing out the storage?

            Cheers,

            Paul.


            > -----Original Message-----
            > From: ukusa_gateway@yahoogroups.com
            > [mailto:ukusa_gateway@yahoogroups.com] On Behalf Of Kevin Hawkins
            > Sent: 03 January 2009 12:34
            > To: ukusa_gateway@yahoogroups.com
            > Subject: Re: [ukusa_gateway] Actions based on level change of group
            >
            > Paul Gale wrote:
            > >
            > > Does what I want to achieve make sense?
            > >
            > A scene on C-Bus is a collection of several groups that each
            > independently have a level and ramp rate associated with them. As such
            > the concept of dimming a scene doesn't sit naturally as members of the
            > scene may be at different levels (even off).. Indeed on the trigger
            > group a scene is triggered by that group being set to a specific
            > level. That's not to say you can't use level changes on a group and
            > apply them to a scene but it requires some interpretation. The
            > normal/obvious one is that a scene at 50% level would set each member
            > of
            > the scene to 50% of the normal level that it would be on at normally.
            > The ramp rates are normally maintained at the standard scene settings.
            > Only some C-Bus devices can dim scenes.
            >
            > There's a problem though in that you said "HV do some clever stuff
            > based
            > on time of day, alarm state (eg night mode) etc etc." - which I take to
            > mean that when you set specific levels eg level 128 that the scene
            > behaves differently ie its not just a half brightness scene. ie
            > really
            > you're trying to use one button to be able to do upto 256 different
            > things..... If so you couldn't use the C-Bus inbuilt dimmable scenes.
            >
            > One reason is that the results seen on C-Bus would not be inline with
            > what C-Bus might be expecting - eg if it tried to set a scene at 50%
            > brightness but you suceeded in modifying this then there are fairly
            > sophisticated self reconciling aspects of C-Bus that might kick in and
            > try and resolve/correct this. Actually I don't think they would but
            > it's a possibility. Another possible problem is that as you started to
            > traverse the dim level range - assuming you had a C-Bus implemented
            > dimmable scene then it might provide realtime reaction yet you would
            > only be using this to get to a specific level that actioned some other
            > ,
            > possibly totally unrelated change.
            > > I really don't want to do it in a xAP app if possible - like you, I'd
            > rather do anything concerned with lighting etc in hardware.
            > >
            > There's a point at which certain levels of sophistication are really
            > only achievable in software as the complexity in configuring the
            > permutations mean it can't be accomodated nicely in the limited
            > hardware
            > environment. In a software app you effectively have infinite storage
            > resource and a great UI for configuration plus a near unlimited
            > scripting environment.
            >
            > One thing you could perhaps do is have a member of the scene that was
            > virtual and set to the scene level - and then maybe a later member that
            > toggled or pulsed (somehow) then when the later member toggled the
            > earlier member would already be set to the new level. From HV the
            > actions would be triggered and you could do whatever you wanted based
            > on
            > testing the virtuals level.
            >
            > Also C-Bus relays can have threshold on/off levels set so you could
            > have
            > a number of these configured that actually did turn on/off as the level
            > moved between different values in the range 0-255.
            > > Re the slower level changes etc - I don't (think!) I'm at all
            > interested in changing a scene from a CB group level change that hasn't
            > originated from a DLT or other switch input. At least, I've not thought
            > of a situation yet where that would be useful. In my example, I'd just
            > want to very occasionally set the CB group level on the DLT and have HV
            > set all the actual light levels and do some other stuff.
            > >
            > In a way you would be able to do this currently via xAP but not sure
            > about HV though. The reason is that xAP interprets level and state
            > (on/off) independently and so a device could be OFF at level 123 or
            > indeed ON at level 0. So if the DLT toggled on/off a group the
            > current
            > level would be retained and the on/off macro would fire and the level ,
            > as set on DLT, could be used in the macro for testing (maybe).
            > However
            > IIRC HV custom lighting always treats OFF as level 0 ...
            >
            > I'll investigate a bit... Itmay be possible to somehow inform you of a
            > level change in a group in a way that triggered a macro. Maybe I could
            > have a specifically named macro 'xLevelChange' that ran whenever a
            > level
            > changed and I could prefill a named HV variable 'xGroupNumber'with the
            > number of the group that had changed. Coincident level changes would
            > cause issues though, and would certainly delay HV reactions. Is this an
            > acceptable compromise (HV reacting slower ?)
            > > Now, thinking about it, obviously HV won't give me real-time
            > feedback, so maybe this wouldn't be as useable as a CB dimmable scene?
            > I guess most users would expect instant feedback on a dimmer?
            > >
            > Absolutely - and it creates other issues - in that when things don't
            > respond instantly users tend to press again, and again and you get a
            > very frustrating result of things continually changing or looping in
            > unexpected ways. Both the HV serial interface , and the C-Bus PCI are
            > bottlenecks in both directions so I would try and stick with C-Bus
            > dimmable scenes for any realtime feedback.
            >
            > > I guess another way to achieve a more basic version of this is to
            > have a bell push key setup on the DLT and have HV cycle through several
            > different combinations of levels in the scene.
            > >
            >
            > Possible... and you might be able to have some preloaded labels for
            > each of those states to cycle through - if you were prepared to update
            > them via xAP. Preloaded lables don't cause wear on the DLT's memory.
            >
            > K
            > > Thanks,
            > >
            > > Paul.
            > >
            > >
            > >> -----Original Message-----
            > >> From: ukusa_gateway@yahoogroups.com
            > >> [mailto:ukusa_gateway@yahoogroups.com] On Behalf Of Kevin Hawkins
            > >> Sent: 30 December 2008 14:30
            > >> To: ukusa_gateway@yahoogroups.com
            > >> Subject: Re: [ukusa_gateway] Actions based on level change of group
            > >>
            > >> No you can't currently do this as HomeVision only triggers actions
            > >> based
            > >> on on/off changes. Although a lamp can be off at a level eg off at
            > 50%.
            > >> There is a way if you use a xAP capable HA application (see end))
            > >>
            > >> I'm not sure what the advantage is over just setting a group on or
            > off
            > >> ?
            > >> I realise you need more groups this way but there are plenty, also
            > the
            > >> LED indicators work correctly. Convince me it's a desireable feature
            > ;-
            > >> )
            > >> BTW do you mean groups in the lighting application or the trigger
            > >> application ?
            > >>
            > >> There are several issues..
            > >>
            > >> The main one is that sending/checking all the group levels can be
            > very
            > >> bandwidth heavy on the realtively slow HomeVision serial interface
            > >> leading to delays in things happening.
            > >>
            > >> The action screens in HV or HVXL do not have a place to enter levels
            > >> and
            > >> there is only one action per group address. This makes the setup of
            > >> such
            > >> things complex and confusing.
            > >>
            > >> Triggering the action on every level change means every action macro
            > >> has
            > >> to check and decide whether it should run based on previous and
            > current
            > >> level. To do this you need to have previous level stored somewhere
            > and
            > >> it makes macros very long. A way to enable level triggers on a per
            > >> group
            > >> basis is also needed so that people wanting the normal on/off
            > behaviour
            > >> don't get triggers on level changes.
            > >>
            > >> Also consider a trigger based on say level 200. Should a lamp
            > dimming
            > >> from 210 to 190 over say 30 seconds trigger such an action ? In
            > >> actuality the HV custom lighting level is set to 190 instantly at
            > the
            > >> start so it wouldn't. Supplying intermediate levels to HV would be
            > very
            > >> intensive - on a dim from 255 to 0 over a few secs then 256
            > different
            > >> levels would have to be transferred realtime which is not possible.
            > >>
            > >> It may be that there is some sort of workaround for this in a future
            > >> version but the way I tried it before (trigger on every change and
            > >> supply old/new dim levels to teh macro) was complicated and wasn't
            > >> going
            > >> to be very useful. It may need some front end support within HVXL
            > which
            > >> Schelte might consider but the standard HV app wouldn't
            > >> offer.
            > >>
            > >> You can already accomplish this using any xAP capable scripting
            > >> application. You would trigger a script based on the level change
            > and
            > >> then send a xAP command to force run a suitable macro on HV.
            > >>
            > >> K
            > >>
            > >>
            > >>
            > >>
            > >> Paul Gale wrote:
            > >>
            > >>> Kevin,
            > >>> I think this isn’t possible but wanted to check…
            > >>> I’d like to setup an intelligent scene using a single CB group and
            > >>> dimmer button on a DLT. The idea is that I can set a level on the
            > >>> button and HV would interpret that level and set a number of
            > lights,
            > >>> LEDs and other devices to a certain level. This level may also be
            > >>> based on time of day, alarm state etc etc.
            > >>> My understanding is that HV won’t currently trigger an action based
            > >>>
            > >> on
            > >>
            > >>> a level change, only an on/off. Is this correct?
            > >>> Is there a way to make this work? I’d love to be able to set a
            > number
            > >>> of these intelligent scenes around the house.
            > >>> Thanks,
            > >>> Paul.
            > >>> __________ Information from ESET NOD32 Antivirus, version of virus
            > >>> signature database 3723 (20081230) __________
            > >>> The message was checked by ESET NOD32 Antivirus.
            > >>> http://www.eset.com
            > >>>
            > >>>
            > >> ------------------------------------
            > >>
            > >> Yahoo! Groups Links
            > >>
            > >>
            > >>
            > >>
            > >>
            > >> __________ Information from ESET NOD32 Antivirus, version of virus
            > >> signature database 3723 (20081230) __________
            > >>
            > >> The message was checked by ESET NOD32 Antivirus.
            > >>
            > >> http://www.eset.com
            > >>
            > >>
            > >
            > >
            > > __________ Information from ESET NOD32 Antivirus, version of virus
            > signature database 3723 (20081230) __________
            > >
            > > The message was checked by ESET NOD32 Antivirus.
            > >
            > > http://www.eset.com
            > >
            > >
            > > ------------------------------------
            > >
            > > Yahoo! Groups Links
            > >
            > >
            > >
            > >
            > >
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            > __________ Information from ESET NOD32 Antivirus, version of virus
            > signature database 3733 (20090102) __________
            >
            > The message was checked by ESET NOD32 Antivirus.
            >
            > http://www.eset.com
            >


            __________ Information from ESET NOD32 Antivirus, version of virus signature database 3756 (20090110) __________

            The message was checked by ESET NOD32 Antivirus.

            http://www.eset.com
          Your message has been successfully submitted and would be delivered to recipients shortly.