INT-14S-BW validation report – BLE transport disabled

[lyonhome]

Exact model

INT-14S-BW

Profile used

int14s_bw

Transport tested

BLE only with local adapter

Physical probes shown by the Inkbird app

4

Temperature channels shown by the Inkbird app

20

Which channel changes when each probe section is heated

No response

Redacted app screenshots

No response

Test environment

home assistant

Readings and entities

Say which temperatures, battery/state fields and diagnostics populated.

Writes or controls tested

No response

Notes

Hi,

I would like to help validate the Inkbird INT-14S-BW.

Model:
INT-14S-BW

Integration version:
v0.2.2

Home Assistant:
Home Assistant OS

Bluetooth adapter:
ASUS USB-BT540, detected as Realtek Bluetooth Controller

Inkbird firmware:

• Bluetooth firmware: V1.0.2
• Probe firmware: V1.3.1
• 4 physical probes
• 20 expected temperature channels

Current integration state:

• Configured Model: INT-14S-BW
• Model Support Status: cataloged
• Transport Mode: BLE only
• Active Transport: profile_cataloged_only
• BLE Transport Enabled: off
• BLE Connected: off
• Mapped Live Temperature Channel Count: 0
• Temperature Unit: unknown

The thermometer works correctly in the official Inkbird app.
The Home Assistant Bluetooth adapter is active, but the integration does not enable BLE for this profile.

I can provide sanitized diagnostics and assist with testing.

config_entry-inkbird_int14-01KX6SDK5CK11CDVRETAF06GB3 (1).json

Privacy check

• I sanitized private addresses, IDs, keys, credentials, Wi-Fi names, screenshots and entity IDs.

[zampix1]

Hi, thanks a lot — this is a very useful INT-14S-BW baseline report.

What you are seeing is expected with v0.2.2: int14s_bw is currently marked as cataloged, so the integration intentionally disables BLE live decoding and does not create temperature entities yet.

The important confirmation from your report is:

• INT-14S-BW
• 4 physical probes
• 20 temperature channels in the Inkbird app
• HA profile selected correctly
• the integration correctly refuses to fake live support while the parser is not validated

So the next step is not a normal user test, but a read-only validation/debug build.

If you are happy to help, the most useful next data would be:

1. Keep profile int14s_bw.
2. Keep the official Inkbird app fully closed while testing BLE, if possible.
3. Enable debug logging:

   logger:
     logs:
       custom_components.inkbird_int14: debug
       homeassistant.components.bluetooth: debug
       bleak_retry_connector: debug

Restart Home Assistant or reload logging.
Put the station close to the Bluetooth adapter.
Trigger a snapshot attempt from Home Assistant.
Share sanitized:Home Assistant logs around the snapshot attempt
integration diagnostics
the app screen showing the 20 channels
if possible, screenshots/notes while warming one section at a time

For the mapping test, the most useful sequence is:
baseline: all probes at room temperature
warm probe 1 tip only
warm probe 1 middle/body section
warm probe 1 ambient/handle area
repeat for probe 2 if possible
Please keep MAC addresses, IPs, device IDs, local keys, Wi-Fi names and account/account IDs redacted.
No writes for now. I only want to validate discovery, services/characteristics, battery/state and the 20-channel temperature payload first.
Once I have one or two clean logs, I can prepare an experimental read-only branch/prerelease that enables BLE decoding for INT-14S-BW without exposing write controls.

[lyonhome]

Hi, Thanks for your help. I completed the requested validation on my *Inkbird INT-14S-BW*. Environment - Home Assistant Core *2026.7.2* - Home Assistant OS *18.1* - Integration *ha-inkbird-int14 v0.2.2* - Transport mode: *BLE only* Validation completed I performed the requested mapping tests on *Probe 1*: 1. Baseline (room temperature) 2. Heated the probe tip only 3. Heated the middle/body section only 4. Heated the ambient/handle section only I captured screenshots for each step showing the five internal temperature channels (Food 1–4 + Ambient). Diagnostics I have attached the Home Assistant diagnostics JSON. Snapshot result Every Request Snapshot attempt failed with the following message: INT14 ad-hoc BLE snapshot failed: Failed to connect after 9 attempt(s): No backend with an available connection slot that can reach address... unknown (never seen by any scanner) The device is correctly detected as *INT-14S-BW* and the diagnostics confirm the configuration is correct, but BLE snapshots are unable to connect. If it helps, I can also provide: - all screenshots from the four mapping tests - additional Home Assistant logs - more validation tests I'd be happy to test an experimental build or prerelease if you prepare one. Thanks again for working on INT-14S-BW support! Op di 14 jul 2026 om 23:49 schreef zampix1 ***@***.***>:

…

Hi, thanks a lot — this is a very useful INT-14S-BW baseline report. What you are seeing is expected with v0.2.2: int14s_bw is currently marked as cataloged, so the integration intentionally disables BLE live decoding and does not create temperature entities yet. The important confirmation from your report is: - INT-14S-BW - 4 physical probes - 20 temperature channels in the Inkbird app - HA profile selected correctly - the integration correctly refuses to fake live support while the parser is not validated So the next step is not a normal user test, but a read-only validation/debug build. If you are happy to help, the most useful next data would be: 1. Keep profile int14s_bw. 2. Keep the official Inkbird app fully closed while testing BLE, if possible. 3. Enable debug logging: logger: logs: custom_components.inkbird_int14: debug homeassistant.components.bluetooth: debug bleak_retry_connector: debug Restart Home Assistant or reload logging. Put the station close to the Bluetooth adapter. Trigger a snapshot attempt from Home Assistant. Share sanitized:Home Assistant logs around the snapshot attempt integration diagnostics the app screen showing the 20 channels if possible, screenshots/notes while warming one section at a time For the mapping test, the most useful sequence is: baseline: all probes at room temperature warm probe 1 tip only warm probe 1 middle/body section warm probe 1 ambient/handle area repeat for probe 2 if possible Please keep MAC addresses, IPs, device IDs, local keys, Wi-Fi names and account/account IDs redacted. No writes for now. I only want to validate discovery, services/characteristics, battery/state and the 20-channel temperature payload first. Once I have one or two clean logs, I can prepare an experimental read-only branch/prerelease that enables BLE decoding for INT-14S-BW without exposing write controls. — Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=CG6LCCB4LWS27EGEOBCDPL35E2TFZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGQYTCMBZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17641109>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CG6LCCHBLNX5RU4TWCIFYA35E2TFZAVCNFSNUABJKJSXA33TNF2G64TZHMYTEOBVGQ3TSOJUGE5UI2LTMN2XG43JN5XDWMJQGQYDOOJZG2QXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CG6LCCDDM56X5DSEFMLN7UD5E2TFZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGQYTCMBZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CG6LCCDG6DDOJUHDRGGS7NL5E2TFZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGQYTCMBZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[zampix1]

Hi, thanks - I have prepared a prerelease specifically for this first read-only step:

v0.2.3-beta.1 - Cataloged model BLE diagnostics

This build does not enable INT-14S-BW temperature entities and does not expose any writes. It adds a Capture BLE Diagnostics button that:

• asks Home Assistant for the configured BLE address;
• requests one active scan if the station is not currently in the Bluetooth cache;
• can recover through one unambiguous INT-14S-BW name match;
• inventories GATT services and characteristics;
• reads readable characteristics and listens briefly for unsolicited notifications;
• sends no Inkbird authentication, snapshot, pairing or settings commands.

To test it:

1. Enable beta/prerelease versions for this repository in HACS and install v0.2.3-beta.1.
2. Restart Home Assistant.
3. Keep profile int14s_bw and select BLE only or Auto.
4. Fully close the Inkbird app, wake the station and keep it close to the adapter.
5. Press Capture BLE Diagnostics once and wait at least 15 seconds.
6. Download the integration diagnostics and attach the sanitized JSON here.

Please also attach the four redacted app screenshots you already captured, or write the mapping as a small table: physical section heated -> app channel(s) that changed. That work is useful independently from the BLE connection.

The new diagnostic status should tell us whether the remaining boundary is scanner visibility, an ambiguous device-name match, GATT connection, or simply a device that requires the application handshake before sending temperature data.

If the result is still scanner_not_seen, the parser has not been reached yet: Home Assistant needs a local adapter or ESPHome Bluetooth Proxy that can actually see the station while it is awake.

[lyonhome]

Hi, Great news! I tested *v0.2.3-beta.1* and attached the new diagnostics JSON. The results are much better than before. BLE diagnostics summary - BLE diagnostics completed successfully. - Scanner found the configured device. - Scanner match count: *1* - Connected successfully for diagnostics. - 4 GATT services discovered. - 17 characteristics discovered. - 16 readable characteristics successfully read. - 1 notification received. - No read errors. - No notification errors. - No application commands were sent (as expected). This means the device is now visible to Home Assistant and the BLE diagnostics are able to connect and inspect the device successfully. I have also completed the requested probe mapping tests (baseline, tip, middle, ambient) and can provide the screenshots if needed. Please let me know what you would like me to test next. Thanks again! Op wo 15 jul 2026 om 10:36 schreef zampix1 ***@***.***>:

…

Hi, thanks - I have prepared a prerelease specifically for this first read-only step: *v0.2.3-beta.1 - Cataloged model BLE diagnostics <https://github.com/zampix1/ha-inkbird-int14/releases/tag/v0.2.3-beta.1>* This build does not enable INT-14S-BW temperature entities and does not expose any writes. It adds a Capture BLE Diagnostics button that: - asks Home Assistant for the configured BLE address; - requests one active scan if the station is not currently in the Bluetooth cache; - can recover through one unambiguous INT-14S-BW name match; - inventories GATT services and characteristics; - reads readable characteristics and listens briefly for unsolicited notifications; - sends no Inkbird authentication, snapshot, pairing or settings commands. To test it: 1. Enable beta/prerelease versions for this repository in HACS and install v0.2.3-beta.1. 2. Restart Home Assistant. 3. Keep profile int14s_bw and select BLE only or Auto. 4. Fully close the Inkbird app, wake the station and keep it close to the adapter. 5. Press Capture BLE Diagnostics once and wait at least 15 seconds. 6. Download the integration diagnostics and attach the sanitized JSON here. Please also attach the four redacted app screenshots you already captured, or write the mapping as a small table: physical section heated -> app channel(s) that changed. That work is useful independently from the BLE connection. The new diagnostic status should tell us whether the remaining boundary is scanner visibility, an ambiguous device-name match, GATT connection, or simply a device that requires the application handshake before sending temperature data. If the result is still scanner_not_seen, the parser has not been reached yet: Home Assistant needs a local adapter or ESPHome Bluetooth Proxy that can actually see the station while it is awake. — Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=CG6LCCHB2SEX7S546UOQFXT5E467VA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGQ3DGMZYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17646338>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CG6LCCCWYCLY2DYV5BI4GFD5E467VAVCNFSNUABJKJSXA33TNF2G64TZHMYTEOBVGQ3TSOJUGE5UI2LTMN2XG43JN5XDWMJQGQYDOOJZG2QXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CG6LCCB2R3Z6F3YRZWGSXB35E467VA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGQ3DGMZYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CG6LCCDBGHMQCHHQKJEKSWL5E467VA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGQ3DGMZYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[zampix1]

Excellent - this confirms that the scanner/discovery problem is fixed and that the INT-14S-BW exposes a usable connectable GATT surface.

One GitHub/email detail: the diagnostics attachment did not reach the Discussion. The comment contains the text summary, but there is no JSON attachment or download link. GitHub appears to have stripped the attachment from the email reply.

Could you please open this Discussion in the browser and drag/drop these files directly into a new comment?

• the diagnostics JSON from the successful capture;
• the four redacted app screenshots: baseline, tip, middle/body and ambient/handle.

Suggested filenames would be helpful, for example:

• int14s_ble_diagnostics_baseline.json
• int14s_probe1_baseline.png
• int14s_probe1_tip.png
• int14s_probe1_middle.png
• int14s_probe1_ambient.png

Please give the JSON one final privacy check before uploading, although the beta already redacts the configured address and any IP address embedded in diagnostic errors.

The JSON is the important next input: I need the 17 characteristic UUID/property sets, the 16 readable values and the raw notification so I can identify which characteristic carries live temperatures and whether the station requires the existing BW authentication/snapshot handshake.

You do not need to repeat the heating tests yet. Once I have these files, I will inspect them first and prepare a focused beta.2 capture if we need synchronized raw BLE samples for each heated section.

Thanks - this is real progress. We are past Bluetooth reachability and now at the actual payload-decoding stage.

[lyonhome]

Hi,

I have uploaded the requested files directly through the GitHub Discussion:

• successful v0.2.3-beta.1 BLE diagnostics JSON
• Probe 1 baseline screenshot
• Probe 1 tip screenshot
• Probe 1 middle/body screenshot
• Probe 1 ambient/handle screenshot

I have not repeated the heating tests.

Please let me know when the focused beta.2 capture is ready and I will be happy to test it.

Thanks!

config_entry-inkbird_int14-01KX6SDK5CK11CDVRETAF06GB3 (3).json v2.txt

[zampix1]

Thanks, I have now published the focused second-stage build:

v0.2.3-beta.2 - Authenticated INT-14S BLE diagnostics
https://github.com/zampix1/ha-inkbird-int14/releases/tag/v0.2.3-beta.2

This build keeps INT-14S-BW cataloged and non-live. It adds a separate Capture Authenticated BLE Diagnostics button. Unlike the beta.1 passive capture, this button sends the volatile Inkbird session challenge/response and snapshot query frames. The normal clock-sync frame is omitted, and the diagnostic path cannot send unit, display, target, timer, calibration, pairing or provisioning commands.

For this first beta.2 capture:

1. Enable prereleases in HACS and install v0.2.3-beta.2.
2. Restart Home Assistant.
3. Keep profile int14s_bw and transport BLE only or Auto.
4. Fully close the Inkbird app.
5. Take Probe 1 out of the dock, wake the station and leave it at a stable room temperature near the HA adapter.
6. Press Capture Authenticated BLE Diagnostics (not the original passive button) once.
7. Wait at least 20 seconds.
8. Download fresh integration diagnostics and attach the sanitized JSON here.

You do not need to repeat the heating tests yet. This capture should tell us whether authentication replaces the FF01 sentinel values with six live raw slots per physical probe. Once that is confirmed, I can give you one short synchronized mapping test for the exact slot order.

Thanks again for the very useful beta.1 capture and screenshots.

[lyonhome]

Hi,

I tested v0.2.3-beta.2 as requested.

The authenticated BLE diagnostics JSON is attached.

Probe 1 was removed from the dock and left at room temperature during the capture, exactly as requested.

Please let me know what you would like me to test next.

Thanks again for your work on INT-14S-BW support!

config_entry-inkbird_int14-01KX6SDK5CK11CDVRETAF06GB3 (4).json v3.txt

[zampix1]

Thanks - this authenticated capture was exactly what was needed.

Authentication completed successfully, all snapshot queries were accepted, and FF01 returned a stable 54-byte live frame with Probe 1 active and Probes 2-4 using the docked/unavailable sentinel. The field order and scales are now confirmed:

• Internal aggregate: Fahrenheit hundredths
• Food 1-4: Fahrenheit hundredths
• Ambient: Fahrenheit tenths
• station temperature: Fahrenheit tenths

I have published the next prerelease:

v0.2.3-beta.3 - Experimental INT-14S BLE temperatures
https://github.com/zampix1/ha-inkbird-int14/releases/tag/v0.2.3-beta.3

This build enables the 20 physical temperature channels over BLE: Food 1-4 plus Ambient for each of the four probes. It remains deliberately read-only: INT-14S Tuya LAN, cloud and all settings controls are still disabled. The snapshot path also omits clock synchronization and sends only authentication plus read queries.

Could you please run this focused test?

1. Install v0.2.3-beta.3 from HACS and restart Home Assistant.
2. Keep int14s_bw with BLE only or Auto, and fully close the Inkbird app.
3. Remove Probe 1 from the dock and verify that Food 1-4 and Ambient all populate with plausible temperatures. Probes 2-4 should remain unavailable while docked.
4. Remove Probe 2 as well and verify that its five channels populate without Probe 1 disappearing.
5. Attach one redacted Home Assistant screenshot and fresh sanitized integration diagnostics.

There should be no target, timer, calibration, unit or display controls for this profile. Please report it as a bug if any write control appears.

You do not need to repeat the tip/middle/ambient heating sequence: your screenshots plus this authenticated frame already gave us the mapping needed for this beta.

[lyonhome]

Hi,

I tested v0.2.3-beta.3 as requested.

Probe 1 and Probe 2 both populate correctly, with Food 1-4 and Ambient showing plausible room-temperature values. Probe 1 remained available after removing Probe 2 from the dock.

Probes 3 and 4 remained unavailable while docked. I also did not see any target, timer, calibration, unit or display controls for this profile.

I have attached one redacted Home Assistant screenshot and fresh sanitized integration diagnostics.

Thanks again!

config_entry-inkbird_int14-01KX6SDK5CK11CDVRETAF06GB3.json.V4.txt

[zampix1]

Excellent - the beta.3 temperature path is validated.

Your diagnostics confirm:

• profile int14s_bw, BLE-only transport and an active BLE connection;
• 4 physical probes and 20 mapped temperature channels;
• Probe 1 and Probe 2 both returning plausible Food 1-4 and Ambient values;
• Probe 3 and Probe 4 returning the expected unavailable sentinel while docked;
• no Home Assistant diagnostic issues;
• no settings controls exposed.

Your screenshots also caught one useful cleanup item before a stable release: the inherited Charging, Connected, Paired, timer and alarm binary sensors are not trustworthy for INT-14S yet. For example, Probe 1 was actively returning temperatures while Connected showed off, and Charging showed on while it was outside the dock. Those fields come from a model-specific state frame that we have not decoded, so they should not be presented as real states.

I have published the cleanup build:

v0.2.3-beta.4 - Hide unvalidated INT-14S states
https://github.com/zampix1/ha-inkbird-int14/releases/tag/v0.2.3-beta.4

It keeps the validated 20 BLE temperature channels, station temperature and battery path, but stops providing the unvalidated charging/connection/pairing/timer/alarm/Wi-Fi/sound/mute entities. BLE transport and derived battery-quality diagnostics remain.

For the final beta check, please install beta.4, restart Home Assistant and confirm:

1. the same 20 temperature channels still populate;
2. the invalid protocol-state entities are no longer active/provided;
3. no write controls appear.

Because beta.3 already created those entity-registry entries, Home Assistant may retain some as unavailable leftovers. That is different from the integration actively providing them; they can be removed manually after this test. Please mention whether you see active values or only unavailable old entries.

Once this cleanup is confirmed, I will treat INT-14S-BW BLE temperatures as community-validated and prepare the stable v0.2.3 release.

[lyonhome]

Hi,

I tested v0.2.3-beta.4.

The 20 temperature channels still populate correctly.

The previously unvalidated state entities are no longer actively provided. Any remaining old entries are only unavailable entity-registry leftovers.

I also confirmed that no write controls are exposed.

Thanks again!

config_entry-inkbird_int14-01KX6SDK5CK11CDVRETAF06GB3 v4.json

[zampix1]

That’s it — this was exactly the last confirmation I was waiting for.

Thank you, genuinely, for sticking with four beta builds and for giving clear feedback every time. Your captures made it possible to build the temperature parser, and your screenshots caught the misleading inherited state entities before they could reach a stable release.

I’ve now marked INT-14S-BW BLE temperature support as community validated and published v0.2.3.

The honest support boundary for this model is now all 20 temperature channels over BLE, plus battery values when the station reports them. It remains read-only: no LAN, cloud or settings writes yet, and the charging/pairing/timer/alarm states stay hidden until their model-specific bit mapping is properly understood. Any old unavailable entries left in the entity registry can be removed manually; the integration will not actively recreate them.

I’ve credited you in both the changelog and the release notes. Thanks again, @lyonhome — this is exactly how support for hardware I don’t physically own becomes reliable.

[lyonhome]

Hi,

Thank you very much for the kind words and for adding me to the changelog and release notes. I really appreciate it.

It was a pleasure to help test the INT-14S-BW. I'm glad I could contribute and help make support for this model available to the whole Home Assistant community.

Thanks as well for all the work you put into the integration and for responding so quickly to every round of testing. It was great working with you.

Best of luck with the project, and if you ever need another tester in the future, I'd be happy to help!

[zampix1]

Thank you — that really means a lot. It was great working with you too.

I may take you up on that offer for the next phase, but I won’t ask you to test a pile of unverified controls. The sensible first step is one small, reversible BLE write, most likely switching the station between °C and °F and then restoring the original setting. I’ll only ping you again once there is a safe prerelease, a clear before/after procedure and useful diagnostics if the device ignores the command.

For now, enjoy the stable release. You’ve already done more than enough to get INT-14S-BW support over the line.

[zampix1]

Important update before you test: I withdrew the original v0.2.4-beta.1 after a valid report that diagnostics could fail to redact Tuya LAN fields. Please do not use that build. The corrected prerelease is now: v0.2.6-beta.1 – Guarded INT-14S unit write validation This build includes the diagnostics redaction hotfix from stable v0.2.4. If you happened to install the withdrawn beta already, update before downloading or sharing any diagnostics. The test itself is unchanged. This does not enable the normal write controls. It adds only two diagnostic buttons, disabled by default: set Celsius and set Fahrenheit. The integration authenticates first, sends the station-wide unit command, then performs a readback and records the result. When you have time: 1. Enable prereleases in HACS, install v0.2.6-beta.1 and restart Home Assistant. 2. Open the INT-14S device’s entity list, show disabled entities and enable the two Validate BLE Write buttons. 3. Fully close the Inkbird app and note the unit currently shown on the physical station. 4. Press the opposite-unit button once and check whether the station display changes. 5. Download diagnostics immediately. 6. Press the original-unit button once to restore the setting, confirm the display and download diagnostics again. A before/after photo of the station display plus the two sanitized diagnostics files would be ideal. If the first command fails or the display does not change, please don’t keep pressing it — just send that diagnostic and we’ll inspect where it stopped. No rush at all. You already got the read support over the line; this is simply the safest next step whenever it suits you.

[lyonhome]

Hi,

Thanks for letting me know and for preparing the new test.

I'll be away on vacation for the next two weeks, so I won't be able to test it right away.

Once I'm back, I'll install the new beta and, if it's still useful, I'll be happy to give it a try.

Thanks again, and have a great couple of weeks!

[zampix1]

Absolutely no problem — enjoy your vacation and don’t give this another thought for the next two weeks.

The corrected test build will still be here when you get back, and there is no deadline. Stable read support is already released, so this write test can wait until it is convenient for you.

Thanks again for offering to continue. Have a great trip and we’ll pick it up whenever you’re back.

[remb0]

I hope this is usefull.
config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT.json

[zampix1]

Hi @remb0 — yes, this was very useful. It was exactly the capture we needed.

The file is properly sanitized: the station IP, BLE address, device ID and local key are all redacted.

More importantly, DP109 gives us a clean result. It contains the same 54-byte temperature layout already validated over BLE, plus one CRC byte. The LAN temperatures match the BLE values in the same diagnostics value for value, including the three docked/unavailable probes. The final byte also matches CRC-8/ATM, so we can reject corrupted or unexpected payloads instead of showing nonsense temperatures.

I have prepared a new prerelease:

https://github.com/zampix1/ha-inkbird-int14/releases/tag/v0.2.6-beta.7

This beta enables read-only Tuya LAN temperatures for INT-14S-BW. It maps only DP109. Battery/state, target, timer, calibration and all normal writes remain disabled.

For the next test, could you please:

1. Install beta.7 and restart Home Assistant.
2. Keep the correct INT-14S-BW profile.
3. Select Wi-Fi LAN only for a clear LAN-only test.
4. Check that the station temperature and all five channels of the active probe look plausible.
5. Dock or undock one probe and check that its five temperature channels disappear or return together.
6. Let it run through a few polling cycles, then attach one more sanitized diagnostic.

One small side note: the diagnostics show that boris327/ha-inkbird-int14bw is also installed. There is no need to uninstall it, but if it has a config entry for the same station, please disable that entry temporarily during this test so it cannot compete for BLE access.

Thanks — this moved INT-14S LAN support from guesswork to something we can test properly.

[remb0]

wunderfull!
config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (2).json

a lot of (hidden) sensors :)

[zampix1]

That screenshot ended up being useful in two different ways 🙂

First: the good news. The LAN path is definitely working. Home Assistant received the station temperature and all five temperature channels from probe 2, with the other docked probes correctly unavailable.

Second: it caught a cleanup bug on my side. The large group of unavailable Internal, target, timer, calibration and protocol-state entities were not new INT-14S data. Home Assistant had kept old entity-registry entries from the time this same integration entry was configured as INT-14-BW.

I have fixed that in v0.2.6-beta.8. The cleanup is deliberately narrow: it removes only known entities that are incompatible with the selected profile. It does not rename or remove the 20 valid INT-14S temperatures, station temperature, batteries, transport selection or valid diagnostics. No additional writes have been enabled.

When you have a moment, could you install beta.8 through HACS, restart Home Assistant and reopen the device page? The old INT-14-BW-only controls and unavailable Internal temperatures should be gone. The hidden-entity count will not necessarily become zero because some advanced diagnostics are intentionally disabled by default.

If you download diagnostics once more, the field stale_entity_registry_entries_removed will tell us exactly how many old entries were cleaned up. No new LAN capture or private values are needed this time.

Thanks — the screenshot really did expose something that the JSON alone could not show.

[remb0]

this way of work, and your support is great!

config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (3).json

batteries are not available yet.

[zampix1]

Thanks, this file did the trick.

Beta.8 removed 129 stale registry entries, so that cleanup is now confirmed. The batteries were still unavailable because I had deliberately left DP103 unmapped. Your diagnostics contain a clean DP103 frame, and I checked its byte order against the Inkbird app parser: station battery first, then Probes 1-4, followed by a valid CRC.

I have published v0.2.6-beta.9. After installing it and restarting Home Assistant, the five battery entities should populate.

They may all show 100% for now, because that is exactly what the station reported in this capture. No need to deliberately drain anything; just use it normally and, when one value eventually changes, let me know whether Home Assistant follows it.

Beta.9 is still read-only. I have not enabled charging/state/settings DPs or any LAN writes.

[remb0]

yes batterij levels are correct now :)
config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (4).json

[zampix1]

Perfect — that is the confirmation I was waiting for.

I checked the new diagnostics as well: beta.9 is running, the temperatures are still decoding correctly, and the battery entities now match the station. We can consider the INT-14S-BW DP103 battery mapping validated on real hardware.

One small diagnostic detail: the DP103 CRC fields are empty in this particular file because the station does not include the battery frame in every LAN response. Home Assistant keeps the last valid battery values, which is why the entities are correct. I will make the diagnostic remember the last DP103 metadata in a future maintenance update; you do not need to repeat the test.

That closes the battery part. Thanks, and enjoy the thermometer :)

[zampix1]

Since you are testing quickly and the read-only LAN path is now stable, would you be up for one compact settings-mapping round?

Nothing risky would be written by Home Assistant. You would change one setting at a time in the official app, then HA would only take a read-only LAN diagnostic after each change. That should let me identify several missing DPs in one pass.

Please keep Probe 2 undocked, leave the other probes as they are, and use this sequence:

1. Save one baseline diagnostic without changing anything.
2. Change only Probe 2's target temperature to a distinctive value, for example 71 C. Wait about 10 seconds, close the app, then save a diagnostic.
3. Change only the pre-alarm value or toggle it once. Wait, close the app, save another diagnostic.
4. Start a 12-minute timer for Probe 2. While it is running, save another diagnostic.
5. Toggle the station sound/mute setting once and save another diagnostic.
6. Change the display/backlight setting by one step, if the app exposes it, and save the final diagnostic.

Please write the exact old and new value beside each attachment. One setting per file is the important part; if an option is not present in your app, simply skip it. Restore your preferred settings afterwards.

The Home Assistant diagnostics are sanitized, but please do not attach raw TinyTuya output, device IDs or local keys.

I would leave calibration for a separate test. Target, pre-alarm, timer, sound and display are enough for this round.

[remb0]

Yes sure!!
config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (5).json
change brightness tot 85%

but the rest is not possible in the smartlife app as you can see

config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (6).json
i turnd volume off on the inkbird itself:
config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (7).json

[zampix1]

Thanks — the screenshot explains it. Smart Life is only giving you the generic Tuya DP page for this device, not Inkbird's cooking controls, so target temperatures and timers cannot be changed there.

I also need to correct my previous instructions: the three JSON files are normal integration diagnostics. They do not contain the raw LAN capture I meant. I should have explicitly said to press Capture LAN Diagnostics first, wait for it to finish, and only then download the integration diagnostics. That ambiguity was mine.

The good news is that the Inkbird app parser already confirms:

• DP104 is display brightness, and your 85% change is consistent with it;
• DP106 is the station sound level.

Could you do just these two captures?

1. Leave brightness at 85%, press Capture LAN Diagnostics, wait about 15 seconds, then download the diagnostics.
2. Change the station sound once using its physical control, press Capture LAN Diagnostics again, then download the second file. Please say whether that file is sound on or sound off.

No need to repeat the target, pre-alarm or timer tests in Smart Life; that app simply does not expose them. I will handle those through a dedicated HA test build later.

One small privacy note: the Smart Life screenshot shows part of dp_udid_mac_version. It is not your local key, so there is no emergency, but it may contain a device identifier/MAC. If you can, please edit the comment and replace that screenshot with a cropped or redacted version.

[remb0]

config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (9).json
config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (8).json

[zampix1]

I checked both files. They are valid beta.9 diagnostics, but neither contains any lan_debug_* fields, which means the capture button did not run before the download. Even a failed capture would leave a status and timestamp, so this is not a DP result yet.

The exact entity name is Capture Read-Only LAN Diagnostics. It is a button on the Inkbird device page under the diagnostic entities; it is different from Home Assistant's Download diagnostics command.

Could you try this exact sequence once more?

1. Set brightness to 85% and sound to off.
2. Press Capture Read-Only LAN Diagnostics and wait about 15 seconds.
3. Only after that, use Download diagnostics and attach the JSON as “85%, sound off”.
4. Turn sound on, press Capture Read-Only LAN Diagnostics again, wait, then download the second JSON as “85%, sound on”.

If you cannot see that button, or pressing it shows an error, stop there and send a screenshot of the Home Assistant device page. Do not keep repeating the downloads.

The files you already sent are still useful: they confirm beta.9 remains healthy. They just do not contain the raw DP snapshot needed to distinguish the sound values.

And no rush at all. August is a slightly chaotic holiday month for everyone, so please do this whenever you have the device and five quiet minutes. Next week or after the holidays is equally fine.

[remb0]

Vandaag · 3 augustus 2026
Capture Read-Only LAN Diagnostics
Ingedrukt
Local LAN Update OK
True
Capture Read-Only LAN Diagnostics
Ingedrukt
config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (11).json
config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (10).json

I hope this time I did it well

[zampix1]

Yes, this time you did it exactly right :)

File 11 is the completed capture, and it finally gave us a clean result: DP104 = 85, which matches the brightness you set on the station. So display brightness is now confirmed.

File 10 was simply downloaded a little too early, while the capture still said starting, but you do not need to repeat anything.

The missing sound value is useful too. DP106 was not returned in the completed LAN snapshot, so I am not going to guess or misuse DP102 for it: DP102 is the online/data-update flag, not sound volume.

I have published v0.2.6-beta.10. It adds read-only display brightness and makes the LAN capture status and timestamp visible, so it is easier to see when a capture has really finished. It also keeps the last valid temperature and battery CRC diagnostics when the station sends a partial reply.

No writes are enabled yet. The next brightness/sound test will be a small opt-in write beta, but that can wait until we are both around. No more captures needed for now - thank you!

[zampix1]

The brightness capture was useful, but I agree that the real goal is the probe alarms, not the display.

I have now published v0.2.6-beta.11. This one writes the actual food high target for each probe through the local Tuya connection.

The four test controls are disabled by default and are named Validate LAN Write: Probe N Food High Target. Please enable only the one for an idle probe, note its current target, then set something easy to recognize, for example 70 C. Check whether the new target appears on the station and in the Inkbird app.

After that, download the integration diagnostics once and tell me which probe and value you used. The diagnostic status should say either confirmed_by_readback, readback_mismatch, or awaiting_visual_confirmation.

This test is LAN-only and cannot fall back to BLE. I have also kept every other INT-14S write blocked for now, so we are testing one real setting without opening the whole control surface at once.

If this works, I can turn the experiment into proper controls for food high/low and ambient alarms instead of more diagnostic buttons.

[remb0]

H is flashing on device. I set a 90C temperature.
the app of smartlife is useless to see something :(

is see in the file:
"target_write_validation_active": false,
"target_write_validation_last_run_epoch_s": 1785820593,
"target_write_validation_probe": 1,
"target_write_validation_requested_c": 90.0,
"target_write_validation_requested_f_tenths": 1940,
"target_write_validation_dp": "122",

config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (12).json

hope this give the needed info?

[remb0]

done
config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (15).json

[zampix1]

This is much better. The beta.13 fix worked.

The diagnostics now contain three clean, separate attempts:

• Food High: 90 C — sent
• Food Low: 10 C — sent
• Ambient High: 40 C — sent

All three have command_sent: true, the values are no longer mixed, and the false -17.8 C placeholder is gone. So the serialization and inactive-threshold fixes are confirmed.

There is only one item missing from the history: Ambient Low. You do not need to repeat the first three. Please set only Probe 1 Ambient Low Target to 5 C, check what the station shows, then attach one last diagnostics file.

Because the station still does not return DP122 in the immediate LAN read-back, please also tell me briefly whether the station showed the expected H/L target indication for Food Low and Ambient High. The JSON confirms the commands were sent; the display confirms that the station applied them.

[remb0]

here you go
config_entry-inkbird_int14-01KYHZPK0FECZC5FNWRJWFQ3AT (16).json

[zampix1]

The JSON is clean now. Ambient Low 5 C was sent successfully, with no error and no return of the false -17.8 C value.

The history now shows:

• Food High: 90 C
• Food Low: 10 C
• Ambient High: 40 C
• Food High: 25 C
• Ambient Low: 5 C

All five attempts have command_sent: true, and none of their diagnostic fields overlap. I assume the extra Food High 25 C was intentional, probably to make the station's H indication easier to trigger; if so, that was a useful extra check.

From the Home Assistant side, beta.13 is behaving correctly. I only need one final sentence from you before I mark Food Low and both Ambient thresholds as hardware validated: did the station actually show or react to the expected low/ambient targets? DP122 is still absent from the immediate LAN read-back, so the JSON proves the commands were accepted but the station display is our confirmation that it applied those specific fields.

No more JSON files are needed.

[remb0]

This is great!

I see the H and hear the sound indeed!
The buttons to set the temp up and down are not that handy:P because they send every change instead of doing this when yo finally set the right temperature.

[remb0]

other question: did you tried the dashboard i started with?
because of the new sensors I will try to finalise, so if you have any remarks, ideas, bugs or whatever, i'm very happy if I can do something in retrun.

[zampix1]

Yes, that confirms the high alarm properly: the station accepted the target, showed the H and sounded the alarm.

And you are absolutely right about the + / - controls. The current Home Assistant number entities are validation controls, not the finished UI. Sending a LAN write on every single click is clumsy and unnecessarily noisy. Before I expose these as normal controls, I want an edit-then-apply flow, with explicit Apply / Cancel, like the pattern you already used in your dashboard.

About the dashboard: the honest answer is that I had not yet found the time to adapt it to my INT-14-BW and test it. Work has been completely full-on lately, and when I get home I have two small children, so long quiet BBQ sessions have not exactly been happening :)

I finally sat down and adapted it today. My INT-14-BW has core + ambient for each probe rather than the five INT-14S channels, so I removed the extra channel cards and mapped it to the eight temperature entities that really exist on my model. I installed it alongside my existing Inkbird dashboard instead of replacing it. Cook Control, Probes and Settings all load now, with no missing-entity errors.

The station was switched off when I took this screenshot, so the unknown/offline readings are expected. This is the adapted dashboard running on my own Home Assistant, not a mock-up:

I still have not tested the real cooking workflow. This weekend may finally be the right moment: my wife and the kids are going to the seaside, so I might actually manage a proper low-and-slow and test the targets, alerts, ETA, snooze and notifications rather than just clicking around an idle dashboard.

My first concrete suggestion is to make the channel layout model-aware in the dashboard strategy. Then the same project could render the INT-14-BW with 2 channels per probe and the INT-14S-BW with 5, without requiring a local adapted copy. After a real cook I will have much more useful feedback for you.

[FutureGUIs]

Hi @zampix1 can you post your yaml code here, I'd really like to use this in my dashboard too as I have a INT-14S-BW

[zampix1]

Quick update: your confirmation was enough to stop dragging this through more prereleases. v0.2.6 is now the stable release:

https://github.com/zampix1/ha-inkbird-int14/releases/tag/v0.2.6

I kept the boundary clear: INT-14S BLE and local LAN readings are in the stable release, and the Probe 1 food-high write is hardware validated from the station's H indication and audible alarm. The other threshold controls remain hidden advanced diagnostics for now; they are not being presented as finished settings controls.

I also agree with your point about the + / - buttons. I am not going to turn the write-on-every-click behavior into the final UI. An explicit Apply / Cancel step is the right way to handle those settings.

So no more beta is needed for normal INT-14S use. We can use a future prerelease only when there is actually a new DP or control worth testing.

[remb0]

thank you so much. I will push a smal update on the dasboard today. :)