February 23, 2015 at 1:40 am #35642
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:
it gives me a response of:
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.February 24, 2015 at 4:45 pm #35669
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,
SamerFebruary 25, 2015 at 12:03 am #35673
<div>Thanks, Samer… I appreciate all your work on the project. You do great work.
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>
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.
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?February 25, 2015 at 12:06 am #35675
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.February 25, 2015 at 12:26 am #35676
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.February 25, 2015 at 12:57 am #35677
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.February 25, 2015 at 1:47 am #35678
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.
- You must be logged in to reply to this topic.