Unofficial Inkbird thermometer integrations: INT family / INT-14-BW and IHT-2PB

Share your Projects! Custom Integrations
1

Hi all,

I’ve published two unofficial Home Assistant integrations for Inkbird thermometers.

These projects were built from real hardware, reverse-engineered, cleaned up and released as HACS custom repositories.

GitHub profile:

Inkbird INT-14 / INT-14-BW

Repo:

This is the bigger one.

The INT-14 is a nice thermometer station, but Home Assistant support has been basically missing, fragmented or stuck behind vendor app / Tuya / cloud limitations.

Current scope:

  • local BLE discovery, snapshots and explicit commands
  • local Tuya LAN polling and writes when host, device_id and local_key are supplied
  • optional read-only Inkbird cloud history for DP109 temperature history
  • no cloud live updates
  • no cloud writes
  • HACS custom repository
  • tested with real INT-14 hardware

The goal is to make the INT-14 usable in Home Assistant in a practical, local-first way, while keeping cloud usage optional and limited.

Inkbird IHT-2PB

Repo:

This one is simpler and cleaner: BLE-only, local-only.

Current scope:

  • local BLE only
  • no Inkbird cloud
  • no Tuya cloud
  • no MQTT bridge required
  • optional ESPHome Bluetooth Proxy as a remote BLE radio
  • exposes probe temperatures, alarm/fault/hold state, target/calibration values, battery raw level, backlight, unit and freshness
  • HACS custom repository
  • tested with real IHT-2PB hardware

Notes

Both projects are unofficial and not affiliated with Inkbird.

The public repositories are sanitized: no private MAC addresses, LAN IPs, local keys, tokens, app dumps or raw captures.

I’m looking for feedback from other real devices, especially:

  • different INT-14 / INT-14-BW firmware versions
  • different IHT-2PB firmware versions
  • different probe combinations
  • different Bluetooth adapters
  • ESPHome Bluetooth Proxy setups
  • Tuya LAN / local_key configurations
  • reconnect and BLE range behavior

If you own one of these thermometers and want proper Home Assistant support instead of depending only on the vendor app, feel free to test the repositories and open issues with compatibility reports.

I had to do the annoying reverse-engineering work for my own setup anyway, so I decided to publish it properly instead of leaving it buried in a private Home Assistant config.

1 Like
2

Small update:

The integration has now been updated to v0.2.0.

It is no longer limited to the tested INT-14-BW path only: it now includes model profiles for the modern Inkbird INT food thermometer family.

Current status:

  • INT-14-BW: tested baseline
  • related INT-14 / INT-12 / selected INT-11 profiles: experimental
  • newer INT-22 / INT-31 / INT-33 / INT-54 family targets: cataloged for future validation, not exposed as supported profiles yet

The integration is now profile-aware:

  • creates only the probe entities expected by the selected model
  • validates probe-specific services against the selected profile
  • adapts diagnostics and battery/state quality entities
  • enables or disables BLE, Tuya LAN and cloud history depending on the declared profile capabilities

Release:

Main validation thread:

If you have an INT-14S, INT-12, INT-11 or a related modern Inkbird food thermometer, test reports are welcome.

3

Small update: v0.2.1 is out.

Release:

The main change is that the integration now separates physical probes from temperature channels.

This matters for newer Inkbird INT thermometers such as INT-31-BW, INT-14S-BW, INT-12E-BW, INT-33-BW and INT-11S-B, where one physical probe can expose multiple internal temperature sensors.

Current status:

  • INT-14-BW remains the tested baseline.
  • INT-14-BW exposes 4 physical probes and 8 live mapped temperature channels.
  • INT-31-BW is cataloged as 1 physical probe / 5 expected channels.
  • INT-14S-BW is cataloged as 4 physical probes / 20 expected channels.
  • INT-12E-BW is cataloged as 2 physical probes / 10 expected channels.
  • INT-33-BW is cataloged as 3 physical probes / 13 expected channels.
  • INT-11S-B is cataloged as 1 physical probe / 5 expected channels.

