Mesh Models in a gateway

RE: Mesh Models in a gateway

Dilanka Asiri — Fri, 26 Jul 2019 02:14:10 GMT

Thanks for your clarification and help throughout the case.

Regards,
Asiri

RE: Mesh Models in a gateway

tesc — Wed, 24 Jul 2019 16:12:05 GMT

Hi,

Flash wearout means the contents in flash is not what it should be, and that might lead to error at any point in time when data has been read from flash and then used.

Feedback from our mesh team is that flash wearout is less of a problem than what I expected. It will happen after much more than 10 000 reconfigurations, as flash manager writes new records to the flash page until the page is full. Typically there will be more than 300 address changes for DSM, before a flash erase is needed. The number for the access layer is more than 400. This means model publication can typically be changed more than 3 million times before flash starts to wear out. Increasing number of pages for access layer and/or dsm will increase number of publication changes linearly.

Regards,
Terje

RE: Mesh Models in a gateway

Dilanka Asiri — Tue, 23 Jul 2019 04:18:13 GMT

Hi,

What if the flash wears out, the assert happens when loading data at the startup or when saving?

Thanks,
Asiri

RE: Mesh Models in a gateway

tesc — Mon, 22 Jul 2019 11:30:38 GMT

Hi,

I have sent a request to the Mesh team, to see if either we can get reconfiguration of models without the need to write to flash, or if they have other solutions to your use case.

Due to summer vacation season here in Norway, it might take some time to get a response. I am sorry for any inconvenience.

Regards,
Terje

RE: Mesh Models in a gateway

Dilanka Asiri — Mon, 22 Jul 2019 03:57:57 GMT

Hey,

Could you come up with a solution for reconfiguring models without the need for flash writes?

Thanks
Asiri

RE: Mesh Models in a gateway

tesc — Thu, 04 Jul 2019 09:30:08 GMT

Hi,

There is no practical way to avoid asserts like that from happening, given that after an asserts all bets are off as to the overall working of the Mesh stack.

Dynamically reconfiguring models (without the need for flash writes) is something that I can report to the Mesh team in order to look into for further improvements.

Regards,
Terje

RE: Mesh Models in a gateway

Dilanka Asiri — Tue, 14 May 2019 16:50:10 GMT

Hey,

I get you, but as a company our product (gateway) will have a limited lifetime in that case even if we have more models, given that the write cycles on the NRF52832 is 10000.
If the number of cycles exceed and gets corrupted, would it run to a mesh assert in the startup, because as I said earlier, I could set the publication address each time I publish data and the retrieved publication address from the flash memory is of no use in my application. If it does run into an mesh assert (because of the corrupted data in the flash) is there a way of ignoring it, and continue the normal operation of the mesh stack.

Thanks,
Asiri

RE: Mesh Models in a gateway

tesc — Tue, 14 May 2019 16:22:27 GMT

Hi,

Any configuration of the models, including publish addresses and subscription addresses, are supposed to survive a reset. For that reason, all such configuration values are to be stored in non-volatile memory.

In our bt mesh stack, the responsibility of storing configuration data to non-volatile memory is partly covered by the stack and partly covered by the model implementation. While the DSM part is done in the stack, the access layer part is done in the model implementation. As such, you only control the access part of it.

Since the stack is provided as source code you technically have access to disabling flash writes in DSM, but do note that since that constitutes a change of the stack you cannot use our qualification ID for the stack any more if you do so.

You are not the first customer to ask for this (or similar) scenario, and we are aware of the use case. Hopefully we can do something to better suit this use case in the future, but for the time being I am afraid using several models is the way to go. (Unless you want to qualify the stack yourself, at which point modifying the behavior of DSM becomes a valid option.)

Regards,
Terje

RE: Mesh Models in a gateway

Dilanka Asiri — Tue, 14 May 2019 11:48:59 GMT

Hey,

For the runtime environment, only the volatile memory is used right. (Say setting the publication address of an element, and then publishing it). This depends on the volatile memory or does it depend on the flash memory aswell. Isn't the flash memory used to get data back to the voltaile memory after the reset, or does it have other purposes throughout the code?

