Forum Replies Created
-
Posts
-
OSPi uses a shift register to drive the solenoids, not direct GPIO pins. The shift register itself uses 4 GPIO pins.
To clarify, each log file is named by a number that’s the epoch time divided by 86400 (the number of seconds in a day). The epoch time counts the number of seconds since Jan 1, 1970, so that divided by 86400 gives the number of days since Jan 1, 1970. For example, the log data of Apr 20, 2015 would be stored in a file named 16545.txt.
Hi Sean, to diagnose the issue, the easiest way is to use the RFToy to listen to your OSPi when it sends the signal, and see if it can decode the signal. If nothing is detected at all, it might be a wiring issue. If it detects the code, but the last four digits (which record the signal timing) is very different, that’s most likely due to a timing calibration issue, and that’s easy to fix by tweaking the last four digits.
This is likely an issue with the real-time clock or its battery. You should check if the CR1220 battery is installed correctly, and check if it has sufficient voltage (at least 2.7V or above).
My understanding is that RPi 2 model B is the only RPi 2 available out there.
I have to complain that the RPi version naming is very confusing — for example, I would imagine someone may easily confuse the original RPi model B with RPi 2 model B — they have different form factors. I wish RPi foundation had used a different letter, like RPi 2 model C, so to eliminate the confusion. As is it’s already getting hard to keep up with all the different versions out there 🙂
Older versions of the firmware store the log files in root directory, more recent ones stores them in a folder called LOGS (in order to get files better organized).
Hi Sean, sorry for my confusion, now I understand, yes, you have OSPi (I was judging from the picture you posted that you have an OSDIY).
So, I have to clarify to you that only recent OSPi Plus boards (version number 1.42) have added the pin headers for RF transmitter. What you have is probably the original version which comes with a yellow relay and not RF transmitter headers. Since a couple months ago, we’ve decided to retire the relay, but instead add RF pin headers.
The firmware by default uses the same pin (originally assigned to relay) for the RF transmitter. So I think the easiest way is probably to pick a different GPIO pin (GPIO18 is recommended), and modify the firmware to match your new pin. Check the attached image for suggested pins. Basically you can connect RF transmitter’s DAT, VCC, GND pins to GPIO18, +5V, GND pins marked in the image. (although the transmitter can work with 3.3V, use 5V helps boost its transmission range). Next, modify the PIN_RF_DATA defined in defines.h (under the #if defined(OSPI) section) to 18 (originally it’s 15, which is the same as the relay pin). Then recompile the firmware. This should allow you to use RF transmitter. Let me know if this is clear.
Attachments:
What you have is a microcontorller-based OpenSprinkler (looks like it’ a DIY kit), it’s not OSPi. So this is actually not the right subforum for this post.
The A3, VIN and GND are the three pins to connect to RF transmitter (they correspond to DATA, VCC and GND). I apologize that the user manual is only showing an exmaple for the fully assembled OpenSprinkler, while yours is a DIY kit. But yes, A3, VIN and GND are the three pins you are looking for.
That’s really strange, that the LCD displays messages normally just not when you press B1. I would suggest that you use the Firmware Updater to re-flash the firmware and see if that resolves the issue.
The only difference between OS 2.3 and 2.2 is that 2.3 uses ATmega1284p and 2.2 uses ATmega644p. Because this upgrade went ahead of plan, we haven’t properly documented the difference yet. At the moment the firmware is the same for both, although 2.3 is clearly has more flash memory space and RAM space for future upgrades. As I said, the main reason we upgraded is that ATmega1284p ends up costing less than ATmega644p.
I honestly have no idea. If Windows’s Device Manager reports it found USBasp and there is no question mark or acclamation mark, it means the device driver is installed correctly. Did you click on ‘Detect Device’ before ‘Upload Firmware’? Since you already know you have OS 2.1, you can skip ‘Detect Device’, just simply select OpenSprinkler_v2.1 from the dropdown list and click on ‘Upload Firmware’ (assuming the device is in bootloading mode prior to clicking on ‘Upload Firmware’).
In your first post you said ‘see attached picture’ but I don’t seem to find any attachment. Here are some basic steps to diagnose:
1) Does the LCD turn on and display messages? If not, it’s likely something is wrong with the 16MHz crystal (for the microcontroller) causing it to not start.
2) If the LCD turns on but get stuck in the ‘Connecting…’ step, it’s likely an issue with the Ethernet controller and/or 25MHz crystal.
3) After the LCD passes ‘Connecting…’ step, click on B1 and check to see what IP address it’s assigned. If you have a more recent firmware you can click B2 to see the MAC address (but if you have an early version of firmware B2 will not show MAC address).
Let me know your findings.
You can use the rain sensor port for sure — a rain sensor itself is a switch (i.e. activated or deactivated by rain). You can connect a normal switch to rain sensor port, and when the switch is closed the OSPi will stop watering. However, the firmware currently does not support any ‘suspend’ function — if a program is supposed to run while the switch is on, the program run will be skipped and will not be kept in the queue. Hopefully the chances of your pool filling overlapping with sprinkler run are small.
The verification error may be due to defective crystal or perhaps the bootloader has corrupted for some reason. Is this a DIY kit or you purchased it fully assembled?
Sure, OSPi can parse XML. If you are using Dan’s Python interval program, it should be pretty easy to add a module to parse XML data from your server. If you are using the unified firmware, it’s a bit tricky because that program is written in C++ which means it’s not as easy as Python to parse XML.
The way the unified firmware parses weather data is that it queries the opensprinkler.com cloud server which runs a Python script. So the cloud server serves as a middle man between OS and WUnderground. If you can modify your server to return data in simpler format, that should work a lot better. You can take a look at weather.cpp in the unified firmware code to see the format of the output data from the weather script.
The RTC is optional. It’s really meant for situations where the controller is back from power loss, but there is no Internet yet (so the controller cannot perform NTP sync and will start with a wrong time).
At the moment we are recommending either powerline adapters or the TP-LINK WiFi adapter. I agree that build-in WiFi would be a better solution, but it’s not really cost-effective. The TP-LINk adapter is $20 and powerline adapter is $30. These are not that more expensive than USB WiFi dongles. Also, powerline adapters are more reliable and less prone to WiFi signal issues.
As another part of the added cost: having built-in WiFi means the product needs to be FCC certified (OpenSprinkler is FCC verified, and does not require certification because it doesn’t have intentional radiators). Having intentional radiators means we must test the product to acquire an FCC ID, even if the circuit is made of all FCC-approved parts.
I did look at RachIO’s IFTTT a little while ago. For the micrcocontroller-based OS, this will probably only be available once we have cloud-based service, because the microcontroller is not powerful enough to handle the requests directly. For Pi and BBB it should be achievable locally without going through cloud.
Yes, you can connect a rain sensor to your 1.1. Please check the OSPi user manual:
http://rayshobby.net/docs/ospi14_manual.pdf
page 10, RPi pin uses. According to the diagram, the firmware uses GPIO 14 as rain sensor. What you need to do in terms of connection is: VCC (3.3V) -> 30K (or 27K) resistor -> one wire of rain sensor, and the other wire of the rain sensor -> GND. This way, the pin is pulled high by default, and when rain sensor clicks it’s pulled to ground.The current version of OSPi also has a 4.7K resistor in series and a TVS in parallel to the rain sensor port, to protect it from transient voltages. These are optional, but can improve the reliability. For details, you can check the schematic:
https://raw.githubusercontent.com/rayshobby/opensprinkler/master/OpenSprinkler%20Pi/hardware/ospi_v14%2B_sch.pngYes, the firmware had a bug. After spending hours debugging tonight, apparently it’s a bug in setting a socket as ‘non-blocking’. The bug should be fixed now. Please see my post here:
https://opensprinkler.com/forums/topic/programs-only-seem-to-run-when-website-or-app-is-open/#post-36743We are working on this. Currently since program settings do not have a concept of ‘stop time’, our work-around is to allow the ‘duration’ to be the time between sunset to sunrise. This should satisfy the immediate need to use OpenSprinkler for switching lights (from sunset to sunrise). The change should be included in the next firmware numbered 2.1.4. Thanks.
I just updated this thread:
https://opensprinkler.com/forums/topic/programs-only-seem-to-run-when-website-or-app-is-open/#post-36743
Apparently there is a bug in the previous version that was setting a non-block socket incorrectly. The bug is now fixed.UPDATE: I think I’ve found the issue. It’s a bug in setting a socket non-block. It actually has nothing to do with usleep. The bug caused the firmware to stop program time keeping when there is no connection (i.e. socket is blocked). The bug is now fixed. Please perform a ‘git pull’, then do ‘./build.sh ospi’, and restart. Let me know if this solves the issue. Thanks!
I can confirm the issue. I am really shocked to see it, that as soon as the browser is closed, the program seems to have lost response. This is quite alarming. I am sorry that the issue wasn’t discovered during testing because we’ve always had the browser or app open. Now the issue can be reproduced we are trying to figure out the solution. It looks like this either has to do with the usleep introduced in the main loop, or the way non-block SOCKET is implemented. We will immediately look for solutions. Thanks.
@Greg, OK, this seems to be the first request to support a station triggering both masters. We were about to make UI changes to support two master stations, so it’s good to know that.
