Weber Connect Smart Grilling Hub integration

here’s a sample template I feed into the main yaml…

############################################
# MODULE: iGrill 3 BLE Integration Template
# TYPE: Sensor + BLE Client
# CREATED: 2025-10-06
# AUTHOR: Soup (Steve Campbell)
#
# INPUTS:
#   - MAC address (BLE)
#   - Battery level (AA or docked)
#   - Propane level (if docked)
#   - Temperature probes 1–4
#
# OUTPUTS:
#   - Connection status (binary + text)
#   - Battery sensor (template)
#   - Propane status (emoji + %)
#   - Probe temps (raw + emoji summary)
#
# RUNTIME IMPACT:
#   - BLE scan + 60s polling
#   - 4 probe sensors + propane + battery
############################################

ble_client:
  - mac_address: ${mac_address}
    id: ${igrill_id}
    on_connect:
      then:
        - binary_sensor.template.publish:
            id: ${igrill_id}_connection
            state: ON
    on_disconnect:
      then:
        - binary_sensor.template.publish:
            id: ${igrill_id}_connection
            state: OFF

binary_sensor:
  - platform: template
    name: "${igrill_name} Connection"
    id: ${igrill_id}_connection
    device_class: connectivity

sensor:
  - platform: igrill
    ble_client_id: ${igrill_id}
    update_interval: 60s
    send_value_when_unplugged: true
    unplugged_probe_value: 0
    battery_level:
      name: "${igrill_name} Battery"
      id: ${igrill_id}_battery
    propane_level:
      name: "${igrill_name} Propane"
      id: ${igrill_id}_propane
    temperature_probe1:
      name: "${igrill_name} Probe 1"
      id: ${igrill_id}_probe1
    temperature_probe2:
      name: "${igrill_name} Probe 2"
      id: ${igrill_id}_probe2
    temperature_probe3:
      name: "${igrill_name} Probe 3"
      id: ${igrill_id}_probe3
    temperature_probe4:
      name: "${igrill_name} Probe 4"
      id: ${igrill_id}_probe4

text_sensor:
  - platform: template
    name: "${igrill_name} MAC Address"
    id: ${igrill_id}_mac
    lambda: |-
      return std::string("${mac_address}");


  - platform: template
    name: "${igrill_name} Probe Summary"
    id: ${igrill_id}_summary
    lambda: |-
      if (!id(${igrill_id}_connection).state) {
        return {"🔌 OFFLINE"};
      }
      auto format_probe = [](float temp) -> std::string {
        if (temp <= 0.0) return "🧊";
        if (temp < 100.0) return "🌡️ " + to_string((int)temp) + "°F";
        return "🔥 " + to_string((int)temp) + "°F";
      };
      std::string p1 = format_probe(id(${igrill_id}_probe1).state);
      std::string p2 = format_probe(id(${igrill_id}_probe2).state);
      std::string p3 = format_probe(id(${igrill_id}_probe3).state);
      std::string p4 = format_probe(id(${igrill_id}_probe4).state);
      return "P1: " + p1 + " | P2: " + p2 + " | P3: " + p3 + " | P4: " + p4;



  

and the “main” (at least as I see it)

############################################
# MODULE: BLE iGrill Monitor (Mini + iGrill 3 x2)
# TYPE: ESPHome Config + Substitutions
# CREATED: 2025-10-06
# AUTHOR: Soup (Steve Campbell)
#
# INCLUDES:
#   - soup_device_base.yaml (shared device config)
#   - template_igrill_mini.yaml (Mini logic)
#   - template_igrill_3.yaml (iGrill 3 logic)
#
# UNITS:
#   - iGrill Mini DE9B (mac_address_1)
#   - iGrill 3 9999 (mac_address_2)
#   - iGrill 3 5843 (mac_address_3)
#
# ENTITY ID FORMAT:
#   - All IDs use last 4 of MAC for uniqueness
#   - Example: igrill_mini_de9b_connection_bin
#
# RUNTIME IMPACT:
#   - BLE scan + 60s polling per unit
#   - Avoid MAC collisions or scan overlap
#
# FUTURE:
#   - Add alert logic for propane + probe temps
#   - Expand overlay tile with grill mode + vibe
#  mac_address_1: "70:91:8F:98:DE:9B"
#  mac_address_2: "70:91:8F:98:1C:9B"
#  mac_address_3: "70:91:8F:1E:58:43"  #New Igrill3
############################################

substitutions:
  name: esphome-web-7a0558
  friendly_name: BLE iGrill 7A0558 Modular

  igrill_mini_mac: "70:91:8F:98:DE:9B"
  igrill_mini_name: "iGrill Mini DE9B"
  igrill_mini_id: "igrill_mini_de9b"

  # iGrill 3 1C9B (old)
  igrill_3_1C9B_mac: "70:91:8F:06:1C:9B"
  igrill_3_1C9B_name: "iGrill 3 1C9B"
  igrill_3_1C9B_id: "igrill_3_1c9b"

  # iGrill 3 5843 (new)
  igrill_3_5843_mac: "70:91:8F:1E:58:43"
  igrill_3_5843_name: "iGrill 3 5843"
  igrill_3_5843_id: "igrill_3_5843"

esphome:
  name: ${name}
  friendly_name: ${friendly_name}
  name_add_mac_suffix: false
  project:
    name: esphome.web
    version: '1.0'

esp32:
  board: esp32dev
  framework:
    type: esp-idf

web_server:

esp32_ble_tracker:
  scan_parameters:
    window: 160ms
    interval: 160ms

external_components:
  - source: github://bendikwa/[email protected]

packages:
  device_base: !include 
    file: soup_device_base.yaml

  igrill_mini: !include 
    file: igrill_mini_template.yaml
    vars:
      mac_address: ${igrill_mini_mac}
      igrill_name: ${igrill_mini_name}
      igrill_id: ${igrill_mini_id}

  igrill_3_1D9B: !include
    file: igrill_3_template.yaml
    vars:
      mac_address: ${igrill_3_1C9B_mac}
      igrill_name: ${igrill_3_1C9B_name}
      igrill_id: ${igrill_3_1C9B_id}

  igrill_3_5843: !include
    file: igrill_3_template.yaml
    vars:
      mac_address: ${igrill_3_5843_mac}
      igrill_name: ${igrill_3_5843_name}
      igrill_id: ${igrill_3_5843_id}


I just bought the weber connect hub. I haven’t connected it to WiFi, just BLE. And with firmware 2.0.3_7398 (latest as of now) it detects the probe and shows the readings. So it seems to me that WiFi connectivity is optional, and it should work over just Bluetooth. Now I appreciate that it might have different communication protocol than iGrill, but I wonder if anyone tried to use Bluetooth only?

I built an add-on that talks to the Weber Connect hub locally over Bluetooth — no cloud, no account:

Add the repository, install Weber Connect BLE Bridge, open the panel, tap Find My Hub, and press the button on the hub when it beeps. Probe temperature and state come through MQTT discovery. There is also a handoff mode that releases the hub so the Weber app can connect, then reconnects.

@Lash-L — you mentioned needing the Bluetooth init: the pairing exchange (session claim, version negotiation, frame format, key exchange) is implemented in saber_frames.py / weber_ble_pair.py if it is useful for a native integration.

Tested on HA Yellow (aarch64); amd64 images also published. Issues/PRs welcome.

I developed this for the Weber Connect Hub (Wifi). Give it a shot and let me know how it works for you. GitHub - GabrielGoldsteinAnidea/weber_connect_ha: Weber Connect Wifi for Home Assistant · GitHub

Is this an add on or HACS?

Wow, very impressive integration! Easy install, easy set up, good documentation. Just perfect.
The only thing i found, there's a slight disconnection every now and then.

I made this small dashboard:

I'm not very much into UX. Suggestions are welcome!

I tried both the HA add-on and the HACs integration. The HA add-on works fine but has the disadvantage that you can’t use it together with the Weber app.

So I also wanted to try the hacs integration from @gabriel.goldstein but wasn’t able to retrieve the secret. In the documentation, the tools link mentioned is no longer working, and the docs weren’t that clear on what steps I needed to do to get the necessary details. I tried with PCAPdroid + mitm on Android on my S26, but the traffic kept encrypted, and I wasn’t able to have it trust the installed CA certificate.
Where can I find clear documentation on how to get the secret/device password?

Weber Connect for Home Assistant 2.0 (Unofficial)

@Gabriel.goldstein @kahilzinger @Sander_van_den_Broek @christianv8 — v2.0 is now available.

Home Assistant and the official Weber app can now work together. The add-on creates its own companion identity, so users do not need a Weber account password, phone secret, packet capture, MITM proxy, or custom CA. Select Set Up My Hub and confirm once on the hub. The Weber app can then own Bluetooth and start a recipe while Home Assistant continues receiving read-only probe updates through Weber Cloud. Local only remains available.

Also new: a one-screen UI, optional probe nicknames that retain the probe number, and 10-second local readings by default.

Verified on a Weber Connect Hub with Home Assistant Yellow and the official Android app, including a recipe started in the app while Home Assistant received the same cook’s probe telemetry. Other models, firmware, hosts, and regions still need community testing—issues and PRs are welcome.

@christianv8, this removes the secret/device-password step you were blocked on. @Sander_van_den_Broek, I would appreciate a retest of the intermittent disconnect you saw.

The addon works great also without the direct bluetooth connection now.

Only issue I have is, I don’t see the entities published to mqtt. Nothing pops up and also the logs don’t show any error. I’m using Mosquitto broker addon and the regular MQTT integration in home assistant. The mosquitto broker log shows:
2026-07-18 13:42:19: New client connected from 172.30.33.6:49501 as weber_connect_hub_bridge (p4, c1, k30, u’addons’).

Anything I missed?

Some other things I noticed:

  • After a restart I connect another probe it doesn get the new information(I was on cloud) of the new probe. However it says it updated while and when you check connection to cloud it says to work fine.
  • Once I switched back to bluetooth it’s not working it stays on cloud.
  • When I try to forget the bridge in settings it looks like nothing happens and you can keep pressing the button but after a couple of seconds it logs out.
  • I don’t think it works with bluetooth proxies right? I have 2 and it seems bluetooth only works when near my home assistant machine.

Thanks for the detailed feedback. Most of these line up with fixes/clarifications that just shipped in 2.1.0.

The MQTT issue especially sounds like the discovery bug fixed: the add-on could connect to Mosquitto successfully, but Home Assistant could still ignore the discovery payload on hubs that do not report a firmware version. In 2.1.0 the discovery payload no longer includes that unknown optional field, and the add-on now logs a positive “MQTT publishing ready” line with the state topic, discovery prefix, and discovery topic count.

For the other notes:

  • Cloud can be healthy while Weber has not yet published a fresh probe snapshot. “Check connection” verifies the bridge can access the hub; it does not force Weber Cloud to publish a new probe row.
  • “Reconnect Home Assistant” tries direct Bluetooth again. If the hub is out of range, asleep, busy with the app, or not near the Home Assistant host Bluetooth adapter, the bridge will keep using cloud when cloud is available.
  • “Forget hub” now shows immediate progress while it closes Bluetooth, cloud, and MQTT sessions.
  • Bluetooth proxies are not supported by this add-on right now. It talks directly to the Home Assistant host’s BlueZ Bluetooth service, so pairing/local BLE needs the hub near the HA machine or its attached adapter.

Please update to 2.1.0 and retest. If MQTT entities still don’t appear, please share the add-on log line that starts with “MQTT publishing ready” and confirm whether your Home Assistant MQTT integration has discovery enabled with the default homeassistant discovery prefix.

And please keep the feedback coming.

Update: I’m planning to release version 3.0 within the next 24–48 hours. This release moves Weber Connect Unofficial from an add-on to a native Home Assistant integration, with native entities and ESPHome Bluetooth proxy support.

I’m running final validation and stress testing now. More details and installation instructions will follow with the release.

Weber Connect Unofficial 3.0 is now available

Version 3.0 replaces the previous add-on with a native Home Assistant integration.

What’s new:

  • Native Home Assistant devices and entities—no MQTT broker required
  • Support for local Bluetooth adapters and ESPHome Bluetooth proxies
  • Four stable probe temperature entities
  • Phone + Home Assistant mode lets the Weber app use Bluetooth while Home Assistant receives temperatures through Weber Cloud
  • Optional Home Assistant-only Bluetooth mode
  • Automatic private companion pairing—no Weber email, password, packet capture, or manually extracted secrets
  • Probe nicknames that retain the physical probe number
  • Completely redesigned setup and configuration experience

I physically tested pairing through an ESPHome proxy, simultaneous Weber app and Home Assistant monitoring, cloud updates, proxy-only operation, restarts, and recovery after a proxy reboot. The final test suite contains 112 tests with over 95% coverage.

A second proxy wasn’t available, so multi-proxy failover is the main scenario that remains unverified.

Installation

  1. Open HACS → Integrations → Custom repositories.
  2. Add https://github.com/ProspectOre/weber-connect-unofficial as an Integration.
  3. Download Weber Connect Unofficial and restart Home Assistant.
  4. Open Settings → Devices & services and select the discovered Weber hub.

During initial pairing, fully close the Weber app and temporarily disable Bluetooth on phones or tablets that use the hub. After setup finishes, Bluetooth can be turned back on and the Weber app reopened.

Version 3.0 is a clean replacement for the old add-on, not an in-place upgrade. Remove the previous add-on before installing it.

Release and complete documentation:

@niner nice! Works great here. It discovered and connected through bluetooth right away for me. Also updates seem to work fine.
The cloud option is also still available? So you can use it in parallel with your phone app. Maybe good to add an entity to mention how it’s connected and when it got it’s last update.

Great to hear. You should see these improvements in the latest 3.0.2 release

Does this only work over Bluetooth? Mine is outside and on the WiFi network on the same Layer-2 network as HA but I doubt I have anything Bluetooth in range of it.

I can easily see its status over WiFi.

It doesn’t require a permanent Bluetooth connection. Bluetooth is needed for discovery and the one-time physical-confirmation pairing—either through Home Assistant’s Bluetooth adapter or an active ESPHome Bluetooth proxy near the grill.

After setup, the default Phone + Home Assistant mode receives status through Weber Cloud using the grill’s Wi-Fi/Internet connection. Home Assistant can then be completely outside Bluetooth range, and the Weber app can continue working normally.

It does not currently communicate directly with the grill over the local Layer-2 Wi-Fi network. If your Home Assistant Bluetooth cannot reach it for initial setup, an ESPHome Bluetooth proxy near the grill should solve that.

By any chance, and I know this is not directly part of this, I am running HA on a VM and I have a Raspberry PI doing my Z-Wave and Zigbee networks. By any chance does anyone know if there is a way to bring that Bluetooth on that Raspberry PI in as a resource to use on my HA VM?

Edited…I just bought some ESP32 devices to set up a Bluetooth Proxy to help out with that. It is 95-degrees outside and was over 100 yesterday…I hope they can take the outdoor heat. They don’t have to worry about water where it will be.

OK. I got me set up some ESP32 Home Bluetooth Proxies set up. It detects. This is the hub, not any device configured in a grill, itself.

It is detected. It sees it. The Hub is awake and showing temperature as I have a ambient probe plugged into port 1.

I get:

What happened: The hub returned TIMED_OUT for pairing.

No Home Assistant integration entry was saved. Keep the Weber app closed and phone or tablet Bluetooth off, wake the hub, then try pairing again with the same prepared private connection.

Hi, can you open an issue on GitHub if this is still an issue. Thanks