CBUS messages I cant seem to decipher

I am trying to understand a message coming from my CNI, and cant seem to figure out where it is coming from. I have a very small and basic clipsal setup, commands look like:

0508FF001EFFE7966F8B8AD6
0505FF001EFFE7966452CED9
050DFF001EFFE7897BA76FD1

So 05 means it is a lighting command. I would expect the next to to be the origination address, and the next 2 to be the app address ("FF" in the above messages, which doesnt jive with what I would have expected from standard lighting commands)

Below is a command that I do recognize:
052B3800015F38

Which translates to:
{ messagetype: '05',
originator: '2B',
appaddress: '38',
fbyte: '00',
command: '01',
group: 95,
commandtext: 'off',
status: 'off',
level: 0 }

Anyone seen these kind of messages before? Any help you could give would be greatly appreciated.

 

In the manual I found this note:

"Application address $FF is reserved for network management functions and must not be used."

Does anyone know if I can safely just ignore these messages intended for app address FF, like the ones I am receiving above? I just dont want to go dropping messages if they have data I should be aware of or need to do something with?

 

Thanks Nick, and thanks for the clarification on '05', as I reviewed the full spec closer you are correct, nothing specific about 05 being only lights.

I had originally used this doc: http://training.clipsal.com/downloads/OpenCBus/C-Bus Quick Start Guide.pdf

In section 7.1 it states that the 05 on the front identifies the message as a lighting message, and that is where I got led astray originally.

 

An old thread, but hey, that's how I roll.

I initially thought that the received message transmitted from the PCI to the serial interface would start with 03, 05, 06 as a means of knowing if it were a P-MP, P-P, etc but it appears not to be the case after looking at the protocol documents a little closer. So the sending command would use these different headers depending on whats being sent to where, but the received message would always be 0x05 if it were a SAL message in SMART mode or 0x86 for a CAL message.

Would this be a correct interpretation of the protocols?

Cheers,
Paul

 

Hi Nick,

Thanks for the response. Are you also talking about the reply to a CAL command. The documentation on the CAL reply (4.3.3.1 CAL Reply) would suggest that the first byte for a long form reply is simply 0x86.

Same for a SAL lighting type message (4.3.3.2 Monitored SAL) where sending a command would start with the Header byte, being message type + priority but a reply would still start with 0x05 as defined explicitly in the Serial Interface Guide.

Regards,
Paul

 

Yup, that's pretty much what I figured, the documentation for the protocols seems to be almost there but has gaps unfortunately. I guess an example of this would be in interpreting the 4 bytes returned for a serial number. Who'd have thought gluing the first 2.5 bytes to the last 1.5 bytes to get the serial number

Have picked this up after a couple of years ignoring now that I have a web interface sorted out.

Cheers,
Paul