I think that the answer is that there is no correct answer. Whilst this is a simple question, the answer is kinda open.
You're asking about the entropy of correlated data with respect to random number generation. The key reference for this is NIST Special Publication 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation. Look to sections 5 and 6. You be faced with two questions; Is my data correlated (non IID) and if so, what is it's entropy rate? You have already realised that the standard $ -K\sum_{i=1}^n {p_i \log p_i} $ isn't appropriate.
Is your data correlated?
This is the first step, and NIST suggests permutation testing, as below:-
There are 11 tests NIST recommends, all of which are somewhat complex. To help (not) they have release some code on GitHub that implement these tests. I'm unsure of how official this is, but see the well received How to interpret the entropy results for a NIST test file as to their soundness. An immediately apparent problem for implementation is that as $ T, T_i \in \mathbb{R} $, the equality test in Fig.4, section 2.2.2 becomes difficult without bounds. In a nutshell, the code doesn't work well enough for field use.
What is the entropy?
If you manage to satisfy yourself that the data is non IID, NIST recommends taking the lowest value of another 10 complex statistical tests as the min. entropy value. Similarly, the Python and C++ code has problems outputting a coherent and credible entropy estimate. Perhaps you can implement the tests yourself in another fashion.
What I do.
I too build random number generators and I use similar permutation tests, but focused solely on a compression test. Compression exploits correlation and eliminates redundancy. Compression is also used in both the NIST non IID confirmation and entropy estimation tests above.
One can calculate what I have termed a correlation factor, $ c_f $, explored in What exactly does compression say about correlation of data? If $ c_f \simeq 1 $ then the data is IID, and non IID if $ c_f > 1 $. I then use the non permuted compressed file size and divide twice by two to get a conservative entropy rate. This method seems to be as good as any, and more robust that most. I estimate about 1.6 bits / byte from a 24V Zener diode at 10kSa/s. That's 16kbps of cryptographic strength entropy.
Notes.
- I now use fp8 and paq8px compressors as they are about the best I can find that will compile for me. They'll compress IID data to within 1% of the theoretical Shannon limit.
- Divide by two as a security precaution to allow for improvements in compression algorithms, whilst realising that these improvements are asymptotic with diminishing returns.
- Divide by two again just because.
