Forum Replies Created
-
Posts
-
200ish mA current when a zone is running seems normal. So the wiring and connection to solenoid seems fine. Two things to check first:
1. In Settings -> Advanced, check the ‘Boost Time’ option — its default value is 320ms. Has it changed?
2. Do you have a master or pump zone? If so, what’s the brand name / model number of your pump start relay? DC-powered OpenSprinkler is known to not work with all pump start relays, so if you do have one, it’s better to stay with AC-powered OpenSprinkler, or you can change your pump start relay to solid state relay which works well with DC OpenSprinkler.How long is your IFTTT key? Since you are on firmware 2.1.8, I suspect the issue maybe that the IFTTT key length exceeds what’s allowed in firmware 2.1.8. You should consider updating to firmware 2.1.9(3), the latest version — it allows much longer string size so if key length is was the cause then it should be solved by updating firmware.
Never mind, I was able to get it working again. Somehow the ‘create your own applet’ is only showing up in their app and not in browser interface. In any case, please let me know some details of your setup, such as what are you using as action (notification? text message? email?)
I am looking into this issue. It seems IFTTT has changed significantly from the last time I logged in, the entire interface, and some features in the past have disappeared. They might have been moving towards a paid platform. I will do some research and report back.
The controller needs to be powered by a power adapter, so if you don’t have a power outlet where the remote controller is to be installed, that can be tricky. One option is solar power — one of the reasons to go with DC-powered OpenSprinkler is if you need to power it off-grid. I’ve seen customers using solar power (usually with a backup battery) to power it. It can accept input voltage of 12VDC, which is what solar usually outputs. But I have no idea about the cost of it — installing a small solar panel should be relatively cheap, I just don’t have any specific number in mind.
1) I don’t think so — your contractor may be referring to driving the solenoids with 24V DC, but OpenSprinkler DC is specifically designed to drive the solenoid with an impulse voltage to engage it and then use a low voltage (7.5V) to provide holding current. This amount of current is compatible with the amount of current running through the solenoid under AC. So I don’t believe it shortens the span. In addition, plenty of people in the open source community built controllers that drive the solenoids with 12VDC (without the impulse-holding mechanism that OpenSprinkler DC uses), and have been doing so for a long time. So overall I think the risk of lowering the solenoid’s life span is very very small.
2) The claim that ‘AC travels better than DC’ should be taken within context. It all boils down to ‘wire resistance’. Power is wasted on the copper wires as electricity travels through it. The power loss is basically square of current times the wire resistance (I^2 * R). So under the same amount of current, the power loss is the same, regardless of whether it’s running AC or DC. As I said above, DC OpenSprinkler achieves roughly the same solenoid current as in AC mode, so the power loss is similar too.
Where ‘AC travels better than DC’ comes in is the fact that it’s easy to step the voltage up and down with AC. To transmit the same amount of power, higher voltage means less current, and less current means less power loss. So AC wins because you can use transformer to step up the voltage at the transmitter side, which reduces the current being transferred, thus reducing the power loss. On the contrary, it’s not so easy to step up and down DC voltage. If you want to know more, you can read the story of the fights between Thomas Edison and Nikola Tesla, the famous war of DC vs. AC.
3) Not sure how far your solenoid is away from the main controller. If it’s within WiFi range, you could get another opensprinkler and sets it up as a remote controller listening to the master controller. Remote zone is a standard feature supported by OpenSprinkler firmware.
60′ is probably ok. You can make a custom cable using a long Ethernet cable. We don’t have any test data on how far the cable can run — this depends a lot on for example, the wire thickness. So I can’t say for sure, but I think 60′ sounds ok.
The signals running on the ribbon cable are I2C (if you are referring to OS3) and shift register (basically SPI bitbang) data for OS 2.x or OSPi. These are not direct on/off signals.
I honestly have no idea what’s causing this. I suggest that you submit a support ticket with your configurations attached so we can import it on a test OS and see if we can reproduce the issue. If it’s a time zone issue, one thing you can do is to clear your location (click the cross icon next to location) and then the time zone will become editable. So you can set the time zone manually.
You misunderstood how the time is calculated. The time zone (tz) variable is stored in flash memory space and it’s preserved whether or not the controller can reach the opensprinkler weather server or not. Also, it’s not updated frequently, the controller only sends out a weather request at reboot, and every two hours afterwards. Next, every time the controller receives a valid NTP result, it stores it in the real-time clock chip, which is battery backed, so even if the controller is offline, the real-time clock will keep the time remembered and keep it going.
Since you’ve made a lot of posts, I am getting confused exactly when the time change is observed, so here are some questions:
1. Upon reboot, while the LCD displays ‘NTP syncing’, is the time correct?
2. If you observe time change, roughly when does it happen? Immediately after NTP syncing, or some time after?“Anything changed on server side maybe?” What server? NTP server — we have no control over that; opensprinkler weather server — we made no change, plus, your time zone is correct, so that’s not the issue.
The post you linked to said specifically that’s not a NTP issue, it’s a WiFi connection issue. So that post and the issue you encountered are not the same.
You said “The NTP server doesn’t provide any information about the timezone” — yes, of course, that’s why I said “The time is calculated using two pieces of information: the NTP time (which is UTC+0 time) and the time zone.
Your time zone looks fine: 56 means UTC+2, which I assume is the correct time zone for your location. If time zone is correct, then the only thing I can think of would be NTP is getting an incorrect UTC+0 time for some reason. Go to Edit Options -> Advanced, NTP Server IP, what’s the IP set there? If you have firmware 2.1.9(3), you can set it to 0.0.0.0, which will make it use the default pool.ntp.org. Otherwise if there is a valid NTP IP address, it will use that server.
I believe that’s already supported. Check the github repository:
https://github.com/OpenSprinkler/OpenSprinkler-Weather
close to the bottom of the page, where it describes WeeWx.Although this is unlikely to make much of a difference: you can try to access the controller through a web browser, either on your phone, or on your laptop/desktop computer, and see if you could make changes to the additional start times. The browser window can provide a bigger screen space so maybe this will help discover something we missed previously.
@BratNZ: sure, the sensor pins are digital pins so obviously they can only read digital signals (on or off). ESP8266 unfortunately only has one analog pin and that’s already used for reading solenoid current. For that reason the sensors are assumed “switch” sensors, and not analog sensors.
Flow sensors are also switch sensors basically, though they click at much more rapid pace compared to rain or soil sensors.
“What’s the memory usage and cycle time of the current OpenSprinkler code?”
– At resting state, OS 3 has about 27 to 30KB RAM available. There is also plenty of flash memory space, so you can expand the firmware quite a bit. About ‘what’s the cycle time’ — I don’t know what you mean by cycle time. If you are really worried about RAM and flash memory space, you can use OSPi, which is based on Linux.“How many digital I/O ports on the microcontroller are free?”
– On OS 3, none, because all GPIO pins are used. However, you can expand GPIO using IO expander — that’s also how OpenSprinkler expanders work, they use PCA9555 I/O expanders on I2C line.Again, I think if you have complicated processing need, you should consider using OSPi, which has pretty much unlimited processing power and storage.
The time is calculated using two pieces of information: the NTP time (which is UTC+0 time) and the time zone (this is obtained from the opensprinkler weather server, which calculates your time zone using your location). If you export your configurations to a .json file, and open the file, there is a variable called “tz”, which is the time zone. This value should be equal to your time zone (sign included) times 4 plus 48. For example, if your time zone is UTC+0, it should be 48, if it’s UTC+2, it should be 56; if it’s UTC-4, it should be 32 and so on.
Basically if time zone is correct, then the issue has to do with NTP sync, otherwise it has to do with time zone not being calculated correctly.
I can’t think of any obvious reason — are you able to make other changes to the program, such as changing the primary start time? If so, I really don’t know why it can’t save changes to the additional start times.
Turns out to be a Google API permission setting issue. It should be fixed now. Try again and see if it works.
Thanks for reporting this. We are taking a look at this issue — it seems to do with Google Map API. We are contacting Google support and will follow up as soon as we hear back. In the meantime, it seems you can navigate the map and visually select a point, even if the search bar doesn’t work. Also, to choose a weather station (I assume this is using PWS), you need a valid Wunderground API key, in case you are not aware.
Please open a support ticket: we need you to export your configurations so we can import them on a test unit and see if we can reproduce the issue.
Adapters rated for 500mA usually can sustain quite high inrush current — 500mA just means it can maintain 24VAC when supplying 500mA current. But the current and voltage output are on a continuous spectrum — if you start drawing 750mA, for example, it doesn’t just go down to 0 volt, instead, the voltage drops to something below 24V (maybe 22V), and to most solenoid valves 22V works perfectly fine. Of course at some point if a device is drawing a significantly amount of current, then the voltage drops quickly to an insufficient amount.
Another thing to keep in mind that if all valves open at exactly the same time, then the demand for inrush current is quite high. However, if solenoids open one after another, even with just 1 second of delay between them, the demand for inrush current is significantly lower as only at most one inrush current is present at any given moment.
The DC-powered OpenSprinkler is similar, except it actually does the ‘staggering’ automatically — even if you program it to turn on 3 zones at the same time, it will stagger them by 1 second apart. The reason is that DC-powered OpenSprinkler uses an internal voltage booster, to generate a high voltage that can engage the valve. If all three solenoids are turned on at the same time, the impulse voltage may not be sufficient to drive all of them. So staggering them ensures that the impulse only supplies to one at a time, thus reducing the demand. So basically the principle is similar to AC-powered (except on AC-powered there is no automatic staggering so the burden is all on the power supply).
I would say if you want to run more than 2~3 amp of total current you should consider using a relay board. It’s safer and isolate the control side with load side. The calculation from spec sheet often gives you a pretty high number, but in reality, the demand for current is not that high. Most solenoid valves, even rated at 24VAC, would work fine without any problem with something like 20VAC, which also means lower current than spec sheet.
I am not entirely sure how you derived the 3.5A number: are you saying that you are running 11 (3+8) zones simultaneously? That seems a bit too much. If you mean 3 run at the same time, but you have a total of 8 zones, then the calculation should be based on the 3 zones. I am pretty sure even a 750mA adapter would be fine for 3 simultaneous zones. If you do plan to open 11 zones at the same time, I would highly recommend using an external relay board.
Linux-based OpenSprinkler (OSPi) can support SSL as described above. Microcontroller-based OS (like OS 3.0) does not as the chip used in it (ESP8266) is not powerful enough to make it serve SSL as server.
I can’t think of any reason why OS and OG would behave differently — they use the same chip (ESP8266) and at the moment the firmwares for both use the same ESP core version. I don’t think it has anything to do with Blynk either — that’s just a optional feature for OG — Blynk is not turned on by default, and the built-in web interface is always available, just like in OS. It’s certainly true that OS firmware is much bigger and more complicated than OG firmware. But I can hardly imagine why it would make a different in terms of staying connected to the same router.
Just to make sure I understand this question: are you referring to using PWS (personal weather station) as weather data source? I am not sure what you mean by “issues with APIs disappearing from the weather sites they use”. The default weather source we use is DarkSky, and we have a paid API key for it. I’ve not heard reports that the API disappears. So I assume you mean using PWS with Wunderground. Understand that currently we only support PWS through Wunderground. Whether WU API key expired in 6 months or not is beyond my knowledge — I haven’t heard of this, but if this is a new thing, I will take a look and see if there is any work-around. It’s difficult to read directly from your PWS because different PWS have completely different APIs and it’s going to be a big challenge to write code to accommodate them all. On the other hand, those that can send data to WU will all follow WU’s API standard, that’s why read their data through WU makes things much easier and streamlined.
Also, source code for all pieces of the project is available on Github. If you want to customize any part of it, such as changing the way it calculates watering percentage, change the rain delay threshold, you can feel free to do so. The github is:
http://www.github.com/opensprinkler
