[TW#14142] Bluetooth Mesh support (IDFGH-763)

[OtherCrashOverride]

Support for the new Bluetooth Mesh standard needs to be addressed.

[ngonhatnhi]

@Yulong-espressif Can you tell us released plan of ESP BLE Mesh ? We had to wait in very long time...

[Shannon-I-am]

@ramams and @ngonhatnhi, I guess there was a problem with the test.

[ngonhatnhi]

I will attempt to contact Espressif biz service, hope that we 'll get some news about BLE Mesh

[Yulong-espressif]

Hi, @all, Thank you for your continued attention to BLE Mesh. At present, ESP32's BLE Mesh has been opened to the second batch of customers for testing. Due to business considerations, we are not yet able to publicly release the BLE Mesh version. If you need it urgently, please contact our business department. I am sorry for the inconvenience caused to you.

[ngonhatnhi]

@Yulong-espressif Hello Mr.Yulong, i can not find email and phone number of your biz deparment in espressif.com , so can you help me ?

[Shannon-I-am]

With such lack of clarity and inability to keep to schedules I'm switching from Espressif to Nordic.

[jo-nas]

What about this? https://github.com/espressif/esp-mdf

[Shannon-I-am]

@jo-nas that uses wifi, so although it may be relatively low power it's not going to be able to provide the battery-life of a BLE Mesh network.

[ReanimationXP]

@Yulong-espressif any update on public release?

[hardikharpal]

@Yulong-espressif Will it be available for public release? Not asking about time frame.

[toxuin]

I think we should bump this more often.

[sthenc]

This is taking so long I completely lost interest in this.

With this not being done more than a year after the initial plans (and no one reverse-engineering the thing), I think it might even be possible they had some sort of silicon bug. Priority customers usually get the engineering samples first for the new silicon, and this is probably how long it takes to fix that sort of bug.

But I am not sure which is more disturbing, complete lack of transparency regarding that, or restricting access to basic functionality that the competitors have had for a year or so now.

[DevyatovAndrey]

@Yulong-espressif any update on public release?

[bwannduke]

@Yulong-espressif any update on public release? A road map of this would be good, agreed.

[Isl2017]

Hi, All

Thanks for your interest in our ESP32 and BLE Mesh.

About the BLE Mesh development

• In order to make the most of our limited human resource on the development of new “BLE Mesh Features”, currently the ESP BLE Mesh SDK is not public and is provided only to some internal-test customers.
• The latest version of ESP BLE Mesh is “ESP-BLE-Mesh-v0.5” and it has been just provided to our round-2 internal test customers.
• If you want to participate in our internal test, it is recommended to contact our Business team for more information
• So currently there is no exact public release plan. If your project is urgent, please participate in our internal-test

Note: “ESP-BLE-Mesh-v0.5” supports the following features

1. Provisioning
   • Support PB-ADV and PB-GATT bearers
   • Add Provisioner feature
2. Networking
   • Support relay, segmentation, etc
3. Proxy Support
4. Foundation Models
   • Configuration Server Model
   • Configuration Client Model
   • Health Server Model
   • Health Client Model
5. Generic Client Models
   • Generic OnOff Client
   • Generic Level Client
   • Generic Default Transition Timer Client
   • Generic Power OnOff Client
   • Generic Power Level Client
   • Generic Battery Client
   • Generic Property Client
6. Lighting Client Models
   • Light Lightness Client
   • Light CTL Client
   • Light HSL Client
7. Sensor Client Models
   • Sensor Client
8. Time and Scenes Client Models
   • Scene Client

[chegewara]

Glad to hear that rest of us (read most of us) are not important customers.

[Isl2017]

Glad to hear that rest of us (read most of us) are not important customers.

I'm sorry for my inappropriate description. But I hope you can understand us. As of right now, we have accepted all the customers provided by our BS team who applied for the internal test. Please contact the business team if you really need it currently, thanks :)

[chegewara]

@Isl2017 I dont need it urgently, probably i dont need it at all, but i would like to participate in test. Its not like that i feel i am good at bluetooth, but as you said, you are having limited human resources.

[Isl2017]

@chegewara Really thanks a lot for your attention and support. We hope that our BLE Mesh is somewhat stable and can support most necessary features when we release it. Hope again for your understanding :)

