OpenSprinkler Forums OpenSprinkler Unified Firmware Announcing OpenSprinkler Unified Firmware 2.1.9

  • This topic has 41 replies, 13 voices, and was last updated 2 days ago by Ray.
Viewing 17 posts - 26 through 42 (of 42 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.

    • This reply was modified 1 day, 23 hours ago by Ray.
Viewing 17 posts - 26 through 42 (of 42 total)
  • You must be logged in to reply to this topic.

OpenSprinkler Forums OpenSprinkler Unified Firmware Announcing OpenSprinkler Unified Firmware 2.1.9