Struggling to Upgrade to ESPHome with Hubitat

[mluck1]

@Nate, this is continuation of this thread from the Hubitat community last week. I am starting a new thread here at your request.

Having reverted to legacy last week, I started with a blank sheet and tried again. Unfortunately I couldn’t even get back to where I hit a wall last time. Now, when I create the virtual device in Hubitat I get “Connecting” as the network status, but it never goes online and ultimately resolved to “Offline”

Here was my process (and honestly, I have repeated this dozens of times over many hours and hours, so it’s entirely possible I am doing something stupid):

1. Factory reset the Pro board
2. Flashed espHome using install.konnected.io (the Pro board I am working with currently is a v1.8 fwiw)
3. Went to Konnected mobile app, added device, configured zones, enabling Local Native API and Local Web Page/API.
4. Built firmware
5. Updated firmware
6. Waited for device to come back online
7. In Hubitat, created virtual device
8. Added IP address in Preference tab (can confirm the board is connected to network via ethernet as my router (Unifi) says so, plus I’m able to put the board’s IP address in my browser and pull up the Konnected status page, per below)
9. After saving the IP address, I go to the Commands tab and hit initialize. This is where I get stuck repeatedly. Hubitat logs report failed attempt to connect.

Interestingly, the child devices do show up and seem to even work now, but the parent device continues to indicate offline. So strange.

Konnected Pro Board Status Page

Hubitat Logs Showing Failed Connection Attempts

– Nate, your forum won’t allow me to add media to my posts –

And here's the log from the Konnected Status Page when I produced a couple random events

ime Level Tag Message
09:50:59 [D] [debug:191]
CPU Frequency: 160 MHz
09:50:59 [D] [debug:199]
Framework: ESP-IDF
09:50:59 [D] [debug:206]
ESP-IDF Version: 5.4.2
09:50:59 [D] [debug:211]
EFuse MAC: C0:49:EF:51:1A:00
09:50:59 [D] [debug:079]
Reset Reason: Reboot request from esphome.ota
09:50:59 [D] [debug:107]
Wakeup Reason: undefined
09:50:59 [D] [debug:079]
Reset Reason: Reboot request from esphome.ota
09:50:59 [D] [text_sensor:085]
‘Reboot Reason’: Sending state ‘Reboot request from esphome.ota’
09:50:59 [C] [debug:112]
Partition ta
09:50:59 [C] [debug:119]
otadata 1 0 0x00009000 0x00002000
09:50:59 [C] [debug:119]
phy_init 1 1 0x0000B000 0x00001000
09:50:59 [C] [debug:119]
app0 0 16 0x00010000 0x001C0000
09:50:59 [C] [debug:119]
app1 0 17 0x001D0000 0x001C0000
09:50:59 [C] [debug:119]
nvs 1 2 0x00390000 0x0006D000
09:51:19 [D] [api.connection:253]
Hubitat HE Christina Main Hub (10.0.0.7) disconnected
09:51:19 [W] [component:297]
api set Warning flag: unspecified
09:51:22 [D] [api:160]
Accept 10.0.0.7
09:51:22 [W] [component:336]
api cleared Warning flag
09:51:22 [D] [status_led:030]
Restoring light state OFF
09:51:22 [D] [api.connection:1383]
Hubitat HE Christina Main Hub (10.0.0.7) connected
09:51:26 [D] [sensor:131]
‘Heap Free’: Sending state 298116.00000 B with 0 decimals of accuracy
09:51:38 [D] [light:089]
‘blue_status_led’ Setting:
09:51:38 [D] [light:102]
State: ON
09:51:38 [D] [binary_sensor:039]
‘Utility Motion’: New state is ON
09:51:38 [D] [status_led:050]
‘blue_status_led’: Setting state ON
09:51:38 [D] [light:089]
‘blue_status_led’ Setting:
09:51:38 [D] [light:102]
State: OFF
09:51:38 [D] [status_led:050]
‘blue_status_led’: Setting state OFF
09:51:44 [D] [light:089]
‘blue_status_led’ Setting:
09:51:44 [D] [light:102]
State: ON
09:51:44 [D] [binary_sensor:039]
‘Utility Motion’: New state is OFF
09:51:44 [D] [status_led:050]
‘blue_status_led’: Setting state ON
09:51:44 [D] [light:089]
‘blue_status_led’ Setting:
09:51:44 [D] [light:102]
State: OFF
09:51:44 [D] [status_led:050]
‘blue_status_led’: Setting state OFF
09:51:53 [D] [api.connection:253]
Hubitat HE Christina Main Hub (10.0.0.7) disconnected
09:51:53 [W] [component:297]
api set Warning flag: unspecified
09:51:55 [D] [sensor:131]
‘Uptime’: Sending state 1743.24304 s with 0 decimals of accuracy
09:51:56 [D] [api:160]
Accept 10.0.0.7
09:51:56 [W] [component:336]
api cleared Warning flag
09:51:56 [D] [status_led:030]
Restoring light state OFF
09:51:56 [D] [api.connection:1383]
Hubitat HE Christina Main Hub (10.0.0.7) connected
09:51:56 [D] [sensor:131]
‘Heap Free’: Sending state 298116.00000 B with 0 decimals of accuracy
09:52:26 [D] [sensor:131]
‘Heap Free’: Sending state 298116.00000 B with 0 decimals of accuracy
09:52:27 [D] [api.connection:253]
Hubitat HE Christina Main Hub (10.0.0.7) disconnected
09:52:27 [W] [component:297]
api set Warning flag: unspecified
09:52:32 [D] [api:160]
Accept 10.0.0.7
09:52:32 [W] [component:336]
api cleared Warning flag
09:52:32 [D] [status_led:030]
Restoring light state OFF
09:52:32 [D] [api.connection:1383]
Hubitat HE Christina Main Hub (10.0.0.7) connected

[nate]

@mluck1 I’ve upgraded your trust level on the community. please post the additional screenshots.

From the log snippit you just posted, it looks like Hubitat is connecting.

[mluck1]

Thanks @nate

It still shows offline--initialize and/or refresh doesn't get it online

The parent device log shows that it is unsuccessfully trying to connect

But the logs on the Konnected board status page seems to indicate it is online

Something funky is going on. I wonder if there’s a situation where the parent device could incorrectly think it’s disconnected, even when the children are getting events?

[nate]

Hmm, I haven’t seen this one before.

The line ESPHome sending msg type #3 that is failing and retrying is Hubitat trying to send a connect request, which seems to correspond with the API warning flags in the device logs.

So, it’s communicating, but something is going wrong with the handshake to establish the persistent socket connection. Strange.

I will try to reproduce it here with a clone of your firmware. Could you share with me your 12-character device ID?

[mluck1]

Thanks Nate

DeviceID = c049ef511a00

EDIT: In an attempt to eliminate variables, I tried it on a different Hubitat hub. Got the same behavior. I also tried a different Pro board on the same Hubitat hub. And I got normal totally functional behavior. Hmm.

EDIT 2: one other troubleshooting tidbit: I noticed the uptime attribute in the Hubitat device is continually incrementing, as one would expect normally, even though network status remains Offline.

[nate]

@mluck1 I think I figured it out. First, the proposed fix:

In Hubitat, go to Libraries Code > esphomeApiHelper. Scroll all the way down to line 1235 which is currently:

espHomeConnectRequest(settings.password as String)

Change that line to:

espHomeConnectResponse(0: [])

Then go back to your device and hit Initialize again. It should fully connect this time.

What appears to have happened here is a change that was introduced in ESPHome 2025.10.0. Now honestly looking at the code I’m not sure why this change would affect us in this case, but the backstory is that ESPHome is deprecating/removing the plaintext password capability in favor of noise encryption which has been supported by ESPHome/HA for a few years now. This Hubitat library for ESPHome was originally written before plaintext passwords were deprecated, and now this connectRequest / connectResponse cycle is no longer relevant.

As of yet, this Hubitat ESPHome library doesn’t support ESPHome noise encryption, so we’re not using passwords nor encryption at present for Hubitat users. I probably should get around to adding support for proper encryption … but alas too many things on the todo list.

So long story short, it wasn’t a failure to connect at all, it was actually connecting just fine, but since the unnecessary connectRequest was getting called and never getting a response back from the device, Hubitat didn’t know that the connection succeeded.

The fix above is kinda a hack to just bypass the connectRequest and assume that we’re not using authentication at all, and just sets the connection flags immediately after we get a HelloResponse back from the device.

@mluck1 please try it out and let me know how that works. If successful, I will work on updating the library and publishing a new version.

[mluck1]

Yup that worked. Thanks for the assist. Really appreciate it.

@nate

alas too many things on the todo list

You and me both, brother.

[nate]

Proper fix done:

Handle passwordless authentication behavior change in ESPHome 2025.10; rename ConnectRequest/Response to AuthenticationRequest/Response

Thanks for reporting @mluck1!

[mluck1]

No prob.

To pick up this change, do we need to reflash from install.konnected.io?

[nate]

No, this is the library on the Hubitat side. A firmware update isn’t needed.
Update with HPM or by downloading the latest ZIP:

Release 2025.10.1 · konnected-io/konnected-hubitat