As I understand it, the amount of entropy in a password represents the number of guesses required to know what that password is. Each bit is a single yes-or-no decision, and ideally, the attacker would either get a "correct password" or "incorrect password" result (so, they have to guess the whole thing, all at once). For n bits of entropy, that requires 2^n guesses.
The desired strength depends on what sort of threat you expect to face. In particular, it depends on how fast the attacker can make guesses, and how long you expect the attacker to keep trying.
Once you have those numbers, your target minimum entropy (in bits) should be:
n = log_2(totalGuesses) = log_2(guesses/sec * durationInSeconds)
The persistence of the attacker is something which I don't know how to estimate. For the sake of argument, let's assume that you want your password to be secure for 1 week after the attacker starts guessing.
Number of guesses per second depends on how the password is protected, and what sort of access the attacker has. For an online attack (i.e., trying the login form of a website), you could rate-limit it to a fairly low value; 10 per second would be achievable. For unsalted MD5, it's safer to assume billions of guesses per second. For a strong hashing algorithm like bcrypt, it will be somewhere in-between (MUCH slower than MD5, in any case).
So, at 1 billion hashes per second (offline MD5 cracking), you would need to defend against about 6*10^14 guesses total, requiring about 49 bits of entropy. At 10 guesses per second (online, rate-limited attack), you need to defend against about 6*10^6 guesses, so you need about 22. bits of entropy.
Of course, per-character estimates of Shannon entropy will not accurately estimate the difficulty of cracking a password, and the percentage error will vary wildly depending on various factors. The approach you're taking will only give reasonably accurate results for computer-generated passwords, NOT for human-generated passwords.