Separate inputs for flow and rain

[Martin]

Hi Ray and Samer
the future will be used at the same time flowmeter and rain sensor? Currently, the two sensors on a single pin. I use OSPi and I would like to take both flow and rain. Thank you Martin

[Ray]

They can certainly be separated. The only reason they share the same pin currently is that the enclosure does not have a separate cutout for flow sensor. You can solder a wire from the circuit board and assign a separate pin to flow sensor, but most users are not going to be able to do so. In the future if we redesign the enclosure this will surely be included.

At the moment if you want to use separate pins, you can change the flow sensor pin definition in defines.h. You also need to make a few additional changes since a couple of controller variables are shared between the two (because the firmware assumes there is only one sensor). The changes shouldn’t be too hard to make. Just do a global search of OPTION_SENSOR_TYPE and you should find all places where the code handles rain sensor and flow sensor.

[Martin]

Hi Ray,
I understand that it does not currently hardware version of the other terminal, but I use OSPi and I have no problem to connect additional pin. The problem I see is that applications from Samer does not actually choose both sensors (flow and rain). I would in the future be used only OpenSprinkler Unified Firmware instead OSPy. Currently did not work LCDs and other features that I had OSPy from Rimco OSPy. But the Application of Samer is God! The problem is that I am not a guru in C ++ and other things. Originally it was OSPi from Dan (I started to learn Python), then I switched to OSPy from Rimco (and re-started everything from scratch – ie plugins for OSPy). Currently I see the opportunity to start doing everything properly in OpenSprinkler Unified Firmware, but are fading and I’m not able to do much of anything. Today I tried all day to get into Uni fw I2C LCD support, but only same mistakes …. I would also like to participate as a contributor (I have a lot of sensors in the system OSPy). I have no problem to build your own hardware to test (for example, support the buttons in OSPi as the Arduino hardware version).
Thanks Martin

[Martin]

thought:
I still think of one idea within OpenSprinkler Unified Firmware applicable to all versions OSPi/ BBB / HW Sprinkler – use I2C bus supporting circuitry (such as ADC, pulse counter, etc …) then it will not matter whether the hardware version has pins. If I2C IC is mounted and connected in to FW as plugin (circuit would I2C injected as a plugin). But it’s just a thought. Once again, thank you for the work and effort you devote to the project.
example wind plugin: http://www.pihrt.com/elektronika/298-moje-raspberry-pi-plugin-prutokomer
example keyboard:
http://pihrt.com/elektronika/323-moje-raspberry-pi-plugin-ospy-8-tlacitek-8-led
Thanks Martin

[Ray]

I think you are talking about two different issues: one is having two separate pins for rain sensor and flow sensor (and this has nothing to do with OS vs. OSPi, both of them have enough number of pins, but the enclosure has only one sensor connector); the other issue is having a common set of I2C components shared between OS and OSPi. For the second issue, all hardware platforms (Arduino/OSPi/BBB) support I2C, so you can definitely connect any I2C component to any of them. Also, the main reason behind the Unified Firmware is indeed to have a common piece of firmware that can compile for all of them. Regarding ADC: since Arduino and BBB both have plenty of analog pins, there is no reason why not to make use of them. The fact that RPi doesn’t have ADC is really a downside of it. Regarding pulse counter: all three platforms use Interrupt to handle pulse count, which is already supported in the Unified Firmware.

[Martin]

Yes,
Thank you for your answers. Sorry for the stupid questions. However, the question was whether it will be used at the same time rain and flow. If I can modify the code and add a pin to OSPi regardless of the OS? and ask git-pull? If it make does encourage Samer opportunity for both sensors simultaneously?
Thank you Martin

[Ray]

You are right that the app / UI currently assumes there is only one sensor, but that’s only relevant to the UI — you can still modify the firmware to support rain sensor and flow sensor at the same time. Currently the code for sensing rain and counting flow sensor are exclusive: if the sensor type is rain sensor, it will bypass the interrupt function for counting flow; conversely, if the sensor type is flow, it will bypass the code to check rain sensor status. If you use two separate pins, then they don’t need to be exclusive. So basically all you need to do is minor changes to the firmware to make sure both the rain sensor code and flow sensor (interrupt) code are enabled.

[Martin]

You are right That it can modify in the FW …
But I would not want to get to the stage That I’ll make Adjustments FW and Then Will not supported (Either UI or HW). I already Went through this with OSPi dan / OSPy Rimco.

