Oh cool! I didn’t realize Simple Sprinklers was released.
2 Likes
Some folks on the ST community have been chomping at the bit waiting on it and I saw the Smartest House mentioned it was finally released. Nice work and great idea for that multi relay. Years ago I had bought all the components for an Arduino based relay sprinkler system but then decided to buy a Rachio instead.
1 Like
Really? Got a link? 
1 Like
Starts here:
3 Likes
Dang! I’ll monitor that thread. I had just assumed their staff were the people testing it 
3 Likes
I bought a few for those devices from that ebay seller, but I can't get them to fully work with Hubitat and the built in driver. They will join the network, their time gets set, and if I use the manual button on the device then Hubitat can see it was on and off, but I can't get Hubitat to do any type of control. Anyone recently bought the devices and have you had any better luck?
I bought one from (presumably same guy) on ebay too. I only did a brief (waterless) test, but mine seem to work OK. I cycled it via the device page, and by a very simple rule (basically on/off after a minute. The time set immediately and I was surprised it was automatic.
I think you have to be in Auto mode, is that what you are using?
I'm in auto mode, I bought 3 of them, I've only paired 2 so far. Both of them didn't get the Orbit Hose driver initially and I had to manually set it. It felt like the 'Initialization' phase of the zigbee join timed out (or took a long time).
I'm not seeing the states most folks are reporting.
They do pick up the correct time from the zigbee network.
Press configure in the device page?
Tried it, no effect.
Zigbee logs:
Water Timer A2020-05-18 22:06:41.087 profileId:0x104, clusterId:0x20, sourceEndpoint:1, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-64
Water Timer A2020-05-18 22:04:53.101 profileId:0x104, clusterId:0x6, sourceEndpoint:1, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-64
Regular logs:
dev:3532020-05-18 06:25:55.042 pm warndebug logging disabled...
dev:3532020-05-18 06:24:51.071 pm debugParse: catchall: 0104 0020 01 01 0040 00 5066 01 00 0000 00 01
dev:3532020-05-18 06:23:45.096 pm traceReceived on/off report
dev:3532020-05-18 06:23:45.088 pm debugParse: read attr - raw: 50660100060800001000, dni: 5066, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00
dev:3532020-05-18 06:22:50.115 pm debugParse: catchall: 0104 0020 01 01 0040 00 5066 01 00 0000 00 01
dev:3532020-05-18 06:20:49.082 pm debugParse: catchall: 0104 0020 01 01 0040 00 5066 01 00 0000 00 01
dev:3532020-05-18 06:18:48.067 pm debugParse: catchall: 0104 0020 01 01 0040 00 5066 01 00 0000 00 01
dev:3532020-05-18 06:18:36.089 pm traceReceived on/off report
dev:3532020-05-18 06:18:36.083 pm debugParse: read attr - raw: 50660100060800001000, dni: 5066, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00
dev:3532020-05-18 06:16:47.075 pm debugParse: catchall: 0104 0020 01 01 0040 00 5066 01 00 0000 00 01
dev:3532020-05-18 06:14:46.071 pm debugParse: catchall: 0104 0020 01 01 0040 00 5066 01 00 0000 00 01
dev:3532020-05-18 06:13:28.096 pm traceReceived on/off report
dev:3532020-05-18 06:13:28.088 pm debugParse: read attr - raw: 50660100060800001000, dni: 5066, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00
dev:3532020-05-18 06:12:45.094 pm debugParse: catchall: 0104 0020 01 01 0040 00 5066 01 00 0000 00 01
dev:3532020-05-18 06:10:44.090 pm debugParse: catchall: 0104 0020 01 01 0040 00 5066 01 00 0000 00 01
dev:3532020-05-18 06:09:12.006 pm debugopen(time) with 10
dev:3532020-05-18 06:09:11.998 pm debugopen()
dev:3532020-05-18 06:08:43.073 pm debugParse: catchall: 0104 0020 01 01 0040 00 5066 01 00 0000 00 01
dev:3532020-05-18 06:08:19.099 pm traceReceived on/off report
I don't see anything obvious, but I am not much of an expert beyond punch button here, see what happens there type thing.
Your RSSI looks OK to me though, lower is better. Mine is -74 and it works fine. Most things on my network are much better than this (low to mid 50s to mid 60s), but I have it in a bad spot in a closet right now. So I don't think you have a location issue, or repeater issue.
They do take a very long time to initialize while pairing. If that isnt completed they will appear paired but will NOT work, period. Remove, re-pair and walk away. Make fresh ground coffee, eat a bagel with cream cheese (and smoked salmon 
), make a pit stop... and then come back and see the screen. They also must be in AUTO mode to accept remote commands.
2 Likes
And as I said, mine takes approx 12 seconds to switch state - Open or Closed, from pressing the button on the driver page
2 Likes
For the remove & re-pair sequence, does the device need to be factory reset? Do all traces need to be removed from HE (what would those be?). Does the webpage that is showing the initialization need to be left up for the 'long time' while initializing?
Is there any half-joined to the hub state?
Currently the hose timer shows connected to the zigbee network, has the time set correctly, and when I use the 'Manual' button on the physical device I see state changes in the HE logs.
But, none of the commands sent from HE->hose timer seem to have any effect.
Any suggestions for a hose tap time for use with hubitat in Australia?
Is this the only orbit iris model# 27087 supported by hubitat?
For Linktap owners, I did my own driver for the Tap Linker product, should you want to try. It includes the ability to receive events/data from Linktap, apart from start/stop watering. More info here
Cheers
Mine does the same thing
@pedro.f.andrade I wonder if since the website states that these devices are zigbee if a local driver could be developed instead of cloud based integration?
No, unfortunately while they use zigbee as a transport, they're not using either ZHA 1.2 or Zigbee 3.0 as the profile. From the Link-Tap FAQ:
1 Like
Ughhh I hate that...
2 Likes
