Rachio Smart Sprinkler Controller

kovacsi2899 · May 30, 2026, 6:35am

New release is published:

Main focus:

existing controller / zone / schedule compatibility
canonical Flex Schedule Thing type: rachio:flex-schedule
no support for temporary development-only rachio:flexschedule Things
reduced repeated API calls during Item REFRESH
previous throttling fix must remain stable
webhook behavior should not regress

This removes API overload in some cases. Now binding should run smoothly. I will continue with testing of newly added items and units for the zones.

Any log about issue would be welcomed.

pleedell · May 31, 2026, 2:08pm

Not seeing much, here is debug log of rachio binding for example. I’ve tried disabling/re-enabling the bridge and also a zone thing but not seeing anything resembling an error/warning or even a channel reference. Any advice on additional steps to get you better info?

2026-05-31 08:00:11.038 [DEBUG] [rachio.internal.RachioHandlerFactory] - RachioHandlerFactory: Create thing handler for type rachio:zone
2026-05-31 08:00:11.041 [DEBUG] [rachio.internal.RachioHandlerFactory] - Zone handler created: thingUid=rachio:zone:fab4def67a:7087A78D171C-1, bridgeUid=rachio:cloud:fab4def67a
2026-05-31 08:00:11.057 [DEBUG] [o.internal.handler.RachioZoneHandler] - Zone initialize entered: thingUid=rachio:zone:fab4def67a:7087A78D171C-1, bridgeUid=rachio:cloud:fab4def67a, configured zoneId=‘f1a34ac3-9486-4cef-91f1-44d62ae31d9b’
2026-05-31 08:00:11.059 [DEBUG] [o.internal.handler.RachioZoneHandler] - Zone parent bridge resolved: thingUid=rachio:zone:fab4def67a:7087A78D171C-1, bridgeUid=rachio:cloud:fab4def67a, bridgeOnline=true
2026-05-31 08:00:11.061 [DEBUG] [inding.rachio.internal.api.RachioApi] - getZoneByUID: mapped requested zone UID ‘rachio:zone:fab4def67a:7087A78D171C-1’ to Rachio zone ‘Front Lawn (1)’ using configured zoneId ‘f1a34ac3-9486-4cef-91f1-44d62ae31d9b’
2026-05-31 08:00:11.063 [DEBUG] [o.internal.handler.RachioZoneHandler] - Zone model lookup succeeded: thingUid=rachio:zone:fab4def67a:7087A78D171C-1, zoneId=‘f1a34ac3-9486-4cef-91f1-44d62ae31d9b’, zoneName=‘Front Lawn (1)’, controllerId=‘04e732b0-5389-44c7-94ec-ac615b090da5’
2026-05-31 08:00:11.064 [DEBUG] [o.internal.handler.RachioZoneHandler] - Rachio-8D171C[1]: Zone status set ONLINE
2026-05-31 08:01:56.847 [DEBUG] [rachio.internal.RachioHandlerFactory] - Removing Rachio handler
2026-05-31 08:03:17.952 [DEBUG] [internal.handler.RachioDeviceHandler] - Update for device ‘04e732b0-5389-44c7-94ec-ac615b090da5’ received.
2026-05-31 08:03:17.955 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler RachioDeviceHandler of thing rachio:device:fab4def67a:7087A78D171C tried updating channel lastUpdate although the handler was already disposed.
2026-05-31 08:03:17.956 [DEBUG] [internal.handler.RachioDeviceHandler] - Updating device status
2026-05-31 08:03:17.959 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler RachioDeviceHandler tried updating the thing status although the handler was already disposed.
2026-05-31 08:03:40.893 [DEBUG] [rachio.internal.RachioHandlerFactory] - RachioHandlerFactory: Create thing handler for type rachio:device
2026-05-31 08:03:40.913 [DEBUG] [internal.handler.RachioDeviceHandler] - Initializing Rachio Thing ‘rachio:device:fab4def67a:7087A78D171C’.
2026-05-31 08:03:40.915 [DEBUG] [internal.handler.RachioDeviceHandler] - Resolving Rachio controller Thing ‘rachio:device:fab4def67a:7087A78D171C’ by configured deviceId ‘04e732b0-5389-44c7-94ec-ac615b090da5’
2026-05-31 08:03:40.916 [DEBUG] [inding.rachio.internal.api.RachioApi] - Mapped requested device UID ‘rachio:device:fab4def67a:7087A78D171C’ to Rachio device ‘Rachio-8D171C’ using configured deviceId ‘04e732b0-5389-44c7-94ec-ac615b090da5’
2026-05-31 08:03:40.918 [DEBUG] [internal.handler.RachioBridgeHandler] - RachioCloud: No callbackUrl configured.
2026-05-31 08:03:40.920 [DEBUG] [internal.handler.RachioDeviceHandler] - Updating device status
2026-05-31 08:03:40.923 [DEBUG] [inding.rachio.internal.api.RachioApi] - Load current schedule for device ‘04e732b0-5389-44c7-94ec-ac615b090da5’.
2026-05-31 08:03:41.094 [DEBUG] [internal.handler.RachioDeviceHandler] - Rachio-8D171C: Loaded current schedule for controller ‘04e732b0-5389-44c7-94ec-ac615b090da5’: running=false, id=‘’
2026-05-31 08:03:41.095 [DEBUG] [inding.rachio.internal.api.RachioApi] - Load forecast for device ‘04e732b0-5389-44c7-94ec-ac615b090da5’ using METRIC units.
2026-05-31 08:03:41.205 [DEBUG] [internal.handler.RachioDeviceHandler] - Rachio-8D171C: Loaded forecast for controller ‘04e732b0-5389-44c7-94ec-ac615b090da5’ using METRIC units
2026-05-31 08:03:41.206 [DEBUG] [inding.rachio.internal.api.RachioApi] - Load device events for device ‘04e732b0-5389-44c7-94ec-ac615b090da5’ from 1780149821206 to 1780236221206.
2026-05-31 08:03:41.307 [DEBUG] [inding.rachio.internal.api.RachioApi] - Loaded 5 device events for device ‘04e732b0-5389-44c7-94ec-ac615b090da5’.
2026-05-31 08:03:41.308 [DEBUG] [internal.handler.RachioDeviceHandler] - Rachio-8D171C: Loaded 5 recent controller events over 24 hours
2026-05-31 08:03:41.309 [DEBUG] [internal.handler.RachioDeviceHandler] - Updating device status
2026-05-31 08:03:41.310 [DEBUG] [internal.handler.RachioDeviceHandler] - Rachio-8D171C: Device Rachio-8D171C initialized.

