Auxiliary input unit "hangs"

I have a system with a 5504 Aux input unit that looks at 2 x volt free contacts on a hot water system, and 2 x volt free contacts on a septic tank. The problem is when there is an interuption to the local (mains) power supply it gets upset. The whole of the C Bus system starts up great, but the two inputs from the hot water system do not work in that the LEDs on the 5504 are on when they should be off or off when they should be on. I have switched the hot water end of the cables manually and it makes no difference to the LEDs, but what does work is to disconnect the cables from the 5504 unit and then reconnect them. The LEDs then report correctly on the contact status. I have tried shorting the terminals on the module, but that doesn't work, only a disconnect and reconnect does the trick. The other two channels on the septic tank work just fine. All the channels are programmed the same, as a bell push input. The remainder of C Bus does what the 5504 LEDs are indicating. So the output of the 5504 onto C Bus is normal, it's only the status of 2 of the channels that is not getting across the 5504. The only time this happens is when there is a power failure, and it's begining to piss me off.......

And the answer is........

 

I have heard of this occasionally happening with fairly old 5504AUX units. How old is the unit?

If you toggle the C-Bus Group Address on/off from another C-Bus unit does it start responding?

Is the 'Broadcast on Power Up' feature turned on?

 

OK, to answer the questions....

Manufacturing Date:-

Unit Mfg June 2006. I purchased it during 2008, and installed it 2009.

Toggling:-

I can toggle addresses from within toolkit, and sometimes after that it works. If I toggle an input that has a closed contact across it to an "ON" state then it responds correctly to the input, if I toggle an input to an "OFF" state, then it ignores the closed input until the input opens and then closes again.

Broadcast on Power Up:-

This was set "OFF", I have now set it to "ON".

It appears:-

1/ that the unit is booting up with all channels in an "OFF" state.

2/ that the unit waits for the input to agree with the channel state before operating normally.

As my system has "break on rise" thermostats, it would wait an awful long time for the thermostat to operate if there is no output from the unit to run the hot water........

Best

Pete Steggle

 

What are the settings on the Power Failure tab? Is the unit programmed to recover to Previous Levels or Preset Levels?

 

Well, it's programmed to recover to preset levels, which is what it appears to be doing, but I'm really not sure which one this should be set to.

My understanding is:-

Recover to preset levels. Recovers to the level set by the sliders shown on the power failure tab.

Recover to previous levels. Recovers the unit to the levels that were present immediatly prior to failure.

My selection would, based on that understanding, have to be "None of the above". Liquid levels, air pressures, and the two temperatures I'm monitoring and controlling change whether C Bus is on or not, and the option I need on the power failure page is "Recover to what the input is doing right now". Then it would work just fine.

Of course, as ever, I'd be very happy for my understanding to be wrong, and be told to tick the box and the problem is resolved! I just can't see it that way at the moment.

I've just been reading through the help pages for the Aux input units, and the Bus Couplers. Would I be correct in saying that the Bus Coupler would have the same issues?

 

Bus Coupler and Auxiliary input units share the same firmware core, so if an issue affects one, it will affect the other (given the same fw versions of course). The main difference between the units is in the extra circuitry required to achieve isolation from the bus.

Until about 2008, these units incorporated firmware which initialised the key state to agree with the physical state of the contacts without issuing any commands (which otherwise could create a huge burst of communication just as the network was recovering from a loss of power in a system with many bus couplers / auxiliary units). The initialisation also allowed for the units to recover the group state as you describe.

Ten to 25 seconds after power-up, the units can be configured to broadcast the recovered state of the controlled groups so that in systems without any output units, the recovered group states of the bus coupler or auxiliary unit can be determined.

Usually, this is an adequate solution, but does not address the situation of a change in input state when there is no C-Bus power.

If your units are of this vintage, you could try setting the power recovery level to be 255 for the channels with contacts that are normally closed (thermostat = 'break on rise'.. I assume this is normally closed). The recovered states would at least then agree with the state most of the time.

The firmware was changed at version 2.2.00 to cater for situations such as yours.
The newer firmware overrides recovered group states with states determined according to the actual inputs at power-up. This means that even if the recovered group state was OFF, if the contacts were closed at power-up, the switch internally will change its state as if the C-Bus power had always been on, and the contacts had just closed. If there are no output units on the network, then the outcome of the power-up broadcast feature will always agree with the contact state as you desire.
This is all true if the bus coupler or auxiliary input unit controls groups for which there are no C-Bus output units.

If however the bus coupler or auxiliary input unit is operating in the primary application and there ARE output units on the same groups and application, and if those output units recover a state not agreeing with the switch contacts, then the bus coupler or auxiliary unit will change its internal state to agree with that of the output unit (this is standard C-Bus behaviour), and then you may once again see a disagreement between contact state and group state.
But there is a way around this.
With the newer firmware, secondary applications are supported, so you can solve the second problem by making the bus coupler or auxiliary input unit operate on the secondary application*. This works because group state corrections are not made on the secondary application, and the bus coupler or auxiliary input unit will always define the group state.

* I suggest making the Primary application in the unit different to what you normally use, but make the secondary application your normal lighting application for this to work)

I hope this is useful!

 

Hi Guys,

Thanks for taking the time to give detailed replies to my question. It did take me a little time to understand what Dons reply actually meant, but if I got it right, the firmware prior to 2.2.00 Aux unit starts up and sets it's outputs according to the power recovery settings and broadcasts these on the network. And that's that. After 2.2.00 I could set the unit to output on a secondary application and then it would work properly.

It baffles me that a device designed as a contact interface can get into a state where it doesn't reflect what the contacts are doing!

As my Aux unit has firmware number 1.0.67, and the bus couplers on my system have firmware number 1.2.67, I'm going to assume that this is a lost cause unless I throw out these units and fit new ones where I could set the secondary application to the one I want. That's $$ as I have 4 bus couplers and an Aux unit that don't do what I thought they would do.

Is it possible to update the firmware to better than 2.2.00?

Is it possible to use my PAC to issue a command that will initialise the Aux unit correctly?

What about putting in a network bridge with the Aux and Bus units on one side (with a power supply) and the remainder of my network the other? Would that enable the correct start up state as there would be no output units on the new network?

Best

Pete

 

The hardware is totally different between those two versions of bus coupler, so no update is available.

All you can really do from the PAC is turn groups on or off, and you can do this in the Bus Coupler already by specifying power-up levels.

This still doesn't solve the fundamental problem that the state has changed when the Bus Coupler or Aux Input unit wasn't looking (i.e. unpowered).

 

But I thought that the fundamental problem was that the unit booted up without checking the input states and then put out bad information.

Bugger........

But thanks for your help anyway!

Best

Pete S