On the other hand, if the flow sensor used as a detector malfunction (no flow if station open, or vice versa is a large flow if the station is closed, etc …) is in my view appropriate to use detection (another detection at this time is not in the OS -AC/DC/OSPi). And if I use only flow sensor (rain sensor is disabled) and now rain and station has now irrigation – this is error.
It is therefore appropriate to have these two sensors together. I understand that the box has no hole OS (the terminal with another pin).
The user base uses rain sensor, and if he wants to expand its hardware pulls out another conductor plate. But according to my aid should both simultaneously.

If not support in the OS (and mainly in UI) for two sensors simultaneously does not make sense to further discussed in this thread because I got back to the blind fork.

Thanks Martin

[Ray]

If you use a weather algorithm (either Zimmerman or Auto Rain Delay), which uses online weather data, perhaps you can remove the rain sensor. Alternatively, you can connect the rain sensor (assume it’s normally closed) in line with the COM (common) wire, which serves to cut off sprinkler when rain sensor is activated.

[ShawnHarte]

Would it be possible to run the rain and flow sensors on the same wire then in firmware count puleses while a program is running and look for a constant high for rain while no program is running. A diode on the sensor wires should take care of backfeeding either sensor, and we would get the benefit of both sensors without the need for messing with the board directly.

This would also allow an alarm condition for leaks, or open valves while a program is not running because a pulse detected outside prescribed times would indicate unplanned watering. It would also allow for stopping a program if the ‘pulse’ goes solid indicating way too much flow or rain.

[bryanmee]

What happens if the contacts on the flow meter are closed when you stop watering? Would this look like rain to the controller?

[Ray]

@ShawnHarte: what you described is an interesting idea that allows two signals to be multiplexed on the same wire and use a smart algorithm to decouple them. But I think it’s going to be difficult to make it work in this case: if one sensor is left in a closed contact state, it will mask out the other sensor. For example, if the rain sensor’s contact is closed, the controller will sense a constant 0 on the sensor pin, and flow sensor clicks will not be correctly received. It’s the same situation if the flow sensor is left in a closed contact state.

So without using separate pins, the best work-around for now is to either rely on online weather data and weather algorithm, or connect the rain sensor in series on the common wire (like how a rain sensor can be used with a generic controller that doesn’t have a rain sensor port).

[Martin]

Hi all,
weather algorithm is not 100% function on my location.
Example: weather reports rain, yet not a drop of rain falls, and the program was blocked – this is a mistake.
The only real indicator is the rain sensor whether it rained or not.
Yes is possible join rain sensor between power outlets valves (COM terminal), but I lose the ability to detect rain in the mobile application and that’s the main reason why I talk about it constantly. I do not want a virtual prediction from weather algorithm , but the actual entry.
Furthermore it is not yet actual resolved protection when is not water in reservoir or pipe burst (via water flow sensor). I want to use the maximum (ie, mobile applications and Unified Firmware), but until this somehow solve reasonably’ll have to use OSPy (https://github.com/martinpihrt/OSPy) where the detection of flow (pressure) resolved plugin, but unfortunately the mobile application of Samer early as this tree is not supported. I just do not understand why it is a problem to connect additional input in HW Unified firmware.
Ray, of course, is the main creator and I do not have anything to say, but that I consider fundamental to be able to order hardware (or Rasp from Ray).
Thanks Martin

[ShawnHarte]

I use a setup similar to what I described to fill a pond when the water gets low using a dry contact switch on a float and a hall effect flow meter, in the 3 years it has been runnning I never had the flow meter stop in a open position. I honestly hadn’t even thought about it till now.

I may have to rethink that setup, but I’m also intrigued by the fact it hadn’t happened. I wonder if the magnetic pickup causes it to stop in a certain position every time. I’ll tear in to it since winter is on its way in and I wont need to fill the pond.

As far as the rain sensor masking the flow sensor I don’t think it would be a problem since rain would inherently prevent flow, we would only loose the ability to detect leaks when it is raining.

[Ray]

@Martin: I understand your request, but it’s important to make the UI/app consistent with the hardware capability. If the hardware only allows one sensor to be connected to the sensor terminal, the UI/app should match that and should not present rain sensor and flow sensor as two separate options.

If you need separate sensors, you will have to modify the firmware anyways. So the UI doesn’t really matter because in the firmware you can allow as many sensors as you need — the UI just provides an easy way for you to modify the options and parameters, but you can always changes these directly int he firmware, or through the HTTP GET command, without having to go through the UI at all.

[Martin]

@Ray: I understand the problem, if not support the app with multiple inputs i remained Rimco version. Thank you Martin

[Author]

Posts