[Ray]

Generally, you can create a program and set it to ‘disabled’ (i.e. enabled flag is off). This way it doesn’t matter how you program its day / time, the program won’t run normally, but it’s available to be triggered using buttons or sensor input as switch. To use buttons, you can press and hold button B3, to activate the ‘manual run’ program feature, there you can select any program (including those that are disabled) to run. To use sensor input (which you already know): the second sensor can trigger the second program. Again, if you set that program to disabled, then it won’t run normally, so you can set any day / time as you want.

[Ray]

Since the version that supports Ethernet module was only released in April 2019 (last year), if you bought your OS 3 after April last year you can purchase the module separately. Otherwise your controller most likely does not support Ethernet module. In any case, you can submit a support ticket with your order number so we can verify.

[Ray]

You can debug this way:
first, you need to stop the process from running in the background, which you can do by following:
sudo /etc/init.d/OpenSprinkler.sh stop

then, in the firmware source file folder, there is a file called “defines.h”, which has a macro define ENABLE_DEBUG
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/defines.h#L27
uncomment that line to enable command line printout. Next, re-compile the firmware by:
./build.sh ospi

finally, run it in command line by:
sudo ./OpenSprinkler
this will run the firmware manually, and it should print out debugging information.

Edit: just realized that after running ./build.sh ospi it might start the process in the background again. So if you encounter any problem running the firmware, you can do sudo /etc/init.d/OpenSprinkler.sh stop again to stop the background process.

[Ray]

If you haven’t done so, you can submit a support ticket attaching a copy of your configuration (i.e. the file saved from ‘Export Configurations’). I will check if we can reproduce the issue on the test OS.

The fact that it’s reporting ‘offline’ for Weather Service, and also the Last Response is empty seems to suggest there are other issues: Last Response being empty generally means the controller did not receive the result of the weather call. This could be due to your router blocking the incoming traffic (e.g. if you have set up a firewall etc.), or it could be the weather url has been changed and the weather server is unreachable. In any case, if you send us your configurations we can take a look and find out more.

[Ray]

You can submit a support ticket and provide your order number or order information. We can ship a spare SD card to you.

[Ray]

From the OS API document:
https://openthings.freshdesk.com/helpdesk/attachments/5114870617
section 4: it supports a command /cv with parameter rsn=1 to reset all zones (i.e. stop all zones). So in your case it would be:
192.168.1.113/cv?pw=XXXXXXXX&rsn=1

[Ray]

Did you check if the ‘Location’ you set is correct? The controller uses your location to obtain time zone automatically, so if the location is incorrect that will result in the time being different.

[Ray]

The language setting is cached in browser. So I think the easiest way is to open a private browsing window to access the controller, which will have all cached values in default settings. Also, you can clear browser cache (you don’t need to clear everything, just anything that has to do with the controller’s IP address).

[Ray]

This could be NTP sync problem but could also be a time zone problem (i.e. the controller wasn’t able to get time zone correctly using your location). To check any time zone issue: if your controller runs firmware 2.1.9 minor revision (2), you can check the system diagnostics (at the home page, swipe left to right to open the left side menu, then click on System Diagnostic). It will show when the last weather call was sent out and when the response was received. The time zone data is obtained through the weather call.

I noticed that you said on your OS, the NTP IP is 204.9.54.119 port 13650: is this a custom NTP server IP? I think the default NTP server is different. Also, where is port 13650 coming from? I think by default NTP uses port 123, I don’t think the controller even provides an option to configure NTP server port.

[Ray]

That’s a good question: I will check but I think this option is not visible in the user interface. On OS 3.0 or any controller that has LCD and buttons, this option can be configured manually using buttons and LCD. Usually this option is set this way: on the master controller, once you configure a remote zone, it will check the remote controller (based on the IP address you gave) to see if it’s in remote extension mode. If not, it will prompt you whether you want to set it to remote extension mode. That’s the dialog box you see. Later if you want to change the remote controller back to normal mode, you can go to the homepage of the remote controller, and it should have a red bar at the bottom indicating it’s in remote extension mode. You can click it to change it back.

The remote extension mode is a simple binary option that you can read or set through the HTTP API. However, it seems, as you observed, it’s not exposed in the UI so you can’t set it through the UI. This can certainly be changed in the future when we update the UI.

[Ray]

Technically it’s possible through the browser as long as you have a way to cache the javascript files. The reason to use app when the controller is in AP mode is that due to lack of Internet connection, the javascript files need to be accessible locally — the app embeds these so it will work fine. But there are also ways to cache them in a browser so you can use a standard browser as well.

We used to support browser apps (like Chrome apps) in the past, but over time such support has been dropped (for example, in recent news Google is discontinuing Chrome apps)

[Ray]

18 to 20 AWG should be sufficient for each zone wire. You are correct that in your case the common wire needs to be thick, because if you plan to run several vales at the same time, the entire amount of current has to run through the common wire, but the return path is through each zone’s corresponding zone wire, so the common wire needs to be quite thick. I believe 2.5mm^2 is sufficient for common. You can always use parallel connection to combine several thin wires to achieve the effect of a thicker wire.

