[rachio] Initial contribution -

[kovacsi2899]

No description provided.

[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.