C-bus MMI Report Rate

Current c-bus's status reporting is set to occurs every 3 seconds..is there any way that i could reduce it further so that the status could b retrieved and displayed on my pronto much faster..

 

C-Bus MMI's are part of the background synchronisation and error checking process of C-Bus. They consume a small portion of the C-Bus bandwidth. I would not recommend reducing the C-Bus MMI rate below 3 seconds.

Once a connection is made to C-Bus, the network can be immediately asked for the state of the groups. There is no need to wait for the next C-Bus MMI to occur.

If you are using someone else's pronto interface, then there's a good chance that the time it takes for the Pronto system to discover the on/off state of the C-Bus groups will not be affected by the MMI rate on the network.

If you state more clearly what you're trying to achieve, I'm sure there is a better method of gathering the network state in a timely fashion.

 

The following r the messages that i have received from the c-bus after initializations. Any way for me to skip those PCI returns (1st 4 lines) n directly jump to the MMI Report Lines which could further reduce the status update delay. I tried to remove the character "g" from every initilization commands, but somehow the MMI messages become inconsistent..

Initialization Commands
Com1.send("~~~\r");
Com1.send("A3210038g\r");
Com1.send("A3420002g\r");
Com1.send("A3300079g\r");

MMI Messages
3230078
86D0D0003230078
g.8380094...
g.
MMI Report Line 1
MMI Report Line 2
MMI Report Line 3

In addition, when i off the light through a saturn switch..it tooks about (5-8 seconds) to update n display on my pronto as the switches r set to report their status to the c-bus every 3sec (min).

 

does that means tat my pronto could nvr be updated n displayed in less than 3 sec since the s/w is designed in such a way that it will only update its status to the c-bus network every 3 sec?

anyway..thanks for ur advice!!!

 

they require decoding the lighting messages as the occur (not hard) and keeping a local copy of the level of each of the groups you want to monitor < sorry nick..i don't really get what are you trying to say..would you mind to elaborate further?

Basically I need to get the lighting status (On/Off Only, not level) of all together 10 groups (Application address = 38hex in Cbus). However, as i have mentioned, it tooks bout 5-8 seconds to update n display in my pronto because of the following reasons:

(1) "Status Report" time of a s/w could only be set at 3 sec (min & could not b reduced further using C-bus Toolkit) which means when a switch is being press to on/off the light, it will takes the switch about 3 sec to update it status to c-bus b4 i could retrieve it using my pronto.

(2) The 1st 4 lines of PCI returns (e.g Ackowledgement char: .g) which i have mentioned earlier in the post further delay the decoding process about 1 sec.

(3) One thing i am not sure is that why the 3 lines of MMI report comes in line-by-line slowly (i retrieve it and display on my pronto) whereas it could be retrieve n display immediately when I use c-bus diagnostic kit to read the MMI application report.

CF.widget("label1").label = Com1.match("","\r",0);
message = CF.widget("label1").label;
checkstr = message.substr(1,6);

(4) I could only set my pronto page script to excute every 1 sec. Further reduces would causes some status fail to retrieve n update.


Hence, the delay here n there added up causes my status update process becomes very slow. Anyway..i have attached along my script in text format. Would appreciate if someone could help. THANK YOU VERY MUCH!

 

When you press a button on a C-Bus switch, a message is sent on C-Bus to turn the Group Address on or off. This message is sent immediately. You need to understand these messages. The C-Bus protocol documentation will explain how to understand these messages. You need to update the state of the Pronto in response to these messages.

These messages are separate to the MMI messages. The regular 3-second MMI messages are only useful to you for doing periodic background checks to ensure that the the state of your Pronto is still in sync with C-Bus.

Reducing the MMI rate (if this was possible) would not help you much. The rate of MMI messages on the network seems largely unrelated to your delays.

This seems to be a characteristic of the Pronto. It is not a characteristic of C-Bus.

When the script runs, how much data gets processed? Does the script only send 1 command to C-Bus each time it runs? It sounds like your script is taking a long time to execute.

I am going to make the assumption that your script only sends 1 command to C-Bus each time it runs and suggest that this is what is happening:
1. Pronto initialises (n seconds)
2. Pronto sends first command to C-Bus and gets a response (1 second)
3. Pronto sends second command to C-Bus and gets a response (1 second)
4. Pronto sends third command to C-Bus and gets a response (1 second)
The PCI will now report MMI's to the Pronto.
5. Between 1 and 3 seconds later, the first MMI is reported to the Pronto by the PCI.