[Ray]

OpenSprinkler does not require an access point to run — in fact, initially itself is an access point, allowing your phone or laptop to connect to it to set configurations. If you plan to use it in access point mode, just make sure to use the opensprinkler mobile app, and the device’s ip address is 192.168.4.1. Almost all functions will work in ap mode, except (for obvious reasons) any internet-dependent features like weather-based adjustment and NTP time sync (you can set device time manually).

[Ray]

Our entire code base is open-source. The weather adjustment methods are here:
https://github.com/OpenSprinkler/OpenSprinkler-Weather

[Ray]

Which version of firmware does your controller run? With our latest firmware, you can check the System Diagnostics (on the left side menu of the homepage) to see what’s going on with the weather adjustment.

[Ray]

You said “openHAB system getting a false message that a station has turned off immediately after being commanded on” — can you elaborate on that? In what way does it get a false message that a station has turned off? The HTTP API only returns a status code after a command has been sent to it. If you send a command to open the zone, it should send back a {“result”:1} if it’s successful. The message does not carry any information about whether the zone has turned on or off. Or did you mean that you are using OpenSprinkler’s IFTTT notification to notify OpenHAB? I am just confused in what way is the controller sending back a message to OpenHAB?

[Ray]

Well, we have never tested the main controller and expander separated that far away (i.e. more than a few meters away). Sure you can make a custom expander cable using an Ethernet cable, as long as you make sure the wiring of the cable is the same as the provided expander cable. The connector you linked to is fine, or you can use any 2×5, 2.54mm spacing connector. The advantage of the IDC connector is that it’s polarized so it prevents mistakes when plugging in the wrong way. The bigger issue with a long cable is that the signal quality can degrade over long distance. Also, don’t forget about the COM (common) wire — all zones connected to the expander must also have a common wire that should be combined with the common wire of zones on the main controller (or if it’s a separate wire, it can go into the section COM port on the main controller). The bottomline is that in addition to the expansion cable, you most likely also need a long common wire (though you can make use of one of the spare wires on the Ethernet cable as common wire).

[Ray]

Here is a simple guide to determine which one to choose:
1. Does your system have a pump start relay? If so, go with the AC-powered because the DC-powered is known to be not compatible with some pump start relays (however, you can always replace your pump start relay by a solid state relay and DC-powered works fine with most solid state relays).
2. DC-powered is more convenient for customers outside of US/Canada/Mexico where 24VAC power adapter is difficult to source. It’s also flexible for users who want to power sprinkler system off-grid, such as by using solar power.
3. DC-powered is slightly lower-cost — if you are US/Canada/Mexico based, the power adapter is included. For AC, the power adapter is additional.

[Ray]

The arrow should move the program up. What you reported sounds like a bug, I will take a look right away.

Update: I can verify that this is indeed a firmware bug, and will be fixing it right away. Thanks for reporting.

[Ray]

You can always use the OpenSprinkler HTTP API to set the watering percentage from an external script. For example, you can write a script that runs a server to calculate watering percentage, and have it send HTTP command to the controller to update the watering percentage every day.

[Ray]

One thing you can try is to check the raw log data, using the /jl command. Specifically, open a browser and type in:
http://x.x.x.x/jl?pw=yyyy&hist=2
where x.x.x.x is your OpenSprinkler’s IP address, yyyy is the md5 hash of your plain text password (you can use an online md5 hash calculator such as https://www.md5hashgenerator.com/ to get it).
Check the output and see if there is any obvious problem.

[Ray]

You can do a git checkout of any previous commit of the firmware. Or you can directly download the firmware 2.1.8 release:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/releases
and unzip it and compile it.

[Ray]

You can find the pin assignment in the hardware design details:
https://github.com/OpenSprinkler/OpenSprinkler-Hardware/tree/master/OS/3.0
OS 3 (based on ESP8266) does NOT use 74HC595, mainly because ESP8266 does not have enough number of GPIO pins. Instead, it uses PCA9555 IO expander, which is I2C-based so only uses 2 pins and are shared with OLED and RTC.

[Ray]

You are correct that the current ET implementation results in one update per day, and it only uses the weather data from the previous day instead of accumulated over many days.

Part of the challenge of including more data is that the weather service generally charges more for access to more history data. We have never charged our users any subscription fee, so a big increase in weather service bill will be difficult for us to cover.

One possibility to avoid querying the weather service for history data is to simply cache the data locally on the controller. That way, if we keep the past, say, 2 weeks of data, that should be sufficient for ET calculation and won’t trigger additional charges. This is definitely possible, we just haven’t got around time to implement that.

[Ray]

@Craig: after upgrading to firmware 2.1.9, I recommend you to do an explicit factory reset (even though the firmware update should trigger a reset, we’ve found a few cases where explicit factory reset resolved some flash-related issues). The reset procedure is:
– power off the controller, then power it back on, and as soon as you see the OpenSprinkler logo, press and hold the first push button (B1) and continue holding it until the LCD shows ‘Reset?’ or ‘Factory Reset?’
– press and hold third push button (B3) until the controller reboots itself and completes reset.

[Author]

Posts