[chegewara]

Thats the problem i dont understand. Thinking like that then whole esp-idf stack should be closed for only few testers, because there still is a whole bunch of issues/bugs. Dont get me wrong, i dont complain about that. This is big project and i know that a lot good programmers are working on it. When first version of esp-idf has been released how well developed it was?

What you said about being important customer, i understand that too. I am not important to you (espressif) because i wont buy 10, 20 and maybe even 100k chips/modules. But i would rather prefer to wait for ble mesh not knowing that. So your statement was very loud and clear.

Have a nice day.

[Isl2017]

To apply for the internal test, please feel free to submit your demands here : https://www.espressif.com/en/company/contact/pre-sale-questions-crm

The submitted questions will be transferred to our CRM system directly, and the BS team will get back to you asap.

[ReanimationXP]

I agree that the entire point of open source is being missed here. Opening it up to others would allow them to assist you with pull requests. Nobody is going to bash you for a properly-marked experimental beta not working correctly.. if anything they would try to help get it working and flesh out the featureset.

Secondly, you shouldn't need details on whatever project we're experimenting with or a personal consultation in order to share some framework code with us and let us determine if it's presently useful for us or not. Quite frankly, that's insulting that you need to decide if our project is good enough or not. It sounds to me like you're focusing too much on personal partnerships instead of getting the average developer comfortable with new features of your product. You can trust that the latter will go a lot further in future sales.

[chegewara]

@Isl2017 Little offtopic:

@chegewara Really thanks a lot for your attention and support. We hope that our BLE Mesh is somewhat stable and can support most necessary features when we release it. Hope again for your understanding :)

To be honest i dont think that espressif team cares about my attention or support at all. But here is the thing, i dont feel like i have skills to prepare some PRs in esp-idf or even arduino-esp32 repository. I really suck at programming skills, but i have plenty of time at my regular work and i can do whatever i want, watch tv or play games or play with any other hardware. So why i am spending so much time with esp32? Because i think its very nice piece of hardware which can be used to build so many cool stuff. But thats not all, here on esp-idf repository issues i have contact with few people (i am opening a lot issues), and personally i think good about them. Thats why i think its worth to support esp32 and this project. For some reason support for ble and bluetooth in generally on forum is very poor, its main reason i am opening so many issues here.

But what i want to say. I dont want to start storm in the glass of water, i am just trying that you guys have support from community and we community prefer rather to have piece of software with basic functionality to learn it, to help you make it better etc rather than be treat like that. There was announcement that we get mesh in april, then july and so on, now we hear that we are not important customers and we get it when we get it. This personally makes me feeling that ive been wrong and i become feeling i want to quit this and just play with project that @nkolban start. This gives me fun and pleasure because all what i am doing someone else will shows me appreciation just by using piece of code i write.

[bwannduke]

I definitely agree with getting early-alpha out to the community, but there is a fine line with open-source, specifically with a commercial offering of hardware behind it. If Espressif releases initial releases that are buggy as hell, and not even the slightest ready, it reflects poorly on them, and they are pushing a new model of open-source in an embedded space to cutthroat and historically very proprietary and litigious. I think it is the most important message to send to them as the community of devs that want to work on this product platform, that their product is being adopted, and that the community of developers themselves have helped to establish ESP's brand in the market as an open platform, and that we are ready to dive in and help them release this product to the market.

[todduk]

Please stop whining.

[bwannduke]

Going to pass on this flame bait

[ReanimationXP]

