New OpenSprinkler User – My initial experience

[DaveC]

I am replacing an Irritrol PC controller with OpenSprinkler. My system has 24 stations of varying types (sprays, rotors, and drips) servicing lawn, established trees and scrubs, and some new planted areas

As was true with the Irritrol system, it is important to understand the schedule’s capabilities and limitations to achieve what you want or change your use model to align with what the scheduler allows. While I have more to learn about what I can do with the scheduler, I was able to build a schedule comparable to what I’ve been using in about an hour. I checked it using the program preview and spotted an error which was easily corrected. OS has been running on the bench for 2 days and I am monitoring the log to see that the program is doing what I intended. Assuming no errors for a week, I’ll make the controller switch this weekend.

I’m also integrating OS with my home’s Crestron automation system. I’ve started working on the software to connect them. My automation system does not have http or JSON libraries, but after a quick Wireshark I learned the details of what OS expects. Simple communication is working though I have a bit of work yet to build a JSON parser for the responses.

Bottom line: Easy to set up and get working from both a homeowner and developer perspective. Thanks Ray and Samer. Nice product!

The following are a few minor items from my initial setup experience:

The OS case does not have all the labels that the directions show: No ‘Power’ or ’24VAC’ labels.

I have an zone expander. Both UI’s indicate 8 zones in the opening page. I immediately thought that I had a problem since it didn’t see the other 16 zones. I eventually made my way to Options -> Station Handling. There I saw that 24 stations were ‘available’, but only 8 were selected in the parameter. Once I choose 24, everything was OK, though I thought it was odd that I was also presented with choices for 32, 40 and 48. I think it would be more intuitive for most installations if the default was the opposite. I.e. All ‘Available’ stations would be seen and usable at the start. If you want to constrain the usable stations you could change the parameter.

I installed the Mobile app on 4 different devices. By default the name wraps differently on them:
Galaxy S6 and Galaxy S3 The name wraps by 1 character (I.e. the last ‘r’ is on its own line)
Galaxy Tab3 – The name wraps by 2 characters
Galaxy Tab4 – No wrap

Initially I let OS use its default DHCP setup and I used the scan method to connect each mobile device. After seeing that everything was working correctly, I changed my router to have a DHCP reservation for the OS. This address was different than the one that was provided initially. I restarted the controller to pick up the new address, BUT I had to manually reset the address in every mobile device from the original DHCP address to the new one. I wasn’t expecting that the address found by the mobile app scan would be saved. I had connected multiple times from some of the devices and each time I was presented with a choice for how to find the OS address. This led me to think that that address was not being retained by the mobile app. But it apparently it did remember it since the change of OS address resulted in an error when the mobile app was started, scan was no longer a choice to find the address and the address in the Manage Sties section was the original one.

[Samer]

Hi David,

Thank you for sharing you experience as this is valuable information to improve the product!

In regard to the labeling on the case, I think Ray would be best to address this however I will touch on the software issues you mentioned.

The expansion boards have historically been managed by the user and the firmware will never modify the station capabilities. The reason is because the firmware has a concept of “virtual stations” which can be used for mainly RF stations right now but will also allow remote stations in the future (stations on a separate OpenSprinkler controller).

For the program name, I used to have it named Sprinklers to avoid the wrapping of the long name. Unfortunately, that adds some confusion and doesn’t help the name association so it was changed. Unfortunately, I don’t think there is much I can do on this front.

The app does save the IP and works by communicating directly (currently no cloud option). When the app scans, it’s just scanning your local network (all 255 IPs) and showing you any NEW OpenSprinkler device it finds. If the IP changes, or you want to add another site: you can open the left side panel (swipe right) and hit “Manage Sites”. This will open the site manager page and on the top right corner is an Add button. This will either open the manual entry popup or, if scan is available, show you an option to scan or manually add a device. This is what you are needing to rescan or you can just replace the IP with the reserved IP you put in your router.

Thanks again.

[DaveC]

Hi Samer,

Re: Long name
A couple of apps that I use have long names. They are displayed in 2 lines. The line wraps are not random so there must be a way to make the wrap work either by inserting a <CR> or adding spacing before and after to the first part to cause the wrap where you want it. Just a suggestion… you could have ‘Open’ on the top line followed by ‘Sprinker’ on the second line.

