Forum Replies Created
-
Posts
-
Instructions to compile firmware can be found on our support website:
https://support.opensprinkler.comI don’t think there is any side effects. Maybe one thing to be aware of is to avoid triggering reboot when a program is running. If you are sure no program will be running at some specific time, you can trigger a reboot at that time. Otherwise you can also poll the controller status to see if any program is current running, and avoid triggering the reboot if that’s the case.
Setting it beyond 240 will require modifying the firmware. A work-around is to find where the sensor delayed off time is applied, and scale it up (like multiplying it by 10, or whatever factor that’s sufficient to cover the amount of time you need).
Did you purchase OSPi from us or are you using your own build? Are you using relays? If so, be aware that many relays boards use ‘active low’ logic, which means they will activate when the signal is low. OSPi uses ‘active high’ logic, so it will be the exact opposite.
The numbers you are referring to here are ‘pulse rate’, they are not pulse frequency. You can get a rough idea of pulse frequency if you know your water pipe’s flow rate (i.e. how many liters per second). The flow rate divided by pulse rate is the number of clicks per second.
For example, if you choose the 1L/pulse version, and your flow rate is roughly 5 liters per second, then while water is running it will generate roughly 5 pulse per second. I think anything below 10 pulses per second is ok — if the frequency is much higher beyond that, the controller may miss some clicks and consequently the flow reading may be inaccurate.
The way DC-powered controller works is as this: it’s powered by a low-voltage (7.5VDC to 12VDC) adapter, and it has a built-in voltage booster to generate a high impulse voltage — the impulse voltage will energize the solenoid, then it lowers the voltage to input voltage to provide holding current.
Other than it needs to be powered by a DC adapter, it works the same way as AC-powered controller. If you are based in US or Canada, your package will include a 7.5VDC adapter. Otherwise, you need to find a DC adapter yourself — 9V and 12V are both quite common.
This will require modifying the firmware. A work-around is, as you said, reboot the controller every day. If you are ok with writing some script, you can certainly write an external script that automatically triggers a reboot of the controller each day. This can be done by making use of OpenSprinkler’s HTTP API.
Unfortunately OS 3.0 only works with expander version 3.0. It’s not compatible with expander 1.x or 2.x.
In AP mode, you need to have your laptop or computer connect to the AP name that OpenSprinkler creates (the OS_xxxxxx SSID). Then once connected, open a browser and type in: http://192.168.4.1/update
To enter bootloading mode, the correct procedure is as follows:
– remove all power from OpenSprinkler (i.e. remove orange terminal block, and unplug USB).
– press and hold B2, then plug the USB cable in. Then release the button. The LCD will remain off, indicating it’s in bootloading mode waiting for program to be uploaded.If you search “water meter pulse output” on amazon you can find several choices. They usually have two wires coming out of the meter. There are brand names like EKM or DAE.
There are also smaller and cheaper ones that come with 3 wires — those are usually not very reliable and tend to generate too many pulses per second so I wouldn’t recommend them, although they are still usable with OpenSprinkler.
Most rain sensors themselves already have a mechanism to set a delay time when rain is received. This is usually through mechanical methods (I’ve written a blog post about it in the past: https://rayshobby.net/wordpress/using-rainfreeze-sensor-with-opensprinkler/).
I believe the code for handling sensors is exactly the same between 2.1.9(0) and 2.1.9(3). I double checked the two versions source code and didn’t see any difference. So I can’t explain why it makes a difference on your side. I will do some additional test of 2.1.9(3) on flow sensor, but I’m pretty sure I’ve tested it before and it works fine.
Regarding flow count at the end of each station run vs. the type=fl: they are not the same: the former is recorded at the end of a single station run, the latter is recorded when the program queue is empty (i.e. all stations finish running). It’s possible that the former is 0 (because it didn’t register any click during the station run) but the latter is not 0.
The flow value is already logged. Perhaps you mean a different way of logging the flow rate — note that currently it’s only logged when a zone runs. If no zone is running, it doesn’t log flow rate, for the simple reason that it would generate a large amount of log data.
‘sn1’ is determined by the sensor, it cannot be set manually. By setting it manually, did you mean to just temporarily reset its value? Otherwise how long do you want the ‘manually set’ value to last?
The voltage reported (5VDC initially and then 1.8VDC) is unusually low. There are two things to check:
– make sure you measuring DC (not AC) voltage (it seems you are, just to double check).
– remove power from the controller, and use multimeter to measure the resistance between COM (common) wire and the zone that has problem. Most 24VAC solenoids should have a resistance of somewhere between 20 to 50 ohm. If it’s too low, it indicates a shorting, either in the solenoid or in the wiring.Another possibility is that the internal boost converter on the controller is not functioning properly. But judging from the fact that the other zones work, this is unlikely to be the case. Still, if you want to isolate solenoid issues with controller issues, you can do the following:
– remove the COM (common) wire from the terminal block: this will disconnect all solenoids from the controller circuit.
– Turn on the problematic zone for 1 minute, and while it’s running, measure the DC voltage between COM terminal and the zone port. This should give you a voltage that’s somewhat higher than the DC power adapter you are using. For example, if your power adapter is 7.5VDC, the voltage you measured here should be higher than 7.5, indicating the internal voltage booster functions correctly. Basically this is the voltage that the controller presents to the solenoid, before the solenoid is actually connected. Once the solenoid is wired into the circuit, and if the solenoid has a shorting, that will lower the measured voltage significantly (which could explain why you are only getting 1.8VDC).You will need to flash the firmware onto the new chip. The flashing procedure depends on what OS version you have: the very early version of OS 3 (with acrylic clear cover enclosure) has built-in USB serial and you can flash through the microUSB port; later ones (with white injection molded enclosure) do not have built-in USB serial anymore, you will need an external USB serial adapter, such as CH340-based (most inexpensive), FTDI, etc. It does require soldering 4 wires (5V, GND, TX, RX). Internally we use a custom made CH340 programmer, which has a card edge connector that plugs directly into the matching slot at the top of the PCB. Without the custom programmer, you need to solder 4 wires onto the card edge connector pins.
Desoldering the 0 ohm resistor is the best way to decouple the 5V coming from OSPi with 5V coming from USB. However, in most cases it’s fine if you don’t desolder the 0 ohm resistor. The reason is that these different 5V power sources are all based on switching power circuit, which means there is a feedback loop that monitor’s the actual voltage on the 5V line — if the voltage is higher than the internal reference, that particular switching power circuit will turn off. So whichever 5V power source is outputting the highest voltage will take over. For example, if the USB adapter normally outputs 5.01V, and OSPi’s switching circuit normally outputs 4.97V, when they are put together, USB will take over as it has the highest voltage.
Minor revisions (like 2.1.9 (0) or (1) or (2) or (3)) are usually bug fixes. Details can be found at github commit history:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/commits/master
For example, minor revision (3) has the following changes: fix bug with program moveup api; increased ether buffer size for OS 2.3 and 3.0; improve NTP; fix bug in server_change_station that causes buffer overflow when there are a large number of zones.The latest firmware is the default firmware file you see at the download folder. Previous firmwares are in the archived subfolder.
I have responded to your support ticket. Honestly I don’t know — if OSPi is outputting a voltage much higher than 5V, that could explain it, but you measured VIN-GND voltage, that’s about 5V, so it’s normal. I can’t think of any other reason why it would burn RPi.
That’s probably because you are not on the master branch. You can do a
git checkout master
to switch your branch back to master branch.This will require modifying the firmware. I don’t know what type of pressure sensor you have, and what type of signal it outputs. Attaching such a sensor to the controller requires figuring out how the controller can read the signal from the sensor.
I don’t understand the example you gave. If weather adjustment is 100%, that does not change the program run time at all — program run time is multiplied by the weather adjustment percentage number. So if it’s 100%, then a 10-minute long program is still 10-minute long. That doesn’t get reduced to 5-minute.Did you actually observe it or are you just guessing it based on your understanding?
Also, what you meant by “additional start times being used to distribute resource use for long runs” is the so called “cycle and soak” — it’s not at all what weather adjustment is doing. You can use additional start times to split, say, an original 1 hour long program to, say, 15 minutes long but repeating 4 times. This has nothing to do with weather adjustment.
There is no technical barrier — the interval can certainly be 1, there is no boundary problem. It’s just that the current way is what the firmware has been since beginning, and no one has ever requested the ability of settings interval to 1. I think people are used to the way traditional sprinkler controllers work where you set a program, and you choose weekdays the program runs on, and if you want it to run each day, then just select all weekdays. Back in my mind my reasoning was probably that ‘weekday’ schedule and ‘interval day’ schedule should cover different sets of capabilities, so that if one of them already supports ‘everyday’ capability, the other does not need to overlap and cover the same capability as well.
