-
-
Notifications
You must be signed in to change notification settings - Fork 0
Complete guide EN
This page explains how to use ha-inkbird-int14 with Home Assistant and what the integration can realistically provide.
The main target is still the Inkbird INT-14 / INT-14-BW station with wireless probes and Wi-Fi/Bluetooth support. That is the device tested with real live readings.
The component is no longer hardwired as if INT-14 were the only member of the family. During setup you choose a model profile. The profile tells Home Assistant how many physical probes and expected temperature channels exist, which transports make sense and which commands should be blocked.
In practice:
- INT-14-BW: tested;
- INT-14P, INT-12, INT-12I and INT-11I: experimental;
- INT-14S-BW: community-validated read-only BLE with 20 live temperatures (4 food + ambient for each of 4 probes);
- INT-12E-BW: community-validated read-only BLE with 10 live temperatures (4 food + ambient for each of 2 probes), available in the
v0.2.6prerelease line; - INT-11P, INT-11S, INT-31 and INT-33: cataloged, with expected probe/channel layout but no validated live reads yet.
INT-11I-B note: a community report from Dmitry/dskudrin validated BLE as a GATT-poll device. ff01 exposes one probe temperature in little-endian Fahrenheit hundredths; 2a19 exposes two battery bytes, base/booster first and probe second. It remains read-only for now: writes are disabled until validated on hardware.
INT-14S-BW note: its BLE parser comes from authenticated diagnostics and controlled tests shared by a real device owner. Its 20 read-only temperatures are available in the stable integration. Normal controls, Tuya LAN and cloud remain disabled for this profile. The v0.2.6 prerelease has two disabled-by-default C/F diagnostic buttons for a small, reversible write test; they are not general write support.
INT-12E-BW note: notifications normally update its temperatures roughly every three seconds. The configurable 5-300 second interval controls only fallback direct reads; it does not slow down valid notifications. The station has been observed closing each BLE session after about 30 seconds with reason 0x13, and the integration reconnects automatically. Food 4 is confirmed as the tip channel on both probes, while the physical order of Food 1-3 still needs mapping. LAN, cloud, writes and protocol-state entities remain disabled.
The Model profiles page keeps the current list.
Behavior may vary depending on:
- hardware revision;
- firmware version;
- station Wi-Fi state;
- distance from the Bluetooth adapter or Bluetooth proxy;
- station and probe battery state;
- probes inserted, charging or disconnected.
If you have a similar but not identical model, open a Discussion with the exact model, firmware version and symptoms. For experimental profiles, even a clean "this does not work yet" report is useful if the logs are redacted.
The integration is hybrid and local-first. In plain terms: it tries to stay local when it can, without pretending that every device state comes from the same path.
It uses local paths whenever possible:
- local BLE for snapshots, state, battery and supported commands;
- local Tuya LAN for Wi-Fi station polling and mapped writes when
host,device_idandlocal_keyare configured; - optional experimental read-only cloud history.
There are no cloud writes. Full cloud live control is not supported.
- Open HACS.
- Open Custom repositories.
- Add:
https://github.com/zampix1/ha-inkbird-int14
- Category: Integration.
- Install.
- Restart Home Assistant.
- Add the integration from Settings -> Devices & services.
BLE does not require a cloud account or local key.
Home Assistant must be able to reach the station over Bluetooth:
- a USB Bluetooth adapter attached to Home Assistant;
- an ESPHome Bluetooth proxy near the thermometer;
- another Bluetooth proxy supported by Home Assistant.
If the Home Assistant server is far away from the cooking area, an ESPHome Bluetooth proxy near the thermometer is often more useful than a USB dongle in the server rack.
Profiles with a connected GATT loop also show BLE fallback direct-read interval in setup, reconfigure and options. Leave it at 10 seconds unless troubleshooting. This is a backup read interval, not a cap on notification-driven entity updates.
INT-14-family BLE sessions perform a local challenge/response before snapshots and command readback. INT-11I-B and INT-12E-BW use their own direct GATT read paths instead, so not every profile exposes the same authentication diagnostics.
This does not use user credentials. It only moves the local BLE session into the state expected by the station.
Useful diagnostic entities:
-
BLE Auth OK; -
Last BLE Auth Error; -
Last BLE Auth Ack; -
Last BLE Auth Request Epoch; -
Last BLE Auth Ack Epoch.
If BLE Auth OK is True, the local BLE session was authenticated.
To use the station over local Wi-Fi, provide:
- station host or IP;
- device ID;
- local key;
- protocol version, usually
3.5; - poll interval.
In plain terms:
| Field | What to enter |
|---|---|
| Host or IP | The station address on your LAN. A router DHCP reservation is recommended. |
| Device ID | The Tuya identifier for your station. It is not the model name. |
| Local key | The Tuya local key for this specific device. It is not your Wi-Fi password and not your Inkbird password. |
| Protocol version | Usually 3.5 for the tested INT-14-BW station. |
| Poll interval | How often Home Assistant polls the station. Start with 10 seconds. |
The integration does not retrieve the local key automatically. Get it from your own device/account with an external Tuya/local-key workflow, then paste it into the Home Assistant setup or options. If you already use LocalTuya, TinyTuya or another Tuya LAN tool for the same station, these are the same kind of values. Follow those tools' current documentation for key extraction. If you reset or re-pair the station, the local key may change.
This integration does not ask for Tuya cloud credentials. It only needs the final local values for your own station.
Practical routes:
- If the station is already configured in LocalTuya, Tuya Local or another Tuya LAN tool, reuse the same values: IP/host, device ID, local key and protocol version.
- TinyTuya can scan the LAN and run its wizard:
python -m pip install tinytuya
python -m tinytuya scan
python -m tinytuya wizardAfter the wizard, look for the station in devices.json. Useful fields usually look like:
{
"name": "example name",
"id": "example-device-id",
"key": "example-local-key",
"ip": "192.0.2.10",
"version": "3.5"
}- The Tuya IoT developer portal can show the same values after linking the app account that owns the device. The usual path is cloud project, device list, API Explorer and a device details query.
devices.json, device IDs, local keys, API keys and API secrets are private. Do not upload them to GitHub and do not paste them into issues.
Useful references:
- TinyTuya: https://github.com/jasonacox/tinytuya
- Tuya Local device details guide: https://github.com/make-all/tuya-local/blob/main/DEVICE_DETAILS.md
- LocalTuya: https://github.com/rospogrigio/localtuya
Recommended sequence:
- set up the station in the Inkbird app and verify that Wi-Fi works;
- reserve a fixed IP for the station in your router if possible;
- get the station device ID and local key;
- in Home Assistant open Settings -> Devices & services -> Inkbird INT;
- enter host/IP, device ID, local key, version
3.5and poll interval10; - enable the LAN test before saving if you want an immediate check;
- leave transport mode on
Autofor normal use.
These values are private and must not be posted in public issues or screenshots. Replace them with placeholders when asking for help.
LAN is useful for stable polling when the station is connected to Wi-Fi. In Auto, the integration prefers LAN when the LAN configuration is complete.
Auto
Uses the most practical transport. If LAN is configured, it tends to use LAN instead of keeping BLE connected continuously.
BLE only
Forces the BLE path. Depending on the profile this can mean one-shot snapshots and supported local commands, or a read-only connected GATT loop. For INT-12E-BW, notifications are applied immediately and the configured direct-read interval is only a fallback.
Wi-Fi LAN only
Uses only local Tuya LAN. Requires a correct host, device ID and local key.
Wi-Fi cloud only
Uses only the optional experimental read-only cloud history.
The integration exposes only the entities that are valid for the selected profile. Depending on the model, these can include:
- station/base temperature;
- core temperature for the probes declared by the selected profile;
- ambient temperature for the probes declared by the selected profile, when available;
- probe connection/charging/paired state;
- station battery;
- probe batteries when reported by the station;
- active transport state;
- LAN/cloud/BLE state;
- target high/low;
- timers;
- pre-alarm;
- calibration;
- C/F unit;
- display/backlight.
Many raw or fragile entities are diagnostic or disabled by default. That is intentional: the default dashboard should stay readable, while the noisy details are still there when you need to debug.
Authenticated local BLE testing showed that the station may keep reporting all probes as 100%, even when that is unlikely to be the real battery level.
For that reason the integration:
- keeps fresh numeric values available;
- does not hide the value;
- exposes
Battery Report Quality; - exposes diagnostic
suspectsensors/binary sensors.
If you see suspect_probe_100_plateau, the station reported a suspicious plateau. Home Assistant is not inventing or correcting the value.
Local writes use LAN when available and BLE when both the selected transport and model profile allow it. INT-14S-BW, INT-12E-BW and INT-11I-B remain read-only in normal use.
Expected commands:
- C/F unit;
- display/backlight;
- target temperature;
- pre-alarm;
- timer;
- timer reset;
- calibration.
Writes may depend on firmware and radio state. After a write, check readback or the station UI.
Cloud history is:
- optional;
- disabled by default;
- read-only;
- limited to DP109 history;
- never used for writes.
Do not post cloud credentials in public issues.
Do not publish:
- real BLE address;
- real LAN IP;
- local key;
- device ID;
- token;
- API secret;
- screenshots with private data;
- entity IDs if they contain personal names.
Use placeholders such as:
AA:BB:CC:DD:EE:FF
192.0.2.10
example-device-id
example-local-key
Use Discussions for general questions and feedback:
https://github.com/zampix1/ha-inkbird-int14/discussions
Use Issues for reproducible bugs:
https://github.com/zampix1/ha-inkbird-int14/issues
Please include:
- exact model;
- firmware if visible;
- selected transport;
- redacted logs;
- expected result;
- observed result.