Is there a way I can decode MMI's? I am trying to assist with some debugging for someone else and the current Cbus Diagnostic Utility gives a nice popup of Status and Level MMI's but I need to know how the popup values relate to the actual raw data. Here is an example, how can I decode the strings below to give me the levels shown in the popups? I presume I can then apply the same logic to the Status MMI's. 2011/03/30 16:32:15 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 0 2011/03/30 16:32:15 Rx : F907380B00000000000000000000000000000000000000000000BD<CR> 2011/03/30 16:32:15 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 11 2011/03/30 16:32:15 Rx : F70738160000000000000000000000000000000000000000B4<CR> 2011/03/30 16:32:15 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 22 2011/03/30 16:32:15 Tx : \05FF0073073820<CR> 2011/03/30 16:32:15 Tx : = Multipoint, Level MMI Request, Application 56 2011/03/30 16:32:15 Rx : F907382000000000000000000000000000000000000000000000A8<CR> 2011/03/30 16:32:15 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 32 2011/03/30 16:32:15 Rx : F907382B000000000000000000000000000000000000000000009D<CR> 2011/03/30 16:32:15 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 43 2011/03/30 16:32:15 Rx : F7073836000000000000000000000000000000000000000094<CR> 2011/03/30 16:32:15 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 54 2011/03/30 16:32:15 Tx : \05FF0073073840<CR> 2011/03/30 16:32:15 Tx : = Multipoint, Level MMI Request, Application 56 2011/03/30 16:32:16 Rx : F90738400000000000000000000000000000000000000000000088<CR> 2011/03/30 16:32:16 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 64 2011/03/30 16:32:16 Rx : F907384B000000000000000000000000000000000000000000007D<CR> 2011/03/30 16:32:16 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 75 2011/03/30 16:32:16 Rx : F7073856000000000000000000000000000000000000000074<CR> 2011/03/30 16:32:16 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 86 2011/03/30 16:32:16 Tx : \05FF0073073860<CR> 2011/03/30 16:32:16 Tx : = Multipoint, Level MMI Request, Application 56 2011/03/30 16:32:16 Rx : F907386000000000000000000000AAAAAAAAAAAAAAAA0000AAAAC4<CR> 2011/03/30 16:32:16 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 96 2011/03/30 16:32:16 Rx : F907386BAAAAAAAA0000AAAA00000000AAAAAAAA0000AAAAAAAA11<CR> 2011/03/30 16:32:16 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 107 2011/03/30 16:32:16 Rx : F7073876AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA969634<CR> 2011/03/30 16:32:16 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 118 2011/03/30 16:32:16 Tx : \05FF0073073880<CR> 2011/03/30 16:32:16 Tx : = Multipoint, Level MMI Request, Application 56 2011/03/30 16:32:16 Rx : F9073880AAAAAAAA0000AAAAAAAA0000AAAAAAAAAAAAAAAAAAAA54<CR> 2011/03/30 16:32:16 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 128 2011/03/30 16:32:16 Rx : F907388BAAAAAAAAAAAA0000000000000000000000000000000041<CR> 2011/03/30 16:32:16 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 139 2011/03/30 16:32:17 Rx : F7073896000000000000000000000000000000000000000034<CR> 2011/03/30 16:32:17 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 150 2011/03/30 16:32:17 Tx : \05FF00730738A0<CR> 2011/03/30 16:32:17 Tx : = Multipoint, Level MMI Request, Application 56 2011/03/30 16:32:17 Rx : F90738A00000000000000000000000000000000000000000000028<CR> 2011/03/30 16:32:17 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 160 2011/03/30 16:32:17 Rx : F90738AB000000000000000000000000000000000000000000001D<CR> 2011/03/30 16:32:17 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 171 2011/03/30 16:32:17 Rx : F70738B6000000000000000000000000000000000000000014<CR> 2011/03/30 16:32:17 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 182 2011/03/30 16:32:17 Tx : \05FF00730738C0<CR> 2011/03/30 16:32:17 Tx : = Multipoint, Level MMI Request, Application 56 2011/03/30 16:32:17 Rx : F90738C0000000000000000000000000000000000000AAAAAAAA60<CR> 2011/03/30 16:32:17 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 192 2011/03/30 16:32:17 Rx : F90738CBAAAAAAAAAAAAAAAA5555AAAAAAAAAAAA0000AAAAAAAA5F<CR> 2011/03/30 16:32:17 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 203 2011/03/30 16:32:17 Rx : F70738D6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC<CR> 2011/03/30 16:32:17 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 214 2011/03/30 16:32:17 Tx : \05FF00730738E0<CR> 2011/03/30 16:32:17 Tx : = Multipoint, Level MMI Request, Application 56 2011/03/30 16:32:18 Rx : F90738E0AAAA000000000000000000000000000000000000000094<CR> 2011/03/30 16:32:18 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 224 2011/03/30 16:32:18 Rx : F90738EB00000000000000000000000000000000000000000000DD<CR> 2011/03/30 16:32:18 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 235 2011/03/30 16:32:18 Rx : F70738F60000000000000000000000000000000000000000D4<CR> 2011/03/30 16:32:18 Rx : = Extended Format MMI, Local, Level MMI, Application 56, Block Start = 246 2011/03/30 16:32:24 Rx : 0513DF000E0207DB031E020D011020200096<CR> Here is a Status MMI extract: 2011/03/30 16:32:30 Tx : = Multipoint, Status MMI Request, Application 56 2011/03/30 16:32:30 Rx : D8380000000000000000000000000000000000000000000000F0<CR> 2011/03/30 16:32:30 Rx : = Status MMI, Application 56, Block Start = 0 2011/03/30 16:32:30 Rx : D83858000000A8A222A8AAAA6A8AA2AA0A0000000000000000E6<CR> 2011/03/30 16:32:30 Rx : = Status MMI, Application 56, Block Start = 88 2011/03/30 16:32:30 Rx : D638B0000000000000A86A2AAAAAAA020000000000000006<CR> 2011/03/30 16:32:30 Rx : = Status MMI, Application 56, Block Start = 176 2011/03/30 16:32:40 Rx : 0512D000019187<CR>
The decoding of all these bytes is spelled out in the Serial Interface Users Guide, part of the public release documents of the C-Bus Serial Protocol. Have you read that document?
Ok, I can now decode MMI's from the documentation provided. I would like to go one step further. What can I expect between C-Gate and the PCI when I enter the 'On 254/56/117' command? From my sniffer trace I see the following: <Content Removed> How do I decode the first three bytes properly?
Your sniffer trace is incomplete and does not represent a complete valid message. The C-Bus protocol documentation, whilst freely available, is only made available by accepting the licence agreement, so to discuss or disclose the details of what the low-level bytes mean on a public forum, readable by anyone, would be a breech of the conditions of the licence. I suggest you contact either the C-Bus Enabled coordinator or Clipsal Technical Support who will be able to explain that detail to you.
I only took the Data portion of the frame capture, the rest is only TCP stuff. I will drop an eMail to tech-support to see if they are willing to explain the coding of the data portion. I didn't realise that this particular section of the protocol is not made public. Ingo
There is definitely something missing... I suspect the transaction between C-Gate and the CNI is broken up over multiple TCP packets. Why are you sniffing using TCP though? For stuff like this you can look at the C-Gate log file. Nick
The C-Bus Protocol is freely available with respects to $$. It's not freely available in a legal sense as you must agree to the terms and conditions of use to gain access to the documentation. One of the conditions is that you will not distribute the content of the protocol. Posting it on a forum that does not require a log-in to view it would probably be viewed as distribution, from a legal perspective. The info as to how to send things like discrete on/off/ramp commands to C-Bus is actually described in the Serial Interface User Guide document you already have. The structure of the commands that C-Gate sends to the PCI, be they Ethernet, USB or Serial, all conform to the information in that document. Why you'd want to decode the specific mode of operation that C-Gate is using, when the serial protocol is already published, raises my left eyebrow about 30% and makes me wonder what your intentions are. If there's something specific that you're trying to achieve perhaps we can short-cut your discovery process by pointing you in the right direction.
Ok, here is the bottom line. I am helping test and develop a new Cbus application, currently it's not working as expected and me, NOT being the programmer, is trying to see why things behave in a certain way. Level-9 debug on CGate doesn't give me the actual data sent from the application unless I am missing something. Knowing what to expect on the Ethernet I can then make the comparison from the same command sent from the application. If there is a difference then I know the format of the command sent is not 100% correct. If the command sent via the application is similar to the one generated from within C-Gate then I have to look elsewhere. Fairly straight forward and nothing illegal or eyebrow raising in my intentions.
Odd... level 9 logs should show you vast amounts of gory detail. However, be aware that c-gate does exploit an addressing shortcut of the PCI, and so you may see what appear to be incomplete messages. If they don't start with "\" then it means that specific addressing was sent/set in a prior message, and the shortcut is then used to reference the same address in later messages.
The trouble you will have in looking at the messages that C-Gate is sending to the C-Bus interface is that they change format depending upon what mode C-Gate has the C-Bus Interface running in. C-Gate has been around for many years and is pretty tough code now. You'd be better to monitor the C-Bus network using the Diagnostic Utility (recent versions disclose much more of the actual C-Bus network traffic) and compare what it sees on the network with what you're sending to C-Gate. If the two don't match, the issue is almost certainly in what the 3rd party application is sending to C-Gate. As NickD says, the commands sent to the Ethernet interface can be broken up over multiple TCP packets, so you'll need to hunt through the Ethernet traffic to piece together the data in the packets that go together to make a single command sent to the C-Bus interface. Quite tedious, and very unlikely to be where your problems are coming from. Event level 9 does give you just about everything and does show you what is being sent to the C-Bus Interface.
Ok, I will try the level-9 debugs again and use the diagnostic utility. Looking at the Ethernet frames will be much harder to decypher than I initially thought. Thanks for the valueable feedback. Ingo
It's a little unclear what you are actually doing here.. You mention intercepting TCP frames between C-Gate and a PCI... this is a serial connection, so there is no TCP connection... so I assume either you mean a CNI, or you are actually looking at the socket connection between an application like Toolkit and C-Gate. If it is the latter, then this connection encrypted to protect against people reverse engineering the (not publicly released) commissioning process/protocol, which, if used incorrectly, has the capacity to cause irreversible damage to units. Perhaps you can tell us a bit more about : - how your application connects to C-Bus (ie does it connect to a PCI/CNI directly, or does it connect to C-Gate?) - what you are trying to do to debug it (you appear to be using C-Gate, but it's not clear what you are doing with it). Nick
Nick, Yes, it is a CNI and what I am doing is to send a command from the New application via CGate to the bus. This command does function X. I then do the same command directly on CGate EG 'On 254/56/117' to see if the results are the same. Fairly simple though. With the Application not doing what it's supposed to I am trying to figure out if there is a hidden character, or something in the formatting, that is sent along to CGate which might cause it to not recognise the application's command. It is entirely possible that the application's command format has a non-printable character in there somewhere that I need to identify. Basically, once the manual CGate command and the application generated command string is reliable and identical I am stepping off this topic and will be focussing on other areas. I need to know the basics are working flawlessly before I try and get the features going.
