I have been bought a IBS-TH1 sensor. I have found it logs the data incorrectly, If I set it to 10 second intervals, it appears to only log a correct reading every 10 readings (100 seconds). The other 9 data points are made up, as they always follow a straight line. If I set it to 30 seconds, the data has the same issue with only every 10th reading being correct. The same happens with all the settings. With 1 minute logging, the data every 10 minutes is correct but the other 9 minutes appear to be made up (estimated). Is there an issue with the firmware in the unit? In the settings on the app, it says version 2.3.0.
Hello,
Could you please let me know the phone model?
If you remove the battery of the IBS-TH1 and reinstall it, will its data change?
Is it possible to send a screenshot of the data?
Hi Tania,
The phone is a Samsung Galaxy A13.
I have uploaded some of the data to excel and produced a couple of graphs. They are both for 100 readings but logging at 10 seconds and 1 minute. They both show the same issue which produces a sawtooth pattern, which is not correct.
Only allowed to upload one item per post so will upload the 10 second graph in a another post.
I have removed the battery from the sensor to reset it, so will update on whether that changes anything,
Kind regards and Happy New Year,
John
I forgot to add. The blue line shows the temperature as downloaded from the sensor. The orange line is the plotted difference from the previous reading. This highlights the jump every 10 readings, which is not correct.
I contacted the engineers, and they replied that because the IBS-TH1 is powered by batteries, in order to reduce power consumption and data reading time, the data of IBS-TH1 has been compressed, it is normal for the sawtooth pattern to appear.
Maybe you could use it with IBS-M1 or IBS-M2 gateway, the gateway will upload the sensor data to the cloud through 2.4GHz wifi, its data is not compressed, maybe it can meet your needs?
Morning. I tried a reboot of the device (battery out). It has made no difference. The data still does not look right. I have noticed that the last few readings of a download ( downloading data for todays date) are more variable. However, this data gets changed if I download the same data a few minutes later. Below is an example of some data I downloaded yesterday.
Data on the left was downloaded at 12:29:20. Data on the right was downloaded at 12:32:10.
The data on the right shows the change to the data between 12:28:10 and 12:29:20. I am not sure if this is the app or the device itself doing this change.
03/01/2023 12:26:10 57.38 03/01/2023 12:26:10 57.38
03/01/2023 12:26:20 57.38 03/01/2023 12:26:20 57.38
03/01/2023 12:26:30 57.77 03/01/2023 12:26:30 57.77
03/01/2023 12:26:40 58.17 03/01/2023 12:26:40 58.17
03/01/2023 12:26:50 58.57 03/01/2023 12:26:50 58.57
03/01/2023 12:27:00 58.97 03/01/2023 12:27:00 58.97
03/01/2023 12:27:10 59.36 03/01/2023 12:27:10 59.36
03/01/2023 12:27:20 59.76 03/01/2023 12:27:20 59.76
03/01/2023 12:27:30 60.16 03/01/2023 12:27:30 60.16
03/01/2023 12:27:40 60.56 03/01/2023 12:27:40 60.56
03/01/2023 12:27:50 60.96 03/01/2023 12:27:50 60.96
03/01/2023 12:28:00 61.78 03/01/2023 12:28:00 61.78
**03/01/2023 12:28:10 61.88 03/01/2023 12:28:10 62.21**
**03/01/2023 12:28:20 62.62 03/01/2023 12:28:20 62.64**
**03/01/2023 12:28:30 62.62 03/01/2023 12:28:30 63.07**
**03/01/2023 12:28:40 63.29 03/01/2023 12:28:40 63.50**
**03/01/2023 12:28:50 63.29 03/01/2023 12:28:50 63.93**
**03/01/2023 12:29:00 64.20 03/01/2023 12:29:00 64.36**
**03/01/2023 12:29:10 64.30 03/01/2023 12:29:10 64.79**
**03/01/2023 12:29:20 64.86 03/01/2023 12:29:20 65.22**
03/01/2023 12:29:30 65.65
03/01/2023 12:29:40 61.96
03/01/2023 12:29:50 62.38
03/01/2023 12:30:00 62.8
03/01/2023 12:30:10 63.22
03/01/2023 12:30:20 63.64
03/01/2023 12:30:30 64.06
03/01/2023 12:30:40 64.48
03/01/2023 12:30:50 64.90
03/01/2023 12:31:00 65.32
03/01/2023 12:31:10 65.75
03/01/2023 12:31:20 61.41
03/01/2023 12:31:30 61.41
03/01/2023 12:31:40 60.74
03/01/2023 12:31:50 60.74
03/01/2023 12:32:00 60.09
03/01/2023 12:32:10 60.09
The above data wasThanks for the info about the compression. It means the product does not do what it claims to do. I am a bit disappointed and maybe this should be mentioned on the product info, as a claimed 10 second logging interval is not really correct.
Oh wow - why do you have logging intervals ranging from 10 seconds to 2 hours? It is understandable, that short intervals fill the data buffer faster than long ones. But what kind of compression is applied the logged data?
I noticed the same weird logging behavior and decided to make a test to check what is actually logged for a simple setup with 2 glases of water (simplified):
- 98 °C water
- 24 °C water
So when putting the remote sensor in one glas, waiting for 5x interval, then move it to the other glas, back and forth. Readings of the logged data shows inconsistent behavior - even inconsistent to what the display reading tells Sometimes the step from 24 to 98 and back to 24 is logged, but mostly it is not, but replaced by an averaged linear increase/decrease.
This is very annoying and makes the device (I bought 4 of them) almost useless for taking reliable temperature logs. I did the test with Engbird App Version 2.3.3 and device version 2.3.
I am perfectly ok with limited storage as long as it reliably logs the data, however I cannot accept arbitrary data logged.
Pointing to the gateway use is no solution, as for several applications I need to setup the logger and read out a few days later.
- Please supply an option to switch off compression
- Please also explain which limits apply to compress data
kind regards
tobbbie
1 Like
to johnhallam40:
Have you made further observations?
- Is a simple 1:10 datapoint compression - replacing the missing points with linear interpolation?
- or is there some more “logic” applied (like only replace almost linear, but then more than just 10)?
To support:
- please provide insight the your compression logic to bring back some belief in the logged data
- as already asked for: provide an option to switch off “compression” on the price of reduced data storage
I re-checkd my stored logs, and I can report the following “compression” logic:
IBS-TH1 Plus records
- 10 data-points in a row
- then it keeps the 1st and 10th and replaces the rest (8) with linear interpolated
This makes 2 data-points for 10 reported logged data-points - it records the next 10 datapoints
- keeps point 11 and 20 and replaces the intermediate ones.
The result is an awkward sequence of 2 real (in a row) and 8 interpolated data points.
Starting point is record number 1.
I still have to supply proof for the correct logging via the IBS-M1 gateway to the cloud.
The use of the Inkbird Pro app and the linked cloud space has its own challenges I will report in a separate thread.
1 Like
Tania 20Feb2023,
How can we as users of the IBS-TH1 Plus, force the Sensor to record a Correct reading at each and every selected interval? Battery life is of no consequence to me, I will replace them as often as required, However I cannot use the IBS-TH1 Plus in its current state of recording only Two out of every Ten measurements correctly.
Recording both correct and incorrect measurements ruins the entire Data Set.
Please help with this issue at your earliest convenience.
Tx JB
I helped myself in selecting a shorter interval and throwing away all the interpolated values. Since the “real” values are not having the same time-gap (mind the two-in-row real ones) you need to kick out 9 in 10 values and pick only every tenth value, staring with the first.
So instead of selecting 5 minutes interval (300 seconds), I chose 30 seconds and after kicking out the interpolated and worthless values I end up in 300 seconds. Of course the time to leave the device untouched is drastically reduced, but for me 10 days is still ok.
Also mind that the time-“stamps” are calculated backwards from the time of reading out the log. This creates the effect, that at the other end of log (the real start of the log) the time-“stamp” is moving with every read-out of the log file that has enough time-gap to the previous read-out. For my devices the calculated time-delay varies from 60 to 120 seconds per day.
So you best create a first read-out immediately after starting the log to get the real start-time of the first value and then for any subsequent read-out you must re-calculate the real interval-time using the real start-time noted from the first early read-out and the time of last read-out.
Quite a lot of post processing to do if you want to have exact data points in terms of values and time.
Here we are a year later and it seems like Inkbird has not released any firmware or other changes to remove this lousy compression, is that the feeling?
Was about to buy an IBS-TH2 and see if it was worth buying a bunch of them for the rest of my team, but as others said, that compression algorithm makes them useless. Hopefully Inkbird will catch up with that and fix it, until then I will have to look for something better.