[RELEASE] Konnected Garage Door Opener Official Driver

nate · October 13, 2025, 10:27pm

@jrvisconti This has been fixed in project version 1.5.4 which I just released a few minutes ago. The Security+1.0 devices constantly report their state, but the blaQ was supposed to just basically ignore it if nothing had changed since the last state. There was a bug in one of the recent updates that must have removed that check, and we've fixed it now. Thank you for reporting.

CaptWoody · July 28, 2026, 8:41pm

@nate Not sure what the issue is but all of a sudden both of my GDOs are no longer working with Hubitat. They both show open in HE but are closed. None of the buttons, on/off open/close do anything. The web interface is working fine. I have tried rebuild the firmware on both. I have unplugged the GDOs and the Blaq as well as shutting down HE and left them all unplugged for 30 seconds. Not sure what else I should try.

Update 7/30 - I have repaired the driver in hubitat package manager (You should add an additional note in the driver code showing which version it is) no change.

I decided to try my backup hub which is still on 2.5.0.153. When I closed the GDO this is what the log was showing

CaptWoody · July 30, 2026, 4:54pm

@nate I beleive this may have started after I updated the firmware to V1.5.9.7.

I thought I saw some yellow lines when I was lookig at the logs with my primary hub connected but because the logs were scrolling so fast I couldn’t read them. Sure would be nice to have a better way to see the logs in the web interface.

nate · July 30, 2026, 7:11pm

Check the version of the espHomeApiHelper under Libraries code. This makes it seem like the client library is too old for the firmware:

Update it from here: https://raw.githubusercontent.com/konnected-io/hubitat-public/refs/heads/main/ESPHome/ESPHome-API-Library.groovy

CaptWoody · July 30, 2026, 7:20pm

just updated it but still not working. The log is scrolling to fast to capture but I can see the same message scroll by

nate · July 30, 2026, 7:24pm

Please try to capture at some of the logs, or a screenshot. otherwise I don’t really know what’s going on. mine is working fine.

CaptWoody · July 30, 2026, 7:36pm

Seems odd that the log is showing API 0.0 but looking at the API Version in HE shows 1.14

nate · July 30, 2026, 7:55pm

It looks like the device is connected and online. I am really not sure.

Maybe try nuking the device states in hubitat and letting them repopulate.

Is anyone else having this problem?

CaptWoody · July 30, 2026, 8:46pm

I just deleted the devices and uninstalled via HPM. Rebooted. Reinstalled via HPM. Added a new device and still getting the same error.

I guess I have learned my lesson about updating firmware on these if everything is working.

I will wait for a little while to see if anyone else runs into this or you find something. If not I will just physicall remove them and replace them with something else.

nate · July 30, 2026, 8:59pm

From those screenshots it looks like it’s working fine and healthy.

I haven’t seen any errors, just that API version warning but a warning is not an error. It’s an odd one though.

If you click any of the commands (Open / Close / Set) do you get an actual error in the log? What happens?

nate · July 30, 2026, 9:30pm

@CaptWoody Ok I threw Claude at it and I think we found the problem.

We are at the point now where AI is smarter and faster than me. It’s incredible

Try replacing your esphomeAPIHelper code with this version:

https://raw.githubusercontent.com/konnected-io/hubitat-public/fix/api-1.14-object-id-derivation/ESPHome/ESPHome-API-Library.groovy

CaptWoody · July 30, 2026, 9:35pm

So you said nuke so I did. I factory reset one of them, deregistered and readded it. Deleted the device in HE and readded it. Nothing changed. Just saw your post. Doing it now

CaptWoody · July 30, 2026, 9:40pm

Well I should have waited a bit longer. Guess even at my old age I need to learn more patients.

That seems to have worked. It is now working. Now I just need to re-add the other GDO back into HE and figure out what automations are broken now

If I run into any issues after I have some dinner I will let you know. Thanks

nate · July 30, 2026, 9:54pm

Great. Here is the actual fix. I’ll be pushing it thru ASAP:

github.com/bradsjm/hubitat-public

Declare API 1.14 and derive object_id when the device omits it

main ← konnected-io:pr/api-1.14-object-id-derivation

opened 09:46PM - 30 Jul 26 UTC

heythisisnate

+58 -5

