Forum Replies Created
-
Posts
-
OK, do you know if your relay board is active high or active low logic? In other words, to activate the relay do you set its pin high or low? The reason I am asking is that I know there are many relay boards that are active low logic, in which case you will need to reverse the logic when calling digitalWrite on these pins.
When you said ‘all the relays of the relay board are partial activated (a low light led but the relay don’t active) before to start Opensprinkler….’, do you mean the 3 relays connected to OpenSprinkler, or other, unused relays (i.e. not connected to OpenSprinkler)?
There is a recent post here:
https://opensprinkler.com/forums/topic/flow-sensor-working/
about getting flow sensor to work with the microcontroller-based OS. I know that RPi supports interrupt pins, so the same approach should work for OSPi, but it’s yet to be tested.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.
“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.
OK, glad that you figured it out in the end. As I said, we are now recommending the Unified OpenSprinkler Firmware to OSPi and OSBo users:
https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-3-for-avrrpibbblinux/
which has the same software features as the standard OS.I doubt it has to do with what’s shown on the LCD — if the web UI shows the correct time that means the controller has the correct time.
I’ve found the bug with LCD showing the wrong day of the week. It has to do with this function OpenSprinkler::weekday_today() in OpenSprinkler.cpp. It should account for the time zone. As I mentioned earlier: prior to firmware 2.1.3 the firmware stores local time (after time zone offset) in RTC; now it stores UTC+0 time. Most of the code has been updated to reflect this change, but I didn’t update the weekday_today function. I am pretty sure this only affects the LCD display.
Regarding skipping 1am program: my suggestion is to see if you can reproduce the issue. Also keep in mind that if the program is set to use weather adjustment, it may have been skipped due to 0% watering percentage.
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/Also, I made it pretty clear above that no matter how well the algorithm is designed, there always exist cases that some water cycles will have to be ignored. Because the water time can increase due to weather adjustment, and stations have to run sequentially, you are essentially relying on the fact that there is enough spare time between water cycles for it to catch up. Let’s look at one extreme case: say you have a program that runs stations 1 to 8, each for 1 hour, and the program repeats every 12 hours. Now let’s say the weather algorithm says each station has to run 2.5 hours instead of 1 hour, so suddenly the program takes 20 hours to finish, and there is no way it can satisfy the water time requirement, simply because there is not sufficient gap between each program repetition to catch up with the increased water time. So I think it’s reasonable to require the the repeat cycles to be sufficiently far apart.
My point is that the algorithm will try its best to satisfy the requests, but no matter what, there is always a limit. Even with the best algorithm, you can always come up with cases that it cannot handle, and argue that it has flaws.
One solution is to set the stations to run in parallel mode — that is, any station can turn on at any time, without serializing them. This can solve your immediate need. But again, there is no perfect solution.
To understand your request, can you explain why you want to water the same station again over a short period of time? Why not aggregate it so that you water a longer period of time for the same station, as opposed to water it twice over a short period of time?
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.
Hmm, there may be a software issue I am not aware of. Here are two additional things you can try:
1) Go to /home/ubuntu/demo and there should be a simple demo called selftest. Try to run this (make sure to run this in sudo) and see if that can activate the valves
2) In case you didn’t notice, we have just released the unified OpenSprinkler firmware:
https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-3-for-avrrpibbblinux/
this is a new firmware that’s fully compatible with the standard OS firmware.If neither produce any different results, there may be a hardware issue. You can email [email protected] to proceed.
Did you set your sprinkler programs to ‘Use Weather Adjustment’? This option is off by default. The preview does account for the watering percentage parameter for the future (as long as the weather adjustment method is Manual. If the weather adjustment method is Zimmerman, it will use the calculated percentage for today but 100% for future days)
OK, this may have something to do with a change in 2.1.3 where the internal RTC now stores UTC+0 time (whereas previously it was storing the local time). Most places that use RTC time have been changed accordingly, but perhaps when calculating the day of the week, I forgot to account for this change. Will check it. Thanks for reporting.
“Then dis-assembled the set up, removed the BBB (to isolate the problem) and connected the power and checked with the multimeter directly against the pins. No power.” I don’t understand what this means: without the BBB, the OSBo cannot turn on any station, it needs BBB to send control command to it, so obviously without it there won’t be any output voltage on any station.
When you used multimeter to test, are you actually running the OpenSprinkler program, or at least the test program, so you know the software is actually turning on a station?
As I said, we test each single board and make sure every station works on each board. The likelihood of all stations failing is quite small. Anyways, if you still can’t figure out, send an email to [email protected] and we can have you return the board to check it for you.
If none of the zones has output voltage, I would suspect that the COM terminal block may have a connection problem. All OSBo boards have been tested and we verify that each station can activate a real sprinkler solenoid. However, the test does not check terminal block so that could be the source of the problem.
The exact Zimmerman algorithm is documented here:
https://opensprinkler.freshdesk.com/solution/categories/5000022938/folders/5000099525/articles/5000017312-using-weather-adjustments
It uses the average humidity and mean temperature. The average humidity is calculated from min/max humidity (both reported by WUnderground), and the mean temperature is directly reported by WUnderground. Although the highest temperature may be 82 F, the mean temperature over the day, in your case, was only 53 F. From your screen shot, the 15% result is correct. It’s calculated by 100% + (30% – (15%+79%)/2) – (70 – 53) * 4% = 15%The weather adjustment code is written in Python and is hosted on our server. If you want to customize the formula, you can host the Python script on your own server, and change the ‘WEATHER_SCRIPT_HOST’ macro define in file defines.h accordingly. The code assumes that the script is at:
WEATHER_SCRIPT_HOST/weather1.py
The reason it’s done this way is that the microcontroller is not powerful enough to parse XML data from WUnderground, so it’s necessary to relay the data to a cloud server, which does the calculation and returns the % watering parameter back to OS.We are actually trying to implement ET-based algorithm, which is a more standard way to calculate water time. Hopefuly this will make the weather calculation more accurate.
When measuring the output voltage, make sure that you are measuring AC voltage between the COM terminal and any station that you have turned on. If you happen to turn your multimeter to DC voltage, the reading will be about 0 (because the average DC reading of an AC wave is 0). Also check to make sure the terminal blocks are inserted tightly.
Hi Robert,
Really glad to see that you got a flow sensor to work with OS, and thanks for sharing the code. I’ve done a bit of research myself a while back, and the flow sensor I tried (it’s a very cheap one like this: http://www.amazon.com/1-60L-Effect-Sensor-Counter-FS300A/dp/B00HR6BTYQ) sends out pulses very quickly and I didn’t think it was feasible for an interrupt pin (i.e. may be losing a lot of pulses). The one you used seems to pulse at a much slower rate and it’s perfect for an interrupt pin. Now that the signal can be read reliably to OS, the rest (display, logging etc) is just a matter of software changes. So I think this is a big step towards having flow sensor officially supported by OS firmware.
One quick question: where did you buy the NETAFIM meter? I would like to get one to test as soon as possible.
In terms of the hardware, my plan is to remove the power switch currently on OS and use that opening to fit a small connector wired to the flow meter. In the new batch of OS enclosures, the silkscreen above the power switch opening has been removed, particularly for this purpose 🙂
It’s possible but will require a bit of work: first, OSBee uses the Arduino pin 9 to generate a high-frequency PWM signal for the boost converter. Pin 9 is internally tied to timer 1. In order to change it, you will need to bend pin 9 on OSBee out (so it disconnects from Arduino pin 9), and solder a wire to connect it to some other PWM-capable pin. For example, pin 3 or 11 (both of which are tied to timer 2). Then change the code in OSBee’s library functions accordingly (i.e. setting up timer 2 to use the highest frequency, and also set the correct PIN_BOOST).
Alternatively, is it possible to change your other code to use timer2 instead of timer1?
I don’t think Mega and Uno are pin compatible, so I don’t think you can plug OSBee to Mega.
You are right — the version you have is a slightly updated version 2.2u (basically adding a hardware MAC address chip).
Thanks. Just as a reference link, we wrote a blog post about 24VAC relays that we’ve tested internally:
https://opensprinkler.com/using-24v-ac-relays-with-opensprinkler/@dun4cheap, thanks for your comments. Regarding renaming the product, I did think about it as I was indeed trying to make OpenSprinkler more general and be able to switch more devices other than sprinkler valves. If you think about, it’s fundamentally a web-connected, reasonably complex timer system. Controlling sprinkler valves is obviously one applications, but other types of appliances, and home (indoor or outdoor) lighting also often need time-based control and can certainly benefit from web-connectivity. My hesitation is that I’ve heard from many friends that it’s important to market a product with a dedicated purpose — advertise OpenSprinkler as a general-purpose control may have adverse effect. That’s why I’ve kept naming it OpenSprinkler, with extensions to other applications. Hope this makes sense.
About weather feature with a large-scale installations — one solution is to reduce the call frequency — right now the firmware is sending a query to the weather script once every 15 minutes. In practice it probably doesn’t need to be called so frequently. So reducing it to once per hour can significantly reduce the total number of quires. The other solution is to upgrade wunderground account to a paid type, which gives you a higher quota. I realize that this is a burden on the consumer, and we have been thinking about purchasing a paid account ourselves so that the consumers will not need to apply for a separate wunderground key anymore. We haven’t figured out all the details yet, especially we don’t want third parties to take advantage of our script and drain the quota. So for the time being, the above two solutions should work for large-scale installations.
PIN_SR_LATCH and PIN_SR_OE are pins relevant to the shift register. These don’t matter to you. For example, in the begin() function, comment out all lines that have to do with PIN_SR_LATH, _OE, _DATA, and _CLOCK, and instead, replace them with code that initialize your GPIO pins. Say if you are using GPIO18, GPIO22, GPIO27 for zones 1, 2, 3, just write:
pinMode(GPIO18, OUTPUT);
digitalWrite(GPIO18, LOW);
which sets GPIO18 as an output pin and initializes it to zero. Similar for the other two pins.For apply_all_station_bits(), that function reads out the station status, and pushes out the value to shift registers. You can comment out the entire section and replace it with something like:
byte brd_bits = station_bits[0]; // brd_bits stores the status of the first 8 stations, i.e. those on the main controller
digitalWrite(GPIO18, brd_bits & 0x01); // assigns the status of the first station to GPIO18
digitalWrite(GPIO22, (brd_bits >> 1) & 0x01); // second station to GPIO22
digitalWrite(GPIO27, (brd_bits >> 2) & 0x01); // third station to GPIO27My suggestion is to unplug Pi from the OSPi board, and try to see if the issues persist. This way you can isolate problems with Pi vs problems with OSPi. Keep in mind that the microSD card might have gone bad causing the symptoms you see.
