Status Report

Hello

I found that Status Report(MMI message) occupied band width of C-Bus communication line.
As default configuration is 3 second.

This is my understanding of functionality of status adjustment by Status Report.
- All C-Bus input units have Status Report function.
- If Status Report interval timer is expired, MMI message is sent and the timer is restarted.
- All C-Bus units are hearing MMI message. If it is received, interval timer is restarted.
- Normally, MMI message sender reach first timeout of interval timer in all of C-Bus input units. So, that unit send a next MMI.
- All of C-Bus units adjust internal status by receiving Status Report.

I have a few questions.

Why is that the C-Bus status in MMI message sending by unit is right guaranteed?
If the MMI sender may be unable to receive a C-Bus command correctly, will not the status of an MMI message become not right from it?
If information by received Status Report is not match with own information, what kind of action will be taken in MMI receiver.

I think that It seems that the unit newly connected to C-Bus utilizes Status Report effectively.
However, in the C-Bus network whose connection is stable, I can think that Status Report does not have a big meaning.

Please teach me why Status Report needs in C-Bus network.
Please teach me how to guess the optimal value of Status Report interval.

 

The terms 'Status Report' and 'MMI' refer to the same thing in C-Bus.

The Status Report is a special single message in which a number of units can contribute data, and a number of units can all receive the contributed data simultaneously. The Status Report is unique to C-Bus and is patented.
The purpose of the Status Report is to maintain a connection over time between C-Bus input units (sensors, bus couplers and key units), and output units (relay and dimmer units).
If any status errors are discovered, then corrective action can be taken.
How it works:
Only output units contribute any data to the Status Report. The data that is contributed is the ON / OFF status of each Group within an Application. The Status Report protocol allows contributions to the same Group by multiple units in such a way that conflicts can be detected.
C-Bus Input units receive all Status Reports relating to their Primary Application. For each Group within the primary Application, the input units will analyse the contributions from all output units, and will do one of the following:
If there is no contribution, or the contribution agrees with the ON / OFF state that the input unit has for that group - it will do nothing,
If there is a contribution indicating a conflict in state between output units, the last input unit to transmit any command controlling that Group will transmit a command in an attempt to correct the conflict.
If there is a valid contribution from one or more output units that does not agree with the state of the input unit, the input unit will change its state to match the state of the output units.

Your description of how the Status Report is initiated is pretty well right, except that only C-Bus input units can initiate a Status Report.

To answer your questions:

1) There is no guarantee that the status returned in the Status Report is 'right', but the protocol has been designed so there is a priority as follows:
a) output units control loads, and therefore should not change load state without a good reason, so in a case of a status disagreement with input units, the input units will change state to agree with output units. This way, the system is consistent.
b) if there is a disagreement between output units, then some loads may be in the wrong state and must be corrected. In this case, the last controlling input unit state is used to define the load state. In the end, all input and output units should arrive in the same state.

2) there are two parts to this:
a)The unit that initiates the MMI is not fixed, and there is a maximum interval allowed on any network (slightly longer than the configured MMI or Status Report interval programmed in units), after which all input units will attempt to take over as initiator of teh Status Report. If a unit is having trouble communicating, another is likely to take over the function in any system.
b)On / Off status received in any one Status Report may be corrupted by electrical noise, so before taking any corrective action, all C-Bus units using Status Report information will wait a minimum of three successive status report frames all with the same state information. This effectively filters noise from Status Report information.

3)In an ideal network with no communication errors, no electrical noise and perfect connections, the Status Report is of little use. Status Report frames are given the lowest priority of any C-Bus message, so should not cause problems if configured correctly. Unfortunately, the world is not ideal, and we have found that the Status Report system used by C-Bus is an effective means to keep a system operating despite occasional communication problems.

The optimal Status Report interval depends upon an acceptable time to make any state corrections. In Lighting where key units are used, we find that a 3 second interval is appropriate as it provides status corrections in 15 seconds at the earliest. If a system is designed using mostly sensors and / or remote control of lighting, perhaps 10 seconds would be appropriate (30 seconds would be the shortest time to make a status correction), but for heating, irrigation, security, etc. it may be more appropriate to make the interval closer to a minute.

 

Hello Don,

Thank you very much for your explanation.
I read your comment for another post regarding Status Report and C-Bus Bridge.
I understood needs of Status Report.

I have a trouble regarding Colour C-Touch and MMI.
I posted it to C-Touch part of Forums.
The cause of the trouble is not determined.
However, in my guess, I think that there is a problem in processing of MMI within Colour C-Touch.

I think C-Bus network is designed for hardware input units and output units.
C-Bus touch panels does not have Status Report interval parameter.
It will not be a sender of Status Report.
Regarding touch panel of C-Bus, I feel that status change of icon not using the usual C-Bus message but using the information on Status Report.
I think that Colour C-Touch can not show correctly the state of the remote network.

Thank you very much.

 

This is correct. Colour C-Touch does not initiate MMI requests. Colour C-Touch just observes the MMI messages and if a discrepancy is seen, then it will act as described by Don above for input units.