Important: cataloged does not mean live support yet.

The integration now knows the expected probe/channel layout, but it does not create fake temperature entities, enable writes or enable live transports for those models until real hardware reports confirm the payload mapping.

v0.2.1 was smoke-tested on my real INT-14-BW before release:

  • existing config entry/device remained stable
  • 8/8 live temperature channels populated
  • BLE snapshot/write passed
  • Tuya LAN polling/write validated with the integration LAN module

Validation thread:

If you have one of these newer INT models, especially INT-31-BW, INT-14S-BW, INT-12E-BW, INT-33-BW or INT-11S-B, clean validation reports are very welcome.

4

Hello!

Thanx for integration, seems to be useful

Test report for INT-11I-B

Model printed on device/app:

INT-11I-B

Selected profile:

int11i_b / INT-11I-B

Transport tested:

BLE only
Local Home Assistant Bluetooth adapter

Discovery / advertisement:

Name: INT-11I-B
Address: AA:BB:CC:DD:EE:FF
RSSI: about -60 dBm
Manufacturer data:
17544: 196a6588c938c1a42100236400640000

Service UUIDs:
0000ff00-0000-1000-8000-00805f9b34fb

Connectable: true

Result:

BLE connection/status is detected.
Battery/charge information is detected.
Temperature entities stay unavailable/unknown.

Expected result:

The probe temperature should be populated from GATT characteristic:

Service UUID:        0000ff00-0000-1000-8000-00805f9b34fb
Temperature UUID:   0000ff01-0000-1000-8000-00805f9b34fb
Battery UUID:       00002a19-0000-1000-8000-00805f9b34fb

The working ESPHome decoder for this model reads temperature from ff01 as:

raw = int.from_bytes(x[0:2], "little")
fahrenheit = raw / 100.0
celsius = (fahrenheit - 32.0) * 5.0 / 9.0

Battery mapping from 2a19:

x[0] = booster/base station battery %
x[1] = probe battery %

This seems consistent with the merged Bluetooth-Devices/inkbird-ble INT-11I-B support, where this model is handled as a connectable GATT-poll device rather than an advertisement-only decoder.

So the current int11i_b profile in ha-inkbird-int14 appears to connect and read battery/status, but does not yet populate the probe temperature from ff01.

1 Like
5

Thanks Dmitry, this was exactly the missing piece.

I pushed experimental INT-11I-B GATT-poll support to main:

  • ff01 temperature as little-endian Fahrenheit hundredths
  • 2a19 battery as base/booster + probe battery
  • writes disabled for now
  • INT-11I-B profile reduced to 1 physical probe / 1 live temperature channel

Could you test current main before I cut v0.2.2?
Expected result: probe temperature should populate in BLE only mode, battery should still populate, and no write controls should be exposed for INT-11I-B.

6

Wunderfull, gonna test.

By reconfiguring i got a error

1000114956
10001149561440×3168 105 KB

Tomorrow i gonna check how to get wifi woking with the key, and the ble option by my esphome network and report back! Thanks

7

Thanks, that was a real integration bug.

I pushed a fix to main:

  • added a proper Home Assistant reconfigure flow
  • hardened form defaults so old/partial entries do not crash the config flow with a 500 error
  • reconfigure now reloads the integration after saving

Commit: e7438be

Could you test current main again? If it works on your side too, I’ll cut a v0.2.2 patch release for HACS.

8

Now it works perfect, ty!

Screenshot6
Screenshot62088×1254 134 KB

1 Like
9

Great, thanks Dmitry. I’ll mark the current BLE read path as community-validated.

Writes are intentionally disabled in the current release, but they are planned. The Inkbird app contains a separate ff02 write protocol for alarm targets and device settings.

Would you be willing to test an experimental build? We would start with a harmless setting with readback, such as display brightness or temperature unit, and then validate high/low temperature alarm targets.