ESP32 already has an established foothold, nothing they release at this point is going to harm the product or the brand, so that excuse is crap. Besides that, they are already in the testing phase and have been for months, so they already have something that is at least somewhat functional. This is what alphas and betas are for. Just because you might not be comfortable with submitting PRs, that doesn't mean the rest of the world isn't. There's still plenty of stuff you could do such as documentation to help them out that they would be wasting time on internally because they didn't open source the project.

[denyip]

@Isl2017 , I have followed your instruction to submit the application form for internal testing, but there is no any reply at all.

[Isl2017]

@chegewara @ReanimationXP @bwannduke Thanks for all your suggestions. I keep listening to your comments and thinking over whether it is possible to release BLE Mesh SDK earlier. Please help understand that "BLE Mesh is not somewhat stable now" is not the only reason why we decided to release it later, but there are some other considerations.

For example, we need to observe our “IDF breaking change rules” once it is merged into the IDF. That means, once “BLE Mesh feature” is merged to the IDF, we can’t add breaking changes (like API modification) to the IDF except for a major IDF version (like IDF 3.0, 4.0, etc). It will limit our mesh development. Currently, I have been discussing with our IDF team to see if it is possible to add "BLE Mesh feature" as a beta version and not observe this "breaking change rule".

We will try our best to resolve those difficulties, release BLE Mesh SDK earlier and hope that you could understand our difficulties. Please help wait for some more time and we will publish an announcement here once we have any updates for release.

[Isl2017]

@denyip I have checked with our Business team and they have not found the requirement with keyword "denyip". Could you re-submit your requirement and leave your "requirement message title " here? We will re-check it.

[pctj101]

Probably reasonable to put such unstable API code in a branch so that it's pretty obvious the API is under development. If it gets fewer updates/gets out of sync with master/gets totally rewritten prior to release, so be it.

[Isl2017]

@pctj101 Yes, it is another solution we are considering. The problem we encounter for this solution is:

• Because we separate the features of IDF and the features of BLE Mesh;
• So for some features that we need to modify the IDF, we will merge it into the IDF firstly and then rebase our BLE Mesh branch (we will not introduce breaking changes when we add the features for IDF)
• In this case, if we use this solution (put the BLE Mesh feature in a branch), it might difficult for us to manage different versions
• Because once we rebase the BLE Mesh branch, the customer can’t revert to the older version

[pctj101]

Yeah sounds like to minimize pre-release work, a non-maintained dead-end branch may be more fitting. A branch which kinda works but is not scheduled to get any updates. Perhaps even if tight on time, without full integration with the IDF.

Any updates would go into another branch which might have no easy migration path.

It might not be convenient for early developers but sometimes thats the cost of being on the bleeding edge. If you set the expectations for support/roadmap (for example “no support/not taking PRs yet” then there’s little basis for complaint).

Each developer eventually needs to learn for themselves when they have sufficient skill to use a API in various stages of the lifecycle. If it’s too hard then wait.

Anyways good to see your team is considering various options!

[ReanimationXP]

@Isl2017 Yes, thanks for listening and providing some rationale. It's understandable that Mesh requiring changes to the IDF which would break existing apps is not a great solution to push out before that version of the IDF is ready.

I'm on board with @pctj101's suggestion of a dead-end branch of the IDF which includes the necessary changes for Mesh, such that we could play with it in the same environment you develop on. I will add that it would be a good idea to suggest that users simply clone down a second copy of the "beta" IDF specifically for working with Mesh. Once you merge the changes into the next major IDF version, the user would simply update their main IDF as normal, and then projects written for mesh would likely transfer over with little to no issue.

Thanks again for listening rather than taking offense, and for giving us some additional background :)

[pctj101]

There might be a case where some devs decide to submit high numbers of issues/tickets for the BLE Mesh, even though it's been publicly stated that it's unsupported.

In that case, it might be good to make a separate esp-blemesh-beta repo for example and just blackhole all the tickets (or read them later when ready to release officially).

[ReanimationXP]

