Orbit Sprinkler Timer (Iris)

worth trying - a plug-in 3 or 5VDC supply, plugged into a Zwave plug. I’d try monitoring the voltage while it’s plugged into the original timer, and assuming the voltage doesn’t get weird, then move it to the Zwave plug supply.

You’d have to poke holes in the plug to monitor it, or otherwise get at the pin voltage. Or you could just try it anyway.

This makes your sprinkler depend on the cloud. Is it a disaster, if it waters continuously until someone gets home to turn it off manually?

@ero4444 @flavorthirty
I would be interested in this solution. Does anyone know what voltage the orbit extra valve actually takes?

The connector for the orbit extra valve, is it a standard form factor plug that I can find on amazon?

The smartthings power plug and lowes iris plug operate local so not dependent on cloud.

Aeon zeave may operate local, can anyone confirm if the aeon zwave plug operates local when using the built-in device handler?

I’d also be very interested in trying your app out!

You should be able to download the code from here; https://github.com/jrbmobile/Water-The-Garden

You’ll want to sign-up for a dark sky account for rain prediction control and I still haven’t had time to modify for multiple valves and switches based on moisture sensors, other than that it works well except with an Orbit timer :frowning: I haven’t seen anyone yet that has made Orbit work correctly, but if you’ve read the threads it’s probably a proprietary issue. Orbit works flawlessly with Iris but no joy on Smartthings. The GE outdoor outlet controls power the sprinkler valve via a doorbell transformer and is a cheaper solution.

Regards

is the issue where it keep cloning itself resolved?

I’m using the gussery DTH and I’ve never had that issue. This is one of my favorite devices and I’m on the market for two more. If anyone hates this device, I’ll take it off your hands for the right price.

Anyone else is getting -233% battery left notifications? I started getting bombarded with it yesterday. Had the device for 2-3 weeks and was working more or less ok.

well I put mine back into the system. Here is hoping for the best

1 Like

Just blasting commands at this thing and hoping one of them sticks is laughable, but it does kind of work. Honestly a product like this never should have made it to market, but whatevs.

So you mentioned previously that you’re able to reset the devices default timeout? How do you do that?

It works for me. Runs my sprinkler 3x a day for 15 min each - assuming it hasn’t rained recently.

Sorry, can you refresh my memory?

Keep in mind it wasn’t made for SmartThings.

1 Like

Well you just said you can run the sprinkler for 15 minutes but the default is 10m. Are you able to set this option via CoRE? All I see is open/close or on/off.

Also how many times do you have to send the open or turn on command for it to stick reliably?

Can you post a picture of your piston?

Ok well, this kind of seems to work. It’s not quick or anything, and I can’t seem to change the default 10 minute timeout, but I can more or less turn on/off the sprinklers.

This piston is triggered by a virtual switch. This way I can toggle the sprinklers manually, schedule them from another piston, or access them via a friendly name in Alexa.

I’d love any feedback about how to control the Orbit run time via CoRE (or in this case WebCoRE), and also any tips on number of commands I need to send and how frequently to dispatch them. Right now, as you can see I’m running every 10 seconds for 12 cycles. This has worked every time eventually, though it’s not quick and I’ve only tested 2 or 3 times. I’m sending both an “open” and a “turn on”. I’m not sure which is best or if they do the same thing, but I figured if I’m blasting it with commands hoping something will stick, why not send both?

Thanks-

Each time you send the on command it starts the 10 min timer. Send the on command for 5 minutes. Once you stop sending on events, it will turn off in 10 more minutes. I’m not actually doing this anymore, but it does work. The reason I stopped was because there came a time where I wanted to stop the sprinkler immediately.

I haven’t bothered to try to figure this out.

Just like you I’m using a virtual switch. I’m certain that repetitive 20 second timers are frowned upon. But regardless here is my piston, I haven’t gotten around to moving it to webCore yet. When I do I’ll try to figure out a reliable minimum of spams to get the desired behavior. Using cycles like you did is probably smarter than how I did it.

what does sprinkler valve forcer do?

That is the name of the piston I posted

Oh so it just runs itself again? You do that for 5minutes and then let it finish out a full run for 15 total?

Again, I run mine do mine 12 times with a 10 sec wait between runs. So if it doesn’t start in 2 minutes it gives up. I haven’t had a run fail yet, on either start or stop. If the stop fails, worst case is it stops in 10min when the orbit timer runs out, so no stuck open valve. I suppose there could be an incident where the batt dies with the valve open, but that was also true for the standalone timer valves I’ve been using for the last few years.

Every year I forget to bring these things in for the winter and come back in the spring and they leak everywhere.

You are going to LOVE WebCoRE!

1 Like

I used to do it for 5 min then let it run out at 15. But there ended up being a few times where I wanted it to stop immediately. so I modified the piston to it’s current state.

Currently - when the corresponding virtual switch is on (per scheduling apps) it spams on, when it is off - it spams off.

I’ll change that when I move it to webcore in the near future. I like your idea of maybe 5 runs being effective enough.

Orbit Hose Timer data dump:

TL;DR- This device is flawed and if there’s anyway you can avoid buying it, I’d suggest doing so. The key problem is that it has severely limited zigbee range. Within a few feet of a hub or repeater it seems to work fine, but more than 10-15 feet it becomes erratic or doesn’t function at all.

I have now spent three days trying to get two of these devices to work I’ve tried them with both SmartThings and Iris hubs, and using both the gussery3 and SmartPower Outlet Device Handlers. The range limitation is common to both hubs.

Of the 2 device handlers in Smartthings, the SmartPower Outlet handler works better. It at least reports correct state and seems to respond a little quicker… when its working that is. For example when you first switch to this DH, the icon in the ST app will switch from open/close to on/off. As soon as you press this button for the first time however, you’ll be stuck in “turning on…” for a good 15 minutes. Finally the device will right itself and begin responding. This odd pause/stuck behavior may return for reasons that I’ve yet to determine, or it may simply be masked by the fact that I’m blasting commands at it.

Because of this weirdness, I’ve wrapped both of my Orbit devices with a simulated switch. This switch then controls a piston that sends a barrage of start and stop commands to the valve. I’ve had good luck so far with a loop of 6 commands spaced 10 seconds apart. It would take a great deal more time and testing to optimize this setup and I don’t really feel like spending any more hours on this.

My setup basically looks like:

foo.valve -> the device itself using the SmartPower Outlet device type
foo.switch -> a simulated switch created in the IDE console
foo.controller -> a WebCoRE piston that fires a set of commands at foo.valve based on foo.switch state
foo.scheduler -> a WebCoRE piston that turns foo.switch on and off at designated watering times

Note that you can not control the watering time with ST. When the device receives an on command it will start for 10m. You can configure this from the Iris interface but not ST. If you need longer watering times you’ll have to configure multiple start events.

As I said, I bought an Iris hub just for these devices. I figured that the $69 to get my sprinklers working was worth it given the cost of a full blown smart watering system. These devices are discovered and pair with Iris quite easily. The firmware then updates for 20-30 minutes, at which point they become fully useable. As a side note, upon switching these devices back to ST I’ve noticed no improvement in their handling with the new firmware.

Anyway, the whole IRIS process is pretty smooth, and unlike in ST the water time can be scheduled from the app. ST with WebCoRE is much better at configuring complex actions of course, but my plan was to hook my hose timers up to Iris and then trigger them from ST via IFTT or something.

I didn’t get that far because as soon as I moved my IRIS hub to its final location, the devices didn’t work any better than they did with ST. At that point I figured that I could add the devices back to ST, return the Iris hub, and with the $69 from the return, buy 2 Iris smart plugs to uses as zigbee repeaters and I’d be in better shape.

In summary, I have two Orbit hose timers setup. It took many more hours than it should have to get them to a state where it seems like they work, and I still don’t quite trust their reliability. They only turn on if I blast multiple commands at them, and all in they cost double what they appear to because of the need to add zigbee repeaters to my network, though one could argue that there is benefit to those beyond the Orbit valves.