10

Awesome - I’ve a INT-14S-BW on the way so will be looking forward to using/testing this!

11

Awesome, thanks Rob — INT-14S-BW would be a really useful one to validate.

I already added an INT-14S-BW profile, but it is intentionally marked as cataloged/experimental for now. From the app/model data it looks like a different multi-sensor layout than the tested INT-14-BW: 4 physical probes, probably multiple temperature channels per probe.

So when yours arrives, the first useful test would be very simple:

  • install the latest release
  • add “Inkbird INT”
  • select the INT-14S-BW profile
  • check whether Home Assistant discovers it over BLE
  • check what diagnostics/battery/state entities appear
  • compare the HA entities with what the official Inkbird app shows

Temperature channels may not populate yet, and that’s expected. I didn’t want to fake live support until someone with real hardware can confirm the payloads.

If you’re happy to share redacted logs/screenshots when it arrives, that would be perfect. The most useful bits are: app screen showing the probe/channel layout, HA debug logs, BLE advertisement/service data if available, and which channel changes when you heat each probe/sensor area.

No need to test writes at the beginning — read-only validation first is already very helpful.

12

Small update after quite a few late-night debugging sessions :slightly_smiling_face:

The INT integration has grown beyond the original INT-14-BW implementation, so I have now reorganized and updated the repository, documentation and wiki to better reflect the current status of the supported and experimental models.

Recent work includes improved BLE reconnect handling for the INT-14-BW, experimental support for additional INT-family thermometers, and community-validated read support for the INT-11I-B and INT-14S-BW.

The current v0.2.6 beta is still being tested, but the latest feedback has been very encouraging: even though some stations intentionally terminate their BLE connection after roughly 30 seconds, the integration now reconnects automatically and continues updating normally.

There are still a few details to polish, including the relationship between the configured polling interval and notification-driven temperature updates, but overall it is becoming considerably more stable.

Updated repository and documentation:

A big thank you to everyone testing real hardware and sending detailed reports. They have been extremely useful in finding behaviours that would have been almost impossible to reproduce with only my own device.

13

I mixed some fantastic work and made it in hacs as a dashboard strategie so other users can enjoy/improve.

what to you think?

14

This is very interesting — I’ll definitely give it a proper try during my next cooking session with the Primo Kamado.

At first glance, it looks like a really useful companion to the integration, especially the presets, alerts and custom recipe flow. I’m curious to see how it behaves during a real cook rather than just looking through the repository.

One important question, though: do I need to open an issue for a pulled pork preset, or are you going to add it voluntarily? :grinning_face_with_smiling_eyes:

I also noticed that you already implemented stall detection, which is a very nice touch. Have you considered turning wrapping or foiling into an actual cooking phase, with separate stages or targets for brisket, pulled pork and ribs?

I’ll let you know how it goes after the cook.

Thanks for building and sharing it!

15

Nice, just the first version And my first experience of dashboard flow and hacs etc.. so all feedback is welcome.

I’m also curious not tested in real life yet, this saterday :slight_smile:

Ofcourse I will add it for you (the least thing I can do)
i always use this recepy: Wedstrijd pulled pork van de barbecue, zo maak je het - door Noskos BBQ

but If you have other values no problem i will add. and pull request also welcome. I think recepts is personal therefore the custom option will be great.

