- This topic has 44 replies, 14 voices, and was last updated 8 years, 11 months ago by
.
-
Posts
-
Hi All,
OpenSprinkler firmware 2.1.4 is just released. As before, this is a unified firmware that runs on all OpenSprinkler platforms (OS, OSPi, OSBo, including software simulation on Linux).
Main Changes:
– Support for California Watering Restriction. This is available in Edit Options -> Weather Control -> Weather-based Restriction.
– Support to use sunrise-to-sunset time, or sunset-to-sunrise time as the watering time/duration. Due to this addition, the station’s maximum water time per session is reduced to 16 hours (previously the limit is 18 hours).
– Support for two independent master stations. Each master can be defined from any of the available stations (previously it was limited to the first 8) and has its own set of on/off adjusted times. Each non-master station can be set to trigger neither, either, or both of the master stations.
– 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.
– Added variables to store the time stamps of the last requested weather call and last received weather call.
– Fixed a bug that causes the controller to stop responding when there are a large number of stations with long names.OS specific changes:
– Fixed a bug that causes the LCD to display wrong day of the week.
– Support to re-initialize the Ethernet controller when the last received weather call is more than 12 hours ago. This will hopefully fix the weather adjustment not updating issue.
– Support to display external ip and last received weather call to LCD display. The current button functions are:
* click / hold B1: show IP / stop all stations
* click / hold B2: show MAC / restart controller
* click / hold B3: switch display board / manual start program
* B1 + B2: show gateway (i.e. router) IP
* B2 + B1: show external (i.e. WAN) IP
* B2 + B3: show time stamp of the last successful weather call (lswc)
(Note: B1 + B2 means pressing B1 first, and while holding it, press B2 until it triggers the action. This is in the same manner as Ctrl+C etc.)OSPi/OSBo/Linux specific changes:
– Switched to use Zimmerman’s wrapper classes for sockets. This improves the robustness of the Ethernet server and fixes the server crashing issue.
– Added support to automatically detect RPi rev. 1 (the oldest RPi) and use the correct GPIO pin number (for backward compatibility).
– Improved build script. The build script now compiles the firmware and also sets the firmware to auto-start upon booting.
– Added sync() before reboot to prevent file system corruption.
Upgrade OS 2.0/2.1/2.2/2.3 to Firmware 2.1.4:
Please follow the Firmware Upgrade Instructions.
Important: if you have downloaded the firmware updater program previously, you will need to re-download it. This is because the previous version does not support OpenSprinkler 2.3 and hence is discontinued. The up-to-date program should display ‘Release Date: 04/26/15’ at the bottom of the window.
Upgrade OSPi/OSBo to Firmware 2.1.4:
1.If you have never installed the unified firmware before: open a command line window (or ssh to the device), go to the home folder (cd ~) and run
git clone https://github.com/OpenSprinkler/OpenSprinklerGen2.git
to clone a fresh copy of the repository.If you have installed a previous version of the unified firmware, go to the installation folder (by default ~/OpenSprinklerGen2), and run
git pull
to obtain the latest version.2.In the OpenSprinklerGen2 folder, and run
sudo ./build.sh ospi
for OSPi. This will generate an executable program called OpenSprinkler, and also set up startup script for auto-run at startup.Similarly, on OSBo, run
sudo ./build.sh osbo
Please make sure you run the correct command for OSPi or OSBo, because they have completely different pin settings.3. Before you reboot, keep in mind that by default the OpenSprinkler program will use HTTP port 8080. If you have an existing program or service that’s already using port 8080, such as Dan’s ospi.py or Rich’s sprinklers_pi, please stop those programs first, to avoid port conflict. Specifically:
sudo /etc/init.d/ospi stop
sudo update-rc.d ospi remove
will stop the ospi.py program. Similarly,
sudo /etc/init.d/sprinklers_pi stop
sudo update-rc.d sprinklers_pi remove
will stop the sprinklers_pi program.4. Reboot RPi and BBB, and the firmware should be good to go.
Thank you Ray, and all the others that make these updates possible. I can’t wait to upgrade and use some of the new features.
Regards.
Bruce
Thanks Ray. It works like a charm.
Also, with the logging function, should the water police ever drop by, I have a record of compliance.
Hi,
I just upgraded my 2.1 OS to 2.14 and when i load the json for the program the browser gets stuck on a black screen “loading”
Here is the json:
{“programs”:{“nprogs”:13,”nboards”:4,”mnp”:14,”mnst”:4,”pnsize”:12,”pd”:[[2,127,0,[1260,0,0,0],[0,5400,0,0,0,4200,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”goat zone”],[2,127,0,[1080,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3000,0,0,0,0,0,0,0,0,0,0,0],”Goat impact”],[1,127,0,[390,32,30,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,0,0,0,0,0],”goat water”],[1,127,0,[395,15,60,0],[0,0,0,0,0,0,2,0,0,0,0,0,0,0,0,0,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”dog water ne”],[0,119,0,[840,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1800,0,0,0,0,0,0,0,0,0],”house drip”],[3,27,0,[2,0,0,0],[0,0,0,0,0,0,0,0,0,4500,4500,2400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”Rotor”],[3,27,0,[0,0,0,0],[0,0,3600,0,3600,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”Spray House”],[3,27,0,[510,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3600,0,0,3600,0,0,0,0,0,0,0,0,0,0],”Spray wh oc”],[3,21,0,[840,0,0,0],[0,0,0,0,0,0,0,0,0,3600,2700,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”Rotor Day”],[3,43,0,[0,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1800,0,0,0,0],”Deice jugua”],[3,43,0,[420,0,0,0],[0,0,0,3600,0,0,0,0,3600,0,0,0,0,0,0,0,0,0,0,0,0,0,3600,0,0,0,0,0,0,3600,0,0],”drip all”],[3,59,0,[510,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,3000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”banana “],[2,106,0,[0,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3600,0,0,0,0],”DeIce spray”]]},”stations”:{“snames”:[“old goat h20″,”goat rotors”,”circle house”,”west pepper drip”,”house spray”,”west goat canal”,”dog north”,”Future Master”,”drip trees”,”west rotor”,”mideast rotor”,”east rotor”,”bananas”,”goat h20 pen”,”refill pond”,”banana drip”,”dog east”,”jr”,”outside circle”,”e. gto removed”,”impact goat”,”w. house spray”,”house drip”,”back chicken”,”se gto h20″,”front chicken”,”gto water”,”deice spray”,”dragon fruit”,”jugua papaya”,”blk greenhouse”,”bwn greenhouse”],”masop”:[125,255,255,255],”ignore_rain”:[64,0,1,4],”act_relay”:[0,0,0,0],”stn_dis”:[128,160,136,208],”rfstn”:[0,0,0,0],”stn_seq”:[247,254,191,219],”maxlen”:16},”options”:{“fwv”:213,”tz”:32,”ntp”:1,”dhcp”:0,”ip1″:192,”ip2″:168,”ip3″:101,”ip4″:220,”gw1″:192,”gw2″:168,”gw3″:101,”gw4″:1,”hp0″:80,”hp1″:0,”hwv”:21,”ext”:3,”sdt”:0,”mas”:0,”mton”:0,”mtof”:0,”urs”:1,”rso”:0,”wl”:72,”den”:1,”ipas”:1,”devid”:0,”con”:110,”lit”:100,”dim”:15,”rlp”:0,”uwt”:1,”ntp1″:204,”ntp2″:9,”ntp3″:54,”ntp4″:119,”lg”:1,”reset”:0,”dexp”:3,”mexp”:5},”status”:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”settings”:{“devt”:1430831789,”nbrd”:4,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”West Palm Beach, Florida”,”wtkey”:”dddddddddddddddd”,”sunrise”:398,”sunset”:1195,”eip”:849542700,”sbits”:[0,0,0,0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0]],”lrun”:[0,0,0,0]}}
I think this has to do with DHCP: you are using static IP (dhcp=0). Right after firmware upgrade, the controller is back to DHCP mode. During the import process, the IP address will immediately change after the DHCP is set to 0, and therefore the import cannot continue and complete. We highly recommend keeping DHCP but use your router’s DHCP reservation to create a fixed IP. This way there will be no issue with import, and you are less likely to get into IP conflict issues.
In any case, if you restart and try ‘import configuration’ again it should be able to complete the import.
I had rebooted before and i tried it again. this is the same configuration i’ve always used previously.
I reset the machine and tried to load the same json after changing DHCP from 0 to 1. i managed to change some of the configuration of the OS (weather id, exp board count), but it won’t import the station names or programs.
I probably can reenter all the stations and the programs, but its a bunch of work. Are you able to import this into your test OS?
Here is the updated json with dhcp set to 1:
{“programs”:{“nprogs”:13,”nboards”:4,”mnp”:14,”mnst”:4,”pnsize”:12,”pd”:[[2,127,0,[1260,0,0,0],[0,5400,0,0,0,4200,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”goat zone”],[2,127,0,[1080,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3000,0,0,0,0,0,0,0,0,0,0,0],”Goat impact”],[1,127,0,[390,32,30,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,0,0,0,0,0],”goat water”],[1,127,0,[395,15,60,0],[0,0,0,0,0,0,2,0,0,0,0,0,0,0,0,0,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”dog water ne”],[0,119,0,[840,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1800,0,0,0,0,0,0,0,0,0],”house drip”],[3,27,0,[2,0,0,0],[0,0,0,0,0,0,0,0,0,4500,4500,2400,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”Rotor”],[3,27,0,[0,0,0,0],[0,0,3600,0,3600,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”Spray House”],[3,27,0,[510,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3600,0,0,3600,0,0,0,0,0,0,0,0,0,0],”Spray wh oc”],[3,21,0,[840,0,0,0],[0,0,0,0,0,0,0,0,0,3600,2700,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”Rotor Day”],[3,43,0,[0,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1800,0,0,0,0],”Deice jugua”],[3,43,0,[420,0,0,0],[0,0,0,3600,0,0,0,0,3600,0,0,0,0,0,0,0,0,0,0,0,0,0,3600,0,0,0,0,0,0,3600,0,0],”drip all”],[3,59,0,[510,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,3000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”banana “],[2,106,0,[0,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3600,0,0,0,0],”DeIce spray”]]},”stations”:{“snames”:[“old goat h20″,”goat rotors”,”circle house”,”west pepper drip”,”house spray”,”west goat canal”,”dog north”,”Future Master”,”drip trees”,”west rotor”,”mideast rotor”,”east rotor”,”bananas”,”goat h20 pen”,”refill pond”,”banana drip”,”dog east”,”jr”,”outside circle”,”e. gto removed”,”impact goat”,”w. house spray”,”house drip”,”back chicken”,”se gto h20″,”front chicken”,”gto water”,”deice spray”,”dragon fruit”,”jugua papaya”,”blk greenhouse”,”bwn greenhouse”],”masop”:[125,255,255,255],”ignore_rain”:[64,0,1,4],”act_relay”:[0,0,0,0],”stn_dis”:[128,160,136,208],”rfstn”:[0,0,0,0],”stn_seq”:[247,254,191,219],”maxlen”:16},”options”:{“fwv”:213,”tz”:32,”ntp”:1,”dhcp”:1,”ip1″:192,”ip2″:168,”ip3″:101,”ip4″:220,”gw1″:192,”gw2″:168,”gw3″:101,”gw4″:1,”hp0″:80,”hp1″:0,”hwv”:21,”ext”:3,”sdt”:0,”mas”:0,”mton”:0,”mtof”:0,”urs”:1,”rso”:0,”wl”:72,”den”:1,”ipas”:1,”devid”:0,”con”:110,”lit”:100,”dim”:15,”rlp”:0,”uwt”:1,”ntp1″:204,”ntp2″:9,”ntp3″:54,”ntp4″:119,”lg”:1,”reset”:0,”dexp”:3,”mexp”:5},”status”:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”settings”:{“devt”:1430843994,”nbrd”:4,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”West Palm Beach, Florida”,”wtkey”:”dddddddddddddddd”,”sunrise”:398,”sunset”:1195,”eip”:849542700,”sbits”:[0,0,0,0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0]],”lrun”:[16,4,4,1430843707]}}
I am able to replicate this issue using the configuration you have pasted. This has nothing to do with DHCP as the app will not import DHCP setting (this would change the IP and cause all subsequent import requests to fail).
The issue seems to be with the /jn reply. After I imported your configuration, this is the reply the controller gives when requesting /jn:
{"masop":[125,255,255,255],"ignore_rain":[64,0,1,4],"masop2":[0,0,0,0],"stn_dis":[128,160,136,208],"rfstn":[0,0,0,0],"stn_seq":[247,254,191,219],"snames":["old goat h20","goat rotors","circle house","west pepper drip","house spray","west goat canal","dog north","Future Master","drip trees","west rotor","mideast rotor","east rotor","bananas","goat h20 pen","refill pond","banana drip","dog east","jr","outside circle","e.gto removed","impact goat","w.house spray","house drip","back chicken","se gto h20","front chicken","gto water","deice spray","dragon fruit","jugua papaya","blk greenhouse","bwn greenhouse"This is a partial reply and I know Ray added some logic to split the payload into smaller packets in 2.1.4 and right now I suspect it is the culprit. Once he is available, I will reference this post so we can hopefully find a fix. Unfortunately, for now it seems reverting back to 2.1.3 in your case will be the best solution, while we get this fixed.
Thank you
OK, I made some progress: I was able to reproduce the issue and it seems to have to do with the way the Ethernet library handles multiple packets. I modified the code to address the issue and updated the firmwares. You should launch the firmware updater, click on ‘Download Firmware’ to grab the latest firmware files, and update firmware. You don’t need to re-import. Let me know if this fixes the issue. Thanks.
I was not able to load firmware 2.1.4 on OS hw v2.1 with the Apr 26, 2015 firmware updater from here: <https://opensprinkler.freshdesk.com/support/solutions/articles/5000381694-update-opensprinkler-firmware-with-downloads->. I tried both openSuSE linux 13.2 and Windows 8.1, and neither worked uploading the firmware. They just seemed to sit there forever, doing nothing. I previously loaded 2.1.3 firmware using Windows 8.1 (with the last loader I suppose), so I know it used to work for me.
However “avrdude -c usbasp -F -p m644p -U flash:w:firmware2.1.4.hex” on linux did work for me to load the 2.1.4 firmware.
Hi,
Installing the updated firmware did it! In fact looking at the log it appears that everything was functioning except the UI.
As always thanks for your great work on the OS!
I’ll keep you posted if i see any further issues.
Gary
Ray,
Can you expand in detail on the California water restrictions? As the restrictions are still different through out the state.
Thanks,
Ed
Hi Ed,
The relevant code for how California restriction is calculated can be viewed here: https://github.com/OpenSprinkler/Weather-Adjustment/blob/master/application.py#L336-355
Specifically though, it’s adds the amount of rain over the past 2 days and the current day. If this is greater than 0.01″ of rain, then a restriction is applied. This effectively changes the watering level to 0%. Once the flag is cleared, the watering resumes.
I ran into serious issues after updating firmware to the latest version on my ospi. I use one extension board, S1 to S16.
I have a pump on s1. Once i turn on any Station manually, S1 and the Sx cycle between 24v and 0v every second.
I tried to set the masterstation to S11 which I am not using, same result. Using two stations as masterstation and setting Sx to use both again shows same result. Powersupply of ospi is at a stable 24vac.
Any thoughts?I also noticed that the off voltage readings of stations 1 to 11 are 0.5v which seem ok, but station 12 upwards read 6.5v in off mode. These stations are set to disabled.
Ray, just a question: why don’t you setup a repository for the compiled application, to have the installation up-to-date with standard “apt-get update; apt-get upgrade” commands?
Regards
Which compiled application are you referring to? For OSPi or microcontroller-based OS? For OSPi, it’s better if you run the build.sh script to compile it locally, because you may have a different version of Raspbian, and the compiled version may not work on your particular Raspbian. Also, keep in mind that the firmware is cross-platform — it’s for all of OS, OSPi and OSBo (and including any Linux system). Providing compiled binaries for all platforms is time consuming and in my opinion not necessary.
@pls90: can you elaborate on ‘S1 and Sx cycle between 24V and 0V every second’? Do you mean all stations turn on and off at the same time every second, or the stations run one after another every second? Also, does this only happen if you define a master station? If you don’t define a master station does the issue occur?
Ray, Thank you for getting back to me.
I tried turning on only one station at a time manually. This opens the selected valve and starts the pump, turns both off after one second, turns them on again and so on.
I will have to try what happens if I dont define any master station. I’ll keep you updated.Ok, I did some more testing.
The voltage cycles between on and off regardless of a masterstation.
The off voltage of stations 12-18 is 7v regardless of their disabled status.
Is there anything else I can try?I tried to revert back to the previous working version but seem to be unable to prevent the unified firmware to be automatically startet at bootup. Could someone kindly advise me as to how to make the old version to be loaded at bootup?
Right now my ospi is unusable. 😢@pls90 Sorry for the delay in getting back to you. In order to remove the start up of the unified firmware please run the following command:
update-rc.d OpenSprinkler.sh remove
This will prevent OpenSprinkler Unified firmware from starting on systen startup. You could either restart after or manually kill the running process.
I have some issues with Sunset-Sunrise programs.
I have 2 zones with RF lights sockets for the night, I want to turn them on at sunset and off at sunrise.
Case A) Correct set up values – wrong schedule (imho)
If I set the program “Start Time”=”Sunset” and the “Station”=”Sunset to Sunrise” the preview shows me it starts correctly (20:30) but it ends after 14:51:17 hours, basically like a wrong sunrise time (supposed 5:45). I waited a day to test it to void the preview script and it started at the correct hour but it showed that is scheduled to run 14:51:17 hours (confirmed through logging).
Case B) Wrong set up values – correct preview – not tested yet
If I set the program “Start Time”=”Sunset” and the “Station”=”Sunrise to Sunset ” I get a correct preview which I did not test yet because I thought this is kind of wrong because of the Station’s value “Sunrise to Sunset”I can provide direct access if need it.
In both case A and case B, you said ‘I set the program “Start Time”=”Sunset” and the “Station”=”Sunset to Sunrise”’. So how are these two cases different?
@Samer thank you for your help. I was able to start Richard Zimmermans 1.0.7 firmware which runs without any problems, no powercycling.
So the issue seems not to be with my ospi but with the new unified firmware.
I wonder what is different in my installation from all the others which seem be running fine. Anyone using unified firmware with an extension board?
- You must be logged in to reply to this topic.