Forum Replies Created
-
Posts
-
They are defined in defines.h:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/defines.h#L374The firmware already has a logic:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L727
where if the watering percentage is below 20% AND if the resulting water time is less than 10 seconds then it skips that zone. Perhaps you want these parameters to be set differently?As I said, there are several ways to implement a custom weather algorithm. Here are the details:
1. The best and the easiest way is to make use of the OpenSprinkler HTTP API and have a computer or server (such as a linux machine, a raspberry pi would suffice too) send command to OpenSprinkler to update the watering percentage, or to change program settings as needed. The advantages of this approach include: no need to modify OpenSprinkler firmware; you can use any programming language of your choice, and it’s easy to make changes to the weather algorithm. The only downside is it requires another computer, but as I said, you can use a raspberry pi, which is very cheap.
2. You can also change the firmware on OpenSprinkler. The advantage of this is that it does not requires another computer, but it has many downsides, mainly that changing firmware is more difficult, you are limited to use C++ as that’s what the firmware is written in, and it runs on the microcontroller so the computational cost is more restrictive. Firmware compilation instructions are here.
There are several possible ways to implement a custom weather algorithm, but first of all, please understand that to translate this idea to algorithm, it needs to be more precisely defined. In your example, a condition like ‘If over 85F’ needs to be defined more precisely: did you mean the maximum temperature of a day, of the past 3 days, of the past week, or average temperature, or what is the temperature referring to? Also the action ‘water every 3 days’ — how long should this action persist before it re-checks the condition again? For example, if yesterday’s max temperature is more than 85, but today it’s less than 85, what should be the appropriate action?
In short, while your description seems intuitive and makes sense, to translate it to a computer algorithm requires more precise description.
ESP8266 has built-in bootloader that supports serial programming. Unlike AVR or other microcontrollers, this bootloader is there already to begin with. We use a USB serial (CH340-based) programmer to program it for the first time. With the firmware uploaded, it can then support OTA firmware update. But USB flashing always works, even if the firmware fails to run.
The information you found about GPIO2 may be referring to the bare ESP8266 chip. We don’t ever use the bare ESP8266 chips, instead we use the ESP-12 module, which is very common and it has built-in pull up for GPIO2. Typical circuits for ESP8266 module only require pull-ups for RST, EN, GPIO0, and a pull-down for GPIO15. I’ve never seen that pull-up is required for GPIO2.
You said without that pullup uploading rarely works. I think one possibility is that maybe you are using a serial baud rate that’s too high: 230400 baud rate should be pretty reliable in general. Higher than that generally requires the auto-reset circuit: for example, with the USB programmer that I have, I can use 921600 baud rate, because it has built-in auto-reset circuit.
First of all, you can send a support ticket and request a USB-serial programmer and we can send you one. The programmer can plug into the 2×3 card edge slot close to the top of the PCB, that way you can program it via USB.
Second, if you have your own USB serial (either CH340, or CP2102 or any other serial), you can also use that but you will have to solder wires onto the serial pins, and the standard procedure for getting ESP8266 into flash mode is to keep GPIO0 pulled down to ground when the controller is powered up. GPIO0 is connected to the middle button (B2), so that needs to be pressed down when you power up the controller and then it will enter bootloading mode.
The USB programmer that we use has built-in auto reset circuit, therefore there is no need to press B2 down when using the programmer.
I am not sure about what you said about GPIO2 — GPIO2 is already pulled up internally on ESP8266, there is no need to add external pullup. Though, adding an external pullup won’t hurt either.
Yes 2A is more than sufficient — OpenSprinkler Latch consumes well under 1A so 2A is plenty.
You may want to check if you can find LM2596 modules like the one in the Amazon link. These are widely available and much cheaper than the popolu module. Also they are available on Aliexpress — the shipping can be long during COVID, but the price is unbeatable on Aliexpress.
OpenSprinkler Latch can work with 7.5V input voltage — it has built-in boost converter to generate enough voltage to drive latching valves. So even if input voltage is down to 5V, it can still drive latching solenoids.
I do NOT recommend using the battery unless if you can make sure it has regulated output voltage at 12V or below.
You can use a 7805 linear regulator, a switching regulator like this:
https://www.amazon.com/DZS-Elec-Adjustable-Electronic-Stabilizer/dp/B06XRN7NFQ
or a simpler solution is to use a bunch of diodes in series as a way to drop some voltages. Please make sure that the input voltage MUST be provided through the black power barrel, NEVER provide input voltage through the pin named VIN — the VIN pin is a 5V output pin for powering certain sensors, it’s not for input power.I have never seen this issue. I suggest you use the Test OS API script:
http://raysfiles.com/os/TestOSAPI.html
and check the Json all /ja output and see if it’s valid.Also, you can always submit a support ticket:
https://opensprinkler.com/forums/topic/forum-vs-support-tickets/I am not sure how you use GDB to debug — the firmware runs on the microcontroller and it’s not a process running on your computer, so I am not sure how to use GDB to, say, set breakpoints and step over the firmware code. There are way to debug a microcontroller such as JTAG. That requires hardware support, and I’ve never used JTAG myself. For the moment serial printf is the best way probably.
The firmware github has a pull request that allows disabling RTC:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/pull/118/
In essence, if you don’t plan to have RTC, just go to main.cpp and comment out the following lines:setSyncInterval(RTC_SYNC_INTERVAL); // RTC sync interval setSyncProvider(RTC.get);I recommend using AO3407, although AO3401 should also work. AO3407 has higher gate-source maximum voltage compared to AO3401.
The component on the left (marked QPC) is AO3407 (or CJ3407 as equivalent) — it’s a P-MOSFET.
The one on the right (closer to COM) is AO3400 (or CJ3400 as equivalent) — it’s an N-MOSFET.The IP address is NOT the same with WiFi vs. with wired Ethernet module. Please, always press button B1 to check the IP address assigned to it.
“DHCP disabled as the site will not always have internet access” — I do not understand this — your router’s DHCP feature has nothing to do with Internet access.
“internet connection is required to access the controller because of Java” — no, this is NOT true. You can use the OpenSprinkler mobile app which does not require Internet. It only requires Internet if you use a web browser to directly access the controller. Also, it does not use Java, it uses Javascript.
The forum does not allow .bin type of file. You can try to zip it, or change it to some other extension name. If it still doesn’t work, you can probably put it on Google drive and share a link, or send it to me and I can copy it to a online folder for people to download.
If your water level sensor outputs a signal and that signal voltage is between 0V to 5V, or, if your water level sensor is a dry contact switch (i.e. does not output an active voltage, but is a reed switch or relay switch), you can connect it to OpenSprinkler as a rain sensor or soil sensor. This way, when the sensor is activated, the water programs will not run.
One possibility is that after power break, the OpenSprinkler booted much faster than the router. The firmware uses the following logic to check whether it should go into Ethernet mode or WiFi mode: 1) it detects if the Ethernet module exists by sending a command to the Ethernet module and verify the return value; 2) if it exists, it then does DHCP to attempt to obtain a valid IP address — this step has a 60 seconds time out, if it isn’t able to get valid DHCP within 60 seconds, it goes into WiFi mode. So this could explain why it went into WiFi.
A work-around is to set a static IP on your OpenSprinkler — when using static IP, it will bypass DHCP so as long as it passes step 1, it will stay in wired Ethernet mode. However, setting a static IP on the controller has its own risks: it might result in a IP conflict if your router ends up assigning the same IP to another device. You can avoid that by changing your router’s DHCP configuration to limit the range of DHCP IPs, and give your OpenSprinkler an IP outside of that range.
On the other hand, if this is a one-off issue and you do not anticipate the power break to happen often, perhaps just leave it as is.
Take a look at this thread: https://opensprinkler.com/forums/topic/recommended-flow-meter/#post-66055
@Dulac, apologies for the account issue. We were in the process of cleaning spammers and perhaps there was a false positive on your account.
I don’t completely understand exactly what you want to do to make the pump work for you. For a computer program to work according to your needs, you need to provide a sequence of conditions and logic that can be implemented in the program. For example, if something happens, then do this. If I understand from your description, it sounds like what you want is: if pump motor is not moving (or perhaps this condition should be ‘if there is no water’), then do not run sprinkler programs. Is this correct? As I said, I don’t fully understand the problem to come up with this list of ‘if this, then that’. If you can define it, then I will be able to tell how to do it with OSPi.
Well, by ‘slow-varying’ sensors I mean those whose statuses don’t change more than once per few hours. Flow sensor certainly does not fall into this classification.
If you are looking to publish to MQTT every time flow sensor clicks, and you are sure your flow sensor clicks slowly, it may be feasible. You probably want to insert code into the flow_poll function instead of binarysensor_status function, because as I said binarysensor_status is meant for rain and soil sensors, and they are affected by the sensor on/off delays which you don’t want to apply to flow sensor. Another consideration is that while publishing to MQTT is ok, don’t log flow events to the controller’s log file because that will generate too much log data. If you have OSPi this is probably ok, but microcontroller-based OpenSprinkler does not have much flash memory space, logging raw flow events will quickly fill up the space.
‘flcrt’ is always available, regardless of whether a zone is running or not. So checking flcrt is a good way to detect, for example, water leaks or water usage at any time. If you want to log the total click count, that’s also fine — flcrt is just the rate of change of total click count. But keep in mind that the total click count is volatile — once the controller reboots it will reset to 0.
I don’t think you should use “detect_binarysensor_status” to handle flow sensor. This function is meant for slow changing events like rain or soil sensor activations / deactivations. In addition, they are controlled by the ‘on delay’ and ‘off delay’ parameters to filter out noise / false triggerings.
As I said, flow sensor events are much more rapid and the sensor can fire multiple clicks per second. This will generate a large number of events. If you treat flow events the same way as rain / soil (which is what binary sensor is referred to), the UI will not display it correctly.
What you should do is to take the average number of clicks over a period of time and log/sample that number. The ‘flcrt’ parameter can be used for that — it counts the number of clicks within each 30-seconds window. You can certainly modify the firmware and the UI code to log this paramerter.