kovacsi2899 · June 2, 2026, 4:46am

kovacsi2899 · June 2, 2026, 4:46am

I have uploaded a new test build from the current PR-clean branch.

This build includes the latest cleanup and fixes:

Cloud Connector-only configuration
final flex-schedule Thing type
schedule start-time handling from startDate
command-only moistureLevel/moisturePercent handling
safer logging
Rachio servlet lifecycle cleanup

Could you please test this build instead of the earlier one?

The most useful checks would be:

Cloud, controller, zones, schedules and flex-schedules come ONLINE.
Existing Items update correctly.
Disable/re-enable a zone or controller Thing and check whether the “handler was already disposed” warning still appears.
If configured, webhook registration is retained and not duplicated. Your log shows that webhook is not configured.
Please send the Rachio log around startup and the disable/re-enable test.

pleedell · June 4, 2026, 10:13am

Thanks. I don’t have webhooks configured. I’ve enabled debug for the binding and restarted my OH instance to produce the following:

openhab.log (158.7 KB)

kovacsi2899 · June 13, 2026, 8:25am

New version is published. Polling behaviour is improved. Webhook is still under testing. Items needs to be recreated as official naming convetion of Openhab is implemented. It was necessary for official binding implementation.

pleedell · June 13, 2026, 4:29pm

New version working fine. I did go and recreate all things as well as items but no issues seen yet.

Thx!

kovacsi2899 · June 13, 2026, 4:33pm

