OSPi Rain Sensor

[atom]

Greetings,

I have a OSPi plus with zone extension board. All working awesomely. Thanks, Ray, Dan and Samer.

I have an Irritrol wireless rain senor. It offers normally open (NO) and normally closed (NC) triggering. The reciever has no problems communicating with the sensor. However, it doesn’t matter if I choose NO or NC and adjust the sensor type in the software accordingly, I cannot get any rain events to be sensed.

I have tried trouble shooting by setting the rain sensor software to NC and disconnecting the rain sensor plug, I would have thought that this open circuit would trigger a rain event as the software is expecting a NC feedback loop.

I am not brave enough to change the software to NO and jump the sensor pins as I don’t want to destroy anything.

I don’t have access to a multimeter and am hoping someone has an idea to assist me in trouble shooting this scenario.

Thanks.

[Ray]

The easiest way to test is to connect a wire between the two ports on the rain sensor terminal block, and by plugging it in or out you can simulate closing or opening the rain sensor. You don’t need to worry about jump the rain sensor pins — that’s exactly how a typical rain sensor works — it’s basically a rain activated switch.

[atom]

Thanks for your super prompt response.

Have manually tested in NC and now NO configurations and can’t get the software to sense any rain.

Hmm.

[Ray]

Which firmware are you running? Did you try the unified OpenSprinkler firmware?
https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-3-for-avrrpibbblinux/

[atom]

Hi Ray,

I am running OpenSprinkler Pi version: 2.2.30 (2015-02-21).

Guess I am going to have to try the unified OpenSprinkler firmware.

Going to be some time before I report back as need to research how to have dual softwares on a single micro SD.

 

[atom]

Reporting Back.

Everything A OK on OpenSprinkler firmware 2.1.3.

NO/NC work exactly as expected.

Thanks Ray for the super support.

 

As a Post Script:

I would like add that Dan’s project seemed so much easier to get online reliably. I understand that this is an enthusiasts’ project and it takes a good understanding of the underlying technologies. I thought I had a basic understanding, however, I have found that the OpenSprinkler firmware much more difficult to work with.

I recoginise that these issues are down to my lack of skill and or knowledge but even Mr Google makes it easier to find working solutions with Dan’s software. This is not a criticism of OpenSprinkler as I understand that so much time has gone into development. Really wish that softwares had very different names as would make research so much easier.

The beauty of Dan’s system to me was the ease of network configuration and running automatically at boot. These things have been so much more difficult with OpenSprinkler.

OSPi dead simple to set up and make bulletproof (wifi and restarting software automatically at power failure), OpenSprinkler works with sensor. Probably PICNIC or PEBCAK but just my experience.

[Ray]

“I have found that the OpenSprinkler firmware much more difficult to work with” — this is understandable, because the unified firmware is written in C++, which is less flexible than a script language like Python. I know that people are more comfortable working with Python than C++. However, we don’t have the resources or time to manage two different programs, and the unified firmware allows us to make the firmware compatible across all OpenSprinkler platforms, so that features will be made available to them simultaneously.

That being said — I don’t think the Unified Firmware is that difficult to work with. Most function names are defined to be easy to understand, and I’ve put comments throughout the program.

“The beauty of Dan’s system to me was the ease of network configuration and running automatically at boot. These things have been so much more difficult with OpenSprinkler.” — I don’t think these have anything to do with the program itself — network configuration is part of the RPi setup procedure, and setting a program to auto-start on boot can be done for any program. My forum post include specific instructions on how to set OpenSprinkler firmware to start on boot. Let me know if anything there is unclear.

[atom]

Greetings Ray,

I am sorry if my comments were perceived as a criticism of your awesome work, and if so I unreservedly apologise. Your rapid response is a tribute to your excellent customer service and sets a benchmark that not many others can achieve.  Thank you.

I have followed the installation instructions, verbatim. I cannot get the cron job to automatically start OpenSprinkler on reboot. I know that I will work things out and will continue learning.

Thanks again.

 

[Ray]

There are multiple ways to set a program to run on boot. I basically followed suggestions by Samer to create a cron job, which seems to work for me. Dan and Rich both used a script to install the program to /etc/init.d/ folder. It should be very easy to replicate the script for the unified firmware. As I said, setting a program to run on boot is a Linux thing, it does not have to do with the choice of firmware.

[atom]

Fair enough Ray.

It is your baby and I never said it was an ugly one.

The documentation and implementation of Dan’s software kicks ass compared to the the original firmware. It is vastly better documented and that is why I rate it over the initial firmware.

Be as defensive as you like if but if you cannot take user feedback on board with grace, your rapid fire support is greatly diminished.

Please, as the Owner/Creator make the software versions have unique identifiers that Mr Google can’t confuse.

How about an up-to date wiki with tested clean install instructions? I will gladly contribute my experiences.

A burnable image would place your fantastic product into the realm of commercial operators.

Sorry, I have been as polite as possible but please realize your product could be made more user friendly. Hardware and support is ABSOLUTELY AWESOME the documentation needs work.

Utmost respect for giving birth to such an awesome project.

[Ray]

Well, the Unified Firmware for OSPi is currently in Beta testing stage (as I mentioned in the post). So there is very minimal documentation at the moment. The goal is that as soon as it becomes stable, and potential bugs are fixed, we will make a pre-configured SD card so that users can just burn and use it right away. These have all been described in the original post about the Unified Firmware. Thanks.

[Author]

Posts