We have some suggestions. First of all, I hooked up an AM2315 to our test setup and ran it for days with no problems. That being said, John said he had some problems a couple of weeks ago that sounded similar to your problem.
We know a couple of things at this point:
1) The manufacturer says there is no known problem like this.
2) We are running the AM2315 off of ESP8266 in the OurWeather kits for hundreds of thousands of reads with no problem.
3) John has seen a problem like yours in the past. The problem went away so he didn't pursue it.
The problem seems to be focused on the I2C bus on the Raspberry Pi and that is what we are going to focus on in the next weeks (start later next week) to figure out. The first thing to do is for us to build a reliable failure mode so we can test fixes. The Am2315 has kind of a funky startup mode (it powers the device down between reads to reduce self heating), so it doesn't always show up on an i2cdetect.
At this point, we think that something is interrupting the I2C bus on the Raspberry Pi every once in while and locking the bus. We are going to need to dig into the drivers and probably rewrite some of the existing ones to mimic what we do on the ESP8266 which absolutely fixed the similar reliability problem. More on that as we dig into the problem.
First of all, regarding the power locking (we saw the same thing on the ESP8266 until we fixed it), there is a solid work around. We have something called the Grove PowerSave which allows you to power off and power on specific I2C devices under software control. We used it extensively in Project Curacao2 to increase reliability and reduce power. Check this out: