Forum Replies Created
-
Posts
-
Ah, ok, I figured out why: station delay time is quantized to every 5 seconds. So if you set a delay time below 5 seconds, it will be rounded to 0. You can set it in multiples of 5.
OK, I checked the firmware code, and here is the logic:
– when special station auto refresh is turned on, the master controller sends a command to turn the remote zone on for 2*MAX_NUMBER_STATIONS seconds each time. As firmware 2.1.7 allows a maximum of 56 zones, this is about 2*56 = 112 seconds, so roughly 2 minutes. And every MAX_NUMBER_STATIONS seconds (56 in this case), the master controller send refreshing signals to renew the on time for another 112 seconds. This keeps the master controller and remote zone in sync as close as possible, so even if master controller loses connection to remote, the remote zone will remain on for no more than 112 seconds.– when special station auto refresh is turned off, the master controller sends a one-time turn-on command to remote zone, to turn it on for the maximum number of time (about 18 hours), and will not send refreshing commands. It then sends turn-off command when the zone is scheduled to be turned off.
If you observe the remote zone turns off after 2 minutes, even if the corresponding zone on the master controller shows longer time, that means the master controller is not sending renew commands for some reason. I don’t know why, but my guess is that maybe it took master controller more than 112 seconds to cycle back and send renew commands — however, even in that case, I would expect it to again turn the remote zone on after some time. So basically I don’t know the reason, however, it sounds like keeping special station auto refresh option off resolves the issue.
Well, it’s exactly because you can already do that by selecting every day using a weekly schedule — selecting interval of 1 day is equivalent to selecting all of Monday to Sunday.
Here it is.
Attachments:
50.97.210.169 is an NTP server we’ve used for a long time in previous firmwares. I am not sure where I got it from, probably from an open-source piece of code. It seems this NTP server is no longer working reliably, that’s why in firmware 2.1.9(3) we changed it to use DNS name like pool.ntp.org
There is no user manual for OSBee — the video on the product page:
https://opensprinkler.com/product/opensprinkler-bee/
basically serves as a manual. There hasn’t been any firmware update for OSBee so what the video shows is the only firmware that’s ever released. The only way to re-configure WiFi is to perform a factory reset — this is done by holding the pushbutton for more than 5 seconds, and the controller will reset to AP mode so that you can follow the WiFi setup steps to get it log on to a new WiFi.I don’t know. I have not seen this issue before. The firmware gets current time from Raspbian system so if there is any issue with timing you should first check the time settings in Raspbian. What version of firmware is running on your RPi? Also, what happens if you start a zone with less than 5 minutes run time?
What’s the firmware version running on your master controller, and the remote controller respectively?
Here are pictures of the front and back of the top-layer board.
Attachments:
Ok, I probably misunderstood the description in your first post. My guess is that it’s possible you have two remote zones which are pointing to the same zone on the remote controller. So if you set one of them to run, the other is not running, then the special station auto-refresh will cause the second one to turn off the remote zone after about 2 minutes. You should check through your remote zone settings and see if there might be a duplicate.
The 18 hours run time is normal: it’s the maximum run time allowed on any zone. The actual run time will be decided by the master controller — when the master controller sends a command to turn off that remote zone, it will be shut off. The reason to have a 18 hr maximum is such that in case master controller loses connection, it won’t leave the remote zone on indefinitely.
I don’t get it: see the screenshot below, it says ‘Login or Signup to submit a new ticket’. I don’t know how it can be more obvious than that.
Attachments:
Scroll to the top do you see a ‘Support’ link? Isn’t that obvious?? Also in the app, you can swipe left to right to open the left-side menu, and it has ‘Help and Support’ link.
I didn’t see anywhere on the page that explains the color coding of the wires, so I can’t say for sure, but generally speaking, I assume red is 5V, black is GND, and yellow is signal (SN1).
Be careful that these types of flow sensors generate high pulse rate, and they may not work with OpenSprinkler 3.0 well — the technical reason is that due to some interrupt issues with ESP8266, the flow sensor reading is implemented by a method that combines interrupt and polling, so when the pulse rate is very high (like more than 100 per second), the controller may not be able to catch up with the fast pulse and so the flow reading can be inaccurate.
If you set a controller as remote (in your case, #2), you should not be operating zones on that controller — instead, you should be operating those zones on the master controller. Basically, a remote controller should only passively listen to the master controller and you should not open zones on that remote controller directly.
The turning off is due to the master controller sending periodic signals to refresh the remote zones, to make sure they are in sync with what the master controller thinks their statuses are. If you don’t want that behavior, you can go to the master controller (#1 in your case), Settings -> Advanced -> and uncheck “Special Station Auto-Refresh”, so that the master controller will not send refreshing commands. However, I recommend you not do so because if you do that, the master controller and remote controller can be out of sync and it can be confusing.
Typical mistakes with zone expander connection is not hooking up the COM (common) wire for zones on the expander. The user manual:
https://openthings.freshdesk.com/support/solutions/articles/5000716364-opensprinkler-user-manuals
page 4 at the top shows a diagram of the correct connection.Look, if you are looking for support with your existing system, you should submit a support ticket — the forum is not the right place to ask for support, especially if you need urgent help — we don’t check forum posts on a regular basis; to start the support process, we need you to provide your order number, so we can check exactly what you have ordered; we also frequently ask you to attach a copy of your configurations, which I am sure you don’t want to put them on a public forum.
That’s a bug in the program which we haven’t fixed. Basically, what’s happening is that programs are always scheduled whether rain sensor is active or not. However, rain sensor status is applied at much lower level — where solenoid actions happen. The reason it’s done this way is that different zones may have different attributes, so you may have a program that contains zones that are not affected by rain sensor. For that reason, the program scheduling does not check rain sensor status, and so you will still receive notification about program being scheduled, even if no zone is actually running. This is on our todo list to be fixed in the future.
I was gonna add one more thing but managed to forget: you may be aware that we also sell DC-powered OpenSprinkler (microcontroller-based one, not OSPi unfortunately). This is my own creation, while all other sprinkler controllers on the market use 24VAC and triacs. The thinking behind developing DC-powered controller is that I consider 24VAC an old technique that should be obsolete. 24VAC transformers are bulky, expensive, and not universal (i.e. same transformer does not work in all countries). On the other hand, DC power adapters are much smaller and cheaper. The DC-powered OpenSprinkler uses MOSFETs, which are much more efficient switches than triacs because, as you mentioned, the voltage drop across a MOSFET switch is very very small so they can run a lot more current.
I have always hoped that the industry will move more towards DC-based system, but it seems no one has any incentive to replace them. Some companies like US Solids, have created motorized ball valves that work with a wide range of voltage (like their 9-24V AC/DC series). I am really hoping to see more of these changes and innovations, because I believe 24VAC should be made obsolete and replaced by more modern systems.
Could you find out the IP address of your phone or laptop when it’s connected to the same network? I am curious to see if they have the same IP address or maybe your guest network is assigning IP in different address ranges.
I don’t know what’s the best way to proceed. If you need to program the controller, you can keep it in AP mode — that way itself behaves like a router. You can have your phone connected to that AP. As long as you use the OpenSprinkler mobile app, you can change settings and set programs (in AP mode the controller has a fixed IP of 192.168.4.1). That way at least you can start using it.
Well we do have a more recent firmware: 2.1.9(3). You can follow the instructions to update to it:
https://openthings.freshdesk.com/support/solutions/articles/5000832310-opensprinkler-3-x-firmware-update-guideWe don’t have resources to test the controller exhaustively with all wifi routers. There might be wifi routers that don’t work very well with the wifi chip. I really don’t have enough knowledge to tell.
Hmm… I really have no idea. If your phone / laptop is on the same network as the controller, I don’t understand how it can’t even return anything with the /ja command. One last thing I can think of, judging from the IP address (10.100.xx.216) is that maybe your network has a different subnet mask. Do you know what kind of wifi network it is? Is it a standard wifi router or is it something more enterprise level? I will check subnet mask, but other than that I really have no idea.
Do you really need to poll every 15 seconds? Rain sensor status doesn’t change that frequently — I think polling once every 5 minutes is sufficient.
Pulse rate is a constant — this depends on the spec of your flow sensor. The flow count is a number that’s increasing, not pulse rate. It’s like saying the speed of water is constant, but the volume of water flowing through the pipe is increasing.
Sure, values are resetted when rebooting.
The github page has links to how to compile:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware
If you use OSPi, the instructions for installing firmware is here:
https://openthings.freshdesk.com/support/solutions/articles/5000631599-installing-and-updating-the-unified-firmware-on-ospi
as to how to get pull request, just google.The next few weeks. It will be released in a new firmware. It will support both sending status and receiving (though initially it probably won’t be the full set of features currently supported by HTTP API).
If you can manage to compile the firmware, you can already get the pull request and compile the firmware yourself.
