Wrong min and max values on MSI Z490 Tomahawk

Yeah their response is pretty lame. I have found the Aquasuite devs to be somewhat defensive, and usually start out assuming the person reporting an issue either doesn't understand or is doing something wrong. I have gotten them to fix a few obscure bugs, but not before I was able to replicate the problem every time and had a few other people on their forum concur. When they finally actually looked at it they said Oh yeah - you're right. It will be fixed in the next release, which it was. I don't know if synchronizing polling of this particular sensor involves a global mutex or some other mechanism but it does not look like they are willing to address it, so OP may need to rethink his alarm strategy.

BTW - I posted further up that I have had sensor values imported from HWINFO stop reporting in AQS. It just happened again. This time it was both DIMM temps. I ran the Shared Memory Viewer you provided and it showed both of these values present so I think you are right - it's an Aquasuite issue. This would be a tough one to convince them of because it only happens occasionally. It's also not the only AQS mystery bug I have encountered. I have a custom overview page set up to auto-load when AQS starts. One day it stopped working. I tried everything, looked at the config xml file, and could not figure out why overview page auto-load stopped working. A few days ago it magically started working again. I had not changed anything prior to this. I posted on the forum about this one but didn't get anywhere. It is what it is I guess. Their controllers are really nice and AQS is a great program. Now I just accept that it's not perfect (like HWINFO).
Yes, it requires a global mutex to synchronize access to the eSIO with other clients. The issue happens only if at the same moment multiple applications send commands to the eSIO not knowing that anyone else is doing the same. Imagine that one application sends a command to read temperature 1, but another one to read fan 1 at the same time. The eSIO responds to commands in order (or might skip the 2nd command) so results returned to applications might not be what they expected. This also explains why this situation occurs rather rare. It's not serious (besides getting wrong results), but would be more serious if one application would be sending commands to write some register which could result in eSIO register corruption. ArgusMonitor had a similar issue and since they implemented the global mutex I haven't heard of such problems.
Thanks for confirming they they should be using a global mutex to poll this sensor. I just posted over there pushing them to clarify if they are using a global mutex or not. They said that they "do it correctly" and that means using a global mutex. They know that a lot of AQS users are importing data from HWINFO so they have both programs running, so this is definitely something that they should fix. They will probably respond with another snotty remark, but no harm in trying I guess.