This sequence of events seems to be consistent with your 5-8 seconds for the Pronto to get the C-Bus states.

As Ashleigh says, sit down and read the C-Bus protocol documentation carefully.

You should only need to initialise the PCI the first time you connect to it. You'll also need to re-initialise the PCI if there is a power failure, as the Pronto runs on batteries and may not see it.

Is the slow delay to obtain the initial state of the C-Bus groups only an issue the very first time you use the Pronto, and all subsequent uses are fine?

 

Are you initialising the PC interface correctly?

It has several modes and not all of those will send back an on/off status when a button is pressed.

As mentioned in the other posts

You should get the MMI once and then keep track of the on/off after that, this would require a second decoding routine as the output is not the same as the MMI response.

Sending an MMI request all the time is bad news and will really bog down the network.

From memory (and its fading fast ) the g you are seeing is one of several possible checksum hashes depending on what mode you are in.

But I could be wrong on that one, its been a long time since I've had to play with the guts of it.

Michael

 

I think we have some miscommunication =). Lets imagine i have a 'Kitchen Page' in my pronto which CONTROL as well as MONITOR the status of 3 lighting groups. When I first log into the Kitchen Page, my pronto will initialize the C-BUS for MMI report. C-Bus will then send the MMI report back to me which contains the ON/OFF information of total 256 groups. Therefore, I just use a If..Else statement to extract the ON/OFF status of all 3 lighting groups that I have wanted. After decoding the MMI report, the status of the 3 lighting groups will be UPDATED and DISPLAY respectively on my pronto with 'ON' or 'OFF' text as the indication. ALONG THIS PROCESS..THERE's A DELAY ABOUT 5-8sec WHICH I HAVE MENTIONED EARLIER.

Secondly, if I toggle the VIRTUAL BUTTONS in my pronto, it is able to CONTROL all 3 lighting groups & updates their status in my pronto without any problem or delay since i do not need any information from the MMI report once my pronto updated with the latest ON/OFF status of each lighting groups. For example, Light 1 is ON initially, when i pressed the button again, my pronto will transmit a msg to c-bus to turn it off. The status on my pronto will then toggle to display a OFF status (Using if..else statements).

Finally, if someone OFF light 1 through the wall switch, my pronto must be able to detect and update the status respectively. This is where another 5-8 sec delay comes into the picture. In order for me to get the correct status of all 3 groups, my pronto must keep on doing the background checking my non-stop receiving the MMI report from the C-BUS, decode it, update it and display it as I never know when the user will On/Off the light through the wall switch.

From my understanding, the only way for my pronto to get the latest lighting status is to keep on doing background checking. Hence, "When you press a button on a C-Bus switch, a message is sent on C-Bus to turn the Group Address on or off. This message is sent immediately. You need to understand these messages." <-- when someone press a buton on a switch, is true that a message is sent to c-bus to turn the group address on or off. But there is no way for me to retrieve this message directly from the switch. What i can do is, wait for the regular 3sec MMI report to inform me that this switch has actually change its status.

Anyway..thanks alot for your help!!! Cheers! =)

 

As i have mentioned, i have to keep monitoring the status of each ligting groups & update to my pronto respectively. Hence, I have no choice but to keep requesting for the MMI report for background checking.

 

The way you have configured the PC interface, you should be seeing the immediate messages (starting with "05") on the network resulting from buttons on network units being used to control load states. Normally you can update status one group at a time by decoding these short messages.

Is the reason you can not use these messages to update your Pronto status because you can not continuously monitor the serial port so you may miss some groups?

 

Sorry Guys..i think i begin to realize something especially after reading Don's advice! THANKS!

Basically what you all mean is i should monitor and decode the individual PCI returns (something like "\05...") instead of monitor & decode the whole MMI report for 256 lighting groups?

 

That's right!

Decoding the "05" messages (we refer to them as Specific Application Language or SAL commands) is what you need to do to get very fast status updates.

For the lighting Application, there is only a small set of commands to decode:

ON,
OFF,
Ramp_at_Rate_to_Level and
Terminate_Ramp.

 

Correct. If you can decode these messages you will be able to update the status of your pronto immediately.