How do I calculate an hours capacity to Story Points for an individual?

In Scrum, there's no good way of doing what you're trying to do. The only purpose of estimation is for the Developers to collectively get their arms around how much work they can take on in a Sprint. Everything else reduces to value delivery and empirical process control. The technique they use for estimation is entirely up to them, as is any commitment they jointly choose to make. It's best not to try and determine how to max a person out.

Why are you mixing estimation units?

Estimation isn't required in Scrum. Personally, I don't find it valuable and I try to encourage my teams to use approaches that take less time and have shown to be just as effective for planning and forecasting. However, there are still teams that do find estimation to be useful or stakeholders who expect estimates. If a team isn't ready or is unable to give up estimation, my advice would be to avoid mixing units. If you're going to be measuring the team's capacity in hours (which is good, since it's much easier to think across the spectrum of work and leave in hours than points), then you should also be estimating your work in hours.

More specifically, my advice would be this:

• Estimate work in ideal hours. That is, the total number of hours across all members of the team touching the work from start to done if they were to be uninterrupted and have total focus from start to finish.
• Forecast your capacity in hours. You know how long your work day is and how long your Sprint is. However, you do need to realize that not every working hours is on Sprint work. There's various kinds of overhead activities. I tend to use "1 work day = 6 hours" at most. Various organizations will have different ratios between clock time and ideal hours. Be sure to subtract known holidays, leaves, vacations, and overhead that you know about.
• Check your planned work against your capacity. You don't necessarily need to fill your capacity. It's better to create a Sprint Goal, check the work that you think is needed to complete the Sprint Goal against your capacity, and then reevaluate the Sprint Goal if it's too much.

There is no scuh relation.

Story points are used solely by Dev team  as a clue for approximately estimate the load for sprint planning. Technically , the sprint planning is not a mathematical calculation (an example of bad practice - is the team took PBIs  for 50 points and when one of the representer of mangment asks why 50?, the previous sprint was 60, let's  add something additional to the sprint) 

Capacity can be understood as available resources, and this should be sounded on planning; what can affect the capacity is - vacations, Non working days, or any other deviation in availability, e.g Team need to pass security treaning..

Hello there,

First you calculate the average time to complete one story point for the team then divide user’s available hours in the sprint by this average time per story point.

I agree with most here, I think you should avoid trying to "max out" a Developer in a Sprint.  Personally I use the average Story Points completed in the last 6 Sprints to forecast what future Sprints might look like, minus public holidays & leave.  That gives my team a guide for how many Story Points they could commit to in a Sprint.  But of course it's an estimate only, there is no exact science here.