The only thing is that I can use the inkbird only in the bluetooth mode. I added it to smart life (useless because of the values and misses options) But never succeseeded futher :(. any tips?
inkbird app is also good, but my policy is to have everythin integrated in home assistant :stuck_out_tongue:

thanks again for your hard work, that is still the foundation of this!!!

16

I agree that recipes are personal, but I don’t think the dashboard needs a separate hard-coded preset for every possible variation.

Most long cooks follow roughly the same reusable flow: cook unwrapped, detect the stall or wait for the bark to set, optionally wrap, continue towards the finishing range, check tenderness, then vent and rest or hold.

What really changes between recipes is the temperature, timing and which stages are enabled. A small stage editor could let people change those values and save their own presets without needing dozens of built-in recipes.

Triggers could include temperature, elapsed time, stall detection and manual confirmation. Bark, wrapping and final tenderness cannot always be determined reliably from temperature alone. Ribs probably need their own simpler template too, since wrapping is optional and the bend test is often more useful than a fixed internal temperature.

About Wi-Fi: you probably haven’t missed a hidden setup step.

Pairing the INT-14S-BW with Smart Life confirms that the station can use the Tuya platform, but it does not automatically mean that its local Tuya LAN data can already be understood by Home Assistant.

At the moment, the integration supports the INT-14S-BW through read-only BLE. Local Tuya LAN has been validated on the INT-14-BW, but we have not yet captured and validated the INT-14S-BW data-point map, so I don’t want to blindly reuse the INT-14-BW mapping and expose incorrect values or controls.

If you’re interested, we can open a separate GitHub Discussion and investigate it with a read-only LAN capture. We would need the station IP, device ID and local key; the protocol version can usually be tested. Please never post the device ID or local key publicly.

Until that capture is done, BLE-only operation on the INT-14S-BW is the expected result, not a configuration failure.

17

I will do that improvements!

And more wishes, pr, or requests are welcome!

for the wifi setup: when added to smart life it not come into my tuya cloud or available in tinytuya.
Do you have tips for that? I removed it from the inkbird app.
I defienatly want to provide info and help

18

Great, thanks for being willing to help. This could be our chance to understand whether the INT-14S-BW can also work locally over Wi-Fi.

Tuya has made this part much more confusing than it should be. Adding the station to Smart Life does not automatically make it appear in a Tuya Developer project, even if you used the same email address.

On my INT-14-BW setup I already had the required device credentials from the development work, so I did not personally go through this exact procedure from a fresh Smart Life account. This is the standard route, but the INT-14S-BW may still have some additional Inkbird/Tuya restriction.

First, please don’t remove or pair the station again. A new pairing can change its local key, so keeping the current setup intact will save us some trouble.

In Smart Life, check the account region under:

Me > Settings > Account and Security > Region

Then open your project on the Tuya Developer Platform and make sure its data center is compatible with that region. For European accounts, Central Europe is often the correct choice, but follow the region shown in Smart Life rather than guessing.

Inside the Tuya project, go to:

Devices > Link Tuya App Account > Add App Account

Choose automatic linking with read-only access, scan the QR code using Smart Life and check whether the station appears under All Devices.

Also check the project’s Service API section and make sure IoT Core and Authorization are subscribed and authorized.

If the station appears, try:

python -m tinytuya wizard

You can also run:

python -m tinytuya scan

The scan may find the station’s IP address, device ID and protocol version on your network. It cannot recover the local key by itself, but it will tell us whether the station is exposing a Tuya LAN service.

If the scan finds it but the wizard does not, the problem is probably the Tuya account link or data-center selection. If everything looks correct and the device still refuses to appear, that is useful information too: we may be dealing with an Inkbird/Tuya OEM limitation rather than something you did wrong.

For the actual testing, let’s continue in the existing INT-14S-BW GitHub Discussion.

It already contains the BLE validation work for this model, so it makes sense to keep the Wi-Fi investigation, screenshots, captures and test builds there as well.

Just hide the device ID, local key and any credentials before attaching anything. Once we understand what the INT-14S-BW exposes over Wi-Fi, we can come back here and share the useful result with everyone.

19

I tried it yesterday and it was in the smart life app (turned integration off)
In smart life the vlaues were strange. but it doesnt matter because i want only use the home assistant steering :stuck_out_tongue:
in the tuya portal it became available.
but the python -m tinytuya scan. gives only 2 other devices. not my inkbird.

in the mean time: I finetuned the settings a bit more for the dashboard.

20

maybe this is very good news: