INT-12E-BW

[Nexus1212]

Question

Hello,

I own an Inkbird INT-12E-BW and would be happy to help add or validate support for this model.

My setup:

• Exact model: INT-12E-BW
• Integration profile: int12e_bw
• Home Assistant version: 2026.7.1
• Integration version: 0.2.2
• Transport: BLE through an ESPHome Bluetooth Proxy
• Physical probes: 2
• Temperature channels shown in the Inkbird app: 5 per probe, 10 total

When I trigger a snapshot, the ESPHome Bluetooth Proxy successfully connects to the station. The BLE connection opens and service discovery completes, but no live temperature channels are currently available, which seems consistent with the cataloged int12e_bw profile.

I can provide:

• redacted Home Assistant diagnostics
• redacted integration and ESPHome Bluetooth Proxy logs
• redacted screenshots from the Inkbird app
• controlled temperature tests for the tip, middle/body and ambient section of each probe
• additional BLE captures or tests according to your instructions
• testing of a development branch or prerelease version

Please let me know which logging settings, capture method or measurement procedure would be most useful.

Thank you!

Chris

Integration version

0.2.2

Home Assistant version

2026.7.1 / 18.1

Model/profile, if relevant

INT-12E-BW

Transport path, if relevant

Auto

Context

No response

Privacy check

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

[zampix1]

Hi Chris, sorry I missed this earlier — and thanks, this is exactly the kind of INT-12E-BW report I was hoping for.

What you are seeing is expected with 0.2.2: the int12e_bw profile is currently cataloged only. It knows the expected hardware shape — 2 physical probes, 5 temperature channels per probe — but it does not create live temperature entities yet because I don’t want to fake support before validating the real payloads.

For the first pass, the most useful data would be read-only only:

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

   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 ESPHome Bluetooth Proxy.
Trigger one snapshot from Home Assistant.
Save:Home Assistant diagnostics for the integration entry
Home Assistant log around the snapshot attempt
ESPHome Bluetooth Proxy log for the same time window
a redacted screenshot of the Inkbird app showing the 10 temperature channels

Please keep MAC addresses, IPs, device IDs, local keys, Wi-Fi names and account data redacted.
For the temperature mapping, this would be very helpful:
baseline screenshot with both probes at room temperature
warm only probe 1 tip, then take an app screenshot/log note
warm a middle/body section of probe 1, then note which app channel changes
warm the ambient/handle area of probe 1, then note which app channel changes
repeat the same for probe 2
No writes for now. I only want discovery, service/characteristic data, battery/state if present, and the mapping between the app’s 10 displayed values and the BLE payload.
Once I have that, I can prepare a read-only development branch or prerelease that dumps/decodes the INT-12E-BW channels without exposing any write controls.

[zampix1]

Hi Chris, the promised read-only test build is now available:

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

It keeps int12e_bw cataloged: no live temperature entities, no fake channel values and no write controls. The new Capture BLE Diagnostics button performs scanner discovery, GATT inventory, readable-characteristic reads and a short unsolicited-notification capture without sending Inkbird application commands.

Please enable beta/prerelease versions in HACS, install v0.2.3-beta.1, restart Home Assistant, keep the Inkbird app closed, wake the station near the ESPHome Bluetooth Proxy, press Capture BLE Diagnostics, wait at least 15 seconds and attach the sanitized integration diagnostics.

Your controlled app-side mapping is still useful too. A baseline plus probe 1 tip/body/ambient changes is enough for the first pass; probe 2 can follow once we know whether both probes share the same payload layout.

This build is diagnostic only. I will enable live entities only after the real 10-channel payload and channel order are confirmed.

[Nexus1212]

Hi,

I installed v0.2.3-beta.1 and successfully ran the BLE diagnostics capture for my INT-12E-BW.

The diagnostic capture completed successfully. The device was found using its configured BLE address, the connection and service discovery worked, and 16 readable characteristic values were captured. No application commands were sent to the Inkbird device.

No BLE notifications were captured during this run. Several notification subscriptions returned BleakError, but the direct characteristic reads completed without errors.

I have attached the sanitized Home Assistant diagnostics file. I removed the BLE MAC address, the Home Assistant entry ID, and unrelated custom integration information. The raw BLE characteristic values have been left unchanged because they may be needed for decoding.

Thank you for working on support for this model.

config_entry-inkbird_int14-01KXK4XQMB7TFRQRRHX6EMXHJV.json

[zampix1]

Hi Chris, thank you — this capture is extremely useful, and the direct characteristic reads are enough to move forward even though notifications failed through the proxy.

One privacy note first: despite the manual cleanup, the attachment still contains the BLE address in two places: data.address and data.entry.unique_id. I found no Tuya local key, token, password or private IP in the file, but please remove or edit the attachment when convenient. You do not need to upload it again for my analysis; I already have the protocol data I need. Future diagnostics generated by stable v0.2.5 or later redact both paths automatically.

The good technical news is that FF01 is a 28-byte frame: two 13-byte probe blocks followed by a two-byte station temperature. That is the exact structural pattern used by INT-14S-BW, scaled down from four probes to two. Each probe block contains an aggregate value, Food 1-4, Ambient and one status byte. The observed values and scales are internally consistent, and 2A19 also has the expected three battery bytes: station plus two probes.

So the next build can be read-only and narrow:

• parse the two FF01 probe blocks;
• expose Food 1-4 and Ambient for both probes;
• expose station/probe battery values;
• use direct GATT reads as the reliable snapshot path when ESPHome notification subscriptions are unavailable;
• keep every write control disabled.

I’ll prepare that prerelease next. After installation, the useful validation will simply be checking that all ten temperatures populate and warming tip/body/ambient sections to confirm the channel labels.

[zampix1]

Hi Chris,

Thanks again — your capture was enough to build the first live, read-only INT-12E-BW implementation.

v0.2.6-beta.2 - Experimental INT-12E BLE reads is now available.

This build uses direct GATT reads, so the notification errors you saw through the ESPHome Bluetooth Proxy should not block it. For int12e_bw it now exposes:

• Food 1-4 and Ambient for probe 1;
• Food 1-4 and Ambient for probe 2;
• station temperature;
• station and probe battery percentages.

It does not enable any writes, Tuya LAN, cloud access or unvalidated state entities for this model.

When you have a moment, please update to beta.2, restart Home Assistant, keep the Inkbird app closed, wake the station near the proxy and press Request Snapshot. The first thing to check is simply whether all ten temperature entities populate with plausible values.

If they do, the most useful follow-up is a small mapping test on probe 1: note the baseline, warm the tip, then a middle/body section, then the ambient end, and tell me which Home Assistant channel changes each time. A short table is perfect; screenshots are optional. There is no need to post another full diagnostic file unless something fails.

One privacy reminder: beta.2 contains the stable diagnostics redaction fixes, but it is still worth reviewing any file before attaching it publicly.

Thank you for making this possible.

[Nexus1212]

Hi,

I installed v0.2.6-beta.2 and tested the live INT-12E-BW entities.

All ten probe temperature entities are populated, and the displayed values
look plausible for both probes.

One mapping result is now confirmed:

• Probe 1: Food 4 is the sensor at the tip of the probe.
• Probe 2: Food 4 is also the sensor at the tip of the probe.

I have attached a screenshot showing how the entities currently appear in
Home Assistant.

The readings work, but the updates appear noticeably delayed. In the ESPHome
Bluetooth Proxy log I can see the expected short BLE connections and clean
disconnects, but I also observed occasional failed connection attempts with:

Connection open error, status=133

A retry usually succeeds afterwards. I have attached a short, sanitized log
excerpt showing one of these failed attempts and the following successful
connection.

Could you please confirm whether the repeated connect/read/disconnect cycle
and the current update interval are expected for the direct GATT read
implementation?

Would it also be possible to make the BLE polling interval configurable,
or set it to approximately 10 seconds for the INT-12E-BW?

For cooking, an update interval of roughly 45–60 seconds feels quite slow,
especially when the probe temperature is changing quickly.

Since repeated BLE reconnects may increase the chance of status=133 errors,
perhaps the connection could remain open and FF01 could be read directly
every 10 seconds, rather than reconnecting for every update.

I understand that the station itself may not provide a genuinely new
measurement every 10 seconds, but a configurable polling interval would
still be very useful.

Please let me know whether you would like me to perform additional mapping
tests for Food 1-3, or collect a longer timestamped test showing the Home
Assistant update intervals.

Here is a sanitized ESPHome Bluetooth Proxy log excerpt showing one failed
connection attempt with status=133, followed by a successful retry:

`[20:13:31.405][I][bluetooth_proxy:059]: [0] [AA:BB:CC:DD:EE:FF] Connecting v3 with cache
[20:13:31.463][D][esp32_ble_tracker:169]: connecting: 0, discovered: 1, disconnecting: 0, active: 0
[20:13:31.463][D][esp32_ble_tracker:909]: Stopping scan to make connection
[20:13:31.464][D][esp32_ble_tracker:917]: Promoting client to connect
[20:13:31.469][I][esp32_ble_client:126]: [0] [AA:BB:CC:DD:EE:FF] 0x00 Connecting
[20:13:31.469][D][esp32_ble_client:232]: [0] [AA:BB:CC:DD:EE:FF] medium conn params
[20:13:31.469][D][esp32_ble_tracker:169]: connecting: 1, discovered: 0, disconnecting: 0, active: 0

[20:13:51.438][D][esp32_ble_client:157]: [0] [AA:BB:CC:DD:EE:FF] Disconnect before connected, disconnect scheduled
[20:13:51.444][D][esp32_ble_client:380]: [0] [AA:BB:CC:DD:EE:FF] ESP_GATTC_DISCONNECT_EVT, reason 0x100
[20:13:51.447][D][bluetooth_proxy.connection:383]: [0] [AA:BB:CC:DD:EE:FF] Disconnect, reason=0x100
[20:13:51.456][D][esp32_ble_client:212]: [0] [AA:BB:CC:DD:EE:FF] ESP_GATTC_OPEN_EVT
[20:13:51.456][E][esp32_ble_client:325]: [0] [AA:BB:CC:DD:EE:FF] ESP_GATTC_OPEN_EVT in DISCONNECTING state (status=133)
[20:13:51.464][W][esp32_ble_client:224]: [0] [AA:BB:CC:DD:EE:FF] Connection open error, status=133

[20:13:51.751][I][bluetooth_proxy:059]: [0] [AA:BB:CC:DD:EE:FF] Connecting v3 with cache
[20:13:51.779][I][esp32_ble_client:126]: [0] [AA:BB:CC:DD:EE:FF] 0x00 Connecting
[20:14:10.368][D][esp32_ble_client:212]: [0] [AA:BB:CC:DD:EE:FF] ESP_GATTC_CONNECT_EVT
[20:14:10.368][D][esp32_ble_client:212]: [0] [AA:BB:CC:DD:EE:FF] ESP_GATTC_OPEN_EVT
[20:14:10.368][I][esp32_ble_client:344]: [0] [AA:BB:CC:DD:EE:FF] Connection open
[20:14:10.369][D][esp32_ble_tracker:169]: connecting: 0, discovered: 0, disconnecting: 0, active: 1
[20:14:10.369][D][esp32_ble_client:411]: [0] [AA:BB:CC:DD:EE:FF] cfg_mtu status 0, mtu 517`

Privacy note: The BLE address AA:BB:CC:DD:EE:FF shown in the log excerpt is
not my device's real address. I had already replaced the original address
with this fictional placeholder before posting the log.

Thank you again for implementing support for this model.

[zampix1]

Hi Chris,

This is excellent news — confirming all ten live temperatures on real hardware is the important milestone, and knowing that Food 4 is the tip sensor on both probes already gives us the first reliable physical mapping.

You were also right about the slow updates. The previous beta reused the existing BLE session loop, which intentionally connected, read, stayed open briefly, disconnected and waited before trying again. With an ESPHome proxy that could easily become a 45-60 second cycle, and each new connection was another opportunity to hit a transient status=133 error.

I have prepared a new build specifically for this:

v0.2.6-beta.3 - Persistent INT-12E BLE polling

For INT-12E-BW it now:

• keeps the GATT connection open;
• reads only FF01 and 2A19 every 10 seconds by default;
• lets you change the interval from 5 to 300 seconds in the integration options;
• reuses the active connection when Request Snapshot is pressed;
• reconnects only after the station or proxy actually drops the link.

The isolated status=133 is not a parser problem. It is a connection-open failure from the ESPHome/ESP32 BLE side. It is only concerning if retries stop recovering; in your log the next attempt connected successfully. Keeping one connection open should substantially reduce how often that path is exercised.

Could you update to beta.3, restart Home Assistant and leave the default 10-second interval for the first test? No manual snapshots should be necessary. The useful result is simply:

1. whether temperatures change roughly every 10 seconds for 5-10 minutes;
2. whether the proxy keeps one connection open instead of reconnecting every cycle;
3. whether it recovers automatically if the connection drops once.

After that, mapping Food 1-3 would absolutely be useful, but there is no need to do everything at once. A timestamped update test is the priority for this beta.

Thank you — this was a very precise report and it directly exposed the weak part of the first implementation.

[Nexus1212]

Hi,

I tested v0.2.6-beta.3 with the default 10-second interval.

The temperature updates feel much better, and the integration automatically
recovers whenever the BLE connection drops.

However, the ESPHome Bluetooth Proxy log shows that the connection does not
remain open indefinitely. It is terminated very consistently after
approximately 30 seconds with:

ESP_GATTC_DISCONNECT_EVT, reason 0x13
Disconnect, reason=0x13

After each disconnect, the integration automatically reconnects and continues
providing values. I did not observe another status=133 error in this test.

Observed connection durations:

• 21:21:19 to 21:21:48 — approximately 29 seconds
• 21:22:15 to 21:22:45 — approximately 30 seconds
• 21:23:00 to 21:23:31 — approximately 30 seconds
• 21:23:46 to 21:24:16 — approximately 30 seconds
• 21:24:29 to 21:25:00 — approximately 30 seconds

This looks like the remote device may have a fixed connection timeout of
approximately 30 seconds. Could the INT-12E-BW station itself be terminating
persistent GATT connections?

So, for the requested beta.3 checks:

1. Temperatures update much more frequently: Yes
2. One connection remains open continuously: No, it drops after about 30 seconds
3. Automatic recovery after a drop: Yes

I can provide a sanitized log excerpt if useful.

[zampix1]

Hi Chris,

Yes — those timestamps are consistent enough that the station itself is almost certainly enforcing an approximately 30-second BLE session limit. BLE reason 0x13 means the remote side terminated the connection, and the fact that it happens while FF01/2A19 are being read every 10 seconds rules out simple client inactivity.

The important parts are working: updates are faster, the integration detects the drop, and it recovers automatically. There is no need for the sanitized log excerpt; your timestamp table already gives us the useful evidence.

I have made one small recovery adjustment:

v0.2.6-beta.4 - INT-12E reconnect tuning

It keeps the 10-second read interval but waits only 5 seconds after the station's normal remote disconnect before reconnecting. Actual connection failures still use at least a 10-second backoff, so the integration should not hammer the ESPHome proxy if it encounters another status=133.

I am deliberately not trying to defeat the 30-second limit with an unknown keepalive or application write. The read-only reconnect path is safer and is already proving reliable.

For this beta, a short confirmation is enough: please check whether the gaps between the 0x13 disconnect and the next successful connection are now shorter, and whether temperatures continue updating normally for about 10 minutes. If that passes, I would consider the transport behavior good enough for the first stable INT-12E read-only release.

The Food 1-3 physical mapping can follow separately; it no longer blocks the transport work.

[Nexus1212]

I checked the configuration/options dialog of the Inkbird INT integration
entry, not only the Reconfigure dialog. However, I do not see any option for
changing the polling interval from the default 10 seconds.

I also re-downloaded beta.3 through HACS and restarted Home Assistant again,
but the option is still not visible.

Could you please confirm where exactly the setting should appear?

[zampix1]

Hi Chris,

You are right — this was my mistake. The runtime setting existed in beta.3, but I had only added it to the Options schema and assumed Home Assistant would expose that path consistently. Your installation proves that assumption was wrong, so there was no hidden location you had missed.

I have fixed it in:

v0.2.6-beta.5 - Visible BLE polling option

The field is now explicitly included in all three flows:

• initial setup;
• Reconfigure;
• integration Options/Configure.

Its label is BLE direct-read interval (GATT polling profiles), with an allowed range of 5-300 seconds and a default of 10.

Please install beta.5 rather than beta.4, restart Home Assistant, and open Reconfigure first. The field should appear directly below Request BLE snapshot on connect. It should also be present in Options. Saving either form reloads the entry and applies the selected interval.

Beta.5 includes the beta.4 reconnect improvement as well, so you can use this one for both checks. If the field is still missing, please tell me which fields you do see in Reconfigure and I will stop guessing and reproduce that exact form path.

Sorry for sending you looking for an option that was not actually visible on your system, and thank you for catching it quickly.

[Nexus1212]

Hi,

I found the polling interval option in v0.2.6-beta.5 and left it at the
default value of 10 seconds.

The temperature values are working well. However, while the BLE connection
is active, the Home Assistant temperature entities appear to update roughly
every 3 seconds rather than every 10 seconds. This behavior is fine for me,
but I wanted to mention it because it does not appear to match the configured
interval.

The station still terminates every BLE connection after approximately
30 seconds with reason 0x13.

The reconnect behavior is now much better and generally reliable.

Observed connection sessions:

• 23:16:13.388 to 23:16:43.796 — approximately 30.4 seconds
• 23:16:52.106 to 23:17:22.218 — approximately 30.1 seconds
• 23:17:33.163 to 23:18:03.357 — approximately 30.2 seconds
• 23:18:25.479 to 23:18:55.579 — approximately 30.1 seconds

Observed offline gaps until the next successful connection:

• approximately 8.8 seconds
• approximately 8.3 seconds
• approximately 10.9 seconds
• one slower reconnect of approximately 22.1 seconds

I did not observe any status=133 errors in this test. The integration always
recovered automatically, and the temperature values continued updating
after each reconnect.

Could you please confirm whether temperature entity updates roughly every
3 seconds are expected when the direct-read interval is configured to
10 seconds?

Overall, beta.5 feels responsive and reliable.

Thank you very much :)

[Nexus1212]

By the way, I wanted to support your work and buy you a coffee, but the
Buy Me a Coffee link in the repository currently returns a 404 page.

Is there another current donation link or another way I can support the
project financially? :)

[zampix1]

Hi Chris,

Yes, the roughly 3-second entity updates are expected with what your latest test has revealed.

The station is now successfully delivering FF01 notifications while the BLE session is active. Home Assistant applies those push updates immediately, so they can arrive more frequently than the configured 10-second interval. The setting controls our explicit direct GATT reads of FF01/2A19; it is a fallback/readback interval, not a throttle for valid notifications.

That is actually the best outcome:

• notifications provide responsive updates at roughly 3 seconds while available;
• the 10-second direct read protects us if notifications are missed or unsupported by a proxy;
• the station still enforces its approximately 30-second session limit;
• the integration reconnects and resumes both paths automatically.

Your 8-11 second normal offline gaps are consistent with the 5-second backoff plus BLE connection setup. The single 22-second gap is slower than ideal, but because it recovered without status=133 and without intervention, I would not treat it as a blocker. We should continue to watch it in normal use.

I will rename the UI wording to BLE fallback direct-read interval in the next release so it no longer suggests that all entity updates are limited to that cadence.

With this result, I consider the INT-12E-BW BLE temperature/battery transport community-validated and suitable for the first stable read-only release. Food 1-3 physical placement remains documentation work, not a transport blocker.

And thanks for trying to buy me a coffee 😄 You somehow managed to find one more bug: the coffee link is broken too. I’ll fix that tomorrow — after tonight, I may need the whole pot rather than one cup.

Seriously though, your testing has already helped this project a lot. Thank you!

[Nexus1212]

Hi,

I also wanted to share a screenshot of the dashboard I built around the
INT-12E-BW entities:

It now looks really good in Home Assistant. I have separate sections for the
black and white probes, including:

• all five temperature sensors per probe;
• probe battery levels;
• station temperature and battery level;
• BLE connection status;
• one-hour history graphs for all probe temperature channels.

I also added a simple visual representation of both probes, so the sensor
positions are easier to understand at a glance.

The integration is already very useful in practice, and the dashboard makes
the multi-sensor layout much easier to read than in a standard entity list.

Thank you again for adding support for the INT-12E-BW.

Images :

Code Yaml:

type: grid
cards:
  - type: heading
    heading: Schwarze Sonde
    heading_style: title
  - type: picture-elements
    image: media-source://media_source/local/inkbird_probe_2.png
    grid_options:
      columns: full
    elements:
      - type: state-label
        entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_4_temperature
        tap_action:
          action: more-info
        style:
          left: 11.7%
          top: 29.5%
          color: "#2478c8"
          font-size: 14px
          font-weight: "700"
          line-height: "1"
          white-space: nowrap
      - type: state-label
        entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_1_temperature
        tap_action:
          action: more-info
        style:
          left: 27.1%
          top: 74.0%
          color: "#7669bf"
          font-size: 14px
          font-weight: "700"
          line-height: "1"
          white-space: nowrap
      - type: state-label
        entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_3_temperature
        tap_action:
          action: more-info
        style:
          left: 37.7%
          top: 29.5%
          color: "#bd9411"
          font-size: 14px
          font-weight: "700"
          line-height: "1"
          white-space: nowrap
      - type: state-label
        entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_2_temperature
        tap_action:
          action: more-info
        style:
          left: 46.6%
          top: 74.0%
          color: "#49aeba"
          font-size: 14px
          font-weight: "700"
          line-height: "1"
          white-space: nowrap
      - type: state-label
        entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_ambient_temperature
        tap_action:
          action: more-info
        style:
          left: 87.4%
          top: 29.5%
          color: "#9344a1"
          font-size: 14px
          font-weight: "700"
          line-height: "1"
          white-space: nowrap
  - type: tile
    grid_options:
      columns: full
    entity: >-
      sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_4_temperature
    vertical: false
    features_position: bottom
  - type: tile
    grid_options:
      columns: full
    entity: >-
      sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_1_temperature
    vertical: false
    features_position: bottom
  - type: tile
    grid_options:
      columns: full
    entity: >-
      sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_3_temperature
    vertical: false
    features_position: bottom
  - type: tile
    grid_options:
      columns: full
    entity: >-
      sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_2_temperature
    vertical: false
    features_position: bottom
  - type: tile
    grid_options:
      columns: full
    entity: >-
      sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_ambient_temperature
    vertical: false
    features_position: bottom
  - type: tile
    grid_options:
      columns: full
    entity: sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_battery
    vertical: false
    features_position: bottom
  - type: heading
    icon: mdi:chart-timeline-variant
    heading_style: title
    heading: Letzte Stunde
  - type: history-graph
    entities:
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_4_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_1_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_3_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_2_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_ambient_temperature
    hours_to_show: 1
  - type: heading
    icon: mdi:chart-timeline-variant
    heading_style: title
    heading: Letzten 10 Stunden
  - type: history-graph
    entities:
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_4_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_1_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_3_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_2_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_ambient_temperature
    hours_to_show: 10
  - type: heading
    icon: mdi:chart-timeline-variant
    heading_style: title
    heading: Letzten 24 Stunden
  - type: history-graph
    entities:
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_4_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_1_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_3_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_food_2_temperature
      - entity: >-
          sensor.controlroom_inkbird_int_12e_bw_grillthermometer_probe_1_ambient_temperature
    hours_to_show: 24

[zampix1]

Chris, this was too useful to leave buried in the thread, so I added a cleaned-up version to the project:

• dashboard guide
• wiki page
• sanitized YAML example

I kept the screenshot and probe artwork, credited you, and replaced the installation-specific entity IDs with placeholders. I also noted that Food 4 at the tip is confirmed, while the Food 1-3 positions still follow the community layout until we have a controlled physical mapping.

The probe graphic is a much better way to read five temperatures than a plain entity list. Thanks for sharing it. If you would prefer different attribution, or would rather not have the artwork bundled in the repository, just tell me and I will change it.