Inkbird IBS-TH2 'noisy' data

Anto79-ops commented 1 year ago

The problem

Good day,

I recently acquired 2 Inkbird's, IBS-TH2, and placed them in my fridge and freezer. The devices almost immediately showed up on HA upon adding batteries to it. I have my HA Raspberry Pi instance and 7, ESP32 BT proxies (enabled for both active and passive scanning from ESPHome). I noticed however, the values that InkBird's (both devices) report is quite noisy and temperatures can jump up to 20oC sometimes, but its mostly only 5oC, for example.

When using the manufactures app (Engbird) the plots to not look like this, just your normal smooth line (its not clear if the manufacturer is applying smoothing).

I've seen similar reports about this, such as:

https://github.com/home-assistant/core/issues/76602

and

https://community.openmqttgateway.com/t/inkbird-ha-integration-values/1939

Not sure if this is something to do with my BT setup or some code issue, hence I'm just posting here.

Both my Inkbird sensors exhibit this behavior in HA. and it seems to be doing this with all entities as the same is true for humidity readings, and signal strength readings. Battery is at 100% so the line is straight.

thanks for your time

What version of Home Assistant Core has the issue?

2023.1.1

What was the last working version of Home Assistant Core?

not sure

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Inkbird

Link to integration documentation on our website

https://www.home-assistant.io/integrations/inkbird/

Diagnostics information

just noisy plots, no errors in regular logs

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

bdraco commented 1 year ago

Thanks. I ordered a few of them. Hopefully they won't take too long to show up

Anto79-ops commented 1 year ago

Awesome! Your bin is getting more and more full!

In the option on that AliExpress link, the "color" is:

30PIN-CH9102X

On the back of the board, it says

ESP32 DEVKITV1

bowentz commented 1 year ago

My issue seems to go away if I have the sensor pretty close to the proxy (about 6 feet), but if I move it away (15ft) the issue comes back. I'm using the m5stack-atom. I did try with one of my other proxies on the HiLetgo ESP32 Mini ESP-WROOM-32 with no improvement. Suggest @Anto79-ops maybe a sensor close to a proxy to see what happens...

Sensor about 6 feet away from proxy:

Anto79-ops commented 1 year ago

My issues seems to go away if I have the sensor pretty close to the proxy (about 6 feet), but if I move it away the issue comes back. I'm using the m5stack-atom. Suggest @Anto79-ops maybe a sensor close to a proxy to see what happens...

Sensor about 6 feet away from proxy:

Great suggestion, I can easily put a proxy within 3 ft... Ok I'll give this a try.

Right now there is a Shelly (about 6 ft) and the RPi4 BT about 8 ft on the floor below the fridge (i.e. In the Basement) but I can put a proxy closer, as there is an electrical outlet just near the fridge in question.

Anto79-ops commented 1 year ago

hey all, I have a few couple of updates but unfortunately, more of the same, though:

What you see here is the latest plot. Red arrow is when I placed a proxy just outside the fridge, probably 3 ft from the sensor. The two green dots, is when I started the update to the proxies to ESPHome Dev ( 2023.2.0-dev Feb 4 2023, 18:28:40), and the second green arrow is when the update finished (took about 1 hr and 15 mins to get all proxies).

You'll see my freezer went into defrost mode, hence the rise in temp around the update time.

Not sure if the sensor was still glomming on a proxy that was far, hence why I didn't see a change.

bdraco commented 1 year ago

Can you turn on debug logs for homeassistant.components.bluetooth and capture the AdvertisementData the exact time you get bad spike and a good value right after it?

Anto79-ops commented 1 year ago

For sure.

I did catch this on previous capture.

You can see there is 2 spikes, I would consider this a bad data. Do you want the logs for this? Can I send it to you personnel via message on Discord or something else?

thanks

bdraco commented 1 year ago

It would be better if you can get a good value that's -15 and bad value that is +5

The larger the range between them the better as it should make it easier to see patterns

Any of these work to send the data: Dropbox nick@koston.org Gdrive bdraco@gmail.com

Anto79-ops commented 1 year ago

Sounds good! Let me do another capture and I will send you the file(s) there...

Anto79-ops commented 1 year ago

Ok, @bdraco, I caught some fish for you, and some are big!

Here's a timeline of events.

I placed this in my configuration.yaml and restarted HA

logger:                       
  default: info               
  logs:                      
    homeassistant.components.bluetooth: debug

10:19 am MST -logging started (after HA restarted)