You see for my application, I don't necessarily require saving the publication address of the module of the flash, because each time a message gets published, i could set the publication address of the element. Considering this fact is there a workaround other than having more models? (Even having more models, the cycles of the gateway would be limited, this is what I'm trying to clarify from my end).

Thanks,
Asiri

RE: Mesh Models in a gateway

tesc — Tue, 14 May 2019 09:48:51 GMT

Hi,

The suggestion to have a pool of several models is intended to be a caching mechanism. I.e. that if you use the same few models often then you don't need to configure those addresses all the time. I.e. preferably you use a heuristic that minimizes the need for publish address reconfigurations.

While you do have control over flash storage done by the access module, you do not have control over flash storage done by the device state manager (dsm) module. If you do not update the data stored for the access module (but dsm is updated behind the scenes) then you are likely to end up in a bad state after a reset. (Akin to a dangling pointer in c.)

You may recover from dsm/access inconsistencies by removing the gateway node from the network and reprovision it again on every reset, or at least when you get the mesh assert because of dsm/access being out of sync, but that again would put more strain on the mesh network, involves the provisioner, and leads to more flash erase cycles... This is the reason why it is generally better to have more models (to avoid reconfigurations leading to more flash usage.)

Regards,
Terje

RE: Mesh Models in a gateway

Dilanka Asiri — Mon, 13 May 2019 13:54:02 GMT

Hi,

If you take the function handle_config_model_publication_set in config_server.c. There is a function access_flash_config_store. In the documentation it is said that this is line of code where the access layer information gets stored in the flash. So if i comment out this, since i don't actually want to save the publication address (before publishing data i set the address of the model always), I won't have to worry about the flash memory issue as you have said in the earlier reply (~which means you run the risk of wearing out the flash). WiFi module always sent the state and respective element address to which the publication address of the NRF node in the gateway is updated before publishing data. So this would solve the issue right?

And you said earlier to use like 10 models and do round robin when publishing data. (is it just because of the wearing out flash issue?). If the above flow is okay (comment out the access_flash_config_store()), then is it fine to use one model. Will there be any performance hits compared to using 10 models?

Thanks,
Asiri

RE: Mesh Models in a gateway

tesc — Mon, 13 May 2019 11:57:22 GMT

Hi,

Yes, in that case that would be the best option. (And of course if a model is already configured with the correct publication address then that one is reused instead of reconfiguring the next one round-robin.)

Regards,
Terje

RE: Mesh Models in a gateway

Dilanka Asiri — Thu, 09 May 2019 16:32:16 GMT

Grouping is the option for the customer right. We have no control over it. The customer can group the devices as per his/her needs. (say all the lights in the room as a group, he/she can group them from the mobile application that we are developing which in that case we have no control over the group, its totally the customers requirement.)

In that case what you recommend is to have several elements having the same model in the gateway publish data to the nodes. (like round robin)?

RE: Mesh Models in a gateway

tesc — Thu, 09 May 2019 15:58:08 GMT

Hi,

While one client model of each type would technically work, it may not be a good option in the long run. The reason is that there will be a couple of flash writes every time you reconfigure the publish address, which means you run the risk of wearing out the flash. Because of that it might be a better idea to use more clients. I suggest that you do some calculations based on what will be the usage scenario, and figure out how many reconfigurations you would expect over time. If you reach tens of thousands during the product life time then you probably want to do some changes.

In general, you should organize your network so that several server models subscribe to the same group address. Then you control the group, and not individual servers. E.g. all the lighting fixtures in a room. That also makes it easier to replace light bulbs, as you only need to reconfigure the new light bulb to subscribe to the group address.

Regarding publishing data, there is a limit for any mesh node on the network of publishing 100 messages during a moving 10 second time frame. I.e. peak throughput will be ten messages per second. This means using group addresses (controling multiple nodes together) is better than individually controlling multiple nodes.

Getting messages from multiple nodes should not be an issue, other than the general issue of packet collisions if the network gets congested. While there is a limit on throughput originating from a node, there is no limit on relaying or receiving packets.

Regards,
Terje

RE: Mesh Models in a gateway

Dilanka Asiri — Thu, 09 May 2019 10:40:39 GMT

Also say in a RGB light, and if there are 100 RGB lights, all the messages from those 100 lights will publish to a single element in the gateway. Will this be a problem?