Well, I think maybe the issues I was having had to do with not knowing there are 13K pullups already on the Gen3 Devices. I’m hoping changing pullup resistance fixes my problem also.
Maybe the higher temps were causing the resistance to change enough on the resistors to push it over the edge.
How amazing that it was so close to the edge that raising the temp a few degrees pushed it over. So glad this is behind me. I have 3 different temp/humi sensors in the mail now though, haha.
Thank you so much for keeping me on the scent with this. I really appreciate it!
Yea I’m happy that this mystery is probably solved now.
Need to give you some time to keep testing before checking the solution box.
Sorry about that! Thanks for your posts (and same to RWB). Appreciate the info! One problem, though. I will probably be confronted by my wife about laughter waking her up a little after 4 in the morning. Hey, IT WAS WORTH IT!
Nice!
I actually have a BME280 sensor here that I need to use since the SHT30 is reading way to high.
What library are you using for this BME280?
FYI, running smooth as.
Library used was a hacked together Adafruit one. I found a way simpler one mid way through this whole mess and discarded it because it didnt work, but it may have also been pull-up related. The Adafruit one relies on that adafruit_sensor library, which isnt as relevant with inbuilt Wire.h support.
I still dont know how to upload libraries to github, but will work on it now.
Or… paste below? what works for you?
Ok, got it working using a smaller library that uses Wire (so the setspeed will work too). I THINK i figured out how to upload to github... Have also written a simple example script that dumps all the readings to a Particle.publish (as the device is remote now).
@irwige I gave your library a try and it loaded but it would give a RED SOS error after a few seconds.
I went ahead and just loaded the example from the most downloaded BME280 library on the Particle Web IDE and that worked perfectly.
Now I’m comparing the temp readings of the BME280 vs the SHT31 Temp/Humidity Sensor.
I had said I noticed the SHT31 reading 2-3 degrees higher than what I knew the inside temps were.
I just placed both sensors beside each other and I will watch how close they are over time. Right now they are pretty close but I need to give it some time.
I need to add the BME280 Temp and Humidity to the online graphing to see what it looks like over time between the two.
The Serial window is the BME280 readings after sitting next to the SHT31 for a few mins.
I have this sensor board but I removed the CCS811 VOC sensor because it sucked and it would heat the board up affecting the BME temp readings.
This breakout has 4.7k pull-up resistors on it for reference. So thats 13K pullup on the Photon and 4.7k on the breakout. How do we calculate resistance?
The resistor are in parallel, so you add the reciprocal of the values and take the reciprocal of the result:
Rtotal = 1/( 1/R1 + 1/R2 )
Rtotal = 1/( 1/4700 + 1/13000)
Rtotal = 1/( 0.000212765957446809 + 7.69230769230769e-05)
Rtotal = 1/0.000289689034369885
Rtotal = 3451.97740112994
so 3.45k.
The reciprocal of resistance is called "conductance" so here you are adding the conductances to find the total conductance, and then taking the final reciprocal to get back to resistance.
To avoid redefining common mathematical rules and terminology ( 
) I'd rather write this as
13k || 10k || 10k -> 3.61k
(read as: 13k parallel 10k parallel 10k results in 3.61k)
Ahh there he is! @ScruffR, I was beginning to think you had pushed me out to sea on an iceberg, and moved on with your life!
I think we need a separate sub-forum for sweet sweet plots.
Nah, I just saw you in other good hands 
Well, Sydney is slowly getting warmer and guess what… iiiiiiiit’s back, but this time at 30dC… ffs…
Wondering if changing it to a 5k ohm resister will help (or putting another 10k in parallel?).
edit: one additional piece of information is that I had to change out the Boron (the other went into an unrepairable SOS 10 beep loop 
) So not sure if this one needs a little more assistance in the pull ups, as the old one was working fine till it gave up. Will start another post about the two Borons I have had die. Both had the same code which made updates to EEPROM hourly… presume something related to this, but if it wont even last a few weeks with hourly EEPROM updates, then why make it a feature?
You can file a support ticket for that - I'm sure these devices should not just give up working as long you didn't do any bodily harm to it
Also correct use of EEPROM on a hourly basis should not kill a device (although bad practice can kill EEPROM even when only employed on a hourly basis 
). However, if you should have happened to wear out the flash area dedicated to EEPROM the device should still be usable (minus the EEPROM feature).
Cheers, will do.
update: Whoever "KT" is that handles tickets is the next least helpful thing to throwing this device in the bin. Not even reading my emails and just throwing me stock replies.