Again I agree, getting issues / tickets for something that is clearly in beta would not be great, so a separate repo entirely might be wise. Additionally or alternatively, marking it as an alpha might discourage issue creation further. Our intent definitely isn't to hamper development with bogus tickets.

[chegewara]

It is possible that wifi mesh is in separate repository, esp-adf too, even if its in very early stage. Both are linked to esp-idf particular commit. I am listening all arguments and still dont see reason why it cant be put in separate repository if so many function is already implemented. I dont know if you remember what situation with esp-idf was about year ago or so. There was group of people complaining that esp-idf is so bugged that should not be released. But some of users, including me kept telling them it is staged as beta and its normal that we have bugs. esp-idf survived such complaining people but thanks to issues reported by community it was developed to stage we have today so much faster in my opinion.

I understand that espressif decision is we wont have access to bt mesh yet and to be honest i dont need explanations and rational arguments. Frustrating is that since this issue has been opened we got few possible dates when we get it, then about half year without update and now this. "We have nice looking working beta version but it is for few chosen people only".

[erikwilson]

@Isl2017 A Beta repo of esp-idf would be awesome, would have more devs willing to contribute and test!

More transparency in the way of code in development is always better! There appears to be a similar situation with LLVM, Cadence apparently has a working Xtensa LLVM backend for paying customers, and there are a handful of aborted open source attempts to create one, likely abandoned because there are rumors Espressif will release one themselves.

[Isl2017]

Hi, All

Thanks for all your brainstorms.

We have created a temporary BLE Mesh branch on Github now.

It is now allowed to clone the BLE Mesh project:

• Branch: feature/esp-ble-mesh-v0.5
• BLE Mesh APIs & Core code: components/bt/ble_mesh
• BLE Mesh Examples: examples/bluetooth/ble_mesh

Please help understand that this is a beta version and I think there's still a lot to be improved.

We hope to receive your suggestions about the ESP BLE Mesh SDK. So if you have any issues/advice/questions/feature requests, don't hesitate to raise issues on Github.

When you raise issues/questions/requests, please help add a tag of BLE Mesh to the issue title, so that we could quickly recognize and track. Thanks.

[pctj101]

Sweet! It's clear your team has put plenty of time into developing BLE Mesh to this point. Thanks for sharing it out here!

[chegewara]

@Isl2017 Thanks you for very good tutorials. As always nice job.

[Isl2017]

@pctj101 @chegewara Thanks for your approvals. We are going into it 🙂

[chegewara]

@Isl2017 I was harsh, but that does not mean i dont appreciate hard and good work you all are doing. Ive seen all ble tutorials and they are very helpful. When i can i paste link to it. Its always nicely write, easy to understand and all info needed to understand API usage.

[chegewara]

I have to say BIG thank you for releasing beta version. I had not much time to play with it so far, but i love it. I dont know yet which android provisioner i like more, with silicon labs we have options to easy switch all available server configs like proxy, relay or element type. In other hand is not recognizing more than one element per node (maybe its esp32 issue see ad1) even if is assigning all necessary unicast addresses. Second provisioner is nRF Mesh, which is not as easy to use, but is recognizing all elements in one mesh node (3 in my tests). I could not find option to turn on/off relay or proxy like in Silicon lab app, but there is more options to manage mesh node.

AD1: I dont want to open issue yet, because i dont know if this is issue or just i am initializing elements in node wrong way. This is log i am getting:

E (448) BT_LOG: btc_mesh_model_op_add, Invalid model operation min_len = 1073486928, or param
callbak = 0x3ffc1d48, the last valid opcode = 0x0
E (448) BT_LOG: btc_mesh_model_op_add, Invalid model operation min_len = 1073486928, or param
callbak = 0x3ffc1d48, the last valid opcode = 0x0
E (458) BT_LOG: btc_mesh_model_op_add, Invalid model operation min_len = 1073486928, or param
callbak = 0x3ffc1d48, the last valid opcode = 0x0

Code:

static esp_ble_mesh_model_t root_models[] = {
    ESP_BLE_MESH_MODEL_CFG_SRV(&config_server),
    ESP_BLE_MESH_SIG_MODEL(ESP_BLE_MESH_MODEL_ID_GEN_ONOFF_SRV, onoff_op, &onoff_pub, &led_state[0]),
};

static esp_ble_mesh_model_t root_models1[] = {
    ESP_BLE_MESH_MODEL_CFG_SRV(&config_server),
    ESP_BLE_MESH_SIG_MODEL(ESP_BLE_MESH_MODEL_ID_GEN_ONOFF_SRV, onoff_op, &onoff_pub, &led_state[1]),
};

static esp_ble_mesh_model_t root_models2[] = {
    ESP_BLE_MESH_MODEL_CFG_SRV(&config_server),
    ESP_BLE_MESH_SIG_MODEL(ESP_BLE_MESH_MODEL_ID_GEN_ONOFF_SRV, onoff_op, &onoff_pub, &led_state[2]),
};

static esp_ble_mesh_elem_t elements[] = {
    ESP_BLE_MESH_ELEMENT(0, root_models, ESP_BLE_MESH_MODEL_NONE),
    ESP_BLE_MESH_ELEMENT(0, root_models1, ESP_BLE_MESH_MODEL_NONE),
    ESP_BLE_MESH_ELEMENT(0, root_models2, ESP_BLE_MESH_MODEL_NONE),
};

Even when i am getting those errors nRF Mesh is recognizing that node has 3 elements and i can get/set value for each element. There is one more small issue i dont understand. When with Silicon labs provisioner i have provisioned mesh node and then i turn off proxy i am getting this message constantly repeated every 10 sec:

W (1872995) BLE_MESH: No subnets to advertise on
W (1882995) BLE_MESH: No subnets to advertise on

Anyway, i just want to say one more time 🥇 Thank you espressif team.

[wnnwoo]

How about the latest mesh status?

[jeromeDms]

I have to say BIG thank you for releasing beta version. I had not much time to play with it so far, but i love it. I dont know yet which android provisioner i like more, with silicon labs we have options to easy switch all available server configs like proxy, relay or element type. In other hand is not recognizing more than one element per node (maybe its esp32 issue see ad1) even if is assigning all necessary unicast addresses. Second provisioner is nRF Mesh, which is not as easy to use, but is recognizing all elements in one mesh node (3 in my tests). I could not find option to turn on/off relay or proxy like in Silicon lab app, but there is more options to manage mesh node.

AD1: I dont want to open issue yet, because i dont know if this is issue or just i am initializing elements in node wrong way. This is log i am getting:

E (448) BT_LOG: btc_mesh_model_op_add, Invalid model operation min_len = 1073486928, or param
callbak = 0x3ffc1d48, the last valid opcode = 0x0
E (448) BT_LOG: btc_mesh_model_op_add, Invalid model operation min_len = 1073486928, or param
callbak = 0x3ffc1d48, the last valid opcode = 0x0
E (458) BT_LOG: btc_mesh_model_op_add, Invalid model operation min_len = 1073486928, or param
callbak = 0x3ffc1d48, the last valid opcode = 0x0

Code:

static esp_ble_mesh_model_t root_models[] = {
    ESP_BLE_MESH_MODEL_CFG_SRV(&config_server),
    ESP_BLE_MESH_SIG_MODEL(ESP_BLE_MESH_MODEL_ID_GEN_ONOFF_SRV, onoff_op, &onoff_pub, &led_state[0]),
};

static esp_ble_mesh_model_t root_models1[] = {
    ESP_BLE_MESH_MODEL_CFG_SRV(&config_server),
    ESP_BLE_MESH_SIG_MODEL(ESP_BLE_MESH_MODEL_ID_GEN_ONOFF_SRV, onoff_op, &onoff_pub, &led_state[1]),
};

