645Re: [ukusa_gateway] Additional CBus network
- Sep 16, 2011Hi 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.
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.
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.
* 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 ?
> 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...
This email has been scanned by Netintelligence
- << Previous post in topic Next post in topic >>