I’m working on finding why webhook is not working. It does not influence binding functionality as polling works in default 120 secoonds. I hope I can fix webhook, then we can increase polling interval.

kovacsi2899 · June 17, 2026, 8:00pm

new release is here: Release PR release · kovacsi2899/openhab-addons · GitHub

legacy webhook is implemented. next will be new webhook development for new functions, dasboard for easy use of binding

kovacsi2899 · June 25, 2026, 7:02pm

(post deleted by author)

kovacsi2899 · June 25, 2026, 7:05pm

New version uploaded:

pleedell · June 27, 2026, 12:37am

I’ve been on version r41 for some time with no issues. Tried the new version above and it won’t initialize for me, shows waiting status in the karaf console. Tried a restart with cache clear, no change. Also removed and re-added the new version with no effect. I then went back to r41 and it worked fine just as before.

Does the new version installation require anything additional?

kovacsi2899 · June 27, 2026, 4:59am

What is you Openhab version? It uses new feature of openhab webhook what was implemented in 5.2 in mid-May. I planned that it should not be problem if you use earlier version. I have kept legacy webhook and implemented new webhook for that purpose. If somebody uses earlier version of OH do not lose all webhook features. R41 was the version what requires delete and add all things and items, and normally this is not needed in later version as it is working on my system since then. Can you share trace log when binding is starting up? You personal data and keys will be not part of the log. It is removed during logging process. When you clear the catch, we empty 2 folders catch and TMP. Then OH restart all settings from scratch. It does not delete your item values what is saved during OH stop.

pleedell · June 27, 2026, 10:00am

Gotcha, thanks. I’m still on production release 5.1.4 so if that’s the issue I’ll wait until the production 5.2 release. Shouldn’t be long

Cheers

kovacsi2899 · June 27, 2026, 12:35pm

Yep, but would be good if you can send me the log, as normally it should not be an issue. I’d like to check as may be I need to fix someting in binding init process.

pleedell · June 27, 2026, 8:00pm

Can do, see attached. I removed r41, confirmed it was removed in the console, re-added the new 5.2 version.

openhab.log (266.1 KB)

kovacsi2899 · June 28, 2026, 4:56am

Many thanks for the log! It shows the binding fails before bridge initialization, during OSGi/SCR component instantiation.

Root cause:
RachioHandlerFactory directly references org.openhab.core.io.rest.WebhookService. That type is not available in the 5.1.4 runtime, so the class loader throws NoClassDefFoundError while instantiating the ThingHandlerFactory. Because the ThingHandlerFactory service never becomes available, discovery and Thing initialization cannot proceed.

So we need to improve backward compatibility and this is a very important test.

I will fix this by removing the direct WebhookService/Webhook type dependency from the core binding classes and moving WebhookService access behind a compatibility/reflection adapter. On runtimes where WebhookService is unavailable, the binding should still start and use legacy webhook/polling behavior; on newer runtimes, the modern WebhookService integration can still be used.

I will come back with an updated version soon, you can test it on 5.1.4. May be fix will come in 2 stage and I will ask you to test if you do not mind step by step.

kovacsi2899 · June 28, 2026, 7:12am

Dear Joe,

Can you try this version? Binding start up fixed. Legacy webhook should work for you and polling in that version.

This is set of new webhook. For legacy webhook, you need to switch off all, fill callback url, user and password fields, and save. You can change and save when thing is active. Then you can deactivate, switch on clear callback, and binding will clear webhook registry. For normal use you can keep it off. We need it temoprary when webhook needs to re-register.

pleedell · June 28, 2026, 6:22pm

Done, the new version starts up fine for me with no errors now (to confirm I’m on 5.1.4 OH release). I haven’t used the webhooks.

kovacsi2899 · June 28, 2026, 6:45pm

If you set Callback URL: https://home.myopenhab.org/rachio/webhook

Your openhab cloud user as Callback Username and cloud password as Callback Password, legacy webhook will work. Now all weather items work and receive values in polling process. You can use almost full functionality of Rachio API with that version.When you upgrade to 5.2 then you wil be able to use new webhook, It works for me in that binding version.