Multisensors - multiple ON/OFF commands issued

I have quite a few (20) multi-sensors. I have noticed in the Toolkit log that often they issue two ON or two OFF commands within the same second (or subsequent second). Is there any reason why they would do this? Is it to do with the fact they use both light and movement?

Sorry if this is a dumb question....just interested to know why.

Many thanks.

TWO ON COMMANDS:
================
DateTime= 26/11/2009 3:24:04 PM App= 056 Lighting Group= 140 Pantry Pelmet T5 Unit= 113 SENPILL/5753PEIR Event= Group on
DateTime= 26/11/2009 3:24:04 PM App= 056 Lighting Group= 140 Pantry Pelmet T5 Unit= 113 SENPILL/5753PEIR Event= Group on

TWO OFF COMMANDS:
================
DateTime= 26/11/2009 3:29:10 PM App= 056 Lighting Group= 140 Pantry Pelmet T5 Unit= 113 SENPILL/5753PEIR Event= Group off
DateTime= 26/11/2009 3:29:10 PM App= 056 Lighting Group= 140 Pantry Pelmet T5 Unit= 113 SENPILL/5753PEIR Event= Group off

 

When C-Bus units send messages on the network, all the other units acknowledge the message either positively or negatively. You can think of it as the other units on the network saying either "Yep, got that loud and clear" or "Pardon, what was that?".

If the Mutlisensor is re-sending the commands then it is most likely the case that your network has a communication problem. One or more of the units on the network is saying "Pardon, what was that you just said?"

If you connect the C-Bus Diagnostic utility to a PCI on your network you will probably be able to see communication errors appearing on the network.

 

Hi Newman

Interesting, is that case for all cbus messages? If you send a message to turn on or off a lighting group relay, does each relay send back a message each time a request is made - I assume the switch recieves that response - how does it act?

And if say one input turns on 10 relay groups do all 10 realy groups each send out a message one after the other to say that they are on or off?

What about temperature sensors, dont they just send out temperature every so often at set intervals?

thanks

 

All C-Bus messages are acknowledged as Newman pointed out. In fact, the protocol has been designed (along similar lines to most packet-based network protocols) to provide a high 'quality of service'. This includes lighting and temperature messages.

Each message has a checksum included as part of the message (a number is added to each message which is the sum of all parts of the message), so that each receiver can calculate a checksum of the received message, and compare the received checksum with the checksum sent by the transmitter. If the two checksums match, the message is good. If the checksums don't agree, something went wrong, so the receiving unit asks for another transmission. This is error detection.

The transmitter will send another copy of the same message in response to the 'negative acknowledgement', and the process repeats. If the second message is ok, it all ends there, but if the second attempt still fails, the receiver will request another copy, and another. This is error correction.

While the number of copies can go on and on, C-Bus limits the process to just three copies so that other communication can continue (one unit having problems shouldn't upset the entire network). when this happens, the transmitter can take special action - such as to flash the LED associated with the key initiating the transmission - so that the user is alerted.

If the transmission is broadcast to more than a single receiving unit, as is the case with lighting control, all the above mechanism still works, but there is a special time slot just after the "Yep, got that loud and clear" or "Pardon, what was that?" where one (or more) units can add " I see all the other units got that but I didn't hear it!". Now all the units that received the message and reported that the message was ok, will also know that one other unit had a problem with the message, so they will ALL throw out the message and the transmitter will send another copy.

This special method of acknowledgement is unique to C-Bus (as far as I am aware), and allows very high reliability of communications in a properly constructed network.

This is only part of the arsenal used in C-Bus to ensure a high 'quality of service'. Other mechanisms include the regular 'status report' (also referred to as an MMI) used in the lighting application.

 

If an input unit is turning on 10 C-Bus groups it will probably split that up into 2 C-Bus messages. One feature of C-Bus is that some commands can be concatenated within a single packet/message. Regardless as to whether the message is turning on 1 group or 5, the bus time taken up to acknowledge the message is the same.

The acknowledge that is send by the receiving unit is confirmation of receipt of the command, not confirmation that the receiving unit has gone to the correct state. The checking and correction of state errors is what the MMI mechanism is for.

The newer (5031RDTSL) temperature sensor can broadcast the temperature regularly. When it does, it is broadcast to all units on the network, and all units acknowledge that they have received the message. For units that are not interested in the temperature message, they then just throw it away.

 

The attached shows the traffic analysis for around 5 hours. There don't appear to be significant errors (based on my reading of other threads and error numbers) but it is clear that at times these errors appear when multi-sensors are triggered and also I have a couple of key input units that flash at times (and generate an analyzer error) which would suggest communication problems. All voltages are between 23v and 30v. The network, generally, is stable.

I have checked all items such as clocks/burdens etc. It is really only one or two units that seem to generate these comms errors consistently (and their voltages are ok).

Is there clear way to determine what might cause these comms errors or which unit/units might be the cause. Would an oscilloscope show anything useful ?

Edit: I have around 10 'home run' c-bus (pink) cables back to the comms room from various areas of the house. The one keypad that flashes consistently is a 6 button reflection and generally only the top two buttons flash when pressed. Interestingly there are five other reflections on this particular cable and none of those have ever given a flashing error. Voltage on all these six is ~27v.

 

If you are ever seeing flashing on key unit indicators then it confirms that there are communication errors on the network. If the unit sends the initial message, but it fails, and the 3 subsequent copies fail, then it will flash it's indicators to tell you that it was unsuccessful in it's communication.

It's time to work through the basics, such as making sure there is only 1 network burden, less than 1000m of cable, no more than 2000mA of C-Bus supplies, less than 100 units on the network, no more than 3 units with the clock generator function enabled, the Toolkit calculator doesn't show any errors (may require manual correction of catalogue numbers in the database to work correctly), C-Bus cable is properly segregated from mains, checking for a faulty unit, etc.

A CRO trace may/may not show what's going on and is probably only useful if most other avenues of investigation have been exhausted.