Bridging applications and control via PCI using Local SAL

KevinH · Jul 12, 2006

I have a wireless network with application bridging on the lighting app. All works well. On the wireless side I have an output channel set to group 23. On the wired side if I have group 23 setup in a dimmer channel then I can issue a serial PCI command to group 23 on the local wired network and the wired and wireless group 23 change. If however group 23 is only present in a key input unit on the wired (I remove the group 23 in the dimmer and put it back to a key input) then the PCI command doesn't control the wireless output channel, however the key input on the wired DLT does though.

The Local SAL option is set on the PCI (bit 1 param 42) and I understood from the PCI docs then that the PCI should appear identical to the DLT key input..... what am I missing here ?

Kevin

The PCI options I have set are CONNECT+SRCHK+SMART+MONITOR+IDMON and PCN+LOCAL_SAL+PUN+EXSTAT and the checksum is correct on the latter group

ashleigh · Jul 12, 2006

What firmware version is your PCI?

KevinH · Jul 12, 2006

Actually it's a SIM module v 4.2.00

K

ashleigh · Jul 13, 2006

PCI or SIm, version 4.2, should be just fine.

In the document "Cbus Interface Requirements", check the section on initialising the interface - carefully - and make sure you have set the appropriate modes.

The PCI or SIM will generate messages that pass through A SINGLE bridge that is linking two networks, provided the PCI/SIM is in LOCAL_SAL mode.

If you want two networks to be joined, make sure you have it symmetric by setting each side of the bridge (or gateway) appropropriately (usually the same).

KevinH · Jul 13, 2006

Hi Ashleigh - The bridge is I'm fairly sure set up correctly and certainly pressing a key input on either side changes the corresponding group on the other. I have also checked the SIM interface options 3 settings for the SIM by using C-Bus diagnostics via another PCI and interrogating the other SIM and that shows that Local_SAL is enabled and the other settings are as above.

What is strange is that if I create the group in a dimmer channel it works, its only when the groups is only present in a key input (or not present at all) that it fails. I'm just exploring Diagnostics to see what I can get at in terms of C-Bus messages that might help here.

Kevin

<edit> ... Ah hang on a sec..I think I've worked out what's wrong here (my oversight) - I think that when a group is only present in the key unit then MMI info shows the group as non existant and hence my own copy of the state table is blocking the command going out, occasionally after the group changes state I have inconsistent state table info caused by monitoring group changes that allows me local control but the next MMI wipes it out again. If I use a dimmer for the group it would of course work as MMI's match.

Richo · Jul 14, 2006

KevinH said:

Ah hang on a sec..I think I've worked out what's wrong here (my oversight) - I think that when a group is only present in the key unit then MMI info shows the group as non existant and hence my own copy of the state table is blocking the command going out, occasionally after the group changes state I have inconsistent state table info caused by monitoring group changes that allows me local control but the next MMI wipes it out again. If I use a dimmer for the group it would of course work as MMI's match.
Click to expand...

Yes, that seems like the likely cause.

ashleigh · Jul 14, 2006

Ah yes, indeed.

WRT MMI's:

You can use MMIs as a means detecting current group states, and for detecting errors (two output units report a different state), and discrepancies (outputs disgree with inputs).

Using MMIs to determine EXACTLY which groups are present in a network is prone to error, because it only reports groups present in output units. If you have other groups being used for magical purposes, the MMI is not your friend, because it does nothing for you.

KevinH · Jul 14, 2006

Thanks guys - and I believe I'm almost there now. I assume there was some reason that keyinputs don't contribute to MMI info , perhaps a capability/resource one.

On a related issue AIUI it is not possible for an externally connected 3rd party device (eg via a PCI) to participate in updating that MMI info either - perhaps to artificially maintain a group. This being a PCI restriction/feature. Is there an available 'low cost' Clipsal product that offers group maintenance of say 16 groups within the MMI that could soley be used for that purpose ? Perhaps like a dimmer with no dimmer electronics - just the C-Bus stuff, I am also assuming no software product could do this eg C-Gate ? If not maybe such a device would be useful , and could be engineered fairly readily from a dimmer or similar with the mains voltage parts removed......

Kevin

ashleigh · Jul 14, 2006

KevinH said:

... I assume there was some reason that keyinputs don't contribute to MMI info , perhaps a capability/resource one.
Click to expand...

If you read the sections in the lighting application documentation about MMI Mastering, Discrepancies and error detection / correction it becomes apparent that key units must initiate MMIs (so they can do the checking), and output units populate MMI's (to let the initiating units know what is going on).

Therefore, you cannot sensibly have an input unit which contributes to an MMI.

On a related issue AIUI it is not possible for an externally connected 3rd party device (eg via a PCI) to participate in updating that MMI info either - perhaps to artificially maintain a group. This being a PCI restriction/feature. Is there an available 'low cost' Clipsal product that offers group maintenance of say 16 groups within the MMI that could soley be used for that purpose ? Perhaps like a dimmer with no dimmer electronics - just the C-Bus stuff, I am also assuming no software product could do this eg C-Gate ? If not maybe such a device would be useful , and could be engineered fairly readily from a dimmer or similar with the mains voltage parts removed......
Click to expand...

See above. There are no plans to produce such a device, and to do so in a PCI is far from trivial. There are also m ore fundamental issues to resolve, for such a device.

For example: a PCI is primarily a protocol translation device - it has no inherent knowledge (of itself) of the groups that are of interest to the serial-connected thingy.

So, which groups should the PCI maintain? If any? And how does the serial-connected device tell it which ones to play about with? And in the event of an update, which device (the PCI or the serial-connected one) is the master in charge of updating / maintaining the state of the group?

These issues put it firmly in the very-hard basket. The only time that it is essential to contribute to an MMI is for a new output device. In that case, CIS offer the "GOC" - under separate license agreement, and at CIS discretion.

Don · Jul 17, 2006

Kevin

If you have any output device on the network, it might be useful to take advantage of the fact that all the groups available for 'logic' will provide a contribution to the MMI, even if the group is not associated to affect the state of an output terminal. You could use these groups to achieve your MMI contribution for your group 23.

Don

Bridging applications and control via PCI using Local SAL

KevinH

ashleigh Moderator

KevinH

ashleigh Moderator

KevinH

Richo

ashleigh Moderator

KevinH

ashleigh Moderator

Don

Want to reply to this thread or ask your own question?

Bridging Matrix Switchers

Applications and Trigger Control

Using Using a Shutter Control Relay as a Change over Relay

Bridging 2 Wired networks wirelessly

"bad SAL"/"unknown cbus" command/response

Bridging 560125R Remote Amplifier?

network bridging

CBUS control via C-bus PCI

Bridging applications and control via PCI using Local SAL

ashleigh Moderator

ashleigh Moderator

ashleigh Moderator

ashleigh Moderator

Want to reply to this thread or ask your own question?

Useful Searches