OpenSprinkler Forums OpenSprinkler Unified Firmware Crashes when I try to update water level via HTTP

  • This topic has 6 replies, 2 voices, and was last updated 6 years ago by tom.
Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #35642

    tom
    Participant

    My Open Sprinkler (arduino version, latest firmware) has been running fine.  However, when I try to change the water level with an HTTP Get command:

    http://(ip-addr)/co?pw=xxx&o23=45

    it gives me a response of:

    {"result":1}

    and then the network access freezes. The controller continues to run properly, making and logging runs.
    I just can’t access anything from the web. I don’t see it on my router’s attached devices list, either.

    I reset the unit, restore a previously exported backup file, and it runs fine again, until I repeat the HTTP Get
    command.

    #35669

    Samer
    Keymaster

    The /co command is a bit tricky because omitted variables are interpretted as disabled and therefore certain options get turned off. This includes DHCP which is likely getting switched off and causing connectivity issues. The following variables are the compelete list that are handled in the same fashion:

    o2 – NTP
    o3 – DHCP
    o21 – Use rain sensor
    o22 – Rain sensor type
    o25 – Ignore password

    If any of these are not provided to /co they will be disabled or turned off.

    Hope this helps,
    Samer

    #35673

    tom
    Participant

    <div>
    <div>Thanks, Samer… I appreciate all your work on the project.  You do great work.

    </div>
    I got things working OK by adding the additional parameters, but it sure is complicated .  It seems kind of dangerous that a badly formed GET command would shut down all access to controller.</div>
    <div>
    The way that it is set up,  a program that just wants to change the water level has to also manage the NTP, DHCP, ignore password, rain sensor, and type of rain sensor states.  Kind of goes against the whole spirit of a REST interface.

    </div>
    It seems to me that a better way would to make the state of each parameter independent of the others.  If a parameter is not mentioned in the GET command, it is not changed.  If it is set =0, it is off, and =1 it is set to on.  That way there is no confusion about unintended side effects of a state change, and a program does not have to be concerned with managing all the other states in the command.

    Does this sound reasonable?

    #35675

    Samer
    Keymaster

    Of course however the firmware is designed with hardware constraints and furthermore backward compatibility with previous apps and UIs. Maintaining the compatibility is mostly why things proceed the way they do in regard to the API.

    Looking forward, we plan on fixing this and hopefully will do soon.

    #35676

    tom
    Participant

    I understand, but it seems a shame to be limited by hardware constraints in this day and age 🙂

    I’m torn between using the Arduino and the Pi versions.  The Arduino version seems to be more reliable and has a better scheduling system.  The Pi system is more open and available for programming, but doesn’t have the zone-level scheduling that I need.  I’m pulling down Evapotranspiration data from California’ CIMIS databank, and reading pulses from a Dywer flow meter, but am confused as to how best pull it all together, or what other efforts are under way… I’d love any advice folks might have.

     

    #35677

    Samer
    Keymaster

    The next firmware release will be cross platform meaning it will also support the Pi and Beagle variants. This brings all the Arduino features to those platforms such as zone-level scheduling.

    In regard to Evapotranspiration, we have designed the weather adjustments to be able to handle new methods such as ET quite quickly. We are currently working on a method which uses ET and hope to have it available soon.

    #35678

    tom
    Participant

    great.  I’m looking forward to it.  Do we have visibility into the next release?  a beta program?

    p.s. it would be great if the zones would have their numbers and names displayed throughout (as in the /#os-stations display).  I like to use zone names while walking about and testing the system (“lawn near BBQ” makes it easier to find it), but also use the zone numbers for checking out the wiring, valves, etc.

Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.

OpenSprinkler Forums OpenSprinkler Unified Firmware Crashes when I try to update water level via HTTP