Re: Changing the controller address
It did replace the address once I realized what the behavior was but it was not intuitive, at least to me. Since the app would give me the scan or set manual popup each time I started it (with the original address), it felt like it was not being saved. Since it knew ‘an’ address after the initial scan why didn’t it give me the option to just connect? Knowing that I was going to change its address to the reserved one, I left it in this temporary (or so I thought) state, i.e. scanning at startup. Once I changed the address, I expected the app to give me the same scan or manual pop-up that it had been giving so I could now chose manual and set it, but it gave me an error instead. My point here is just so you understand why I had the expectation that I did. I got to the right steps but not as quickly as it could have been.

Thanks

[Ray]

@David: thanks for sharing your experience.

1) Regarding the label on the case: the missing ‘Power’ and ’24VAC’ labels are intentional. We are transitioning to use DC powered circuit, so in the future the power supply to OpenSprinkler will be 9VDC (instead of 24VAC). Although it’s powered by DC, it can still work with 24VAC sprinkler solenoids. The main reason to switch to DC powered circuit is that it makes the the controller compatible with both standard 24VAC solenoids as well as other types of DC solenoids. In addition, for international customers, DC power supplies are much easier to source than AC transformers. Due to this reason, the enclosures have removed the ’24VAC label’. But I admit that it should probably at least have a ‘Power In’ label or something that indicates the purpose of that port.

The ‘Power’ label used to be for the power switch. In the future we are planning to remove the power switch, and instead make that port a connector for flow meters/sensors. Due to this reason, the label ‘Power’ has been removed too.

2) Regarding the need to select the number of stations — this is just due to historic reason. Older versions of the controller were not able to automatically detect the number of stations on the expansion boards, so we left this as an option for users to select. Also, as Samer said, because OpenSprinkler supports RF (radio frequency) stations, users may want to set a larger number of stations than physically available. In the future we may consider splitting the virtual stations into its own group, so that they won’t be mixed with the physical stations.

[DaveC]

Thanks for the explanation about the labels. I figured it wasn’t accidental but it’s nice to know why and where things are headed.

RE: number of stations
Being able to to select more stations than the physical set makes sense. I do think it would be easier for some users if either the initial (out of the box) default for physical stations was to enable all that were found (i.e. opposite of what it is now) OR if a note was added to the Getting Started Guide that tells people that they have to go set this if they have an expander.

Another out of the box simplification would be to prompt the user for Location OR add a reminder to the Getting Started Guide to remind people to set it. Its great that NTP is on by default but you still need to set your location to get the time right.

I know that both of these items are listed in the user manual but only in their reference form. If these 2 items had behaved as I described or were in the Getting Started Guide, my out of the box experience would have be perfect. I.e. I plug in the expander card, plug in an Ethernet cable, turn power on, point the browser or mobile app at it, it prompts for location (or reminds me to do it) and done, it’s ready to program. I understand that different users have different views, I’m just sharing mine FWIW.

Thanks again. I’m very happy with the product, and so is my wife (also a techie)… and she absolutely hates the system we’re replacing.

[Samer]

Hi David,

I agree 100% in regard to the intial setup of the device. My idea is very simple: the firmware has a variable for “new device” which on first startup is true and after the first request of controller data (for example /jn), the flag is set to false and that’s it.

Then the app can use this flag and if true, open a special page which allows guided walkthrough of important configuration (such as location) or allow an option to import backup, or skip and goto home page (as it does now). This would be a one time thing that only occurs if the “first time” flag is true. I am still discussing this with Ray but I think it offers what you are asking for while giving a bit more guidance to new users.

Let me know what you think with the system proposed above.

Thanks!

[DaveC]

Hi Samer,

I like your approach. The result will be similar to what users are used to other consumer devices when they first install them. i.e. little hand holding to get them to a base usable state quickly.

A little detour to explain why I’m interested in this aspect of the product…
When I decided to go with the Irritrol system back in ’05 (sounds like a long time ago), the irrigation contractor that was installing my system was interested in the product’s concept of being able to manage schedules on a PC and load them into the controller. It would be easier for him to manage the part of his customer base that relied on him to maintain their system. Other, more tech-savvy types, might like it too. He and I tested it to see if it was easy enough, functional enough and reliable enough for him to sell. Well, it wasn’t. It was not too easy to configure and the PC software to manage it was buggy and unreliable. The one great feature it had that we’ll miss, is the dirt and water resistant remote. Mobile device are great but they’re not as easy to use with gloves on nor as tolerant of dirt and water. Since that time I’ve looked for a new solution. I’ve considered a few, but none met enough of the my requirements… until OS. I still work with the same contractor for any significant changes to my system. Once I get a little more experience with OS, I’m going to show it to him. So far I think it is easy enough and functional enough for him.

Thanks

[Author]

Posts