Forum Replies Created
-
Posts
-
There are some choices of water meter you can find on the market (if you are in the US, you can search on Amazon). These water meters usually have a reed switch inside and sends out clicks (i.e. the switch opens and closes), the frequency of which depends on how fast water is flowing through the meter. We are actually working on getting this supports in the official OpenSprinkler firmware, however, at the moment we are planning to support just one meter so if you need two meters or more you will have to connect some additional wires.
1) If you use a DC power supply, you may see the effect that the valve will turn on but will not turn off. Because triacs (which is what OpenSprinkler uses to switch solenoids) are only meant to switch AC current, not DC current. However, if you have a small load (like an LED light or something) it should still be able to turn them off. For additional details, you can read about how triacs work to see why they are not meant for DC current.
2) manual_run_program will indeed immediately stop all existing running programs. You can see that in the code of that function.
On the official version C7 is not populated. If you want you can put a 0.01uF capacitor there. It’s a filter cap and the exact value doesn’t matter very much.
D1 should be in the direction that the anode (positive) is connected to the fuse, and cathode (negative, with a strip on the component) is connected to capacitor C1.
From your pictures it looks like the LEDs on the Ethernet jack are not lighting up, not even the green LED. This might be caused by a defective ENC28J60 Ethernet controller, or the 25MHz crystal. Both are pretty easy to source on Digikey or Mouser for just a few bucks.
But before you proceed, the ‘buttons’ not working might be related to the Ethernet jack. Can you be more specific about the ‘buttons not working’? Which buttons, and why did you think they are not working? Note that if you have the latest firmware 2.1.5, the button functions have changed. There is no longer a ‘test’ mode at start-up, instead, you can run a test program (using button B3) after the controller has powered up. For details, please refer to the user manual.
I am not sure about the RPi SD card corrupt issue: I have a test RPi 2 running for several weeks and I’ve not had any corruption issue.
Hi, we are working on adding flow sensor support to the firmware and at the moment the plan is to support one flow meter connected to the rain sensor port. So the rain sensor port will have dual functions: you can either use it to connect a rain sensor or a flow sensor. At the moment we cannot support more than one flow sensor — but in most cases one flow sensor is probably sufficient, especially since in most cases the stations run in sequential mode. Robert on the forum has provided his implementation of flow sensor, and our code will be based on his as a starting point.
The controller is set to perform NTP sync every 24 hours. Are you consistently seeing 30 minutes delay in time, or does it change over time?
Can you export your controller’s configurations and attach them here? I am traveling in China and I can’t access dropbox (it’s blocked in China). If you need to attach an image, you can attach it in the post here — the forum support image attachments.
Sure, it makes sense. You are right that this part of the code should be added in the ‘if (os.old_status.rain_sensed != os.status.rain_sensed)’ block because you want to make sure it only triggers the program once every time the rain sensor status changes.
I am not sure how you plan to implement run_program() and stop_program() functions. There is a ‘manual_start_program’ that’s already implemented and you can certainly make use of it. Note that since programs usually come with specified water times, so once starting they will eventually stop after the specified water times have elapsed. Therefore I am not sure what ‘stop_program’ is really doing. Perhaps you meant calling reset_all_stations there?
“I read how you intend to discontinue the relay on the OPSi board. It sounded like primarily a cost decision”
Well, it’s partly to save cost, but the primary reason is that very few people make use of the relay, so we don’t want to keep an expensive feature that few people use. Also we are in the process of developing a standalone open-source garage door opener, so I hope not to keep overlapping features between different products.I appreciate your suggestions, but honestly the lessons we learned from a business point of view is that it’s better to not offer a variety of versions of the same product. The reason is that keeping different versions make it harder for users to choose, and it’s difficult to predict demand and expected inventory of each version so it’s harder to remain profitable. Already we’ve been getting questions all the time about the difference between OpenSprinkler, OSPi and OSBo, and creating further divisions in OSPi will just make the situations worse. Someone with hacking skills can always create a customized, hackable version themselves, and enjoy the making process. For us, it’s a big investment to make a entirely new version, with new enclosure, and without knowing the size of the market in the first place. Hope this makes sense.
This is definitely the first time I”ve heard of such an issue. I can’t think of any hardware or software reason that would cause it to send a ‘split-second impulse’. I honestly don’t have any information to explain why it’s doing so.
OK, this is an interesting feature that I’ve not thought about before. I think it’s easy to add a ‘delay zones by xxx minutes’ feature, but I would be cautious to add a ‘pause until I click on resume’ feature, because if you forget to click on resume, it can pause forever and stop future programs to run.
Quick update: as we’ve announced in this post just now: https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-5-major-bug-fix/, a major DHCP bug was discovered today, which explains the DHCP issues you’ve seen. The symptom occurs when you have DHCP reservation set up for OpenSprinkler (e.g. DHCP lease time is infinity). This triggers the bug and causes the controller to repeated send DHCP requests. The bug is now fixed. Hopefully it has addressed some of the issues users have encountered here.
The firmware uses the Arduino DS1307 RTC library, which supports both DS1307 and DS3231:
http://playground.arduino.cc/code/timeWhich firmware are you running on the OSPi? We’ve recently updated the OSPi pre-configured SD card image and the default firmware on start-up using the new SD card image is the OpenSprinkler Unified Firmware. In case you are running other firmwares, like Python Interval, or Rich’s sprinkles_pi program, please specify. Thanks.
The shutdown issue you are reporting might be due to mechanical issue with the valves. To test, I suggest that you try to turn off OpenSprinkler directly by switching off its power switch. Does the same issue happen? If so, that mean the issue has to do with the sprinkler valves (i.e. the way that they close under water pressure).
This is a general-purpose waterproof enclosure that has built-in outlet and is big enough to fit one OpenSprinkler, transformer, adapter, plus a couple of expansion boards:
http://www.amazon.com/Orbit-57095-Sprinkler-Weather-Resistant-Outdoor-Mounted/dp/B000VYGMF2To add to what Samer said: the main reason to query the cloud is to enable features such as automatic time zone and DST detection, and getting sunrise/sunset times. In the past we’ve always had users who complain that every year when DST changes the controller could not automatically update time. This is the main motivation behind adding the support. But as Samer said, the cloud connection is not critical to the operation of the controller — if there is no connection, it simply won’t perform NTP sync, won’t auto-detect DST, sunrise sunset times will be set to a default value, sprinkler programs will run as usual.
Of course as the firmware becomes more complex, to accommodate all different scenarios, there are inevitably some bugs that we may not have discovered during testing. But it has always been our intention to make OpenSprinkler a device that works independent of the existence of Internet. If there is any feature you don’t like about the firmware, feel free to modify the source code — the project is made open-source to provide flexibility and any customization you may need.
Re: “When network connectivity is lost, it might be useful to log that condition.”
I agree it may be useful to log it in case the network checking fails several times in a roll.Re: The controller won’t ping or do time sync’ing when a program is running.
Do you have just one single program over that period of time or multiple programs that run one after another? If you have just a single program, ping shouldn’t occur until that program is finished. If you have multiple programs, ping will occur at the end of each program.“The DHCP behavior while triggered by some issue also showed that the OS could be a poorly behaving DHCP client. This seems like a concern because it could potently be triggered by something different than whatever was addressed in 2.1.4(new).” — perhaps I didn’t explain this correctly: with the bug in the old firmware 2.1.4, if time changes (say, after NTP sync, time has gone back 1 minute), this could immediately trigger the device to reconnect due to DHCP renewal timeout, and the precise reason is that the bug turns a negative number into a large positive number; when the first DHCP request comes back, time hasn’t elapsed that much yet, so it still thinks DHCP has expired and sends out a second request. This goes on until the timeout turns back from a large positive number (which should have been negative) to 0, and then it will stop sending DHCP requests. Hope this makes sense.
“I don’t know what the controller uses the pings for” — this is for periodically checking if the controller is still connected to the router. Most systems have to do the same to make themselves aware of the network connectivity. If the connection is lost, it will try to re-establish connection after some time out. This is quite important because if your router went down and came back up, the device needs to be able to re-establish connection, otherwise it will lost the connection forever until you restart next time.
Samer is right in that while a sprinkler program is running, the device will pause sending ping requests until the program finishes. This is the line in the source code that bypasses network checking while a program is running:
https://github.com/OpenSprinkler/OpenSprinklerGen2/blob/master/main.cpp#L927
Similarly while a program is running the device will not perform NTP time sync, for the reason that if time changes while a program is running it may mess up the program run time unexpectedly.
