Forum Replies Created
-
Posts
-
Please note that tick() is called inside the maintain() function:
https://github.com/OpenSprinkler/UIPEthernet/blob/master/UIPEthernet.cpp#L139
you can certainly change the call to tick() to maintain() but maintain() is heavier weight than tick().The build instructions were outdated and I just updated them. Two things:
1. using esp8266 core 2.7.4 is fine as the firmware has been verified to compile with 2.7.4 (though 2.5.2 should also work fine)
2. for the UIPEthernet library, use the one that we’ve modified (it contains some dhcp fixes and customization). This is available in the OpenSprinkler github repository, and here is the direct download link:
https://github.com/OpenSprinkler/UIPEthernet/archive/fixes/dhcp.zipI’ve never used 74880 baud rate. Common baud rates for ESP8266 are: 115200, 230400, 460800, and 921600. Generally 230400 is pretty safe regardless of what auto-reset circuit there is; and 921600 is occasionally too fast for boards depending on the auto-reset circuit design.
LPM means liter per minute, which does not provide enough information about the number of pulses / clicks.
‘1.037 pulses per lpm’ has the wrong unit — it should be pulses per liter or something like that. I think 1.037 pulse per liter sounds quite slow — a flow meter like this generally produces a lot of clicks. For example, this sensor:
https://www.amazon.com/Uniquers-Flowmeter-Counter-Plastic-Threaded/dp/B075VLZVDM
which is similar to yours, specifies the pulse per liter is:
Pulses per Liter: 450
or in otherwords, liter per pulse is 1/450.Once a controller is set up as remote controller, many functionalities are disabled, mainly because the remote controller is regarded as if it’s a physical extension board wired to the main controller, so it cannot schedule zones on its own, its purpose is to passively listen to the command sent from the main controller. If it schedules zones on its own then it will lose synchronization with the main controller.
If you do want to use the program switch on the remote controller, just remove its extension mode (at the homepage, the status bar, where you see it says extension mode, click it and reset it back to normal mode). This way it can be an independent controller, so the sensors will work, but it also listen to the main controller.
First, please be aware that the latest firmware is at:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware
the LCD library can automatically detect both parallel type and I2C type.Second, if you built your own: version 2.3 uses ATMEGA1284, not ATMEGA644. You can still flash earlier versions of firmware (prior to version 2.1.6) if you have 644, but the latest firmware is too large to fit on 644, so you will need 1284. Also, a blank MCU does not come with bootloader, so either you can use a ISP programmer to flash the firmware, or you use ISP programmer to flash the bootloader then you can flash any firmware using the USB port.
Very interesting. Coincidentally, a user recently contacted me about extending the capability of OpenSprinkler, such as support for 1-wire devices, and in the middle of thinking about this, I decided to make an extension module which make use of the existing zone expander connector to hook up various I2C devices. Because OpenSprinkler 3.0 zone expander uses I2C, the connector has all the necessary pins. So I am thinking of making a variant of the zone expander called 1-Wire / Analog extension module, which plugs into the zone expander connector, and it will serve as a 1-wire device master, and also will have ADS1015 / 1115 to provide analog reading capability. The nice thing about this is that just like the zone expander, it will have a incoming 2×5 connector and outgoing 2×5 connector, so existing zone expanders can still be plugged into this module. So some part of this plan happen to coincide with your idea!
I would be careful putting two controllers in parallel. The reason is that the internal mechanism of how each controller switches a solenoid can be different, and if both try to turn on the same solenoid at the same time it might result in shorting. I think if the following two conditions are satisfied it should be safe:
1. each controller uses its own power supply, no sharing of the same power supply
2. it’s guaranteed that the two controllers won’t turn on the same solenoid at the same time.The firmware already allows you to change the HTTP port. Go to Edit Options -> Advanced -> HTTP port. You will have to restart RPi or restart the OpenSprinkler process after this, for the port to be effective.
My post above:
https://opensprinkler.com/forums/topic/recommended-flow-meter/#post-66055
explains how to search it on amazon. Unfortunately 2-wire meters are generally a lot more expensive. In the US it’s generally $60 USD and above. But they are a lot more accurate and reliable that the cheap 3-wire type.One issue is that the links are all https — secure http — the HTTP station feature does not support https, it has to be http, which probably explains why it doesn’t work.
First, thanks for sharing your project. Regarding the question “Any ideas where to init the sensors” — can you be more specific? Did you mean where in the firmware code to init the sensors? Generally initialization code can go to OpenSprinkler.cpp, look for the
OpenSprinkler::begin()
function. But if your code requires network to be ready, then it should go to main.cpp, look for the
do_setup()
function. There you will see mqtt.init.If pid is 99, then it’s a manual run. Otherwise, the pid would be a valid program index (since there can only be up to 40 programs, a valid program ID would be from 0 to 39).
Both are ok. If you don’t open more than 2 zones at the same time, then 1A is sufficient. If you need more zones to turn on simultaneously, then go with 3A.
Yes I am looking into combining the two libraries so that the firmware can dynamically choose which one to use based on the detected result.
Please take a look at the technical support page:
https://openthings.freshdesk.com/support/solutions/articles/5000859137-troubleshooting-and-technical-help
and scroll down to the question about “My controller’s LCD went bad. How can I get it replaced?”.PR stands for “Pull Up”. It’s used on OpenSprinkler 2.x as a way to detect how many expanders are daisy chained with the main controller. For OSPi it isn’t used because of the lack of analog reading ability of RPi (although OSPi has a ADC chip, it’s never utilized by the firmware). So on OSPi the “PR” line is tied to ground.
On the expander the PR line is actually connected to a 4.7k resistor and the other side of the resistor is connected to ground. The idea is that the main controller (OpenSprinkler 2.x) pulls the PR line up through a 10K resistor, and each expander pulls PR down to ground by a 4.7K resistor. So by checking the voltage on the PR line using an analog pin, the main controller can detect how many expanders are connected: since each additional expander adds another 4.7K resistor in parallel, it changes the voltage divided by this resistor network.
OSPi has a switching regulator that generates 5V DC from 24V AC input power. By “single power supply” it means the same 24V AC power is used to drive solenoid valves as well as powering RPi.
For users outside of US/Canada/Mexico, please find 24V AC power supplies locally in your country. AC power adapters are NOT regulated and the ones we sell are only rated for 110V input. So it cannot be used in other countries.
For OSPi, you will NOT see NTP option because time is managed by your RPi, the firmware does not manage time directly. So if you get a wrong time, you should check your RPi settings, there you can change NTP server etc.
For microcontroller-based OpenSprinkler, the firmware allows you to choose which NTP server you want to use. Since firmware 2.1.9(4) the default is 0.0.0.0, which tells the firmware to use pool.ntp.org. Otherwise if you put in a custom server IP, then it uses that IP.
This can be done in two ways: the easiest is probably to use an external server, like a Raspberry Pi, which receives data from the sensors, computes watering level or any adjustment you need, and use OpenSprinkler’s HTTP API to send the result to OpenSprinkler, say, to modify the watering level, trigger a rain delay etc.
The more difficult route is to modify the OpenSprinkler firmware to read the sensors. This is harder due to the limited computation resources of the microcontroller, and also you will be restricted to use C++ as that’s what the firmware is written in. In contract, with the first approach you can use any scripting language you want.