10:26 am MST - at this point, I thought it would be good idea to take out the freezer sensor for it to warm up, and then put it back in again...but I ran into issues...for some reason, the sensor became unavailable after I took it out? Strange thing, that never happened before. Long story short, the sensor started report again and I placed it back in the freezer. So, ignore the readings up until next time stamp (10:55 am)

10:55 am - count data starting from here (red line on plot below)

12:00 pm - logging stopped

Here's the snapshot of the whole thing

You can see that there are quite a few large temp reading from 10:55 am to 12:00 pm. The temps starts to go up towards the end, that is my frost free freezer kicking in.

I will send you the log file now.

c0bra99 commented 1 year ago

I have a IBS-TH2/P01B sensor (no external probe connection) and having the same issue with the random swing in values. I had this sensor working for a year or so prior with esphome directly using inkbird_ibsth1_mini and never saw the same swings in values. I have just switched it over to use the bluetooth proxy integrations and seeing this issue.

Some notes on my setup that may (or may not) help:

The sensor is placed in a HVAC vent with an expected temperature between 60-80°F going up/down every time the heat turns on roughly every 15-30 minutes
The incorrect anomaly peaks all have the same identical value, 79.05°F, until I changed the batteries and this value changed to always be 78.3°F. It's almost like it is sending a "max" or "peak" value it's seen since it was powered on and it is being interpreted as a current temperature, or some old value being cached.
I have 2 bluetooth proxies, one is very close to the inkbird sensor, the other is further away but can still pick up the inkbird sensor
Both of the bluetooth proxies are running on a ATOM Lite ESP32 (https://shop.m5stack.com/products/atom-lite-esp32-development-kit)
I put fresh batteries in the inkbird "just in case", and the issue persists
I am running Home Assistant 2023.2.1, and ESPHome 2022.12.8 and the bluetooth proxies have been flashed with the same version using a usb connection
The inkbird sensor sends a lot of updates
The only other bluetooth sensors I monitor are 5 lywsd03mmc running BTHome, but there is a lot of other bluetooth devices/traffic where I am. I do not see the same issue with the lywsd03mmc devices.
The same fluctuation appears for the battery level as well. My battery was showing 30% so I put fresh ones in it, it took a little bit to show the updated 100%, but it keeps bouncing back down to 30% even an hour after the battery has been changed. (see very bottom screenshot)

My bluetooth proxy esphome config is below, both are identical except the names:

substitutions:
  name: "bluetooth-proxy01"
packages:
  esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/m5stack-atom-lite.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
api:
  encryption:
    key: !secret api_key
ota:
  password: !secret ota_password

Before battery change: inkbird fluctuations before

After battery change, and the HVAC has not been running so the graph should be very smooth with not much fluctuations: inkbird fluctuations after

Interesting that the battery % is doing the same fluctuations: inkbird battery fluctuations

bdraco commented 1 year ago

Does everybody with the issue have multiple bluetooth adapters that are both in range of the device enough that it might switch between them?

bowentz commented 1 year ago

Does everybody with the issue have multiple bluetooth adapters that are both in range of the device enough that it might switch between them?

Yes, I have the RPi and one proxy on the M5 about equal distance apart. They are both the same distance from the sensor (15 feet).

I do have other proxies, but they are all at least 30 feet away..

Anto79-ops commented 1 year ago

Definitely for me too,

I tried to create a BT mesh network (if that even exists), and room presence detection.

I would imagine that all nine BT access points are within 40 ft of each other and some for sure are less than that.

Anto79-ops commented 1 year ago

If it's any consolation I also have two Govee's H5179.... and they do not have this problem.

They are in different locations of the house but I would imagine they are also within reach of more than one proxy

I don't know if knowing this information helps.

bdraco commented 1 year ago

This is a result of how the data gets processed

The inkbirds abuse the manufacturer data field so when it switches between the adapters we don't know which data is the old data and the new data so it picks the first changed it sees which can be wrong.

bowentz commented 1 year ago

OK... this is starting to feel like an AA meeting or some 12 step program, but I also must confess that I have 8 LYWSD03MMC temp/humidity sensors connecting to the proxies (BTHOME) all over the house and also all are communicating via ESPHome using the sensor component. The LYWSD03MMC devices do not seem to have the problem, but it does look like the proxies do register changes more frequently that the sensor component.

bdraco commented 1 year ago

The LYWSD03MMC doesn't abuse the manufacturer data field like the inkbird does. All of its data comes in the service_data field and its done in line with the ble spec.

Only 6 of the ble integrations abuse the manufacturer data field like the inkbird does:

thermopro_ble/parser.py

sensorpro_ble/parser.py

inkbird_ble/parser.py. (likely doesn't need a change besides the underlying lib)

bluemaestro_ble/parser.py

tilt_ble/parser.py

sensorpush_ble/parser.py

c0bra99 commented 1 year ago

I just installed home assistant 2023.2.3 because I saw the fix for this was in it, but.... now all the Inkbird entities are just showing Unavailable. Not sure what to do next, I may try removing the integration and re-adding it tomorrow (if it discovers it), unless anyone has other ideas?

c0bra99 commented 1 year ago

Nevermind, it took about 35 minutes to start showing data for some reason but it is working now!

Anto79-ops commented 1 year ago

its fixed! thank you very much @bdraco and everyone else.

You can see here when I updated.

c0bra99 commented 1 year ago

The noisy random spikes issue is fixed for me, but I am getting some "flat lines" where it is not updating data. I noticed a few things in my log files around these times. It originally was showing Unavailable until I got this message for one of my proxies:

2023-02-07 22:33:43.427 WARNING (MainThread) [aioesphomeapi.connection] bluetooth-proxy02 @ 192.168.1.119: Connection error occurred: 
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 520, in send_message_await_response_complex
    await fut
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 519, in send_message_await_response_complex
    async with async_timeout.timeout(timeout):
  File "/usr/local/lib/python3.10/site-packages/async_timeout/__init__.py", line 129, in __aexit__
    self._do_exit(exc_type)
  File "/usr/local/lib/python3.10/site-packages/async_timeout/__init__.py", line 212, in _do_exit
    raise asyncio.TimeoutError
asyncio.exceptions.TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 303, in _keep_alive_loop
    await self._ping()
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 628, in _ping
    await self.send_message_await_response(PingRequest(), PingResponse)
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 537, in send_message_await_response
    res = await self.send_message_await_response_complex(
  File "/usr/local/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 522, in send_message_await_response_complex
    raise TimeoutAPIError(
aioesphomeapi.core.TimeoutAPIError: Timeout waiting for response for <class 'api_pb2.PingRequest'> after 10.0s

After that message it started updating and working with none of the random spikes like before.

Throughout the night I noticed several lines of these "EOF received" in the log, but they don't exactly match up with the flat lines.

2023-02-07 22:59:42.633 WARNING (MainThread) [aioesphomeapi.connection] bluetooth-proxy01 @ 192.168.1.118: Connection error occurred: EOF received
2023-02-07 23:30:44.973 WARNING (MainThread) [aioesphomeapi.connection] bluetooth-proxy01 @ 192.168.1.118: Connection error occurred: EOF received
2023-02-07 23:49:39.682 WARNING (MainThread) [aioesphomeapi.connection] bluetooth-proxy01 @ 192.168.1.118: Connection error occurred: EOF received
2023-02-08 00:50:25.818 WARNING (MainThread) [aioesphomeapi.connection] bluetooth-proxy02 @ 192.168.1.119: Connection error occurred: EOF received
2023-02-08 05:57:10.804 WARNING (MainThread) [aioesphomeapi.connection] bluetooth-proxy02 @ 192.168.1.119: Connection error occurred: EOF received
2023-02-08 06:17:45.827 WARNING (MainThread) [aioesphomeapi.connection] bluetooth-proxy02 @ 192.168.1.119: Connection error occurred: EOF received

bdraco commented 1 year ago

That might be an esphome issue. Try flashing esphome dev or wait for 2023.2 release of esphome

Anto79-ops commented 1 year ago

awesome to hear the spikes are gone for everyone else.

@c0bra99 I have the same errors in my logs (still do), follow this issue where I submitted it:

https://github.com/home-assistant/core/issues/87158

c0bra99 commented 1 year ago

I still think there is some issue specific to the inkbird sensor through the bluetooth proxy losing data. @Anto79-ops do you notice any "flat lines" from your inkbird sensor where it has stopped getting updates? I am getting those errors occasionally in the log, but it does not appear to impact the lywsd03mmc BTHOME sensors so I am not sure if it is related to this issue.

I know the inkbird sends a lot of updates and is usually very quick to show changing temperatures. The bluetooth proxy is not showing as many of the updates, and I am ok with losing some, but it is losing large chunks of time with no updates at all as well.

I have moved one of the lywsd03mmc sensors to right beside the inkbird, and I have also setup the old esp32_ble_tracker using inkbird_ibsth1_mini again to watch the same inkbird sensor. Here you can see the lywsd03mmc is still showing updates through the proxy (1 small gap at 9:55 for some reason) but the inkbird has stopped updating since 9:48 through the bluetooth proxy, but has been updating consistently through the esp32_ble_tracker since I set it back up at 9:43

Anto79-ops commented 1 year ago

@c0bra99

I don't think I have the flat line issue as much, for example, here is the last 24 hrs, and the last 12 hrs was with the new update to fix the noisy problem.

One thing I did do is that I downloaded the manufactures app (its actually called EngBird on Android), and I changed the reporting interval to 30 seconds instead of every 2 or 3 seconds. I might even change it to a minute or 2 just to save battery life. After I changed the settings in the app, I uninstalled the app so that it does not try to connect to the sensor at the same time as the proxy....that would definitely cause disconnect issues.

The signal in my InkBirds range from -70 to sometimes -85 dBm (I would image signal is only getting out from the back of the fridge as every other side has stainless steel or steel), so I would expect disconnects and some flatlines at the signal. Does your signal become poor before it disconnects?

c0bra99 commented 1 year ago

I have not used their app to adjust it but I knew the update interval was very quick such as every 2 seconds. Signal should not be an issue for mine, it is about 5 feet away from one of the bluetooth proxies, line of sight with nothing in between it. The battery life on my sensor is very good, I had the original batteries in it over a year and it was only down to 30% before I swapped them to see if it helped with the original noisy data issue.

Between 9:47 and now there are only a few updates through the proxy. It seems like when there is a big difference in temperature it starts sending more updates/faster and those seem to get captured better, whereas the small gradual temperature changes are not being captured.

Maybe I will try increasing the interval in their app to see if that helps, but that seems counterintuitive. Maybe the proxy is getting too many messages from it and ignoring it?

Anto79-ops commented 1 year ago

it kind of looks like it not changing because the temperature is not changing?

Try the app, it also display history and you can compare the plots, maybe.

EDIT: no never mind, I was looking at the wrong plot.

c0bra99 commented 1 year ago

The blue line and the cyan line are the same exact sensor, one being captured through the bluetooth proxy and one from the old esp32_ble_tracker that was used before the proxy existed. Since the cyan line is changing I know the sensor is updating with new temperatures, but the proxy is losing/ignoring/missing it for some reason.

Anto79-ops commented 1 year ago

to be honest, i'm not exactly sure, but just curious, do you have 3 different systems of proxies trying to connect to the same sensor? If you disconnect the purple and the cyan proxy, would that improve the blue poxy?

c0bra99 commented 1 year ago

The purple line is a lywsd03mmc sensor running BTHome, being read through the same 2 bluetooth proxies as the blue line. The cyan line is the old way of capturing bluetooth traffic using esphome (https://esphome.io/components/esp32_ble_tracker.html) running on a completely different esp32. Since these are all passive readings there should be no way one is interfering with the other.

I added the lywsd03mmc in the same location as the inkbird to show the temperature is changing and the bluetooth proxy is still capturing data from other devices during the "flat line". That's why I am thinking it is a problem specific to the inkbird proxy integration.

The plot in the "engbird" app looks similar to the cyan line, just squished to a phone screen

Under settings it is interesting to see the interval was by default 1min. I know 100% it was updating faster than 1 min, so I am not sure if that is showing the current setting or if there is something weird with it.

Anto79-ops commented 1 year ago

I experienced the same, it said 1 minute, but I know it was 2 to 3 seconds. However, when I changed it to 30 seconds, it does usually follow with 30 second rule.

I just wanted to share my ESP32 config.yaml, perhaps you can try it, and it might fix it, also, i'm using ESPHome Dev. But, even pre-dev, I was not seeing flat lining.

substitutions:
  name: esp32-bluetooth-proxy-299fcc
packages:
  esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/esp32-generic.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false

esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:
  active: true

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

sensor:
  # Uptime sensor.
  - platform: uptime
    name: esp32-bluetooth-proxy-299fcc.uptime
  - platform: template
    name: esp32-bluetooth-proxy-299fcc.free_memory
    lambda: return heap_caps_get_free_size(MALLOC_CAP_INTERNAL);
    unit_of_measurement: 'B'
    state_class: measurement

switch:
  - platform: restart
    name: "Family Room BT Proxy Restart"

esp32:
  board: esp32dev
  framework:
    type: esp-idf
    version: 4.4.3
    platform_version: 5.3.

home-assistant / core