Optimising comms via C-Gate

A couple of observations from my test system:
If I send 255 commands immediately after each other:

Code:

ON /254/56/0
ON /254/56/1
...
ON /254/56/254

.. then C-Gate returns pretty fast (well under a second), although the actual process of turning the lights on will continue for about 10s. (I can control this with the speed-write parameter, I assume, but haven't tested that.)

If, while the ON's are happening, I query the status of the groups with

Code:

GET /254/56/0 level
GET /254/56/1 level
...
GET /254/56/254 level

.. then I get back the actual status, ie some will be on and others off.

If, instead of sending ON to 254 different addresses, I repeatedly send ON to (say) group 0, then it takes as long as it takes to send to 254 different addresses, so there's no optimisation taking place to detect the duplication.

So, my questions:

• Is there any way to find the "pending" status, ie to see the level that was last set even if the command hasn't gone to the unit yet?
• Is there any setting I've missed that would make C-Gate combine multiple buffered commands to the same group?

I can do some of this in my own application logic if necessary but I don't want to re-invent the wheel if C-Gate can do it. It seems to me that it would be useful for C-Gate to do it (at the very least spotting that it has several commands queued for one group address and removing any duplication), which also makes me think it might already be there somewhere and I'm looking in the wrong place!

 

If you send the same message more than once, C-Gate will send then all to C-Bus. There are cases where this is the desired behaviour, so C-Gate does not attempt to filter these out.

 

Fair enough.

In that case, is there any way to get back the buffered status, ie so that:

Code:

ON /254/56/1
GET /254/56/1 level

.. returns the level as 255, even if that command has yet to go out to C-Gate? (Or an alternative to GET that would do this?)

Out of curiosity, does C-Gate even "know" itself? Or does it just have a large buffer that it sends as/when it can without any real concept of what's in the buffer? Is there any way for my application to check the size of the comms buffer to know whether it's being filled faster than it's emptying?