Setting polling interval for Inkbird IBS-TH2

I have two Inkbird IBS-TH2 thermometer / hygrometer Bluetooth sensors for tracking the temperature of my fridge and freezer.

I installed the batteries, added them to the Engbird app, and set the name and polling interval (10 minutes). I then opened HA and saw both devices were recognized in Integrations and added them to the Inkbird integration. The fridge looks like it’s updating every 10 minutes (still waiting for the next update). The freezer is updating about every 10-30 seconds.

To top it off, I tried removing and re-adding the devices to see if that would help, and the freezer is still updating every 10-30 seconds. The fridge only recognized one entity (RSSI) and the battery, temp, and humidity are not appearing.

I did see a thread talking about active vs passive mode for the Bluetooth integration but it looks like that has change and now there’s active / passive / auto options.

At this point I’m regretting buying these sensors, but I’m hoping someone can point me in the right direction. Any help appreciated!

I don’t think you can set the interval.
The device sends out data as it’s programmed to do, and HA just listens.

What is the issue you are trying to solve?

EDIT, didn’t realize the app could set interval.
Could it be that it sends data when enough change has happened?
I know a lot of other thermometers are programmed to do this, if the change is not large enough just skip it, but if it’s larger than some value send data even if’s too often.
Placing it in the freezer will probably have a few minutes of constant sending of data, if it’s set up like that.

It’s been overnight so the temperature and humidity values have stabilized so I can see small bumps in the temperature about once per hour, presumably from the compressor cycling.

Restarting HA got my refrigerator sensor entities to all appear. However, now I’m seeing the temperature and humidity for both sensors updating at least once a minute although the battery entity for both updates less frequently, every 1-20 minutes.

Weird. Seems like this is going to eat up the battery pretty quickly. Sure wish the interval setting worked…

To a BlueTooth device, a freezer looks like a very efficient Faraday cage, and a fridge probably less so, depending on their construction and orientation and whether it is located inside close to the door or not. Batteries do not like the cold. Conventional batteries last less the colder it gets.

Getting the signal to your BlueTooth receiver, especially if they rely on session establishment first rather than BLE advertisements is going to eat batteries.

Your RSSI figures for each device would be interesting to note, especially if the same BlueTooth receiver is used for both.

Your battery values are going to go down steadily, so do not have to be reported as often as the temperature and humidity, a power saving function built into many battery powered devices firmware. This is normal operation.

Do both devices have the same firmware level?

You may need to have probe sensors inside the fridge/freezer and the rest of the circuitry snaking outside for optimum operation.

Food and other items inside have thermal inertia, the internal temperature remaining quite stable, depending on mass and volume, and how often the door is opened. Be sure you are measuring that rather than the internal air flow from the circulating fan. If your temperature probes are waterproof, put them in a jug of water. Around ice and cold, humidity can often be difficult to measure.

The temperature does not vary by much and then slowly, even during extended defrost cycles which can be once or many times a day, or if you have a fan curculating air efficiently, frost free operation keeping things at a fixed level. Overfilling your fridge or freezer is the worst way to interfere with this temperature control and will increase power consumption considerably.

Reporting every few seconds rather than every ten minutes is going to get you a lot more data, but probably not so much more information that is more useful.

Fitting larger external batteries may also be a consideration for extended life. You can get AA to D call adapters, use D cell alkalines, and bung the whole lot in a waterproof ABS case for optimal life.

…or just use a tweaked LYWSD03MMC with custom pvxx or atc firmware off GitHub like I do for my freezer sensors. Cheap and do the job, especially if you add back the missing capacitors to extend battery life. Cheaper than the Inkbirds. Bonus: cute display.

Thanks for the excellent info! I’m ok measuring the air temperature. My primary goal for monitoring is due to regular power outages and food safety concerns. RSSI is -90 and -97 so that seems reasonable. I experimented with the active/auto/passive setting, and on passive I didn’t get any updates, but auto seems to be polling the temperature and humidity every few minutes. However, looking at the known issues for the Inkbird integration, it looks like there are known issues with it not recognizing data sent through advertisements going back a few years, so it may be an integration issue rather than a sensor issue:

I’ll need to turn on debug logging and see what’s actually being sent and when. If battery life becomes an issue I’ll have to look a a different sensor.

I have four IBS-TH2 devices, one each in fridge and freezer and two at normal room temperatures (not in Faraday cages :grin:).