This is incorrect. If you change a Group Address on C-Bus, you will see colour C-Touch change the state immediately. Relying on the MMI mechanism would result in a delay of 12 to 15 seconds, assuming you have a 3 second MMI rate.

Colour C-Touch will show the state for a remote network if it sent the message to the remote network (in this case it assumes the message was successful), or if it receives a message from the remote network.

 

Hello,

I am sorry.
I missed to understand regarding status changing icon in Colour C-Touch.
In my environment, Colour C-Touch does not change status of icon by coming from message by another network.
I divided one network into two. Each network is connected by C-Bus Bridge.
It became clear that C-Bus Bridge had not transmitted a part of Scene published from Colour C-Touch to another network.

05,68,38,00,12,12,00,12,13,00,12,15,00,12,16,00,12,1D,00,12,1E,00,01,A0,C3,<CR> 27 bytes not passed
05,68,38,00,12,0D,00,12,14,00,12,0E,00,12,0F,00,12,10,00,12,11,00,90,<CR> 25 bytes passed
05,7E,38,00,01,E5,01,FB,79,F9,01,D4,01,FC,79,FA,01,DB,01,DA,01,C8,01,CA,61,<CR> 26 bytes not passed
05,7E,38,00,01,76,79,E6,79,F3,03<CR> 11 bytes passed
05,68,38,00,02,01,B2,02,02,B2,02,03,B2,02,04,B2,02,05,7F,79,06,01,07,74,<CR> 25 bytes passed
05,68,38,00,01,08,01,09,79,0A,01,0B,79,0C,02,0D,33,02,14,33,01,E7,01,31,8F,<CR> 26 bytes not passed

C-Bus Bridge has not transmitted 26 bytes or more of message including CR.
The firmware of C-Bus Bridge is 4.4.00.
Is this known issue? Or is it a bug?

Thank you very much.

 

The messages of 26 or more bytes by your reckoning are too long to pass through a bridge. The message length that a bridge can handle is limited. Normally this is not a problem, because C-Bus units usually generate messages that can pass through bridges.

I don't know exactly how you have created these long messages, but if you can break the information from one long message to two shorter messages, you will have success in transmitting the commands through bridge units.

 

Hello Don,

The 26 bytes message was created by Colour C-Touch.
The project was created by PICED 4.8.3.0 version.

It is very easy to reproduce.

Should I report this information to C-Touch thread?

I want this bug to fix by next version of PICED.

Thank you very much.

 

We are looking into this problem.

If you need an immediate fix, you can change your scenes so that they are broken into smaller scenes of up to 6 groups each, and triggered with slight delays between each, so that message length is kept low

The problem is only related to networks with bridges, and is the same with all bridges, so firmware version does not make any difference.

 

As Don says, we are looking into this. It is issue number 19633.

The problem only occurs if you have 10 on/off commands in a Scene (or more). This results in a command which is one byte too long to automatically go across a bridge in application connect mode.

There are several solutions:
1. Break the Scene up into smaller Scenes (as Don suggested).
2. Change one on/off command to a ramp command. This will increase the length of the command by one byte which will actually cause the message to be broken into smaller messages before being sent to C-Bus.
3. Change the Scene so that the C-Bus messages are addressed to the remote network.

 

There is actually a fourth option, but it needs some background information first.

When C-Bus commands are sent to the C-Bus Module (CBM) which is used in all of the touch screens, the commands are added to a queue for transmission. The PICED FAQ topic "C-Bus Command Queue" gives an introduction to this.

The CBM automatically concatenates commands where possible into a single message. So, for example, if you send 25 lighting On commands in quick succession (for example in a scene) then the CBM will package these up into 2 messages, each with 10 commands, followed by another with 5 commands.

The CBM can only concatenate commands addressed to the same Network and Application. So, for example, if your Scene had 5 lighting On commands for Application 56 followed by 12 for Application 57, then the result would be a message containing the 5 messages for Application 56 followed by a message with 10 commands for Application 57 followed by another with 2 commands for Application 57.

Therefore, if your Scene contains a mixture of different Applications and/or Networks, you could order them in such a way as to cause the messages to be shorter.

In this case, we are trying to avoid a message with exactly 20 bytes of "commands" where:

• On commands are 2 bytes
• Off commands are 2 bytes
• Ramp commands are 3 bytes

So we need to avoid a message with 10 on/off commands. Similarly, a message with 2 ramp commands and 7 On commands would be a problem.

 

Hello Don and Darren,

Thank you very much for your comments.

This issue will be fixed in next release.
I assigned the same Scene to Colour C-Touch in both network. And I assigned the same Trigger ID to the Scene.
It is an easy method although the same command may send into a network twice by this method.
If a problem is solved by new PICED, I will delete the scene assigned into another Colour C-Touch.

Thank you very much.

 

Yes, it will.

That is a good solution to the problem.

 

I appear to be having a similar problem. Was this issue fixed with 4.8.4?

http://www.cbusforums.com/forums/showthread.php?t=6117

Thanks!
-Duke

 

No, the issue will be fixed in the next major release of PICED, which will almost certainly be 4.9.0.