Forum Replies Created
-
Posts
-
Please report your hardware version and firmware version. Without the information it’s difficult to help.
What’s your firmware version? Please always report the firmware version as different firmwares have different configurations.
You can just delete your existing firmware folder, and follow the instructions to install firmware from scratch.
The weather scale is never calculated on the OpenSprinkler controller itself. It is always calculated on the server. As you said, the server call itself was successful as it returned information, but BadWeatherData means parts of the weather data for your location is missing. For example, if it needs 24 hours of data and the weather data contains less than 24 then it will trigger such error. You can try to change your location slightly and try again.
I don’t think you can have it pre-configured because each power socket has a different RF code and no commercial product will have the RF code marked on the product. If you don’t want RFToy, you can use an Arduino and RF receiver to assemble your own RFtoy.
@v1pr: as I said, those functions in OpenSprinkler::start_network only create various objects and initialize them, AP does not need to be started at that point. In any case, I’ve never observed ESP8266 crashing due to this. Is this causing ESP32 to crash?
@v1pr, you said “Logically this should not work on the original esp8266 either…” — I don’t understand what this is referring to. Did you mean some line of code should have appeared before some other line of code? If i had to take a guess: note that creating ESP8266WebServer merely creates the object, it doesn’t do anything yet and certainly does not require having WiFi ready at that point. Same with creating the OpenThingsFramework object. The WiFi AP started at this line of code:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L463
The otf->loop() function does the house keeping of responding to WiFi web requests. AP needs to be started before that, which is the case with the code.I have not followed this thread closely because I haven’t compiled the firmware for ESP32. But the OTF library is designed to support ESP32 as well.
A lot of our customers run fairly big facilities that need more than 16 zones. If you just want to control sprinkler solenoids and have no need for sensors or wired Ethernet it’s certainly possible to compile a version of the firmware to control 4 zones. But our controller is designed to accommodate two independent sensors and support wired Ethernet, so there aren’t even 4 spare GPIO pins left on ESP8266. You might be thinking moving to ESP32 saves some cost? But ESP32 itself is more expensive than ESP8266. The only thing ESP32 would save is an IO expander (PCA9555) and thats not that expensive.
If the service is running currently, you cannot run ./OpenSprinkler as it will report failure to initialize network. You will need to stop the service from running, then you can run ./OpenSprinkler (you need to either be root, or use sudo ./OpenSprinkler).
Are you trying to do this for ESP8266 or Rasbperry Pi? OpenSprinkler 3.x which is based on ESP8266, already support PCA9555/PCA9535, which is an I2C expander similar to MCP23017 but cheaper.
Can you give more specifics? What do you mean by adding I2C support? OpenSprinkler 3.x already supports I2C. Did you mean a specific I2C device?
The OpenSprinkler firmware currently does not use I2C for OSPi at all. There is no hardware conflict — the I2C pins are free to use by any I2C device. You may want to write a small and separate program just to test the I2C functionality, such as using wiringPi to detect MCP23017 to make sure the wiringPi I2C functions are working properly. I have no experience with using wiringPi for I2C so I don’t have any advice. Also, make sure I2C is enabled in your RPi configuration.
Ok, I see what you mean. Honestly this is going to be quite complicated to implement, because each different weather algorithm has their own set of parameters, so to account for all of them that would require keeping track of different sets of parameters for each zone. It can be done it’s just complicated and not sure how many users need this.
Probably the easiest workaround is to split your program into multiple programs. Those that should be affected by weather algorithm are in their own programs, and those that should not be affected are in a different set of programs.
The issue with missing rain data in ETo algorithm has been identified and fixed. Let us know if the problem still persists.
1. yes, it should work with OpenSprinkler. The output of this soil clik sensor is a relay which is a dry contact type.
2. no, this soil sensor is not a dry contact type, it requires an additional microcontroller to ‘interpret’ the result of the soil moisture value. It cannot be used directly with OpenSprinkler.
3. please read the OpenSprinkler user manual to understand how sensors work with the controller. Soil sensor and rain sensor work in the same way — when a program is scheduled to run, it checks the sensor value and if it’s activated then the program will not run. More specifically, zones that are set to be affected by sensor will not run if the sensor is activated.I want to explain that the reason we stopped selling latch expander is that there are fewer than 5 orders of latch expander each year… So it makes no sense for us to continue stocking it. One work around is to buy another latch controller and set it in remote extension mode so it basically works as an expander for your main controller, albeit not physically attached to the main controller. Hope this makes sense.
The web version of the app is hosted at ui.opensprinkler.com
When you access the controller directly in a web browser, it returns a homepage that contains re-direction link to the above site, so the browser can load the web UI from there.
The mobile app is the same Javascript code that is wrapped into a native app. The appearance is the same.
The UI looks different with different firmware because each firmware supports different sets of features and the UI detects your firmware version so that it enables or disables certain UI elements accordingly. For example, OpenThingsToken (OTC) is only supported from firmware 2.2.0, so it doesn’t make sense to show this option for firmwares earlier than 2.2.0.
The firmware itself provides HTTP API to interact with the app / web UI. You can go to support.opensprinkler.com and check the OpenSprinkler HTTP API to check the details.If I remember correctly, flow volume is the flow count multiplied by the pulse rate (basically number of clicks multiplied by volume per click). Flow rate is the flow volume per unit time. In this case, the flow rate is flow volume per minute:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L1422I would say 50 pulses per second is really quite high. A lot of the 2-wire water meter probably only generates 50 pulses per minute, not per second. Due to the way the flow count interrupt routine is implemented, ideally the click count should be less than 10 clicks per second. Not sure if you can get a different sensor that generates less clicks. Usually those that are meant for higher volume flow rate will produce less clicks per second.
The unit doesn’t really matter. By default it uses metric I think, so you can just ignore the unit and thus only the number itself matters.
One issue with using all GPIO pins is that some pins must be held at certain state during power-on, while others can have a moment of glitch during power-on. For example, GPIO2 must remain high at power-on, GPIO15 must be low, and GPIO16 starts as high but flickers for a couple hundred milliseconds. So these GPIOs, when connected to relays, can produce moments of false action of the relays, albeit this only happens at power-on or reboot. If this can be tolerated, then you can use all GPIO pins.