All four are set to report every five minutes in the app. The app shows all four to be working as expected.

Using the Inkbird integration I get long periods (sometimes hours) on all four devices with no update. This is much worse with the fridge and freezer (combination of Faraday cage and temperature?). When they are working I can clearly see variations from the compressor cycling.

I use Bluetooth proxies, and I wonder whether the Inkbird integration works with these (I gather that some other integrations don’t). The long periods without update may be the result of the devices connecting intermittently with the Bluetooth adapter in the HA machine, which is some distance away.

I’ve had some success with the TheengsGateway add-on. This does seem to work with proxies - moving the nearest proxy has a clear effect on the update rate. Still hit and miss in fridge and freezer, though.

If your goal is food safety, then the temperature the bacterial growth occurs at is your primary concern - [the unsafe zone of above -5°C for fridges and -15°C for freezers over a total of two hours] - and that is why I explained about the thermal inertia concept. When you open your fridge/freezer, the cold air escaping will show as a big spike in air temperature but the food temperature, the bit that really matters, will only creep up a bit. That bit is what you need to monitor, as that is what the bacteria work with to thrive. That needs to be measured accumulatively over two hours to hit the food safety unsafe threshold. For multiple interruptions of shorter periods, you still need to track the unsafe zone period and discard when it hits the two hour threshold as cooling does not kill the bacteria, just makes it dormant. Above the threshold and it continues to multiply, not start again - cumulative process.

This concept is commonly misunderstood in the food industry. The clock starts from the time the bacteria start multiplying. You may need to monitor more than one food batch if you don’t operate on a FIFO basis and empty out your fridge freezer totally after a food spoilage event. The cost of an extra DS18B20 embedded deep inside your freezer to monitor temperatures there can also be offset by discarding less food that you are certain is not spoiled.

Regulating your temperature and alarms based on air temperature will result in unnecessary power consumption. The times when defrosting occurs (the compressor is turned off but the fans still work) shows that concept is well established in the HVAC industry.

If food spoilage insurance claims are to be pursued, either through the electricity supplier or the insurance company, a printout with minute by minute readings is going to be very hard to argue over. I know, having often had this discussion many years ago as an insurance assessor for food spoilage claims. No proof, no claim. See you in court if you want to argue. Brutal. Again, with an overexcited food safety inspector keen to assert their wide powers, the cumulative time in the unsafe zone meaning huge coolstores did not have to be declared unsafe, individual pallets of food monitored independently.

An unreliable sensor with such weak RSSI values and random reporting sessions relying on intermittent BLE packets is probably not going to comply with regulatory food standard requirements. You need to demonstrate robust measurements. This has health as well as wealth implications - you do not want to poison your family and customers, or risk public liability claims or fines from regulators.

You are probably using inappropriate measurement methods. Dump the Inkbird and go with a waterproof DS18B20 probe in each fridge freezer, inserted in a container of water for thermal inertia, connected to a single ESP32 GPIO using the one-wire protocol if the devices are in close proximity, and separate ESP32s if longer cable runs are not feasible. Is the time the food hit the unsafe zone going to be critical, or just that the temperature was above the limit when the power came back on? Often if you keep the doors closed, the insulation can keep the temperature stable for many hours, sometimes days, and your food is quite safe and the insurance claim will be denied, often on the basis of the fine print that obligates you to minimise the linsurance losses by not opening the doors (‘the fine print giveth, and the fine print taketh away’ is how it was elegantly put)

If you need to continue to monitor during power outage, battery backup via UPS is going to involve the HomeAssistant server, the network, and the sensors staying up. In that case a RS485 bus and remote power supply may be a robust option for connection to the central server location via twisted pair cabling. A simple RS485 adapter is only a few dollars and you treat them as an UART at both ends to transmit serial data, rather than BLE or WiFi your ESP can also use, but may be just as unreliable as the Inkbird you are replacing.

If you’re just doing this at home for personal use and don’t mind a severe bout of diarrhoea occasionally, yes, stick with your Inkbird and grumble to the sky trying to work around the inherent limitations of marginal BLE, relays and proxies. If not, get serious and put robust measures in place. After a few successful food spoilage insurance claims, a generator will also start to look attractive.

I note the latest release of ESPHome includes some love for Inkbird BLE code, so maybe try that before abandoning the devices as unreliable.