Forum Replies Created
-
Posts
-
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.
Well, as I said, you are asking for something we don’t have at the moment, and something that’s not easy to add to the firmware. So either you use the features available to accommodate your need, or just throw away OpenSprinkler and find a product that fits your need. Look, if the feature was easy to add, we would have added it already, don’t you think?
Regardless, I think you are refusing to make creative use of features already available to address your need. For example, if you can’t let each zone run for a short amount of time and switch to another zone, you can create one program per zone. Have that program run just one zone, and use ‘repeat’ to break it into small sessions so if power is reset it loses just one small session. Because the entire program has only one zone, it will just continuously run that zone until it finishes all repeats. Create another program for the next zone and start at the appropriate time. There are creative ways to get what you need. But it seems you would rather want to complain about what’s missing than to leverage what’s already there to address your need.
And I don’t understand why UPS is not viable solution. I am not talking about a big box UPS — it can be as small as a USB power bank. Only the controller itself needs to be powered, not your solenoids. No matter how small your box is, I can’t imagine why it wouldn’t fit essentially a cell phone battery in it.
I have never hard of this definition of ‘fail-safe’ as you described.
Lastly, again, why not choose another product? If every other product has this essential feature you want, why spending so much time here complaining about OpenSprinkler? Don’t you want to find a product that does what you want, and move on?
The existing commercial controllers from decades ago use extremely simple programs, they don’t account for dynamic events, the programs don’t overlap with each other, most of them also don’t pull weather data online to determine the dynamic water time. For those kind of simple programs, it’s certainly possible to do a simple look up to figure out what program should be running at any given time.
If you have long watering sessions, you can break them into smaller intervals using the ‘repeat every’ feature available in the programs. For example, instead of watering for a continuously long 12 hour session, set it to water 15 minutes at a time and repeat 48 times. This way, if the controller reboots in between, it at most loses a 15 minute session but the next repeat cycle it will run again. The user manual specifically mentions this ‘repeat’ feature as a way to break down long water sessions into smaller blocks.
Above all, the entire project is open-source. If you feel one feature is missing and needs to be improved, why not modify the code to implement it yourself? You can do it in anyway you want, and don’t have to wait for us to implement it for you.
I can explain why the way you wanted is much more difficult to implement than you may think. The scheduler in the firmware handle zone starting dynamically. The order of zones, overlapping programs, dynamic parameters, are only known at the time those programs start. If the controller reboots and it misses the start time, it’s actually very complicated to trace back in time to recreate the runtime variables. Additionally there is the question of how far it should trace back in time. If you lost power for 10 hours, does it need to step back in time minute by minute for 10 hours to find if any program may have lasted till the time of the reboot? Keep in mind the controller is a low performance microcontroller. Doing this computation all the time will consume all the computation power and prevent it from carrying out other tasks like responding to web requests.
The preview can be done quickly because that’s a client side program, which means it runs on your phone or computer as a JavaScript program, and it only runs it once when you click on the preview button. Your phone and computer are much more powerful processors and so computing the preview is quite easy.
The idea of computing the preview once at reboot and just keep using it doesn’t work. Programs can be changed and edited at any time. The watering percentage can change dynamically at any time. There are all sorts of dynamic events like zones stopped by rain sensors, manually stopped, paused etc. You may think your solution can fix one issue but likely it will result in multiple other issues that you may not have thought about.
Above all, if you have frequent power loss, couldn’t you address that issue directly by installing a UPS?
This issue is only address in the latest firmware 2.2.1(1) (i.e. minor revision(1)). It was still in 2.2.1(0), which is probably what you have right now. Upgrading to 2.2.1(1) should be quite easy — because this is a minor revision change, your settings are all preserved and you don’t need to export/import configurations.
Hi, this is a known bug in older firmwares (specifically, on OpenSprinkler 2.3, when setting Zone 1 to a group that’s not the default group A). You should update your firmware to the latest (2.2.1(1)) and that should fix the issue.
This sometimes has to do with the configuration file containing non-English characters. It doesn’t happen to all non-English characters but I’ve seen other users have this problem. One thing you may notice is that your station name array looks like this:
“snames”:[“FY N Lawn”,””,””,””,” Strip (facing west)”,””,””,””]
that means some of the strings are not imported correctly. My suggestion is to perform a factory reset, so the station names get reset. Then before you load the old configurations, make sure you can access the web UI. next, you can open your configuration file, check particularly the station names and program names, see if there are any non-English characters and replace them with English characters. Then import and see if it work.I suggest that you submit a support ticket at:
support.opensprinkler.com
with some basic information, and send your controller back to us so we can check and reflash the EEPROM for you so that it will recognize it as DC again. Without it being recognized as DC, the voltage booster circuit won’t engage and therefore it won’t be able to energize the valves with low-voltage power adapter.But you are right that you can actually use 12VDC to power the controller and if it is able to energize the valves, then you can continue doing that. Technically 12VDC is a bit low for producing inrush current, while a bit high for providing holding current, but I’ve seen people using it for years without problem. So if this works for you you can continue using it.
The design of DC-powered controller is optimized for providing the right currents for both inrush and holding. It produces a boosted voltage about 21VDC to energize the valves. Given that a typical 24VAC valve has a resistance of about 35ohm, this corresponds to 600mA inrush current, which matches most valve’s electric spec. Then it lowers the voltage to the input voltage (7.5VDC), corresponding to about 200mA holding current, which is typical.
If it says AC, but the controller itself has a DC label, then something is damaged — the firmware uses the information stored in a EEPROM on the controller to detect whether it’s AC or DC. If that chip is damaged, it won’t be able to read the DC information, and by default it will treat it as AC.
You mentioned using a 24VAC transformer — are you aware that you should NEVER plug in a 24VAC transformer to a DC powered controller? The DC-powered controller only accepts DC power adapter, up to 12VDC. A 24VAC transformer will fry some components in the controller for sure.
The firmware automatically detects your hardware version (AC or DC) so the same os_221_rev1.hex works on both AC and DC-powered OpenSprinkler 2.3.
I’m confused about whether your hardware is AC powered or DC powered. Your first paragraph said ‘DC’, but you said in the App, it shows it’s AC. You can easily check by looking at the controller — does it have a DC label on it? If so, it’s DC. Alternatively, does it have an orange terminal block, or does it have a black power barrel? If orange terminal block, it’s AC; if black power barrel, it’s DC.
What you have is microcontroller-based OpenSprinkler 2.3, it is NOT OSPi (there is no Pi inside the controller). Not sure why you had the impression this is a Pi-based system.
Firmware update instructions for OpenSprinkler 2.3 are here:
https://openthings.freshdesk.com/support/solutions/articles/5000832311Well, the version numbers you mentioned are quite confusing to me. 3.x sounds like the hardware version, there is no firmware version 3.x.
And what’s 2.4? We’ve never sold any hardware version 2.4.You can send a support ticket at:
support.opensprinkler.com
with your configuration, so we can check why it’s not returning the correct time zone for your location. I am not aware that our weather script returns incorrect time zone for any location we’ve tested. It accounts for DST.The firmware uses your location to automatically obtain time. The NTP server setting only gets the UTC time, the time zone is obtained through our weather server. So if the controller isn’t able to get query results from weather server, or the location is wrong, then it cannot get the correct timezone.
If you want to manually set the time zone, you can clear the location (there is a cross icon next to the location). After clearing the location, the time will become editable. Regardless, the best way is to make sure your controller is receiving weather query results, and the location you set is correct.
This can be due to a variety of reasons. For example, the most obvious ones are if you are using a firewall, or proxy server, the settings may prevent weather queries from reaching the controller.
The HA plugin isn’t written by us, so unfortunately I don’t have much knowledge about it. You can ask the author of the HA plugin for details.
This is not a firmware issue — the Use Metric is never stored in the firmware. The UI does, I believe, auto-detect metric vs imperial system (based on your location). So it’s possible that on your desktop browser it was able to auto-detect. The setting is stored in browser’s local cache. It’s not stored on the controller.
Please file a support ticket:
support.opensprinkler.com
including the specific OTC token you are referring to, so we can take a look what might be wrong.