static esp_ble_mesh_model_t root_models2[] = {
    ESP_BLE_MESH_MODEL_CFG_SRV(&config_server),
    ESP_BLE_MESH_SIG_MODEL(ESP_BLE_MESH_MODEL_ID_GEN_ONOFF_SRV, onoff_op, &onoff_pub, &led_state[2]),
};

static esp_ble_mesh_elem_t elements[] = {
    ESP_BLE_MESH_ELEMENT(0, root_models, ESP_BLE_MESH_MODEL_NONE),
    ESP_BLE_MESH_ELEMENT(0, root_models1, ESP_BLE_MESH_MODEL_NONE),
    ESP_BLE_MESH_ELEMENT(0, root_models2, ESP_BLE_MESH_MODEL_NONE),
};

Even when i am getting those errors nRF Mesh is recognizing that node has 3 elements and i can get/set value for each element. There is one more small issue i dont understand. When with Silicon labs provisioner i have provisioned mesh node and then i turn off proxy i am getting this message constantly repeated every 10 sec:

W (1872995) BLE_MESH: No subnets to advertise on
W (1882995) BLE_MESH: No subnets to advertise on

Anyway, i just want to say one more time 🥇 Thank you espressif team.

Hi chegewara, I'm facing the same issue, was wondering if you find a way to declare multiple elements within a single device ? Thanks

[chegewara]

Hi chegewara, I'm facing the same issue, was wondering if you find a way to declare multiple elements within a single device ? Thanks

In fact i did. This is code i changed:

static esp_ble_mesh_model_t root_models[] = {
    ESP_BLE_MESH_MODEL_CFG_SRV(&config_server),
    ESP_BLE_MESH_SIG_MODEL(ESP_BLE_MESH_MODEL_ID_GEN_ONOFF_SRV, onoff_op,
    &onoff_pub, &led_state[0]),
};

static esp_ble_mesh_model_t root_models1[] = {
    // ESP_BLE_MESH_MODEL_CFG_SRV(&config_server),
    ESP_BLE_MESH_SIG_MODEL(ESP_BLE_MESH_MODEL_ID_GEN_ONOFF_SRV, onoff_op,
    &onoff_pub, &led_state[1]),
};

static esp_ble_mesh_model_t root_models2[] = {
    // ESP_BLE_MESH_MODEL_CFG_SRV(&config_server),
    ESP_BLE_MESH_SIG_MODEL(ESP_BLE_MESH_MODEL_ID_GEN_ONOFF_SRV, onoff_op,
    &onoff_pub, &led_state[2]),
};

static esp_ble_mesh_elem_t elements[] = {
    ESP_BLE_MESH_ELEMENT(0, root_models, ESP_BLE_MESH_MODEL_NONE),
    ESP_BLE_MESH_ELEMENT(1, root_models1, ESP_BLE_MESH_MODEL_NONE),
    ESP_BLE_MESH_ELEMENT(2, root_models1, ESP_BLE_MESH_MODEL_NONE),
};

As you can see i have commented out CFG_SRV model in 2nd and 3rd elements, which is normal usage case from what i understand after studying ble mesh specs, but you can also have CFG_SRV model for additional elements if your application requires this.

[Campou]

@jeromeDms @chegewara

• As per the Mesh spec says, The Configuration Server model shall be supported by a primary element and shall not be supported by any secondary elements.
• For multiple elements, please mask the following code in btc_ble_mesh_prov.c (line 966 ~ 971). This mask will be merged soon.

  if (op->min_len > BLE_MESH_MAX_DATA_SIZE || op->param_cb != 0) {
  --op;
  LOG_ERROR("%s, Invalid model operation min_len = %d, or param callbak = 0x%x, the last valid opcode = 0x%x", __func__, op->min_len, op->param_cb, op->opcode);
  return;
  }

• Also recommend to use the Android nRF Mesh App, i found some bugs while using the iOS nRF Mesh App (version V 1.0.2) test multiple elements.

[Alvin1Zhang]

@Campou Thanks for the updates.