Problems with Custom model in Mesh App

[julian.demicoli]

Hello, 

i am currently trying to add my own model to the Mesh Android App. It should just be a simple sensor model. 

It already works to have an own Window, where I can send a custom get Command. On the microcontroller side the get command is also received and a message is returned. 

The problem is, that the message is parsed wrong on the app side. The App thinks, that the Access pdu is an array with 12 entrys, so the opcode can not be used correctly. 

I do not know where the error comes from, I was trying to understand where in the meshprovisioner software stack the access message length is set but i could not find it. 

Here you can see, that the access PDU actually consists of the right elements 0x82C2 is actually my opcode but has 10 extra bytes.. 

What should also be mentioned is, that the Bluetooth message consists of 5 Bytes which are the sensor Values, so there are also 5 Bluetooth parts sent. Maybe this causes the error 

Thanks in advance

Best regards

Julian Demicoli

[julian.demicoli]

I actually found the problem. I was wrong on that the access message length. The problem is, that there is a bug in the app itself. 

In this function (located in MeshParserUtils.java) the opCode is returned as a short. Afterwards it is used as a int, so I am having a negative number even if it's the same in hex in further processing of the opCode. 

[Roshan Rajaratnam]

Hi there is a bug in the mesh sdk causing the vendor model opcodes to be parsed in the wrong endianness. So all messages sent and received will have in big endian instead of little endian. This bug is fixed internally and probably be out in the next mesh release. The Mesh App is using the correct endianness hence its breaking for you. What you may do is to swap your opcode around in the fw and it will work for you. Also if i'm not mistaken, your opcode seems to be wrong according to the spec. All vendor models must have a 3-octet opcode according to page 93 on the mesh profile spec, so the 2 most significant bits are 0b11.

Anyways like i mentioned this is due to the endianness bug in the mesh sdk as of now. Hope this helps

[julian.demicoli]

Hi, thank you very much. This could be the reason why the messages arrive in the wrong sequence. 

I used a fake Sigmodel opcode to decrease the implementation time just for evaluation of how the app works.

I have one more question. Is the android app also suitable for receiving messages, which have been published by the microcontroller? For example if I want to connect to a sensor which publishes a signal if the sensor values go to dangerous values. (Or should I open a new ticket for it?) 

Best regards

Julian Demicoli

[Roshan Rajaratnam]

Well the sequence of the messages may not always be in the correct order when it comes to segmented messages, that's something the library handles as the messages may be relayed via different nodes. The order is never guaranteed but this is handled in the lower transport layer of the network. Once or if all messages are received successfully it will be reassembled in the correct order and sent to the upper transport layer and the access layer.

A new ticket would be much appreciated to for a newer question

And don't forget to accept the answer if it helps ;)

Roshan

[Oleh]

Hello Roshan,

we experience the same with the sdk 3.2.0... was is fixed or postponed?

[kc89rst]

Hello, what is the status regarding this bug, 'cos it looks it is not fixed in the current version of the SKD (3.2.0)? Can you provide the patch for fixing this in the SDK, or we have to struggle with ugly hacks?