[rachio] Initial contribution

[kovacsi2899]

This is a clean replacement for #20793 with the same final Rachio binding content.

Racho Binding Functionality Overview:

The Rachio binding integrates Rachio Smart Irrigation Controllers and Smart Hose Timer resources with openHAB through the Rachio Cloud APIs. A cloud bridge represents a Rachio account and automatically discovers controllers, irrigation zones, fixed and Flex schedules, Smart Hose Timer base stations, valves, and valve programs.

For irrigation controllers, the binding exposes controller availability and operating state, rain sensor and rain-delay information, paused and active watering state, current schedule details, recent API events, weather skips, and forecast data. Controllers can be enabled or disabled, stopped, rain-delayed, paused or resumed, and used to run either individual or multiple zones.

Irrigation zones expose their enabled and watering states, runtime information, last-watered time, water-model values, and zone images. Zones can be enabled or disabled, started and stopped, and supplied with runtime or soil-moisture commands.

Fixed and Flex schedules are represented as separate Things. Their state, associated zones, previous and upcoming runs, and seasonal adjustment are available. Supported commands include starting or skipping a schedule, changing its seasonal adjustment, and skipping the currently running zone.

Smart Hose Timer support includes base-station and valve status, valve battery and flow state, manual watering, default runtime configuration, previous and upcoming watering summaries, program metadata, and commands for creating or canceling skips for upcoming runs.

State is synchronized through polling, with optional modern signed webhooks for near-real-time irrigation and Smart Hose Timer updates. Legacy Rachio notifications remain available as an alternative for irrigation controllers.

Potential Future Development:

The current implementation covers the practical automation surface of the Smart Irrigation Controller and Smart Hose Timer APIs. If there is user demand, future development could add Smart Lighting Controller support, optional creation and editing of Smart Hose Timer programs, Property/Home-based resource grouping, and additional telemetry such as dedicated controller flow-volume channels and richer zone metadata.

Community thread link:
https://community.openhab.org/t/rachio-smart-sprinkler-controller/7078

Link for latest JAR:
https://github.com/kovacsi2899/openhab-addons/releases/tag/PR_review_09_08_2026

[robnielsen]

I am running your latest binding with the openHAB cloud webhook and it is working as expected. One suggestion for is to add something to the UI for the cloud thing with the url for the webhook.

Also, there is a bit of inconsistency with the value of the items for the controller. There is a mix of undefined, empty strings and no value:

Linked Channel	Current Value
rachio:device:config:XXXXXXXXXXXX:last-skip-type	undefined
rachio:device:config:XXXXXXXXXXXX:schedule-name	"" (empty string)
rachio:device:config:XXXXXXXXXXXX:active-zone-name	no value
rachio:device:config:XXXXXXXXXXXX:last-skip-reason	undefined
rachio:device:config:XXXXXXXXXXXX:active-zone-number	no value
rachio:device:config:XXXXXXXXXXXX:last-skip-start-time	undefined
rachio:device:config:XXXXXXXXXXXX:current-schedule-type	undefined
rachio:device:config:XXXXXXXXXXXX:current-schedule-name	undefined
rachio:device:config:XXXXXXXXXXXX:current-schedule-end-time	undefined
rachio:device:config:XXXXXXXXXXXX:current-schedule-start-time	undefined

[robnielsen]

The forecast is completely wrong. Per Google, the forecast for today is high - 88 °F, low - 69 °F, precipitation 35%, wind 14 mph

This is what it is returning, notice the date is in the future. It's June 30, 2026:

Rachio Weather Forecast

Forecast Field	Value
Summary	Showers
High Temperature	73 °F
Low Temperature	57 °F
Precipitation	0.02"
Precipitation Probability	22%
Wind Speed	4.97 mph
Forecast Date/Time	July 11, 2026 at 12:00:00 AM (local time)

[kovacsi2899]

I am running your latest binding with the openHAB cloud webhook and it is working as expected. One suggestion for is to add something to the UI for the cloud thing with the url for the webhook.

Also, there is a bit of inconsistency with the value of the items for the controller. There is a mix of undefined, empty strings and no value:

Linked Channel Current Value
rachio:device:config:XXXXXXXXXXXX:last-skip-type undefined
rachio:device:config:XXXXXXXXXXXX:schedule-name "" (empty string)
rachio:device:config:XXXXXXXXXXXX:active-zone-name no value
rachio:device:config:XXXXXXXXXXXX:last-skip-reason undefined
rachio:device:config:XXXXXXXXXXXX:active-zone-number no value
rachio:device:config:XXXXXXXXXXXX:last-skip-start-time undefined
rachio:device:config:XXXXXXXXXXXX:current-schedule-type undefined
rachio:device:config:XXXXXXXXXXXX:current-schedule-name undefined
rachio:device:config:XXXXXXXXXXXX:current-schedule-end-time undefined
rachio:device:config:XXXXXXXXXXXX:current-schedule-start-time undefined

For the Cloud Thing UI: I added webhook diagnostic properties to make the active webhook state visible from the Thing page. The Cloud Thing now exposes the webhook mode, registration state, last registration attempt, last the Cloud Thing UI: I added webhook diagnostic properties to make the active webhook state visible from the Thing webhook event timestamp and last webhook event type. In my runtime test this shows the expected cloud mode, registered state, and the latest accepted Rachio webhook event.

For the controller channel state inconsistency: I found and fixed the mixed optional-state handling. The controller optional status channels were previously using a mix of UNDEF, NULL and empty strings depending on the code path. I changed those optional controller values so that a normal absence of data now uses NULL consistently. UNDEF is now reserved for invalid nonblank DateTime values.

This applies to:

• active-zone-number / active-zone-name / active-zone-id
• current-schedule-id / current-schedule-name / current-schedule-type / current-schedule-start-time / current-schedule-end-time
• last-skip-type / last-skip-schedule-id / last-skip-start-time / last-skip-reason
• legacy schedule summary fields such as schedule-name / schedule-info / schedule-start / schedule-end

The events.log confirms the change. In idle state the previously inconsistent controller fields now update to NULL. For example, current-schedule-name/type/start/end change from UNDEF to NULL, active-zone fields update to NULL, and last-skip fields also change to NULL. The same log also confirms that when a Zone 7 Quick Run starts, the active-zone fields are populated again and the current schedule fields change from NULL to actual values such as Quick Run, MANUAL, start time, end time, 60 s duration and running=ON.

I also kept current-schedule-running as a real ON/OFF state and current-schedule-duration as 0 s while idle.

[kovacsi2899]

The forecast is completely wrong. Per Google, the forecast for today is high - 88 °F, low - 69 °F, precipitation 35%, wind 14 mph

This is what it is returning, notice the date is in the future. It's June 30, 2026:

Rachio Weather Forecast

Forecast Field Value
Summary Showers
High Temperature 73 °F
Low Temperature 57 °F
Precipitation 0.02"
Precipitation Probability 22%
Wind Speed 4.97 m
Forecast Date/Time July 11, 2026 at 12:00:00 AM (local time)

I fixed weather date alignment and now it shows actual date weather, see screenshot from my Openhab system and my Rachion app,

[robnielsen]

Unable to build with the latest code changes:

[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   RachioDeviceHandlerStatusTest.forecastUpdatedFallbackUsesRetrievalTimestampNotSelectedEntryTime:747
Expected: is "61-82 °F, precipitation chance 0%, wind 8.5 mph"
     but: was ""
[INFO]
[ERROR] Tests run: 408, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:00 min
[INFO] Finished at: 2026-07-03T08:19:50-05:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.5.6:test (default-test) on project org.openhab.binding.rachio: There are test failures.

[kovacsi2899]

Thanks, I fixed the failing test.

The failure was caused by a timezone-dependent test fixture. The test used 2026-06-16T00:00:00Z as the selected forecast entry timestamp. In a negative-offset timezone this can resolve to the previous local date, so the new date-aware forecast selector correctly rejected it as not being the controller-local June 16 forecast.

I made the fixture deterministic by adding an explicit forecast date (2026-06-16) while keeping the entry timestamp in place, so the test still verifies that forecast-updated falls back to the retrieval timestamp and not the selected entry timestamp.

We had also problem with forecasted wind unit handling when it was translated from kpm to kph. I have fixed it in this commit as well.

[robnielsen]

I'm seeing

2026-07-05 18:41:11.776 [WARN ] [internal.handler.RachioBridgeHandler] - Modern webhook registration for controller 'xxxx' failed; polling remains active, cause=RachioApiException

in openhab.log, but the webhook appears to work correctly.

[kovacsi2899]

Warning that modern webhook registration failed, but webhook delivery still appears to work.

This is possible when webhook is not cleared / renewed. Clear all callbacks option is there for a previously registered matching webhook may still exist on the Rachio side and continue to deliver events. The failed call may have been only a registration/renewal attempt, not the active webhook itself becoming invalid.

The Cloud Thing still shows cloud webhook mode and the last webhook event timestamp/type continue to update. Polling also remains active as fallback.

I did try on both webhooks function legacy and new on Opehab 5.2 and 5.1.4 and both was working on 5.2 and legacy was working on 5.1.4. I was starting to use with clear webhook function always at the beginning.

[robnielsen]

Shouldn't the binding first look to see if the binding has a registered webhook and then try to register if there isn't one? The warning message should not be displayed.

[kovacsi2899]

Yes, I agree. I updated this.

The modern webhook registration path is intended to be idempotent: list existing webhooks first, retain a matching registration if present, and only create a new one if no matching webhook exists.

The warning was misleading when a previous matching webhook could still be active and webhook events were still arriving. I adjusted the log/state handling so a failed later verification/renewal attempt after a previous successful registration is treated as non-fatal, with polling still active as fallback. A warning should now be reserved for cases where no known existing registration is available and the binding really fails to establish/verify the webhook.

[robnielsen]

I'm still getting the error:

2026-07-06 19:57:45.273 [WARN ] [internal.handler.RachioBridgeHandler] - Modern webhook registration for controller 'xxxxx' failed; polling remains active, cause=RachioApiException

I figured out what is going on. I have access to a second controller that is controlled by somebody else which is not configured (its ignored in the Things inbox), and it's trying to register a webhook for it, which it shouldn't.

I used Atmosphere CLI to check the webhooks and here's what it reported about it:

Device: Rachio (ID: xxxxx )

• Status: Shared device (Owned by user ID: yyyyyy ).
• Note: Webhooks could not be queried for this device. The API returned HTTP 403 Forbidden (
PERMISSION_DENIED ) because the authenticated user is not authorized to manage or view webhooks on
controllers shared with them by other accounts.

[kovacsi2899]

Thanks a lot, that completely explains the warning you were seeing. The bridge webhook sync was accidentally pulling the entire account device list. This meant it was trying to register shared controllers or devices that weren't even configured as openHAB things yet. Rachio lets you see shared controllers, but throws a 403 permission_denied error if you try to touch their webhooks—exactly what you saw in the Atmosphere CLI. I've tweaked the logic so webhooks only apply to active, configured controllers now. Anything ignored in the inbox or left unconfigured will be completely skipped. If no controllers are ready, the bridge will just say waiting for configured controller things instead of trying to register the whole account. Discovery and polling work exactly the same as before; this just fixes the webhook scope.

[robnielsen]

Looks good now. My only suggestion is to fix the deprecation warnings during compilation. I'll leave it up to the maintainers to do the code review.

[kovacsi2899]

I cleaned up the compile warnings.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.

[wborn]

Thanks for the big PR!

To fix the build error, please add the add-on to: https://github.com/openhab/openhab-addons/blob/main/bom/openhab-addons/pom.xml

Too bad Copilot currently cannot help with reviewing. That would significantly speed up the review process. Maybe temporarily removing the test code brings it below 20000 lines? 🙃

[kovacsi2899]

Thanks, I pushed two follow-up commits.

The first commit addresses the InfluxDB persistence/chart issue reported by Jeff. active-zone-number now publishes 0 when no zone is active. Since Rachio zone numbers are 1-based, 0 is used as the idle/no-active-zone sentinel. active-zone-name and active-zone-id still remain NULL while idle.

The second commit adds org.openhab.binding.rachio to bom/openhab-addons/pom.xml in alphabetical order between qolsysiq and radiobrowser, as requested.

If necessary for copilot, I can remove test folder, pls let me know.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.

[kovacsi2899]

Addressed in commit 2a94bd6.
The discovery path now uses stable, deeply immutable snapshots while retaining live controller and zone identities for handlers and webhooks. The config-status localization, add-on metadata, and event-history UI limit were corrected as requested.
I also tested the generated JAR in a live openHAB installation. Modern start/stop webhooks were processed once, legacy duplicates were ignored, and five consecutive scheduled polls reported Zone 6 as unchanged, confirming that an older cloud lastWateredDate no longer causes repeated zone channel publication.

[wborn]

Thanks for addressing the remaining feedback. AI re-reviewed the current PR head and the previous concerns now look resolved.

Could you also add back the tests that were removed earlier? They provided useful coverage and should remain part of the contribution.

The code still needs a final manual review before this can be considered ready to merge.

Nothing blocking currently

[kovacsi2899]

I’ve restored the Rachio test folder and updated them to match the current implementation in c28e962.
The restored tests now cover the current immutable snapshot handling, webhook lifecycle and modes, configuration reconciliation, handler initialization, API model changes, and asynchronous Smart Hose summary refresh behavior.
Validation completed successfully:
The full suite now contains 416 tests across 30 test classes, all passing. The complete Maven build also passes, including Spotless, Checkstyle, PMD, SpotBugs, BND, XML, and Karaf verification.

This commit only restores and updates files under the Rachio src/test directory; no production code was changed.

[wborn]

Did you see that the tests are falling?

[kovacsi2899]

No. I've just realized. Previously both tests were green. I'll check.

[kovacsi2899]

Quick follow-up on the failed Ubuntu CI run: I traced it to a timing race in cloudWebhookExpiryRefreshIsSharedAcrossBridgeHandlers, not to a production-code regression. onCloudWebhookProviderChanged() schedules reconciliation asynchronously, while the test was checking the second requestWebhook() call immediately.

Commit 04593a4fd4 now waits for the reconciliation to finish before asserting, and applies the same synchronization to the related provider-change tests so the positive and negative cases exercise the completed background work consistently.

Validation is green locally:

• the full configuration test class: 74/74
• the previously failing test: 10/10 separate runs
• the complete Rachio suite: 416/416
• full clean install, including Spotless, Checkstyle, PMD, SpotBugs, BND, XML, and Karaf verification

Only the Rachio test file changed; production code is untouched.

[wborn]

AI re-reviewed the current PR head after the tests were restored.

The restored test suite is a substantial improvement and now provides useful regression coverage for the concurrency and lifecycle issues raised earlier, including immutable discovery snapshots, webhook request/removal serialization, stale event claims, and zone reconciliation.

I found two remaining implementation concerns and one cleanup issue below. The code still needs a final manual review before it can be considered ready to merge.

[wborn]

AI re-reviewed the current PR head after the latest fixes.

The previously raised concerns have been addressed:

• Cloud webhook provider changes are now coalesced correctly while reconciliation is already running, including a deterministic regression test covering a provider change during an active reconciliation pass.
• The binding now uses openHAB's shared Jetty HttpClient through HttpClientFactory for both the Rachio API and image proxying, with focused transport and error-handling tests.
• The restored test sources now use the actual author instead of the openHAB Contributors placeholder.

The restored and newly added tests provide good coverage of the concurrency, lifecycle, webhook, HTTP transport, discovery snapshot, and handler behavior discussed during the earlier reviews. The current CI build is also green.

AI found no further issues in the current changes.

A final human maintainer review is still needed before merging.

Previous AI review concerns have been addressed. Human maintainer review is still required.

[wborn]

Great! Now we need to find some humans who want to review ~30k lines of AI generated and reviewed code. 😄

[kovacsi2899]

Just to clarify the size and the AI point: this is a complete new binding covering controllers, zones, schedules, Smart Hose devices, discovery, webhooks, metadata, and extensive regression tests. Contains much more functions then the original Rachio binding. Of the roughly 30k lines, about 11.5k are tests and 1.9k are resources. I wrote the binding itself; I used Copilot later as an additional review tool to surface edge cases and the kinds of issues automated review might flag, then verified and tested the resulting changes.

[robnielsen]

Here are a few quick code review recommendations and suggestions for minor polish:

[wborn]

Just to clarify the size and the AI point: this is a complete new binding covering controllers, zones, schedules, Smart Hose devices, discovery, webhooks, metadata, and extensive regression tests. Contains much more functions then the original Rachio binding.

That sounds very comprehensive and also explains why the PR has become so large.

Regarding AI, I think we should all be making use of it nowadays where it helps us become more productive.

Could you update the PR description with a short summary of what the binding now provides, and add a link to the Rachio community discussion?

It would also be nice to provide a JAR with the latest changes so users can easily test all the latest changes. I'll also give it a try myself when I find some time, although I don't have any Rachio devices to test the actual device integration with.

[kovacsi2899]

Just to clarify the size and the AI point: this is a complete new binding covering controllers, zones, schedules, Smart Hose devices, discovery, webhooks, metadata, and extensive regression tests. Contains much more functions then the original Rachio binding.

That sounds very comprehensive and also explains why the PR has become so large.

Regarding AI, I think we should all be making use of it nowadays where it helps us become more productive.

Could you update the PR description with a short summary of what the binding now provides, and add a link to the Rachio community discussion?

It would also be nice to provide a JAR with the latest changes so users can easily test all the latest changes. I'll also give it a try myself when I find some time, although I don't have any Rachio devices to test the actual device integration with.

I have edited the description of the PR added summarized info of binding functionality.
I update now community thread with link of this PR and latest jar as well.
I have added corresponding links into the PR descrirption as well.

[robnielsen]

I just noticed this in my openhab.log file with the latest code:

2026-08-09 23:48:45.681 [INFO ] [internal.handler.RachioDeviceHandler] - Home: Status WEATHER_INTELLIGENCE_NO_SKIP for schedule : NO_SKIP_NOTIFICATION_EVENT (start=2026-08-10T05:42:45Z, end=, duration=0min)
2026-08-10 00:42:48.614 [INFO ] [o.internal.handler.RachioZoneHandler] - Home[2]: Zone West STARTED watering (2026-08-10T05:42:46Z).
2026-08-10 00:42:48.618 [INFO ] [internal.handler.RachioDeviceHandler] - Home: Status SCHEDULE_STARTED for schedule : SCHEDULE_STARTED_EVENT (start=2026-08-10T05:42:47.599Z, end=2026-08-10T07:33:07.599Z, duration=110min)
2026-08-10 00:54:35.013 [INFO ] [o.internal.handler.RachioZoneHandler] - Home[2]: Zone West STOPPED watering (timestamp=2026-08-10T05:54:32Z, current=0, duration=706sec/11min, flowVolume=0).
2026-08-10 00:54:35.151 [INFO ] [o.internal.handler.RachioZoneHandler] - Home[3]: Zone Back - SW STARTED watering (2026-08-10T05:54:33Z).
2026-08-10 02:21:22.950 [INFO ] [o.internal.handler.RachioZoneHandler] - Home[3]: Zone Back - SW STOPPED watering (timestamp=2026-08-10T07:21:20Z, current=0, duration=5208sec/86min, flowVolume=0).
2026-08-10 02:21:23.021 [INFO ] [o.internal.handler.RachioZoneHandler] - Home[2]: Zone West STARTED watering (2026-08-10T07:21:22Z).
2026-08-10 02:33:09.444 [INFO ] [o.internal.handler.RachioZoneHandler] - Home[2]: Zone West STOPPED watering (timestamp=2026-08-10T07:33:07Z, current=0, duration=706sec/11min, flowVolume=0).
2026-08-10 02:33:09.635 [INFO ] [internal.handler.RachioDeviceHandler] - Home: Status SCHEDULE_COMPLETED for schedule : SCHEDULE_COMPLETED_EVENT (start=2026-08-10T05:42:45.617Z, end=2026-08-10T07:33:05.617Z, duration=110min)

There are 34 places where INFO logging is occurring, these all should be changed to DEBUG.

[kovacsi2899]

Thanks Rob,
I have updated the code and the jar on the link. You can give another try and check logging. My one was set to trace and I was not aware.