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

645Re: [ukusa_gateway] Additional CBus network

Expand Messages
  • Kevin Hawkins
    Sep 16, 2011
    • 0 Attachment
      Hi Ben,

        Which model  temperature sensors are they and if there's a mode setting for them which one are they in ? Do you know on which C-Bus application they are sending data ?

        I'm guessing from the comment below they're not being used in any C-Bus logic anywhere ,  it maybe that they can send data within the lighting application and if so perhaps they could be easily supported but ISTR yours were an earlier type that had to be polled for information or something. Didn't you send me a link once to a forum post about this ? Polling on C-Bus is to be avoided wherever possible.  

         I don't have any C-Bus temp sensors to try (although I do have a couple of thermostats) but they are quite different I think.

         K

      On 16/09/2011 07:05, Ben Wilkinson wrote:

      Thanks a lot for this, Kevin.  It’s really useful explanation of some bits of HV and the gateway which I didn’t know about.

       

      I think I’ll be able to use Application Bridging to do this if I need to as I have plenty of spare groups.  

       

      I do like the idea of the bigger gateway though if it allows me to read the temperature sensors I’ve installed around the house.  At the moment, there only purpose is to provide a small red light in the rooms they’re in.....  I’m assuming you won’t be doing that in a hurry though, and I’ve managed without them so far.

       

      Ben

       

      From: ukusa_gateway@yahoogroups.com [mailto:ukusa_gateway@yahoogroups.com] On Behalf Of Kevin Hawkins
      Sent: 14 September 2011 15:00
      To: ukusa_gateway@yahoogroups.com
      Subject: Re: [ukusa_gateway] Additional CBus network

       

       

      The gateway creates in it's memory a state table for 256 group's on the
      main C-Bus lighting application 56 (0x38) . There isn't enough memory
      within the gateway* to maintain a table for another lighting application
      on a remote network, or even a secondary lighting application on the
      main network. However there are potentially unused groups that are
      using memory but it's awkward to free them up for other uses. The
      gateway supports network routed messages but essentially in a tolerant
      rather than practical way.

      C-Bus itself only provides status information for groups that are
      present in output units (relays or dimmers). If you create a group in an
      input unit e.g. a switch then C-Bus reports the group as 'absent'
      although it will still pass messages to it. You can not determine its
      state, level or even existence from C-Bus and so these are called
      virtual groups. After a power cycle you can't establish the state of
      such groups. If you have the gateway HomeVision option then you can
      also send messages to these groups, or monitor them for changes -
      effectively creating virtual groups which are useful as triggers. The
      gateway fully tracks these virtual groups , even though C-Bus doesn't,
      and they therefore use memory in the state table memory. Because C-Bus
      doesn't report these groups the gateway only becomes aware they are
      being used when they change state and that makes freeing up unused C-Bus
      groups impossible because there is no assured way to know they are unused.

      So .. let's explore your options...

      1) A second xAP gateway - yes although that would require a slight
      code change to monitor a bridged lighting application.

      2) There is a feature called 'application bridging' that C-Bus
      bridges offer. Basically this merges the groups present within an
      application (e.g. lighting 56) on both sides of the bridge so that if
      you change a group on one side then that group will also change on the
      other side of the bridge. This is especially viable if you are using
      bridges for physical reasons e.g. wiring topology/length but still have
      enough groups on the original lighting such that you can fit them all
      in. This may suit you reasons for bridging. However I think the
      local network will report the application bridged groups on the remote
      network as 'absent' still, and so after a power cycle the gateway won't
      be able to determine the groups state (until they initially change
      state); thereafter it will track them dependably.

      xAP or HomeVision control of the bridged network will work . I
      use application bridging myself for my C-Bus wireless networks and it
      works pretty well. Occasionally I do see inconsistencies between the
      two networks but I attribute that to wireless communication problems.
      It'll likely be robust with a wired bridge.

      3) If you don't have enough groups spare then you can create a
      secondary lighting application on the local network and 'application
      bridge' that to a group on your bridged network. You could have several
      of these. However the gateway will not model these applications within
      it's internal memory and so it will not report them via xAP. I would
      need to check if you can control them via xAP, I suspect you could
      although not using the BSC schema. If you use HomeVision then you will
      be able to send control messages to these groups by entering a different
      application number in the custom lighting table entry. However the
      status will not be tracked in HomeVision's state table and so you would
      need to plan carefully which groups are on which network.

      4) A gateway with more memory and capabilities. I have on and off
      being playing with different gateway hardware that would handle more
      applications and network bridging. A frequent request has been for the
      trigger and enable applications as most people are satisfied with the
      256 lighting groups. I would also like to support other C-Bus
      applications that don't use the lighting protocol (HVAC, Security,
      Media, Measurement, Telephony, Time etc). I don't have immediate plans
      for such a gateway however. PCB's and assembly of such a product on an
      'at cost' basis is not something I'd want to undertake again and so
      should I offer such a product then it would need to be on a commercially
      viable basis = more expensive.

      Although xAP support wouldn't be a problem there is a difficulty in
      supporting remote networks and multiple application from HomeVision.
      The custom lighting table within HV only provides two parameters per
      light, one is used for the group and so there isn't the option to enter
      both an application number and a network number. There are possible
      ways around this perhaps by using variables but it's a little messy.

      HTH Kevin

      * Actually large amounts of the gateway memory are used by HomeVision,
      and this is allocated even if you do not have that option. This is
      because the firmware build contains all options. The HomeVision
      endpoint names are the biggest culprit here and I suppose... if someone
      wasn't using HV but wanted multiple C-Bus applications/networks then
      there would be ample space for these. probably 16 more if I were to
      build a 'non HV' version. Is anyone here in that category ?

      On 14/09/2011 10:50, Kevin Hawkins wrote:
      > Hi Ben,
      >
      > I can't remember which options you had with your gateway, and for
      > some reason I haven't created a serial number entry against your name -
      > are you using HomeVision / are you using xAP ? There's a few
      > possibilities depending on how you're using the existing one.
      >
      > Also how many lighting groups are you using on your main network ?
      >
      > K
      >
      > On 14/09/2011 08:21, bensbarn2001 wrote:
      >> I think I need to add another network to mine (things aren't working properly and I think I've exceeded the 1000m limit). Will the gateway work across multiple networks? They will be connected via the network bridge. It seems that there'd need to be some additional address info, so not sure how it would work currently. Alternatively, I guess I could run 2 gateways...
      >>
      >> Thanks
      >>
      >> Ben
      >>
      >>
      >>
      >>

       


      This email has been scanned by Netintelligence
      http://www.netintelligence.com/email



    • Show all 7 messages in this topic