Forum Replies Created
@bzublin: thanks (and sorry to hear that your post disappeared: I did recently discover our spam filter had false positives so several posts got incorrectly flagged). About PWM control of solenoid: very clever. As I said, it reminded me of motor or stepper controller: it would be interesting to see if we can use a monolithic motor controller to do the job, releasing the microcontroller from having to carry out the sampling and control loop, though using microcontroller does provide the benefit of software-defined current control, which is handy. I am mainly thinking whether I could change the current OpenSprinkler main controller design to use this method as well, but since each controller can handle up to 72 zones, it’s probably not feasible for one microcontroller to perform that much ADC sampling (which also takes a lot of cycle time). What’s why I am thinking whether you can delegate the job to a monolithic motor controller. In contrast, the nice thing with your 2-wire decoder design is that each decoder has its own dedicated microcontroller, so it doesn’t require one central mcu to handle all valves.
Regarding setting addresses: one method is as you said, turn on each decoder one by one. The main controller can be set in ‘discovery’ mode and continuously send out probing signals, any decoder that has already received a permanent address would not respond, while a newly turned on decoder will respond and obtain the current address, then the main controller increments the address and the user turns on the next decoder. This way the user can simply turn on each decoder one by one, and they will get sequential addresses that way.
Another method is by using the ‘old-school’ dip switch: a 8-bit dip switch can set up to 256 unique addresses. This way there is no need for the controller to discover decoders, however the burden is on the user to make sure each decoder gets a unique index.
About ‘regulated low voltage (5V or 3.3V) from the 30V’ — I have plenty of experience with using switch regulator for this. You are correct that linear regulator is not efficient (unless if we are talking about very low current draw). I’ve seen commercial sprinkler controllers that simply use a zener diode based linear regulator, which really only works if the circuit draws less than 10mA, otherwise too much power will be wasted on the current limiting resistor. Using switching regulator, the old school MC34063 is super cheap and can supply up to 500mA, though it’s relatively low frequency and noisy (under small load you may hear inductor humming). The current OS 3.x design uses XL1509, which is also a low-cost chip that can supply up to 1.8A.
Regarding surge protection, the typical approach is TVS diode and/or MOV (sometimes in conjunction with each other). I’ve taken apart some motorized ball valves which have built-in circuit, and those are pretty much what they use for protection.
Sure, I understand, but this request is too specialized, it’s unlikely that we will be able to implement this for you. The project is completely open-source, you can modify the firmware to add I2C type zones yourself.
This has also been discussed in another thread:
if possible, please stick to the same thread instead of creating a new thread.
since you use uwt=1 (which means the current watering percentage applies), if the current watering percentage is 0 or close to 0, that would result in 0 water time. Perhaps try uwt=0 to begin with, just to avoid that being the factor?August 21, 2019 at 1:00 am in reply to: Error with UIPEthernet while compiling for ESP8266 #62247
I am using UIPEthernet version 2.0.7 and I did not get the error regarding beginWithDHCP. I am not sure why it’s reporting on line 102, if you look at UIPEthernet.cpp, the reference to beginWithDHCP appears on line 82. Maybe you should re-download the library and try again? Also, make sure in the make file you give the correct path to UIPEthernet: sometimes you may have multiple instances of the same library so make sure it’s pointing to the correct one.August 21, 2019 at 12:55 am in reply to: Unicode special characters like Ő Ű break UI/config/operation #62246
Thanks for reporting this issue. We will check and try to fix it soon.
It’s not going to automatically create programs given the constraints of simultaneous valves. Instead, you can manually schedule multiple valves to run at the same time. As I said, each ‘program entry’ can include any set of zones (these will run at the same time). So if you want 4 zones to run at the same time, just choose the set of 4 you want, and create a program entry. Then for the next 4 zones you create another entry, and so on.
@bzublin: I read the document, very nice and detailed write-up. One thing that I noticed is you use DC voltage (30V) and PWM to drive 24VAC solenoid. I’ve never thought about it. Is this a known method to drive 24VAC solenoid? It sounds similar to the control circuit for step motors. I find it fascinating because I’ve always disliked the AC-based system — it’s the industry standard for decades and nobody bothers to change anything, but in modern days DC adapters are way cheaper, lighter, and easier to find than AC adapters, due to their demand. So I really hope the manufacturers will move towards more DC-based controller and solenoids. That’s what motivated me to design the DC-powered OpenSprinkler, which does not use PWM, but the underlying design principle is similar to yours, that is, use DC to drive the solenoid, and making sure the current through the solenoid is roughly the holding current. In any case, I am interesting in hearing more about the PWM method, what frequency do you use, how well does it work, any potential issues you are aware of etc. Thanks.
Try to plug in a microUSB cable connected to a USB adapter to power RPI additionally with USB power. The issue is not with 40VA power adapter, the issue is that when OSPi was designed, it was only meant to drive 0.5 to 1amp on 5V line, and since then the new RPIs each version keeps requiring more current so it can’t keep up. Providing USB power to RPi directly should address this issue.August 16, 2019 at 3:25 pm in reply to: Announcing the new ET algorithm and weather service changes #62186
Probably in a couple of weeks? I am returning from vacation and the bulk of FW 2.1.9 has been done. Right now finishing UI implementation and doing final testing.
Why not use expanders? OSPi supports expanders, each adding 16 zones.
Why not use OpenSprinkler expanders? OSPi supports expanders, each adding 16 zones.
- This reply was modified 1 week ago by Ray.
@bzublin: very interesting. This is probably the first open design of 2-wire system I’ve ever seen. It’s very intriguing and I will take a closer look at your design and documentation soon. Thanks for sharing!August 16, 2019 at 3:14 pm in reply to: Can I use old sprinkler controller to power LED Malibu lights? #62178
Keep in mind we also have DC-powered OpenSprinkler, which can run on a DC power adapter with output voltage anywhere between 7.5V DC to 12V DC. This can directly drive 12V DC LED strips.
I do plan to add new types of programs to the firmware which allow you to specify the zone ordering arbitrarily. This will largely follow how OSBee’s programs work, which has already been implemented in OSBee firmware. Basically each program consists of a number of program ‘entries’, where each entry is a set of any number of zones (could be a single zone or could be multiple simultaneous zones) and the associated run time. A program can have a maximum of, say 64 entries. This will allow you to run zones basically arbitrarily. Simplest speaking, each entry is a mini-program and an actual program is made of multiple of these entries. The reason this works well for OSBee is that it only supports 3 zones, so the user interface for such type of programs is easy to implement and looks fairly clean. On the other hand, OS supports up to 72 zones, so the user interface will look a lot more messy and that has been my hesitation. Also, as Samer said, with that many zones the storage becomes an issue that cannot be overlooked. In the past the programs have been stored in EEPROM on OS 2.3 (the size of which is only 4KB) and prior (and flash on OS 3.0). With the upcoming firmware 2.1.9, the programs on OS 2.3 will be stored on external SD card, so the storage will no longer be an issue. We are unlikely to get the program type changed in firmware 2.1.9, but it can be planned for 2.2.0.August 16, 2019 at 3:04 pm in reply to: get actual station runtime using api (FW 2.1.7) ???? #62176
Go to the API document:
check the /jc (controller status) return value, there is an array called ‘ps’ which shows the program and run-time information of each zone.
The main changes probably would be the low-level functions such as apply_all_station_bits — that part of the code triggers the solenoid drivers to open or close valves. Since the main difference of OS and OSBee is what ESP GPIO pins are used, you can follow the dependency on the PIN defines and make changes appropriately it should be fairly easy to get the unified firmware to run on OSBee.
As you said the programs are stored in the EEPROM and it shouldn’t have got lost even if power is lost many times. I am not really sure how it happened — it could be that some weird condition triggered a factory reset which wiped out the programs.
If it doesn’t show any minor revision number, then it’s likely you have minor revision 0, which probably didn’t implement this API. Firmware 2.1.9 should be ready soon, we’ve finished the bulk of the implementation and just finishing up UI implementation and doing final testing.
result: 16 means some data is missing:
I am not quite sure why you are getting this return value. You said your firmware is 2.1.8, but do you see a minor revision, like 2.1.8 (3) is minor revision 3? I could be that you are on an earlier minor revision of 2.1.8 that doesn’t support the en= parameter in /cp.
OK, thanks for the report. Will try to improve the auto reconnect functionality in the net firmware.August 12, 2019 at 5:50 am in reply to: Watering not every day – supported by weather-based algorithms? #62104
The ET algorithm always uses yesterday’s weather parameters (temperature, humidity, precipitation), it does not include today’s precipitation so far, so the watering percentage calculated might not look ideal but keep in mind that today’s weather parameters will be accounted into tomorrow’s watering percentage.
Whether you use ET or zimmerman algorithm, it calculates watering percentage once per day, so the number remains the same until your local time crosses midnight. It always uses yesterday’s weather parameters — I agree that using the accumulated weather parameters over the gap between two runs would be better, but that would involve a lot more changes to the weather script, and it might not always be possible (for example, if you set a program to run every 14 days, I don’t think the weather provider gives history data of that long).
- This reply was modified 1 week, 5 days ago by Ray.
For each program, you can set it to repeat many times a day, by either specifying the second start time, or use the ‘repeating every’ option.
Both the microcontroller-based and Pi-based OpenSprinklers run the same unified firmware. If you choose OSPi, the basic functionalities are the same, except it doesn’t have LCD, buttons, and you need to provide an RPi. There is NO need to trigger programs via bash.
The stock firmware does not support AP-mode operation, but it’s not difficult to modify the firmware to do that.
The OSBee has not been discontinued yet — we still have some in stock and the product is active. I did not compile the OpenSprinkler firmware for OSBee — because OpenSprinkler 3.0 Latch is available, that runs the standard OpenSprinkler firmware. If you want to run OpenSprinkler firmware on OSBee, you may wants to search the forum or Google it because I feel someone has done that previously.August 5, 2019 at 6:00 am in reply to: Firmware upgrade of Rayshobby Raspi 1.2 doesn't work #62026
Did you look at Section C of the instructions? (Stopping various versions of sprinkler program from running)
If that doesn’t work, just burn a new Raspbian from scratch and follow the instructions to install firmware.