I see…in the previous discussions on this thread we talked about simply sending in the reading from the sensor - no calculations needed on the “this side.” Meaning the Iro would take the reading and calculate on its own. This is simpler because you don’t have to query to find out what the total irrigation amount for full moisture is for each zone before you call the fill_to_amount endpoint. This will also avoid confusion and miscalculations on the callers side.
My moisture sensor reads .40, then I should be able to let the Iro know exactly that amount without having to do math on my end.
It is the percent of moisture found in that zone. The sensor reads the moisture level and reports it as a percentage. It goes from 0 to 100% - i then translate it to 0 - 1 and call the endpoint. Does this make sense?
It does, let me think about the best way to do this. The problem is today moisture level is always affected by precipitation, any irrigation events, and daily ET. So, we can’t just set the value to 40% since events are recorded throughout the day that will modify the moisture level.
To make this truly happen we need to allow for setting the moisture level. Currently it is derived from daily observed weather, irrigation events, and precipitation.
Is best case you ultimately controlling the moisture level (all aspects) and we never derive it?
I looked again and found it. This is the amount we irrigate to (in inches).
The moisture sensor in the ground should be the definitive source right? Regardless of what other events happened (daily observed weather, irrigation events, and precipitation) if the sensor says the moisture is at 40% then that must be the case. Especially since weather stations are miles away - rain at the station may not mean rain at my house. I would say that all events should matter, but ultimately if the sensor says there is X amount of moisture then that should trump other events.
I do see depthOfWater - but I wonder how to calculate that based on the reading from the sensor.
BTW - I really appreciate your willingness to have this discussion!
Agreed. Let me think about how to do this. We will need this for sensor based control anyways.
I don’t really know if that can be reverse-engineered. If we can accept the value of the sensor as the truth, then irrigation amount (depth of water) would only be used for our watering duration, and not be used to subtract from.
BTW - I am going to remove the endpoint I put out to change the percent of soil moisture. It doesn’t make any sense at all to be set externally.
FYI I wouldn’t ever use soil sensors unless I planned on being at that property daily to assure the watering is correctly applied due to all the factors involved within the placement of the soil sensors.
Interesting post. what is the final output? does Iro support those sensors? which one you recommend to buy and where is the best place to install? close to the sprinklers or at random places? any documents with the instructions on how to proceed?
@andrey, great question! I haven’t heard of anyone pulling this off yet, but looks like there’s an aging topic on the ST community related to moisture sensors. Might be worth pinging this topic there to see if there’s any updates available.
Is anybody running the Rainbird SMRT-Y - Soil Moisture Sensor Kit with a Gen 1 Iro ? If so, how - have you got it switching the rain sensor terminals or disabling all zones in some other fashion ?
@StuartM, looks like the SMRT-Y sensor acts like a rain sensor; i.e. a switch that interrupts the common wire depending on the soil moisture level.
If you wish to install a sensor on individual zones, an isolated common will also need to be installed and spliced into the zone common before the controller. If you wish to do this, please reference this support article.
Cloud to cloud sounds great. I have seven zones being run by my Rachio 2d generation and I believe having my watering schedule controlled by soil moisture would be great as the different zones dry out at different rates. Do you anticipate your system to work at that level of granularity?
My concern at this point is that Feb 2015, the direction from Rachio was “Expect to see these sometime this year.”. Now over 1 year has passed since this and we still do not have a viable solution and 14 days ago the message is now “no timeframe yet as to when these are built out”.
The messaging provided by Rachio is not clear or concise; the roadmap is obviously consistently in flux, with provides no clear direction to the development team or to customers. Are your PM’s even in touch with customers to understand a customers needs vs wants?
You have competition, like Spruce, which already support this, through the use of SmartThings. This is not the most ideal way of procuring data as there is additional costs involved, but it is a solution non the less.
Well, hold tight. They wanted to rework flex daily to be more approachable and it didn’t pan out as they had hoped. This burned their winter months on development so they have had to fall back and begin development on their new super awesome-o scheduler to accommodate the many customers that face harsh monetary penalties for watering on the wrong day.
It’s ashamed, but they have provided me and others an added ability to help customers with flex setup while they work on “the juice”. I’m not here to make excuses for them, I hope to provide a peak at the sausage facility…
Now…spruce, it’s pretty awesome, I won’t lie, but I’ll take the Pepsi challenge every single day to a well tuned flex…they will get there with an integration, eventually…flex will become the dry spot terminator of irrigation, but, for the moment, you will not find a more accurate/precise water on demand solution sub $300,. Just hold tight…
