OpenSprinkler Forums OpenSprinkler Unified Firmware Announcing OpenSprinkler Unified Firmware 2.1.9

Viewing 25 posts - 26 through 50 (of 63 total)
  • Author
  • #63222


    @Ray: Update regarding network issue:
    Router’s (TP-Link Archer MR200) firmware is updated to the latest version.
    After upgrading the OS controller to 2.1.9, I checked the router’s Log and noticed that there is a repeating exchange of the following sequence of 4 messages with the controller:
    1) “Recv DISCOVER from {OS controller’s MAC addr.}”, 2) “Send OFFER with ip {Reserved IP for OS controller}”, 3) “Recv REQUEST from {OS controller’s MAC addr.}”, 4) “Send ACK to {Reserved IP for OS controller}”.
    This sequence continuous forever, causing delay issues and network failures to the LAN.
    When reverted back to OS version 2.1.7, the issue disappeared (the reserved IP was assigned during the first try, without any retries initiated by the OS controller).
    I hope the the above information might help to resolve the issue.



    I guess the best way to debug is to acquire the same router so we can do some in-house testing. Out of curiosity, where did you buy this router? I looked on Amazon and can’t find this particular model.



    I had the same issue when setting my OpenSprinkler to DHCP and assigning a static IP to it within my router while connected via a wired Ethernet conenction.
    I found using WireShark that the OpenSprinkler kept sending DHCP Discover and DHCP Request messages 5 to 6 times a second.
    This would cause the OpenSprinkler to be slow to respond to button presses and the screen would flicker.

    I am using a DIR-882-US AC2600 EXO MU-MIMO Wi-Fi Router on the latest firmware.

    I resolved the slowness by setting a static IP address within the OpenSprinkler web application but now I’m seeing frequent instances where the OpenSprinkler stops responding to web requests and requires a reboot. Oddly enough it continues to respond to pings, but just not http requests.

    OpenSprinkler V3
    Firmware 2.1.9(1)
    Wired Ethernet



    There is always the possibility that the Ethernet module itself is the problem. If you submit a support ticket, we can arrange to send a replacement Ethernet module to see if it addresses the issue. You can also search for ‘ENC28J60 module’ on Amazon to get a replacement.



    – I bought TP-Link Archer MR200 (as an LTE 4G Router) officially from my ISP (one of the biggest internet providers in Greece), in order to avoid incompatibility issues. (Previously, I had bought different routers from the market and faced compatibility issues.)
    – Please consider the fact that I experience exactly the same problem/behavior with both the OS v2.3 controllers I have; I bought the 2nd several months later than the first, to be used only as a backup. Therefore, I believe that the chances to get rid of the problem by replacing the Ethernet module are very small.



    Yes, I forgot to mention I already tried a replacement ENC28J60 module from Amazon and it did not help.



    @mmavrof: sorry, my message was meant for those who have OS 3.x with wired Ethernet module. Since you have OS 2.3, that doesn’t have replaceable ethernet module, so we will have to try to resolve it through firmware changes.



    Tried to upgrade my OSPi this afternoon ia accordance with the instructions. Pi had the latest rasbian updates.
    This was unsuccessful, and I now have a non-functional sprinkler system. I can ssh to the Pi, but I see no useful log messages anywhere.

    Debugging (or reversion) tips?



    @JonInAz: what specific error message are you getting? “unsuccessful” does not give enough details for diagnosing the problem.



    Ray, I dropped this for a couple of months but still having troubles with the WU integration. I tried a number of different combinations and finally figured out by inspecting the configuration file (using export – email) the PWS was not being defined.

    To fix that I selected a different station on the map. I saved the data and then went back and selected my PWS and saved it again. This time the PWS ID shows up within the brackets for the wto section.

    My question is what the port number option on the same WU configuration section? Is that the port to get out to the network or the specific port for the OpenSprinkler device? The reason is I changed it from port 80 default to the one that is assigned on my router for the Open Sprinkler. Now I can no longer communicate with the OS at all! I can try again with the direct IP address when I’m on my home network.

    Second question – now that the PWS and key is showing up in the WU section (and verified in the config file) – how long does it take for the weather on the top of the page to be updated? I tried viewing the weather before I changed the above port number and it was still indicating the data was from the Dark Sky service. Is there some time period I need to wait before the updated weather information will show up?



    Here is my config data:
    h 100
    t 100
    r 100
    bh 30
    bt 75.02
    br 0
    pws “KTXAUSTI234”
    key “APIKEY************”
    ifkey “”

    Believe I fixed the port issue. Problem is it still reports Dark Sky.



    I’ve just installed the latest unified firmware on my OSPi. I was using the interval program previously. It appears the master off delay won’t accept a positive value. I use the master station to start a bore and the bore is being off/on briefly between stations, not great for the motor. I was hoping to use the master off delay to hold the bore running for 2-3 seconds. Is there a fix for this?



    @jnissen, the attribution to Dark Sky on the weather forecast page is correct. Dark Sky is always used to provide the forecast information. I suspect that your pws historic data from weather underground is correctly being used for watering duration. Unfortunately, attribution of historic data is not currently showing up on the System Diagnostic popup.



    @firefly: since a few firmware versions ago, we’ve changed the way master zone is implemented, as a result, the master off delay can only be negative, and master on delay can only be positive. However, there is a work-around you can use to achieve the effect of positive master-off, that is, by creating a dummy zone (a zone that’s enabled in software but not a physically connected zone). For example, if you have 16 zones, you can designate zone 17 as a dummy zone. Make sure that zone activates the master (by default it does), and include that zone in your program, for how long you want the master to remain on after the last zone closes. This way, at the end of the program, it will run the dummy zone but since it’s not a physically connected zone it won’t actually turn on any sprinkler, other than keeping the master on for the duration you programmed the dummy zone for.

    The latest firmware supports up to 72 zones, so as long as you have not exhausted all 72 zones, you can always designate a dummy zone for this purpose.



    Possible to add to the diagnostic page where the average weather data is being obtained? Would eliminate the confusion if properly configured PWS’s are being used for the calculations. I export my config and believe it’s using the PWS but not sure I can say for sure that is the case.



    No error messages were produced at the command line, none in log files I could think to check at the time.
    Used this process:

    After the install, no OpenSprinkler-related processes ran (that were obvious to me) or exposed via http. This included after a reboot. Dmesg showed no failures at startup, which would suggest the install failed silently.

    Any suggestions on debugging? I’m reasonably literate on Linux = I was a part-time Unix System V admin in the 80’s when IT was a side job for engineers, developed Linux apps and managed Linux installations for some startups cerca 2000, and have used Linux as my primary OS since ’95.

    The git-pull included a viable SIP install, so I manually installed that from within the release and have control, but it no longer is functional with the OpenSprinkler web app. Is the OpenSprinkler API,and how it interfaces to SIP documented somewhere?



    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/ stop

    then, in the firmware source file folder, there is a file called “defines.h”, which has a macro define ENABLE_DEBUG
    uncomment that line to enable command line printout. Next, re-compile the firmware by:
    ./ 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 ./ 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/ stop again to stop the background process.



    today i have run upgarde from 2.1.7 to 2.1.9
    my hardware version is 2.3

    after success upgrade there is no web page comes up in the computer browser and my phone too.
    I can see the device on my router, the devide is working, I can see data on the screen (of the device)

    do you have any idea?

    best regards feri

    you can see the upgarde process here.:

    d:\bb>avrdude.exe -c arduino -p m1284p -P COM5 -U flash:w:os_219.hex

    avrdude.exe: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.01s

    avrdude.exe: Device signature = 0x1e9705
    avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
    To disable this feature, specify the -D option.
    avrdude.exe: erasing chip
    avrdude.exe: reading input file “os_219.hex”
    avrdude.exe: input file os_219.hex auto detected as Intel Hex
    avrdude.exe: writing flash (79118 bytes):

    Writing | ################################################## | 100% 10.45s

    avrdude.exe: 79118 bytes of flash written
    avrdude.exe: verifying flash memory against os_219.hex:
    avrdude.exe: load data flash data from input file os_219.hex:
    avrdude.exe: input file os_219.hex auto detected as Intel Hex
    avrdude.exe: input file os_219.hex contains 79118 bytes
    avrdude.exe: reading on-chip flash data:

    Reading | ################################################## | 100% 8.86s

    avrdude.exe: verifying …
    avrdude.exe: 79118 bytes of flash verified

    avrdude.exe: safemode: Fuses OK

    avrdude.exe done. Thank you.



    Click button B1 to find out the IP address. It’s possible that the IP address has changed after you upgrade the firmware.



    Hi Ray

    thank you very much for your response.
    Of course I have checked it on the router and on the device too.

    After upgrade when entering passowrd, it responses that it is an invalid password.
    I know that after upgrade I sould use default password. opendoor

    I can check out on the device that i should not have to enter with password.
    There is only a blank page after it.

    so I woudl lik some help 🙂 thank you!



    Blank page usually happens when the result from the controller is malformed. To check, you can open a browser and type in the following and check the result:
    where x.x.x.x is your controller’s IP address, /ja is a command that requests all json data as a whole, and a6d82bced638de3def1e9bbb4983225c is the md5hash of ‘opendoor’. As you said, after upgrade, the device key will reset back to opendoor, so this should work. The result should be a valid JSON string (you can use any online json parser to check if the result is valid or not, such as:

    Perhaps you can perform a factory reset just to make sure all parameters are reset back to default values.




    thank you very much for your response.

    Of course i have done factory reset, but not cahnged.

    I checked as you wrote, There are 2 errors in the jason string.

    best regards feri

    Accept-Encoding: gzip, deflate
    Accept-Language: hu-HU,hu;q=0.9,en-US;q=0.8,en;q=0.7




    So it looks like the “loc” location string is corrupted for some reason. You said you have performed an explicit factory reset (i.e. not the reset triggered by firmware update, but rather, you manually perform a factory reset), and this is happening right after that? I am puzzled and don’t know how to explain this.

    Maybe you can check the microSD card in the controller — firmware 2.1.9 stores all settings and programs on the microSD card. So if there is an issue with the card, it could result in corrupted data. The easiest way is to re-format the microSD card, or replace it with a new one. See if this helps resolve the issue.



    i removed the sdcard and format it in a laptop to fat32
    put back, reset again

    nothing changed
    the result of this link (http://x.x.x.x/ja?pw=a6d82bced638de3def1e9bbb4983225c) is: {“fwv”:219}

    remove the card again, check it in the laptop. There are some files on it.

    I connect my device to usb port and network utp cable. (power comes from usb cable)
    do you have any other idea?

    thank you very much! feri



    From the result you are getting, it does seem the device password is no longer the default ‘opendoor’ for some reason. I am not sure how this is possible, especially since you said you’ve done a factory reset.

    The only other thing I can suggest trying is to ignore password, and see what happens. To ignore password, use the following procedure:
    – power off the controller, then hold the third pushbutton (B3) while powering it back on. Continue holding B3 until the LCD shows “Setup Options”
    – click B3 as many times as you need until you reach the “Ignore Password” option.
    – use B1 or B2 to change the value to ‘Yes’.
    – Press and hold B3 until the controller restarts itself. At this point, the change to that option is saved and the controller should now ignore password. See if this allows you to log in.

Viewing 25 posts - 26 through 50 (of 63 total)
  • You must be logged in to reply to this topic.

OpenSprinkler Forums OpenSprinkler Unified Firmware Announcing OpenSprinkler Unified Firmware 2.1.9