Forum Replies Created
-
Posts
-
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.I am not aware of any ongoing issue with the OTC server at the moment. All our test devices are connected and accessible. Maybe double check your OTC token? If you have created more than 1 OTC tokens, maybe you were using the incorrect token?
It looks like you are using the firmware developed by our German distributor Stefan. Since the analog sensor features are written by him (our firmware does not support this yet), please direct your questions to their forum.
What is firmware 2.4.49? That’s not an officially released firmware. Are you using the firmware by our German distributor Stefan? If so, please direct the question to their forum.
Very cool. I like the circular display, looks very nice. Thanks for sharing!
On a high level, the goal you want to achieve is what the OpenSprinkler-Weather script is doing, except our weather algorithm isn’t using gen AI at the moment. The weather script runs on a cloud server, and the firmware queries it every few hours to get the watering percentage.
I imagine a local (non-cloud) AI-based solution can be very useful for adding computer vision to the controller. For example, turn on sprinklers when there are cats or wild animals on the lawn. It can also be used to add voice recognition capabilities.
