Essential and Non-essential c-bus networks

Discussion in 'C-Bus Wired Hardware' started by ICS-GS, Jan 9, 2013.

  1. ICS-GS

    ICS-GS

    Joined:
    Nov 1, 2004
    Messages:
    347
    Likes Received:
    0
    Location:
    SE Melbourne
    Hi Guys,

    Just wondering if anyone else has thought about deploying multiple (essential and non-essential) c-bus networks within an existing c-bus install in a building or home?

    With the theory being that units with power supplies to the network would consume less when not supplying as many units (some research will be required here unless someone already knows the answer).
    ie if 40-50 input units (all drawing approx 18mA each) were removed from the network when unoccupied (and possibly overnight in domestic installs via scheduling via good night / good morning / PIR detection overnight) over 12 months this may add up to a considerable saving.

    I was thinking this could be achieved by one of the following methods:
    • Run new "Essential" network
    • Utilize the existing Brown & Green pairs within the existing caballing for the "essential" (or non-essential) network.
    The link between the "Essential" and "Non-essential" networks would ideally be achieved through a 2 pole relay to link the networks when occupied and break the connection when unoccupied, etc. controlled by an output on an "essential" output module.

    My thoughts on what "Essential" components are...
    • All output modules (to facilitate commands from remote devices, eg wiser)
    • All "nerve center" components such as wiser, touch screens running logic of schedules, etc.
    • Thermostats for HVAC control
    • Security devices
    • External PIR's
    There may be others, but just off the top of my head right now these will do.

    Has anyone done anything like this before, or are there any perceived pitfalls?

    Cheers

    Grant
     
    ICS-GS, Jan 9, 2013
    #1
  2. ICS-GS

    Roosta

    Joined:
    Nov 22, 2011
    Messages:
    560
    Likes Received:
    1
    Location:
    Australia
    Hi Grant,

    While not a completely silly idea, I believe the standby current of the cbus equipment is so low that the possible reliability issues, etc make it totally not worth doing..

    I believe (could be wrong) a standard cbus dimmer/relay with onbaord psu consumes about 0.03w per hour which tallies up to ~260w per year per module.. Is it really worth it to save 10c?

    Other aspects to consider with your thought is what if someone goes to use a device in the 'non essential' area and then has an accident because the lights didnt work? Opens up all sort of scary headaches..

    Cheers..
     
    Roosta, Jan 9, 2013
    #2
  3. ICS-GS

    ICS-GS

    Joined:
    Nov 1, 2004
    Messages:
    347
    Likes Received:
    0
    Location:
    SE Melbourne
    you could be right, i hadn't done the homework, just yet.

    But in my mind i was working through the c-bus side DC consumption, ie 18mA * 40 units = 0.75A in those terms it seemed like a significant saving if this could be halved, i was neglecting the Ac->DC factor.
     
    ICS-GS, Jan 9, 2013
    #3
  4. ICS-GS

    daniel C-Busser Moderator

    Joined:
    Jul 26, 2004
    Messages:
    770
    Likes Received:
    21
    Location:
    Adelaide
    Interesting idea.

    I must note that the software (Toolkit, Schedule Plus, OPC Server) makes a key assumption that once commissioned, the network topology should stay the same. Units that disappear during operation would be treated as network errors. In some cases this can trigger higher levels of traffic as the software tries to figure out what went wrong.

    There are some threshold values that can be played with to reduce the false negative errors but if this sort of power toggling ever became commonplace in the field, we would have to revise that key assumption.

    This is a roundabout way of saying, "try this at your own risk" :)
     
    daniel, Jan 10, 2013
    #4
  5. ICS-GS

    ICS-GS

    Joined:
    Nov 1, 2004
    Messages:
    347
    Likes Received:
    0
    Location:
    SE Melbourne
    hmmmm, this may explain why i have a few network status = error messages from time to time.
    In my "toolkit db" network, i have a few "future" items listed in the network, that are actually not yet installed onto the network, but i have added them to reserve GA's, etc, would this sort of this cause the network to go into error state, or only is they were present then 'disappear'?

    I also understand this screws with the "network" tab, in terms of consumption, impedance and burdens... actually, it would be nice if there were a second calculator open up to show the 'on-line network' if there is an open network, and there is a difference between the # of units on the DB vs he network.
    This may also help when troubleshooting, and dividing networks into smaller segments during faultfinding. I myself (believe it or not) have fallen for the trap of not adding burdens to small chunks of network during faultfinding and wasted many minutes working out why.

    Getting back on to the subject of the thread, i will give it a go when i get some time and report back the results, any chance you can detail which threshold values should be 'tickled'?

    A client actually provoked my initial thoughts about this as one of the selling points for him was using his energy more efficently by ability of running lights @ 50%, using sensors in frequently trafficed areas, linking an all off scene to an 'alarm armed' signal, etc. Then he posed the question of the standing load of all these devices running 24x7 and wether the energy saved equaled the energy used to save energy in the first place. (his wife was sold on the cosmetics anyway, and we all know what the wife wants the wife gets!)

    Maybe some time in the future some sort of revised network bridge could be deployed for this purpose, which could then control this switching and notify the network accordingly. alternatively utilising the brown and green pairs on PSU enabled devices may be worth a look as i dont know anyone who sees the need to use these remote commands anymore, now that most installs can handle scenes with many, many more GA's than days gone by, now that touch screens & wisers are the norm in nearly all installs, assuming this may be why these remote commands were built in, in the first place.

    It would be great to see an energy conservation product trying to conserve as much energy as possible, or at least providing options to do so, if required.

    Regards

    Grant
     
    ICS-GS, Jan 10, 2013
    #5
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.