[RELEASE] Home Connect Integration - Control Bosch, Siemens, Thermador and more

craigde · March 12, 2026, 6:12pm

Status Updates Stopping After a Few Days - Fix in v3.3.21

Hey everyone, thanks to those who reported that status updates stopped working I think I tracked down the root cause and have a fix ready.

What was happening

The V3 integration uses a single Server-Sent Events (SSE) stream to receive real-time updates from Home Connect for all your appliances. When that stream dies (which can happen for various reasons - token expiry, network blip, Home Connect server-side timeout), the driver is supposed to automatically reconnect.

The problem was several scenarios where it wouldn't recover:

The health watchdog could stop running entirely. It used a one-shot timer chain where each check scheduled the next one. If any link in that chain was lost (hub restart, Hubitat state hiccup), the watchdog stopped permanently - no more health checks, ever.
The watchdog only worked when already connected. If the connection status was "failed", "error", or "disconnected", the watchdog would see "not connected" and skip its check entirely. So the one component responsible for recovery would do nothing in exactly the states that needed recovery.
The reconnect attempt counter could permanently kill the connection. After 10 failed reconnects, the driver gave up with "failed - manual reconnect required" and never tried again.
An internal flag could get stuck, silently causing all disconnect events to be ignored.
Hubitat can report the stream as "stopped" while it's still alive. During testing I discovered that Hubitat fires eventStreamStatus(STOP) while the SSE connection is still delivering data. The driver would set status to "disconnected", schedule an unnecessary reconnect, and potentially create duplicate connections - all while events were flowing normally.

The net result: the SSE stream would die, reconnection would fail a few times, and then the driver would give up permanently. All appliances would stop getting real-time updates simultaneously.

Why "start from Hubitat" still worked

Some of you noticed that starting a program from Hubitat still showed status updates, but starting it physically at the machine did not. This is because Hubitat-initiated commands use direct REST API calls (which have their own token refresh and error handling). Physical button presses only generate events via the SSE stream - the exact thing that was broken.

What the fix does (Stream Driver v3.3.21)

Watchdog now runs on a persistent cron schedule (every 5 minutes) instead of a fragile timer chain - survives hub restarts, disconnect/reconnect cycles, and driver updates
Watchdog now auto-recovers from ALL non-connected states, not just "connected"
Stale "connecting" state is detected after 60 seconds and reset
Reconnect attempt counter is reset by the watchdog so the driver never permanently gives up
parse() now corrects stale connectionStatus - if data is arriving, the stream IS connected regardless of what Hubitat's eventStreamStatus reports
disconnect() no longer kills the watchdog cron schedule
refresh() and reconnect() no longer use blocking pauseExecution() which could create duplicate SSE connections when called twice near-simultaneously
Clicking "Initialize and Configure" on any child device now also checks and reconnects the SSE stream if it's down

Also in this update: Siemens Ambient Light support (Dishwasher v3.1.12)

If you have a Siemens dishwasher with Emotion Light (e.g. SX878D26PE), the AmbientLightEnabled, AmbientLightBrightness, and AmbientLightColor events were previously logged as "Unhandled event". These are now tracked as proper device attributes. No impact on dishwashers without this feature.

How to update

Update via HPM as usual, or manually update the Stream Driver, Dishwasher driver, and the parent App code.

How to confirm the fix is working

After updating, follow these steps:

Click Initialize on your Stream Driver. Go to your "Home Connect Stream Driver v3" device page and click the "Initialize" button. This activates the new persistent cron watchdog. Check that connectionStatus shows "connected".
Verify the watchdog is scheduled. On the Stream Driver device page, click "Scheduled Jobs" (tab at the top). You should see streamWatchdog listed as a cron job (0 */5 * * * ?). If you see it as a one-shot runIn instead, click "Initialize" again.
Test with a physical action. Open and close your dishwasher/oven/fridge door. Within a few seconds you should see a log entry like:

Event: BSH.Common.Status.DoorState = BSH.Common.EnumType.DoorState.Open

If you see this, real-time events are flowing from physical interactions.

4 Wait 24 hours and re-check. The old bug typically took a few days to manifest. After a day, go back to the Stream Driver and confirm connectionStatus is still "connected" and that lastEventReceived has a recent timestamp.

A note on API limits

The watchdog reconnect runs at most once every 5 minutes, and establishing an SSE connection is a single API call. Even in the worst case (reconnecting every 5 minutes for 24 hours), that's ~288 calls - well under the 1000/day limit. The existing rate limit detection is still in place and the watchdog respects it.

Let me know how it goes! If you're still having issues after updating, enable "Debug Logging" on the Stream Driver and share the logs.

danabw · March 12, 2026, 6:49pm

Really nice troubleshooting/fixing session, Craig! Thanks for the hard work on this.

Scheduled job appeared:

And I'm getting Open/Close events as noted...below is starting from open state, close, wait 5s, then open.

And from device events:

Do you expect that these changes may have an impact on my problems starting a delayed program?

craigde · March 12, 2026, 7:00pm

I could not repo the delayed start issue. I think try it and share the logs.

oldcomputerwiz · March 12, 2026, 7:28pm

I'll update tomorrow. I'm picking up my bride at the airport then we are going out to dinner.

Thanks Craig!

jb1 · March 12, 2026, 8:36pm

@craigde thanks for your hard work.

Unfortunately no change on my end.
I installed the update via HMP and followed your instructions.

Unfortunately the connection status doesn't show "connected" instead of this it states something like "rate limited until 2026-03-13 9:00 PM". The event tab shows that the status was connecting but chanced immediately from connected to disconnected.

No status changes are going to be updated after a couple of seconds.

Did I miss something or do I have to restart the hub?

Please let me know if you need some log files from the driver or the device.

Thanks

P. S.: the scheduled job seems to be shown correctly

craigde · March 12, 2026, 9:26pm

That rate limit means you exceeded 1000 API calls in 24 hours - likely caused by the old reconnect loop bug before the update. There's nothing to do until that time passes. Important: don't click Initialize, Reconnect, or Refresh until then - each attempt counts against your quota and could push the window out further.

The good news is your scheduled job is set up correctly, so once the rate limit expires tomorrow at 9 PM, the watchdog should automatically reconnect within 5 minutes - you shouldn't need to do anything. If it doesn't recover on its own after 9 PM, click Initialize once and let me know. If it still misbehaves, enable Debug Logging on the Stream Driver and share the logs.

oldcomputerwiz · March 13, 2026, 1:20am

I updated and the dishwasher and states are now updating (on/off, open/closed).

Sometimes the state updates are instantaneous while others may take 10-15 seconds. Normally you wouldn't even notice this as nobody usually stands at their dishwasher turning it on/off or opening/closing the door in rapid succession.

Looks great! Thank you!

danabw · March 13, 2026, 3:13am

Speak for yourself! [Heads off for another 20 minute session enjoying opening and closing his dishwasher.]

danabw · March 13, 2026, 3:17am

Works now! Just set a delayed start for 47 minutes from now. Dishwasher turned itself on in "wait" mode and Bosch app shows the start scheduled in 47 minutes.

Genius! (You.)

jb1 · March 13, 2026, 9:44pm

@craigde Something seems to be wrong with my installation, but I don't know why or what.
Still no luck with my status updates.
Interestingly (on a bad way) my connection status doesn't show connected. Now it says the following:

Furthermore it looks like my installation is too chatty?
Here some logs from my stream driver, hopefully that helps you

In addition some logings from my dishwasher

Hopefully that helps to get an idea what's going on or wrong with my installation.

Thanks in advance for your support

craigde · March 13, 2026, 10:22pm

Hi @jb1 Looking at your logs I think I see what's happening. The rate limit expires, the driver reconnects, and then it immediately fires off 9 API calls (status + settings + programs for each of your 3 appliances) to refresh device state. Those calls are hitting Home Connect's rolling 24-hour window before it's fully reset, which triggers a brand new 24-hour rate limit. You're stuck in a loop.

I've think I have fixed this in Stream Driver v3.3.22 and App v3.1.7:

GET requests now respect rate limit state (they didn't before — only PUT/DELETE did)

The device refresh that runs after reconnection is now blocked when rate limited

The HTTP 429 backoff is now 1 hour instead of 60 seconds

To break the cycle:

Update via HPM to get v3.3.22 / App v3.1.7

Go to the Stream Driver device page and click Clear Rate Limit (this resets the rate limit timer)

Wait a few minutes, then click Initialize

If it connects and immediately gets rate limited again, that means HC's 24-hour window hasn't rolled over yet. In that case, just leave it alone — the watchdog will auto-reconnect once the actual HC window expires, and this time it won't blast all those GET requests.

In the early days of building this driver I got myself in this state and the HC API is unforgiving. Once it blocks you there is no recourse but to wait the full 24 hours. Keep me posted on if it makes a difference in 24 hours from now!

jb1 · March 14, 2026, 7:27am

@craigde Firstly thanks for your support.

I followed your description. After hitting Clear rate limit and waiting a couple of minutes I pressed Initialize. The status shortly changed to connected than to disconnected.

Is it good or bad, I have no clue

craigde · March 14, 2026, 7:01pm

@jb1 Thanks for the logs and device screenshot. I just pushed an HPM update to 3.3.23 for you
What's happening: Home Connect's server is still rate-limiting your account (likely for 24 hours). When you cleared the rate limit and clicked Initialize, the stream briefly connected but Home Connect immediately sent a rate limit error back through the SSE stream, re-setting the local rate limit. The v3.3.22 code had a bug where the disconnect event then overwrote the "rate limited until..." status with just "disconnected", hiding the actual rate limit from you.

What the fix does (already pushed):

Connection status will now correctly show "rate limited until [time]" instead of misleading "disconnected"
Watchdog logs will show the actual expiry time and minutes remaining
Brief connection bounces won't trigger API calls that would worsen the rate limit

What to do now: Install the update. Wait for the server-side rate limit to fully expire (the updated driver will show you exactly when), then the watchdog will auto-reconnect. Don't click Initialize until then.

danabw · March 14, 2026, 7:42pm

Just got to say, I absolutely love how you communicate on the updates. Really great communication.

jb1 · March 14, 2026, 9:16pm

@craigde your support is really awesome and highly appreciated. Thank you very much.

One point just came to my mind and I don't know why my appliances or my setup maybe act differently than the users. Anyway, when you released your new V3 version, you mentioned that both versions can be used in parallel without any interference.

Is it possible that the old setup which is still active and running counts with any requests again at my quote?

Should I maybe deactivate or can I leave it for the moment and just retire when V3 is totally back to normal.

I totally agree with @danabw your communication, but also your support and your work is outstanding.

Please let me know how I can offer you a big coffee as a thank you for all of that.

jb1 · March 14, 2026, 9:49pm

After an update of the driver to v3.3.23 I now see the exact time instead of disconnect. Will wait until 8.24 am tomorrow morning before doing anything. Will see what happens at 8.24 am tomorrow morning. As I understood correctly I need to press Initialize afterwards.

Fingers crossed all is going back to normal.

Again thanks a lot for all your time and support. Your are really outstanding........

craigde · March 14, 2026, 10:44pm

@jb1 Thanks. That's a key piece if info. While its true they should be able to run side by side ok. In this rate limiting situation it could definitely cause problems.

I've done a deep dive into how the Home Connect API rate limiting actually works, because the official documentation is sparse and the behavior isn't intuitive. Sharing my findings here since rate limiting is the #1 issue people run into with Home Connect integrations.

Home Connect Rate Limits

I learnt that in addition to the 1,000 calls/day limit the Home Connect API actually enforces multiple independent rate limits:

Limit	Type	Retry-After Header?
10 requests/sec average (20 burst)	Leaky bucket	No
50 calls in 1 minute	Window	Yes
1,000 calls in 1 day	Window	Yes
10 successive error calls in 10 minutes	Window	Yes
5 start program calls in 1 minute	Window	Yes

The per-second limit uses a leaky bucket algorithm (requests drain at a constant rate). The others use time windows with a "remaining period" countdown.

The Daily Limit: Fixed Window, Not Sliding

The 1,000 calls/day limit uses a fixed window. When you hit it, the API returns:

"The rate limit '1000 calls in 1 day' was reached. Requests are blocked during the remaining period of XXXX seconds."

The "remaining period" is a countdown to when the window resets — not a new 24-hour block from when you hit the limit. Users have reported remaining periods ranging from ~47 minutes to ~14 hours, which corresponds to how much time was left in the current window when they exhausted the quota.

The Hidden Danger: "10 Successive Error Calls"

I think this may be the issue we are running into here:

You hit the daily limit (or any other error)
Any integration retries → gets a 429 back
That 429 counts as an error call
After 10 error calls in 10 minutes, you trigger this rate limit too
Now you're double-blocked
Each subsequent retry is another error call that can extend this block

This creates a vicious cycle: the integration keeps retrying, each retry extends the error-call block, and the "remaining period" grows larger and larger. People in the HA community report being locked out for 5, 10, or even 14+ hours — it's not the daily limit doing that, it's the error-call limit being continuously re-triggered.

The only way to break the cycle is to stop making API calls entirely and wait.

How This Affects Multi-Device Setups

The daily limit is per client per user account — not per device. Whether you have 1 appliance or 5, you get the same 1,000 calls/day. This means more devices = faster you burn through the quota, especially during reconnection events.

A typical reconnect refreshes status, settings, and active program for each device:

1 device: ~3 API calls per reconnect
3 devices: ~9 API calls per reconnect
5 devices: ~15 API calls per reconnect

Under normal SSE streaming operation, this isn't a problem — events push to you in real time with zero API calls. But if your connection bounces repeatedly, those reconnect costs add up fast.

Running Multiple Integrations

You mentioned running two Home Connect integrations (e.g., a legacy driver alongside a newer one), be aware they share the same API quota. You're not doubling your capacity — you're doubling your consumption against the same 1,000-call limit.

I also went back and checked the code from the old drivers and they don't handle 429 errors properly, it will:

Keep retrying after hitting the limit
Trigger the "10 successive error calls" block
Extend that block indefinitely with continued retries
Prevent both integrations from recovering

What To Do Now

Step 1: Disable the old drivers.

Go to the Hubitat Devices page and find your old Home Connect devices (the ones without "v3" in the driver name). For each one, click into the device and remove or disable it. Also disable the old Home Connect app (the one without "v3" in the name) from the Apps page.

This is the most important step — the old drivers don't handle 429 errors properly, so right now they're almost certainly still firing retries in the background, each one counting as an error call and extending your lockout window. Our v3 driver stopped sending requests when it saw the rate limit, but the old drivers don't know to do that.

Step 2: Get the real expiry time.

After disabling the old drivers, run clearRateLimit on the v3 Stream Driver, then click Initialize once. It will almost certainly fail with a 429 — but that's the point. The driver will parse the server's actual Retry-After and update the connectionStatus attribute with the real expiry time (not the stale one from before). This costs you just 1 error call out of the 10-in-10-minutes budget — worth it to know the actual deadline.

Step 3: Wait, then reconnect.

The driver automatically schedules a reconnect when the rate limit expires (plus a safety buffer), so you shouldn't need to do anything — just wait. Check connectionStatus on the Stream Driver; once it flips to "connected", you're back in business.

If for some reason the auto-reconnect doesn't fire (e.g., hub reboot in between), just click Initialize again after the expiry time has passed.

Sources: Home Connect API Documentation, Homebridge Home Connect Error Reference, Home Assistant Community Discussion

jb1 · March 15, 2026, 6:50am

Firstly, you are a genius!
Many thanks man for the detailed explanation and walk through the needed steps to get back in business.
I did all what you described in step 1 and step 2. Just after running "clearRateLimit" and pressing "Initialize" the status changed to "connected". All three devices get the updates and status now. Yes I'm back in business.

Thanks for all your great support and effort in this.

Only one thing I'm still missing, how can I thank you for this........ I owe you a lot of coffee

craigde · March 15, 2026, 8:32pm

So glad it's working!!! You can buy me a beer sometime Let me know if you see any unhandled events in your logs. Since I don't have the same devices as you there may be capabilities I can easily add. For example, I think it was your dishwasher that had lights I added.

JdThomas24 · April 7, 2026, 4:15pm

@craigde - Can you update the debug for an auto off feature - Lets says 30/60 minutes?
I, as with many, forget to turn this off.

Possibly Also:

Suppress keep-alive debug logs
In processSSEMessage(), change the keep-alive log from logDebug to log when verboseStreamDiag is on):