## The problem ESPHome **2026.7.0 stopped sending `object_id` to every API clie…nt**, which breaks entity identification for any driver that keys off it. Six of the bundled example drivers in this repo are affected and will silently match nothing against 2026.7+ firmware: `ESPHome-AthomHumanPresenceSensor`, `ESPHome-EverythingPresenceOne`, `ESPHome-MultiSwitch`, `ESPHome-MultiSwitchSensor`, `ESPHome-MultiContactSensor`, `ESPHome-UpsyDesky` ### How we got here `espHomeHelloRequest()` only ever sent `client_info` (field 1) — never `api_version_major` (2) or `api_version_minor` (3). Devices therefore recorded this client as API **0.0** and, since 2026.1, log: ``` '<client>' using outdated API 0.0, update to 1.14+ ``` That was cosmetic until it wasn't: - ESPHome **2026.1** ([esphome#12698](https://github.com/esphome/esphome/pull/12698)) removed `object_id` from the protocol and bumped the API to 1.14, but kept sending it to sub-1.14 clients behind a backward-compat branch. Reporting 0.0 put us in that branch — the only reason this library kept working. - ESPHome **2026.7.0** ([esphome#17108](https://github.com/esphome/esphome/pull/17108), merged 2026-06-21) deleted that branch. `fill_and_encode_entity_info` no longer sets `object_id` for anyone, so it now arrives empty **regardless of the version a client declares**. ## The fix **FIX-16** — send `api_version_major`/`minor` in `HelloRequest`. I checked all 33 files of the `api` component at tag `2026.7.3`: `client_supports_api_version()` is referenced in exactly one place — the deprecation warning itself — so declaring 1.14 changes no other device behavior. **FIX-17** — `parseEntity()` derives `objectId` from the entity name when the wire field is empty, mirroring ESPHome's `str_sanitize(str_snake_case(name))`. The wire value still wins when present, so one path covers pre-2026.1, 2026.1–2026.6, and 2026.7+ firmware. > ⚠️ The two changes are **only correct together**. On 2026.1–2026.6, declaring 1.14 without the derivation would tell devices to stop sending `object_id` and break firmware that currently works. The derivation is deliberately byte-wise rather than `name.toLowerCase().replaceAll(...)`, which is wrong twice: ESPHome walks the UTF-8 *bytes* (a multi-byte character becomes one underscore **per byte**), and `String.toLowerCase()` is locale-sensitive. ## Why this may not look broken yet Existing installs can appear unaffected — drivers persist entity keys in `state`, and the `key` (an `object_id` *hash* computed on-device) is unchanged. The failure surfaces on a fresh pair, a driver reinstall, or any driver that re-resolves `objectId` → `key` on reconnect. ## Verification No hub in the loop, since Hubitat's injected symbols don't exist offline: - Full-file parse to `Phases.CONVERSION` under Groovy **2.4.21 and 3.0.21** — both clean. - `deriveObjectId()` type-checks under `@CompileStatic` on both and passes 13 cases, cross-checked against an independent port of the C++ algorithm. Covers awkward real-world names (`'Security+ Protocol'` → `security__protocol`, `'Pre-close warning'` → `pre-close_warning`) and multi-byte UTF-8. - `HelloRequest` encodes to `000F010A09<client>1001180E` — `10 01` = major 1, `18 0E` = minor 14, confirming `protobufEncode`'s falsy-skip doesn't drop them. **Confirmed on hardware:** a garage door controller on ESPHome 2026.7.x that was looping connect → 30s → disconnect now stays connected. That 30s was `SEND_RETRY_SECONDS * (SEND_RETRY_COUNT + 1)` — the supervision give-up in `sendMessageQueue()`, reached because a command sent with an unlearned entity key matches nothing on the device, so the expected state response never arrives and `closeSocket()` tears it down. ## Notes - Bumps `API_HELPER_VERSION` to `1.3.2`. - The second commit regenerating `ESPHome-API-Library-Bundle.zip` was produced automatically by `update-bundle.yml`, which runs on a push to any branch — not hand-edited. Verified the entry name is still `esphome.espHomeApiHelper.groovy`. Happy to drop that commit if you'd rather regenerate it on merge. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nate · July 31, 2026, 1:33pm

The fix has been merged upstream, esphomeAPIHelper is now at version 1.3.2.

This update is necessary for anyone on ESPHome firmware 2026.7.0 and higher.

CaptWoody · July 31, 2026, 2:07pm

Looks like there are a lot of debug entries in the HE log still when Enable descriptionText logging is selected. If you toggle it off there are no info entries being produced. I just turned it off and initialized and nothing shows in the logs. However, when I open and closed it shows

nclark · July 31, 2026, 2:07pm

@nate you should update the "packageManifest.json" with new version so that HPM knows there is an update and applies it instead of having to do a repair.

nate · August 1, 2026, 1:31pm

I had already updated the HPM manifests for Konnected's products, which pull in the packaged esphomeAPIHelper, but you're right that the upstream hubitat-public repo manifest was behind.

Thank you @jonathanb for giving me commit rights to hubitat-public

Should be all up to date now in #47

CaptWoody · August 1, 2026, 2:45pm

@nate, not sure if you missed this one or if you are still investigating. But the logs are getting flooded again with the debug with all logging toggled off.

Edit- I tried using Claude and got the following

Line 1103

if (settings.logEnable) { log.debug "ESPHome scheduling healthCheck in ${interval}s" }

Also suggested

Line 1095

if (settings.logEnable) { log.debug 'ESPHome ping response received — rescheduling healthCheck' }
espHomeSchedulePing()

nate · August 1, 2026, 7:36pm

You guys are kinda neurotic about your logs

Looks like the additional healthCheck logging was introduced upstream. Anyway it's now gated behind logEnable in #48

I updated the HPM packages as well.