Forum Replies Created
-
Posts
-
I see why setting negative station delay affects the per zone flow calculation. When a zone turns on, a variable is reset to 0:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L1148
upon a zone finishing, this variable is used to calculate the flow rate.
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L1217
as a result, if the next zone starts before the current zone has finished, this variable gets reset, therefore the current zone will end up with a calculation of 0. This also explains why only the last zone survives because there is no zone following that.To fix this issue would probably require having a per-zone
flow_gallonvariable, so each zone uses its own variable, or have some way to defer the reset of this variable (but risk losing the flow count during the negative station delay time). In any case, the symptom make sense now. Phew.I will double check in the code, but I believe the log only records flow data on a per-program level, it does NOT log on a per zone level. That’s probably what you were observing as only the last zone records flow data. It’s not recorded for the zone, it’s recorded for the program run.
The flow alert feature is different: the alert is checked and calculated after each zone finishes running.
There are no GPIO pins available for connecting a RF receiver. You can get an RFToy:
https://opensprinkler.com/product/rftoy/
which can be used to decode signals.The conversion between L and Gallon can be confusing and I suspect the UI may have a bug in the conversion, especially if the Use Metric checkbox is toggled. So I strongly suggest you ignore the unit, don’t change it. If it shows Liter by default, just keep it as liter, don’t change to gallon, or just treat L as Gallon. If your flow pulse rate is 1 Gallon per pulse, just put the number 1 there, don’t change the unit, even if the unit displayed is L/pulse. In the end, only the number matters, because the firmware doesn’t record the unit. The unit is what the UI attached to the display. If you see X Liter per minute, just treat it as X gallon per minute. Or think of is as X ‘units’ per minute.
The flow alert should send alert as soon as a zone finishes running and the flow rate is above the set flow threshold. There are several things that may contribute to not receiving the flow alert:
1. The flow threshold annotation in the zone name MUST be 5 characters long. Even if it’s something like 0, it needs to be written as ‘0.000’ otherwise the firmware may not detect it as a number.
2. The zone must run for at least 2 and half minutes or more, otherwise the flow rate is unreliable and it will not send flow alert at all.
3. The flow pulse rate in Edit Options needs to be set appropriately. For example, if it happens to be very very small, then the calculated flow rate will be too small to reach the threshold.
4. Make sure your flow meter can generate sufficient number of pulses. We’ve seen some customers use flow meters that generate 1 pulse per several minutes, if the zone runs less than that amount of time, it won’t even click once.As in the original pull request, you can easily test if it’s working by simply setting a flow threshold to 0.000 (i.e. for the zones that you want to test, edit their zone names to have 0.000 at the end). This way, as long as the flow meter clicks at least once during the run time (at least 2.5 minutes long), it should send an alert.
The question is whether you’ve set it in static IP mode (i.e. DHCP mode disabled). It would be easier to check it if you submit a support ticket with a copy of your configurations. You can submit a support ticket at:
support.opensprinkler.comDid you check the firmware version displayed when the controller boots up? It may have firmware 2.2.1(1) already.
Here is one work around you can use. Below I have renamed your original zones 1, 2, 3 to zones 2, 3, 4, you will see why.
1. Set up that pump station as a ‘master zone’ — in Edit Options -> Configure Master, set the appropriate zone as the master zone. For example, if your pump is installed on zone 8, set zone 8 as master.
2. Move your original zones 1 and 2 wires to ports 2 and 3, making zone 1 available as a ‘dummy’ zone. This is used solely to trigger master zone to run (in the beginning like you wanted), and will NOT activate any valve.
3. Configure zones 2 and 3 to NOT ‘Use Master 1’. Specifically, in their zone attribute dialog, uncheck ‘Use Master 1’.
4. Create a program, set zone 1 to be whatever amount of time you need to fill the tank, then the other three zones with their desired amount of water time. This way, zone 1 (dummy zone) will start first (will not activate any valve because that zone has no wire connected to it) — it will activate the master / pump, and fill the tank. Then zone 2 and 3 will run (these two will NOT activate master because their ‘Use Master 1’ has been unchecked). Finally, zone 4 will run and active the master.If OSPi works with another RPi, then most likely OSPi is fine. As you said, probably it has to do with GPIOs on the other RPi. GPIO pin assignments are documented in the OSPi user manual:
https://openthings.freshdesk.com/support/solutions/articles/5000631606-user-manual-opensprinkler-pi-ospi-Are you using AC-powered OpenSprinkler, DC-powered, or Latch? For AC and DC powered, it’s safe to split a wire into 4 and insert them to zones 1, 2, 3, 4 respectively. Each port is logically a switch to ground, so if any port is active, that will activate the solenoid, there is no need to use diode — in fact, using diodes are NOT recommended (especially for AC as that will block half of the AC cycles).
If you are using OpenSprinkler Latch, I need to think a bit more about it.
In Edit Options -> Station Handling, there is an option called ‘Station Delay Time’. It inserts a fixed delay between every two zones. The delay time is fixed regardless of the watering percentage. I know you have just one zone, but there is a work-around to achieve what you want: you split the one zone wires into 4, and connect those to zones 1, 2, 3, 4 respectively. Physically it’s just 1 zone, but logically it’s 4. That way, you can set a program to turn on zones 1, 2, 3, 4 (which physically correspond to the same zone), but it will insert the delay time between them.
Most likely it won’t damage OSPi. Remember, 24VAC’s peak voltage is much higher (1.414 times) than 24VDC, so if the circuit can handle 24VAC, it can handle 24VDC. What would be more of concern though, is your solenoid valves — because of the way solenoid valves work, the current running through them will be way higher under DC than under AC of the same rated RMS voltage. This is explained in my article here:
https://rayshobby.net/wordpress/understanding-24vac-sprinkler-valves/
So the short story is: don’t use 24DC on 24VAC valves, otherwise the valves may burn out prematurely.As to why the valves would only open but not close: that has to do with how triac (AC transistor) works. To turn off, they need a zero-crossing, which happens quickly with AC. On the contrary, with DC, there is no zero-crossing, so once on, a triac will not be able to turn off, even if the gate current is removed.
The most common cause for this symptom is using a power adapter that outputs DC instead of AC. You should check the label of the power adapter, does it have a flat line after ’24V’. If so that’s a DC power adapter.
1) Correct, you can apply regulated 5V to +5V (aka VIN) and GND on the terminal block. You can do so simultaneously with 24VAC transformer plugged into the orange terminal block.
Sometimes people are worried about two 5V sources (OpenSprinkler has an internal 24VAC to 5VDC converter) fighting with each other. This is usually not a problem because both are regulated, so at any time, the one that has slightly higher voltage will take over. But, if you want to absolutely avoid having two 5V sources at the same time, you can do the following: on OpenSprinkler v3, the leftmost pin of the orange terminal block is internally wired to COM (common). You can remove that wire from the terminal block, and also remove the COM (common) wire, then connect these two wires directly together, without going through any terminal block pin. This way, 24VAC will only power the solenoids (and NOT generating 5V via the circuit), and your external 5V will provide the logic level voltage to the controller. This will avoid two 5V sources competing with each other.
2) On DC-powered OpenSprinkler, correct, you can feed 12VDC directly to the DC power barrel (the polarity is center positive, side negative, which is the most common type). No need to mess with the 5V/VIN pin.
(System Idle) is a normal message displayed when the controller is not running any zones or programs.
If you updated from firmware 2.2.0 or earlier to 2.2.1, the WiFi setting will be erased, you need to follow the WiFi configuration step to have the controller log onto your WiFi router again. Factory reset, WiFi reset will also erase WiFi settings. Did you follow the WiFi configuration step in the user manual?If you have AC-powered Opensprinkler, you can get 24VAC relays. These are not the most common type of relays, but they are available at digikey.com or mouser.com if you search for 24VAC relays. You likely need to do soldering as these relays come with pins/legs but not screw terminals. You can also use pump start relays, as they are essentially 24VAC relays but primarily used for switching pumps and are quite bulky. I’ve previously written an article about the various options for 24VAC relay:
https://opensprinkler.com/using-24v-ac-relays-with-opensprinkler/If you have DC-powered OpenSprinkler, you can use solid state relays. These are widely available, and they come with screw terminals so no soldering required. For example:
https://www.amazon.com/SSR-40DA-Single-24-380V-Temperature-Controller/dp/B09NPPLDDTIf you would rather not mess with high voltages and power-line wires, the safest option would be to get an RFToy and RF remote power sockets, then you can use OpenSprinkler to wirelessly toggle power sockest:
https://opensprinkler.com/product/rftoy/Sorry about the delayed response. If I understand correctly, what you want is a display of essentially the time when the last scheduled zone finishes minus the current time, is that correct? Or do you mean just the total run time? The former will account for all pauses, delays between stations etc. The second is purely the sum of all water durations. From your description I assume you mean the former. This should be relatively easy to do, as the UI already knows the scheduled start time and duration of each station, so just need to calculate the end of the last station, and calculate the difference of that from the current time.
Yes, VIN is the +5V pin that’s internally wired to the +5V pin on the circuit. In older version of the enclosure, it’s marked VIN; in newer version it’s marked +5V. This pin is normally used to power certain sensors that require +5V. But it can also be used to provide +5V to the controller. You have to be certain that it should be regulated +5V (not to exceed 5.5V).
If you want to make sure current can only flow in one direction (e.g. from external battery into +5V pin and not the reverse), you can put a Schottky diode inline to control the direction.
The two successful builds are for OS 3.x (d1_mini) and OS 2.3 (atmega1284p). The failed builds are for Linux and Demo, which should be built using the script build.sh and not in VSCode. Their profiles exist in VSCode mainly for the easiness of writing code using VSCode.
You can also select a specific build profile (e.g. d1_mini) in VSCode so it only compiles for that profile and not all 4 of them.Storing run-time in non-volatile memory doesn’t help: 1) flash memories have a limited amount of write cycles. If you write too frequently, like once every few seconds, it will prematurely fail; 2) even if you can write the current run-time into the non-volatile memory, it won’t help in the situation you have a long power break, and a program that would start during the power break won’t have any run-time data generated yet. So the power is back, and the program that didn’t start during the power break won’t start anyways since there wasn’t any run-time data generated for it.
Since other controllers all have this feature you need but are missing the sorting feature, why not go bug them and demand that they implement the sorting feature, then your problem is gone. Convince them that sorting is such a critical feature that it’s insane they haven’t done it yet, and I am sure they will do it for you.
1) By ‘dynamic’ I didn’t mean user-triggered dynamic events. I mean the scheduler works by dynamically arrange all programs / stations as they are encountered. It cannot be easily implemented as a static schedule like other controllers. As an example: OpenSprinkler allows multiple zones to run at the same time. Have you seen other sprinkler controllers that allow this? As one program runs, other programs / stations can start as well, and the scheduler will automatically handle them according to the sequential group flag. So what runs at the current moment is the result of a ‘dynamic’ set of programs / stations that started in the past.
With other controllers, since no two programs can run at the same time, it just scans through all programs, finds which one overlaps the current moment, and starts the program from there. It’s a lot simpler to implement. But this is not how OpenSprinkler works. Additionally, as I said, how far back do you have to start the scan? You could have a program that runs over multiple days. Is the firmware supposed to look back 7 days and check all programs that may start that far back and figure out maybe one of them would have run to the current moment?
Have you seen any other sprinkler controller that uses the concept of sequential group? Sure you may say you don’t run multiple zones at the same time, but many other users do. You may also say you don’t have programs that run over multiple days, but some other users do. If we implement a feature, we can’t do it in a way that work in some situations but not other situations. That would be an incomplete feature.
2) OpenSprinkler has a +5V terminal port, it can be used to power the controller. Find a 5V mini UPS and connect it between 5V and GND and that will keep it running. But it sounds like from your description that you must reboot the controller manually from time to time. I don’t know why, but if you have to do that, this solution won’t help you since it won’t prevent you from rebooting the controller manually.
3) Your example of the moon is super far fetched. If it was your application, you would need to find a NASA-approved equipment. Obviously OpenSprinkler is not NASA-approved, nor FDA-approved either. I can’t help if you need something so mission critical. That’s not our focus. I can’t help if your setup entails multiple reboots / power breaks on a daily basis. This is not our focus.
4) I will say this again: you are asking for something that we don’t have and don’t offer. So either implement it yourself, or find another product that works for you and move on. Spending time here complaining and being angry doesn’t help. It’s like you go to a restaurant and complain that the way they cooked lasagna is wrong. Well, you know that, that’s how they do it. If you don’t like it, go somewhere else and move on.
