Announcing OpenSprinkler Unified Firmware 2.1.4

[Ray]

@Augustin, so it looks like somehow the ‘sunrise to sunset time’ and ‘sunset to sunrise time’ are flipped. To make sure, in general, ‘sunrise to sunset time’ should always go with ‘sunrise time’ as the start time; and similarly ‘sunset to sunrise time’ should always go with ‘sunset time’ as the start time. Although the firmware doesn’t care if you mismatch them, it’s usually a mistake to mismatch them.

[Augustin]

@Ray: I don’t think that is the issue, I managed to test case B last night and it worked same as case A. So it started at around 20:40 and it was supposed to end around 5:40am, but it didn’t, it was scheduled to run for about 14 hours in both cases even if the preview was displaying correctly.

Sunrise hour is working great with another program of sprinkler where I set up to start it at Sunrise +1h and it is working for a week correctly.

My guess is this: When the schedule is computed to run between 20:40 and 5:40 means about 9h so when it starts it adds some values from the next day cycle because is going to next day. So 9h + 3 hours and 20 minutes from the next day evening. Just a guess.

[Augustin]

Tonight I retested Case A) and it scheduled correctly 9 hours starting 20:40 which supposedly turn them off at 5:40 but in preview program shows will be running up to 11:40.

[Samer]

If I understand correctly, the issue is purely with the preview but the schedule does run correctly. If this is the case, I will take a look at the app tonight and see if this is a reproducible bug and if so, get it fixed.

Thanks!

[Samer]

@Augustin, The issue should have been fixed regarding the program preview. The sunrise/sunset times were being incorrectly calculated by the Javascript library and comparing them to the controller’s sun rise/set was causing most of the issues you were seeing. The issue has been pushed to the code here: https://github.com/OpenSprinkler/OpenSprinkler-App/commit/f10431d22d3e2911f114e45cb1b456abb759aafe and will be released in the next app update.

The code has been pushed to the beta server and if you are interested a small post has been written on switching back and forth between beta, here: https://opensprinkler.com/forums/topic/mobile-app-ui-beta-access/

Thanks!

[piaband]

– Support to skip a station if 1) watering percentage is below 20% and 2) the station’s resulting water time is less than 10 seconds. This is to prevent very short watering times.

Where are these new options located in the android app?

[Samer]

@piaband These aren’t standalone options. They are part of the weather adjustment option and if used, won’t water for resulting durations less than 10 seconds (and when the percentage is below 20%).

[Ray]

Note that it will only skip the station run if BOTH conditions are met. The first condition (watering percentage is less than 20%) is to make sure the user didn’t intentionally program a very short water time. For example, if someone programmed a water time of 10 seconds to begin with, this should probably not be skipped because it’s likely the user’s intention to water for a very short amount of time.

[Augustin]

@Samer: Yes, after testing the case A for a couple of days I can confirm that issues appears only in preview program. The operation of the controller is correct.
I will have a look at the beta version.

Thank you!

[ianf]

Hi Ray,

I’ve fixed an issue (pull request 18) with detection of expansion boards that looks like it was introduced in 2.1.0.

I was hoping that this fix would correct another issue I’m having and that is the LCD display doesn’t show status E1:______O__ for stations 9-16 when they’re running. It could be that I just messed up the construction (custom ATMega1284, 20MHz with an 8 station expander on board), but it does turn on the correct stations on the expansion and I enabled serial debugging and annotated the detection code and it returns 1 now, not -1.

If you think the problem is my hardware, I’ll investigate further but at this point I’m pretty sure it’s a software issue. I’ll continue to plug away on my end, but if you can help I’ll be very grateful.

Ian

[Ray]

The LCD display is purely software (because the controller doesn’t have a feedback mechanism to tell if a solenoid is actually on or off). So if the LCD doesn’t display E1 correctly it’s gotta be a software issue. I will check to see if I can reproduce the issue.

[BinaryOS]

Hi Ray,

Any chance the 2.1.4 Arduino firmware code can be made available? only 2.1.2 seems to be available (unless I am looking in the wrong location) :-

https://opensprinkler.freshdesk.com/support/solutions/articles/5000165132-how-to-compile-opensprinkler-firmware
“Download the OpenSprinkler Arduino library. Alternatively, you can also do a Git checkout from the OpenSprinkler Github repository.”

Thanking you.

[Samer]

@BinaryOS,

All of our code is available on our Github page: https://github.com/OpenSprinkler

Specifically, for the firmware, you may access the source code here: https://github.com/OpenSprinkler/OpenSprinklerGen2

[BinaryOS]

Excellent, thank you for the quick reply.

[shiva]

Hi,
I’ve just upgraded ospi from the python program to this version and I have the problem that accessing through web it responds with blank pages on the base ip address (e.g. 192.168.1.88:8080) and with errors putting anything after it (e.g. 192.168.1.88:8080/main).
The app also can’t connect.

If it could be an useful information actually the raspberry is not connected to internet, it is acting as a wifi access point (with hostapd) and a dhcp server.
I’ve only tested it accessing via the wifi network till now.
With the same network configuration and the python program it was working.

Any idea?

[Samer]

The Unified firmware does require the Internet to load the UI files when accessing the control directly by IP address. However, the application does not require the Internet to communicate with the controller.

To troubleshoot, can you you ensure the correct IP address for the Pi by running ifconfig. Once you have the IP, you can try to access the firmware on port 8080 (the default is port 8080) by using the following URL: http://192.168.1.88:8080/su. This is the script change URL which does not require any Internet connection render. If this works, then the app should work as well using the same IP and port.

If you wish, you can also host the UI files on the Raspberry Pi by using Apache or any other web host. We have instructions available here: https://opensprinkler.freshdesk.com/support/solutions/articles/5000164006-using-a-different-server-for-ui-assets

If this continues to not work, you may be best served by sticking with the Pyton program although the Unified program should work in this setting.

Thanks!

[shiva]

Thanks!
That solved!
Now it seems to work, but I still have some doubts.
I’ve setup a nginx web server listening on port 80, OpenSprinkler sw is listening on 8080 (default on OSPi), set the script url to http://127.0.0.1/js so I’m able to open the login page on 192.168.1.88:80 and connect to the sprinkler 192.168.1.88:8080 (or launch the app and connect to 192.168.1.88:8080).
Is it the right way?

One final question: I’m not able to change the “-04:00” Timezone in “Edit options” -> System beacuse it is disabled, system clock and timezone are set ok, but this way OpenSprinkler shows a bad time, example:

Current default time zone: ‘Europe/Rome’
Local time is now: Thu Jun 4 12:14:24 CEST 2015.
Universal Time is now: Thu Jun 4 10:14:24 UTC 2015.

While on OpenSprinkler: Jun 04, 2015 06:14:24

[Samer]

Glad you got it working and you are correct about the default port, sorry.

In regard to the timezone, we have another user reporting this and we have found an issue we are exploring right now. So we will update you soon once we have a resolution.

Thank you!

[shiva]

I managed to change timezone exporting the configuration, modifying tz field in the json file and importing it.

[Samer]

The app will allow you to change the timezone if you delete the location since that’s how it normally decided the timezone. Your method also works as well.

[Author]

Posts