Crashes when I try to update water level via HTTP

[tom]

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.

[Samer]

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

[tom]

<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?

[Samer]

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.

[tom]

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.

 

[Samer]

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.

[tom]

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.

[Author]

Posts